Open Stack

2018-04-25 0:04 GMT+08:00 Fox, Kevin M <Kevin.Fox at pnnl.gov>:
>
> 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.
>

I believe to combine API services into one service will be able to scale
much easier. As we already starting from providing multiple services and
binding with Apache(Also concern about Zane's comment), we can start this
goal by saying providing unified API service architecture (or start with
new oslo api service). If we reduce the difference between implementation
from API service in each OpenStack services first, maybe will make it
easier to manage or upgrade (since we unfied the package requirements) and
even possible to accelerate APIs.

> 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?
>

I like Zane's idea of combining services in Compute Node.

> 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). 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.
>
> What do you think?

It won't hurt when we providing unified OpenStack command (and it's
actually a great stuff), and it should not break anything for API. Maybe
just one more API service call OpenStack API service and it base on teams
to said providing plugin or not. I think we will eventually reach the goal
in this way.

>
> Thanks,
> Kevin--
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180425/d4cf74e7/attachment.html>