Status of openstack in f18?

Mon Nov 12 00:28:05 UTC 2012

On 11/11/2012 11:59 PM, Dennis Jacobfeuerborn wrote:
> On 11/09/2012 11:33 AM, Pádraig Brady wrote:
>> On 11/09/2012 02:07 AM, Dennis Jacobfeuerborn wrote:
>>> On 11/09/2012 01:47 AM, Pádraig Brady wrote:
>>>> On 11/09/2012 12:11 AM, Dennis Jacobfeuerborn wrote:
>>>>> On 11/09/2012 12:55 AM, Pádraig Brady wrote:
>>>>> [SNIP]
>>>>>>
>>>>>> That was the bug fixed (supposedly) by the openstack-utils
>>>>>> update I referenced above. What has probably happened
>>>>>> is that you were just ahead of your fedora mirror
>>>>>> (which was one of the reasons we were using a side repo for the test
>>>>>> days).
>>>>>> Anyway you can update openstack-demo-install manually like:
>>>>>>
>>>>>> rpm -Uvh
>>>>>> http://kojipkgs.fedoraproject.org//packages/openstack-utils/2012.2/6.fc18/noarch/openstack-utils-2012.2-6.fc18.noarch.rpm
>>>>>>
>>>>>>
>>>>>
>>>>> I'm going to try this right away, thanks.
>>>>
>>>> Note the new openstack-utils now does no keystone<->quantum setup at all,
>>>> so that horizon is happy by default. So I've just now updated:
>>>> https://fedoraproject.org/wiki/QA:Testcase_Quantum_V2
>>>> to add the required quantum keystone config steps.
>>>
>>> openstack-demo-install can't really be called again and spits out lots of
>>> errors when I do so (it tries to recreate users and doesn't rewrite e.g.
>>> /etc/nova/nova.conf) so it seems wiping the data manually is the only way
>>> to go.
>>>
>>> Anyway after doing so with the new openstack-utils rpm I now get a
>>> nova-network based setup and after creating a network from the shell and
>>> starting an instance I can successfully ssh into it using the internal IP
>>> from the host.
>>
>> Good stuff.
>>
>>> I was unable to attach a floating ip though. I can add IPs to the pool ok
>>> but when I try to allocate one of the IPs for the VM with "nova
>>> floating-ip-create" I get a failure. The following appears in the nova
>>> api log:
>>> ...
>>> 2012-11-09 02:50:03 TRACE nova.api.openstack   File
>>> "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/contrib/floating_ips.py",
>>>
>>> line 171, in create
>>> 2012-11-09 02:50:03 TRACE nova.api.openstack     address =
>>> self.network_api.allocate_floating_ip(context, pool)
>>> 2012-11-09 02:50:03 TRACE nova.api.openstack   File
>>> "/usr/lib/python2.7/site-packages/nova/network/quantumv2/api.py", line 322,
>>> in allocate_floating_ip
>>> 2012-11-09 02:50:03 TRACE nova.api.openstack     raise NotImplementedError()
>>> 2012-11-09 02:50:03 TRACE nova.api.openstack NotImplementedError
>>
>> So the mention of quantumv2 above is surprising.
>> I'm unsure if you're using quantum or nova networking,
>> but it seems like this run you're using nova networking
>> but may have left stale config pertaining to quantum in
>> /etc/nova/nova.conf.  Please check the 'network_api_class'
>> option, and remove it if you are in fact using nova networking.
>>
>> If you are using quantum here, there there are quantum specific
>> commands for setting up floating IPs at the end of:
>> https://fedoraproject.org/wiki/QA:Testcase_Quantum_V2#Setup
>
> When I tried again the next day I could assign a floating IP without
> problems. Maybe this was a caching issue or my shell env wasn't setup properly.
>
> With that I can now start a single node setup and launch virtual machines
> with proper external connectivity.
>
> I noticed that the quota information on the overview page in horizon is not
> displayed properly and could trace this back to the following patch:
> https://review.openstack.org/#/c/14379/
> With this patch the quota is displayed correctly.

Cool. We'll look at getting that merged to stable/folsom upstream,
and then into our packages.

> Next I tried the following instructions to add a second node:
> https://fedoraproject.org/wiki/QA:Testcase_separate_OpenStack_compute_node
>
> The page referenced "openstack-config-set" which doesn't exist (anymore?).
> Apparently this is now replaced by the syntax "openstack-config --set". I
> changed the page accordingly.

Excellent, thanks.

> After that I can start the compute service and see it in the service list
> on the controller:
>
> [dennis at controller ~]$ sudo nova-manage service list
> Binary           Host                                 Zone
> Status     State Updated_At
> nova-compute     controller                           nova
> enabled    :-)   2012-11-11 23:55:50
> nova-cert        controller                           nova
> enabled    :-)   2012-11-11 23:55:55
> nova-scheduler   controller                           nova
> enabled    :-)   2012-11-11 23:55:55
> nova-network     controller                           nova
> enabled    :-)   2012-11-11 23:55:54
> nova-consoleauth controller                           nova
> enabled    :-)   2012-11-11 23:55:57
> nova-console     controller                           nova
> enabled    :-)   2012-11-11 23:55:50
> nova-compute     node                                 nova
> enabled    :-)   2012-11-11 23:55:58
>
> Notice the two compute entries on "controller" and "node".
>
> The Problem is that I cannot launch instances on the second node. The
> compute log shows the following:
> TRACE nova.openstack.common.rpc.amqp ImageNotAuthorized: Not authorized for
> image f4a80926-fcf7-4758-8a19-ba8c37f3cd16.
>
> Apparently the second node cannot retrieve the image from glance?

Hmm, seems like we need to explicitly config to use keystone on the compute node:
Could you try this line I've added to the wiki:

sudo openstack-config --set /etc/nova/nova.conf DEFAULT auth_stragegy keystone

thanks,
Pádraig.