Open Stack

On Thu, Mar 12, 2015 at 7:19 PM, Thomas Goirand <zigo at debian.org> wrote:

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

I do acknowledge your concerns, absolutely. If you or Alex could come up
with a plan that mitigates both my lack of knowledge and the risk of
inaccurate docs I'd like to review it so we can all move forward.

Thanks,
Anne


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


-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20150312/c0a45f05/attachment-0001.html>