On 24/04/18 12:04, Fox, Kevin M wrote:
Yeah, I agree k8s seems to have hit on a good model where interests are
separately grouped from the code bases. This has allowed architecture to not to
be too heavily influenced by the logical groups interest.
I'll go ahead and propose it again since its been a little while. In order to
start breaking down the barriers between Projects and start working more
towards integration, should the TC come up with an architecture group? Get
folks from all the major projects involved in it and sharing common
infrastructure.
One possible pie in the sky goal of that group could be the following:
k8s has many controllers. But they compile almost all of them into one service.
the kube-apiserver. Architecturally they could break them out at any point, but
so far they have been able to scale just fine without doing so. Having them
combined has allowed much easier upgrade paths for users though. This has
spurred adoption and contribution. Adding a new controller isn't a huge lift to
an operator. they just upgrade to the newest version which has the new
controller built in.
Could the major components, nova-api, neutron-server, glance-apiserver, etc be
built in a way to have 1 process for all of them, and combine the upgrade steps
such that there is also, one db-sync for the entire constellation?
In the pre-containers era one of the most common complaints I heard from
operators was that they were forced to upgrade stuff in lock-step
(because of library version dependencies) when they really wanted to
upgrade each service independently. So this definitely wouldn't work for
everyone.
Another idea that has been floated on occasion is of combining all of
the bits of services that run on a compute node (which include parts of
Nova, Cinder, Neutron, Ceilometer, &c.) into a single... thing. I wonder
if that wouldn't be a more interesting place to start.
The idea would be to take Constellations idea one step farther. That the
Projects would deliver python libraries(and a binary for stand alone operation).
In the sense that we've switched most things with a REST API to running
in Apache using wsgi, that's _technically_ what's happening already ;)
Constilations would actually provide a code deliverable, not just reference
architecture, combining the libraries together into a single usable entity.
Operators most likely would consume the Constilations version rather then the
individual Project versions.
If I'm reading right, you're suggesting that users who just want a quick
way to install a small cloud would use a turn-key controller node
package, while those who need something more sophisticated could
continue to install the individual services separately?
It's an interesting idea, but users of the first sort have a tendency to
turn into users of the second sort, and they want a smooth upgrade path
when that happens. I suspect that's why there aren't any deployment
tools that use this model, even though there are probably no technical
obstacles to it even today.
What do you think?
With respect to the db_sync specifically, I think the main problem is
that it exists at all. You want to be able to do a simple rolling update
where you start containers containing new versions of the code, and then
shut down containers containing old versions of the code. Right now you
have to somehow run db_sync with the new code but make sure it happens
before starting the service with the new code - and in some cases you
may have to shut down the old code first. (And as non-conducive as that
is to orchestrated container deployments, it was 10 times worse
pre-containers when it was virtually impossible to install the two
versions of the code side-by-side.) But once your deployment tool has
solved that horrible problem, it's not difficult for it to add a
for-loop to do it for every service.
What would be a bigger win would be to get rid of db_sync altogether. It
was born in an era when we did massive data migrations between versions.
We've now adopted guidelines for rolling updates saying that we should
only do fast operations like adding/dropping tables/columns during
db_sync, and that deprecation periods must permit the DB to be upgraded
while instances of the previous version of the service are still
running. Once services comply with those guidelines is there any reason
we can't just always update the DB schema during service start-up and
ditch the separate `<service>-manage db_sync` commands? Maybe that would
be a good project-wide goal for an upcoming release.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
