Re: [openstack-dev] stalled bug fixes for vmware driver
Thanks to everyone for the reviews over the last 24 hours. I really appreciate the time and effort from all in the review process. I hope that once we have the tempest results posted automatically for each for each patch then it will give the core reviewers more confidence in the Vmware fixes. Thanks and have a good weekend. Gary On 9/21/13 3:10 AM, Russell Bryant rbry...@redhat.com wrote: On 09/20/2013 07:00 PM, Dan Wendlandt wrote: btw, thanks to the core devs who went and took a look at several of the vmware reviews today. It was like christmas for the team today :) And for the record, I did all of my reviews before this thread even started, just as a part of my normal workflow. I was working from the havana-rc1 bug list. :-) -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Please refrain from +1'ing Candidate Announcements for the PTL Election
I had posted this[1] to the Nova thread and I guess some folks have missed it, so I shall say it again in a specific email. Please refrain from +1'ing candidate announcements. Such posts just take my attention from real candidate announcements. Also they may give the impression to new contributors that this action constitutes voting - which is a false impression. Voting begins September 27th. If you want to express your support for a given candidate I encourage you to find other means of doing so. It is wonderful that we have so many capable, experienced and qualified people for our PTL nominations and we do have a lot of them. I would like to give my attention to them. Thanks again for your understanding, Anita. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015381.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack] Cinder PTL Candidacy
Hello Everybody, I would like to run for election as Cinder PTL for the upcoming I release. For those who don't know me, I am the current Cinder PTL and have been working on OpenStack for almost two years now. Most of that time has been spent leading the Cinder efforts starting with the separation of the Nova-Volume code. The upcoming Havana release will mark our third release with Cinder as a released project in OpenStack and I think we have continued to grow and get better with each release, Havana being no exception. Some of you may know that there's a lot that goes in to being a PTL. I see it as a combination of Project/Team management, Technical Leadership and Evangelism. I love the job, every aspect of it as well as the challenges that come with it. This includes talking about Cinder, brainstorming new ideas and *recruiting* new vendors and contributors. Given Cinders unique plugin model (we now have over 17 supported back end device drivers), one of the biggest challenges is continuing to provide and maintain a feature equivalent and robust reference implementation as well as maintaining consistent behaviors across all of these drivers. At the same time we've provided ways for different vendors to expose their own unique features via optimizations or the use of types and extra-specs. The mantra here has been, if vendor A wants to implement a new feature there has to be a way to implement it across the board. It may not be the most elegant or efficient for some back-ends, but the idea is you will have consistent capabilities and behaviors. One of the things that I think makes the above described philosophy so powerful is that it drives interest and contributions to the project as a whole. The result is that Cinder has multiple contributors from competing storage vendors all driving to advance the overall project for EVERYBODY. I think we've done a fantastic job in this respect and if elected I plan to continue to drive this as one of the main ideologies for the project. There are a number of things that I see as needing particular focus during the upcoming release, and if elected I will try and drive these items: 1. Functional test qualification for back end devices Many of you have heard about this via mailing list, but I think it's critical that we have some way to share publicly that the drivers that are shipped with cinder actually work. This is something that I've started and plan to implement for the I release, it will start simply by requiring that all of the tests we currently run in the CI gates are run against each driver/back-end and the results of those runs are submitted publicly. 2. More involvement in Horizon This has been something that I've thought of and mentioned in the past but it hasn't really happened. For the upcoming release I would like to drive folks that implement new features in Cinder to help contribute and get those same features exposed in Horizon. In my opinion OpenStack is growing so quickly and becoming so large, that there needs to be more contribution from all projects to keep Horizon updated. I'm not saying something as extreme as to have a rule that a BP is not closed/implemented until the Horizon work is done, but I'd love to see folks have that sort of view (un-enforced norm in terms of behaviors) with features they implement in Cinder as we go forward. 3. Organization and strategy around common libraries for Block Storage This is something that we talked about during the last summit and we made some progress on. The problem is that it started to grow in to it's own beast and I think we lost our focus. I'd like to really emphasize early in the Icehouse release what our common goals and objectives are here and make this a reality early on in the release cycle (preferably the first milestone). 4. Continued implementation of task-flows and states We've made a good initial start here by adopting task-flows for our volume-create process. I think there's a lot more that can be done to improve upon what we have here, and also to spread that out to the other Cinder tasks. 5. More interaction with the other projects The worst thing for any project in OpenStack in the coming release IMO is going to be working in isolation. There are a large number of new projects/programs being introduced, many of which that utilize bits and pieces of all OpenStack projects. I think it's critical that we come up with some ways to collaborate across projects and programs, not only for better implementations in consumer projects, but also to make sure we provide valuable features that might be needed. This particularly includes projects like Trove, Ironic and Triple'O. 6. Continue to grow the contributing community This is key IMO for any Open Source project, we need to continue to grow the interest and contributions. Whether that be via new drivers/vendor participation or new core features, I believe involvement and particularly community growth is a
Re: [openstack-dev] [Nove] Launch an instance with IDE disk type instead of virtio disk type
With Havana+ you should be able to use the new block_device_mapping code to specify a particular bus during launch, but for Grizzly you can specify the bus by setting metadata on the image in glance. glance image-update uuid --property hw_disk_bus=ide There are a few properites like this, see https://wiki.openstack.org/wiki/LibvirtCustomHardware Vish On Sep 20, 2013, at 6:30 PM, Pattabi Ayyasami patt...@brocade.com wrote: Hi, We have a KVM qcow2 image to be launched on a KVM host. From Dashboard, I don’t find a way to specify the disk type for a new instance as IDE. The instance was launched with a virtio disk type. virsh dumpxml kvm_vm_name shows the following. …. disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/opt/stack/data/nova/instances/2f317b2e-f3b8-40cd-ba79-402231ccee51/disk'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x08' function='0x0'/ /disk …. I want it to be target dev=’vda’ bus=’ide’/ address type='drive' controller='0' bus='0' unit='0'/ The libvirt.xml under data/nova/instances/image_id …. disk type=file device=disk driver name=qemu type=qcow2 cache=none/ source file=/opt/stack/data/nova/instances/2f317b2e-f3b8-40cd-ba79-402231ccee51/disk/ target bus=virtio dev=vda/ /disk …. I want it to be target bus=”ide” dev=vda”/ I could manually change libvirt.xml and virsh edit kvm_vm_name as mentioned above. But I want to be able to do it either from Dashboard GUI or commands such as glance or nova. Does anyone have any pointers on workarounds / solution on this? Thanks Pattabi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: [Openstack-devel] PGP key signing party during the HK summit
On 09/20/2013 02:33 AM, Thomas Goirand wrote: Hi, Has anyone thought about having a PGP key signing party during the summit? Guys from the Linux kernel thought it was useless, but after the hack of kernel.org, they started to understand it was useful, and now they do have a web of trust. As a package maintainer, I would very much like to have a signing event during the next HK summit, and collect signatures so that I can check the pgp signed tags, which to my very satisfaction, starts to appear for every package release (not sure if this comes from the fact I've been annoying everyone about it in this list, though that's a very good thing). As a note, actually, it is impossible now to make an OpenStack release without a signed tag - the process of releasing itself is triggered only by signed tags. So yes - I fully support developing a keyring. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
