Open Stack

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.