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, Apr 14, 2020 at 12:37 PM Sean Mooney <smooney at redhat.com> wrote:

> On Tue, 2020-04-14 at 11:45 +0200, Dmitry Tantsur wrote:
> > On Thu, Apr 9, 2020 at 7:26 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?
> > >
> >
> > Let's de-focus on OpenShift please. People who just need a bare metal
> > management solution don't need to understand what OpenStack is. What
> would
> > they assume from a quick search? The first link I've got by googling in a
> > private window is our web site with:
> >
> > OpenStack software controls large pools of compute, storage, and
> networking
> > resources throughout a datacenter, managed through a dashboard or via the
> > OpenStack API. OpenStack works with popular enterprise and open source
> > technologies making it ideal for heterogeneous infrastructure.
> >
> > Is it so unexpected they assume Ironic needs virtual machines to operate?
> yes since that at no point mentions viurtual machines.
> openstack is not a vm managment system.
> even in the early days form diablo or essex openstack cloud manage
> baremetal
> computes as well as contaienr via openvz and lxc then nova docker.
>

Not everyone has the same background as you and me. The common
understanding, to a large extent set by the big public cloud providers, is
that IaaS == VMs. It has only started to change.

Move away from our official resources, and things become even worse. One of
the first links in duckduckgo:

https://opensource.com/resources/what-is-openstack
>   OpenStack lets users deploy virtual machines and other instances that
handle different tasks for managing a cloud environment on the fly.
How many readers will guess bare metal in "other instances"? No explicit
mentions of bare metal on the whole page.

My company also contributes, unfortunately:
https://www.redhat.com/en/topics/openstack
> OpenStack is an open source platform that uses pooled virtual resources
to build and manage private and public clouds.
A lot of references to virtualization and only one passing mention of
"bare-metal" on the whole page.


>
> kubernetes is trying to redifine anything that is not contaienr native as
> not cloud but
> the compute context (container, vm or baremetal) provided by a cloud
> system is an implementation
> detail.

the phrase "OpenStack software controls large pools of compute" does not
> imply vm
> any more then "ironic implies ipmi".  ipmi is an important protocol in
> ironic and many of the vendor driver
> just ipmi with extentions but ironic does not directly imply it and
> openstack does not directly imply vms.
>

Ironic is not a driver of OpenStack, and it's certainly not the most
commonly used driver of Nova, so we cannot really draw parallels with IPMI
here.

Dmitry


>
> i admit there has been some misteps in this regard in terms of openstack
> powered programe
>
> specificly the "OpenStack Powered Compute" trademark
>
> the fact it specificaly requires nova as the requirement is actully the
> compute api
>
> https://opendev.org/openstack/interop/src/branch/master/2018.02.json#L100-L193
> can be consuing to some but it does not require the use of virtual machine
> dirver.
>
> the only requiremetn the list that cannot be achive with ironic today is
> compute-servers-resize.
> if the ironic node was pxe booted form a cinder volume resize would
> actully be doable in a diskless
> baremetal server scech as a blade or a rsd system.
>
> if you look at the apiu requriement objectivly it really only requires
> that the api exsits to create an instance
> but does not state way tthat instance is. it could be an lxc contaienr or
> any other virt dirver that fullfuils the api
> requirements.
>
> it would have been nice if this branding treated ironic and now zun i
> guess as first class citizens but i think that is
> an an artifict of the the fact the requiremetn are defiend in terms of api.
>
> compute-servers-create dose not mean create a vm even if that is what will
> happen most of the time.
> >
> >
> > >
> > > > 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.
> > >
> >
> > +1000 although I'm not sure if all projects are interested in
> intermediate
> > releases. Given how many follow the cycle-with-rc model, I doubt it.
> >
> > Dmitry
> >
> >
> > > --
> > > Jeremy Stanley
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200414/392cbcc2/attachment-0001.html>