Open Stack

Hi all,

I am not sure if it is relevant here, but we are trying to use ironic to
boot not only servers but some other HW (which are included into big
projects which are used by big companies all across the world to provide
services) to add it into our machinery in a controlled CI environment.

Also, I think we will use the stack to provision OSP and I have an
expectation to take over CaaS with Zul ?)

Also we are going to provision all HW (as mentioned before, not only
servers but a bit more) of our equipment using ironic.

On Tue, 14 Apr 2020 at 04:25, <Arkady.Kanevsky at dell.com> wrote:

> Agree. We need more visibility into users and their use cases.
>
> -----Original Message-----
> From: Julia Kreger <juliaashleykreger at gmail.com>
> Sent: Monday, April 13, 2020 3:31 PM
> To: Dmitry Tantsur
> Cc: openstack-discuss
> Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?
>
>
> [EXTERNAL EMAIL]
>
> Jumping back into the thread after taking a few days off last week and
> disconnecting.
>
> On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
> >
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 4:03 AM <Arkady.Kanevsky at dell.com> wrote:
> >>
> >> After reading this lengthy and enlightening threadI come back to Julia
> original points.
> >>
> >> 1. What are the benefits of having Ironic as part of OpenStack vs.
> having Ironic as part of opendev?
> >> a. I do not buy that people will use Ironic more as standalone. Biforst
> has been created several years back and was available as standalone Ironic.
> And it is not widely used.
> >
> >
> > It is widely used, just not among big names. Julia and I constantly
> encounter people using it, as well as just installing ironic standalone
> themselves or with kolla. And now metal3 is another standalone ironic use
> case completely unrelated to openstack.
> >
>
> This and worse. Big names use it, but don't like to publicly talk about
> it. Or they use it in fixed process areas. Somewhere along the way, we
> stopped encouraging operators/deployers to really talk about their lives
> and the way they achieve their work. The result is FAR less visibility of
> their use, and a fast track to perception of non-use. What we need as a
> community is actual data collection and statistics that are not an opt-in
> poll. I know that seems antithetical to OpenStack's culture, but perhaps a
> separate website might be able to help drive that.
>
> Another, possibly silly question, are there metrics available for the logs
> of docs.openstack.org ?
>
> [trim]
>
> >>
> >> b. Will the gate and other processes change? Do not think so since the
> current ones work reasonably well.
> >
> >
> > Not much or not at all.
>
> And also, Ironic is largely on the consumption side of other projects for
> integration point testing. Changes outside our control can break the
> Ironic's gate because there is no cross-gating with the way things have
> structurally resulted and evolved over the years. Sometimes we've been able
> to get breaking changes in other projects reverted quickly, but getting
> forward moving fixes has always been an uphill battle because the
> perception of other projects and areas is that it works for them.
>
> [trim]
>
> >
> >>
> >> d. Will Ironic change its release cadence if it is no longer part of
> OpenStack proper? Ironic is only as good as its underlying drivers. That
> means that all drivers, that are currently outside of OpenStack governance
> will have to follow.
>
> In-tree drivers are subject to governance and release processes at
> present. Which is why our stable branch cut is when we release for the
> cycle. Also because we're not able to otherwise create the branch without a
> tag and we don't get beta releases. (Those who hack on the releases repo
> scripting, please feel free to correct me!)
>
> What is not subject to governance is vendor specific API client libraries.
>
> [trim]
>
>

-- 
Ruslanas Gžibovskis
+370 6030 7030
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200414/d4c5eba1/attachment.html>