Open Stack

I missed that mail, and I feel like I need to reply now.

Mostly, I feel that some of the points are completely wrong. Let me
quote and you'll get my point...

On 02/06/2015 07:16 PM, Anne Gentle wrote:
> Here's my analysis.
> 
> Where debconf inconsistency that don't cause failure to install but may
> confuse

I do believe debconf helps to make things more easy for our end users,
not the opposite. I've called for more request of addition to the docs
if things need to be more explicit, so far, it happened only with
Keystone, and merging that patch was really painful, though it happened,
and I think it goes on the right direction.

But IMO, this kinds of statement doesn't help to see progress.

> these I don't consider as reasons to stop publishing:
> 1. deprecated options in mysql conf

Could you be more clear here? What deprecated options? Do you mean when
starting MySQL in the default Debian package for mysql-server? If that's
what you're talking about, I don't think we even need to mention it,
neither on this list, or anywhere (this is a waste of time... this is
just a deprecation WARNING).

> 2. database names end in db

How is this an issue? This is only the default name. If I've set it like
this, it's for a reason, not just for fun. When using sqlite, the db
ends up being (example for keystone) called:
/var/lib/keystone/keystonedb which is self-explanatory. If you remove
"db", then our users would see only /var/lib/keystone/keystone and will
have no clue what that file is for.

Now, someone may suggest to use something like "keystone.db" (like in
Ubuntu). But this doesn't work, as this is incompatible with MySQL (the
dot is not allowed), and this may lead to issue when switching from one
backend to another.

So maybe, what needs to happen, would be the docs to recommend the
scheme which I've been using, rather than Debian switching to a scheme
which happens to not work well.

> 3. uses ip address instead of name

?!? Where? Could you be more specific?

> 4. admin tenant and user instead of separate users and a service tenant

Keystone sets up a tenant called "admin", but this is optional, and this
isn't even the default option to do so (it's off by default). So you
don't actually *have* to do this, and this has been written clearly in
the latest patch I wrote (which was merged).

You could well use a separate tenant for each service if you like (this
may be out of scope of this message, but I think this is cumbersome to
do so: I don't think this adds any security to use different tenant /
username for each service). Anyway, how is this a problem for our users?
It's completely seamless, as it is possible to select the tenant and
user names when installing a given -api package.

> 5. deprecated xml body middleware and kvs backend for keystone

I don't understand here what you mean. Could you explain?

> 6. debconf doesn't enable verbose logging

And? Debconf isn't a mean for configuring *everything*, it's perfectly
ok to set the debug mode by hand in the configuration file if you wish.
This is a mistake which Matt made as well, and I'm not happy at all to
see this kind of misrepresentation spreading in the whole doc team.

> Where there are actual doc bugs due to Debian being different, causing
> problems later:
> 1. rabbitmq bound to 127.0.0.1, perhaps means it thinks of itself as a
> single node install. While this is a philosophical difference, it
> does prevent services on the network and compute nodes from accessing
> the queue.

This is simply *false*. I'd like facts to be actually checked. This was
truth about a year ago only.

> 2. glance.conf problem that causes actual warnings [keystone_authtoken]:
> identity_uri must not use localhost
> 3. glance.conf problem that causes actual warnings [keystone_authtoken]:
> auth_uri must be set to public url, clients may not be able to
> authenticate against an admin endpoint

I haven't seen any real issue from this. Also, I haven't heard any
explanation about this either, despite my requests for comments on
launchpad.

> 4. glance.conf problem: default_store in wrong location, should be in
> [glance_store]

The Debian package uses upstream unmodified configuration file, so if
there's such an issue, please report it upstream.

> 5. my_ip incorrectly configured for glance, causing inability to connect
> from a separate server (When launching an instance, Compute attempts to
> contact the image service using the value of the my_ip option). Again
> this is probably due to assuming a single server install.

This is only the default, which is made to work on a single box indeed.
This doesn't mean that the IP for glance shouldn't be changed on a
multiple server setup. Though that's not "incorrectly configured", in
fact, it's simply *not configured at all*, which is completely
different. Again, you're doing the same mistake as Matt, believing that
Debconf will do all, which isn't the case currently.

> nova.conf config:
> (opinion) metadata service enabled, different from other distros

How is this a problem? Just because it's different? As much as I
understand, we do need the metadata service. Also, there's a specific
debconf prompt about it.

> 6. spice console won't work

Ah? How come it always worked for me? !?! That's also the default
console in Debian (because it's so much faster than VNC).

> 7. [keystone_authtoken]: identity_uri must not use localhost
> 8. [keystone_authtoken]: auth_uri must be set to public url

I'm not sure what you're referencing here. Could you explain better what
you think is an issue?

> 9.doesn't reference controller node for nova to glance connection (acts
> like single node install)

Same. Please configure it by hand. Not an issue, IMO.

> 10.problems with needing port 35357 instead of 5000
> (opinion) nova.conf compute node could remove database connection but
> optional

dbconfig-common does the db setup only if you ask it to do so. If you
don't, it's going to do nothing. So if you wish to remove the database
connection, just go ahead and edit the configuration file...

> neutron problems
> (opinion, but may cause problems) doesn't let people choose their own
> network settings

!?! Really?

> 11. uses deprecated config files

How is upstream configuration file considered deprecated?

> 12. local_ip option not there

It is in the OVS configuration file, just like upstream. And the sysvrc
/ systemd / upstart scripts are reading it, and it works perfectly well
doing this way. It is *the doc team* which decided that upstream way of
doing things was wrong, and recommends to use the ml2 pluging file for
all. IMO this is completely wrong. If you don't like the way Neutron
upstream did, file a bug there. Don't bother downstream distributions
until this is fixed.

> 13. metadata agent won't connect to misconfigured database

Ah? And? Do you know any component on any software that would?
Seriously, could you rephrase so that I understand? :)

> 14. 16. same keystone problems as nova and glance

Please explain what you're talking about.

> 15. L2 population won't work

It works for me, and that's even the default setup which I've set in the
upstream configuration files (Neutron is the only package for which I'm
patching upstream config, because it would be unusable otherwise). I use
this for running my tempest based CI.

So please be more specific, so that actions can be done.

> Overall problems due to basic architecture decisions being different:
> - Debian assumes images served from same node as compute node

No. Not more than any other distribution: you need to configure the
address of your glance node by editing the configuration file.

> - Debian doesn't have nova-network

That is correct. And nova-network is deprecated upstream, and it's been
YEARS like this. How come the install-guide still talks about it? IMO
that's a problem that the doc team should work on, not me as a Debian
package maintainer. I don't plan *ever* to re-add nova-network which has
been said to be deprecated for like 2 years.

> - Debian assumes use of Open vSwitch

The install guides tells only about OVS anyway. But no, it doesn't
really assume that, it's just the default, but you can select the plugin
using debconf, or by editing the core_plugin directive.

> - Debian assumes certain networking settings

Like?

> - Debian enables rabbitmq for glance prior to needing it since telemetry
> is optional, so architecture seems to assume telemetry is a requirement.

Why would you disable rabbitmq if it is to re-enable it later on?
Anyway, that's also a bug upstream IMO that messages are staying on the
bus forever if nobody consume them. Instead, they should be cleaned
somehow. Also, you're assuming that Ceilometer would be the only
consumer of the Glance messages, though this may be not the case. IMO
this should simply be made explicit in the documentation. Last, it is
very easy to enter some credentials in Glance for rabbitmq that would
not work, and therefore, Glance wouldn't send any message to the queue.
That's stupid, but IMO, here it's a problem upstream, not in the
packaging. Also, the install-guide should be more explicit about this,
which I just learn about a few months ago.

> I have been mediating this debate since November 2014 so I'd like to get
> forward movement. My analysis indicates the issues are due to too many
> assumptions being made for Debian causing problems.

My analysis is that none of what you've reported above is a blocker for
having the Debian side of the doc, and that you've simply cut-pasted
what Matt wrote without checking for the facts by yourself. Since Matt
wrote a number of mistakes, it doesn't feel right.

I've replied to a few bugs opened by Matt, but they never got answered.
This doesn't feel right either.

Last, as you may guess, I'm not happy at all about the outcome. Removing
the link to the Debian guide with so little investigation and a so low
understanding is beyond what I ever could imagine... :(

This doesn't feel at all as a welcoming "big tent". Yes, I'm having a
very "hard feeling" right now and wont sleep well tonight. :/

Cheers,

Thomas Goirand (zigo)