Open Stack

On Mon, Apr 13, 2020, at 1:30 PM, Julia Kreger wrote:
> 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 ?

There are! We've started publishing goaccess reports without personal data for OpenDev's websites hosted off of AFS. Each day we run a job for docs.openstack.org logs, https://zuul.openstack.org/builds?job_name=docs-openstack-goaccess-report#, the zuul build for that job has a goaccess report link which takes you to that day's logs: https://1712df26976563daaa68-1d1d80315f13535a7a11e7a3d54723f4.ssl.cf5.rackcdn.com/periodic/opendev.org/opendev/system-config/master/docs-openstack-goaccess-report/12a08de/docs.openstack.org_goaccess_report.html

These jobs should process all currently available logs and they are on a rotation so we get a snapshot over time. This was in part driven to replace some of the 404 url reporting we had in the past, but does a bit more and could potentially be expanded to do even more.

Also, I think docs.openstack.org might have a google analytics setup but I don't know who manage that these days.

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

It should be noted that the CI system doesn't prevent you from cross gating. We have the technical tools necessary to avoid the bulk of these issues.

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