Open Stack

----- Original Message -----
> From: "Thomas Goirand" <zigo at debian.org>
> To: openstack-docs at lists.openstack.org
> Sent: Tuesday, June 3, 2014 4:58:57 AM
> Subject: Re: [Openstack-docs] Patch for automated Debian installations
> 
> On 06/03/2014 02:53 AM, Steve Gordon wrote:
> > From: "Thomas Goirand" <zigo at debian.org>
> >> Probably you wouldn't like to just remove the "openstack-config --set"
> >> things which we see all over the place in the documentation, and which
> >> are RedHat specifics. The debconf prompts are the exact same thing: it's
> >> user interface to OpenStack configuration. Removing both and replacing
> >> them by manual edition of the config file would be inappropriate.
> > 
> > At the summit the team resolved to remove the openstack-config statements
> > and replace them with manual editing of the configuration file to provide
> > more consistency for the guide across distributions [1], and I agree,
> > it's functionally very similar to the use of the debconf prompts. That's
> > why I was surprised to see further patches going in the direction of
> > adding more such steps in place of manual configuration rather than the
> > opposite and noted this on the reviews.

[SNIP]

> > Similarly I believe we resolved to consolidate on documenting RabbitMQ
> > as the message broker and set SELinux to permissive mode, again with
> > the aim of being pragmatic to improve consistency of the guide across
> > distributions.
> 
> Well, that seems very odd to me, because RedHat explicitly supports only
> Qpid, and tells all integrators about it. Using Qpid, at some point,
> will become mandatory to keep official support from RedHat on RHEL,
> which is the reason why I believe this is the wrong choice here. And no,
> I'm not talking about RDO here, but really plain RHEL (I'm seeing the
> etherpad you linked, talks about RDO...)

This is incorrect - RHELOSP 5, includes support for both RabbitMQ and Qpid, as do both RDO Havana and RDO Icehouse. Regardless from a docs.o.o perspective the guides concentrate on the community packages (RDO).

> As for SELinux, it's not an issue in Debian (eg: nothing to do there).
>
> > Another outcome from summit was agreement that each
> > guide should explicitly state its target audience, and Matt filed a
> > bug to this effect, which would make the distinction as to what the
> > guide is and isn't trying to cater to clearer and less hand wavy than
> > it has been up until now. This would be a good opportunity to get
> > involved with shaping that target audience if you disagree with the
> > current group think on this, nebulous as it may be.
> 
> Could you give me the URL of that bug?

https://bugs.launchpad.net/openstack-manuals/+bug/1319394

> >> Please at least back-up from trying to block #97156 and #97158, then
> >> let's calmly discuss about #96695.
> > 
> > I provided my feedback with a -1 (not a -2) on those two patchsets
> > (#97156 and #97158) specifically to avoid blocking them - if two
> > core reviewers agree with the approach at this point they can still
> > approve them for merging.
> 
> Ok.
> 
> > I did put a -2 on the other one (#96695),
> > as did Tom, because I am more strongly of the opinion that its
> > inclusion is not appropriate in its current form.
> 
> Then I'll to make it in a better form. If I understand well, it's the
> "easy button" part that you don't like. In what way could that part be
> more acceptable?

It has the same issues as the other patches in terms of not explaining what information the user is providing for each key while also introducing an all in one deployment tool (albeit an example) which as I noted in the review is something we have previously resolved to exclude from this guide. As I understand it your intent with this section is to explain to users how they can use pre-seeding to automate deployment, but we quite intentionally do not mention automated, non-interactive, deployment at all in this guide. This is why the question being posed is whether it belongs in the guide at all, not whether it can be made acceptable.

> >> I can make it look better if you like, and look less like an "easy button"
> >> (it isn't the goal anyway, so
> >> if it looks like that, then it needs polishing). But I am convince this
> >> section should be there. And finally, it'd be best for both OpenStack
> >> and RedHat to avoid it, but if we can't agree on something, then the
> >> technical committee can decide.
> > 
> > I, like you, contribute to OpenStack documentation primarily in my
> > spare time - it has not been a requirement of my $DAYJOB for some
> > time now. The reason Matt raised this on the list, and I chimed in
> > individually, was to highlight our concerns to the wider team and
> > to have an open discussion with an aim to reaching and documenting
> > consensus as this is a frequent area of contention, and arguably
> > inconsistency. We're all adults here and I am sure we can come to
> > an agreement one way or another as a team. I don't think threatening
> > escalation to the technical committee in your first post discussing
> > the issue raised necessarily promotes healthy discussion, which is
> > all I am trying to do.
> > 
> > Steve
> 
> Maybe the word "threatening" is too strong here.
>
> I wasn't attempting to threaten anyone, or proposing to do it now, just
> merely stating that at the end of a discussion, a possible outcome could
> be asking the tech-ctte to decide.
>
> I come from the Debian community, where there's a lot of heated threads
> in lists and bug entries. While a consensus is always better, one thing
> I have learned is that going quickly to the tech-ctte avoids lots of
> troubles. So if the discussion drains too much of my time and takes too
> long (IMO, it is already the case), then I will go for it, yes. But I
> don't think you should in any case feel "threatened" by it.

While the OpenStack technical committee does have some ability to provide dispute resolution it is generally expected that if a program-internal debate can not be resolved via consensus then the PTL for the program will decide the outcome. As such the technical committee isn't really an exact match with the Debian equivalent, despite the naming. You can find the technical committee's charter, including the role of PTLs, outlined in the governance repo:

    http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst

> BTW, I made lots of points of argumentation in my previous reply to you,
> none of which you commented. Should I then understand that you agree
> with them?

I specifically prefixed my mail with "Providing some initial thoughts inline to better illustrate where I am coming from..." because I wanted to provide a timely, constructive, response. So no you should not, nor should you automatically assume that means I do not agree with them either though.

Thanks,

Steve