<div dir="ltr">Hi all,<br><div><br></div><div>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.</div><div><br></div><div>Also, I think we will use the stack to provision OSP and I have an expectation to take over CaaS with Zul ?)</div><div><br></div><div>Also we are going to provision all HW (as mentioned before, not only servers but a bit more) of our equipment using ironic.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Apr 2020 at 04:25, <<a href="mailto:Arkady.Kanevsky@dell.com">Arkady.Kanevsky@dell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Agree. We need more visibility into users and their use cases.<br>
<br>
-----Original Message-----<br>
From: Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>> <br>
Sent: Monday, April 13, 2020 3:31 PM<br>
To: Dmitry Tantsur<br>
Cc: openstack-discuss<br>
Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?<br>
<br>
<br>
[EXTERNAL EMAIL] <br>
<br>
Jumping back into the thread after taking a few days off last week and disconnecting.<br>
<br>
On Tue, Apr 7, 2020 at 3:34 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Tue, Apr 7, 2020 at 4:03 AM <<a href="mailto:Arkady.Kanevsky@dell.com" target="_blank">Arkady.Kanevsky@dell.com</a>> wrote:<br>
>><br>
>> After reading this lengthy and enlightening threadI come back to Julia original points.<br>
>><br>
>> 1. What are the benefits of having Ironic as part of OpenStack vs. having Ironic as part of opendev?<br>
>> 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.<br>
><br>
><br>
> 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.<br>
><br>
<br>
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.<br>
<br>
Another, possibly silly question, are there metrics available for the logs of <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a> ?<br>
<br>
[trim]<br>
<br>
>><br>
>> b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.<br>
><br>
><br>
> Not much or not at all.<br>
<br>
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.<br>
<br>
[trim]<br>
<br>
><br>
>><br>
>> 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.<br>
<br>
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!)<br>
<br>
What is not subject to governance is vendor specific API client libraries.<br>
<br>
[trim]<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Ruslanas Gžibovskis<br>+370 6030 7030<br></div></div></div>