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

Sean Mooney smooney at redhat.com
Mon Apr 6 11:12:58 UTC 2020


On Mon, 2020-04-06 at 10:40 +0200, Dmitry Tantsur wrote:
> On Mon, Apr 6, 2020 at 10:18 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:
> 
> > On 06.04.2020 09:51, Dmitry Tantsur wrote:
> > > 
> > > 
> > > On Fri, Apr 3, 2020 at 2:48 AM Lingxian Kong <anlin.kong at gmail.com
> > > <mailto:anlin.kong at gmail.com>> wrote:
> > > 
> > >     I see we are talking about another "Gnocchi", when Gnocchi moved out
> > 
> > of
> > >     OpenStack, people said they could run Gnocchi in standalone mode
> > 
> > without
> > >     installing the other OpenStack services, then they changed default
> > >     dependency of some other projects (Ceilometer, Panko, etc) to
> > 
> > Gnocchi.
> > >     As a result, they are all dead (or almost dead).
> > > 
> > > 
> > > I'd be very careful comparing Ironic to Gnocchi/Telemetry. I think the
> > > fate that Telemetry met was largely due to staffing problems, more
> > > specifically, all large contributors pulling away from it. It would end
> > > up the same inside or outside of OpenStack.
> > > 
> > > 
> > >     Another example is a long time ago in one OpenStack project, there
> > 
> > was a
> > >     demand for secret management, people said, Barbican is not mature and
> > >     not production ready yet, we shouldn't dependent on Barbican but
> > 
> > could
> > >     make it optional, as a result, Barbican never adopted in the project
> > 
> > in
> > >     real deployment.
> > > 
> > > 
> > > I don't know much about the Barbican situation, but there may be other
> > > explanations. Some operators are against deploying any new service
> > > unless absolutely necessary, because any new service is a maintenance
> > > burden.
> > > 
> > > At the Denver PTG we were talking about non-Keystone authentication in
> > > Ironic. Keystone is arguably very trivial to install, and still it meets
> > > some resistance.
> > > 
> > > 
> > >     I have been involved in OpenStack community since 2013, I see people
> > >     came and left, I see projects created and died, until now, there are
> > >     only a few of projects alive and actively maintained. IMHO, as a
> > >     community, we should try our best to integrate projects with each
> > 
> > other,
> > >     no project can live well without some others help, projects rarely
> > >     stand or fall alone.
> > > 
> > > 
> > > To be clear, my proposal does not affect this. Specifically:
> > > 1) I don't suggest reducing the number of integration points.
> > 
> > But having *more* integration points and functional duplication, like
> > internal project's authorization, coordination (placement/messaging),
> > shared libraries, indirectly reduce the integration points in OpenStack
> > and pulls off contributors by spreading its focus on that otherwise
> > would have been shipped and maintained "out of box" (or out of big
> > tent). Not ranting, I understand that it is pointless to complain
> > against inevitability.
> > 
> 
> On the other hand, not having some of these prevents adoption (for example,
> the requirement of RabbitMQ has been a huge deal for standalone adoption
> and was considered a blocker for metal3).
> 
> Dmitry
you could use other messaging busses for a long time with oslo.
e.g. zeromq,activemq qpid not just rabbit
if you or someone else was to add supprot for NATS https://nats.io/ or ectd i would love
to try using that in other projects like nova as honestly i think that is the
only true alternitve that has emerged in the last 3-4 years that could propely
replace rabbitmq https://blueprints.launchpad.net/oslo.messaging/+spec/nats-transport

that said there is nothing that requires ironic to use rabbit today
none of the other services should even know if you are using rabbit.
they interact via the restapi only. so ironic is free to use something else if it chooses
too. i belive there are several projects already using etcd. so if a distibupted state model
works better for ironic there is nothing stopping it evloving in that direction.

i would argue that the only reason most service use rabbitmq is that that means there are
less supproting services that need to be maintained by the sys admin.

> 
> 
> > 
> > > 2) Integration points with OpenStack services are already optional in
> > > Ironic.
> > > 
> > > What exactly is your concern? Ironic dropping integration points
> > > altogether? We don't plan on that.
> > > 
> > > Dmitry
> > > 
> > > 
> > >     Well, I'm not part of TC, I'm not the person or team can decide how
> > >     Ironic project goes in this situation. But as a developer who is
> > 
> > trying
> > >     very hard to maintain several OpenStack projects, that what I'm
> > >     thinking.
> > > 
> > >     My 0.02.
> > > 
> > >     -
> > >     Best regards,
> > >     Lingxian Kong
> > >     Catalyst Cloud
> > > 
> > 
> > 
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> > 
> > 
> > 




More information about the openstack-discuss mailing list