Open Stack

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.

Hi Steve,

The summit, like for many, was very busy for me. I had not a single hour
of free time in my schedule. I initially planned on spending time with
the documentation team, however, many sessions clashed (especially with
the release management, which was very important for me as a package
maintainer), and I had to make choices. Unfortunately, I missed the
session you are talking about.

Thanks for telling me what has been discussed, and sorry I couldn't make it.

If I had the chance to come to this session, I would have voice my
concern. Distributions are different, and provide different sets of
tools and interfaces to our users. It should be our goal to introduce
it, while, indeed, trying to keep things consistent across distribution.

I believe we should have a balance here, without reaching one extreme or
the other (eg: extreme constancy or being extremely distro specific).
And of course, it's my view that the debconf interface is important and
should be explained to our users.

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

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?

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

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

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?

Thomas