osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Tue, 2020-04-14 at 11:47 +0200, Dmitry Tantsur wrote:
> On Mon, Apr 13, 2020 at 10:53 PM Doug Hellmann <doug at doughellmann.com>
> wrote:
> 
> > 
> > 
> > On Apr 13, 2020, at 4:50 PM, Julia Kreger <juliaashleykreger at gmail.com>
> > wrote:
> > 
> > On Thu, Apr 9, 2020 at 11:27 AM Doug Hellmann <doug at doughellmann.com>
> > wrote:
> > 
> > 
> > 
> > 
> > On Apr 9, 2020, at 1:24 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> > 
> > On 2020-04-08 10:04:25 +0200 (+0200), Dmitry Tantsur wrote:
> > 
> > On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
> > 
> > [...]
> > 
> > Why *can't* OpenShift include OpenStack projects? I haven't seen
> > this adequately explained.
> > 
> > 
> > It's less of a technical issue, but more of misunderstanding that
> > including an OpenStack project does not involve literally
> > installing OpenStack. And no matter what we think, for a lot of
> > people OpenStack==Nova (another marketing issue to address?).
> > 
> > [...]
> > 
> > I don't understand why that would make a difference in this case,
> > unless you're saying that the people who make architectural
> > decisions about what's included in OpenShift have no actual
> > familiarity with Ironic and OpenStack. If you know anyone who works
> > at that company, can you help them understand the difference?
> > 
> > 
> > This part of the argument has completely lost me. OpenShift 4 already
> > includes Ironic. Iâ??m not aware of any challenges that arose while making
> > that happen that would have been solved or even made easier by Ironic being
> > its own OIP.
> > 
> > 
> > I'm sure one time challenges would have been greater initially, but
> > ongoing headaches would be less IMHO. All headaches there are a result
> > of how people want to do their jobs and achieve/interpret goals with
> > perceptions while trying to match that up to policy and procedural
> > frameworks. In essence, without further delineation, it is an uphill
> > battle that focuses on finding the string "OpenStack" and directing it
> > to that process.
> > 
> > 
> > That may be true, but those problems are internal to Red Hat, arenâ??t they?
> > 
> 
> This particular one - yes. Sigh, I regret bringing up metal3, but I wanted
> an example that I'm well familiar with... It's not only about OpenShift.
> Please.

kayobe is perhaps an example although the fact it used a biforst deployed
ironic to provision hardware for use with kolla-ansible to build a cloud slightly
complicate that example. https://docs.openstack.org/kayobe/latest/

kayobe's use of bifrost/ironic is as a barematal host provider, it then treats openstack
as an application that is deployed on those hosts. if it was useful to them to provision spark
or k8s on those host instead i am sure they would jsut swap out kolla-ansible for another deployment
tool to deploy there workload.

this is effectivly how i would expect standalone ironic to be used most often.
to prepare physical host with a base OS that is then manage by another tools that only/predomently
deals with the software confituretion without having to worry about how the hardware was intially bootstraped.

in that useage model none of the other openstack compnents are required although it may be useful to still have
keystone and swift for auth and image storage althouth tftp works equally well in a static deployment.

> 
> Dmitry
> 
> 
> > 
> > 
> > 
> > On one hand, large distributions want us to have stable branches
> > every year or two. Even what we have is too much.
> > 
> > On the other - we have small consumers who could benefit from just
> > pulling the latest(ish) release and knowing that if a serous bug
> > is found there, they won't have to update to the next feature (and
> > potentially major) release.
> > 
> > [...]
> > 
> > This sounds like a problem shared by, well, basically every other
> > project in OpenStack too. Perhaps it's an opportunity to collaborate
> > on finding solutions.
> > --
> > Jeremy Stanley
> > 
> > 
> >