Re: [Openstack] Havana Packages for Ubuntu 12.04
On 06/17/2013 11:01 PM, Alexander Stellwag wrote: Hi stackers, I wonder if there are havana packages for Ubuntu LTS available. Those in the official cloud archive semm to be identical to the current grizzly packages. We would like to run first tests with havana and prepare for an update as close to the official release as possible. In order not to break our installation process we need to run with packages so directly using git is not an option here. Any ideas and/or links will be greatly appreciated. Cheers, Alex Hi Alex- You can find our Havana trunk testing PPA @ https://launchpad.net/~openstack-ubuntu-testing/+archive/havana. These contain automated per-commit builds of current Havana code. We're still in the middle of both the Havana and Ubuntu 13.10 cycles and so these packages are experimental and unsupported, may contain bugs and are for testing only, etc. etc. Once Havana + 13.10 are released, the Cloud Archive will contain supported Havana release packages for 12.04. Until then, Havana milestones will be uploaded to the Havana pocket of the Cloud Archive as they are released, but as preview/testing only. If you discover any packaging issues in your testing, a bug report against the relevant package in Ubuntu would be greatly appreciated (please include package version and mention of the PPA). Feel free to ping me (adam_g) or any of the other Ubuntu openstack devs (zul, jamespage, yolanda) on freenode #openstack-packaging if you run into issues. Cheers, 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
Re: [Openstack] Grizzly release packages available in the Ubuntu Cloud Archive
On 04/11/2013 10:05 AM, Derek Morton wrote: If you've removed the Ubuntu theme you'll need to change the following in /etc/openstack-dashboard/local_settings.py to get the default theme working: COMPRESS_OFFLINE = False to COMPRESS_OFFLINE = True -Derek This shouldn't be the case. A simple purge of the theme openstack-dashboard-ubuntu-theme package should be all thats required to enable the default dashboard styling. Just confirmed using the openstack-dashboard 1:2013.1-0ubuntu2~cloud0 package from the Ubuntu Cloud Archive. With offline compression functions enabled and the openstack-ubuntu-theme-package uninstalled, everything works as expected and clients end up loading the following compressed assets which are shipped /w the package: 967e5ade6890.js f8791faeb8f8.js d272fede7fb7.css If that is not the case for you please file a bug against the Horizon package in Ubuntu with apache error logs, stating which manifest keys are missing during offline compression. Thanks 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
Re: [Openstack] 2012.2.1 missing several nova dependency packages.
On 03/01/2013 11:42 AM, Wyllys Ingersoll wrote: Im trying to install the nova packages from the Ubuntu 12.04 LTS folsom archives, but some of the required dependencies are no longer available. My sources.list file has this entry: deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main If I remove that entry, I can get the 2012.1.3 release and it will work, but why is it not in the 2012.2.1 tree? Thanks, Wyllys $ sudo apt-get install python-nova Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: python-cinderclient python-cliff python-cmd2 python-novaclient python-paramiko python-pyparsing python-quantumclient The following NEW packages will be installed: python-cinderclient python-cliff python-cmd2 python-nova python-novaclient python-paramiko python-pyparsing python-quantumclient 0 upgraded, 8 newly installed, 0 to remove and 3 not upgraded. Need to get 3,121 kB/4,679 kB of archives. After this operation, 26.2 MB of additional disk space will be used. Do you want to continue [Y/n]? Err http://ubuntu-cloud.archive.canonical.com/ubuntu/ precise-updates/folsom/main python-nova all 2012.2.1+stable-20121212-a99a802e-0ubuntu1.1~cloud0 404 Not Found Failed to fetch http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/n/nova/python-nova_2012.2.1+stable-20121212-a99a802e-0ubuntu1.1~cloud0_all.deb 404 Not Found E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? An update (2012.2.1+stable-20121212-a99a802e-0ubuntu1.2~cloud0) was pushed out in the last few hours that supersedes (and expires) the package you're attempting to download. Run apt-get update before installing and apt should pull the correct version. You might find http://status.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/folsom_versions.html useful in the future. HTH, 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
Re: [Openstack] Call for testing : 2012.2.1 tarballs
On 11/20/2012 01:50 PM, Mark McLoughlin wrote: Hey, We're hoping to publish Nova, Glance, Keystone, Quantum, Cinder and Horizon 2012.2.1 next week (Nov 29). The list of issues fixed so far can be seen here: https://launchpad.net/nova/+milestone/2012.2.1 https://launchpad.net/glance/+milestone/2012.2.1 https://launchpad.net/keystone/+milestone/2012.2.1 https://launchpad.net/quantum/+milestone/2012.2.1 https://launchpad.net/cinder/+milestone/2012.2.1 https://launchpad.net/horizon/+milestone/2012.2.1 That's roughly 80 bugs. We'd appreciate anyone who could give the candidate tarballs a whirl: http://tarballs.openstack.org/nova/nova-stable-folsom.tar.gz http://tarballs.openstack.org/glance/glance-stable-folsom.tar.gz http://tarballs.openstack.org/keystone/keystone-stable-folsom.tar.gz http://tarballs.openstack.org/quantum/quantum-stable-folsom.tar.gz http://tarballs.openstack.org/cinder/cinder-stable-folsom.tar.gz http://tarballs.openstack.org/horizon/horizon-stable-folsom.tar.gz We've also started drafting release notes here: http://wiki.openstack.org/ReleaseNotes/2012.2.1 Contributions to those release notes are very welcome. Thanks! Mark. Seems connection_type / nova.virt.connection.get_connection has gotten prematurely removed in Folsom and nova-compute is broken. :\ Please see https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1081836 and target accordingly. - 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
Re: [Openstack] Packaging Horizon
On 09/14/2012 05:06 AM, Matthias Runge wrote: Hi, currently, I'm trying to package horizon RC1 for Fedora. Since, Fedora does not have node.js included, and also doesn't have LESS included, it won't work per default. Do you have suggestions for me? Thanks We faced the same issue in Ubuntu [1]. Ended up compiling and compressing the CSS and JS at packaging time, shipping those + the manifest.json with the package and enabling COMPRESS_OFFLINE=True by default. Users who might want to make use of lessc and node later can just install node-less and set COMPRESS_OFFLINE=False. Adam [1] https://bugs.launchpad.net/horizon/+bug/1024326 ___ 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] DHCP and kernel 3.2
On 08/09/2012 12:13 AM, Alessandro Tagliapietra wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro Hey Alessandro- I'm able to confirm this affects the quantal kernel (on both quantal and precise) and vanilla kernels since 3.2.26 (at least those available from http://kernel.ubuntu.com/~kernel-ppa/mainline/) I began looking at this issue a while back and doing some packet dumping, but I seem to have misplaced those .pcaps. IIRC, what I saw happening was the instances' DHCP DICOVERY makes it to the server, dnsmasq properly sends an OFFER, but the the instance never returns with the REQUEST. I feel like, at one point, I was seeing an external DHCP server (on the public network) responding to the DISCOVERYs with OFFERs of addresses from the wrong network, and the instance actually REQUEST'ing and getting an IP from the wrong server. I will open a bug about this in Launchpad against the kernel and see if we can get some help bisecting and figuring out what broke. 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
Re: [Openstack] DHCP and kernel 3.2
On 08/09/2012 12:13 AM, Alessandro Tagliapietra wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro ___ Also, when testing FlatDHCPManager are you using multi_host mode, or is DHCP being served from a central nova-network node? What ethernet driver are you using? Thanks, 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
Re: [Openstack] Improving logging
On 07/18/2012 04:32 PM, Eugene Kirpichov wrote: Hi, I noticed that there are quite a few cases when I found my OpenStack installation is broken and logging was not verbose enough for me to understand what exactly was broken, so I had to add more logging statements to the code and relaunch. Would it be useful to contribute such small logging-only patches aplenty as they appear or would that just unnecessarily bother the reviewers? Are there any logging best practices in OpenStack - e.g., is anyone worried about the possible code bloat or log bloat due to too many logging statements? (my experience says that it's impossible to have too many logging statements in a complex system, but well). Also, is the log format supposed to be machine-parseable / do people depend on it, or does it make sense to try introducing patches increasing readability of logs, fixing typos etc.? Thanks. [That's my first email to the list. Nice to meet you. I'm a huge fan of everything that helps understand the behavior of distributed systems, thus my interest specifically in logging] Speaking of logging... I've noticed in Folsom, since the migration of nova to use openstack-common logging facilities, nova services no longer logs anything useful (if anything at all) to the log files it used to. I imagine a tweaked logging.conf needs to be supplied to provide log output comporable to the default verbose=True and debug=True logging setups from Essex. Does anyone have an example logging.conf that will get me this or is this documented somewhere? 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
Re: [Openstack] [Folsom Testing Packages] Feedback
On 07/13/2012 05:50 AM, Emilien Macchi wrote: Thank's to Adam Gandelman for the last e-mail about *Folsom Testing Packages* in *Ubuntu* [1]. I would like to share here my feedback and also the Issues I have today with that : * Glance Packaging [2] : Conflict between two packages. * Glance Endpoint does not work with API V2 but works with API V1. If I comment */etc/glance/glance-api-paste.ini* the part about V2, everything works. Maybe it's my bad, I need to understand more what's wrong. Anyway, I did not have this issue with Essex. * Horizon does not work [3] [1] http://www.mail-archive.com/openstack@lists.launchpad.net/msg14298.html [2] https://bugs.launchpad.net/python-glanceclient/+bug/1024281 [3] https://bugs.launchpad.net/horizon/+bug/1024326 Let me know if you have any idea. Regards Thanks Emilien, this is exacly the kind of testing I was hoping to get! In the future, please target bugs against the Ubuntu distro package rather than the upstream project. Thanks again, hope to have those fixed for you soon. Adam Emilien Macchi *System Engineer* **www.stackops.com* http://www.stackops.com/*|emilien.mac...@stackops.com mailto:emilien.mac...@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 ___ 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] [cinder] Nova-volume vs. Cinder in Folsom
On 07/11/2012 09:22 AM, Narayan Desai wrote: I also vote for option 1, but the migration path really needs to be solid and well documented. -nld I feel the same. I think documented and tested migration paths are of utmost importance here. Unlike the Keystone - Keystone Light migration, people are actually using Nova volume in production right now. There were some facilities added in the later Keystone to help with migration, but AFAICS Keystone adoption at the time wasn't to the point where the migration path really mattered--not enough to have any bugs being rasied, at least. Anyone know if beginnings of such docs and utilities exist currently? 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
[Openstack] Openstack Folsom testing packages available for Ubuntu 12.04 and 12.10.
Hey All- I'd like to announce the availability of Folsom trunk testing PPAs for Ubuntu 12.04 and and 12.10. We've spent a considerable amount of time this cycle expanding our test infrastructure + coverage and packaging efforts in order to support a single Openstack release across two Ubuntu releases. We're not *entirely* there yet, but anyone interested in testing a packaged version of Folsom are encouraged to check out the PPA [1]. https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing The PPA contains packages for both Precise and Quantal (they are built and uploaded in parallel). You can add the PPA to a system running either release by running: sudo apt-add-repository ppa:openstack-ubuntu-testing/folsom-trunk-testing In addition to the core Openstack folsom projects, the PPA also contains several new dependencies that either did not exist in time for 12.04 or have not yet be promoted to the main archives in 12.10. (Note, these will all be available and supported via the cloud archive [2] when it goes live) We're still in the process of fleshing out some of the logistics regarding packaging branches and where to propose merges, but in the meantime any packaging related bugs are more than welcome to be filed against the respective project in Ubuntu. This PPA represents the work we're doing around Openstack packaging for multiple Ubuntu releases. Any help making sure this stuff is solid would be greatly appreciated as it currently benefits two simultaneous release efforts. As mentioned, packages for 12.04 and 12.10 are built and uploaded in parallel for new commits that hit trunk. You can track these builds on our Jenkins dashboard [2]. Deployment and integration testing results should start to publish to that dashboard in the next day or so. We've been triggering cinder and cinderclient builds, but those packages haven't yet seen much testing. Again, any help is greatly appreciated. Our trunk testing PPAs generated some excellent feedback, bug reports and packaging fixes from the community toward the end of last cycle and I'd love to get that going earlier this time around. Cheers, Adam [1] https://launchpad.net/~openstack-ubuntu-testing/+archive/folsom-trunk-testing [2] https://wiki.ubuntu.com/ServerTeam/CloudArchive [3] https://jenkins.qa.ubuntu.com/view/Openstack%20Testing/view/Overview/? ___ 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] Multiple nova-compute hosts, single-host nova-network, and a guest unreachable via its floating IP
On 06/19/2012 10:52 AM, Florian Haas wrote: Hi everyone, perhaps someone can shed some light on a floating IP issue. I have 2 nova-compute nodes (call them alice and bob), one of them (alice) is also running nova-network. bob uses alice as its --metadata_host and --network_host. I assign a floating IP to a guest running on bob. Expectedly, that IP is bound to the NIC specified as the --public_interface on alice (my nova-network host). However, since alice has a route into the --fixed_range network over its local bridge, the incoming traffic for the floating IP is routed there, where there's no guest to answer it -- because the guest is, after all, running on bob. Now, this seems fairly logical to me in the combination of 1. a nova-network host also running nova-compute; 2. other nova-compute hosts being around; 3. those other nova-compute hosts _not_ also running nova-network (and hence there being no multi-host networking). Florian- I was helping someone debug a similar setup a while back and found that nova was not putting the interface into promiscuous mode and it was dropping packets bound for the other compute node on the floor. This came to me after noticing everything seemed to work fine as soon as I started debugging with tcpdump on nova-network. :) HTH, 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
Re: [Openstack] Has anyone tested Juju with 12.04 Essex installation?
On 05/03/2012 06:04 AM, Jorge Luiz Correa wrote: Hi list! I would like to know if someone has tested juju with Essex. I've installed OpenStack using Ubuntu 12.04 and its packages (Essex). The nova components are working fine. I can create and destroy instances. So I'm using Juju from a 11.10 Oneiric. I've made some modifications in my environment.yaml configuration file to work with keystone. In my first tests I could bootstrap, creating a new instance. However, some problems that I'm having now: I'd recommend using the latest Juju version, either from the Juju PPA [1] on oneiric or the version shipped with precise. 1) Juju and nova aren't creating secgroup-rules in the right way. I can see new secgroup-rules, like juju-sample, juju-sample-0 and so on. But, when I list the rules, there are NO rules. The immediately impact is that when running 'juju status' the host is not able to access the instances created by juju. If I go to dashboard and add access with the right ports, so juju gets working. This should be working fine. We fixed some bugs in nova around security groups during Essex that I uncovered trying to get Juju working against it, but since then its been working nicely. I've just bootstrapped against an Essex/12.04 and get a functioning security group rule set. This may look a bit different depending on what you've named the environment, but should be similar: http://paste.ubuntu.com/965169/ 2) The host running juju 'should' know how to resolve the instance names, like server-8, server-10 to address from cloud network. How we need to deal with it? Host running juju has to use the same DNS that serves the cloud? I've changed the dhcp configuration in juju host to add the address of nova network that runs a dnsmasq and knows how to resolve these names. Is this the right way? Recommendations? This is mostly a Nova config thing. By default, new instances' public hostnames are the same as their private hostnames.If you want to be able to reach instances via their private hostname, you'd need to do some DNS magic outside of Juju like you are doing, or perhaps there is a documented way of achieving this in Nova itself. The best solution is to instead add '--auto_assign_floating_ip' to nova.conf. This will ensure a public floating IP is associated with new instances and allow Juju to reach its nodes that way instead. This matches the behavior of EC2. Adam [1] Juju PPA - ppa:juju/pkgs Thanks! -- - MSc. Correa, J.L. ___ 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] Quantum deployment on Essex
On 04/20/2012 01:37 PM, Lorin Hochstein wrote: This might be due to a known issue with the noVNC package that is distributed with Ubuntu 12.04: https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/956949 I have heard that the noVNC fork maintained by Rackspace Cloud Builders works properly with Essex: https://github.com/cloudbuilders/noVNC/ There is a current Ubuntu bug that is attempting to get the newest version synced into Precise via a last-minute feature-freeze exception. Please weigh in with support if you can confirm the debian package works... https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/985274 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
Re: [Openstack] Endpoints problems
On 04/13/2012 10:50 AM, Dolph Mathews wrote: While $(tenant_id)s is certainly the documented syntax, it appears that the SQL catalog backend (and *only* the SQL catalog backend, as far as I can tell) explicitly supports both $(tenant_id)s and %(tenant_id)s: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L163 Perhaps Adam Gandelman has some insight? -Dolph Dolph- No, the same is supported in the case of templated catalog as well, which is what the SQL catalog was largely based off: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L115 Just tested that sed -i 's/\$/%/g' /etc/keystone/default_catalog.templates still produces a functional service catalog when configured to use the templated backend. Seeing as both are supported, perhaps it would be better for docs to be updated to refer to the use of % instead of $ to avoid people running into problems with the $() sub-shell? 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
[Openstack] Recent changes to Ubuntu packaging wrt Glance, upgrading, database sync
Hi- We've added a patch to the Glance package in Ubuntu to help improve the experience for users who are counting on a smooth upgrade from Diablo. Since the release of Essex, I've been mostly focused on upgrade testing. Things seem generally okay with the exception of Glance and the way it manages its database and migrations. To ensure users can reliably upgrade from Diablo, we've made a couple of changes that people should know about as the end result is currently a bit different than what you'd expect comparing to devstack/vanilla git repos. 1. Disabled database auto-creation Glance is the only project that I know of that currently allows sqlalchemy to auto-create database schema to match its database models. This is great for the developer use-case, but really not ideal for anyone who wishes to maintain their database for the long-term. The original issue is that, on startup, glance-registry creates a database schema that reflects its most recent view of the database. When it does, the schema is created outside the view of migrate and the migration repository cannot be used to incrementally upgrade/downgrade the schema. Recent changes [1] in Glance provides a work-around to this isssue, where we rely on glance-registry to automatically put the database under version control after auto-creation and set its version to the most recent (currently 13). This works fine for development but there are important details in the migration code that don't actually end up in the database schema when auto-created (FK constraints, for example) because the migration scripts are not actually run. To avoid this entirely, we've prevented Glance from auto-migrating its database and now require users to migrate the database on new install and upgrade (via db_sync) in the same way Nova does. 2. Sync'ing a new database. The changes also now allow users to set a specific version when initializing version_control on a database with glance-manage, eg: glance-manage version_control 9 glance-manage db_sync This would properly migrate an non-version controlled Diablo database to Essex. This is great, but it is still possible for Diablo users to mistakenly start glance or run db_sync with no version control, and end up in a situation where glance + migrate think it is up to date. In reality the database is missing 3 migrations (one of which, 012 IDs to UUIDs, is very essential!) To prevent this, the Ubuntu patch additionally requires explicitly version_control'ing the database a before db_sync on both new databases and during upgrades of databases that are not already version_control'd. For example, on a new database: # Start from the beginning of the migration repositroy glance-manage version_control 0 glance-manage db_sync or to upgrade from Diablo: # Was our database properly version controlled to begin with? if ! glance-manage db_version ; then # Set its version if not glance-manage version_control 9 fi # Run all migrations 10 to 13 glance-manage db_sync I understand this may have come a bit late to any users of the Precise packages and I apologize for the lack of a heads up. I've filed a new bug [2] about the split brain between glance-registry and and hope to address this at the database management session [3] at ODS next week. Anne Gentle has also proposed an update to the documentation with a note about this. Please understand that our aim was to keep our patch delta as minimal as possible in Ubuntu, but with the yesterday's Final Freeze for the cycle 12.04 we needed something in place that ensures a sane user story for previous users of Diablo and future Essex users alike. Cheers, Adam [1] https://review.openstack.org/#/c/6166/ https://review.openstack.org/#/c/5980/1 [2] https://bugs.launchpad.net/bugs/981081 [3] http://summit.openstack.org/sessions/view/36 ___ 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-* as upstart services in release essex
On 04/10/2012 02:13 PM, Vijay wrote: /etc/init/nova-compute.conf description Nova compute worker author Soren Hansen so...@linux2go.dk mailto:so...@linux2go.dk start on (filesystem and net-device-up IFACE!=lo) stop on runlevel [016] chdir /var/run pre-start script mkdir -p /var/run/nova chown nova:root /var/run/nova/ mkdir -p /var/lock/nova chown nova:root /var/lock/nova/ modprobe nbd end script exec su -c nova-compute --flagfile=/etc/nova/nova.conf nova That upstart job looks either very different (or old) compared to what we've been shipping with current packages in Ubuntu. Cr What does 'dpkg -l | grep nova' show? 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
Re: [Openstack] Best approach for deploying Essex?
On 04/03/2012 08:20 AM, Lillie Ross-CDSR11 wrote: My question is, should I base our new installation directly off the Essex branch in the git repository, or use the packages that will be deployed as part of the associated Ubuntu 12.04LTS release? With Diablo, I was forced to use packages from the ManagedIT PPA with additional Keystone patches to get a consistent, stable platform up and running. Obviously, some of these problems were due to confusion caused by various documents describing different incarnations of Openstack, and not really knowing what was current and stable. Especially the packages shipped with Ubuntu made assumptions about how Openstack was to be deployed that wasn't really apparent. Hey Ross- I can say that the Ubuntu precise packages have been kept relatively in-sync with each components' trunk git repository this cycle. We've made a concerted effort to do weekly snapshot uploads of all Openstack components into the Precise archive starting from the beginning of the Essex+Precise dev cycles. We've also maintained our own trunk PPA (updated continously) around which we center our testing efforts. Now that we're nearing the release of Essex, we've been ensuring the release candidates hit our archive as soon as they are released. As soon as Essex final hits, it'll be uploaded into Ubuntu and give any users who care the remainder of the Ubuntu dev cycle (~1 month) to test and identify issues before LTS ships. Re: deployment assumptions. Last cycle, we were caught off-guard by Keystone's last-minute inclusion into Openstack core and the dependencies this introduced (dashboard especially) It's not that we were making assumptions about how Openstack Diablo should be deployed, just that there was no way we could shoe-horn a new component into the release so late in the game. This time around, a similar curve ball was thrown our way with the Keystone Lite rewrite, but we were able to get this sorted on our end relatively quickly to ensure pending security reviews and main inclusion processes for Keystone weren't blocked. We're making very few assumptions going into LTS and hope to provide as-close-to-pure Essex experience as any. I can only think of a few patches we're carrying, and there are only two default configuration files we ship that differ from those you'd find in the git repos [2]. Perhaps when we release Essex into Precise this/next week, we'll put some notes somewhere outlining any Ubuntu-specific changes for those who are interested. Hope that helps, and of course we welcome your testing and bug reports! -Adam [1] We ship a default nova.conf that configures some Ubuntu defaults: defaults to libvirt compute, uses nova-rootwrap for sudo shell execution (requested by our security team), uses tgt iscsi initiator instead of ietd (tgt is supported in our main archive, ietd is not). Our default Keystone config defaults to the SQL catalog backend instead of the default templated file, though I think SQL catalog is the new default in folsom. ___ 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] Installion guide for OpenStack Essex on Ubuntu 12.04
On 03/26/2012 06:50 AM, Martin Gerhard Loschwitz wrote: Hi folks, I've written a guide on how to install OpenStack Essex on Ubuntu 12.04. It covers the installation and configuration of Keystone, Glance, Nova and Horizon. By following this guide, even people that haven't collected much OpenStack experience so far should be able to get the virtualization environment up and running in a short period of time. The full document is available from here: http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin All feedback and comments are much appreciated -- thanks in advance! Best regards Martin Good stuff, Martin! After a quick read, the biggest thing that stuck out as an eye-sore currently is the reference to Bug #959262 [1] and subsequent manual patching in the Horizon setup. I took a look at this today and confirmed its still affecting Ubuntu. The fix needs to be proposed to milestone-proposed / Essex rc1, which we can hopefully take care of tomorrow. If for whatever reason its not, we'll carry the small patch in Ubuntu going into 12.04. If there are any other packaging specific issue I overlooked, please don't hesitate to file bugs or ping me directly on IRC! Cheers, Adam [1] https://bugs.launchpad.net/ubuntu/+source/python-novaclient/+bug/959262 ___ 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] MySQL connection gone away handling in OpenStack projects
On 03/22/2012 09:48 AM, Vishvananda Ishaya wrote: This looks like a much better solution than MySQLPingListener. It would be good to get this into common / nova, especially if we can verify that it works with postgres as well. Vish +1 for making this the standard method of initializing databases across projects. A quick test of adding a wrapped call to _ENGINE.connect() in the main try/except block of configure_db seems to totally solve the issue of services starting at boot before a database is reachable, reported @ https://bugs.launchpad.net/ubuntu/+source/nova/+bug/959426 -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
Re: [Openstack] Keystone Not Logging
Kevin, Dolph--
Getting this working out-of-the-box has been a TODO of mine for a
while. I've filed https://bugs.launchpad.net/keystone/+bug/959610 to
track.Adding the example dolph mentioned did not seem to get any log
output generated.
@Kevin- The logging.conf installed in the current Ubuntu packages is the
logging.conf that was previously shipped in the pre-KSL keystone
branch. The current logging.conf.sample in the source tree seems to be
copied from glance. This is also installed at
/etc/keystone/logging.conf.sample alongside the version we maintain in
packaging.
Adam
On 03/18/2012 01:03 PM, Kevin Jackson wrote:
Hi,
I have Keystone set up (2012.1~rc1~20120316.2145-0ubuntu1) on Ubuntu
12.04 B1 and it isn't logging.
Only when stopping the keystone service then running 'keystone-all' in
a terminal do I get to see all the debug output.
I've checked permissions (/var/log/keystone and keystone.log are owned
by keystone user/group) and I've tried the packaged
logging.conf.sample (note the ubuntu package ships with this
referencing 'glance') to no avail.
/etc/keystone/keystone.conf
...
verbose = True
debug = True
log_config = /etc/keystone/logging.conf
...
/etc/keystone/logging.conf
[loggers]
keys=root,keystone,combined
[formatters]
keys=normal,normal_with_name,debug
[handlers]
keys=production,file,devel
[logger_root]
level=NOTSET
handlers=devel
[logger_keystone]
level=DEBUG
handlers=devel
qualname=keystone
[logger_combined]
level=DEBUG
handlers=devel
qualname=keystone-combined
[handler_production]
class=handlers.SysLogHandler
level=ERROR
formatter=normal_with_name
args=(('localhost', handlers.SYSLOG_UDP_PORT),
handlers.SysLogHandler.LOG_USER)
[handler_file]
class=FileHandler
level=DEBUG
formatter=normal_with_name
args=('/var/log/keystone/keystone.log', 'w')
[handler_devel]
class=StreamHandler
level=NOTSET
formatter=debug
args=(sys.stdout,)
[formatter_normal]
format=%(asctime)s %(levelname)s %(message)s
[formatter_normal_with_name]
format=(%(name)s): %(asctime)s %(levelname)s %(message)s
[formatter_debug]
format=(%(name)s): %(asctime)s %(levelname)s %(module)s %(funcName)s
%(message)s
Is anyone able to help out what's up with this?
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
___
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] Configuring Nova VNC Proxy_Essex_rc1
On 03/19/2012 09:04 PM, Andrew Weiss wrote: Hi Anthony, So I figured out the issue I was having. I was using the nova-vncproxy Precise rc1 packages, however nova-consoleauth was not included. Instead, I simply pulled the source from Git. Only other issue now is that the access URL that is being returned uses the 127.0.0.1 host. Even after I set the the following flags it still won't change the host to the IP address I want: --novncproxy_base_url=http://192.168.10.1:6080/vnc_auto.html --novncproxy_port=6080 --novncproxy_host=192.168.10.1 When I execute nova get-vnc-console server id novnc I get an access URL back, but it is using the host 127.0.0.1 which obviously poses an issue when I access my dashboard from a different host. Any idea where else I might be able to change this? Thanks, * * Andrew Andrew-- Packaging has been fix to properly install nova-consoleauth as its own binary package (its currently coupled with nova-console), should be updated in precise with the next upload (presumably rc1) [1] However, I had the same results trying to set the base url flag, perhaps that is an unrelated nova bug. Adam [1] https://bugs.launchpad.net/bugs/959426 ___ 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] euca2ools: Failure communicating with keystone (Essex on Ubuntu 12.04 B1)
On 03/16/2012 09:01 AM, Kevin Jackson wrote: After successfully spinning up instances on Essex under Ubuntu 12.04 B1 using nova tool I'm now looking at the EC2 API / euca2ools but I'm hitting an error $ euca-describe-instances Unauthorized: Failure communicating with keystone /etc/nova/nova.conf: --ec2_url=http://172.15.0.2:8773/services/Cloud Do you also have --keystone_ec2_url=http://keystonehost:5000/v2.0/ec2tokens ? 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
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
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 http://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
Re: [Openstack] [ubuntu-cloud] Update on Ubuntu automated testing and CI of Openstack
On 02/27/2012 09:22 AM, Duncan McGreggor wrote: It's been an invaluable source for not only information, but also planning for the cloud work here at DreamHost. This is great to hear! I'm happy to hear other people are benefiting from this as much as Ubuntu To the point of this email, though, I have a question for you that I wasn't able to parse an explicit answer to from your post: For the packages that are built in the PPA linked above, are they only built after all the components of OpenStack have been confirmed working as a whole? Or are they built just after individual testing? The jenkins trunk build jobs are the ones responsible for uploading to the PPA. It basically stuffs the newly built package in the local repository and uploads it to the PPA (if it fails to build, it doesnt upload). The nova trunk build also triggers the deployment + testing. So, to answer, those PPA packages are *pre* deployment + smoke testing. The idea with that is that we can use the PPA externally to debug specific issues that might turn up during testing without blocking the deployment/smoke testing queue. We're limited by the number of machines we have and can not currently run deployment testing in parallel. My question comes from this concern: if we're building out a product based on this PPA, (before Precise is delivered) we want to make sure that when we bring up new systems by installing the packages from the PPA, all of those work together properly. If the latest code from keystone, for example, hasn't been building due to testing errors, we want to make sure that the presence of the older keystone package in the PPA won't be causing issues with the newer builds of the rest of OpenStack. So you might have noticed the version of Keystone we are testing is getting a bit dusty. We decided to freeze the version of Keystone we're testing just before the KSL/redux branch was merged. There are still some features that need to land before we can modify our Juju charms to deploy the new version (specifically SQL persistence for the service catalog). I'm hoping these will land before e4 (tomorrow) so we can begin testing the new branch this week. To clarify: in your blog post, you explicitly mention the validation process per component, starting with the upstream git repos. In the deploy phase, you verify that the system as a whole (all of OpenStack) works as expected. But what happens when one or more of those components don't work? Are packages rolled back in the PPA until the PPA only provides packages that will result in, once installed, a complete working system? So far, we haven't rolled anything back in the PPA or the local repository. I believe Keystone is the only package we've had to freeze while things stabilize upstream. Fortunately, we've found the CI (even with the limited test coverage we currently run) is picking up new bugs almost instantaneously. In most cases we're able to either get a fix into gerrit same day or find a proposed fix that we can cherry pick into our debian/patches/ repository and carry temporarily in our lp:~openstack-ubuntu-testing packages branches until its been fixed proper upstream. Please understand the PPA is for testing purposes only, and we're not making any promise that what installs from there is stable/usable/working. We're using the work around that PPA and this CI to essentially gate what goes into the Ubuntu archive. This cycle, Chuck has been uploading a weekly snapshot of Openstack (usually every Friday). With the CI in place, we can essentially verify that those packages build clean and install okay, and provide something usable given the last weeks Gerrit churn. Keep in mind this is still a developing process. I expect this will evolve over the next few months. We've just begun trigger pre-commit testing to the Diablo stable branch against Oneiric. Still working out some kinks, but we'll hopefully be going into Folsom+Precise with coverage of both trunk and stable updates to Essex/Precise LTS. Also note that, at this point in the Ubuntu development cycle, it can often take *a long time* before an upload to a PPA is built and ready for use. Its probably safe to assume that what you're using from the PPA is what we were testing yesterday (check the version of the package for a timestamp) Keep up the great work, guys -- you have fans out here in the wild, wild world of OpenStack :-) :) Cheers, 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
Re: [Openstack] RFC nova-network RTNETLINK patch
On 02/09/2012 10:25 AM, Bernhard M. Wiedemann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm looking for comments on the attached patch. On the net I found older/different versions of nova/network/linux_net.py containing if err and err != 'RTNETLINK answers: File exists\n': Hi Bernhard- I came across the same thing on Ubuntu yesterday. Recent versions of iproute2 have switched (or fixed, apparently) return codes when unnecessarily adding or removing addresses. This is a new issue on Ubuntu Precise atm and imagine will be on future releases of other distros. There is a review pending that fixes this at https://review.openstack.org/#change,3934 and a LP linked from there. 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
[Openstack] Update on Ubuntu automated testing and CI of Openstack
As promised for anyone who was interested when we announced to the last last week, here is a blog post James Page and I put together describing our Openstack testing efforts and infrastructure in greater detail: http://javacruft.wordpress.com/2012/02/08/automating-openstack-testing-on-ubuntu/ I'm quite pleased with the results of the testing over the last 2 weeks or so. We've already uncovered a number of bugs that we were able to help squash and continue to uncover subtle stuff we wouldn't have come across otherwise until after we've uploaded our weekly Essex/Precise snapshot into the archive. As a result, 'apt-get insatll $core_project' on Precise gets you something more stable than at any point during the Diablo/Oneiric cycle. In the short term, we'll be working to enable pre-commit multi-node smoke testing of the stable Diablo branch on Oneiric as well as deploying and enabling Swift so that we're utilizing all of the current Devstack exercises (we currently run all but swift). We're approaching the Ubuntu feature-freeze (Feb. 16th) and, as always, would greatly appreciate any help further testing and stabilizing Openstack on Ubuntu! Cheers, 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
Re: [Openstack] Ubuntu OpenStack QA Lab up and running
Hey Nati-- 1. Is there any document or opensource of your juju-based ci-deployment? You can find a whole pile of bzr branches that hosts everything this is built on at https://code.launchpad.net/~openstack-ubuntu-testing Beware this contains a lot of stuff! Packaging branches, forked Juju charms customized for the CI lab, various utility scripts we came up with along the way. I'll try to get an email or blog somewhere that gives an overview of what we've put together and how it all works. 2. Which kind of test are you running after deploy test? We're currently deploying components across 8 baremetal nodes and then running a very basic test of cloud functionality. I lifted the euca test from the devstack exercise scripts. I'd like to also recruit the other excercise scripts to smoke test the deployment so we are at least on-par with what upstream CI is testing. I've been poking at tempest in the meantime as well. Unfortunately, every time I do requires uncovering some more bugs. I will probably look into enabling Tempest testing even if its results are not 100% reliable currently. Long-term, we'd like to be using the Tempest suite to do all integration testing. 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
