Re: [Openstack] HVM + Xen Hypervisor via libvirt possible?
We use CentOS in production environment. There is the Zeus project, right? I'll do some research on it 在 2012-6-22 下午12:30，Thomas Goirand tho...@goirand.fr写道： On Fri Jun 22 2012 11:22:13 AM CST, Li Wang fox...@gmail.com wrote: Thanks all for replying. We want to stick on to the Xen Hypervisor for some reason. 1. Does the community plan to support this feature? 2. Could I submit this request to the blueprint? My team would like to contribute on it if necessary. 3. or some good reasons to migrate from Xen to KVM? Hi, why sticking with libvirt? There's XCP available in both Debian and Ubuntu, so there's no reason to use libvirt for Xen anymore! Just apt-get install xcp-xapi in your dom0 and use XenAPI. Thomas ___ 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] Access a 3rd network
Hi, I'm new here so if this is a stupid question or the wrong place to ask, please just point me in the right direction. I have nova-compute running on 4 hosts with nova-network running on the controller host using FlatNetwork. Each of the hosts have three network interfaces: eth0 - 10.10.20.0/24 - public eth3 - 10.10.11.0/24 - private/bridge bond0 - 10.10.12.0/24 - eth1 and eth2 bonded together - not used by nova at the moment The VMs have access to the 10.10.20.0/24 network and the world via floating ip's, but I also need them to have access to the 10.10.12.0/24 network. How can this be done? Is there a way to create a 2nd public network bridged/natted to the bond0 interface? I tried doing this manually by adding an ip to the bond0 interface and the iptables rules, but that only worked from the 12 network to the VMs not from the VMs to the 12 network. Thank you Marnus van Niekerk ___ 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] [Metering] Implemented three methods in Ceilometer
Hi Julien Danjou, I followed the steps given in http://wiki.openstack.org/GerritWorkflow this site. But I am getting some error while executing the command git review. While I am executing that command I am getting following error: Problem running 'git remote update gerrit' Fetching gerrit ssh: connect to host review.stackforge.org port 29418: Connection timed out fatal: The remote end hung up unexpectedly error: Could not fetch gerrit Can you please tell me the way to resolve this error. Thanks Regards, Bharath Kumar -Original Message- From: Julien Danjou [mailto:julien.dan...@enovance.com] Sent: Wednesday, June 20, 2012 2:13 PM To: Kobagana Kumar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Metering] Implemented three methods in Ceilometer On Wed, Jun 20 2012, Kobagana Kumar wrote: Hi Kobagana, I have implemented three more classes in Ceilometer plug-in module. Added those classes in libvirt.py file in compute. The classes which I have added are counters to find out the following: 1. Number of CPUs used 2. Memory used 3. Maximum memory used I am also ready with test cases for those methods. Please let me know the procedure to contribute my code to ceilometer code base. You need to send your patches to https://review.stackforge.org/ using git-review. You can find some documentation about this here: http://wiki.openstack.org/GerritWorkflow -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ 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] [Metering] Implemented three methods in Ceilometer
That simply appears that you have a network issue… Perhaps a firewall at work blocking that port number, or a DNS issue, or a temporary issue with review.stackforge.org? John Postlethwait Nebula, Inc. 206-999-4492 On Thursday, June 21, 2012 at 11:37 PM, Kobagana Kumar wrote: Hi Julien Danjou, I followed the steps given in http://wiki.openstack.org/GerritWorkflow this site. But I am getting some error while executing the command git review. While I am executing that command I am getting following error: Problem running 'git remote update gerrit' Fetching gerrit ssh: connect to host review.stackforge.org (http://review.stackforge.org) port 29418: Connection timed out fatal: The remote end hung up unexpectedly error: Could not fetch gerrit Can you please tell me the way to resolve this error. Thanks Regards, Bharath Kumar -Original Message- From: Julien Danjou [mailto:julien.dan...@enovance.com] Sent: Wednesday, June 20, 2012 2:13 PM To: Kobagana Kumar Cc: openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Subject: Re: [Openstack] [Metering] Implemented three methods in Ceilometer On Wed, Jun 20 2012, Kobagana Kumar wrote: Hi Kobagana, I have implemented three more classes in Ceilometer plug-in module. Added those classes in libvirt.py file in compute. The classes which I have added are counters to find out the following: 1. Number of CPUs used 2. Memory used 3. Maximum memory used I am also ready with test cases for those methods. Please let me know the procedure to contribute my code to ceilometer code base. You need to send your patches to https://review.stackforge.org/ using git-review. You can find some documentation about this here: http://wiki.openstack.org/GerritWorkflow -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com (mailto:julien.dan...@enovance.com) ☎ +33 1 49 70 99 81 DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ 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] [ANNOUNCE] OpenStack Nova, Glance, Keystone and Horizon 2012.1.1 released
Hey, In the time since the Essex release, we have been busy selectively back-porting bugfixes to the stable/essex branch according to our safe source of high-impact fixes criteria documented here: http://wiki.openstack.org/StableBranch Well, those fixes are now available as 2011.3.1 releases! These releases are bugfix updates to Essex and are intended to be relatively risk free with no intentional regressions or API changes. The list of bugs fixed can be seen here: https://launchpad.net/nova/+milestone/2012.1.1 https://launchpad.net/glance/+milestone/2012.1.1 https://launchpad.net/keystone/+milestone/2012.1.1 https://launchpad.net/horizon/+milestone/2012.1.1 Please read (and add to!) the release notes at: http://wiki.openstack.org/ReleaseNotes/2012.1.1 Enjoy! Mark. ___ 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] How to improve our bug triaging ?
Hi, Le jeudi 21 juin 2012, à 16:29 +0200, Thierry Carrez a écrit : * Run BugTriage days more often ? We could have regular (monthly?) Nova Bugtriage days to get rid of what accumulated in the mean time. But I fear that urgent bugs might not get the attention they deserve, and that over time less and less people participate to those exciting events... [...] * Should we just encourage more people to do BugTriaging ? Sounds like the obvious solution. However to do good triaging, you need bug supervisors rights, and when I proposed to open that team (the nova-bugs team) to anyone, there was resistance. Maybe it makes sense for Nova though... or maybe someone should actively manage that team and grant rights to any known triager that needs them. To me, those two points are related: we likely want to have more bug triage days, but in order to make this work in the long term, we need to encourage more people to join the effort. Else, there'll be burnout. We can then have several ways to make those days more exciting; this has been done in many other projects already (setting goals, friendly competition between participants, and even just creating a friendly atmosphere on irc during the day). Even just seeing the impressive stats in your last blog post is a good motivation for the next triage day... Oh, and I don't think we should be afraid of opening up the bug supervisors rights to more people. In other projects, the upsides have largely outweighed the potential downsides. Of course, it requires some expertise, but people will try hard to avoid doing mistakes, and mistakes can be reverted anyway :-) It's more important to have a sane bug database and happy bug reporters, than no mistakes at all. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ 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] Devstack fedora 17 (issues)
Hi All, New to devstack. Any help would be appreciated. Currently I am using devstack on fedora 17 and I get the following error (pasting only error log) (This is master branch ) == .. Waiting for keystone to start... + timeout 60 sh -c 'while ! http_proxy= wget -O- http://10.237.213.237:5000/v2.0/ 21 | grep -q '\''200 OK'\''; do sleep 1; done' + SERVICE_ENDPOINT=http://10.237.213.237:35357/v2.0 + ADMIN_PASSWORD=nomoresecrete + SERVICE_TENANT_NAME=service + SERVICE_PASSWORD=nomoresecrete + SERVICE_TOKEN=tester + SERVICE_ENDPOINT=http://10.237.213.237:35357/v2.0 + DEVSTACK_DIR=/home/tester/OpenStack/devstack + ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-vol,n + -sch,n-novnc,n-xvnc,n-cauth,horizon,mysql,rabbit + bash /home/tester/OpenStack/devstack/files/keystone_data.sh string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str string indices must be integers, not str usage: keystone user-role-add --user_id user-id --role_id role-id [--tenant_id tenant-id] keystone user-role-add: error: argument --user_id: expected one argument usage: keystone user-role-add --user_id user-id --role_id role-id [--tenant_id tenant-id] keystone user-role-add: error: argument --user_id: expected one argument usage: keystone user-role-add --user_id user-id --role_id role-id [--tenant_id tenant-id] keystone user-role-add: error: argument --user_id: expected one argument usage: keystone user-role-add --user_id user-id --role_id role-id [--tenant_id tenant-id] keystone user-role-add: error: argument --user_id: expected one argument usage: keystone user-role-add --user_id user-id --role_id role-id [--tenant_id tenant-id] keystone user-role-add: error: argument --user_id: expected one argument ... ... .. ++ glance --os-auth-token --os-image-url http://10.237.213.237:9292 ++ image-create --name cirros-0.3.0-x86_64-uec-kernel --public --container-format aki --disk-format aki grep ' id ' ++ get_field 2 ++ read data usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [--os-service-type OS_SERVICE_TYPE] glance: error: argument --os-auth-token: expected one argument + KERNEL_ID= + '[' -n /home/tester/OpenStack/devstack/files/images/cirros-0.3.0-x86_64-uec/cirros-0.3.0-x86_64-initrd ']' ++ glance --os-auth-token --os-image-url http://10.237.213.237:9292 ++ image-create --name cirros-0.3.0-x86_64-uec-ramdisk --public --container-format ari --disk-format ari grep ' id ' ++ get_field 2 ++ read data usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [--os-service-type OS_SERVICE_TYPE] glance: error: argument --os-auth-token: expected one argument + RAMDISK_ID= + glance --os-auth-token --os-image-url http://10.237.213.237:9292 + image-create --name cirros-0.3.0-x86_64-uec --public + --container-format ami --disk-format ami usage: glance [--os-username OS_USERNAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [--os-service-type OS_SERVICE_TYPE] glance: error: argument --os-auth-token: expected one argument ++ failed ++ local r=2 ++ set +o xtrace Thanks for taking time, is this a bug or issue with my environment? Note that I see same issue with F16 with stable/essex brach. Prasad -- You received this question notification because you asked the question. smime.p7s Description: S/MIME cryptographic signature -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co.
Re: [Openstack] [ANNOUNCE] OpenStack Nova, Glance, Keystone and Horizon 2012.1.1 released
Great work, congratulations to everybody :-) Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 22 juin 2012 à 10:42, Mark McLoughlin a écrit :Hey,In the time since the Essex release, we have been busy selectivelyback-porting bugfixes to the stable/essex branch according to our "safesource of high-impact fixes" criteria documented here: http://wiki.openstack.org/StableBranchWell, those fixes are now available as 2011.3.1 releases!These releases are bugfix updates to Essex and are intended to berelatively risk free with no intentional regressions or API changes.The list of bugs fixed can be seen here: https://launchpad.net/nova/+milestone/2012.1.1 https://launchpad.net/glance/+milestone/2012.1.1 https://launchpad.net/keystone/+milestone/2012.1.1 https://launchpad.net/horizon/+milestone/2012.1.1Please read (and add to!) the release notes at: http://wiki.openstack.org/ReleaseNotes/2012.1.1Enjoy!Mark.___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] HVM + Xen Hypervisor via libvirt possible?
On Fri, Jun 22, 2012 at 11:22:13AM +0800, Li Wang wrote: Thanks all for replying. We want to stick on to the Xen Hypervisor for some reason. 1. Does the community plan to support this feature? I'd like to see it supported by Nova, because it would improve the libvirt driver in general, but I don't think I'll have time to work on it in the near future. 2. Could I submit this request to the blueprint? My team would like to contribute on it if necessary. Sounds like a good idea to submit a blueprint, or alternatively file a bug, or both. I'm happy to review any code submissions for this. 3. or some good reasons to migrate from Xen to KVM? I'd favour KVM for a variety of reasons, but lets not turn this into a bikeshed discussion about which is best ;-P 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] problem with additional compute nodes
Hi friends,I have problem when I try to add a new compute node, I'd installed nova-compute and copied the nova.conf file from the controller node, but when I restarted services, and run nova-manage service list, I did not have the line containing the nova-compute service on the server2. I tried it with nova-network and it worked well. When I run the command service nova-compute start it worked and it gave me the process id. However, when I run the command service nova-compute stop, I always got the message: stop: Unknown instance:.Thanks for help sincerely ___ 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] [ANNOUNCE] OpenStack Nova, Glance, Keystone and Horizon 2012.1.1 released
Excellent - spotted a few fixes in there for bugs I haven't had time to track down :) Thanks, Kiall Sent from my phone. On Jun 22, 2012 9:45 a.m., Mark McLoughlin mar...@redhat.com wrote: Hey, In the time since the Essex release, we have been busy selectively back-porting bugfixes to the stable/essex branch according to our safe source of high-impact fixes criteria documented here: http://wiki.openstack.org/StableBranch Well, those fixes are now available as 2011.3.1 releases! These releases are bugfix updates to Essex and are intended to be relatively risk free with no intentional regressions or API changes. The list of bugs fixed can be seen here: https://launchpad.net/nova/+milestone/2012.1.1 https://launchpad.net/glance/+milestone/2012.1.1 https://launchpad.net/keystone/+milestone/2012.1.1 https://launchpad.net/horizon/+milestone/2012.1.1 Please read (and add to!) the release notes at: http://wiki.openstack.org/ReleaseNotes/2012.1.1 Enjoy! Mark. ___ 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] ssh not authenticating
Hi, Scott! I knew that the password was already on the cirros image. However, we (Grid Dynamics engineers) faced a strange problem: 1) if an instance is launched without an ssh key, you can login using the password (generated by nova in our case); 2) if an instance is launched _with_ an ssh key, you cannot login using either password or the ssh key. So, VM's filesystem synchronization can be a dark and tricky thing. That's why we are not guaranteed to login by password even if the password was stored in the image originally. On Thu, Jun 21, 2012 at 5:38 PM, Scott Moser smo...@ubuntu.com wrote: On Thu, 21 Jun 2012, udit agarwal wrote: Hi Mandar, Thanks for your reply. But I am still stuck in the problem. I tried with cirros but with no luck. And for the next one, the system still asks me for password, but it was supposed to be password-less. Can anybody help me with this?? As Alexey pointed out, the password for cirros is cubswin:). The *user* is 'cirros'. So, to login with password auth: ssh cirros@ip-address-here password-less ssh *should* work and should *not* depend on filesystem injection by nova. cirros will read the public keys specified from the metadata service and import them into the cirros user's account. You have to specify a key when you launch the instance either by: * nova boot --key_name KEYNAME or * euca-run-instances --key KEYNAME To debug why passwordless ssh is not working: * get the console output of the instance. It likely is complaining that it cannot find the metadata service. * ssh in with password auth and run 'ec2metadata --public-keys'. This will probably fail. Basically, I suspect that your metadata service is not available to the instance. Scott Thanks in advance. --Udit On Thu, Jun 21, 2012 at 6:53 PM, Vaze, Mandar mandar.v...@nttdata.com wrote: Default password for cirros is cubswin:) - including the smiley I hope you entered correct password (It is easy to ignore the last two characters thinking it is a smiley) Other options is to use password less ssh login using keypair. See http://docs.openstack.org/essex/openstack-compute/starter/content/Launch_and_manage_instances-d1e1885.html -Mandar From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of udit agarwal Sent: Thursday, June 21, 2012 11:13 AM To: openstack@lists.launchpad.net Subject: [Openstack] ssh not authenticating Hi, I have setup openstack on my system using the manual http://docs.openstack.org/essex/openstack-compute/install/apt/content/. I tried to run the test image cirros on my system. While I can easily ping it, I faced some problems in authenticating via ssh. First, it asks for password, even providing the correct password for the same, it re asked the password 2 more times and finally denied me the permission. I couldn't resolve this issue then. Can anybody help me with this??? thanks in advance. --Udit __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Alessio Ababilov Software Engineer Grid Dynamics ___ 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] ssh not authenticating
On Fri, 22 Jun 2012, Alexey Ababilov wrote: Hi, Scott! I knew that the password was already on the cirros image. However, we (Grid Dynamics engineers) faced a strange problem: 1) if an instance is launched without an ssh key, you can login using the password (generated by nova in our case); 2) if an instance is launched _with_ an ssh key, you cannot login using either password or the ssh key. I've not seen this myself. could you provide a console log (euca-get-console-output) of the image that is broken? And exactly what cirros image you're using? (ie, the disk.img or the uec tarbal...) I really can't imagine anything that would mess up password based auth with the cirros user. So, VM's filesystem synchronization can be a dark and tricky thing. That's why we are not guaranteed to login by password even if the password was stored in the image originally. Sure, I wouldn't recommend password based auth anyway. It is only enabled in the cirros image as its intent is test. please do not run cirros images with default password for anything important. ___ 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] Diagnosing RPC timeouts when attaching volumes
The timeout occurs when nova-compute is trying to do an rpc call to nova-volume. It looks like this is just the compute log. Do you have an error in the volume log? There were no errors in the volume log. It may have been a networking problem caused by the local iptables firewall on the volume server getting reset...but it's part of a larger issue we're struggling with, which is that in general OpenStack makes it very hard to track down errors along the RPC chain. Thanks! -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist| http://ac.seas.harvard.edu/ Academic Computing | http://code.seas.harvard.edu/ Harvard School of Engineering and Applied Sciences | ___ 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] Thoughts on client library releasing
Mark McLoughlin wrote: That actually goes to something I'm not aware of us - the project - having spent much time discussing. We do twice yearly releases of our collection of software, but there are public cloud providers which want to essentially do continuous deployment from our development branch. To what extent is that a reasonable thing for the project to support? If we had a shorter release cycle, would the cloud providers switch their deployments from continuous to the releases? If not, can the project and cloud providers better co-ordinate somehow? That's a discussion we had before the Essex release, when we were looking into releasing more often (every 5-8 weeks) instead of every 6 months. What makes a release ?. After all, you will never prevent people from using milestones or random snapshots, and we should strive to make master always installable and working. So why do releases ? And what should be the cadence ? To me, releases are synchronization points. We have to have a cycle with a timeframe where development slows down at one point to let QA, documentation, integration testing and translation catch-up. A release is a point in time where the stars are all aligned. The release cycle is there to help us achieve that regularly. Those synchronization points also serve to maintain stable branches and coordinate with distros (it's no mystery that we are cadenced in a way that makes us friendly with time-based distros). Currently we can only achieve that star-aligning process every 6 months, but I hope that we'll be able to do releases more often in the future. That said, us releasing every 6 months doesn't mean we should prevent users from being able to pick a version and run with it. In particular, I think our client library release scheme shouldn't actively go against that by synchronizing too much with the core release schedule. [...] For argument sake, and given a 6 month cycle, say that's 2 months before the release date. For Folsom, that's the folsom-3 milestone. Before that date, the project recommends that public cloud providers deploying Folsom from our development branch does not expose any of the new REST APIs which were added in Folsom. Assume we have provided a mechanism (e.g. a config option) to make that possible. That means that we don't need a release of client libs with support for those APIs until folsom-3. Even in this constraining setup, you keep the user vs. developer dichotomy: you want developers and early testers to actually play with your new REST APIs... so you still need two channels: developer and supported. I think Monty's solution is a way to support both in the same channel, as everyone wants to use PyPI and it supports only a single channel. My understanding is that you resist it because you think it will break during the development cycle, so releasing only when APIs to be ready and official is safer. What about mandating that new REST APIs get exposed in the client using a experimental or non-final-yet flag ? And when they get official (folsom-3 ?) we expose them to all users ? Then you could have both stable and experimental APIs live happily together... in the same PyPI channel and in the same stream of releases. [...] e.g. I could see us doing this: - When we hit essex-3, we did the first release of the client libs which supported new REST APIs added in Essex - We continue adding bugfixes and new client lib features based on the essex APIs to the master branch of the client project - At Essex release time, we do another release of the client libs ... purely to co-ordinate with the project release - We continue doing releases as the need arises - At some point, new REST APIs are added in Folsom and we want the client lib to support it. At that point, we branch off an 'essex' branch of the lib. Support for those new REST APIs goes into master, everything else goes into both. - We continue doing releases from the essex branch Alternatively, the new API could be developed in a next branch and merged in around folsom-3. I think that would be more consistent with how we do things, and you don't have to switch branches you release from. - When we hit folsom-3, the REST APIs freeze and we do our first release containing support for the new REST APIs added in Folsom The trick here is that your new REST APIs only get exposed in a published version of the client library at folsom-3, which is quite late. That would work if only end users consumed the library, and all end users would run on final releases. But our projects also use the libs to communicate between themselves. If API changes all land in F3, when does Horizon work to integrate the new featureset ? They actually need to work with experimental APIs available in the client libs as early as possible to integrate the new featureset in time for final release... So I think I still prefer the single
Re: [Openstack] HVM + Xen Hypervisor via libvirt possible?
On 06/22/2012 02:04 PM, Li Wang wrote: We use CentOS in production environment. There is the Zeus project, right? I'll do some research on it Well, if you use CentOS, then why not using XCP, the open source appliance, from Citrix? It's CentOS based... I heard about the Zeus project, but I'm not sure how fare they are with this. I'm Cc-ing Mike and Jon, upstream for XCP, maybe they will be able to tell how far they've gone, and if it's already in Fedora. Thomas ___ 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] HVM + Xen Hypervisor via libvirt possible?
On 06/22/2012 05:56 PM, Daniel P. Berrange wrote: 3. or some good reasons to migrate from Xen to KVM? I'd favour KVM for a variety of reasons, but lets not turn this into a bikeshed discussion about which is best ;-P Let's put it this way: if you want to run with libvirt and Openstack, then yes, you should probably switch to KVM. But if you want to keep Xen, then you should probably switch to XCP. Thomas ___ 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 with DevStack
Hi,
I developed those changes with Ubuntu 12.04, so it should be OK.
I think that error means you don't have anything set in HOST_IP (i.e. IP
address of the XenServer) at the point in install_os_domU.sh:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/install_os_domU.sh#L257
The HOST_IP should have been setup by this (or whatever is in your localrc
file):
https://github.com/openstack-dev/devstack/blob/master/tools/xen/install_os_domU.sh#L168
Have you got the networking working correctly on your XenServer on Ubuntu?
Ifconfig should list xenbr0 having an appropriate IP address.
Hope that helps,
John
From: r...@midokura.jp [mailto:r...@midokura.jp] On Behalf Of Ishimoto, Ryu
Sent: 22 June 2012 3:11
To: John Garbutt
Cc: Takaaki Suzuki; openstack@lists.launchpad.net
Subject: Re: [Openstack] XCP with DevStack
Hi John,
Thanks for all your help. I have a question regarding your patch to make
devstack work with XCP (https://review.openstack.org/#/c/7673/). Does this
patch apply to devstack with XCP 1.3.2(the package version that comes with
Ubuntu 12.04?) We verified that devstack does install without a problem with
XCP 1.5 but we are still having issues with 1.3.2.
After looking into this issue a bit further, we noticed that the problem occurs
during the OpenStack DomU VM installation process. The preseed file location
is incorrect ('http:///devstackubuntupressed.cfg') even though this file was
copied to the correct location by the script prior to the installation step.
Due to our lack of knowledge in this matter, all we could manage was to
hard-code the proper URL in the kernel parameter set in
'tools/xen/scripts/install-os-vpx.sh' script. To be more precise, we added the
hard-coded URL in the generation of kernel parameters in 'set_kernel_params()'
method, and this successfully got us through the installation process.
Although this temporary hack got us moving forward, we would love to get some
inputs on how we can actually fix this.
We would really like devstack to work with 1.3, so if you or anyone could point
us in the right direction, we would be more than happy to help out on this.
Thanks in advance!
Cheers,
Ryu
On Fri, Jun 1, 2012 at 9:18 PM, John Garbutt
john.garb...@citrix.commailto:john.garb...@citrix.com wrote:
Hi,
I assume you are using xcp-xapi in Ubuntu. First of all, is it all running
correctly (i.e. xe vm-list is returning correctly):
http://wiki.xen.org/wiki/Using_XCP_-_preparing_the_toolstack
It turns out the current DevStack will not work with this, but I have pushed
some changes to support it:
https://review.openstack.org/#/c/7673/
The networking configuration can be a little confusing, there is an overview on
the wiki:
http://wiki.openstack.org/XenServer/NetworkingFlags
The DevStack flags are there to configure each of the VIFs on the DomU, the
defaults can be seen here:
https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc
If things are still un clear, do ask some more questions.
I have plans to document this exact setup in some detail in the near future.
Feel free to add to these docs on the wiki.
Thanks,
John
-Original Message-
From:
openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.netmailto:eu.citrix@lists.launchpad.net
[mailto:openstack-bounces+john.garbuttmailto:openstack-bounces%2Bjohn.garbutt=eu.citrix@lists.launchpad.netmailto:eu.citrix@lists.launchpad.net]
On Behalf Of Takaaki Suzuki
Sent: 01 June 2012 10:12
To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Cc: dev
Subject: [Openstack] XCP with DevStack
Hi all.
I need your knowledge. :)
I prepared XCP plus OpenvSwitch with Ubuntu precise on own environment.
And I want to prepare DevStack for XCP(Ubuntu).
https://github.com/openstack-
dev/devstack/blob/master/tools/xen/README.md
I don't understand localrc network settings part.
The script launched DevStackOSDomU. after that network settings part failed.
If you know any other DevStack/OpenStack for XCP installation or
configuration document.
Please let me know.
Thanks!
--
Midokura Japan
Suzuki
___
Mailing list: https://launchpad.net/~openstack
Post to :
openstack@lists.launchpad.netmailto: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] HVM + Xen Hypervisor via libvirt possible?
I have asked some of the Xen.org guys if they know anyone who has time to fix this. I will let you know if I have any luck. But yes, the XenAPI driver (talking to XCP) is probably the best way forward with Xen right now. If there are any blockers making that work, I am happy to help were I can. Cheers, John -Original Message- From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Thomas Goirand Sent: 22 June 2012 2:40 Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] HVM + Xen Hypervisor via libvirt possible? On 06/22/2012 05:56 PM, Daniel P. Berrange wrote: 3. or some good reasons to migrate from Xen to KVM? I'd favour KVM for a variety of reasons, but lets not turn this into a bikeshed discussion about which is best ;-P Let's put it this way: if you want to run with libvirt and Openstack, then yes, you should probably switch to KVM. But if you want to keep Xen, then you should probably switch to XCP. Thomas ___ 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] How to improve our bug triaging ?
On 21/06/2012, Thierry Carrez thie...@openstack.org wrote: * Should we just encourage more people to do BugTriaging ? Sounds like the obvious solution. However to do good triaging, you need bug supervisors rights, and when I proposed to open that team (the nova-bugs team) to anyone, there was resistance. Maybe it makes sense for Nova though... or maybe someone should actively manage that team and grant rights to any known triager that needs them. I don't think an open team is required, but actually approving people to it would help. I went looking the right team to join the other day after seeing some recent bugs that I'd be able to confirm. Saw there were six people pending approval, including Chuck, who's clearly qualified to do bug triage, so gave up on the idea. There's really no reason not to approve everyone who requests membership right away, can always kick them out if they prove to be clueless. Martin ___ 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] Essex multi network,instance can't get correct route
hi, i got essex, ___ 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] multi network,instance can't get route correct
HI: I get essex(flatdhcp), i have mulit network in my instance, create network like this: #nova-manage network create --label=public --fixed_range_v4=10.0.0.0/24--network_size=255 --bridge=public --bridge_interface=em2 --multi_host=T #nova-manage network create --label=private --fixed_range_v4=10.0.1.0/24--network_size=255 --bridge=private --bridge_interface=em3 --multi_host=T netwrok list # nova-manage network list id IPv4 IPv6 start address DNS1 DNS2 VlanID project uuid 1 10.0.0.0/24 None 10.0.0.2 8.8.4.4 None None None b66ea728-9ac5-42ba-b666-82adc1dad37f 2 10.0.1.0/24 None 10.0.1.2 8.8.4.4 None None None 3b4aecd6-5541-4dda-bd45-d21c4a0701b3 like this,the instance can work correct, the instance default route to public is 10.0.1.*（i hope the default route is 10.0.0.*） but when i assignation an floating ip to the instance,the floating ip assignation to ip (10.0.0.*) of the instance not 10.0.1.*,so the instance's network has wrong,' so, i get this,use_single_default_gateway=True in nova.conf, in this situation,sometime the instance can't get route,the instance's network can't work. like this: [image: 内嵌图片 6] it shoud be like this: [image: 内嵌图片 7] is there anyone can help me? thank very much :) image.pngimage.png___ 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] [metering] gating test blockade broken
I collected all of the individual patches for fixes to nova.cfg, nova.rpc, and PEP-8 changes to create one mega-patch, which has now been applied [1]. The primary source of the problem was the move of nova.rpc to openstack.common, but the upgrade of pep8 to 1.3.1 also introduced test failures. The former were resolved by updating our code to also use openstack.common.rpc and the pep8 issue was taken care of by configuring our tests to use version 1.1 in the tox.ini file. The end result is that HEAD works and the tests pass, so we can resume normal development now. Doug [1] https://review.stackforge.org/#/c/221/ ___ 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] AttributeError: virDomain instance has no attribute 'reset'
That's pretty much what I understood based on a conversation with Vish on IRC the other day. It's caused me to pretty much give up on 11.10 for modern OpenStack (Nova) installs. -jay On 06/22/2012 01:23 AM, Vaze, Mandar wrote: Found this bug (albeit for Fedora 16) https://bugs.launchpad.net/nova/+bug/1011863 https://bugs.launchpad.net/nova/+bug/1011863 I’ve updated the bug with my details Does that mean Folsom won’t be supported on Ubuntu 11.10 ? -Mandar *From:*openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] *On Behalf Of *Vaze, Mandar *Sent:* Friday, June 22, 2012 9:41 AM *To:* Vishvananda Ishaya *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] AttributeError: virDomain instance has no attribute 'reset' Vish, I’m running on Ubuntu 11.10 (GNU/Linux 3.0.0-12-server x86_64) When I tried to upgrade I got the following message libvirt-bin is already the newest version. libvirt0 is already the newest version. python-libvirt is already the newest version. Which package should I upgrade/install ? Thanks, -Mandar *From:*Vishvananda Ishaya [mailto:vishvana...@gmail.com] mailto:[mailto:vishvana...@gmail.com] *Sent:* Friday, June 22, 2012 12:13 AM *To:* Vaze, Mandar *Subject:* Re: AttributeError: virDomain instance has no attribute 'reset' the reset command was only recently added to libvirt, so your version is probably just to old. We have discussed adding a fallback of shutting down and restarting the domain if reset is not defined, but no one has implemented it yet. Vish On Jun 21, 2012, at 5:56 AM, Vaze, Mandar wrote: Vish, I recently merged my code with master after a few weeks. Now I’m getting the error mentioned in the subject line during reboot. I looked at the history and this change is done in the following commit by you. https://github.com/openstack/nova/commit/ae878fc8b9761d099a4145617e4a48cbeb390623 I also realized that you have defined reset() method in fakelibvirt for testing - so may be tests pass OK. I’m using libvirt_type=kvm Do I need to update any library (python or otherwise) for this change ? Any other suggestions to troubleshoot this ? Thanks, -Mandar Here is relevant snippet from my debug session : /opt/stack/nova/nova/virt/libvirt/connection.py(847)_hard_reboot() - virt_dom.reset(0) (Pdb) dir(virt_dom) ['ID', 'OSType', 'UUID', 'UUIDString', 'XMLDesc', '__del__', '__doc__', '__init__', '__module__', '_conn', '_o', 'abortJob', 'attachDevice', 'attachDeviceFlags', 'autostart', 'blkioParameters', 'blockInfo', 'blockPeek', 'blockStats', 'connect', 'coreDump', 'create', 'createWithFlags', 'destroy', 'detachDevice', 'detachDeviceFlags', 'hasCurrentSnapshot', 'hasManagedSaveImage', 'info', 'injectNMI', 'interfaceStats', 'isActive', 'isPersistent', 'isUpdated', 'jobInfo', 'managedSave', 'managedSaveRemove', 'maxMemory', 'maxVcpus', 'memoryParameters', 'memoryPeek', 'memoryStats', 'migrate', 'migrate2', 'migrateSetMaxDowntime', 'migrateSetMaxSpeed', 'migrateToURI', 'migrateToURI2', 'name', 'openConsole', 'pinVcpu', 'reboot', 'resume', 'revertToSnapshot', 'save', 'schedulerParameters', 'schedulerParametersFlags', 'schedulerType', 'screenshot', 'setAutostart', 'setBlkioParameters', 'setMaxMemory', 'setMemory', 'setMemoryFlags', 'setMemoryParameters', 'setSchedulerParameters', 'setSchedulerParametersFlags', 'setVcpus', 'setVcpusFlags', 'shutdown', 'snapshotCreateXML', 'snapshotCurrent', 'snapshotListNames', 'snapshotLookupByName', 'snapshotNum', 'state', 'suspend', 'undefine', 'updateDeviceFlags', 'vcpus', 'vcpusFlags'] (Pdb) type( virt_dom) type 'instance' (Pdb) type(virt_dom) type 'instance' (Pdb) n AttributeError: virDomain instance has no attribute 'reset' __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ 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:
[Openstack] nova volume attachment issue
Hello, I am able to create a volume (Essex released version). But, I am not able to attach it to an instance. I am using the following in nova.conf: --iscsi_ip_address=10.1.2.0 --iscsi_helper=tgtadm But, still, I am getting iscsiadm: No portal found error in nova-compute.log. I have open-iscsi, iscsitarget and tgt started. In kern.log, I see this error all the time: ISCSI Initiator (TCP/IP) connection3:0: detected conn error (1020) Any clue is appreciated Thanks, jsb___ 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] Instance spawning issues - Index out of range exception
Hi, while trying a launch an instance, i encounter the following error (from nova-compute log). Could somebody please shed some light on this? 2012-06-22 21:17:52 ERROR nova.rpc.amqp [req-59553bb4-d3c8-4cdf-b7e2-0c4fa5d54027 036b5b0be29c42d89a096c695ffa02e0 e6aa7a13922f422c94bed4455833df58] Exception during message handling 2012-06-22 21:17:52 TRACE nova.rpc.amqp Traceback (most recent call last): 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py, line 252, in _process_data 2012-06-22 21:17:52 TRACE nova.rpc.amqp rval = node_func(context=ctxt, **node_args) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 114, in wrapped 2012-06-22 21:17:52 TRACE nova.rpc.amqp return f(*args, **kw) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 177, in decorated_function 2012-06-22 21:17:52 TRACE nova.rpc.amqp sys.exc_info()) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-06-22 21:17:52 TRACE nova.rpc.amqp self.gen.next() 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 171, in decorated_function 2012-06-22 21:17:52 TRACE nova.rpc.amqp return function(self, context, instance_uuid, *args, **kwargs) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 651, in run_instance 2012-06-22 21:17:52 TRACE nova.rpc.amqp do_run_instance() 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/utils.py, line 945, in inner 2012-06-22 21:17:52 TRACE nova.rpc.amqp retval = f(*args, **kwargs) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 650, in do_run_instance 2012-06-22 21:17:52 TRACE nova.rpc.amqp self._run_instance(context, instance_uuid, **kwargs) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 451, in _run_instance 2012-06-22 21:17:52 TRACE nova.rpc.amqp self._set_instance_error_state(context, instance_uuid) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-06-22 21:17:52 TRACE nova.rpc.amqp self.gen.next() 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 432, in _run_instance 2012-06-22 21:17:52 TRACE nova.rpc.amqp self._deallocate_network(context, instance) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2012-06-22 21:17:52 TRACE nova.rpc.amqp self.gen.next() 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 429, in _run_instance 2012-06-22 21:17:52 TRACE nova.rpc.amqp injected_files, admin_password) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 592, in _spawn 2012-06-22 21:17:52 TRACE nova.rpc.amqp self._legacy_nw_info(network_info), block_device_info) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/exception.py, line 114, in wrapped 2012-06-22 21:17:52 TRACE nova.rpc.amqp return f(*args, **kw) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 916, in spawn 2012-06-22 21:17:52 TRACE nova.rpc.amqp block_device_info=block_device_info) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1525, in to_xml 2012-06-22 21:17:52 TRACE nova.rpc.amqp rescue, block_device_info) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1408, in _prepare_xml_info 2012-06-22 21:17:52 TRACE nova.rpc.amqp nics.append(self.vif_driver.plug(instance, network, mapping)) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py, line 99, in plug 2012-06-22 21:17:52 TRACE nova.rpc.amqp return self._get_configurations(network, mapping) 2012-06-22 21:17:52 TRACE nova.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py, line 69, in _get_configurations 2012-06-22 21:17:52 TRACE nova.rpc.amqp 'ip_address': mapping['ips'][0]['ip'], 2012-06-22 21:17:52 TRACE nova.rpc.amqp IndexError: list index out of range ___ 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] Tihomir Trifonov added to horizon-core
Welcome Tihomir to horizon-core! Thanks for all the great contributions in the past months! Devin ___ 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] Pointer to the Image Service draft
Hi, Could someone post the pointer to the draft of Image Service for Folsom? Thanks Vibhu ___ 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 Community Newsletter -- June 22
Highlights of the week OpenStack Summit coming October 15th-19th to San Diego, CA http://www.openstack.org/blog/2012/06/openstack-summit-coming-october-15th-19th-to-san-diego-ca/ Mark your calendar October 15th-19th in San Diego, California with more of everything: 4 days of Design Summit, 2 full days of conference content, more devops time, more workshops. One registration system./No invitation required for Design Summit tracks and no cap /(limited only by facility capacity). One name for the weeks' activities: OpenStack Summit with designated rooms for Design Summit various Conference topics. More details http://www.openstack.org/blog/2012/06/openstack-summit-coming-october-15th-19th-to-san-diego-ca/. OpenStack Nova, Glance, Keystone and Horizon 2012.1.1 released http://markmail.org/message/hbki7eweg4qb2o33 The bugfixes contained in this release were backported from the development branches into a stable branch http://wiki.openstack.org/StableBranch. The release is intended to be a relatively risk free update with no intentional regressions or API changes. Performance metrics http://markmail.org/message/tv63o6c2ozb7fg6d An interesting discussion on how to do performance analysis on OpenStack. *Cinder* status update http://markmail.org/message/cxw5xm7qmvh6t3kf Cinder is the new project intended to separate block storage out of Nova and provide it via it's own service. The goal is to have a functional replacement for Nova-Volumes by Folsom 2. What to expect and what's in progress in the status update http://markmail.org/message/cxw5xm7qmvh6t3kf by John Griffith. **Thoughts**on**client**library***releasing* http://markmail.org/message/6wffnfnhliswnrjh The community is trying to figure out how to release client libraries. No consensus yet and therefore no decision: your opinion is appreciated. Upcoming Events * Australian OpenStack User Group http://aosug.openstack.org.au/events/62345642/ Jun 26, 2012 - Brisbane, Australia Details http://aosug.openstack.org.au/events/62345642/ * Australian OpenStack User Group - Sydney Meetup http://aosug.openstack.org.au/events/67053762/ Jun 28, 2012 - Sydney, Australia Details http://aosug.openstack.org.au/events/67053762/ * Juju Works Like a Charm http://www.meetup.com/OpenStack-LA/events/67004572/ Jun 28, 2012 - Los Angeles, CA Details http://www.meetup.com/OpenStack-LA/events/67004572/ * OSCON http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf Jul 16 - 20, 2012 - Portland, OR Sponsor http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf * 13th International Free Software Forum - OpenStack Track http://wiki.openstack.org/FISL13 Jul 25 - 28, 2012 - Porto Alegre, Brazil Coordination http://wiki.openstack.org/FISL13 * 2012 OpenStack APEC Conference http://openstack.csdn.net/index.html Aug 10 - 11, 2012 - Bejing+Shanghai, China Details http://openstack.csdn.net/index.html Other news * OpenStack Project 2012-06-18 meeting summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-19-21.02.html and full log http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-19-21.02.log.html Welcome new contributors Celebrating the first patches submitted this week by: * Martin Packman, Canonical * Sascha Peilicke, Suse /The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment./ ___ 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] Tihomir Trifonov added to horizon-core
Welcome indeed! You have been doing great work and we all appreciate it! John Postlethwait Nebula, Inc. 206-999-4492 On Friday, June 22, 2012 at 1:45 PM, Devin Carlen wrote: Welcome Tihomir to horizon-core! Thanks for all the great contributions in the past months! Devin ___ 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
Re: [Openstack] Thoughts on client library releasing
On Fri, Jun 22, 2012 at 6:00 AM, Thierry Carrez thie...@openstack.org wrote: Mark McLoughlin wrote: That actually goes to something I'm not aware of us - the project - having spent much time discussing. We do twice yearly releases of our collection of software, but there are public cloud providers which want to essentially do continuous deployment from our development branch. To what extent is that a reasonable thing for the project to support? If we had a shorter release cycle, would the cloud providers switch their deployments from continuous to the releases? If not, can the project and cloud providers better co-ordinate somehow? That's a discussion we had before the Essex release, when we were looking into releasing more often (every 5-8 weeks) instead of every 6 months. What makes a release ?. After all, you will never prevent people from using milestones or random snapshots, and we should strive to make master always installable and working. So why do releases ? And what should be the cadence ? To me, releases are synchronization points. We have to have a cycle with a timeframe where development slows down at one point to let QA, documentation, integration testing and translation catch-up. A release is a point in time where the stars are all aligned. The release cycle is there to help us achieve that regularly. Those synchronization points also serve to maintain stable branches and coordinate with distros (it's no mystery that we are cadenced in a way that makes us friendly with time-based distros). Currently we can only achieve that star-aligning process every 6 months, but I hope that we'll be able to do releases more often in the future. That said, us releasing every 6 months doesn't mean we should prevent users from being able to pick a version and run with it. In particular, I think our client library release scheme shouldn't actively go against that by synchronizing too much with the core release schedule. Well said, as have all the contributions to the discussion. Right now Piston Cloud maintains our own clients based on the full packages of Diablo with fixes from newer releases -- like being able to installing all of glance using pip to get to the client libraries. I can't wait for the releases of the glance and swift client libraries. https://github.com/openstack/python-swiftclient https://github.com/openstack/python-glanceclient If not their own projects within launchpad for client library will severe issues and lengthening resolved bug lists have the visibility for a natural release management? What tools will support the client libraries having good cadence? On the other hand separation is artificial when it's the same technical owners and the client libraries evolve hand-in-hand with the servers. My recommendation -- although being their own Launchpad projects makes many of the answers for release management more obvious and far easier -- would be to get a baseline of quality client libraries, and leave them fully embedded in the servers' projects, versioned the same as the servers, until demonstrated that isn't working, and re-evaluation on a bug backlog by bug backlog basis. Thank you, -- @lloyddewolf http://www.pistoncloud.com/ ___ 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] Additional compute node network issues - rpc timeout
Thanks for your reply Chris. I checked both and nither firewall rules are in the war nor there is the control_exchange in nova.conf. Just to confirm: for a single host network setup, nova-network is supposed to be setup only on the cloud controller and compute nodes should only run nova-compute. Is this correct? On Fri, Jun 22, 2012 at 10:36 PM, Chris Wright chr...@sous-sol.org wrote: * Derek Eli (derek.el...@gmail.com) wrote: I am having issues with spawning a VM which gets scheduled to a non cloud controller node, running nova-compute only. It fails with a nerwork configuration error. Looking at logs reveals that it was an rpc timeout error. Further investigations (nova-network logs) reveal that the nova-network tried to send a message to network.nova2 queue and it never received a response and times out, hence, the compute node never receives a reply and times out. doing a rabbitmqctl shows no queue named network.nova2. firewall rules on cloud controller node in the way? nova.conf not matching (i.e. one has control_exchange=nova2 in it)? ___ 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 doesn't release ips when terminating instances
When an instance terminates, the allocated field in the fixed_ips is set to 0, but the instance_id field remains set. Once all the addresses are in this state, new instances fail to start, and the following error is logged by nova-network: 2012-06-22 23:09:34 ERROR nova.rpc.amqp [req-1fea207d-cd65-4375-9a04-17ba1ab92e3e 22bb8e502d3944ad953e72fc77879c2f 76e2726cacca4be0bde6d8840f88c136] Returning exception Zero fixed ips available. to caller Which shows up in compute.log as: 2012-06-22 23:08:35 TRACE nova.rpc.amqp RemoteError: Remote error: NoMoreFixedIps Zero fixed ips available. Manually set instance_id=NULL in the fixed_ips table allows things to work again. We're running the 2012.1.1 release and we're using the FlatDHCP model. Is this a known bug? Thanks, -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist| http://ac.seas.harvard.edu/ Academic Computing | http://code.seas.harvard.edu/ Harvard School of Engineering and Applied Sciences | ___ 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 volume attachment issue
On Fri, Jun 22, 2012 at 11:18 AM, jsb jay_...@yahoo.com wrote: Hello, I am able to create a volume (Essex released version). But, I am not able to attach it to an instance. I am using the following in nova.conf: --iscsi_ip_address=10.1.2.0 Is that correct? shouldn't it be like 10.1.2.* --iscsi_helper=tgtadm But, still, I am getting iscsiadm: No portal found error in nova-compute.log. What about if you try to discovery the targets directly? do you know the host the volume is on? iscsiadm -m discovery -t st -p ip_of_host_where_volume_is I have open-iscsi, iscsitarget and tgt started. You probably don't want iscsitarget tgt - if you're nova.conf is set to tgt - try to purge iscsitarget the dkms. Good luck! -clayg ___ 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-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
On Jun 20, 2012, at 3:18 AM, Thierry Carrez wrote: The current PPB had a discussion yesterday on the bylaws for the Foundation Technical Committee (TC), mainly around whether PTLs should get reserved seats on the TC. I would like to summarize the options and extend the discussion to the Foundation ML for wider input. My initial proposal [1] was to have a directly-elected committee (9 seats, all elected by technical contributors to OpenStack projects as a whole, in the same way each PTL is elected by the contributors of each project). Some members of the current PPB suggested that we should keep reserved seats for the core projects PTLs, and only directly elect 5 extra seats (TC = PTLs+5 seats, 11 seats for the original setup). The main argument against the directly-elected model is that you might run in a situation where a PTL of a smaller project does not get a vote on the TC, especially as the number of core projects grows. IMHO the potential drawbacks of the PTLs+5 model are: * Committee bloat as we grow our number of projects * Skewed election power for smaller projects members * Projects have different sizes but PTL votes carry the same weight * Have fear of dilution play a role when deciding new core inclusion * Have fear of bloat play a role when deciding new core inclusion * Have fear of bloat or dilution discourage further core project splits In the end, the result should not be very different: I expect most PTLs to be elected anyway since the voters are the same people that elected them in each project. And the use of proportional representation option in the Schulze algorithm specifically ensures that smaller groups get a fair representation and cannot be displaced by a majority of voters. Additionally, PTLs have to accept that some TC decisions will not go their way: having one vote doesn't magically ensure that all decisions will go your way, especially in a large committee. So I think the key question is whether the TC should be considered the college of the PTLs + a number of extra elected people, or whoever the technical contributors elect for the job, who may or may not also be PTLs. One thing to remember is that the Technical Committee will define what OpenStack is technically, which goes beyond just core projects. It influences library projects, gating projects, plug-ins etc. I much prefer the PTL+5 model. 1) the PTL is already an elected position 2) I think it would be foolish of us to create a structure where technical decisions that are supposed to be made across all the projects *could* be voted on and set by a different group of people than the leads of those projects. 3) I think your fear of bloat of the group is not a valid concern - the appointed positions dissipate, and the core projects growth has been minimal, mostly fragmenting of Nova into it's relevant constituent parts. The core of why I'm so opposed to a separately elected model for the technical committee is that it explicitly forms two groups that have overlapping accountability, but which may not be the same people. In the best of all worlds, this would be a non-issue, but it is the height of foolishness to create a structure with a division of groups and not a corresponding division of accountability. To me, this is suggesting that we create a ticking time bomb of technical division within the foundation from the very start. Thierry has made the argument that It likely would be all the PTLs, but that just begs of the question of why even set up a process that could fragment and induce confusion the decision process over technical decisions. - joe ___ 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
Re: [Openstack-poc] [Openstack] Thoughts on client library releasing
How do these plans fit with the idea of creating a unified client library (either as one package or several, based on a common core)? On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor mord...@inaugust.com wrote: We're trying to figure out how we release client libraries. We're really close - but there are some sticking points. First of all, things that don't really have dissent (with reasoning) - We should release client libs to PyPI Client libs are for use in other python things, so they should be able to be listed as dependencies. Additionally, proper releases to PyPI will make our cross project depends work more sensibly - They should not necessarily be tied to server releases There could be a whole version of the server which sees no needed changes in the client. Alternately, there could be new upcoming server features which need to go into a released version of the library even before the server is released. - They should not be versioned with the server See above. - Releases of client libs should support all published versions of server APIs An end user wants to talk to his openstack cloud - not necessarily to his Essex cloud or his Folsom cloud. That user may also have accounts on multiple providers, and would like to be able to write one program to interact with all of them - if the user needed the folsom version of the client lib to talk to the folsom cloud and the essex version to talk to the essex cloud, his life is very hard. However, if he can grab the latest client lib and it will talk to both folsom and essex, then he will be happy. There are three major points where there is a lack of clear agreement. Here they are, along with suggestions for what we do about them. - need for official stable branches I would like to defer on this until such a time as we actually need it, rather than doing the engineering for in case we need it. But first, I'd like to define we, and that is that we are OpenStack as an upstream. As a project, we are at the moment probably the single friendliest project for the distros in the history of software. But that's not really our job. Most people out there writing libraries do not have multiple parallel releases of those libraries - they have the stable library, and then they release a new one, and people either upgrade their apps to use the new lib or they don't. One of the reasons this has been brought up as a need is to allow for drastic re-writes of a library. I'll talk about that in a second, but I think that is a thing that needs to have allowances for happening. So the model that keystone-lite used - create an experimental branch for the new work, eventually propose that it becomes the new master - seems like a better fit for the drastic rewrite scenario than copying the stable/* model from the server projects, because I think the most common thing will be that library changes are evolutionary, and having two mildly different branches that both represent something that's actually pretty much stable will just be more confusing than helpful. That being said - at such a time that there is actually a pain-point or a specific need for a stable branch, creating branches is fairly easy ... but I think once we have an actual burning need for such a thing, it will make it easier for us to look at models of how we'll use it. - API or major-rewrite-driven versioning scheme I was wondering why bcwaldon and I were missing each other so strongly in the channel the other day when we were discussing this, and then I realized that it's because we have one word API that's getting overloaded for a couple of different meanings - and also that I was being vague in my usage of the word. So to clarify, a client library has: * programming level code APIs * supported server REST APIs So I back off everything I said about tying client libs version to server REST API support. Brian was right, I was wrong. The thing that's more important here is that the version should indicate programmer contract, and if it that is changed in a breaking manner, the major number should bump. If we combine that with the point from above that our libraries should always support the existing server REST APIs, then I think we can just purely have statements like support for compute v3 can be found in 2.7.8 and later and people will likely be fine, because it will map easily to the idea just grab the latest lib and you should be able to talk to the latest server Yea? So in that case, the client libs versions are purely whatever they are right now, and we'll increase them moving forward using normal library version thoughts. - room for deprecating old APIs The above then leads us to wanting to know what we do about supported server REST APIs over time, especially since I keep making sweeping statements about should support all available server versions ... How about this as a straw man: Since we're planning on
Re: [Openstack-poc] [Openstack] Thoughts on client library releasing
On Mon, Jun 18, 2012 at 5:56 PM, Monty Taylor mord...@inaugust.com wrote: On 06/18/2012 02:25 PM, Doug Hellmann wrote: How do these plans fit with the idea of creating a unified client library (either as one package or several, based on a common core)? They are kind of orthogonal. At the point where python-openstackclient is ready for release, we'd likely want to manage it the same way. That makes sense. I didn't know if the unification work would be a trigger for the major rewrite branching and versioning issues that you mentioned. On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: We're trying to figure out how we release client libraries. We're really close - but there are some sticking points. First of all, things that don't really have dissent (with reasoning) - We should release client libs to PyPI Client libs are for use in other python things, so they should be able to be listed as dependencies. Additionally, proper releases to PyPI will make our cross project depends work more sensibly - They should not necessarily be tied to server releases There could be a whole version of the server which sees no needed changes in the client. Alternately, there could be new upcoming server features which need to go into a released version of the library even before the server is released. - They should not be versioned with the server See above. - Releases of client libs should support all published versions of server APIs An end user wants to talk to his openstack cloud - not necessarily to his Essex cloud or his Folsom cloud. That user may also have accounts on multiple providers, and would like to be able to write one program to interact with all of them - if the user needed the folsom version of the client lib to talk to the folsom cloud and the essex version to talk to the essex cloud, his life is very hard. However, if he can grab the latest client lib and it will talk to both folsom and essex, then he will be happy. There are three major points where there is a lack of clear agreement. Here they are, along with suggestions for what we do about them. - need for official stable branches I would like to defer on this until such a time as we actually need it, rather than doing the engineering for in case we need it. But first, I'd like to define we, and that is that we are OpenStack as an upstream. As a project, we are at the moment probably the single friendliest project for the distros in the history of software. But that's not really our job. Most people out there writing libraries do not have multiple parallel releases of those libraries - they have the stable library, and then they release a new one, and people either upgrade their apps to use the new lib or they don't. One of the reasons this has been brought up as a need is to allow for drastic re-writes of a library. I'll talk about that in a second, but I think that is a thing that needs to have allowances for happening. So the model that keystone-lite used - create an experimental branch for the new work, eventually propose that it becomes the new master - seems like a better fit for the drastic rewrite scenario than copying the stable/* model from the server projects, because I think the most common thing will be that library changes are evolutionary, and having two mildly different branches that both represent something that's actually pretty much stable will just be more confusing than helpful. That being said - at such a time that there is actually a pain-point or a specific need for a stable branch, creating branches is fairly easy ... but I think once we have an actual burning need for such a thing, it will make it easier for us to look at models of how we'll use it. - API or major-rewrite-driven versioning scheme I was wondering why bcwaldon and I were missing each other so strongly in the channel the other day when we were discussing this, and then I realized that it's because we have one word API that's getting overloaded for a couple of different meanings - and also that I was being vague in my usage of the word. So to clarify, a client library has: * programming level code APIs * supported server REST APIs So I back off everything I said about tying client libs version to server REST API support. Brian was right, I was wrong. The thing that's more important here is that the version should indicate programmer contract, and if it that is changed in a breaking manner, the major number should bump. If we combine that with the
Re: [Openstack-poc] [Openstack] Thoughts on client library releasing
Big +1 for automated tagging and releasing (sounds like we're managing wildlife...) from Jenkins! - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Monday, June 18, 2012 3:00 PM To: Joe Heck Cc: openstack-poc@lists.launchpad.net; openst...@lists.launchpad.net Subject: Re: [Openstack] [Openstack-poc] Thoughts on client library releasing On 06/18/2012 02:26 PM, Joe Heck wrote: Monty - Thierry stated it as an assumption last PPB meeting, but I'd like it to be explicit that we have at least a tag on each client library release that we make so that it's possible to distribute a version of the clients. +1000 I didn't want to get too far into implementation details, but the way I'd really like to see this work for the client libs is that releases are actually trigger via jenkins by tags on the repo - so there would literally be no way to release something _without_ a tag. I've got a POC patch to do the tag-based-versioning here: https://review.openstack.org/#/c/8427/ We need to get (aiui) one thing landed to zuul so that we can appropriately trigger on tag events... but that's the plan in my brain hole. On Jun 18, 2012, at 2:11 PM, Monty Taylor wrote: We're trying to figure out how we release client libraries. We're really close - but there are some sticking points. First of all, things that don't really have dissent (with reasoning) - We should release client libs to PyPI Client libs are for use in other python things, so they should be able to be listed as dependencies. Additionally, proper releases to PyPI will make our cross project depends work more sensibly - They should not necessarily be tied to server releases There could be a whole version of the server which sees no needed changes in the client. Alternately, there could be new upcoming server features which need to go into a released version of the library even before the server is released. - They should not be versioned with the server See above. - Releases of client libs should support all published versions of server APIs An end user wants to talk to his openstack cloud - not necessarily to his Essex cloud or his Folsom cloud. That user may also have accounts on multiple providers, and would like to be able to write one program to interact with all of them - if the user needed the folsom version of the client lib to talk to the folsom cloud and the essex version to talk to the essex cloud, his life is very hard. However, if he can grab the latest client lib and it will talk to both folsom and essex, then he will be happy. There are three major points where there is a lack of clear agreement. Here they are, along with suggestions for what we do about them. - need for official stable branches I would like to defer on this until such a time as we actually need it, rather than doing the engineering for in case we need it. But first, I'd like to define we, and that is that we are OpenStack as an upstream. As a project, we are at the moment probably the single friendliest project for the distros in the history of software. But that's not really our job. Most people out there writing libraries do not have multiple parallel releases of those libraries - they have the stable library, and then they release a new one, and people either upgrade their apps to use the new lib or they don't. One of the reasons this has been brought up as a need is to allow for drastic re-writes of a library. I'll talk about that in a second, but I think that is a thing that needs to have allowances for happening. So the model that keystone-lite used - create an experimental branch for the new work, eventually propose that it becomes the new master - seems like a better fit for the drastic rewrite scenario than copying the stable/* model from the server projects, because I think the most common thing will be that library changes are evolutionary, and having two mildly different branches that both represent something that's actually pretty much stable will just be more confusing than helpful. That being said - at such a time that there is actually a pain-point or a specific need for a stable branch, creating branches is fairly easy ... but I think once we have an actual burning need for such a thing, it will make it easier for us to look at models of how we'll use it. - API or major-rewrite-driven versioning scheme I was wondering why bcwaldon and I were missing each other so strongly in the channel the other day when we were discussing this, and then I realized that it's because we have one word API that's getting overloaded for a couple of different meanings - and also that I was being vague in my usage of
Re: [Openstack-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
On Wed, Jun 20, 2012 at 8:02 AM, Mark McLoughlin mar...@redhat.com wrote: On Wed, 2012-06-20 at 12:18 +0200, Thierry Carrez wrote: [..] So I think the key question is whether the TC should be considered the college of the PTLs + a number of extra elected people, or whoever the technical contributors elect for the job, who may or may not also be PTLs. [..] Nice summary. Interested folks can also read the debate at last night's PPB meeting: http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-19-20.00.log.html I completely buy your argument that all seats should be elected. And I also expect that most PTLs would be elected. Put it this way - with the all seats are elected model, a voting contributor gets to weigh up the likely contribution to the committee of a given PTL versus other non-PTL candidates. I think that's healthy. +1 I originally thought, The PTLs are already elected, why vote again? but your arguments about the TC size as we add more projects convinced me it will be better to use a separate selection process. Some PTLs may not want to serve on the TC anyway, since it needs to have a more holistic view of OpenStack vs. the focus of managing a specific project. Related, I think the committee should be making more of an effort to encourage rough consensus in the community on the matters under their consideration. IMHO, committee members should be voting on is there a workable rough consensus on this matter? rather than voting based purely on their own personal opinion. Leaders always have a challenge balancing between recognizing group consensus and codifying it versus influencing the group to move in a direction it may not want, to but needs, to go. I don't see the TC having an easier time of this than anyone else in history. :-) If that was the case, any PTL who was constructively engaging in a debate and helping to reach a consensus would have no fear of being ignored. Agreed. The OpenStack community has better than average collaboration skills so I don't expect problems with the TC ignoring anyone making rational arguments. Doug ___ 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
Re: [Openstack-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
On Wed, Jun 20, 2012 at 10:03 AM, Thierry Carrez thie...@openstack.orgwrote: Doug Hellmann wrote: On Wed, Jun 20, 2012 at 8:02 AM, Mark McLoughlin mar...@redhat.com mailto:mar...@redhat.com wrote: I completely buy your argument that all seats should be elected. And I also expect that most PTLs would be elected. Put it this way - with the all seats are elected model, a voting contributor gets to weigh up the likely contribution to the committee of a given PTL versus other non-PTL candidates. I think that's healthy. +1 I originally thought, The PTLs are already elected, why vote again? but your arguments about the TC size as we add more projects convinced me it will be better to use a separate selection process. Some PTLs may not want to serve on the TC anyway, since it needs to have a more holistic view of OpenStack vs. the focus of managing a specific project. I also think that PTLs and other respected leaders of this community can affect a TC decision without necessarily formally voting at the end of the discussion. They have a lot of influence, and they can use it by giving their strong position on a subject -- the meetings are open to all and I expect PTLs to show up when something that directly affects them is discussed. Whether their influence also counts as a formal vote in the final TC tally is a bit of a separate question... which I'd rather let the foundation technical members decide. That is another good point. Doug ___ 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
Re: [Openstack-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
I'm glad someone from the PTL+5 camp spoke up! In my mind, the PTL is responsible for moving their individual OpenStack sub-project forward. The technical committee is responsible for OpenStack as a whole, and making sure that the individual projects are advancing OpenStack in the right direction. In other words, I see the PTLs' responsibilities as more day-to-day operations (code reviews, blueprints etc), whereas the Committee should be concerned with the technical vision and strategy (e.g. what overall features should be part of the N+2 release and do we need e.g. to add new projects to get there?) To use a startup analogy, I see the PTLs as Director of Engineering and the technical committee as CTO. Just as different people fill those roles in a company, I probably wouldn't vote the same way. Obviously some people would be good in both roles, but we shouldn't mandate that the two be linked. In particular, we shouldn't exclude someone from being a PTL because they wouldn't be a good CTO. There are also other issues with PTL+5 IMHO (e.g incentivizing the Balkanization of OpenStack), but at core I see the two roles as being very different. Justin --- Justin Santa Barbara Founder, FathomDB On Fri, Jun 22, 2012 at 10:20 AM, Joe Heck joe.h...@nebula.com wrote: I much prefer the PTL+5 model. ___ 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
Re: [Openstack-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
It sounds like the heart of our differing views here is that there's a lack of clarity on what the technical committee is. That may because I'm not intimately involved in drafting the legal docs etc, but I think it's probably also due to a general lack of definition of those roles will be. In my mind I don't imagine the TC to be PTLs + user representatives; I see them as having responsibility for the (technical) bigger picture. I would definitely support a group that is focused on users, but I don't think that's the TC. I would venture that the hardest responsibility the TC will have is to say no to the PTLs. For example (and not to pick on you, just that gmail is helpfully suggesting it): does v3 of the OpenStack Identity API advance OpenStack enough to justify the resource requirements on downstream projects? Can we make changes to minimize the impact on everyone else, while still letting Keystone advance? Do the changes go far enough, or do we want to minimize long-term pain by adding more to the API now, rather than requiring a v4 in 12 months time? Should we defer a significant change until the next release, even if it is better for that one project to include it now? So I _want_ a division between the TC the PTLs, that reflects their different responsibilities. There will be arguments, but hopefully they will be constructive arguments like this one. In other words, we should expect healthy disagreement; it is a failure in my mind if we build a second group comprised merely of yes-men for the existing groups. Justin --- Justin Santa Barbara Founder, FathomDB On Fri, Jun 22, 2012 at 12:12 PM, Joe Heck joe.h...@nebula.com wrote: On Jun 22, 2012, at 11:53 AM, Justin Santa Barbara wrote: In my mind, the PTL is responsible for moving their individual OpenStack sub-project forward. The technical committee is responsible for OpenStack as a whole, and making sure that the individual projects are advancing OpenStack in the right direction. In other words, I see the PTLs' responsibilities as more day-to-day operations (code reviews, blueprints etc), whereas the Committee should be concerned with the technical vision and strategy (e.g. what overall features should be part of the N+2 release and do we need e.g. to add new projects to get there?) To use a startup analogy, I see the PTLs as Director of Engineering and the technical committee as CTO. Just as different people fill those roles in a company, I probably wouldn't vote the same way. Obviously some people would be good in both roles, but we shouldn't mandate that the two be linked. In particular, we shouldn't exclude someone from being a PTL because they wouldn't be a good CTO. That sounds great, but the reality is that all of these projects today are evolving actively with each other, and very little is done in isolation. The assumption that anything other than basic project management could be done effectively in isolation is a misnomer. The PTLs today as a group are doing the duties you are ascribing to the technical committee. Where we are lacking in that operation is more getting more of a voice of people using the product in that same group. This is exactly why I think we should expand on the PTL set of people with additional elected positions from the community to fill out that need. Creating a separate group will simple introduce confusion and frustration when these groups diverge. Having a separate group asserting what others *should* do is fine in a company, but a recipe for disaster in an open source organization. As you're very aware, If you want something done, come with the code. Making a means of having separate groups in this respect is pre-seeding that division as soon as one of the PTLs *is not* elected to the technical committee. Why on earth would we want to set ourselves up for failure in that way? -joe ___ 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
Re: [Openstack-poc] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)
Fascinating. The tension between community driven and committee driven technical direction, it seems. Justin, I would have been way more comfortable had your example been more vision and architecture focused instead of consequence-control focused. I could see the role of the TC as bringing a perspective on highest value road-mapping across the projects and assisting in aligning decisioning to that. I can see it as a group that makes smart decisions on the boundary between core and satellite projects. I can see it as a driver for encouraging integrations with other open source ecosystems. But, in trademarked Jan form, if you think you can add a control function, you're likely off your chum. (pardon my use of that obscure colloquialism). After all, Supreme executive power derives from a mandate from the masses! Not from some farcical aquatic ceremony! Less playfully, however, there is no question that a collaboration the size of OpenStack could benefit from vision and architecture perspective outside of the individual projects involved. That said, the intersection of such strategic and visionary thinking requires integration with (instead of management or separate direction of) the leadership of the projects. Creating this integration oriented approach rather than an implicitly confrontational approach is, I believe, Mr Heck's fine intent. Joe you may publicly lambast me and my perspective if I am off target here. Providing additional color, IMNSHOYBNI, an integrated approach will go a long way in keeping the community from telling the TC to fork off... which is better for the entire effort and certainly for us customers. Discuss. Jan On Jun 22, 2012, at 12:45 PM, Justin Santa Barbara jus...@fathomdb.com wrote: It sounds like the heart of our differing views here is that there's a lack of clarity on what the technical committee is. That may because I'm not intimately involved in drafting the legal docs etc, but I think it's probably also due to a general lack of definition of those roles will be. In my mind I don't imagine the TC to be PTLs + user representatives; I see them as having responsibility for the (technical) bigger picture. I would definitely support a group that is focused on users, but I don't think that's the TC. I would venture that the hardest responsibility the TC will have is to say no to the PTLs. For example (and not to pick on you, just that gmail is helpfully suggesting it): does v3 of the OpenStack Identity API advance OpenStack enough to justify the resource requirements on downstream projects? Can we make changes to minimize the impact on everyone else, while still letting Keystone advance? Do the changes go far enough, or do we want to minimize long-term pain by adding more to the API now, rather than requiring a v4 in 12 months time? Should we defer a significant change until the next release, even if it is better for that one project to include it now? So I _want_ a division between the TC the PTLs, that reflects their different responsibilities. There will be arguments, but hopefully they will be constructive arguments like this one. In other words, we should expect healthy disagreement; it is a failure in my mind if we build a second group comprised merely of yes-men for the existing groups. Justin --- Justin Santa Barbara Founder, FathomDB On Fri, Jun 22, 2012 at 12:12 PM, Joe Heck joe.h...@nebula.com wrote: On Jun 22, 2012, at 11:53 AM, Justin Santa Barbara wrote: In my mind, the PTL is responsible for moving their individual OpenStack sub-project forward. The technical committee is responsible for OpenStack as a whole, and making sure that the individual projects are advancing OpenStack in the right direction. In other words, I see the PTLs' responsibilities as more day-to-day operations (code reviews, blueprints etc), whereas the Committee should be concerned with the technical vision and strategy (e.g. what overall features should be part of the N+2 release and do we need e.g. to add new projects to get there?) To use a startup analogy, I see the PTLs as Director of Engineering and the technical committee as CTO. Just as different people fill those roles in a company, I probably wouldn't vote the same way. Obviously some people would be good in both roles, but we shouldn't mandate that the two be linked. In particular, we shouldn't exclude someone from being a PTL because they wouldn't be a good CTO. That sounds great, but the reality is that all of these projects today are evolving actively with each other, and very little is done in isolation. The assumption that anything other than basic project management could be done effectively in isolation is a misnomer. The PTLs today as a group are doing the duties you are ascribing to the technical committee. Where we are lacking in that operation
[Openstack-ubuntu-testing-notifications] Build Failure: precise_essex_nova_stable #6
Title: precise_essex_nova_stable General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_essex_nova_stable/6/Project:precise_essex_nova_stableDate of build:Fri, 22 Jun 2012 08:31:54 -0400Build duration:2 min 29 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesBump version to 2012.1.2by markmceditnova/version.pyConsole Output[...truncated 2207 lines...]hard linking smoketests/test_sysadmin.py -> nova-2012.1.2/smoketestshard linking tools/clean-vlans -> nova-2012.1.2/toolshard linking tools/clean_file_locks.py -> nova-2012.1.2/toolshard linking tools/enable-pre-commit-hook.sh -> nova-2012.1.2/toolshard linking tools/hacking.py -> nova-2012.1.2/toolshard linking tools/install_venv.py -> nova-2012.1.2/toolshard linking tools/nova-debug -> nova-2012.1.2/toolshard linking tools/pip-requires -> nova-2012.1.2/toolshard linking tools/rfc.sh -> nova-2012.1.2/toolshard linking tools/test-requires -> nova-2012.1.2/toolshard linking tools/with_venv.sh -> nova-2012.1.2/toolshard linking tools/conf/create_conf.py -> nova-2012.1.2/tools/confhard linking tools/conf/generate_sample.sh -> nova-2012.1.2/tools/confhard linking tools/esx/guest_tool.py -> nova-2012.1.2/tools/esxhard linking tools/xenserver/vdi_chain_cleanup.py -> nova-2012.1.2/tools/xenserverhard linking tools/xenserver/vm_vdi_cleaner.py -> nova-2012.1.2/tools/xenservercopying setup.cfg -> nova-2012.1.2Writing nova-2012.1.2/setup.cfgcreating distCreating tar archiveremoving 'nova-2012.1.2' (and everything under it)ERROR:root:Error occurred during package creation/buildERROR:root:[Errno 2] No such file or directory: '/tmp/tmpYXFvbq/git/nova/dist/nova-2012.1.1.tar.gz'INFO:root:Complete command log:INFO:root:Destroying schroot session: precise-amd64-a655592e-3d16-43b4-8fb1-8c97b7507c1fschroot -b -c precise-amd64schroot -r -c precise-amd64-a655592e-3d16-43b4-8fb1-8c97b7507c1f -u root -- apt-get updateschroot -r -c precise-amd64-a655592e-3d16-43b4-8fb1-8c97b7507c1f -u root -- apt-get -y install equivs devscripts bzr bzr-builddeb git quilt gnupgbzr branch lp:~openstack-ubuntu-testing/nova/precise-essex-proposed /tmp/tmpYXFvbq/novaschroot -r -c precise-amd64-a655592e-3d16-43b4-8fb1-8c97b7507c1f -u root -- mk-build-deps -i -r -t apt-get -y /tmp/tmpYXFvbq/nova/debian/controlschroot -r -c precise-amd64-a655592e-3d16-43b4-8fb1-8c97b7507c1f -- python setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 132, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpYXFvbq/git/nova/dist/nova-2012.1.1.tar.gz'Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 132, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpYXFvbq/git/nova/dist/nova-2012.1.1.tar.gz'Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: precise_essex_nova_stable #7
Title: precise_essex_nova_stable General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise_essex_nova_stable/7/Project:precise_essex_nova_stableDate of build:Fri, 22 Jun 2012 15:08:59 -0400Build duration:14 minBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesConsole Output[...truncated 14917 lines...]deleting and forgetting pool/main/n/nova/nova-cert_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-common_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-kvm_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-lxc_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-qemu_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-uml_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-xcp_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-xen_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-console_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-consoleauth_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-doc_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-network_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-objectstore_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-scheduler_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-vncproxy_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-volume_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-xcp-network_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-xcp-plugins_2012.1.1+git201206212002~precise-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/python-nova_2012.1.1+git201206212002~precise-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 388.INFO:root:Storing current commit for next build: 17c78ebca1f3164d27d8bffa16fd9933adfdd7fcINFO:root:Complete command log:INFO:root:Destroying schroot session: precise-amd64-4871c138-1555-46f7-a241-00287ee4a759schroot -b -c precise-amd64schroot -r -c precise-amd64-4871c138-1555-46f7-a241-00287ee4a759 -u root -- apt-get updateschroot -r -c precise-amd64-4871c138-1555-46f7-a241-00287ee4a759 -u root -- apt-get -y install equivs devscripts bzr bzr-builddeb git quilt gnupgbzr branch lp:~openstack-ubuntu-testing/nova/precise-essex-proposed /tmp/tmpxQEEUG/novaschroot -r -c precise-amd64-4871c138-1555-46f7-a241-00287ee4a759 -u root -- mk-build-deps -i -r -t apt-get -y /tmp/tmpxQEEUG/nova/debian/controlschroot -r -c precise-amd64-4871c138-1555-46f7-a241-00287ee4a759 -- python setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log be3a2f5d33cbfe84a4a317a54b0e2728a57422bc..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/precise-essex-stable --forcedch -b -D precise --newversion 2012.1.2+git201206221512~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 2012.1.2+git201206221512~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucschroot -r -c precise-amd64-4871c138-1555-46f7-a241-00287ee4a759 -- bzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC nova_2012.1.2+git201206221512~precise-0ubuntu1_source.changessbuild -d precise-essex -n -A nova_2012.1.2+git201206221512~precise-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/essex-stable-testing nova_2012.1.2+git201206221512~precise-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include precise-essex nova_2012.1.2+git201206221512~precise-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/nova/precise-essex-stable+ [ ! 0 ]+ jenkins-cli build precise-openstack-essex-deployEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
