cloud May 2012

cloud@lists.fedoraproject.org

26 participants
29 discussions

help
by Julien De Groote 10 May '12

10 May '12

On Thu, May 10, 2012 at 2:00 PM, <cloud-request(a)lists.fedoraproject.org>wrote: > Send cloud mailing list submissions to > cloud(a)lists.fedoraproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://admin.fedoraproject.org/mailman/listinfo/cloud > or, via email, send a message with subject or body 'help' to > cloud-request(a)lists.fedoraproject.org > > You can reach the person managing the list at > cloud-owner(a)lists.fedoraproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cloud digest..." > > > Today's Topics: > > 1. Re: nova.rpc.amqp ValueError: too many values to unpack > (Ask Stack) > 2. Re: nova.rpc.amqp ValueError: too many values to unpack > (Pádraig Brady) > 3. Re: nova.rpc.amqp ValueError: too many values to unpack > (Ask Stack) > 4. Re: nova.rpc.amqp ValueError: too many values to unpack > (Russell Bryant) > 5. Re: nova.rpc.amqp ValueError: too many values to unpack > (Pádraig Brady) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 May 2012 06:40:58 -0700 (PDT) > From: Ask Stack <askstack(a)yahoo.com> > To: Pádraig Brady <P(a)draigBrady.com>, Fedora Cloud SIG > <cloud(a)lists.fedoraproject.org> > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > Message-ID: > <1336570858.6536.YahooMailNeo(a)web140518.mail.bf1.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > Pádraig > Thanks. > > core01 is the controller. ( Do I need to disable nova-cert on the > controller? ) > > nova-manage service list > DEBUG nova.utils [req-0d242a3d-ede1-41fd-9064-2b6a0fb3e14d None None] > backend <module 'nova.db.sqlalchemy.api' from > '/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.pyc'> from > (pid=6653) __get_backend /usr/lib/python2.7/site-packages/nova/utils.py:659 > Binary Host Zone > Status State Updated_At > nova-compute core01 nova > enabled :-) 2012-05-09 13:33:01 > nova-scheduler core01 nova > enabled :-) 2012-05-09 13:33:01 > nova-volume core01 nova > enabled :-) 2012-05-09 13:33:01 > nova-cert core01 nova > enabled :-) 2012-05-09 13:33:01 > nova-network core01 nova > enabled :-) 2012-05-09 13:33:01 > nova-compute core00 nova enabled :-) > 2012-05-09 13:32:59 > nova-network core00 nova disabled XXX > 2012-05-08 21:21:04 > > > > > > > nova.conf on the second compute node: > > > [DEFAULT] > logdir = /var/log/nova > state_path = /var/lib/nova > lock_path = /var/lib/nova/tmp > dhcpbridge = /usr/bin/nova-dhcpbridge > dhcpbridge_flagfile = /etc/nova/nova.conf > force_dhcp_release = True > injected_network_template = /usr/share/nova/interfaces.template > libvirt_xml_template = /usr/share/nova/libvirt.xml.template > libvirt_nonblocking = True > vpn_client_template = /usr/share/nova/client.ovpn.template > credentials_template = /usr/share/nova/novarc.template > network_manager = nova.network.manager.FlatDHCPManager > iscsi_helper = tgtadm > #sql_connection = mysql://nova:nova@localhost/nova > connection_type = libvirt > firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver > rpc_backend = nova.rpc.impl_qpid > root_helper = sudo nova-rootwrap > > #rabbit_host = 172.20.0.51 > sql_connection = mysql://nova:nova@172.20.0.51/nova > glance_api_servers = http://172.20.0.51:9292 > iscsi_ip_prefix = 172.20.0.51 > ec2_api = 172.20.0.51 > ec2_url = http://172.20.0.51:8773/services/Cloud > fixed_range = 10.0.0.0/24 > network_size = 256 > qpid_hostname = 172.20.0.51 > verbose = true > auth_strategy = keystone > > > > > > > > ----- Original Message ----- > From: Pádraig Brady <P(a)draigBrady.com> > To: Ask Stack <askstack(a)yahoo.com>; Fedora Cloud SIG < > cloud(a)lists.fedoraproject.org> > Cc: > Sent: Tuesday, May 8, 2012 7:25 PM > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > > On 05/09/2012 12:13 AM, Ask Stack wrote: > > Instances can start on the first nova node (controller) fine. > > > > I am having problems with the second nova computing node. > > "nova-manage service list" shows "nova-compute" have smilies on both > nodes. > > "euca-describe-images" shows the correct images. > > however when I launch an instance, nova's compute log shows > > > > TRACE nova.rpc.amqp File > "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 86, in > pick_glance_api_server > > TRACE nova.rpc.amqp host, port_str = host_port.split(':') > > TRACE nova.rpc.amqp ValueError: too many values to unpack > > TRACE nova.rpc.amqp > > > > This is on a fedora 16 environment. Both computers have the same rpm > packages. > > python-glance-2012.1-4.fc16.noarch > > python-novaclient-2012.1-1.fc16.noarch > > python-nova-2012.1-3.fc16.noarch > > openstack-nova-2012.1-3.fc16.noarch > > Sounds like a config error. > What's the value of this variable in /etc/nova/nova.conf? > > ###### (ListOpt) A list of the glance api servers available to nova > ([hostname|ip]:port) > # glance_api_servers="$glance_host:$glance_port" > > cheers, > Pádraig > > > > ------------------------------ > > Message: 2 > Date: Wed, 09 May 2012 15:00:34 +0100 > From: Pádraig Brady <P(a)draigBrady.com> > To: Ask Stack <askstack(a)yahoo.com> > Cc: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > Message-ID: <4FAA7882.8020700(a)draigBrady.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 05/09/2012 02:40 PM, Ask Stack wrote: > > nova.conf on the second compute node: > > > > [DEFAULT] > > > glance_api_servers = http://172.20.0.51:9292 > > I think you need to remove the http:// prefix from the above > > cheers, > Pádraig. > > > ------------------------------ > > Message: 3 > Date: Wed, 9 May 2012 07:16:17 -0700 (PDT) > From: Ask Stack <askstack(a)yahoo.com> > To: Pádraig Brady <P(a)draigBrady.com> > Cc: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > Message-ID: > <1336572977.77942.YahooMailNeo(a)web140520.mail.bf1.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > Pádraig. > Thanks! that worked. > > > > > > ----- Original Message ----- > From: Pádraig Brady <P(a)draigBrady.com> > To: Ask Stack <askstack(a)yahoo.com> > Cc: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > Sent: Wednesday, May 9, 2012 10:00 AM > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > > On 05/09/2012 02:40 PM, Ask Stack wrote: > > nova.conf on the second compute node: > > > > [DEFAULT] > > > glance_api_servers = http://172.20.0.51:9292 > > I think you need to remove the http:// prefix from the above > > cheers, > Pádraig. > > > > ------------------------------ > > Message: 4 > Date: Wed, 09 May 2012 10:45:14 -0400 > From: Russell Bryant <rbryant(a)redhat.com> > To: cloud(a)lists.fedoraproject.org > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > Message-ID: <4FAA82FA.6040303(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > > ----- Original Message ----- > > From: Pádraig Brady <P(a)draigBrady.com> > > To: Ask Stack <askstack(a)yahoo.com> > > Cc: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > > Sent: Wednesday, May 9, 2012 10:00 AM > > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > > > > On 05/09/2012 02:40 PM, Ask Stack wrote: > >> nova.conf on the second compute node: > >> > >> [DEFAULT] > > > >> glance_api_servers = http://172.20.0.51:9292 > > > > I think you need to remove the http:// prefix from the above > > On 05/09/2012 10:16 AM, Ask Stack wrote: > > Pádraig. > > Thanks! that worked. > > This looks like a reasonable bug to file that would be trivial to fix. > Nova should be a bit more forgiving if the http prefix is given. > > http://bugs.launchpad.net/nova > > -- > Russell Bryant > > > ------------------------------ > > Message: 5 > Date: Thu, 10 May 2012 11:31:37 +0100 > From: Pádraig Brady <P(a)draigBrady.com> > To: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > Message-ID: <4FAB9909.4070105(a)draigBrady.com> > Content-Type: text/plain; charset=UTF-8 > > On 05/09/2012 03:45 PM, Russell Bryant wrote: > >> ----- Original Message ----- > >> From: Pádraig Brady <P(a)draigBrady.com> > >> To: Ask Stack <askstack(a)yahoo.com> > >> Cc: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org> > >> Sent: Wednesday, May 9, 2012 10:00 AM > >> Subject: Re: nova.rpc.amqp ValueError: too many values to unpack > >> > >> On 05/09/2012 02:40 PM, Ask Stack wrote: > >>> nova.conf on the second compute node: > >>> > >>> [DEFAULT] > >> > >>> glance_api_servers = http://172.20.0.51:9292 > >> > >> I think you need to remove the http:// prefix from the above > > > > On 05/09/2012 10:16 AM, Ask Stack wrote: > >> Pádraig. > >> Thanks! that worked. > > > > This looks like a reasonable bug to file that would be trivial to fix. > > Nova should be a bit more forgiving if the http prefix is given. > > > > http://bugs.launchpad.net/nova > > I'm not sure. > > The error message isn't too bad. > > Also it's generally best to limit input combinations. > What about 'https', trailing '/' etc. > > Also maybe in future http might not be used, > which would involve config editing to support. > > cheers, > Pádraig. > > > ------------------------------ > > _______________________________________________ > cloud mailing list > cloud(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud > > > End of cloud Digest, Vol 29, Issue 6 > ************************************ > -- *dgIT Consulting sprl* Rue Britannique, 7 7090 Braine le Comte tel: +32 (0) 496 87 04 51 email: jdegroote(a)dgitconsulting.be

1 0

OpenStack status
by Pádraig Brady 08 May '12

08 May '12

Hi, It's been 2 weeks since the last status update, so here's the latest: https://fedoraproject.org/wiki/OpenStack_status_report_2012-05-08 Historical archives are here: http://fedoraproject.org/wiki/OpenStack_status_reports Cheers, Pádraig. (appended below for convenience) = OpenStack Essex was pushed to EPEL = After a couple of weeks testing in preview repos and epel-testing, the Essex group of OpenStack packages were added to EPEL as a single [https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5719 update] on May 4th. The [[Getting started with OpenStack EPEL]] documentation continues to be updated with simplified instructions as the packages evolve and helper utilities become available. Thanks to all those testing these packages, and for [http://lists.openstack.org/pipermail/openstack-operators/2012-May/000693.ht… informing others] of their availability = OpenStack Essex was pushed to Fedora 17 = Fedora 17 is now frozen for release, which since May 1st [http://lists.fedoraproject.org/pipermail/cloud/2012-May/001423.html includes the Essex OpenStack release]. The [[Getting started with OpenStack on Fedora 17]] documentation is being updated in conjunction with the EPEL documentation referenced above. = Security Fixes = The above releases include these security fixes: * [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2101 openstack-nova: No quota enforced on security group rules] * [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2094 python-django-horizon: XSS vulnerability in Horizon log viewer] = Misc = Adam Young continued to work on running OpenStack in httpd (supporting SSL etc.) and proposed [https://lists.launchpad.net/openstack/msg10843.html a consistent URL naming scheme] for the various services Adam has also started [http://lists.fedoraproject.org/pipermail/cloud/2012-April/001385.html looking at packaging the noVNC] web browser to vnc proxy Russell Bryant who had been deeply involved in the Fedora OpenStack releases has been added to the upstream OpenStack docs-core, common-core and nova-core teams Russell also blogged about [http://russellbryantnet.wordpress.com/2012/04/24/openstack-design-summit-an… his Folsom design summit experience] and impending upstream work Gary Kotton has started looking into [http://www.ovirt.org/wiki/Quantum_and_oVirt Quantum and oVirt integration] Chris Wright and Mark Atwood created a great presentation at [http://www.opencloudconf.com/ The open cloud conference], on [http://www.slideshare.net/fallenpegasus/openshift-openstack-fedora-awesome integrating OpenShift and OpenStack] Derek Higgins and Dan Prince continue to update the [https://github.com/fedora-openstack/openstack-puppet puppet modules supporting OpenStack on Fedora] = OpenStack wiki category = All OpenStack Fedora wiki entries can now be seen at the [https://fedoraproject.org/wiki/Category:OpenStack OpenStack Category]

1 0

Cloud SIG meeting today... in ... 50 minutes.
by Robyn Bergeron 04 May '12

04 May '12

Time flies when you're having fun! Cloud SIG meeting is in a short while. See you there :) When: 1900 UTC (3pm US Eastern, 12pm US Pacific) Where: #fedora-meeting on irc.freenode.net -Robyn

1 0

Re: Packaging of noVNC and Websockets
by Adam Young 02 May '12

02 May '12

https://bugs.launchpad.net/nova/+bug/993352

1 0

Re: Packaging of noVNC and Websockets
by Adam Young 02 May '12

02 May '12

On 05/01/2012 06:44 PM, Anthony Young wrote: > Adam, > > It turns out that kanaka also maintains a websockify tree that > independently houses the websocket and proxy code. As we discussed on > irc, I've proposed some changes to that repo: > https://github.com/kanaka/websockify/pull/40 - if you could take a > look and offer feedback that would be great. > > A few things that differ in that tree from what you describe below: > > * I created a subdirectory for the websockify module (rather than > leaving code at top level) > * I put the proxy base class in websockify/proxy.py (rather than > leaving it in websockify.py, which I rename to bin/websockify). That is fine. I was tempted that way myself, but wasn't sure that there was enough code to justify it. It is only about 280 lines of code, and thus I would see that being deployed in, for example: /usr/lib[64]/python2.7/site-packages/websockify.py as opposed to having to manage /usr/lib[64]/python2.7/site-packages/websockify/__init__.py Perhaps for the git repo, it just makes sense to have a python subdir with the websockify.py and other potential modules files in there, and then an explicit PYTHONPATH set to look there? Just for development. However, your approach is certainly OK. > * I also adopted the convention to use 'www' instead of 'html' to > store html/js/css (although noVNC does not need to use this code > directly). Agreed. I like this better as it is more inclusive. > > Once we work through these structural changes, we can turn our > attention to some of the other fixes that you mentioned to me > (directory listing, organization of html/css/js in the noVNC tree). > > Anthony > > > On Fri, Apr 27, 2012 at 1:26 PM, Adam Young <ayoung(a)redhat.com > <mailto:ayoung@redhat.com>> wrote: > > Trying to get the noVNC package into something that matches the > Fedora Python pakcage specificiation. > > 1. Create a bin directory, and all shell scripts and executable > python files go in there. These will get installed into /usr/bin. > All the files in here will be prefixed by novnc-. > nova-novncproxy is the exception ,as it will eventually move back > to Nova. These are img2js.py, json2graph.py, launch.sh, u2x11, > u2x11, websockify, rebind. > > 2. websocket.py. is a Python file that is both an execuatble and > a module. It will get split into two parts. The module > websocket.py will stay in the top level directory with a .py > extension. The executable portion will go into bin as websockify. > The module code will get installed into /usr/lib/python2.7/site- > packages/. > > 3. All client side Javascript and html files will go into an > html subfile. This includes the html and ico files in the top > dir, and the subdirectories 'include' and 'images'. > > 4. rebind.so needs libtool support. It will get moved into a > subdir name rebind. It will get installed into /usr/lib[64] as a > versioned .so, probably 0.1.0 > > > This will likely conflict with a future websocket RPM, but we'll > burn that bridge when we get there. > > For our purposes, we don't really need rebind, as we are not using > it. I'm almost tempted to leave it out of the RPM. Dan B > mentioned that it needs IPv6 support, but I don't think it is > worth doing that right now. > > > The Init script for the VNC code is in Nova. Since daemon runs > with --user nova, it should be run as a non-priveledged user, > which means that it only has the problem of running in the wrong > CWD. I suggest that we put > > os.chdir(os.path.dirname(sys. argv[0])) > > into nova-novncproxy. > >

1 0

Re: OpenStack Essex now in EPEL
by Pádraig Brady 01 May '12

01 May '12

On 05/01/2012 09:34 PM, Fox, Kevin M wrote: > Figured it out. Sorry to waste your time. It was an extra nova-network process hanging around. Once I stopped it, things started working well again. The documentation here: > https://fedoraproject.org/wiki/Getting_started_with_OpenStack_Nova > > Should probably be amended to state that nova-network should not be started on an additional compute node. Its for HA, not for compute. Great, thanks for telling us that. I've updated the wikis. cheers, Pádraig.

1 0

Fedora 17 openstack packages Status
by Pádraig Brady 01 May '12

01 May '12

Here's a summary of the OpenStack package status for Fedora 17. Updates have been submitted for Essex final for all of the OpenStack packages. Thanks to those involved! Package Status Karma Needed for stable -------------------------------------------------------------------------- openstack-nova-2012.1-1 updates-testing 2 openstack-glance-2012.1-3 stable-pending 0 openstack-keystone-2012.1-1 stable-pending 0 python-django-horizon-2012.1-1 updates-testing 1 python-novaclient-2012.1-1 updates-testing 2 python-eventlet-0.9.16-6 updates-testing 2 openstack-quantum-2012.1-1 updates-testing 3 python-quantumclient-2012.1-1 updates-testing 3 python-keystoneclient-2012.1-1 updates-testing 2 openstack-swift-1.4.8-1 updates-testing 2 openstack-utils-2012.1-1 package-review-request We can push from updates-testing to stable after 3 days (when stable is open), but any karma feedback for the above packages would be appreciated. As for stuff left to do and Fedora release dates: updates-testing is open as you can see. stable will open again April 17th (after beta release) stable will close on May 7th (final change deadline) Also I'd appreciate a review of openstack-utils-2012.1-1 https://bugzilla.redhat.com/show_bug.cgi?id=811601 http://fedoraproject.org/wiki/Packaging:ReviewGuidelines cheers, Pádraig.

1 1

Re: OpenStack Essex now in EPEL
by Pádraig Brady 01 May '12

01 May '12

On 05/01/2012 05:27 PM, Fox, Kevin M wrote: > The following rpm versions were copied from here and had working floating-ip's: > http://pbrady.fedorapeople.org/openstack-el6/ > > Files: > openstack-dashboard-2012.1-2.el6.noarch.rpm > openstack-glance-2012.1-3.el6.noarch.rpm > openstack-keystone-2012.1-1.el6.noarch.rpm > openstack-nova-2012.1-2.el6.noarch.rpm > openstack-quantum-2012.1-1.el6.noarch.rpm > openstack-quantum-linuxbridge-2012.1-1.el6.noarch.rpm > openstack-quantum-openvswitch-2012.1-1.el6.noarch.rpm > openstack-quantum-ryu-2012.1-1.el6.noarch.rpm > openstack-utils-2012.1-1.el6.noarch.rpm > python-django-horizon-2012.1-2.el6.noarch.rpm > python-glance-2012.1-3.el6.noarch.rpm > python-keystone-2012.1-1.el6.noarch.rpm > python-keystoneclient-2012.1-1.el6.noarch.rpm > python-nova-2012.1-2.el6.noarch.rpm > python-novaclient-2012.1-1.el6.noarch.rpm > python-paste-deploy-1.5.0-3.el6.noarch.rpm > python-quantum-2012.1-1.el6.noarch.rpm > python-quantumclient-2012.1-2.el6.noarch.rpm > python-routes-1.12.3-3.el6.noarch.rpm > > Since it worked in a previous version that you provided, I'm guessing it is a packaging problem, not a source problem? Should we try and compare files and see whats different? Well the only difference really between the above and what's in EPEL now, is to use the parallel versions of python-paste-deploy1.5 and python-routes.1.12, in all packages. I.E. code is just moved around. The trace back is consistent with None being returned when rpc calling get_floating_ip on the nova network service. Perhaps there is a timing issue introduced? Could you enable verbose = True in /etc/nova/nova.conf, restart the openstack-nova-{conpute,network,api} services, and get any info in /var/log/nova/* as to why None was being returned through this interface? cheers, Pádraig.

1 0

Essex EPEL Testing
by Brown, David M JR 01 May '12

01 May '12

Fedora Devs, I just spent the last couple of days fighting with Essex on RHEL6 and its been entertaining and I'd like to share some of the oddities and experiences. System configuration is the following. Two nodes on their own /24 connected by cross over to each other on the second interface. The first node is the cloud controller and has tons of storage (11T) and 32Gb ram and 16 cores The second node I would like to make an extra compute node and it has 24Gb ram and 8 cores (still in a work in progress) Originally the cloud controller was running Diablo on RHEL6 and was working fine. I couldn't find any 'upgrade' instructions for going between Diablo and Essex and I wasn't too worried because the usage of the cloud was limited to just a couple of guys. So I was satisfied with backing up manually all the data and rebuild the cluster. I noticed when I did the update that things stopped working and following the install instructions blew away all local data in the cloud. I was following the instructions found at the following URL. http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL I got the packages from http://pbrady.fedorapeople.org/openstack-el6/ First issue. Wow, this is long, its almost long enough that making an uber script in a common package somewhere to run would strip out of most of the manual commands to run. I'd suggest first pulling out all the openstack-config-set commands and put them in a script to run. Not sure what to do about the swift documentation bits, that seems like a very manual set of configurations why aren't they part of the swift rpm? Another suggestion would be to split it out into a couple of documents one describing installation and configuration then the next describing putting data/users into it and starting stuff? thoughts? After I got everything setup and working I noticed an issue with the dashboard, most of the static stuff wasn't showing up I had to add a symlink. /usr/share/openstack-dashboard/static -> openstack_dashboard/static Then the dashboard picked up the right stuff and it worked. There's some consistency issues and I'm not sure if this is an openstack issue in general. The euca tools and how you configure them with keystone only seem to work with your personal instances and configuration. However, the dashboard seems to show users everything associated with the project instead. For example when I allocate floating IPs from the website those won't show up when I run euca-describe-addresses and respectively euca-allocate-address won't show up the IP allocated in the dashboard. I've looked at the database and the project ids are used when using the dashboard and user ids are used when using the euca tools. I think the euca tools could be setup to see everything that the dashboard sees however the documentation doesn't point to how to do that. There also seems to be some serious functionality faults that I can't seem to make work. I can't make a user attached to multiple projects, not sure how to do that. Also, seems like there's a lot of, "huh, that doesn't seem implemented yet." However, this seems like a general openstack issue, documentation says X but that doesn't work yet or anymore. I'm having a serious issue not getting a the second compute node working `nova-manage service list' doesn't show ':-)' for the compute and network services running on that node. I've followed the instructions to the letter and tried getting things working but its not going. nova.conf for the controller. [DEFAULT] logdir = /var/log/nova state_path = /var/lib/nova lock_path = /var/lib/nova/tmp dhcpbridge = /usr/bin/nova-dhcpbridge dhcpbridge_flagfile = /etc/nova/nova.conf force_dhcp_release = False injected_network_template = /usr/share/nova/interfaces.template libvirt_xml_template = /usr/share/nova/libvirt.xml.template libvirt_nonblocking = True vpn_client_template = /usr/share/nova/client.ovpn.template credentials_template = /usr/share/nova/novarc.template network_manager = nova.network.manager.FlatDHCPManager iscsi_helper = tgtadm sql_connection = mysql://nova:nova@localhost/nova connection_type = libvirt firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver rpc_backend = nova.rpc.impl_qpid root_helper = sudo nova-rootwrap auth_strategy = keystone public_interface = eth0 quota_floating_ips = 100 nova.conf on compute node [DEFAULT] logdir = /var/log/nova state_path = /var/lib/nova lock_path = /var/lib/nova/tmp dhcpbridge = /usr/bin/nova-dhcpbridge dhcpbridge_flagfile = /etc/nova/nova.conf force_dhcp_release = True injected_network_template = /usr/share/nova/interfaces.template libvirt_xml_template = /usr/share/nova/libvirt.xml.template libvirt_nonblocking = True vpn_client_template = /usr/share/nova/client.ovpn.template credentials_template = /usr/share/nova/novarc.template network_manager = nova.network.manager.FlatDHCPManager iscsi_helper = tgtadm sql_connection = mysql://nova:nova@CC_NAME/nova connection_type = libvirt firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver rpc_backend = nova.rpc.impl_qpid root_helper = sudo nova-rootwrap rabbit_host = CC_NAME glance_api_servers = CC_NAME:9292 iscsi_ip_prefix = CC_ADDR public_interface = eth2 verbose = True s3_host = CC_NAME ec2_api = CC_NAME ec2_url = http://CC_NAME:8773/services/Cloud fixed_range = 10.0.0.0/24 network_size = 256 Any help would be helpful. Thanks, - David Brown

9 14

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cloud May 2012