Open Stack

Hi again all,
I'm top posting, sorry. I finally had a chance to do more in-depth analysis
of these bug reports.

I hesitated initially on whether to post to the list, since there are a lot
of hard feelings coming up around this, and people are pretty tired of the
"drama." But we need to address these issues, and I don't want anyone to
feel personally tied to the issues. There is no individual blame or fault
here. That said, as PTL I do need to make a decision based on technical
merits.

I did an analysis to see whether the install issues come up from a
difference in philosophy or bugs in the doc. I'm leaning towards "bugs in
the doc causing issues" as the final analysis, and I'd like us to consider
stopping links to the Debian Install Guide until the issues are addressed.

Here's my analysis.

Where debconf inconsistency that don't cause failure to install but may
confuse, these I don't consider as reasons to stop publishing:
1. deprecated options in mysql conf
2. database names end in db
3. uses ip address instead of name
4. admin tenant and user instead of separate users and a service tenant
5. deprecated xml body middleware and kvs backend for keystone
6. debconf doesn't enable verbose logging

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.
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
4. glance.conf problem: default_store in wrong location, should be in
[glance_store]
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.

nova.conf config:
(opinion) metadata service enabled, different from other distros
6. spice console won't work
7. [keystone_authtoken]: identity_uri must not use localhost
8. [keystone_authtoken]: auth_uri must be set to public url
9.doesn't reference controller node for nova to glance connection (acts
like single node install)
10.problems with needing port 35357 instead of 5000
(opinion) nova.conf compute node could remove database connection but
optional

neutron problems
(opinion, but may cause problems) doesn't let people choose their own
network settings
11. uses deprecated config files
12. local_ip option not there
13. metadata agent won't connect to misconfigured database
14. 16. same keystone problems as nova and glance
15. L2 population won't work

Overall problems due to basic architecture decisions being different:
- Debian assumes images served from same node as compute node
- Debian doesn't have nova-network
- Debian assumes use of Open vSwitch
- Debian assumes certain networking settings
- Debian enables rabbitmq for glance prior to needing it since telemetry is
optional, so architecture seems to assume telemetry is a requirement.

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. I know Thomas and Alex
planned to test this week, so I hope they can validate these bugs and
devise a plan to address them.

Based on the plan, we'll make a decision about links and/or redirects.

Let me know the plans by replying here or responding to the bugs by 2/16/15.

Thanks,
Anne

On Mon, Feb 2, 2015 at 4:38 PM, Anne Gentle <annegentle at justwriteclick.com>
wrote:

>
>
> On Mon, Feb 2, 2015 at 3:21 PM, Matt Kassawara <mkassawara at gmail.com>
> wrote:
>
>> Over the weekend, I attempted to install OpenStack Juno core services
>> (keystone, glance, nova, and neutron) on Debian Wheezy using the Juno
>> installation guide. I could not obtain an operational environment (i.e.,
>> successfully launch an instance) by exclusively using configuration
>> generated by Debconf (and associated tools) or after fixing/augmenting the
>> configuration with existing manual steps in the guide (primarily networking
>> content). I opened the following bugs describing my observations:
>>
>> http://tinyurl.com/ooccchh
>>
>> Thomas (zigo) and I briefly discussed a few of these issues on IRC, but
>> I'm documenting them all for tracking purposes.
>>
>
> Okay, thanks for the list Matt. Looks like 14 new bugs, some of which
> can't really be fixed in the docs, at a glance. The bug reports are
> thorough, and I would like further investigation.
>
> Thomas and Alex and anyone else who'd like to work on these: Our usual
> processes, with these new bugs, is to look at them, mark them
> Status:Confirmed if you agree it can be fixed in the docs, or if it needs
> to be fixed in packaging and/or the config tool, then please set to
> Status:Won't Fix. I believe they are all of Medium Importance.
>
> You can also assign yourself to these bugs once they are Status:Confirmed
> by clicking the exclamation point next to "Unassigned" in the Assigned
> column and then click "Pick me."
>
>
>>
>> I'm stepping away to focus on the networking guide content.
>>
>
> Sounds fine, we'll keep up with reviews of the Install Guide.
>
> Thanks,
> Anne
>
>
>>
>> _______________________________________________
>> OpenStack-docs mailing list
>> OpenStack-docs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>>
>>
>
>
> --
> Anne Gentle
> annegentle at justwriteclick.com
>



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