[Rdo-list] More transparency in RDO infra/process
by Rich Bowen
I wanted to share a portion of a conversation with folks here, and ask
for some help.
To summarize, it's confusing to people who are not part of the process
(and often for people who are) where all of the pieces of the RDO
process live, what they do, how they talk to one another, and so on.
Because of how RDO has evolved, and interacted with other parties
(Fedora, CentOS, upstream OpenStack, Trystack, and now the rpm-packaging
upstream project, and probably other things I'm forgetting) it can feel,
sometimes, that there's some magic involved.
I'd like to bring more clarity to this with some docs, some diagrams,
and whatever else we need to do, both to bring more transparency to the
process, and to help people who are trying to get involved, find their
way. I could definitely use your help in making that happen.
--Rich
-------- Forwarded Message --------
On 09/18/2015 05:49 AM, Rich Bowen wrote:
>
>
>>>> * One of the criticisms against RDO at the moment is the lack of real
>>>> transparency and confusion as to the infrastructure and systems that
>>>> power it.
>
>
> I'm curious where you're seeing this criticism, as I haven't seen it at
> all. I'll take this as an action item to thoroughly document the
> infrastructure and systems that power RDO, but I was completely unaware
> that this was a concern.
>
>
>
It's been mentioned to me by operators that I've spoken to at Meetups
and the like. It's more of a casual observation from users who are more
interested in contributing and being a part of RDO.
If you look at Fedora as an example, all the infrastructure is exposed,
they have things like bohdi and koji that allow you to directly see and
"touch" the entire process used to ship Fedora. You can very easily
follow the process code goes through the whole system to get out the
door (and the documentation of how it all works is very good).
While all the pieces of RDO are open (I think), there is no unified
documentation that shows you a birds eye view of how it all works. We
have tools like delorean and rdopkg which aim to make things easier for
people (and they do), and you often follow the documentation to do what
you need to do, without understanding why. How does code upstream get
into RDO? Following the packging docs it looks like it touches github,
fedora, delorean, and other pieces.
Things like Delorean and the CI parts often have no links off the main
rdo website (or if they do, they are buried in a page somewhere). We
have pieces running on OS1, we have pieces running on Trystack, we have
pieces living inside fedorapeople (?), we have pieces in Centos/CBS, I'm
still not entirely sure where the main site itself is running so if
anyone wants to actually try and understand the infrastructure (and in
particular, what infrastructure impacts RDO) it's a mystery.
Even something as simple as this
https://apps.fedoraproject.org/
To have links to all the parts of the RDO that exist currently, would be
a massive help.
<snip>
Note Rich this is not a slight against yourself and the fantastic work
you have done for RDO, I think this is more because the RDO project has
had to grow, change and adapt so quickly, everything is moving at
breakneck speed so it's hard for people not involved to keep up.
8 years, 6 months
[Rdo-list] Migrating from MySQL-python to PyMySQL
by Javier Pena
Hi all,
During the review of a packaging change to the Neutron package [1], we realized that our installation tools are still using MySQL-python for the db connections, and several of our packages still depend on the MySQL-python package, even though they rely on oslo.db, which has now moved to PyMySQL as default driver [2].
I'd like to propose the following plan for this migration:
a) To avoid any short-term breakage, make python-oslo-db require MySQL-python and python-PyMySQL.
b) Remove all MySQL-python dependencies from those packages that should no longer require it ([3], if I did not miss anyone). All these packages already require python-oslo-db, so there would be no missing deps.
c) Update installers to support PyMySQL in their db connection strings.
d) Once MySQL-python is no longer necessary, remove it from the dependencies for python-oslo-db
What do you think? Steps a) and b) should be relatively easy to do in the short term, but I'm concerned about the testing implications of c) at this time of the Liberty cycle.
Regards,
Javier
[1]- https://review.gerrithub.io/247972
[2]- http://docs.openstack.org/developer/oslo.db/installation.html#using-with-...
[3] python-cinder
python-glance
openstack-heat-common
python-keystone
python-manila
python-neutron
python-nova
python-octavia
openstack-designate-central
openstack-designate-mdns
8 years, 6 months
