Hi, what is the status of openstack in Fedora 18? The feature page doesn't describe how to get a working openstack installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration. Specifically the cinder and quantum services don't look like they are set up properly.
Regards, Dennis
On Wed, Nov 07, 2012 at 07:25:08PM +0100, Dennis Jacobfeuerborn wrote:
what is the status of openstack in Fedora 18? The feature page doesn't describe how to get a working openstack installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration. Specifically the cinder and quantum services don't look like they are set up properly.
The packages in F18 are roughly the same as those in EPEL, so the recently-updated instructions here https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL should basically apply.
On 11/07/2012 08:19 PM, Matthew Miller wrote:
On Wed, Nov 07, 2012 at 07:25:08PM +0100, Dennis Jacobfeuerborn wrote:
what is the status of openstack in Fedora 18? The feature page doesn't describe how to get a working openstack installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration. Specifically the cinder and quantum services don't look like they are set up properly.
The packages in F18 are roughly the same as those in EPEL, so the recently-updated instructions here https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL should basically apply.
These are the instructions i followed. The problem is that this setup apparently relies on cinder and quantum and these services aren't configured properly.
I was able to get cinder going by creating a cinder-volumes volume group and removing /etc/tgtd/conf.d/cinder.conf and putting an "include /etc/cinder/volumes/*" in /etc/tgt/targets.conf. After that creating a volume results in a status "available" rather than "error".
I can't get quantum going though and without it instances can not be started. I tried installing the linuxbridge plugin and running quantum-node-setup but when I restart the quantum service I get this in the log: ... 2012-11-07 14:53:28 WARNING [quantum.api.extensions] extension flavor not supported by plugin <quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2 object at 0x2e078d0> ...
I can create, list and delete networks fine but I don't see any bridges coming up and launching instances fails.
Regards, Dennis
On 11/07/2012 08:58 PM, Dennis Jacobfeuerborn wrote:
On 11/07/2012 08:19 PM, Matthew Miller wrote:
On Wed, Nov 07, 2012 at 07:25:08PM +0100, Dennis Jacobfeuerborn wrote:
what is the status of openstack in Fedora 18? The feature page doesn't describe how to get a working openstack installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration.
Hi Dennis,
that is just not true, but I must admit, configuration of OpenStack is a more complex task.
OpenStack consists of a stack of applications providing several partly overlapping services. So it might be the case, you tested one application, but another part has been configured to provide a service.
The packages in F18 are roughly the same as those in EPEL, so the recently-updated instructions here https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL should basically apply.
These are the instructions i followed. The problem is that this setup apparently relies on cinder and quantum and these services aren't configured properly.
I was able to get cinder going by creating a cinder-volumes volume group and removing /etc/tgtd/conf.d/cinder.conf and putting an "include /etc/cinder/volumes/*" in /etc/tgt/targets.conf. After that creating a volume results in a status "available" rather than "error".
were you testing F18 or any RHEL build?
I can't get quantum going though and without it instances can not be started. I tried installing the linuxbridge plugin and running quantum-node-setup but when I restart the quantum service I get this in the log: ... 2012-11-07 14:53:28 WARNING [quantum.api.extensions] extension flavor not supported by plugin <quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2 object at 0x2e078d0> ...
I can create, list and delete networks fine but I don't see any bridges coming up and launching instances fails.
How do you know, cinder is not working or bridges don't come up?
Instead of following the instructions given for EPEL, which don't really apply in depth for f18, you should take a look at
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
On 11/08/2012 07:59 AM, Matthias Runge wrote:
On 11/07/2012 08:58 PM, Dennis Jacobfeuerborn wrote:
On 11/07/2012 08:19 PM, Matthew Miller wrote:
On Wed, Nov 07, 2012 at 07:25:08PM +0100, Dennis Jacobfeuerborn wrote:
what is the status of openstack in Fedora 18? The feature page doesn't describe how to get a working openstack installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration.
Hi Dennis,
that is just not true, but I must admit, configuration of OpenStack is a more complex task.
OpenStack consists of a stack of applications providing several partly overlapping services. So it might be the case, you tested one application, but another part has been configured to provide a service.
The packages in F18 are roughly the same as those in EPEL, so the recently-updated instructions here https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL should basically apply.
These are the instructions i followed. The problem is that this setup apparently relies on cinder and quantum and these services aren't configured properly.
I was able to get cinder going by creating a cinder-volumes volume group and removing /etc/tgtd/conf.d/cinder.conf and putting an "include /etc/cinder/volumes/*" in /etc/tgt/targets.conf. After that creating a volume results in a status "available" rather than "error".
were you testing F18 or any RHEL build?
I can't get quantum going though and without it instances can not be started. I tried installing the linuxbridge plugin and running quantum-node-setup but when I restart the quantum service I get this in the log: ... 2012-11-07 14:53:28 WARNING [quantum.api.extensions] extension flavor not supported by plugin <quantum.plugins.linuxbridge.lb_quantum_plugin.LinuxBridgePluginV2 object at 0x2e078d0> ...
I can create, list and delete networks fine but I don't see any bridges coming up and launching instances fails.
How do you know, cinder is not working or bridges don't come up?
Instead of following the instructions given for EPEL, which don't really apply in depth for f18, you should take a look at
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
Regards, Dennis
On 11/08/2012 03:56 PM, Dennis Jacobfeuerborn wrote:
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
It is linked on that page "How To Test" [1]
[1] http://fedoraproject.org/wiki/Features/OpenStack_Folsom#How_To_Test
So, maybe you were looking to something else?
On 11/08/2012 04:01 PM, Matthias Runge wrote:
On 11/08/2012 03:56 PM, Dennis Jacobfeuerborn wrote:
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
It is linked on that page "How To Test" [1]
[1] http://fedoraproject.org/wiki/Features/OpenStack_Folsom#How_To_Test
So, maybe you were looking to something else?
Hm, my mistake then, sorry. I guess I got too focused on the documentation section because that's where I noticed the installation instructions link.
The test page mentions additional repositories. Are these still required/recommended or should I disregard these and instead use whatever is actually in Fedora 18 now? Given that the beta is around the corner it would probably be better to test the "out of the box" experience. Are there any known issues left that require these repos?
Regards, Dennis
On 11/08/2012 03:15 PM, Dennis Jacobfeuerborn wrote:
On 11/08/2012 04:01 PM, Matthias Runge wrote:
On 11/08/2012 03:56 PM, Dennis Jacobfeuerborn wrote:
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
It is linked on that page "How To Test" [1]
[1] http://fedoraproject.org/wiki/Features/OpenStack_Folsom#How_To_Test
So, maybe you were looking to something else?
Hm, my mistake then, sorry. I guess I got too focused on the documentation section because that's where I noticed the installation instructions link.
I've updated he Docs section to be less confusing.
The test page mentions additional repositories. Are these still required/recommended or should I disregard these and instead use whatever is actually in Fedora 18 now? Given that the beta is around the corner it would probably be better to test the "out of the box" experience. Are there any known issues left that require these repos?
It's best to use the Fedora 18 repos now. I've updated the test day instructions. Note you should be using the Fedora 18 updates-testing repo at this stage. There are currently fixes there for openstack-utils and scsi-target-utils at least.
thanks, Pádraig.
On 11/08/2012 04:29 PM, Pádraig Brady wrote:
On 11/08/2012 03:15 PM, Dennis Jacobfeuerborn wrote:
On 11/08/2012 04:01 PM, Matthias Runge wrote:
On 11/08/2012 03:56 PM, Dennis Jacobfeuerborn wrote:
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
It is linked on that page "How To Test" [1]
[1] http://fedoraproject.org/wiki/Features/OpenStack_Folsom#How_To_Test
So, maybe you were looking to something else?
Hm, my mistake then, sorry. I guess I got too focused on the documentation section because that's where I noticed the installation instructions link.
I've updated he Docs section to be less confusing.
The Docs section isn't that confusing I was just a bit daft :)
The test page mentions additional repositories. Are these still required/recommended or should I disregard these and instead use whatever is actually in Fedora 18 now? Given that the beta is around the corner it would probably be better to test the "out of the box" experience. Are there any known issues left that require these repos?
It's best to use the Fedora 18 repos now. I've updated the test day instructions. Note you should be using the Fedora 18 updates-testing repo at this stage. There are currently fixes there for openstack-utils and scsi-target-utils at least.
So I reinstalled and tried again without the libvirt and selinux workarounds mentioned in the test page as these bugs apparently are fixed in the latest packages.
I ran into two problems:
1. Bug 868357 prevents openstack-demo-install from working
Basically keystone doesn't start and after applying the workaround mentioned in that bug there still seem to be issues possibly related to the fact that the keystone data couldn't be properly setup during the install.
I shut down all services, wiped /var/lib/mysql/*, then started mysql and ran openstack-demo-install again. This time things worked and I could do "cinder list" on the shell without error and create a volume through the horizon interface.
2. Quantum is registered as the networking service but not configured
The test page says the quantum setup is optional but this is not the case. According to https://lists.launchpad.net/openstack/msg17285.html if the quantum service is enabled (and it is apparently after running openstack-demo-install) then horizon uses it. Since it isn't configured this doesn't work though.
The "Test Cases" section also seems to assume the use of the nova-network service which conflicts with what the openstack-demo-install has set up.
So it looks like either the demo install script must be adapted to enable nova-network rather than quantum or the manual configuration of quantum has to be declared mandatory.
Since a network *must* be specified when creating a VM in horizon no VMs can be created at this point.
Regards, Dennis
On 11/08/2012 08:16 PM, Dennis Jacobfeuerborn wrote:
On 11/08/2012 04:29 PM, Pádraig Brady wrote:
On 11/08/2012 03:15 PM, Dennis Jacobfeuerborn wrote:
On 11/08/2012 04:01 PM, Matthias Runge wrote:
On 11/08/2012 03:56 PM, Dennis Jacobfeuerborn wrote:
https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
Thanks for that link. I'm going to retry this with these instructions. I looked at the feature page and that only links to the setup instrunctions for Fedora 17. The EPEL link I found on google.
I would perhaps be a good idea to link the test day page on http://fedoraproject.org/wiki/Features/OpenStack_Folsom so that people looking for that feature get more accurate descriptions for the setup.
It is linked on that page "How To Test" [1]
[1] http://fedoraproject.org/wiki/Features/OpenStack_Folsom#How_To_Test
So, maybe you were looking to something else?
Hm, my mistake then, sorry. I guess I got too focused on the documentation section because that's where I noticed the installation instructions link.
I've updated he Docs section to be less confusing.
The Docs section isn't that confusing I was just a bit daft :)
The test page mentions additional repositories. Are these still required/recommended or should I disregard these and instead use whatever is actually in Fedora 18 now? Given that the beta is around the corner it would probably be better to test the "out of the box" experience. Are there any known issues left that require these repos?
It's best to use the Fedora 18 repos now. I've updated the test day instructions. Note you should be using the Fedora 18 updates-testing repo at this stage. There are currently fixes there for openstack-utils and scsi-target-utils at least.
So I reinstalled and tried again without the libvirt and selinux workarounds mentioned in the test page as these bugs apparently are fixed in the latest packages.
I ran into two problems:
- Bug 868357 prevents openstack-demo-install from working
Thanks for updating that bug with info. I'll look at fixing this tomorrow.
Basically keystone doesn't start and after applying the workaround mentioned in that bug there still seem to be issues possibly related to the fact that the keystone data couldn't be properly setup during the install.
I shut down all services, wiped /var/lib/mysql/*, then started mysql and ran openstack-demo-install again. This time things worked and I could do "cinder list" on the shell without error and create a volume through the horizon interface.
Yes openstack-demo-install is designed to be restartable
- Quantum is registered as the networking service but not configured
The test page says the quantum setup is optional but this is not the case. According to https://lists.launchpad.net/openstack/msg17285.html if the quantum service is enabled (and it is apparently after running openstack-demo-install) then horizon uses it. Since it isn't configured this doesn't work though.
The "Test Cases" section also seems to assume the use of the nova-network service which conflicts with what the openstack-demo-install has set up.
So it looks like either the demo install script must be adapted to enable nova-network rather than quantum or the manual configuration of quantum has to be declared mandatory.
Since a network *must* be specified when creating a VM in horizon no VMs can be created at this point.
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/no...
thanks, Pádraig.
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/no...
I'm going to try this right away, thanks.
I tried to set up quantum according to the docs on the test page and while I don't get any errors it doesn't seem to work as I cannot get any packets to the VM.
This might be related to: https://bugzilla.redhat.com/show_bug.cgi?id=872689
In the l3-agent.log I see this: ... RuntimeError: Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-39e52a8a-9ffe-4ba5-a625-bb7513035cbf', 'sysctl', '-w', 'net.ipv4.ip_forward=1'] Exit code: 1 Stdout: '' Stderr: 'mount of /sys failed: Device or resource busy\n'
As the bug mentions all "ip netns exec" calls seem to fail so this is likely to interfere with quantum and also makes debugging difficult.
Regards, Dennis
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/no...
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.
I tried to set up quantum according to the docs on the test page and while I don't get any errors it doesn't seem to work as I cannot get any packets to the VM.
This might be related to: https://bugzilla.redhat.com/show_bug.cgi?id=872689
It does look like the same issue. Please update with a little info if you can, at least to ping the assignees.
In the l3-agent.log I see this: ... RuntimeError: Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-39e52a8a-9ffe-4ba5-a625-bb7513035cbf', 'sysctl', '-w', 'net.ipv4.ip_forward=1'] Exit code: 1 Stdout: '' Stderr: 'mount of /sys failed: Device or resource busy\n'
As the bug mentions all "ip netns exec" calls seem to fail so this is likely to interfere with quantum and also makes debugging difficult.
thanks, Pádraig.
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/no...
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.
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
Regards, Dennis
I tried to set up quantum according to the docs on the test page and while I don't get any errors it doesn't seem to work as I cannot get any packets to the VM.
This might be related to: https://bugzilla.redhat.com/show_bug.cgi?id=872689
It does look like the same issue. Please update with a little info if you can, at least to ping the assignees.
Done.
Regards, Dennis
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/no...
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
thanks, Pádraig.
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/no...
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.
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. After that I can start the compute service and see it in the service list on the controller:
[dennis@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?
Regards, Dennis
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/no...
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@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.
On 11/07/2012 06:25 PM, Dennis Jacobfeuerborn wrote:
Hi, what is the status of openstack in Fedora 18?
New, but has gone through 2 test days relatively successfully
The feature page doesn't describe how to get a working openstack
The "how to test" section on the feature page lists: https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack That would be the best starting point.
installation going and the "openstack-demo-install" seems to run fine but results in a non-working configuration.
Specifically the cinder and quantum services don't look like they are set up properly.
So there was a recent update to scsi-target-utils you probably need, which is currently in updates-testing: https://admin.fedoraproject.org/updates/scsi-target-utils-1.0.32-2.fc18
Please log specific issues in bugzilla or on #fedora-openstack on freenode, and we'll look into them.
thanks, Pádraig.
-
Dennis Jacobfeuerborn -
Matthew Miller -
Matthias Runge -
Pádraig Brady