Re: [Openstack] XCP + OpenStack
Hi, Below is my view, Mike and Jon are welcome to correct me if needed. On 03/14/2012 06:27 AM, Todd Deshane wrote: Looks like the Debian repos on Xen.org are out of date. I'm not sure if the intention was to drop them once the packages got into SID or if they would be staging/unstable packages that existed before they got picked up by SID...(adding Mike and Jon to the CC to clarify). I think that was the plan yes, and that Mike didn't update the xen.org repositories. The wiki does include adding a line for the Debian experimental repo, That became completely wrong, and can potentially be harmful. so the packages in it would be used instead of the Xen.org repo since they are newer. There's nothing in Debian experimental that a user would need, and nothing XCP related either. Everything is in Debian SID / testing. I don't know for Ubuntu though, but I suspect it should be the same. Maybe you know better, and can tell me what the status is in Ubuntu? There is an xcp-xapi package (and its dependencies) in 12.04 universe. The problem is that the Ubuntu package is outdated. It's version 1.3-15, when SID has 1.3.2-3. If someone has contacts with Ubuntu people, it'd be worth asking them to pull the package from SID. Sending a bug report on Launchpad for that would be worth. Note that I personally don't care at all about the state in Ubuntu, so I wont do this work. The Ubuntu PPA is up-to-date and is the right place for Ubuntu users that want the latest packages going forward. I'd be very careful if having XCP in Ubuntu proper, but having an outdated (buggy) package. Potentially, this may harm XCP users who will not know that they should use the PPA. I believe the packages in the PPA are always a couple weeks ahead of the packages that are in Ubuntu universe. The PPA has version 1.3.2-1, which is about 2 months old it's missing few fixes (taken from debian/changelog, only the Ubuntu relevant parts): * Added /etc/xen as an empty directory for xcp-networkd (Closes: #663352). * xcp-networkd depends on openvswitch-datapath-dkms * Fix bug in vif hotplug script which prevented vm shutdowns I'd worry only about that last issue, which is really a blocker. The patch is here: http://anonscm.debian.org/gitweb/?p=pkg-xen/xen-api.git;a=blob;f=debian/patches/fix-vif-script;h=690e6ae5072c258b36699ef89815882a218c196a;hb=e9990da415a88f5f08b236a70e25630351552b2f Once Ubuntu 12.04 and Debian Wheezy go stable we'll want to update the wiki to be explicit about what is in the distros and what is not, I believe you can already do that, at least for SID/wheezy. Note that Debian 7.0 Wheezy is planned to be frozen next June. but I think we'll always have development packages that will be available for testers/early adopters in Debian SID and the PPA. Early testers, IMO, should use Git: git clone https://github.com/xen-org/xen-api.git Then, you should make sure to have both master and debian branches, get in the debian branch, and do: git-buildpackage I'm assuming that stable packages will be maintained in Wheezy and that development packages will be maintained in Debian SID right? Right, that's how it is always done in Debian. I hope that Citrix will decide that a long term support (2/3 years) will start after Ubuntu 12.04 is released, and that fixes will always be pushed there. Also, we can sometimes do some Wheezy backports if we need newer features. backports.debian.org is now officially part of Debian! I'd be happy to provide / maintain Wheezy backports later. Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP + OpenStack
I have updated the wiki at: http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution :) Thomas On 03/13/2012 10:55 PM, Todd Deshane wrote: On Mon, Mar 12, 2012 at 2:10 PM, Eduardo Nunes eduardo.ke...@gmail.com wrote: I read all the docs about it but i dont get it, what release shold i use, i run the xcp under the linux or i run linux under the xcp? You actually have two options for XCP. You can install XCP as a distro itself (CD/PXE install) by downloading the ISO from http://xen.org/download/xcp/index.html. The second option is that you can get an XCP-like system that includes the XCP XAPI toolstack by installing the xcp-xapi package on Ubuntu or Debian by following these instructions http://wiki.xen.org/wiki/Project_Kronos Soon you will be able to do the same on Fedora/CentOS as well, but work is still in progress. (http://wiki.xen.org/wiki/Project_Zeus_Fedora_Spec) I cover these and other details about XCP and Xen in this talk: http://www.cloudstack.org/build-a-cloud-day-videos/202-introduction-to-the-xen-cloud-platform.html Do contact me if you want to discuss any of these things in more detail. Thanks, Todd ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] When how are glance-cache* (.conf, -paste.ini) files loaded / parsed ?
Hello all, Can someone help me understand what options need to be in glance-api.conf and what options can be left to glance-cache.conf , resp glance-cache-paste.ini ? Case in point: If I wanted to use the xattr driver, I need to specify that in glance-api.conf -- specifying that in glance-cache.conf is ignored. The trivial solution is to copy the options from glance-cache.conf and paste them in glance-api.conf but I hardly think this was the intention of having the two split. So I'd like to understand when how those two files are loaded / parsed. The questions above is for the image cache, but I guess the same type of questions can be asked for the scrubber (i.e. glance-scrubber.conf resp glance-scrubber-paste.ini) Least I forget: This is for the E4 code release. TIA for the help, Florian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
Shep, Those steps are great. I'll be running through them, the devstack and any other info I've collated and update the bug I originally raised that caused me the pain that tipped me over the edge ( https://bugs.launchpad.net/glance/+bug/953989) Adam, the other bugs raised in the last day regarding my issues where raised by jaypipes when helping me troubleshoot my install : https://bugs.launchpad.net/keystone/+bug/954089 and https://bugs.launchpad.net/keystone/+bug/954087 Regards, Kev On 14 March 2012 01:59, Justin Shepherd jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.comare *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Kevin Jackson @itarchitectkev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Notifiers
Hi, we are thinking to contribute to increase the types of notifications (events) through the rabbit server. We are thinking to notify from each Openstack component (nova, glance, quantum in the future ...) We think that unify the code on the openstack-common stuff is a great idea. We are really interested to collaborate on this topic. Cheers, Juan On 12/03/12 14:33, Swaminathan Venkataraman wrote: Hi, I've been playing around with openstack for a month now and was looking to see how I can contribute. I saw that nova and glance use different methods to send out notifications. It looked relatively straight forward to make them use one common library for notifications. That way, when we make changes or add new transports we do not have to do it twice (or more number of times depending on how other components of openstack do notifications). Let me know if someone is already working on this. If not, let me know if this makes sense and I can start by creating a blueprint. Also, is there any preference to use object oriented (or not)? Cheers, Venkat ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Juan Antonio García Lebrijo *CTO* *www.stackops.com* http://www.stackops.com/ *| * juan.lebr...@stackops.com mailto:juan.lebr...@stackops.com| skype:juan.lebrijo.stackops ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] When how are glance-cache* (.conf, -paste.ini) files loaded / parsed ?
Florian, The key point in the split between glance-api.conf, glance-registry.conf, glance-cache.conf etc. is the glance application intended to consume that config. This follows directly from the naming: bin/glance-api by default consumes glance-api.conf bin/glance-registry by default consumes glance-registry.conf bin/glance-cache-* by default consumes glance-cache.conf bin/glance-scrubber by default consumes glance-scrubber.conf This is merely a convention, which can be overridden for example by naming the glance API service config as foobar.conf: bin/glance-api --config-file /path/to/foobar.conf However the naming convention is convenient as it may allow the pathname of the config file to be inferred if not explicitly specified, for example for the glance-api application, the follow search order is used: ~/.glance/glance-api.conf ~/glance-api.conf /etc/glance/glance-api.conf /etc/glance-api.conf or, in general, replace glance-api above with the program name, i.e. basename(sys.argv[0]) The intended consumer then determines what options should be specified in each config file, for example there would be no point in defining the the backend s3/swift store config in glance-cache.conf, similarly no need to define the max cache size in glance-api.conf, nor the scrubber wakeup time in glance-registry.conf. Then each .conf file has a corresponding -paste.ini, which splits along a different axis. Here the idea is to separate the core and paste deploy config for a particular glance application. So for example the default paste config for glance-api is glance-api-paste.ini, to be found in the same directory as glance-api.conf. Again this is merely a convenient convention that may be overridden. Does that all make sense? Cheers, Eoghan Can someone help me understand what options need to be in glance-api.conf and what options can be left to glance-cache.conf , resp glance-cache-paste.ini ? Case in point: If I wanted to use the xattr driver, I need to specify that in glance-api.conf -- specifying that in glance-cache.conf is ignored. The trivial solution is to copy the options from glance-cache.conf and paste them in glance-api.conf but I hardly think this was the intention of having the two split. So I'd like to understand when how those two files are loaded / parsed. The questions above is for the image cache, but I guess the same type of questions can be asked for the scrubber (i.e. glance-scrubber.conf resp glance-scrubber-paste.ini) Least I forget: This is for the E4 code release. TIA for the help, Florian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] When how are glance-cache* (.conf, -paste.ini) files loaded / parsed ?
Eoghan, Yes, it does make perfect sense. Kind thanks for the explanation. However, what is still unclear is what config iteems that pertain to other apps must still be present (ie. duplicated in) glance-api.conf (e.g. image_cache_driver , etc ) Thanks again, Florian On Mar 14, 2012 10:45 AM, Eoghan Glynn egl...@redhat.com wrote: Florian, The key point in the split between glance-api.conf, glance-registry.conf, glance-cache.conf etc. is the glance application intended to consume that config. This follows directly from the naming: bin/glance-api by default consumes glance-api.conf bin/glance-registry by default consumes glance-registry.conf bin/glance-cache-* by default consumes glance-cache.conf bin/glance-scrubber by default consumes glance-scrubber.conf This is merely a convention, which can be overridden for example by naming the glance API service config as foobar.conf: bin/glance-api --config-file /path/to/foobar.conf However the naming convention is convenient as it may allow the pathname of the config file to be inferred if not explicitly specified, for example for the glance-api application, the follow search order is used: ~/.glance/glance-api.conf ~/glance-api.conf /etc/glance/glance-api.conf /etc/glance-api.conf or, in general, replace glance-api above with the program name, i.e. basename(sys.argv[0]) The intended consumer then determines what options should be specified in each config file, for example there would be no point in defining the the backend s3/swift store config in glance-cache.conf, similarly no need to define the max cache size in glance-api.conf, nor the scrubber wakeup time in glance-registry.conf. Then each .conf file has a corresponding -paste.ini, which splits along a different axis. Here the idea is to separate the core and paste deploy config for a particular glance application. So for example the default paste config for glance-api is glance-api-paste.ini, to be found in the same directory as glance-api.conf. Again this is merely a convenient convention that may be overridden. Does that all make sense? Cheers, Eoghan Can someone help me understand what options need to be in glance-api.conf and what options can be left to glance-cache.conf , resp glance-cache-paste.ini ? Case in point: If I wanted to use the xattr driver, I need to specify that in glance-api.conf -- specifying that in glance-cache.conf is ignored. The trivial solution is to copy the options from glance-cache.conf and paste them in glance-api.conf but I hardly think this was the intention of having the two split. So I'd like to understand when how those two files are loaded / parsed. The questions above is for the image cache, but I guess the same type of questions can be asked for the scrubber (i.e. glance-scrubber.conf resp glance-scrubber-paste.ini) Least I forget: This is for the E4 code release. TIA for the help, Florian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] When how are glance-cache* (.conf, -paste.ini) files loaded / parsed ?
Yes, it does make perfect sense. Kind thanks for the explanation.
However, what is still unclear is what config iteems that pertain to
other apps must still be present (ie. duplicated in) glance-api.conf
(e.g. image_cache_driver , etc )
This is probably something we should document more carefully so it's clear
to users from the outset which config options are required and when.
However I don't have a definitive mapping of config items to apps, so I'd
normally consider them on a case-by-case basis and just check where the config
option is used. For example it may be always required by a particular app, or
only be required if a particular middleware is enabled.
In this particular case, a little grep'ing in the codebase soon reveals when
the image_cache_driver config item is required.
$ find glance -name *.py | grep -v test | xargs grep -n -B 5
image_cache_driver
glance/image_cache/__init__.py-33-class ImageCache(object):
glance/image_cache/__init__.py-34-
glance/image_cache/__init__.py-35-Provides an LRU cache for image
data.
glance/image_cache/__init__.py-36-
glance/image_cache/__init__.py-37-opts = [
glance/image_cache/__init__.py:38:cfg.StrOpt('image_cache_driver',
default='sqlite'),
--
glance/image_cache/__init__.py-48-
glance/image_cache/__init__.py-49-def init_driver(self):
glance/image_cache/__init__.py-50-
glance/image_cache/__init__.py-51-Create the driver for the cache
glance/image_cache/__init__.py-52-
glance/image_cache/__init__.py:53:driver_name =
self.conf.image_cache_driver
So we see that this config option is pulled in by the
glance.image_cache.ImageCache
class, which is then used as follows:
$ find glance -name *.py | grep -v test | xargs grep ImageCache | cut -f1
-d: | sort | uniq
glance/api/cached_images.py
glance/api/middleware/cache.py
glance/image_cache/cleaner.py
glance/image_cache/__init__.py
glance/image_cache/prefetcher.py
glance/image_cache/pruner.py
glance/image_cache/queue_image.py
Looking the first two source files, we see that the image_cache_driver config
option
would be required in the glance-api application iff a caching or
cachemanagement-based
pipeline is selected.
Cheers,
Eoghan
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Notifiers
To make the notifiers common, the QAL / RPC will also have to be made common. The Glance code for notifications currently implements queue/rpc-implementation specific notifiers, so this might not be a bad thing… If there is an effort to move the RPC into openstack.common, then I would like to be involved, if only as a reviewer to ensure the queue abstraction layer makes it over safely. [I still question if we need an rpc.notify()…] -- Eric Windisch On Wednesday, March 14, 2012 at 5:19 AM, Juan Antonio García Lebrijo wrote: Hi, we are thinking to contribute to increase the types of notifications (events) through the rabbit server. We are thinking to notify from each Openstack component (nova, glance, quantum in the future ...) We think that unify the code on the openstack-common stuff is a great idea. We are really interested to collaborate on this topic. Cheers, Juan On 12/03/12 14:33, Swaminathan Venkataraman wrote: Hi, I've been playing around with openstack for a month now and was looking to see how I can contribute. I saw that nova and glance use different methods to send out notifications. It looked relatively straight forward to make them use one common library for notifications. That way, when we make changes or add new transports we do not have to do it twice (or more number of times depending on how other components of openstack do notifications). Let me know if someone is already working on this. If not, let me know if this makes sense and I can start by creating a blueprint. Also, is there any preference to use object oriented (or not)? Cheers, Venkat ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Juan Antonio García Lebrijo CTO www.stackops.com (http://www.stackops.com/) | juan.lebr...@stackops.com (mailto:juan.lebr...@stackops.com) | skype:juan.lebrijo.stackops ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] git review complains about Contributor Agreement not signed
Hi, I have signed the agreement but I'm not sure how to make my git review command realize that. Right now I got: $ git review fatal: A Contributor Agreement must be completed before uploading: http://wiki.openstack.org/HowToContribute fatal: The remote end hung up unexpectedly Thanks, Yun ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] How could I delete errored volumes?
Hi, folks! nova client couldn't delete images in error state, but it could delete errored instances. I think we need this feature. # nova volume-delete 3 ERROR: Invalid volume: Volume status must be available (HTTP 400) -- Regards, Roman Sokolkov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] git review complains about Contributor Agreement not signed
On 03/14/2012 09:59 AM, Yun Mao wrote: Hi, I have signed the agreement but I'm not sure how to make my git review command realize that. Right now I got: $ git review fatal: A Contributor Agreement must be completed before uploading: http://wiki.openstack.org/HowToContribute fatal: The remote end hung up unexpectedly Referring to the above wiki page, have you added yourself to the contributors wiki page? Have you requested and been approved for membership in the openstack-cla group on Launchpad? -- Russell Bryant ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Compute with Xen
i'e installed the xcp with this notes, http://wiki.xen.org/wiki/XAPI_on_Ubuntu and instaled the compute, but it's now working with the xen, i've change the flag of the hypervisor on the nova.conf. what do i do now? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Compute with Xen
On Wed, Mar 14, 2012 at 10:29 AM, Eduardo Nunes eduardo.ke...@gmail.com wrote: i'e installed the xcp with this notes, http://wiki.xen.org/wiki/XAPI_on_Ubuntu and instaled the compute, but it's now working with the xen, i've change the flag of the hypervisor on the nova.conf. what do i do now? Nova should run in a domU. Checkout the xcp-toolstack branch of this tree https://github.com/mcclurmc/devstack/tree/xcp-toolstack Run the scripts in: https://github.com/mcclurmc/devstack/tree/xcp-toolstack/tools/xcp-toolstack Salvatore: do you have any updates on this code for devstack? Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://blog.xen.org/ http://wiki.xen.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How could I delete errored volumes?
On Mar 14, 2012, at 9:13 AM, Roman Sokolkov wrote: nova client couldn't delete images in error state, but it could delete errored instances. I think we need this feature. # nova volume-delete 3 ERROR: Invalid volume: Volume status must be available (HTTP 400) +1 to the feature request. In the mean time try using nova-manage to delete these volumes. nova-manage volume delete 3 Jason ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
Those were great bugs too - sorry you hit them, but thanks to you and Jay for reporting them in! We're working on them now! -joe On Mar 14, 2012, at 1:45 AM, Kevin Jackson wrote: Shep, Those steps are great. I'll be running through them, the devstack and any other info I've collated and update the bug I originally raised that caused me the pain that tipped me over the edge (https://bugs.launchpad.net/glance/+bug/953989) Adam, the other bugs raised in the last day regarding my issues where raised by jaypipes when helping me troubleshoot my install : https://bugs.launchpad.net/keystone/+bug/954089 and https://bugs.launchpad.net/keystone/+bug/954087 Regards, Kev On 14 March 2012 01:59, Justin Shepherd jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.com are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Kevin Jackson @itarchitectkev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How could I delete errored volumes?
Surprisingly nova-manage works very cool! 2012/3/14 Jason Hedden jhed...@mcs.anl.gov On Mar 14, 2012, at 9:13 AM, Roman Sokolkov wrote: nova client couldn't delete images in error state, but it could delete errored instances. I think we need this feature. # nova volume-delete 3 ERROR: Invalid volume: Volume status must be available (HTTP 400) +1 to the feature request. In the mean time try using nova-manage to delete these volumes. nova-manage volume delete 3 Jason -- Regards, Roman Sokolkov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Compute with Xen
Hi Todd, I did some work on the devstack port for xapi on Debian. Unfortunately I have not yet pushed it back, as it is not completed. I was trying to use devstack to run Openstack with Quantum on XCP. I will get back at you as soon as it is done. Eduardo, the devstack port linked by Todd should be fine anyway. It is a fork which was performed about 5 weeks ago. In the meanwhile there have been changes in devstack, but mainly around refactoring. You should be able to create an XVA appliance with all the Openstack services using the scripts in the xcp-toolstack folder anyway. I will then update this folder rebasing the scripts according to the changes in the 'xen' folder. Cheers, Salvatore -Original Message- From: todd.deshane@gmail.com [mailto:todd.deshane@gmail.com] On Behalf Of Todd Deshane Sent: 14 March 2012 15:30 To: Eduardo Nunes Cc: openstack@lists.launchpad.net; Salvatore Orlando Subject: Re: [Openstack] Compute with Xen On Wed, Mar 14, 2012 at 10:29 AM, Eduardo Nunes eduardo.ke...@gmail.com wrote: i'e installed the xcp with this notes, http://wiki.xen.org/wiki/XAPI_on_Ubuntu and instaled the compute, but it's now working with the xen, i've change the flag of the hypervisor on the nova.conf. what do i do now? Nova should run in a domU. Checkout the xcp-toolstack branch of this tree https://github.com/mcclurmc/devstack/tree/xcp-toolstack Run the scripts in: https://github.com/mcclurmc/devstack/tree/xcp-toolstack/tools/xcp- toolstack Salvatore: do you have any updates on this code for devstack? Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://blog.xen.org/ http://wiki.xen.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How could I delete errored volumes?
This is an annoying operational concern, so I have targeted it and proposed a fix. https://review.openstack.org/5342 Please verify that it works for you. Vish On Mar 14, 2012, at 9:03 AM, Jason Hedden wrote: On Mar 14, 2012, at 9:13 AM, Roman Sokolkov wrote: nova client couldn't delete images in error state, but it could delete errored instances. I think we need this feature. # nova volume-delete 3 ERROR: Invalid volume: Volume status must be available (HTTP 400) +1 to the feature request. In the mean time try using nova-manage to delete these volumes. nova-manage volume delete 3 Jason ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
In case any one runs into this, there is a bug in the Precise upstart package that causes a reboot after installing essex to result in a kernel panic. I don't know exactly what in the openstack install process triggers it but there is a PPA mentioned in comment #11 of this bug ticket that fixes the problem after upgrading the upstart package: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/935585 -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] When how are glance-cache* (.conf, -paste.ini) files loaded / parsed ?
The image caching configuration is somewhat unique within Glance, as it is
needed by multiple wsgi apps. As you point out, that means you need to
duplicate your cache configuration in glance-api.conf and glance-cache.conf to
get everything to play well together. I'm going to update the docs to make that
point clear, and I'll also file a bug on the issue of unnecessary duplication.
Brian
On Mar 14, 2012, at 5:06 AM, Eoghan Glynn wrote:
Yes, it does make perfect sense. Kind thanks for the explanation.
However, what is still unclear is what config iteems that pertain to
other apps must still be present (ie. duplicated in) glance-api.conf
(e.g. image_cache_driver , etc )
This is probably something we should document more carefully so it's clear
to users from the outset which config options are required and when.
However I don't have a definitive mapping of config items to apps, so I'd
normally consider them on a case-by-case basis and just check where the config
option is used. For example it may be always required by a particular app, or
only be required if a particular middleware is enabled.
In this particular case, a little grep'ing in the codebase soon reveals when
the image_cache_driver config item is required.
$ find glance -name *.py | grep -v test | xargs grep -n -B 5
image_cache_driver
glance/image_cache/__init__.py-33-class ImageCache(object):
glance/image_cache/__init__.py-34-
glance/image_cache/__init__.py-35-Provides an LRU cache for image
data.
glance/image_cache/__init__.py-36-
glance/image_cache/__init__.py-37-opts = [
glance/image_cache/__init__.py:38:cfg.StrOpt('image_cache_driver',
default='sqlite'),
--
glance/image_cache/__init__.py-48-
glance/image_cache/__init__.py-49-def init_driver(self):
glance/image_cache/__init__.py-50-
glance/image_cache/__init__.py-51-Create the driver for the cache
glance/image_cache/__init__.py-52-
glance/image_cache/__init__.py:53:driver_name =
self.conf.image_cache_driver
So we see that this config option is pulled in by the
glance.image_cache.ImageCache
class, which is then used as follows:
$ find glance -name *.py | grep -v test | xargs grep ImageCache | cut -f1
-d: | sort | uniq
glance/api/cached_images.py
glance/api/middleware/cache.py
glance/image_cache/cleaner.py
glance/image_cache/__init__.py
glance/image_cache/prefetcher.py
glance/image_cache/pruner.py
glance/image_cache/queue_image.py
Looking the first two source files, we see that the image_cache_driver config
option
would be required in the glance-api application iff a caching or
cachemanagement-based
pipeline is selected.
Cheers,
Eoghan
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
Hi Shep and others - A couple of questions to enhance my understanding while I walk through this for the install doc. Service Tenant - do you create just one service tenant to enclose all the service users? Glance Service User - do you create a Nova Service User and a Swift Service User also? files/default_catalog.templates - are your commands updating the template or a database? It this is a point of confusion. I guess I have to also add: [catalog] driver = keystone.catalog.backends.sql.Catalog to keystone.conf in order to use a database backend for my service catalog? Thanks for improving my mind map. Anne On Tue, Mar 13, 2012 at 8:59 PM, Justin Shepherd jshep...@rackspace.comwrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.comare *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
On Mar 14, 2012, at 11:57 AM, Anne Gentle wrote: Hi Shep and others - A couple of questions to enhance my understanding while I walk through this for the install doc. Service Tenant - do you create just one service tenant to enclose all the service users? Glance Service User - do you create a Nova Service User and a Swift Service User also? files/default_catalog.templates - are your commands updating the template or a database? It this is a point of confusion. I guess I have to also add: [catalog] driver = keystone.catalog.backends.sql.Catalog to keystone.conf in order to use a database backend for my service catalog? Thanks for improving my mind map. Anne Anne, I based the service tenant off what is done in devstack.. and it creates one service tenant that encloses all the service users. Yes, i also create a nova and swift user that is part of the service tenant (also based on what is being done in devstack). In the example i set the name and password the same, but i generate separate passwords for each in actual deployments. As for the default_catalog.templates, I am not making use of that file in any way. I am creating endpoints from the command line/api which populates the service catalog.. To be honest I also find this file confusing, and do not understand why or how you use it. --shep On Tue, Mar 13, 2012 at 8:59 PM, Justin Shepherd jshep...@rackspace.commailto:jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.orghttp://openstack.org/. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.comhttp://archive.ubuntu.com/ are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
Yeah, one service tenant, and then service accounts for each of nova, glance, quantum, swift. I've got a review that's updating this detail in the keystone docs right now (https://review.openstack.org/#change,5348) The catalog can be either the template (in which case, you don't use commands, you just edit the template) or the SQL based catalog (where you do use the commands) -joe On Mar 14, 2012, at 9:57 AM, Anne Gentle wrote: Hi Shep and others - A couple of questions to enhance my understanding while I walk through this for the install doc. Service Tenant - do you create just one service tenant to enclose all the service users? Glance Service User - do you create a Nova Service User and a Swift Service User also? files/default_catalog.templates - are your commands updating the template or a database? It this is a point of confusion. I guess I have to also add: [catalog] driver = keystone.catalog.backends.sql.Catalog to keystone.conf in order to use a database backend for my service catalog? Thanks for improving my mind map. Anne On Tue, Mar 13, 2012 at 8:59 PM, Justin Shepherd jshep...@rackspace.com wrote: Sent this to kevin earlier, thought i would throw it out to the list.. here are the steps i take to get a working keystone and glance on Ubuntu-12.04 using the ubuntu packages. http://paste.openstack.org/show/9101/ These steps produce a working keystone and glance.. not 100% sure they are the most efficient steps, would be curious to hear from others if there is a better way. --shep On Mar 13, 2012, at 5:41 PM, Adam Gandelman wrote: On 03/13/2012 01:53 PM, Kevin Jackson wrote: Whilst OpenStack is being developed, a lot of people's entry into OpenStack is through deb packages (or insert your fave package management in here) - therefore Ubuntu becomes unofficial (but vocal) PR to OpenStack. If the Ubuntu debs don't install, it becomes Plan B to install from somewhere else - even if that somewhere else is openstack.org. When we view the pages of http://www.ubuntu.com/cloud there is little doubt that OpenStack is a 1st class citizen (Best-of-breed cloud infrastructure is built into every copy of Ubuntu). Kevin- As someone who helps maintain the Ubuntu packages, I'm curious to know when/what/where the problems you've hit installing packages. Do/did bug #s exist? Can you please file bugs when you hit them? We've been making an extra effort to ensure that the Openstack packages on archive.ubuntu.com are *at least* installable without error at any given time. Packaging bugs have slipped through into our weekly uploads, but we've been either catching them early or responding to any new relevant bug reports, and doing point uploads with fixes ASAP so things are installable until the next weekly upload. I ask anyone that is running into packaging problems: Please file bugs against the Ubuntu packages if you find they are failing to install. They *will* get fixed! Adam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same
We recently changed the MAC address assigned to guests so that they started with 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses changing on the bridge device as machines are shut down (because supposedly the bridge grabs the lowest MAC address numerically): https://bugs.launchpad.net/nova/+bug/921838 However, it looks we bumped into some similar behavior done by libvirt: It also sets the first byte to 0xfe for the host network device, in the hope of avoiding the same bug. Thus, with the patch, the host vnetX and the guest eth0 have the same MAC address. I think this breaks FlatManager, but I don't know why, and I really don't know why it wouldn't break other modes, and I'm hoping a network guru can explain/confirm. When they have the same MAC address, ARP resolution isn't working: the guest issues an ARP request for the gateway, on the host I can see the ARP request and response, but the guest doesn't appear to see/accept the ARP response and so it just keeps retrying. This message appears in dmesg: [ 2199.836114] br100: received packet on vnet1 with own address as source address I'm guessing that 'address' means 'MAC address', and this is why ARP is failing, it sounds like the bridge might be dropping the packet. Changing to 0x02, or 0xfc does fix it (although my arithmetic was wrong, and vishy points out we should use 0xfa instead of 0xfc). Networking guru questions: - Does this explanation make sense? - Why didn't other networking modes break? - Should we simply revert the change and go back to 0x02? - Should we switch to 0xfa to try to avoid the bridge interface problems? Or does it simply not matter if libvirt is changing the MAC for us? - Can anyone explain https://bugs.launchpad.net/nova/+bug/908194 ? Is that bug because there was no 'real' device on the bug reporter's bridge? Vishy has proposed this patch, which looks good to me: https://review.openstack.org/#patch,sidebyside,5351,1,nova/utils.py Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same
On Wed, Mar 14, 2012 at 10:50:28AM -0700, Justin Santa Barbara wrote: We recently changed the MAC address assigned to guests so that they started with 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses changing on the bridge device as machines are shut down (because supposedly the bridge grabs the lowest MAC address numerically): https://bugs.launchpad.net/nova/+bug/921838 However, it looks we bumped into some similar behavior done by libvirt: It also sets the first byte to 0xfe for the host network device, in the hope of avoiding the same bug. Thus, with the patch, the host vnetX and the guest eth0 have the same MAC address. I think this breaks FlatManager, but I don't know why, and I really don't know why it wouldn't break other modes, and I'm hoping a network guru can explain/confirm. I don't really know why either - all I know is that the host side must be different from the guest side. When they have the same MAC address, ARP resolution isn't working: the guest issues an ARP request for the gateway, on the host I can see the ARP request and response, but the guest doesn't appear to see/accept the ARP response and so it just keeps retrying. This message appears in dmesg: [ 2199.836114] br100: received packet on vnet1 with own address as source address I'm guessing that 'address' means 'MAC address', and this is why ARP is failing, it sounds like the bridge might be dropping the packet. Changing to 0x02, or 0xfc does fix it (although my arithmetic was wrong, and vishy points out we should use 0xfa instead of 0xfc). Networking guru questions: - Does this explanation make sense? - Why didn't other networking modes break? - Should we simply revert the change and go back to 0x02? - Should we switch to 0xfa to try to avoid the bridge interface problems? Or does it simply not matter if libvirt is changing the MAC for us? Hmm, I guess I mis-read the original patch vish submitted. I thought it was only changing the MAC address of host TAP devices that Nova created itself, and not the guest MAC address sent in the MXL. The MAC address sent in the libvirt XML (which is the guest visible MAC) should not be using 0xfX at all - ideally it should just use the standard MAC prefix for the hypervisor in question. eg for Xen, use 00:16:3E and for LXC/KVM use 52:54:00 If libvirt is creating the TAP device itself, (eg interface with type=bridge|direct), then Nova should not do anything special with the MAC. If Nova is pre-creating a TAP device (eg for use with interface type=ethernet, then Nova should set the top byte to 0xfe (because libvirt won't be doing so with pre-created TAP devices). Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Swift acting as nova-objectstore
Hi Vish, I have done some more testing on those two reviews on a clean devstack install with this nova review : https://review.openstack.org/5338 this keystone review : https://review.openstack.org/5340 and a small modification to devstack to have S3_URL pointing to Swift if we have it installed : http://pastie.org/private/mwqxhkbcs8yvxnqjbluja [should be merged in https://review.openstack.org/#change,4696] When launching excercises/bundle.sh everything seem to work ok : http://pastie.org/private/dif4hc9jxj2owfs9dq7lvg Uploading and Registring seems to have been done currently, and I can see it from Swift : stack@devstack:~/devstack$ swift list testbucket [swtoken-swift3-tests] bundle.img.manifest.xml bundle.img.part.00 There is one place where it looks like it's erroring out : http://pastie.org/private/10pta1v5txfzwjjzfehukg which seems to be somewhere along glance connection, I am not entirely how everything get passed from nova- objectstore to glance and where does it fails, any ideas ? Thanks, Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same
On 03/14/2012 01:50 PM, Justin Santa Barbara wrote: We recently changed the MAC address assigned to guests so that they started with 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses changing on the bridge device as machines are shut down (because supposedly the bridge grabs the lowest MAC address numerically): https://bugs.launchpad.net/nova/+bug/921838 I believe the bridge changing it's MAC address is a known issue, fixed in later versions of libvirt, see https://bugzilla.redhat.com/show_bug.cgi?id=609463 Absent of that fix, the best solution I've found is: - Create a dummy tap device, and attach it to the bridge $ ip tuntap add dev tap_brfoo mode tap $ brctl addif brfoo tap_brfoo - Set it's MAC to $MAC_FOO (whatever you choose) $ ip link set tap_brfoo address $MAC_FOO - And the bridge's MAC too $ ip link set brfoo address $MAC_FOO This should anchor the bridge's MAC address to $MAC_FOO for the life of the bridge. You could set the bridge in promisc mode if you don't like the above, but then you'll start seeing packets duplicated, yuck. -Brian However, it looks we bumped into some similar behavior done by libvirt: It also sets the first byte to 0xfe for the host network device, in the hope of avoiding the same bug. Thus, with the patch, the host vnetX and the guest eth0 have the same MAC address. I think this breaks FlatManager, but I don't know why, and I really don't know why it wouldn't break other modes, and I'm hoping a network guru can explain/confirm. When they have the same MAC address, ARP resolution isn't working: the guest issues an ARP request for the gateway, on the host I can see the ARP request and response, but the guest doesn't appear to see/accept the ARP response and so it just keeps retrying. This message appears in dmesg: [ 2199.836114] br100: received packet on vnet1 with own address as source address I'm guessing that 'address' means 'MAC address', and this is why ARP is failing, it sounds like the bridge might be dropping the packet. Changing to 0x02, or 0xfc does fix it (although my arithmetic was wrong, and vishy points out we should use 0xfa instead of 0xfc). Networking guru questions: * Does this explanation make sense? * Why didn't other networking modes break? * Should we simply revert the change and go back to 0x02? * Should we switch to 0xfa to try to avoid the bridge interface problems? Or does it simply not matter if libvirt is changing the MAC for us? * Can anyone explain https://bugs.launchpad.net/nova/+bug/908194 ? Is that bug because there was no 'real' device on the bug reporter's bridge? Vishy has proposed this patch, which looks good to me: https://review.openstack.org/#patch,sidebyside,5351,1,nova/utils.py Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Swift acting as nova-objectstore
I investigated this and it looks like there is some kind of odd race condition causing the status to show up as available before the image is actually available. This caused euca-deregister to get executed too quickly and the upload of the image to glance failed. I'm not quite sure how that happened unless there is some typo in the timeout line waiting for register. I will try and reproduce this on a local install. Otherwise i think the code is good to go. Vish On Mar 14, 2012, at 11:14 AM, Chmouel Boudjnah wrote: Hi Vish, I have done some more testing on those two reviews on a clean devstack install with this nova review : https://review.openstack.org/5338 this keystone review : https://review.openstack.org/5340 and a small modification to devstack to have S3_URL pointing to Swift if we have it installed : http://pastie.org/private/mwqxhkbcs8yvxnqjbluja [should be merged in https://review.openstack.org/#change,4696] When launching excercises/bundle.sh everything seem to work ok : http://pastie.org/private/dif4hc9jxj2owfs9dq7lvg Uploading and Registring seems to have been done currently, and I can see it from Swift : stack@devstack:~/devstack$ swift list testbucket [swtoken-swift3-tests] bundle.img.manifest.xml bundle.img.part.00 There is one place where it looks like it's erroring out : http://pastie.org/private/10pta1v5txfzwjjzfehukg which seems to be somewhere along glance connection, I am not entirely how everything get passed from nova- objectstore to glance and where does it fails, any ideas ? Thanks, Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Random libvirt hangs
From what I understand, the SmokeStack integration tests are running on Ubuntu 11.10 (XenServer) and Fedora 16 (Libvirt), so as a practical matter those platforms will be more battle-tested even if they aren't officially blessed as supported platforms. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On Mar 13, 2012, at 3:15 PM, Justin Santa Barbara wrote: I certainly understand your position Thierry. However, I think it is important that we target one 'golden' platform, and that we take responsibility for any issues with that platform. Otherwise we simply end up pointing fingers and being blocked on backports, and the end result is a system that just doesn't work for the people actually deploying it. File a bug upstream is an appropriate response for me, but it's not really OK for end-users. We could then have a policy that 'if Essex fails on TargetPlatform it's an OpenStack issue, otherwise it's a distro issue'. We can either work around the bug or work with TargetPlatform to get a bugfix integrated. Other distros can look to the golden platform to understand what patches are needed and how things are supposed to work. It sounds like Precise is a good candidate for Essex: it is an LTS release, and we have time to ensure that any required bugfixes (that we don't want to work around) make it into the official release. If that's agreeable, then e.g. we probably retarget devstack and our documentation from Oneiric to Precise. We should probably gate on Precise as well. I will be much happier if we just say we aim to support X; I don't really care what X is. I'm just going to be running OpenStack on the machine, so I'm not picking my distro e.g. based on how I feel about Unity. I'd imagine most users are in a similar camp. Justin On Tue, Mar 13, 2012 at 5:00 AM, Thierry Carrez thie...@openstack.org wrote: Justin Santa Barbara wrote: Which operating system(s) are we aiming to support for Essex? Is the plan to backport the latest libvirt to Oneric, or are we going to wait for Precise? The question is the other way around: which operating systems aim to support Essex ? We try to set the dependencies for OpenStack to a reasonable set of versions (generally compatible with the release under development of the major Linux distributions), but it's up to the distributions themselves to make sure they align if they want to support a given version of OpenStack. Ubuntu will ship Essex in 12.04 LTS. I don't think there are any plans to backport it to 11.10. Fedora will support Essex in Fedora 17, etc. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Can openstack support spice ?
On 03/11/2012 02:31 AM, wangsuyi640 wrote: Dear all: The release of openstack on my server is D3. I tred to run 'qemu-kvm -hda /root/free.img -m 512 -vga qxl -spice port=5930,disable-ticketing ' without openstack , it worked well. However,I have tried to modify the '/opt/stack/nova/nova/virt/libvirt.xml.template' in order to let the spice work with the openstack. Then it failed. Is there anyone tried this? Could you give me some help? Thanks. Have a look at this Work In Progress: https://review.openstack.org/5319 cheers, Pádraig. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same
We are following a similar approach, as indicated by Brian here, in the Linux-bridge plugin for Quantum. There is a dummy tap device created with the requested MAC address, and is the first one to get added to the bridge. Subsequently, the bridge's MAC address stays anchored to this tap device's MAC. Thanks, ~Sumit. -Original Message- From: openstack-bounces+snaiksat=cisco@lists.launchpad.net [mailto:openstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of Brian Haley Sent: Wednesday, March 14, 2012 11:42 AM To: Justin Santa Barbara Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same On 03/14/2012 01:50 PM, Justin Santa Barbara wrote: We recently changed the MAC address assigned to guests so that they started with 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses changing on the bridge device as machines are shut down (because supposedly the bridge grabs the lowest MAC address numerically): https://bugs.launchpad.net/nova/+bug/921838 I believe the bridge changing it's MAC address is a known issue, fixed in later versions of libvirt, see https://bugzilla.redhat.com/show_bug.cgi?id=609463 Absent of that fix, the best solution I've found is: - Create a dummy tap device, and attach it to the bridge $ ip tuntap add dev tap_brfoo mode tap $ brctl addif brfoo tap_brfoo - Set it's MAC to $MAC_FOO (whatever you choose) $ ip link set tap_brfoo address $MAC_FOO - And the bridge's MAC too $ ip link set brfoo address $MAC_FOO This should anchor the bridge's MAC address to $MAC_FOO for the life of the bridge. You could set the bridge in promisc mode if you don't like the above, but then you'll start seeing packets duplicated, yuck. -Brian However, it looks we bumped into some similar behavior done by libvirt: It also sets the first byte to 0xfe for the host network device, in the hope of avoiding the same bug. Thus, with the patch, the host vnetX and the guest eth0 have the same MAC address. I think this breaks FlatManager, but I don't know why, and I really don't know why it wouldn't break other modes, and I'm hoping a network guru can explain/confirm. When they have the same MAC address, ARP resolution isn't working: the guest issues an ARP request for the gateway, on the host I can see the ARP request and response, but the guest doesn't appear to see/accept the ARP response and so it just keeps retrying. This message appears in dmesg: [ 2199.836114] br100: received packet on vnet1 with own address as source address I'm guessing that 'address' means 'MAC address', and this is why ARP is failing, it sounds like the bridge might be dropping the packet. Changing to 0x02, or 0xfc does fix it (although my arithmetic was wrong, and vishy points out we should use 0xfa instead of 0xfc). Networking guru questions: * Does this explanation make sense? * Why didn't other networking modes break? * Should we simply revert the change and go back to 0x02? * Should we switch to 0xfa to try to avoid the bridge interface problems? Or does it simply not matter if libvirt is changing the MAC for us? * Can anyone explain https://bugs.launchpad.net/nova/+bug/908194 ? Is that bug because there was no 'real' device on the bug reporter's bridge? Vishy has proposed this patch, which looks good to me: https://review.openstack.org/#patch,sidebyside,5351,1,nova/utils.py Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova client returning malformed request (HTTP 400)
Dear all, After getting past some initial keystone issues on Essex E4 (Ubuntu 12.04 B1) I'm now having issues with communicating with nova using keystone. I've a paste of my session here: http://paste.openstack.org/show/9413/ Essentially I've set up my keystone endpoints (which I'm pretty sure are correct - but I'm sure I've said that before...) and I've set up my user accordingly. Tenant: demo User: demo Password: openstack Role: Member Tenant: service User: nova Password: nova Role: admin When issuing nova list I get: openstack@ubuntu:~/openstack/demo$ nova list Malformed request url (HTTP 400) nova-api.log has: 2012-03-14 20:23:09 INFO nova.api.openstack.wsgi [req-77ce4d2a-2a0d-4164-9dfc-e001c78237d9 5bc2fbeb8c6a4f3e9ad88fdd6d186229 5bc2fbeb8c6a4f3e9ad88fdd6d186229] GET http://172.16.0.5:8774/v2/1ecd90d361ad44b894b9cd627f410445/servers/detail 2012-03-14 20:23:09 DEBUG nova.api.openstack.wsgi [req-77ce4d2a-2a0d-4164-9dfc-e001c78237d9 5bc2fbeb8c6a4f3e9ad88fdd6d186229 5bc2fbeb8c6a4f3e9ad88fdd6d186229] Unrecognized Content-Type provided in request from (pid=10754) get_body /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:697 Debug output is in the paste. Anybody come across this? I've seen this bug which possibly suggests a config issue: https://bugs.launchpad.net/nova/+bug/915151 and I've seen a potential pipeline issue maybe? Cheers, Kev -- Kevin Jackson @itarchitectkev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova client returning malformed request (HTTP 400)
Hi, be sure that auth_strategy=keystone it in your nova.conf file and keystone enable in /etc/nova/api-paste.ini (Not neccesarry this last step with new conf file format, post-essex4) Ghe Rivero On Wed, Mar 14, 2012 at 9:24 PM, Kevin Jackson ke...@linuxservices.co.ukwrote: Dear all, After getting past some initial keystone issues on Essex E4 (Ubuntu 12.04 B1) I'm now having issues with communicating with nova using keystone. I've a paste of my session here: http://paste.openstack.org/show/9413/ Essentially I've set up my keystone endpoints (which I'm pretty sure are correct - but I'm sure I've said that before...) and I've set up my user accordingly. Tenant: demo User: demo Password: openstack Role: Member Tenant: service User: nova Password: nova Role: admin When issuing nova list I get: openstack@ubuntu:~/openstack/demo$ nova list Malformed request url (HTTP 400) nova-api.log has: 2012-03-14 20:23:09 INFO nova.api.openstack.wsgi [req-77ce4d2a-2a0d-4164-9dfc-e001c78237d9 5bc2fbeb8c6a4f3e9ad88fdd6d186229 5bc2fbeb8c6a4f3e9ad88fdd6d186229] GET http://172.16.0.5:8774/v2/1ecd90d361ad44b894b9cd627f410445/servers/detail 2012-03-14 20:23:09 DEBUG nova.api.openstack.wsgi [req-77ce4d2a-2a0d-4164-9dfc-e001c78237d9 5bc2fbeb8c6a4f3e9ad88fdd6d186229 5bc2fbeb8c6a4f3e9ad88fdd6d186229] Unrecognized Content-Type provided in request from (pid=10754) get_body /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:697 Debug output is in the paste. Anybody come across this? I've seen this bug which possibly suggests a config issue: https://bugs.launchpad.net/nova/+bug/915151 and I've seen a potential pipeline issue maybe? Cheers, Kev -- Kevin Jackson @itarchitectkev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Ghe Rivero *OpenStack Distribution Engineer **www.stackops.com | * ghe.riv...@stackops.com diego.parri...@stackops.com ** | +34 625 63 45 23 | skype:ghe.rivero* * http://www.stackops.com/ * * ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Removal of VSA Code
Apologies if you receive this email twice, I sent the first one from the wrong address. Hello Everyone, Last week during the release meeting it was mentioned that the VSA code is not working properly and we should either fix it or remove it. I propose to remove it for the following reasons: * Lack of documentation -- unclear how to create a vsa image or how the image should function * Lack of support from vendors -- originally, the hope was other vendors would use the vsa code to create their own virtual storage arrays * Lack of functional testing -- this is the main reason the code has bitrotted * Lack of updates from original coders -- Zadara has mentioned a few times that they were going to update the code but it has not happened * Eases Transition to separate volume project -- This lowers the surface area of the volume code and makes it easier to cleanly separate the volume service to compute As far as I can tell Zadara is maintaining a fork of the code for their platform, so keeping the code in the public tree doesn't seem necessary. I would be happy to see this code come back in Folsom if we get a stronger commitment to keep it up-to-date, documented, and maintained, and there is a reasonable location for it if the volume and compute code is separate. If anyone disagrees, please respond ASAP. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Question about quantum
Hello, I see that quantum has come a long way since its diablo version. I was wondering if quantum-essex works with nova/openstack essex version only or is quantum-essex indepedent of nova/openstack versions/evolution. Thanks, -Vijay___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Question about quantum
On Wed, Mar 14, 2012 at 4:35 PM, Vijay vija...@yahoo.com wrote: Hello, I see that quantum has come a long way since its diablo version. I was wondering if quantum-essex works with nova/openstack essex version only or is quantum-essex indepedent of nova/openstack versions/evolution. Hi Vijay, I'd strongly suggest only using quantum-essex with nova-essex. Quantum added a lot of nova integration features in Essex, and unless you're quite familiar with the Quantum and QuantumManager (in Nova) code and know exactly when the features that you require were introduced, you can get in trouble. Also, I don't know of any effort to backport Quantum-related bug-fixes from essex to diablo versions, which is another reason to stick with the current essex releases. Dan Thanks, -Vijay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Removal of VSA Code
Related links: https://bugs.launchpad.net/nova/+bug/954490 https://review.openstack.org/#change,5377 On Mar 14, 2012, at 6:54 PM, Vishvananda Ishaya wrote: Apologies if you receive this email twice, I sent the first one from the wrong address. Hello Everyone, Last week during the release meeting it was mentioned that the VSA code is not working properly and we should either fix it or remove it. I propose to remove it for the following reasons: * Lack of documentation -- unclear how to create a vsa image or how the image should function * Lack of support from vendors -- originally, the hope was other vendors would use the vsa code to create their own virtual storage arrays * Lack of functional testing -- this is the main reason the code has bitrotted * Lack of updates from original coders -- Zadara has mentioned a few times that they were going to update the code but it has not happened * Eases Transition to separate volume project -- This lowers the surface area of the volume code and makes it easier to cleanly separate the volume service to compute As far as I can tell Zadara is maintaining a fork of the code for their platform, so keeping the code in the public tree doesn't seem necessary. I would be happy to see this code come back in Folsom if we get a stronger commitment to keep it up-to-date, documented, and maintained, and there is a reasonable location for it if the volume and compute code is separate. If anyone disagrees, please respond ASAP. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] User experience and simplified configurations
Have you tinkered with devstack Its simplifies some of the issues you raised for a dev guy. debo From: openstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Aniruddha Khadkikar Sent: Wednesday, March 14, 2012 9:03 PM To: openstack@lists.launchpad.net Subject: [Openstack] User experience and simplified configurations Hi, Its only recently that I have started exploring openstack and the first thing that comes to my mind is the nature and amount of configuration required for the various components. The managed IT Deb packages for Diablo were very helpful in reaching a poc level implementation involving a separate cloud controller, volume and glance with swift and with a compute node. Are there any plans to simplify the configuration files and develop command line wizards for a better user experience? I believe that with every release an incrementally better experience will help in greater adoption of the platform. For example I could only get things working on my third trial. That too led to problems due to EC2 not working till a project was added using nova manage. I still remain confused between tenants and projects in Diablo. Logically one customer (tenant) should be able to run multiple projects. So I was a bit surprised at them being treated as equivalent. First target for simplification could be the various pipeline settings and the nova configuration. I have found these a bit complicated to understand. I have not started testing Essex yet. Regards Aniruddha ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] User experience and simplified configurations
On Thu, Mar 15, 2012 at 9:46 AM, Debo Dutta (dedutta) dedu...@cisco.com wrote: Have you tinkered with devstack …. Its simplifies some of the issues you raised for a dev guy. No, I have not used Devstack as the purpose is to simulate a close to production type POC and not a deployment on a single machine. Also we wanted to go through the documentation in detail to increase our understanding of the platform and implement the steps manually. Regards, Aniruddha From: openstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Aniruddha Khadkikar Sent: Wednesday, March 14, 2012 9:03 PM To: openstack@lists.launchpad.net Subject: [Openstack] User experience and simplified configurations Hi, Its only recently that I have started exploring openstack and the first thing that comes to my mind is the nature and amount of configuration required for the various components. The managed IT Deb packages for Diablo were very helpful in reaching a poc level implementation involving a separate cloud controller, volume and glance with swift and with a compute node. Are there any plans to simplify the configuration files and develop command line wizards for a better user experience? I believe that with every release an incrementally better experience will help in greater adoption of the platform. For example I could only get things working on my third trial. That too led to problems due to EC2 not working till a project was added using nova manage. I still remain confused between tenants and projects in Diablo. Logically one customer (tenant) should be able to run multiple projects. So I was a bit surprised at them being treated as equivalent. First target for simplification could be the various pipeline settings and the nova configuration. I have found these a bit complicated to understand. I have not started testing Essex yet. Regards Aniruddha ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] User experience and simplified configurations
Then you might want to start with some of the chef cookbooks people use. Ask Jay Pipes, he was planning to consolidate them! debo -Original Message- From: Aniruddha Khadkikar [mailto:askhadki...@gmail.com] Sent: Wednesday, March 14, 2012 9:37 PM To: Debo Dutta (dedutta) Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] User experience and simplified configurations On Thu, Mar 15, 2012 at 9:46 AM, Debo Dutta (dedutta) dedu...@cisco.com wrote: Have you tinkered with devstack Its simplifies some of the issues you raised for a dev guy. No, I have not used Devstack as the purpose is to simulate a close to production type POC and not a deployment on a single machine. Also we wanted to go through the documentation in detail to increase our understanding of the platform and implement the steps manually. Regards, Aniruddha From: openstack-bounces+dedutta=cisco@lists.launchpad.net [mailto:openstack-bounces+dedutta=cisco@lists.launchpad.net] On Behalf Of Aniruddha Khadkikar Sent: Wednesday, March 14, 2012 9:03 PM To: openstack@lists.launchpad.net Subject: [Openstack] User experience and simplified configurations Hi, Its only recently that I have started exploring openstack and the first thing that comes to my mind is the nature and amount of configuration required for the various components. The managed IT Deb packages for Diablo were very helpful in reaching a poc level implementation involving a separate cloud controller, volume and glance with swift and with a compute node. Are there any plans to simplify the configuration files and develop command line wizards for a better user experience? I believe that with every release an incrementally better experience will help in greater adoption of the platform. For example I could only get things working on my third trial. That too led to problems due to EC2 not working till a project was added using nova manage. I still remain confused between tenants and projects in Diablo. Logically one customer (tenant) should be able to run multiple projects. So I was a bit surprised at them being treated as equivalent. First target for simplification could be the various pipeline settings and the nova configuration. I have found these a bit complicated to understand. I have not started testing Essex yet. Regards Aniruddha ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 955308] [NEW] MultiStrOpt doesn't always accept multiple strings
Public bug reported: It appears to work for CLI options but not when using config files. Looking at the tests, this appears to be a known bug since the assertion in test_conf_file_multistr_values_append has been commented out with a FIXME. ** Affects: openstack-common Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/955308 Title: MultiStrOpt doesn't always accept multiple strings Status in openstack-common: New Bug description: It appears to work for CLI options but not when using config files. Looking at the tests, this appears to be a known bug since the assertion in test_conf_file_multistr_values_append has been commented out with a FIXME. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-common/+bug/955308/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 951197] Re: openstack namespace does not play nicely with checkedout repos
Reviewed: https://review.openstack.org/5179 Committed: http://github.com/openstack/openstack-common/commit/e8a5ae2e5aab6b649b57d03f8a03af689d7e6b6e Submitter: Jenkins Branch:master commit e8a5ae2e5aab6b649b57d03f8a03af689d7e6b6e Author: Jason Kölker ja...@koelker.net Date: Fri Mar 9 17:29:41 2012 -0600 Import cfg module directly if not in path If openstack.common is not installed, but another module has declared the openstack namespace an ImportError is thrown since the common doesnt exist in the openstack namespace. This falls back to importing cfg directly from ./openstack/common/cfg.py. Also ensures that openstack/__init__.py exists in the destination * Fixes LP951197 Change-Id: I88c26fb7cc1aed97e66b068e4f0562b1f00b2b29 ** Changed in: openstack-common Status: In Progress = Fix Committed -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/951197 Title: openstack namespace does not play nicely with checkedout repos Status in openstack-common: Fix Committed Bug description: Both openstack.common and openstack.nose_plugin declare the 'openstack' namespace. When one package is installed it breaks pythons search path of ./ for modules. This breaks update.py for example which is meant to be run out of the os-common checkout directory. It imports cfg from openstack.common, but since it is not installed it cannot be found: site-packages$ ls openstack* openstack.nose_plugin-0.5-py2.7-nspkg.pth openstack: nose_plugin.py nose_plugin.pyc openstack.nose_plugin-0.5-py2.7.egg-info: dependency_links.txt installed-files.txt PKG-INFO SOURCES.txt entry_points.txt namespace_packages.txt requires.txt top_level.txt common$ python update.py Traceback (most recent call last): File update.py, line 64, in module from openstack.common import cfg ImportError: No module named common Since update.py is a temporary workaround for incubation we *could* hack it to inject ./openstack/common into the openstack namespace, but there might be a better way. Need to research. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-common/+bug/951197/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
[Openstack-poc] [Bug 954488] Re: nova/openstack/common/cfg.py: 'nova.api.openstack.contrib.standard_extensions' is non-existant
Reviewed: https://review.openstack.org/5306 Committed: http://github.com/openstack/openstack-common/commit/b2c59f50a8d449d619f52db318cff10211075c53 Submitter: Jenkins Branch:master commit b2c59f50a8d449d619f52db318cff10211075c53 Author: Joe Gordon j...@cloudscaling.com Date: Tue Mar 13 17:25:19 2012 -0700 Fix bug 954488 Change-Id: I99b764310c575e70aff4a6790e8ba8f55e43deeb ** Changed in: openstack-common Status: In Progress = Fix Committed -- You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. https://bugs.launchpad.net/bugs/954488 Title: nova/openstack/common/cfg.py: 'nova.api.openstack.contrib.standard_extensions' is non-existant Status in OpenStack Compute (Nova): Fix Committed Status in openstack-common: Fix Committed Bug description: nova/openstack/common/cfg.py refers to 'nova.api.openstack.contrib.standard_extensions' but this is a non- existant path. nova/openstack/common/cfg.py: DEFAULT_EXTENSIONS = [ 'nova.api.openstack.contrib.standard_extensions' ] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/954488/+subscriptions ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
