[tc] [ironic] Promoting ironic to a top-level opendev project?

Tom Barron tpb at dyncloud.net
Thu Apr 16 14:22:33 UTC 2020

On 16/04/20 14:07 +0100, Sean Mooney wrote:
>On Thu, 2020-04-16 at 07:29 -0500, Sean McGinnis wrote:
>> On 4/15/20 6:47 PM, Jeremy Stanley wrote:
>> > On 2020-04-15 15:46:04 -0700 (-0700), Julia Kreger wrote:
>> > [...]
>> > > People care because they are invested in the community as a whole,
>> > > and I think the thought of such a major change does bring fear. I
>> > > think that is totally natural and honestly I feel the same way.
>> > > Also at the same time, I think we risk letting the fear control
>> > > us. Thus prohibits us and prevents us from what may be the right
>> > > direction. In part, that is also why we need to talk through these
>> > > things. :)
>> >
>> > [...]
>> >
>> > In my case, I just want to make sure folks are approaching these
>> > sorts of decisions by first identifying problems and only *then*
>> > moving to discussing solutions. Otherwise there's a risk that a lot
>> > of effort and resources are wasted on work which doesn't solve
>> > whatever needs solving. Hear each of the arguments (for and against)
>> > with a critical ear, and ask whether they're good solutions for the
>> > problems you've identified.
>> >
>> > Above all, try to avoid the trap of using problems to justify a
>> > solution which has already been chosen for other reasons. When the
>> > discussion starts out as a proposal for some particular solution,
>> > that's how it tends to come across.
>> We also have other projects that can and are used standalone. Cinder has
>> been enabled for that for years, but I'm pretty sure there are others.
>well swift comes to mind im pretty sure it can run standalone or at most using keystone.
>speaking of which keystone can be used standablone in open source mano or keystone.
>im not aware of anyone using placment standalone but it would also be a good candidate.
>glance has no depency on other project to function out side of perhaps keystone.
>im ignoring oslo deps in all cases above by the way since libary dependises are not an overhead
>for the operator they are an over head for the distro maintaienr or you can grab them form pip.
>things like horizon and heat by there nature obviously cannot be used standalone but many of
>the lower level porject could be. if they are actully used standalone is another matter.

Manila can run standalone or with keystone only.  With keystone is the 
way we position it (with CSI plugin) for running multiple Kubernetes 
clusters as isolated tenants with common storage infrastructure.

It would be handy to also have other, loosely coupled, multi-tenant 
service infrastructure services, including one that offers bare metal 
compute instances, developed in a community dedicated to the four open 
principles [1] and aligned with a common technical vision [2].

As I follow this thread I'm trying to understand what "Ironic moving 
out of OpenStack" would mean in terms of the previous paragraph.  That 
doesn't have anything do do with fear of change or wanting to control 
the destinies of other developers.

[1] https://governance.openstack.org/tc/reference/opens.html

[2] https://governance.openstack.org/tc/reference/technical-vision.html

>> So part of this long discussion, I think, is to make sure whatever
>> action the community takes is one that makes sense and does not confuse
>> the situation even more. Looking at it as a whole, does it make sense
>> for any service that can be used standalone to become its own top level
>> project. If it's only after a certain level of adoption, what is the
>> threshold or how is that decided? Is there a better way to not disrupt
>> the community while still addressing the needs of the projects that want
>> to stand out more as something that could be seen as more independent?
>> There isn't really an easy answer here, so it's worth getting input from
>> those involved in the community to make sure we don't go down a path we
>> are going to regret later.
>> Sean

More information about the openstack-discuss mailing list