<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 7:19 PM, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I missed that mail, and I feel like I need to reply now.<br>
<br>
Mostly, I feel that some of the points are completely wrong. Let me<br>
quote and you'll get my point...<br>
<span class=""><br>
On 02/06/2015 07:16 PM, Anne Gentle wrote:<br>
</span><span class="">> Here's my analysis.<br>
><br>
> Where debconf inconsistency that don't cause failure to install but may<br>
> confuse<br>
<br>
</span>I do believe debconf helps to make things more easy for our end users,<br>
not the opposite. I've called for more request of addition to the docs<br>
if things need to be more explicit, so far, it happened only with<br>
Keystone, and merging that patch was really painful, though it happened,<br>
and I think it goes on the right direction.<br>
<br>
But IMO, this kinds of statement doesn't help to see progress.<br>
<span class=""><br>
> these I don't consider as reasons to stop publishing:<br>
> 1. deprecated options in mysql conf<br>
<br>
</span>Could you be more clear here? What deprecated options? Do you mean when<br>
starting MySQL in the default Debian package for mysql-server? If that's<br>
what you're talking about, I don't think we even need to mention it,<br>
neither on this list, or anywhere (this is a waste of time... this is<br>
just a deprecation WARNING).<br>
<span class=""><br>
> 2. database names end in db<br>
<br>
</span>How is this an issue? This is only the default name. If I've set it like<br>
this, it's for a reason, not just for fun. When using sqlite, the db<br>
ends up being (example for keystone) called:<br>
/var/lib/keystone/keystonedb which is self-explanatory. If you remove<br>
"db", then our users would see only /var/lib/keystone/keystone and will<br>
have no clue what that file is for.<br>
<br>
Now, someone may suggest to use something like "keystone.db" (like in<br>
Ubuntu). But this doesn't work, as this is incompatible with MySQL (the<br>
dot is not allowed), and this may lead to issue when switching from one<br>
backend to another.<br>
<br>
So maybe, what needs to happen, would be the docs to recommend the<br>
scheme which I've been using, rather than Debian switching to a scheme<br>
which happens to not work well.<br>
<span class=""><br>
> 3. uses ip address instead of name<br>
<br>
</span>?!? Where? Could you be more specific?<br>
<span class=""><br>
> 4. admin tenant and user instead of separate users and a service tenant<br>
<br>
</span>Keystone sets up a tenant called "admin", but this is optional, and this<br>
isn't even the default option to do so (it's off by default). So you<br>
don't actually *have* to do this, and this has been written clearly in<br>
the latest patch I wrote (which was merged).<br>
<br>
You could well use a separate tenant for each service if you like (this<br>
may be out of scope of this message, but I think this is cumbersome to<br>
do so: I don't think this adds any security to use different tenant /<br>
username for each service). Anyway, how is this a problem for our users?<br>
It's completely seamless, as it is possible to select the tenant and<br>
user names when installing a given -api package.<br>
<span class=""><br>
> 5. deprecated xml body middleware and kvs backend for keystone<br>
<br>
</span>I don't understand here what you mean. Could you explain?<br>
<span class=""><br>
> 6. debconf doesn't enable verbose logging<br>
<br>
</span>And? Debconf isn't a mean for configuring *everything*, it's perfectly<br>
ok to set the debug mode by hand in the configuration file if you wish.<br>
This is a mistake which Matt made as well, and I'm not happy at all to<br>
see this kind of misrepresentation spreading in the whole doc team.<br>
<span class=""><br>
> Where there are actual doc bugs due to Debian being different, causing<br>
> problems later:<br>
> 1. rabbitmq bound to 127.0.0.1, perhaps means it thinks of itself as a<br>
> single node install. While this is a philosophical difference, it<br>
> does prevent services on the network and compute nodes from accessing<br>
> the queue.<br>
<br>
</span>This is simply *false*. I'd like facts to be actually checked. This was<br>
truth about a year ago only.<br>
<span class=""><br>
> 2. glance.conf problem that causes actual warnings [keystone_authtoken]:<br>
> identity_uri must not use localhost<br>
> 3. glance.conf problem that causes actual warnings [keystone_authtoken]:<br>
> auth_uri must be set to public url, clients may not be able to<br>
> authenticate against an admin endpoint<br>
<br>
</span>I haven't seen any real issue from this. Also, I haven't heard any<br>
explanation about this either, despite my requests for comments on<br>
launchpad.<br>
<span class=""><br>
> 4. glance.conf problem: default_store in wrong location, should be in<br>
> [glance_store]<br>
<br>
</span>The Debian package uses upstream unmodified configuration file, so if<br>
there's such an issue, please report it upstream.<br>
<span class=""><br>
> 5. my_ip incorrectly configured for glance, causing inability to connect<br>
> from a separate server (When launching an instance, Compute attempts to<br>
> contact the image service using the value of the my_ip option). Again<br>
> this is probably due to assuming a single server install.<br>
<br>
</span>This is only the default, which is made to work on a single box indeed.<br>
This doesn't mean that the IP for glance shouldn't be changed on a<br>
multiple server setup. Though that's not "incorrectly configured", in<br>
fact, it's simply *not configured at all*, which is completely<br>
different. Again, you're doing the same mistake as Matt, believing that<br>
Debconf will do all, which isn't the case currently.<br>
<span class=""><br>
> nova.conf config:<br>
> (opinion) metadata service enabled, different from other distros<br>
<br>
</span>How is this a problem? Just because it's different? As much as I<br>
understand, we do need the metadata service. Also, there's a specific<br>
debconf prompt about it.<br>
<span class=""><br>
> 6. spice console won't work<br>
<br>
</span>Ah? How come it always worked for me? !?! That's also the default<br>
console in Debian (because it's so much faster than VNC).<br>
<span class=""><br>
> 7. [keystone_authtoken]: identity_uri must not use localhost<br>
> 8. [keystone_authtoken]: auth_uri must be set to public url<br>
<br>
</span>I'm not sure what you're referencing here. Could you explain better what<br>
you think is an issue?<br>
<span class=""><br>
> 9.doesn't reference controller node for nova to glance connection (acts<br>
> like single node install)<br>
<br>
</span>Same. Please configure it by hand. Not an issue, IMO.<br>
<span class=""><br>
> 10.problems with needing port 35357 instead of 5000<br>
> (opinion) nova.conf compute node could remove database connection but<br>
> optional<br>
<br>
</span>dbconfig-common does the db setup only if you ask it to do so. If you<br>
don't, it's going to do nothing. So if you wish to remove the database<br>
connection, just go ahead and edit the configuration file...<br>
<span class=""><br>
> neutron problems<br>
> (opinion, but may cause problems) doesn't let people choose their own<br>
> network settings<br>
<br>
</span>!?! Really?<br>
<span class=""><br>
> 11. uses deprecated config files<br>
<br>
</span>How is upstream configuration file considered deprecated?<br>
<span class=""><br>
> 12. local_ip option not there<br>
<br>
</span>It is in the OVS configuration file, just like upstream. And the sysvrc<br>
/ systemd / upstart scripts are reading it, and it works perfectly well<br>
doing this way. It is *the doc team* which decided that upstream way of<br>
doing things was wrong, and recommends to use the ml2 pluging file for<br>
all. IMO this is completely wrong. If you don't like the way Neutron<br>
upstream did, file a bug there. Don't bother downstream distributions<br>
until this is fixed.<br>
<span class=""><br>
> 13. metadata agent won't connect to misconfigured database<br>
<br>
</span>Ah? And? Do you know any component on any software that would?<br>
Seriously, could you rephrase so that I understand? :)<br>
<span class=""><br>
> 14. 16. same keystone problems as nova and glance<br>
<br>
</span>Please explain what you're talking about.<br>
<span class=""><br>
> 15. L2 population won't work<br>
<br>
</span>It works for me, and that's even the default setup which I've set in the<br>
upstream configuration files (Neutron is the only package for which I'm<br>
patching upstream config, because it would be unusable otherwise). I use<br>
this for running my tempest based CI.<br>
<br>
So please be more specific, so that actions can be done.<br>
<span class=""><br>
> Overall problems due to basic architecture decisions being different:<br>
> - Debian assumes images served from same node as compute node<br>
<br>
</span>No. Not more than any other distribution: you need to configure the<br>
address of your glance node by editing the configuration file.<br>
<span class=""><br>
> - Debian doesn't have nova-network<br>
<br>
</span>That is correct. And nova-network is deprecated upstream, and it's been<br>
YEARS like this. How come the install-guide still talks about it? IMO<br>
that's a problem that the doc team should work on, not me as a Debian<br>
package maintainer. I don't plan *ever* to re-add nova-network which has<br>
been said to be deprecated for like 2 years.<br>
<span class=""><br>
> - Debian assumes use of Open vSwitch<br>
<br>
</span>The install guides tells only about OVS anyway. But no, it doesn't<br>
really assume that, it's just the default, but you can select the plugin<br>
using debconf, or by editing the core_plugin directive.<br>
<span class=""><br>
> - Debian assumes certain networking settings<br>
<br>
</span>Like?<br>
<span class=""><br>
> - Debian enables rabbitmq for glance prior to needing it since telemetry<br>
> is optional, so architecture seems to assume telemetry is a requirement.<br>
<br>
</span>Why would you disable rabbitmq if it is to re-enable it later on?<br>
Anyway, that's also a bug upstream IMO that messages are staying on the<br>
bus forever if nobody consume them. Instead, they should be cleaned<br>
somehow. Also, you're assuming that Ceilometer would be the only<br>
consumer of the Glance messages, though this may be not the case. IMO<br>
this should simply be made explicit in the documentation. Last, it is<br>
very easy to enter some credentials in Glance for rabbitmq that would<br>
not work, and therefore, Glance wouldn't send any message to the queue.<br>
That's stupid, but IMO, here it's a problem upstream, not in the<br>
packaging. Also, the install-guide should be more explicit about this,<br>
which I just learn about a few months ago.<br>
<span class=""><br>
> I have been mediating this debate since November 2014 so I'd like to get<br>
> forward movement. My analysis indicates the issues are due to too many<br>
> assumptions being made for Debian causing problems.<br>
<br>
</span>My analysis is that none of what you've reported above is a blocker for<br>
having the Debian side of the doc, and that you've simply cut-pasted<br>
what Matt wrote without checking for the facts by yourself. Since Matt<br>
wrote a number of mistakes, it doesn't feel right.<br>
<br>
I've replied to a few bugs opened by Matt, but they never got answered.<br>
This doesn't feel right either.<br>
<br>
Last, as you may guess, I'm not happy at all about the outcome. Removing<br>
the link to the Debian guide with so little investigation and a so low<br>
understanding is beyond what I ever could imagine... :(<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This doesn't feel at all as a welcoming "big tent". Yes, I'm having a<br>
very "hard feeling" right now and wont sleep well tonight. :/<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Anne Gentle<br><a href="mailto:annegentle@justwriteclick.com" target="_blank">annegentle@justwriteclick.com</a></div>
</div></div>