Open Stack

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.

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.

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