[openstack-dev] [cinder][nova] cinder-manage volume reattach is broken
Hi All, As this bug (https://bugs.launchpad.net/cinder/+bug/1167931) says, we have to do sth: 1) Just remove 'reattach' in file 'cinder/bin/cinder-manage'. I didn't find any reference to this call. it's om to remove it. 2) If we keep it, 'reattach' function in cinder-manage will be moved to nova side, since 'db.instance_get' in current implement is missing. I'm going to add new sub command like 'nova-manage volume reattch', does it make sense? but is it suitable to operate cinder db (cinder,db.volume_get) in nova-manage? any idea/suggestion about the bug? Thanks, Ray ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder][nova] cinder-manage volume reattach is broken
Is there any use case for reattach? On Mon, Apr 21, 2014 at 1:56 PM, Ray Chen chenrano2...@gmail.com wrote: Hi All, As this bug (https://bugs.launchpad.net/cinder/+bug/1167931) says, we have to do sth: 1) Just remove 'reattach' in file 'cinder/bin/cinder-manage'. I didn't find any reference to this call. it's om to remove it. 2) If we keep it, 'reattach' function in cinder-manage will be moved to nova side, since 'db.instance_get' in current implement is missing. I'm going to add new sub command like 'nova-manage volume reattch', does it make sense? but is it suitable to operate cinder db (cinder,db.volume_get) in nova-manage? any idea/suggestion about the bug? Thanks, Ray ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.comwrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.comwrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com. Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ 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] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.
Aaron One use case is that tenant would like to put all the servers in a single broadcast domain (thus single IP/subnet domain). The servers can include the 3 tier servers (web database and application server). Why would he do that - Because it is simpler. Then the tenant would like to put security appliance firewalls between them. Lets say a database firewall appliance before the database tier or only app servers can access database servers. This is done in physical world but one needs to add switches and wire them from one broadcast domain to other. It is a pain. But in the virtual world this is lot simpler and convenient. prasadv On Wed, Apr 16, 2014 at 5:50 PM, Aaron Rosen aaronoro...@gmail.com wrote: This is true. Several people have asked this same question over the years though I've yet to hear a use case why one really need to do this. Do you have one? On Wed, Apr 16, 2014 at 3:12 PM, Ronak Shah ro...@nuagenetworks.netwrote: Hi Vikash, Currently this is not supported. the NIC not only needs to be in different subnet, they have to be in different network as well (container for the subnet) Thanks Ronak On Wed, Apr 16, 2014 at 3:51 AM, Vikash Kumar vikash.ku...@oneconvergence.com wrote: *With 'interfaces' I mean 'nics' of VM*. On Wed, Apr 16, 2014 at 4:18 PM, Vikash Kumar vikash.ku...@oneconvergence.com wrote: Hi, I want to launch one VM which will have two Ethernet interfaces with IP of single subnet. Is this supported now in openstack ? Any suggestion ? Thanx ___ 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 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] [neutron] Updates to the template for Neutron BPs
Yes. It shows up in the approved section since it's just a build of the patch as-is. The link is titled gate-neutron-specs-docs in the message from Jenkins. -- Kevin Benton On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami dh...@noironetworks.comwrote: Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.com wrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com. Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
That's because spec was proposed to the juno/ folder. Look at https://raw.githubusercontent.com/openstack/neutron-specs/master/doc/source/index.rst, if spec is in juno/ folder, then contents shows it as approved one. Once merged, it means approved, right? So it is going to be Ok after merge. Though a better reminding than just draft in the url could be required if many start to mess it up... On Mon, Apr 21, 2014 at 10:43 AM, Kevin Benton blak...@gmail.com wrote: Yes. It shows up in the approved section since it's just a build of the patch as-is. The link is titled gate-neutron-specs-docs in the message from Jenkins. -- Kevin Benton On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami dh...@noironetworks.comwrote: Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.com wrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com . Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] review request 66006
Hi, Ceilometer dev cores, There is a patch https://review.openstack.org/#/c/66006/, which is backported from 59669, aims at fixing bug : https://bugs.launchpad.net/ceilometer/+bug/1257232 in havana branch, but it is blocked by Alan Pevec Feb 11 Patch Set 4: Do not merge 2013.2.2 freeze Since ceilometer 2013.2.3 has been released, I think such reason is not correct any more, I have asked to remove the -2 in review comment, but get no response So I open a thread in mailing list to ask for help/advice thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Updates to the template for Neutron BPs
Got it. Thanks. Regards, Mandeep On Sun, Apr 20, 2014 at 11:49 PM, Mike Scherbakov mscherba...@mirantis.comwrote: That's because spec was proposed to the juno/ folder. Look at https://raw.githubusercontent.com/openstack/neutron-specs/master/doc/source/index.rst, if spec is in juno/ folder, then contents shows it as approved one. Once merged, it means approved, right? So it is going to be Ok after merge. Though a better reminding than just draft in the url could be required if many start to mess it up... On Mon, Apr 21, 2014 at 10:43 AM, Kevin Benton blak...@gmail.com wrote: Yes. It shows up in the approved section since it's just a build of the patch as-is. The link is titled gate-neutron-specs-docs in the message from Jenkins. -- Kevin Benton On Sun, Apr 20, 2014 at 11:37 PM, Mandeep Dhami dh...@noironetworks.comwrote: Just for clarification. Jenkins link in the description puts the generated HTML in the section Juno approved specs even tho' the blueprint is still being reviewed. Am I looking at the right link? Regards, Mandeep On Sun, Apr 20, 2014 at 10:54 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Yes, thanks, that's exactly what I was looking for! On Mon, Apr 21, 2014 at 12:03 AM, Kyle Mestery mest...@noironetworks.com wrote: On Sat, Apr 19, 2014 at 5:11 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi Kyle, I built template and it looks awesome. We are considering to use same approach for Fuel. My assumption is that spec will be on review for a negotiation time, which is going to be quite a while. In my opinion, it is not always very convenient to read spec in gerrit. Agreed, though for some specs, this is actually an ok way to do reviews. Did you guys have any thoughts on auto-build these specs into html on every patch upload? So we could go somewhere and see built results, without a requirement to fetch neutron-specs, and run tox? The possible drawback is that reader won't see gerrit comments.. I followed what Nova was going and committed code into openstack-infra/config which allows for some jenkins jobs to run when we commit to the neutron-specs gerrit. [1]. As an example, look at this commit here [2]. If you look at the latest Jenkins run, you'll see a link which takes you to an HTML generated document [3] which you can review in lieu of the raw restructured text in gerrit. That will actually generate all the specs in the repository, so you'll see the Example Spec along with the Nuage one I used for reference here. Hope that helps! Kyle [1] https://review.openstack.org/#/c/88069/ [2] https://review.openstack.org/#/c/88690/ [3] http://docs-draft.openstack.org/90/88690/3/check/gate-neutron-specs-docs/fe4282a/doc/build/html/ Thanks, On Sat, Apr 19, 2014 at 12:08 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi folks: I just wanted to let people know that we've merged a few patches [1] to the neutron-specs repository over the past week which have updated the template.rst file. Specifically, Nachi has provided some instructions for using Sphinx diagram tools in lieu of asciiflow.com. Either approach is fine for any Neutron BP submissions, but Nachi's patch has some examples of using both approaches. Bob merged a patch which shows an example of defining REST APIs with attribute tables. Just an update for anyone proposing BPs for Juno at the moment. Thanks! Kyle [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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 -- Mike Scherbakov #mihgen ___ 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 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
I plan to register a blueprints in nova for record this. Can I? -邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: Hi all: Currently, the EC2 API of OpenStack only has tags support (metadata) for instances. And there has already a blueprint about to add support for volumes and volume snapshots using “metadata”. There are a lot of resources such as image/subnet/securityGroup/networkInterface(port) are supported add tags for AWS. I think we should support tags for these resources. There may be no property “metadata for these resources, so we should to add “metadata” to support the resource tags, the change related API. Hi Tianhua, In OpenStack, generally, the choice was made to use maps of key/value pairs instead of lists of strings (tags) to annotate objects exposed in the REST APIs. OpenStack REST APIs inconsistently call these maps of key/value pairs: * properties (Glance, Cinder Image, Volume respectively) * extra_specs (Nova InstanceType) * metadata (Nova Instance, Aggregate and InstanceGroup, Neutron) * metadetails (Nova Aggregate and InstanceGroup) * system_metadata (Nova Instance -- differs from normal metadata in that the key/value pairs are 'owned' by Nova, not a user...) Personally, I think tags are a cleaner way of annotating objects when the annotation is coming from a normal user. Tags represent by far the most common way for REST APIs to enable user-facing annotation of objects in a way that is easy to search on. I'd love to see support for tags added to any searchable/queryable object in all of the OpenStack APIs. I'd also like to see cleanup of the aforementioned inconsistencies in how maps of key/value pairs are both implemented and named throughout the OpenStack APIs. Specifically, I'd like to see this implemented in the next major version of the Compute API: * Removal of the metadetails term * All key/value pairs can only be changed by users with elevated privileged system-controlled (normal users should use tags) * Call all these key/value pair combinations properties -- technically, metadata is data about data, like the size of an integer. These key/value pairs are just data, not data about data. * Identify key/value pairs that are relied on by all of Nova to be a specific key and value combination, and make these things actual real attributes on some object model -- since that is a much greater guard for the schema of an object and enables greater performance by allowing both type safety of the underlying data and removes the need to search by both a key and a value. Best, -jay ___ 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] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt
On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery mest...@noironetworks.comwrote: On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev obonda...@mirantis.com wrote: Hi all, While investigating possible options for Nova-network to Neutron migration I faced a couple of issues with libvirt. One of the key requirements for the migration is that instances should stay running and don't need restarting. In order to meet this requirement we need to either attach new nic to the instance or update existing one to plug it to the Neutron network. Thanks for looking into this Oleg! I just wanted to mention that if we're trying to plug a new NIC into the VM, this will likely require modifications in the guest. The new NIC will likely have a new PCI ID, MAC, etc., and thus the guest would have to switch to this. Therefor, I think it may be better to try and move the existing NIC from a nova network onto a neutron network. Yeah, I agree that modifying the existing NIC is the preferred way. So what I've discovered is that attaching a new network device is only applied on the instance after reboot although VIR_DOMAIN_AFFECT_LIVE flag is passed to the libvirt call attachDeviceFlags(): https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412 Is that expected? Are there any other options to apply new nic without reboot? I also tried to update existing nic of an instance by using libvirt updateDeviceFlags() call, but it fails with the following: 'this function is not supported by the connection driver: cannot modify network device configuration' libvirt API spec (http://libvirt.org/hvsupport.html) shows that 0.8.0 as minimal qemu version for the virDomainUpdateDeviceFlags call, kvm --version on my setup shows 'QEMU emulator version 1.0 (qemu-kvm-1.0)' Could someone please point what am I missing here? What does libvirtd -V show for the libvirt version? On my Fedora 20 setup, I see the following: [kmestery@fedora-mac neutron]$ libvirtd -V libvirtd (libvirt) 1.1.3.4 [kmestery@fedora-mac neutron]$ On my Ubuntu 12.04 it shows: $ libvirtd --version libvirtd (libvirt) 0.9.8 Thanks, Kyle Any help on the above is much appreciated! Thanks, Oleg ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [murano] Proposal to add Ruslan Kamaldinov to murano-core team
+1 Ruslan, congratulations! On Fri, Apr 18, 2014 at 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote: Ruslan, welcome to the Murano core team :)! On Thu, Apr 17, 2014 at 7:32 PM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: +1 On Thu, Apr 17, 2014 at 7:11 PM, Stan Lagun sla...@mirantis.com wrote: +1 Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 17, 2014 at 6:51 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: +1 On Thu, Apr 17, 2014 at 6:01 AM, Dmitry Teselkin dtesel...@mirantis.com wrote: +1 Agree On Thu, Apr 17, 2014 at 4:51 PM, Alexander Tivelkov ativel...@mirantis.com wrote: +1 Totally agree -- Regards, Alexander Tivelkov On Thu, Apr 17, 2014 at 4:37 PM, Timur Sufiev tsuf...@mirantis.com wrote: Guys, Ruslan Kamaldinov has been doing a lot of things for Murano recently (including devstack integration, automation scripts, making Murano more compliant with OpenStack standards and doing many reviews). He's actively participating in our ML discussions as well. I suggest to add him to the core team. Murano folks, please say your +1/-1 word. -- Timur Sufiev ___ 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 -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur, QA Engineer OpenStack Projects Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [murano] Murano bug scrub 04/23/14
Hi all, We have many new bugs in Murano and I suggest to conduct the meeting and discuss all bugs, assign these bugs to developers and set the mailstones. Let's schedule this meeting on 04/23/14, at 16:00 UTC, im #murano IRC. Thank you! -- Timur, QA Engineer OpenStack Projects Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.
Hi, (2014/04/17 21:29), CARVER, PAUL wrote: Akihiro Motoki wrote: To cope with such cases, allowed-address-pairs extension was implemented. http://docs.openstack.org/api/openstack-network/2.0/content/allowed_address_pair_ext_ops.html Question on this in particular: Is a tenant permitted to do this? If so, what exactly is the iptables rule accomplishing? If the intent was to prevent the tenant from spoofing someone else's IP then forcing the tenant to take an extra step of making an API call prior to attempting to spoof doesn't really stop them. In my understanding, the answer is Yes and it is a topic specific to one tenant. When we talk about a security model about security groups, we need to assume three roles: - tenant user, who deploys applications on a tenant provided by tenant admin - tenant admin, who uses OpenStack API to manage a tenant topology (instances, networks, volumes...) - infra administator, who provides OpenStack services and coordindate multiple tennats According to my understanding, security group rules and spoofing rules are defined by tenant admin to prevent tenant user from communicating unintended peers or spoofing other IP addresses. Thus, I think allowed_address_pairs feature does not break the existing security model. Isolation among tenants should be guaranteed at infra level and it is the role of infra administrator. Generally speaking, in neutron concept, a tenant can use any IP and MAC addresses as it wants. Note that 'flat' networking has a limitation and the isolation among tenants depends on these spoofing rules and IP uniqueness, so it should not be used for such situations. Question in general: Is there an easy way to see the whole API broken out by privilege level? I'd like to have a clear idea of all the functionality that requires a cloud operator/admin to perform vs the functionality that a tenant can perform. Obviously Horizon looks different for an admin than it does for a tenant, but I'm not as clear on how to identify differences in the API. AFAIK there is no API summary broken out by priviledge level. In Neutron API, there is no explicit difference between tenant and admin API. It is controlled by policy.json and looking at this file is the easiest way to check it. The default policy is determined based on general use cases discussed during development (mainly from the point view of tenant isolation including security model). Cloud administrators (with keystone admin role) can see all resources and extra attributes by default. It is common in most OpenStack projects. In Horizon, admin and project dashboards have different views. Horizon developers map/classify features into admin or project dashboards, there are many gray zones and RBAC mechanism based on the above policy mechanism has been introduced in Icehouse Horizon. I don't think I answered all of your questions but I hope it answer most. Thanks, Akihiro ___ 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] [murano] Proposal to add Ruslan Kamaldinov to murano-core team
Thank you, guys :) Ruslan On Mon, Apr 21, 2014 at 1:40 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: +1 Ruslan, congratulations! On Fri, Apr 18, 2014 at 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote: Ruslan, welcome to the Murano core team :)! On Thu, Apr 17, 2014 at 7:32 PM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: +1 On Thu, Apr 17, 2014 at 7:11 PM, Stan Lagun sla...@mirantis.com wrote: +1 Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Apr 17, 2014 at 6:51 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: +1 On Thu, Apr 17, 2014 at 6:01 AM, Dmitry Teselkin dtesel...@mirantis.com wrote: +1 Agree On Thu, Apr 17, 2014 at 4:51 PM, Alexander Tivelkov ativel...@mirantis.com wrote: +1 Totally agree -- Regards, Alexander Tivelkov On Thu, Apr 17, 2014 at 4:37 PM, Timur Sufiev tsuf...@mirantis.com wrote: Guys, Ruslan Kamaldinov has been doing a lot of things for Murano recently (including devstack integration, automation scripts, making Murano more compliant with OpenStack standards and doing many reviews). He's actively participating in our ML discussions as well. I suggest to add him to the core team. Murano folks, please say your +1/-1 word. -- Timur Sufiev ___ 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 -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur, QA Engineer OpenStack Projects Mirantis Inc ___ 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] [ceilometer]support direct alarm_evaluator db access
Hi Liu sheng, We're also investigating alarm_evaluator performance. We observed that alarm_evaluator spends half of the time for calling ceilometerclient while evaluating alarms. Allowing alarm_evaluator directly access db will greatly improve the performance if you have many alarms. Best regards, Nihongi From: liusheng liusheng1...@126.com To: openstack-dev@lists.openstack.org Date: Tue, 15 Apr 2014 15:26:58 +0800 Subject: [openstack-dev] [ceilometer]support direct alarm_evaluator db access Hi there, Currently,alarm_evaluator invoke ceilometerclient to get all assigned alarms. and then, evaluate per alarm by get statistics, which will also call ceilometerclient. this process is: evaluator--ceilometerclient--ceilometer API--db. If we use default option of evaluation_interval (60s), and if we have many alarms, alarm_evaluator will frequently invoke ceilometerclient and will produce many http requests per minute. That is inefficient,it affect the performance of ceilometer(data collection, data query, e.g.). The better way is allowing alarm_evaluator access db directely. Should the related codes of alarm-evaluator need a refactor? Can you provide your thoughts about this? I have registered a related blueprint: https://blueprints.launchpad.net/ceilometer/+spec/direct-alarm-evaluator-db- access Best regards Liu sheng ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Nobuyoshi Nihongi NTT Software Innovation Center Phone: +81 422 59 4880 E-mail: nihongi.nobuyo...@lab.ntt.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Migration to packages, step 1/2
How does it impact development process? If I change code of, let's say, shotgun, and then run make iso, will I get an ISO with my code of shotgun? What about other packages, sources of which I did not touch (let's say nailgun) ? Everything is packaged, with two exceptions: *astute* and third-party packages for nailgun-agent. We are working on it. How far we became from implementing simple command to build an OpenStack package from source? Not even a bit closer. Design for OpenStack packages is in progress. What is the time difference, is ISO build became faster? Can you provide numbers? A little bit faster. I did not perform precise measurements and we still need remove gem mirror. It will be something like decreasing from 22 minutes to 17 minutes. We still have puppet modules not packaged, right? Do we have plans for packaging it too? Yes, puppet is not packaged. It is in our post-5.0 plans. On Sat, Apr 19, 2014 at 12:55 AM, Mike Scherbakov mscherba...@mirantis.comwrote: That's cool actually. I have a few specific questions: 1. How does it impact development process? If I change code of, let's say, shotgun, and then run make iso, will I get an ISO with my code of shotgun? What about other packages, sources of which I did not touch (let's say nailgun) ? 2. How far we became from implementing simple command to build an OpenStack package from source? 3. What is the time difference, is ISO build became faster? Can you provide numbers? 4. We still have puppet modules not packaged, right? Do we have plans for packaging it too? I assume we will document the usage of this somewhere in dev docs too. Thanks, On Fri, Apr 18, 2014 at 6:06 PM, Dmitry Pyzhov dpyz...@mirantis.comwrote: Guys, I've removed ability to use eggs packages on master node: https://review.openstack.org/#/c/88012/ Next step is to remove gems mirror: https://review.openstack.org/#/c/88278/ It will be merged when osci team fix rubygem-yajl-ruby package. Hopefully on Monday. From that moment all our code will be installed everywhere from packages. And there will be option to build packages during iso build or use pre-built packages from our mirrors. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ 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] [nova] qemu1.7.1 vs qemu-kvm
Hi, As per I understand, onwards qemu 1.3 release all qemu-kvm features have been merged into upstream QEMU. So, if I use qemu 1.7.1 and use the -enable-kvm flag, the VM will use all kvm capabilities. I have a Openstack Grizzly deployment with nova-network and I want to use qemu 1.7.1. So, I compiled it from source and symlink qemu-system-x86_64 to qemu-kvm. I can boot virtual machines. But, is there any way I can avoid the symlinking and use qemu-system-x86_64 directly? Thanks, Arindam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic]problem deploying ironic with devstack
I'm trying to deploy ironic with devstack. I'm following the instructions @ http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack. It is failing to start nova-scheduler and failing with below error. 2014-04-21 08:01:13.005 INFO nova.virt.driver [-] Loading compute driver 'ironic.nova.virt.ironic.IronicDriver' 2014-04-21 08:01:13.006 ERROR nova.virt.driver [-] Unable to load the virtualization driver 2014-04-21 08:01:13.006 TRACE nova.virt.driver Traceback (most recent call last): 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/virt/driver.py, line 1218, in load_compute_driver 2014-04-21 08:01:13.006 TRACE nova.virt.driver virtapi) 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/openstack/common/importutils.py, line 52, in import_object_ns 2014-04-21 08:01:13.006 TRACE nova.virt.driver return import_class(import_str)(*args, **kwargs) 2014-04-21 08:01:13.006 TRACE nova.virt.driver File /opt/stack/nova/nova/openstack/common/importutils.py, line 28, in import_class 2014-04-21 08:01:13.006 TRACE nova.virt.driver __import__(mod_str) 2014-04-21 08:01:13.006 TRACE nova.virt.driver ImportError: No module named nova.virt.ironic 2014-04-21 08:01:13.006 TRACE nova.virt.driver Here is my localrc contents. # Enable Ironic API and Ironic Conductor enable_service ironic enable_service ir-api enable_service ir-cond # Enable Neutron which is required by Ironic and disable nova-network. disable_service n-net enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service neutron # Log all devstack output to a log file LOGFILE=$HOME/devstack.log DATABASE_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password ADMIN_PASSWORD=password BM_BUILD_DEPLOY_RAMDISK=True BM_DEPLOY_FLAVOR=-a amd64 ubuntu deploy-ironic IRONIC_VM_COUNT=3 IRONIC_VM_SPECS_RAM=512 IRONIC_VM_SPECS_DISK=10 IRONIC_BAREMETAL_BASIC_OPS=True VIRT_DRIVER=ironic SERVICE_TOKEN=password Could someone help me in resolving this issue. I'm trying this on a baremetal server not on vm running ubuntu 12.03. Regards Gopi Krishna S___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] How to use ironic-python-agent ?
Hi, This is regarding the new teeth agent that is proposed in Ironic. I understand that the teeth agent is still under development, but is there some document available on how I can include the teeth agent in my ramdisk, so that I can get it handshaked with the ironic driver. I just checked the wiki for ironic-python-agent below, but couldn't find any information. https://wiki.openstack.org/wiki/Ironic-python-agent Could someone point me how to give a try with this. Thanks. -- Ramakrishnan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Nova-network to Neutron migration: issues with libvirt
(2014/04/21 18:10), Oleg Bondarev wrote: On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery mest...@noironetworks.commailto:mest...@noironetworks.com wrote: On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: Hi all, While investigating possible options for Nova-network to Neutron migration I faced a couple of issues with libvirt. One of the key requirements for the migration is that instances should stay running and don't need restarting. In order to meet this requirement we need to either attach new nic to the instance or update existing one to plug it to the Neutron network. Thanks for looking into this Oleg! I just wanted to mention that if we're trying to plug a new NIC into the VM, this will likely require modifications in the guest. The new NIC will likely have a new PCI ID, MAC, etc., and thus the guest would have to switch to this. Therefor, I think it may be better to try and move the existing NIC from a nova network onto a neutron network. Yeah, I agree that modifying the existing NIC is the preferred way. Thanks for investigating ways of migrating from nova-network to neutron. I think we need to define the levels of the migration. We can't satisfy all requirements at the same time, so we need to determine/clarify some reasonable limitations on the migration. - datapath downtime - no downtime - a small period of downtime - rebooting an instnace - API and management plane downtime - Combination of the above I think modifying the existing NIC requires plug and unplug an device in some way (plug/unplug an network interface to VM? move a tap device from nova-network to neutron bridge?). It leads to a small downtime. On the other hand, adding a new interface requires a geust to deal with network migration (though it can potentially provide no downtime migration as an infra level). IMO a small downtime can be accepted in cloud use cases and it is a good start line. Thanks, Akihiro So what I've discovered is that attaching a new network device is only applied on the instance after reboot although VIR_DOMAIN_AFFECT_LIVE flag is passed to the libvirt call attachDeviceFlags(): https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412 Is that expected? Are there any other options to apply new nic without reboot? I also tried to update existing nic of an instance by using libvirt updateDeviceFlags() call, but it fails with the following: 'this function is not supported by the connection driver: cannot modify network device configuration' libvirt API spec (http://libvirt.org/hvsupport.html) shows that 0.8.0 as minimal qemu version for the virDomainUpdateDeviceFlags call, kvm --version on my setup shows 'QEMU emulator version 1.0 (qemu-kvm-1.0)' Could someone please point what am I missing here? What does libvirtd -V show for the libvirt version? On my Fedora 20 setup, I see the following: [kmestery@fedora-mac neutron]$ libvirtd -V libvirtd (libvirt) 1.1.3.4 [kmestery@fedora-mac neutron]$ On my Ubuntu 12.04 it shows: $ libvirtd --version libvirtd (libvirt) 0.9.8 Thanks, Kyle Any help on the above is much appreciated! Thanks, Oleg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [cinder][nova] cinder-manage volume reattach is broken
Hi All, As this bug (https://bugs.launchpad.net/cinder/+bug/1167931) says, we have to do sth: 1) Just remove 'reattach' in file 'cinder/bin/cinder-manage'. I didn't find any reference to this call. it's om to remove it. 2) If we keep it, 'reattach' function in cinder-manage will be moved to nova side, since 'db.instance_get' in current implement is missing. I'm going to add new sub command like 'nova-manage volume reattch', does it make sense? but is it suitable to operate cinder db (cinder,db.volume_get) in nova-manage? any idea/suggestion about the bug? Thanks, Ray ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] How to use ironic-python-agent ?
Hi, You may want to take a look at: https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/README.md https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/oem/run.sh#L5-L10 It uses its own build scripts and builds image based on coreos https://coreos.com/docs/running-coreos/bare-metal/booting-with-pxe/ Unfortunately, Ironic python agent (aka IPA) and even ironic side agent driver are both under heavy development. Also agent driver hasn't been merged yet - http://lists.openstack.org/pipermail/openstack-dev/2014-April/032273.html From my experience, I was totally out of luck to try them on a previous week. Please let me know if you'll get better than I progress. Many thanks, Alex. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Glance] How about managing heat template like flavors in nova?
We discussed this with the Glance community back in January and it was agreed that we should extend Glance's scope to include Heat templates as well as other artifacts. I'm planning on submitting some patches around this during Juno. Adding the Glance tag as this is relevant to them as well. Original message From: Mike Spreitzer Date:04/19/2014 9:43 PM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Heat] How about managing heat template like flavors in nova? Gouzongmei gouzong...@huawei.com wrote on 04/19/2014 10:37:02 PM: We can supply APIs for getting, putting, adding and deleting current templates in the system, then when creating heat stacks, we just need to specify the name of the template. Look for past discussion of Heat Template Repository (Heater). Here is part of it: https://wiki.openstack.org/wiki/Heat/htr Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [SWIFT] Delete operation problem
Please provide the log file： /var/log/swift/swift.log AND /var/log/keystone/keystone.log On Mon, Apr 21, 2014 at 11:55 AM, Sumit Gaur sumitkg...@gmail.com wrote: Hi I using jclouds lib integrated with Openstack Swift+ keystone combination. Things are working fine except stability test. After 20-30 hours of test jclouds/SWIFT start degrading in TPS and keep going down over the time. 1) I am running the (PUT-GET-DEL) cycle in 10 parallel threads. 2) I am getting a lot of 409 and DEL failure for the response too from SWIFT. Can sombody help me what is going wrong here ? Thanks sumit ___ 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] [Neutron] review hour?
Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? thanks, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] branchless tempest and havana
Now that the branchless tempest idea is gaining steam, we have to address this issue along with how we handle releases that are not longer supported upstream. The current state of running master tempest against stable havana can be seen in the bottom two jenkins entries at https://review.openstack.org/#/c/86416/. The number of failures is manageable and they are due to a variety of issues including: 1. Changes to returned status failure codes 2. dictionary changes that are being checked by schemas now but were not in havana 3 havana failures that still need to bee investigated I would really like to see master running against havana in the gate which would provide value to the refstack effort as well as almost any one who is not doing CD. I proposed a grandfathering of havana by putting a skip decorator for that in master so we could get this in the gate and then figure out how much effort to put in getting more tests to run. This would also be a mechanism to allow upcoming work to not get tripped up on havana issues if we decide that is not worth it. Sean and Matt have objected to this idea. I really don't care that much exactly how we allow master to run against havana as long as the mechanism is in-tree. How do other folks feel about this, and are there other implementation suggestions? Another related issue is what happens when a stable release becomes unsupported given that many OpenStack users will continue to run unsupported releases. For example, there may be a desire to remove xml support in nova. When that happens, any one who still cares about running tempest against an older release will have to fork tempest. That is ok but there could be sharing opportunities. IIRC, this was the original motivation behind stable branches in the first place which was a little controversial at the time. -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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] [Neutron] review hour?
Hi Marios, Just my two cents. I have found these Review Jam's to be quite useful. Ironic has been able to accomplish quite a bit having this style of review, and I believe been able to provide good concise reviews back to the Devs. Chris Krelle On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.comwrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? thanks, marios ___ 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] [Neutron] review hour?
On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why does my Windows 7 VM running under Linux' KVM not use all the virtual processors?
This is a development list, and this sounds like a usage question so I would suggest that you ask on the users list instead: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Thanks. -Ben On 04/18/2014 09:36 PM, shenwei9008 wrote: I hava a problem that in windows 7 VM about the number of vCPU. Then I set up windows instance and give it 8cores, and in windonw7 Device Manager I check out that there are 8 cores. But In cmd.exe execute “wmic-cpu get * find it out that there are 2 single core, I don't know Why. And I modify /etc/libvirt/qemu/instance-*.xml as follow: |vcpu8/vcpu cpu topology sockets='1' cores='4' threads='2'/ /cpu| But this is modified after VM is set up. In according to my need, before VM setting up, VM can be given 8 cores not 2 single core. shenwei9008 ___ 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] [Tripleo] Reviews wanted for new TripleO elements
Please don't make review requests on the list. Details here: http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html Thanks. -Ben On 04/20/2014 02:44 PM, Macdonald-Wallace, Matthew wrote: Hi all, Can I please ask for some reviews on the following: https://review.openstack.org/#/c/87226/ - Install checkmk_agent https://review.openstack.org/#/c/87223/ - Install icinga cgi interface I already have a souple of +1s and jenkins is happy, all I need is +2 and +A! :) Thanks, Matt ___ 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] [nova] qemu1.7.1 vs qemu-kvm
This is a development list and your question sounds like a usage one. I suggest you ask it on the users list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Thanks. -Ben On 04/21/2014 05:34 AM, Arindam Choudhury wrote: Hi, As per I understand, onwards qemu 1.3 release all qemu-kvm features have been merged into upstream QEMU. So, if I use qemu 1.7.1 and use the -enable-kvm flag, the VM will use all kvm capabilities. I have a Openstack Grizzly deployment with nova-network and I want to use qemu 1.7.1. So, I compiled it from source and symlink qemu-system-x86_64 to qemu-kvm. I can boot virtual machines. But, is there any way I can avoid the symlinking and use qemu-system-x86_64 directly? Thanks, Arindam ___ 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] [Neutron] review hour?
+1 On Mon, Apr 21, 2014 at 8:54 AM, mar...@redhat.com mandr...@redhat.comwrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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] [Neutron] review hour?
+1 for the alternate slots. Ghe Rivero El 21/04/2014 17:57, mar...@redhat.com mandr...@redhat.com escribió: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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] [Neutron] review hour?
Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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] [Neutron] review hour?
Hi folks I'm +1 for Review Hour on IRC because it shorten communication round trip time. As Akihiro said, it won't solve everything, but we can improve it Best Nachi 2014-04-21 9:20 GMT-07:00 Akihiro Motoki amot...@gmail.com: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
+1 excellent idea! Fawad Khaliq (m) +1 408.966.2214 On Mon, Apr 21, 2014 at 9:31 AM, Nachi Ueno na...@ntti3.com wrote: Hi folks I'm +1 for Review Hour on IRC because it shorten communication round trip time. As Akihiro said, it won't solve everything, but we can improve it Best Nachi 2014-04-21 9:20 GMT-07:00 Akihiro Motoki amot...@gmail.com: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] nominating Victor Stinner for the Oslo core reviewers team
I propose that we add Victor Stinner (haypo on freenode) to the Oslo core reviewers team. Victor is a Python core contributor, and works on the development team at eNovance. He created trollius, a port of Python 3's tulip/asyncio module to Python 2, at least in part to enable a driver for oslo.messaging. He has been quite active with Python 3 porting work in Oslo and some other projects, and organized a sprint to work on the port at PyCon last week. The patches he has written for the python 3 work have all covered backwards-compatibility so that the code continues to work as before under python 2. Given his background, skills, and interest, I think he would be a good addition to the team. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
If scaling becomes the issue, you can always do review at sub-team level with at least two cores in each review meeting (say neutron-parity, ML2, Services, LBaaS, etc). But probably best to start with one meeting and hit that scale issue first. Regards, Mandeep On Mon, Apr 21, 2014 at 9:20 AM, Akihiro Motoki amot...@gmail.com wrote: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [barbican] Meeting Monday April 21st at 20:00 UTC
Hi Everyone, The Barbican team is hosting our weekly meeting today, Monday April 21, at 20:00 UTC in #openstack-meeting-alt Meeting agenda is avaialbe here https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed to add agenda items You can check this link http://time.is/0800PM_21_Apr_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting if you need to figure out what 20:00 UTC means in your time. -Douglas Mendizábal smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
On 21/04/14 19:20, Akihiro Motoki wrote: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays Akihiro thanks very much for sharing this link. I searched through openstack-dev for a discussion but missed the wiki :/ This is great - it makes more sense since as far as I can see the community is really distributed and so it is difficult for all cores to have consensus on a suitable time. As long as there is a minimum of 2 cores and any number of interested non-core (so that patches can actually get pushed where possible). The downside is losing the '2 meeting slots' advantage though I guess that really is a separate issue (weekly meeting time slot convenience?) that folks may i) agree/disagree is valid and ii) can be discussed as such. thanks! marios On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ 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 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
[openstack-dev] [Infra] Meeting Tuesday April 22nd at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday April 22nd, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to add a property to the API extension?
Alex, thanks for your answer very much. --jyh -Original Message- From: Alex Xu [mailto:x...@linux.vnet.ibm.com] Sent: Sunday, April 20, 2014 7:06 PM To: OpenStack Development Mailing List (not for usage questions); Christopher Yeoh Subject: Re: [openstack-dev] How to add a property to the API extension? On 2014年04月17日 05:25, Jiang, Yunhong wrote: Hi, Christopher, I have some question to the API changes related to https://review.openstack.org/#/c/80707/4/nova/api/openstack/compute/ plugins/v3/hypervisors.py , which adds a property to the hypervisor information. Hi, Yunhong, Chris may be available for a while. Let me answer your question. a) I checked the https://wiki.openstack.org/wiki/APIChangeGuidelines but not sure if it's ok to Adding a property to a resource representation as I did in the patch, or I need another extension to add this property? Does OK when conditionally added as a new API extension means I need another extension? You can add a property for v3 api directly for now. Because v3 api didn't release yet. We needn't wrong about any back-compatibility problem. if you add a property for v2 api you need another extension. b) If we can simply add a property like the patch is doing, would it requires to bump the version number? If yes, how should the version number be? Would it be like 1/2/3 etc, or should it be something like 1.1/1.2/2.1 etc? You needn't bump the version number for same reason v3 api didn't release yet. After v3 api released, we should bump the version, it would be like 1/2/3 etc. Thanks --jyh ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] nominating Victor Stinner for the Oslo core reviewers team
+1 from me. On Mon, Apr 21, 2014 at 12:39 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: I propose that we add Victor Stinner (haypo on freenode) to the Oslo core reviewers team. Victor is a Python core contributor, and works on the development team at eNovance. He created trollius, a port of Python 3's tulip/asyncio module to Python 2, at least in part to enable a driver for oslo.messaging. He has been quite active with Python 3 porting work in Oslo and some other projects, and organized a sprint to work on the port at PyCon last week. The patches he has written for the python 3 work have all covered backwards-compatibility so that the code continues to work as before under python 2. Given his background, skills, and interest, I think he would be a good addition to the team. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for tomorrow's meeting
You know the drill - fill in anything you wish to discuss. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_21st -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-sdk-php] Questions about user-facing documentation
Great questions, Shaunak. Yep I've been thinking about this for a while but not sure I have complete conclusions. More below. On Wed, Apr 16, 2014 at 9:06 PM, Shaunak Kashyap shaunak.kash...@rackspace.com wrote: Hi folks, As part of working on https://blueprints.launchpad.net/openstack-sdk-php/+spec/sphinx-docs, I've been looking at http://git.openstack.org/cgit/stackforge/openstack-sdk-php/tree/doc. Before I start making any changes toward that BP, however, I wanted to put forth a couple of overarching questions and proposals to the group: 1. Where and how should the user guide (i.e. Sphinx-generated docs) be published? Just to give some context and background, we have a User Guide with a Python SDK chapter: http://docs.openstack.org/user-guide/content/ A PHP SDK chapter might be a good addition, if you look at what we have and a pattern that exists, but I'd REALLY like us to break out of the book model and try to create a developer portal with a more page-centered model. What's that? For REST APIs, developers typically expect: developer.example.com - for docs, examples, code, links to download dev kits. api.example.com - for the actual api endpoints. What's tough for us is that there are thousands of OpenStack endpoints by now. A few years back we created api.openstack.org, but didn't realize there's an existing pattern of what devs look for from REST APIs. My bad, I hope we can correct that by creating developer.openstack.org. I know there's http://docs.openstack.org/. It seems like the logical place for these to be linked off of but where would that link go and what is the process of publishing our Sphinx-generated docs to that place? What's tough about correcting our doc domains going forward is that we have docs.openstack.org/developer for all the contributor dev docs. I do want to continue to separate out the audiences: the contributors are Python devs, the app devs are all languages. I'd like developer.openstack.org to be that landing point for all language devs looking to consume OpenStack cloud resources from any provider. Another difficulty is, how do we govern and review this content? Or do we? Does it fall under the Documentation Program mission? Right now our mission states we only cover core projects (the definition being just a handful of projects) and users as top priority. So I see a developer portal as a user priority. I'm not trying to do a land-grab as a PTL here, but trying to serve users as best we can, and this is definitely an underserved audience. The TC has a stance of code or it doesn't count so stackforge seems like a good starting place. Then core teams can form with deliverables, one of which can be docs. I think we're on the right track here, just making sure I state the potential decision point on how to govern SDKs and their docs and form communities around them. 2. How should the user guide(s) be organized? If I were a developer, I'm probably looking to use a particular OpenStack service (as opposed to learning about the PHP SDK without a particular orientation). So I propose organizing the PHP SDK user guide accordingly: as a set of user guides, each showing how to use the OpenStack PHP SDK for a particular service. Of course, Identity is common to all so it's documentation would somehow be included in each user guide. This is similar to how OpenStack organizes its REST API user guides - one per service (e.g. http://docs.openstack.org/api/openstack-object-storage/1.0/content/). Agreed. Please use the service name not our crazy code names. :) Further, within each user guide, I propose ordering the content according to popularity of use cases for that service (with some other constraints such as introducing concepts first, grouping similar concepts, etc.). This ensures that the reader can get what they want, from their perspective. Particularly, beginners would get what they came for without having to read too far into the documentation. As an example, I think http://git.openstack.org/cgit/stackforge/openstack-sdk-php/tree/doc/oo-tutorial.mddoes a fine job of walking the user through common Object Store use cases. I would just extend it to gradually introduce the user to more advanced use cases as well, thereby completing the user guide for Object Store. I think this approach also makes sense. Very user-centric. The only additional overarching organization you might consider is a few classic architectures: ecommerce, high performance computing, media serving, failover design, that sort of cross-service document might help this audience get going. Cc'ing Anne Gentle since she probably has informed opinions on both these questions. Sure do - I think some first steps should be: * Get developer.openstack.org domain name (pre-Summit) * Serve up the content from the api.openstack.org landing page from developer.openstack.org (pre-Summit) * Redirect content from api.openstack.org to developer.openstack.org
Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question
Hi, Despite there are some good use cases for the re-encryption I think it’s out of scope for a Load Balancer. We can defer that functionality to the VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node we should get all kind of encryption infrastructure “for free”. I like the Unix philosophy of little programs doing one task very well and can be chained. So in our case we might want to chain a firewall to a load balancer to a VPN to get the functionality we want. Thoughts? German From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Friday, April 18, 2014 9:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question Hi y'all! Carlos: When I say 'client cert' I'm talking about the certificate / key combination the load balancer will be using to initiate the SSL connection to the back-end server. The implication here is that if the back-end server doesn't like the client cert, it will reject the connection (as being not from a trusted source). By 'CA cert' I'm talking about the certificate (sans key) that the load balancer will be using the authenticate the back-end server. If the back-end server's server certificate isn't signed by the CA, then the load balancer should reject the connection. Of course, the use of a client cert or CA cert on the load balancer should be optional: As Clint pointed out, for some users, just using SSL without doing any particular authentication (on either the part of the load balancer or back-end) is going to be good enough. Anyway, the case for supporting re-encryption on the load-balancers has been solidly made, and the API proposal we're making will reflect this capability. Next question: When specific client certs / CAs are used for re-encryption, should these be associated with the pool or member? I could see an argument for either case: Pool (ie. one client cert / CA cert will be used for all members in a pool): * Consistency of back-end nodes within a pool is probably both extremely common, and a best practice. It's likely all will be accessed the same way. * Less flexible than certs associated with members, but also less complicated config. * For CA certs, assumes user knows how to manage their own PKI using a CA. Member (ie. load balancer will potentially use a different client cert / CA cert for each member individually): * Customers will sometimes run with inconsistent back-end nodes (eg. local nodes in a pool treated differently than remote nodes in a pool). * More flexible than certs associated with members, more complicated configuration. * If back-end certs are all individually self-signed (ie. no single CA used for all nodes), then certs must be associated with members. What are people seeing in the wild? Are your users using inconsistently-signed or per-node self-signed certs in a single pool? Thanks, Stephen On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Apr 18, 2014, at 12:36 PM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Dang. I was hoping this wasn't the case. (I personally think it's a little silly not to trust your service provider to secure a network when they have root access to all the machines powering your cloud... but I digress.) Part of the reason I was hoping this wasn't the case, isn't just because it consumes a lot more CPU on the load balancers, but because now we potentially have to manage client certificates and CA certificates (for authenticating from the proxy to back-end app servers). And we also have to decide whether we allow the proxy to use a different client cert / CA per pool, or per member. If you choose to support re-encryption on your service then you are free to charge for the extra CPU cycles. I'm convinced re-encryption and SslTermination is general needs to be mandatory but I think the API should allow them to be specified. Yes, I realize one could potentially use no client cert or CA (ie. encryption but no auth)... but that actually provides almost no extra security over the unencrypted case: If you can sniff the traffic between proxy and back-end server, it's not much more of a stretch to assume you can figure out how to be a man-in-the-middle. Yes but considering you have no problem advocating pure ssl termination for your customers(Decryption on the front end and plain text) on the back end I'm actually surprised this disturbs you. I would recommend users use Straight SSL passthrough or re-enecryption but I wouldn't force this on them should they choose naked encryption with no checking. Do any of you have a use case where some back-end members require SSL authentication from the proxy and some don't? (Again, deciding whether client cert / CA usage should attach to a pool or to a member.) When you say client Cert are
Re: [openstack-dev] [Neutron] review hour?
On Mon, Apr 21, 2014 at 11:56 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 19:20, Akihiro Motoki wrote: Hi, Previously Neutron team had ReviewDays [1] and core members made themselves focus on reviews and be available on IRC channel one or more day(s) of each week (as possible as they can). The number of neutron reviews has increased compared to that time and I am afraid one or two days reviews cannot deal with neutron reviews, but the similar mechanism might work to make things better. [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays Akihiro thanks very much for sharing this link. I searched through openstack-dev for a discussion but missed the wiki :/ This is great - it makes more sense since as far as I can see the community is really distributed and so it is difficult for all cores to have consensus on a suitable time. As long as there is a minimum of 2 cores and any number of interested non-core (so that patches can actually get pushed where possible). The downside is losing the '2 meeting slots' advantage though I guess that really is a separate issue (weekly meeting time slot convenience?) that folks may i) agree/disagree is valid and ii) can be discussed as such. It seems like the Neutron community has grown such that we have contributors from all over the world now. It may make sense to look at rotating the Neutron meeting so people can at least attend every other week. Alternatively, we could look at areas of focus for core team members (e.g. who's leading what sub-team), and schedule those for the alternating meetings as well. Either way, perhaps this is something to discuss at today's Neutron meeting. I've added it to the agenda. Thanks! Kyle thanks! marios On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com mandr...@redhat.com wrote: On 21/04/14 18:29, Kyle Mestery wrote: On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com mandr...@redhat.com wrote: Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? This is an interesting idea Marios, thanks for proposing it! Are you saying we should have a Review Hour on IRC, where we walk through XX number of reviews as a team? That's an interesting idea actually, and I'd be in favor of something like this. We could rotate timeslots so as to get everyone on the team (both core and non-core) a chance to participate. Can you attend our weekly meeting today [1] where we can discuss this as a team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the irc review hour is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421p1=137p2=179p3=136p4=37p5=166p6=248p7=196p8=47 Thanks! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings thanks, marios ___ OpenStack-dev mailing list
[openstack-dev] [neutron] Service VMs
For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
On Apr 21, 2014, at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: 1. There is nothing Neutron specific about service VMs. Agreed. VMs are one of several options for implementing a service. Managing the full lifecycle tends to touch on lots of OpenStack components and as Kyle wrote below there is nothing to specific to Neutron about them. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. +1 to starting a separate project on stackforge for this work. mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Absolutely. Feel free. On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua huangtian...@huawei.comwrote: I plan to register a blueprints in nova for record this. Can I? -邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: Hi all: Currently, the EC2 API of OpenStack only has tags support (metadata) for instances. And there has already a blueprint about to add support for volumes and volume snapshots using “metadata”. There are a lot of resources such as image/subnet/securityGroup/networkInterface(port) are supported add tags for AWS. I think we should support tags for these resources. There may be no property “metadata for these resources, so we should to add “metadata” to support the resource tags, the change related API. Hi Tianhua, In OpenStack, generally, the choice was made to use maps of key/value pairs instead of lists of strings (tags) to annotate objects exposed in the REST APIs. OpenStack REST APIs inconsistently call these maps of key/value pairs: * properties (Glance, Cinder Image, Volume respectively) * extra_specs (Nova InstanceType) * metadata (Nova Instance, Aggregate and InstanceGroup, Neutron) * metadetails (Nova Aggregate and InstanceGroup) * system_metadata (Nova Instance -- differs from normal metadata in that the key/value pairs are 'owned' by Nova, not a user...) Personally, I think tags are a cleaner way of annotating objects when the annotation is coming from a normal user. Tags represent by far the most common way for REST APIs to enable user-facing annotation of objects in a way that is easy to search on. I'd love to see support for tags added to any searchable/queryable object in all of the OpenStack APIs. I'd also like to see cleanup of the aforementioned inconsistencies in how maps of key/value pairs are both implemented and named throughout the OpenStack APIs. Specifically, I'd like to see this implemented in the next major version of the Compute API: * Removal of the metadetails term * All key/value pairs can only be changed by users with elevated privileged system-controlled (normal users should use tags) * Call all these key/value pair combinations properties -- technically, metadata is data about data, like the size of an integer. These key/value pairs are just data, not data about data. * Identify key/value pairs that are relied on by all of Nova to be a specific key and value combination, and make these things actual real attributes on some object model -- since that is a much greater guard for the schema of an object and enables greater performance by allowing both type safety of the underlying data and removes the need to search by both a key and a value. Best, -jay ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Hi Tianhua, Jay, A blueprint has already been submitted in this regard: https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit# We've been working to implement a generic tagging framework where tags are a first class resource and other resources can be associated with tags. Our first implementation focuses on neutron. For us at Ebay, this forms an important foundational framework to support flexible/customizable VPC architectures. A detailed design with extension/db/other changes has been drawn up and will be submitted for review to the group in the near future. Please do add your thoughts/reviews to it. Regards, Vijay On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes jaypi...@gmail.com wrote: Absolutely. Feel free. On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua huangtian...@huawei.comwrote: I plan to register a blueprints in nova for record this. Can I? -邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: Hi all: Currently, the EC2 API of OpenStack only has tags support (metadata) for instances. And there has already a blueprint about to add support for volumes and volume snapshots using “metadata”. There are a lot of resources such as image/subnet/securityGroup/networkInterface(port) are supported add tags for AWS. I think we should support tags for these resources. There may be no property “metadata for these resources, so we should to add “metadata” to support the resource tags, the change related API. Hi Tianhua, In OpenStack, generally, the choice was made to use maps of key/value pairs instead of lists of strings (tags) to annotate objects exposed in the REST APIs. OpenStack REST APIs inconsistently call these maps of key/value pairs: * properties (Glance, Cinder Image, Volume respectively) * extra_specs (Nova InstanceType) * metadata (Nova Instance, Aggregate and InstanceGroup, Neutron) * metadetails (Nova Aggregate and InstanceGroup) * system_metadata (Nova Instance -- differs from normal metadata in that the key/value pairs are 'owned' by Nova, not a user...) Personally, I think tags are a cleaner way of annotating objects when the annotation is coming from a normal user. Tags represent by far the most common way for REST APIs to enable user-facing annotation of objects in a way that is easy to search on. I'd love to see support for tags added to any searchable/queryable object in all of the OpenStack APIs. I'd also like to see cleanup of the aforementioned inconsistencies in how maps of key/value pairs are both implemented and named throughout the OpenStack APIs. Specifically, I'd like to see this implemented in the next major version of the Compute API: * Removal of the metadetails term * All key/value pairs can only be changed by users with elevated privileged system-controlled (normal users should use tags) * Call all these key/value pair combinations properties -- technically, metadata is data about data, like the size of an integer. These key/value pairs are just data, not data about data. * Identify key/value pairs that are relied on by all of Nova to be a specific key and value combination, and make these things actual real attributes on some object model -- since that is a much greater guard for the schema of an object and enables greater performance by allowing both type safety of the underlying data and removes the need to search by both a key and a value. Best, -jay ___ 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 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] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
On Mon, 2014-04-21 at 13:15 -0700, Vijay B wrote: Hi Tianhua, Jay, A blueprint has already been submitted in this regard: https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit# We've been working to implement a generic tagging framework where tags are a first class resource and other resources can be associated with tags. Our first implementation focuses on neutron. For us at Ebay, this forms an important foundational framework to support flexible/customizable VPC architectures. A detailed design with extension/db/other changes has been drawn up and will be submitted for review to the group in the near future. Please do add your thoughts/reviews to it. Hi Vijay, Please see my first comment on the above document. Tags are single strings, not key/value pairs. IMO, tags are also a **user-controlled** annotation of an object. What you are describing in that proposal seems more to be **system-controlled** annotation of objects using key/value properties... Best, -jay On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes jaypi...@gmail.com wrote: Absolutely. Feel free. On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua huangtian...@huawei.com wrote: I plan to register a blueprints in nova for record this. Can I? -邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: Hi all: Currently, the EC2 API of OpenStack only has tags support (metadata) for instances. And there has already a blueprint about to add support for volumes and volume snapshots using “metadata”. There are a lot of resources such as image/subnet/securityGroup/networkInterface(port) are supported add tags for AWS. I think we should support tags for these resources. There may be no property “metadata for these resources, so we should to add “metadata” to support the resource tags, the change related API. Hi Tianhua, In OpenStack, generally, the choice was made to use maps of key/value pairs instead of lists of strings (tags) to annotate objects exposed in the REST APIs. OpenStack REST APIs inconsistently call these maps of key/value pairs: * properties (Glance, Cinder Image, Volume respectively) * extra_specs (Nova InstanceType) * metadata (Nova Instance, Aggregate and InstanceGroup, Neutron) * metadetails (Nova Aggregate and InstanceGroup) * system_metadata (Nova Instance -- differs from normal metadata in that the key/value pairs are 'owned' by Nova, not a user...) Personally, I think tags are a cleaner way of annotating objects when the annotation is coming from a normal user. Tags represent by far the most common way for REST APIs to enable user-facing annotation of objects in a way that is easy to search on. I'd love to see support for tags added to any searchable/queryable object in all of the OpenStack APIs. I'd also like to see cleanup of the aforementioned inconsistencies in how maps of key/value pairs are both implemented and named throughout the OpenStack APIs. Specifically, I'd like to see this implemented in the next major version of the Compute API: * Removal of the metadetails term * All key/value pairs can only be changed by users with elevated privileged system-controlled (normal users should use tags) * Call all these key/value pair combinations properties -- technically, metadata is data about data, like the size of an integer. These key/value pairs are just data, not data about data. * Identify key/value pairs that are relied on by all
[openstack-dev] [Fuel] Migrate to Postrgresql 9
We use postgresql 8 on master node right now. At some point we will have to migrate to 9th version. And database migration can became painful part of master node upgrade at that point. At the moment part of our developers use psql9 in their environments and see no issues. Should we enforce upgrade before 5.0 release? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Migrate to Postrgresql 9
On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote: We use postgresql 8 on master node right now. At some point we will have to migrate to 9th version. And database migration can became painful part of master node upgrade at that point. At the moment part of our developers use psql9 in their environments and see no issues. Should we enforce upgrade before 5.0 release? ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Performance tests of ceilometer-collector and ceilometer-api with different backends
Hi team! In light of discussions about ceilometer backends, we decided to test performance of different storage backends with collector and api services because these services depend on backends availability. For the collector testing we are using not completely real data, we are generating looking like real samples with variable rate, sending them to the collector and metering the time of these messages processing. Testing result is the time between message receiving for recording message to db. For the api testing we are only comparing the time of requests to api with different backends. We have prepared a document with more detailed description of test plan and first results. This url: *https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing https://docs.google.com/document/d/1ARpKiYW2WN94JloG0prNcLjMeom-ySVhe8fvjXG_uRU/edit?usp=sharing* Please, add you cases and proposals for perfomance testing of collector and api to the document comments. Also you may use etherpad if it is more convenient. https://etherpad.openstack.org/p/performance_test_for_ceilometer_collector_and_api --- Best regards, Tyaptin Ilia, Intern Software Engineer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack/GSoC - Welcome!
Hi Team, Please join me in welcoming the following students to our GSoC program [1]. Congrats everyone. Now the hard work begins :) Have fun as well. Artem Shepelev Kumar Rishabh Manishanker Talusani Masaru Nomura Prashanth Raghu Tzanetos Balitsaris Victoria Martínez de la Cruz -- dims [1] https://www.google-melange.com/gsoc/org2/google/gsoc2014/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][sahara] Merging Sahara-UI Dashboard code into horizon
On 04/17/2014 03:06 PM, Chad Roberts wrote: Per blueprint https://blueprints.launchpad.net/horizon/+spec/merge-sahara-dashboard we are merging the Sahara Dashboard UI code into the Horizon code base. Over the last week, I have been working on making this merge happen and along the way some interesting questions have come up. Hopefully, together we can make the best possible decisions. Sahara is the Data Processing platform for Openstack. During incubation and prior to that, a horizon dashboard plugin was developed to work with the data processing api. Our original implementation was a separate dashboard that we would activate by adding to HORIZON_CONFIG and INSTALLED_APPS. The layout gave us a root of Sahara on the same level as Admin and Project. Under Sahara, we have 9 panels that make-up the entirety of the functionality for the Sahara dashboard. Over the past week there seems to be at least 2 questions that have come up. I'd like to get input from anyone interested. 1) Where should the functionality live within the Horizon UI? So far, 2 options have been presented. a) In a separate dashboard (same level as Admin and Project). This is what we had in the past, but it doesn't seem to fit the flow of Horizon very well. I had a review up for this method at one point, but it was shot down, so it is currently abandoned. b) In a panel group under Project. This is what I have stared work on recently. This seems to mimic the way other things have been integrated, but more than one person has disagreed with this approach. c) Any other options? 2) Where should the code actually reside? a) Under openstack_dashboards/dashboards/sahara (or data_processing). This was the initial approach when the target was a separate dashboard. b) Have all 9 panels reside in openstack_dashboards/dashboards/project. To me, this is likely to eventually make a mess of /project if more and more things are integrated there. c) Place all 9 data_processing panels under openstack_dashboards/dashboards/project/data_processing This essentially groups the code by panel group and might make for a bit less mess. d) Somewhere else? The current plan is to discuss this at the next Horizon weekly meeting, but even if you can't be there, please do add your thoughts to this thread. Thanks, Chad Roberts (crobertsrh on irc) hopefully (1) can be altered after a merge based on ux evaluation, so i'd say go w/ the most consistent approach to start (b). best, matt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? Who is going to drive the development work? Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ 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] [Neutron][LBaaS] SSL re-encryption scenario question
Excerpts from Eichberger, German's message of 2014-04-21 11:51:05 -0700: Hi, Despite there are some good use cases for the re-encryption I think it’s out of scope for a Load Balancer. We can defer that functionality to the VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node we should get all kind of encryption infrastructure “for free”. I like the Unix philosophy of little programs doing one task very well and can be chained. So in our case we might want to chain a firewall to a load balancer to a VPN to get the functionality we want. I think that only makes things simpler in an IPv6+IPSec situation (which, btw, would be fantastic and should be something we all drive OpenStack toward). But if you have to add something like OpenVPN to the load balancer service nodes, I'm not sure you're saving any complexity by using VPN vs. something like stunnel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Migrate to Postrgresql 9
+++ We already use PostgreSQL 9 on some of our dev boxes, and Nailgun works fine in fake mode and unit tests, so the risk of upgrading it now is minimal. I agree with Dmitry P. that it will cost us more to postpone it and make that upgrade a part of Fuel upgrade. -DmitryB On Mon, Apr 21, 2014 at 1:58 PM, Jay Pipes jaypi...@gmail.com wrote: On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote: We use postgresql 8 on master node right now. At some point we will have to migrate to 9th version. And database migration can became painful part of master node upgrade at that point. At the moment part of our developers use psql9 in their environments and see no issues. Should we enforce upgrade before 5.0 release? ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Dmitry Borodaenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Migrate to Postrgresql 9
+MAX_ULONG :-) On Tue, Apr 22, 2014 at 1:28 AM, Dmitry Borodaenko dborodae...@mirantis.com wrote: +++ We already use PostgreSQL 9 on some of our dev boxes, and Nailgun works fine in fake mode and unit tests, so the risk of upgrading it now is minimal. I agree with Dmitry P. that it will cost us more to postpone it and make that upgrade a part of Fuel upgrade. -DmitryB On Mon, Apr 21, 2014 at 1:58 PM, Jay Pipes jaypi...@gmail.com wrote: On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote: We use postgresql 8 on master node right now. At some point we will have to migrate to 9th version. And database migration can became painful part of master node upgrade at that point. At the moment part of our developers use psql9 in their environments and see no issues. Should we enforce upgrade before 5.0 release? ++ -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Dmitry Borodaenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NEUTRON] [IPv6] [VPNaaS] - IPSec by default on each Tenant router, the beginning of the Opportunistic Encryption era (rfc4322 ?)...
Have you considered filing a blueprint for this? It'd be good to keep this on the radar. https://wiki.openstack.org/wiki/Blueprints#Neutron -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] wrap_instance_event() swallows return codes....on purpose?
Hi all, In compute/manager.py the function wrap_instance_event() just calls function(). This means that if it's used to decorate a function that returns a value, then the caller will never see the return code. Is this a bug, or is the expectation that we would only ever use this wrapper for functions that don't return a value? Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-sdk-dotnet] High level architecture and extension doc
Hello All, For anyone interested in the Microsoft .NET side of things... The .NET SDK project has a high level architecture document with details on our design for extensibility. If anyone is interested, the doc can be found here: https://wiki.openstack.org/wiki/OpenStack-SDK-DotNet/HighLevelArch The project would love any comments or feedback that you might have! Thanks, --Wayne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] Selecting Compute tests by driver/hypervisor
I nearly opened a spec for this, but I'd really like to get some feedback first. One of the challenges I've seen lately for Nova teams not using KVM or Xen (Ironic and LXC are just a few) is how to properly run the subset of Compute tests that will run for their hypervisor or driver. Regexes are what Ironic went with, but I'm not sure how well that will work long term since it's very much dependent on naming conventions. The good thing is that the capabilities for each hypervisor/driver are well defined (https://wiki.openstack.org/wiki/HypervisorSupportMatrix), so it's just a matter of how to convey that information. I see a few ways forward from here: 1. Expand the compute_features_group config section to include all Compute actions and make sure all tests that require specific capabilities have skipIfs or raise a skipException. This options seems it would require the least work within Tempest, but the size of the config will continue to grow as more Nova actions are added. 2. Create a new decorator class like was done with service tags that defines what drivers the test does or does not work for, and have the definitions of the different driver capabilities be referenced by the decorator. This is nice because it gets rid of the config creep, but it's also yet another decorator, which may not be desirable. I'm going to continue working through both of these possibilities, but any feedback either solution would be appreciated. Daryl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-sdk-dotnet] High level architecture and extension doc
Hi Wayne, Thanks for sharing this! Alessandro On 22/apr/2014, at 01:41, Foley, Wayne wayne.fo...@hp.commailto:wayne.fo...@hp.com wrote: Hello All, For anyone interested in the Microsoft .NET side of things… The .NET SDK project has a high level architecture document with details on our design for extensibility. If anyone is interested, the doc can be found here: https://wiki.openstack.org/wiki/OpenStack-SDK-DotNet/HighLevelArch The project would love any comments or feedback that you might have! Thanks, --Wayne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Neutron][LBaaS] SSL re-encryption scenario question
German: I'm hearing from a lot of different sources / organizations on this list that re-encryption at the load balancer is a must-have feature. And I was already part of previous discussions on SSL functionality. ( https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL ) Also, even if the load balancer does support re-encryption on the back-end, this doesn't prevent users from using a VPN-based solution either. Stephen On Mon, Apr 21, 2014 at 11:51 AM, Eichberger, German german.eichber...@hp.com wrote: Hi, Despite there are some good use cases for the re-encryption I think it’s out of scope for a Load Balancer. We can defer that functionality to the VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node we should get all kind of encryption infrastructure “for free”. I like the Unix philosophy of little programs doing one task very well and can be chained. So in our case we might want to chain a firewall to a load balancer to a VPN to get the functionality we want. Thoughts? German *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net] *Sent:* Friday, April 18, 2014 9:07 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question Hi y'all! Carlos: When I say 'client cert' I'm talking about the certificate / key combination the load balancer will be using to initiate the SSL connection to the back-end server. The implication here is that if the back-end server doesn't like the client cert, it will reject the connection (as being not from a trusted source). By 'CA cert' I'm talking about the certificate (sans key) that the load balancer will be using the authenticate the back-end server. If the back-end server's server certificate isn't signed by the CA, then the load balancer should reject the connection. Of course, the use of a client cert or CA cert on the load balancer should be optional: As Clint pointed out, for some users, just using SSL without doing any particular authentication (on either the part of the load balancer or back-end) is going to be good enough. Anyway, the case for supporting re-encryption on the load-balancers has been solidly made, and the API proposal we're making will reflect this capability. Next question: When specific client certs / CAs are used for re-encryption, should these be associated with the pool or member? I could see an argument for either case: *Pool* (ie. one client cert / CA cert will be used for all members in a pool): * Consistency of back-end nodes within a pool is probably both extremely common, and a best practice. It's likely all will be accessed the same way. * Less flexible than certs associated with members, but also less complicated config. * For CA certs, assumes user knows how to manage their own PKI using a CA. *Member* (ie. load balancer will potentially use a different client cert / CA cert for each member individually): * Customers will sometimes run with inconsistent back-end nodes (eg. local nodes in a pool treated differently than remote nodes in a pool). * More flexible than certs associated with members, more complicated configuration. * If back-end certs are all individually self-signed (ie. no single CA used for all nodes), then certs must be associated with members. What are people seeing in the wild? Are your users using inconsistently-signed or per-node self-signed certs in a single pool? Thanks, Stephen On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Apr 18, 2014, at 12:36 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Dang. I was hoping this wasn't the case. (I personally think it's a little silly not to trust your service provider to secure a network when they have root access to all the machines powering your cloud... but I digress.) Part of the reason I was hoping this wasn't the case, isn't just because it consumes a lot more CPU on the load balancers, but because now we potentially have to manage client certificates and CA certificates (for authenticating from the proxy to back-end app servers). And we also have to decide whether we allow the proxy to use a different client cert / CA per pool, or per member. If you choose to support re-encryption on your service then you are free to charge for the extra CPU cycles. I'm convinced re-encryption and SslTermination is general needs to be mandatory but I think the API should allow them to be specified. Yes, I realize one could potentially use no client cert or CA (ie. encryption but no auth)... but that actually provides almost no extra security over the unencrypted case: If you can sniff the traffic between proxy and back-end server, it's not much more of a stretch to assume you can figure out how to be a man-in-the-middle. Yes but considering you have no problem
Re: [openstack-dev] [NEUTRON] [IPv6] [VPNaaS] - IPSec by default on each Tenant router, the beginning of the Opportunistic Encryption era (rfc4322 ?)...
This is interesting. How is key distribution handled when I want to use OE with someone like Google.com for example? On Thu, Apr 17, 2014 at 12:07 PM, Martinx - ジェームズ thiagocmarti...@gmail.com wrote: Guys, I here thinking about IPSec when with IPv6 and, one of the first ideas/wishes of IPv6 scientists, was to always deploy it with IPSec enabled, always (I've heard). But, this isn't well diffused by now. Who is actually using IPv6 Opportunistic Encryption?! For example: With O.E., we'll be able to make a IPv6 IPSec VPN with Google, so we can ping6 google.com safely... Or with Twitter, Facebook! Or whatever! That is the purpose of Opportunistic Encryption, am I right?! Then, with OpenStack, we might have a muiti-Region or even a multi-AZ cloud, based on the topology Per-Tenant Routers with Private Networks, for example, so, how hard it will be to deploy the Namespace routers with IPv6+IPSec O.E. just enabled by default? I'm thinking about this: * IPv6 Tenant 1 subnet A - IPv6 Router + IPSec O.E. - *Internet IPv6* - IPv6 Router + IPSec O.E. - IPv6 Tenant 1 subnet B So, with O.E., it will be simpler (from the tenant's point of view) to safely interconnect multiple tenant's subnets, don't you guys think?! Amazon in the other hand, for example, provides things like VPC Peering, or VPN Instances, or NAT instances, as a solution to interconnect creepy IPv4 networks... We don't need none of this kind of solutions when with IPv6... Right?! Basically, the OpenStack VPNaaS (O.E.) will come enabled at the Namespace Router by default, without the tenant even knowing it is there, but of course, we can still show that IPv6-IPSec-VPN at the Horizon Dashboard, when established, just for fun... But tenants will never need to think about it... =) And to share the IPSec keys, the stuff required for Opportunistic Encryption to gracefully works, each OpenStack in the wild, can become a *pod*, which will form a network of *pods*, I mean, independently owned *pods* which interoperate to form the *Opportunistic Encrypt Network of OpenStack Clouds*. I'll try to make a comparison here, as an analogy, do you guys have ever heard about the DIASPORA* Project? No, take a look: http://en.wikipedia.org/wiki/Diaspora_(social_network) I think that, OpenStack might be for the Opportunistic Encryption, what DIASPORA* Project is for Social Networks! If OpenStack can share its keys (O.E. stuff) in someway, with each other, we can easily build a huge network of OpenStacks, and then, each one will naturally talk with each other, using a secure connection. I would love to hear some insights from you guys! Please, keep in mind that I never deployed a IPSec O.E. before, this is just an idea I had... If I'm wrong, ignore this e-mail. References: https://tools.ietf.org/html/rfc4322 https://groups.google.com/d/msg/ipv6hackers/3LCTBJtr-eE/Om01uHUcf9UJ http://www.inrialpes.fr/planete/people/chneuman/OE.html Best! Thiago ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Looking for experienced guide to understand libvirt driver
Hi folks! I am working to add Sheepdog as a disk backend for the libvirt driver. I have a blueprint started and an early version of the code. However I am having trouble working my way thorough the code in the libvirt driver. The storage code doesn't feel vary modular to start with and my changes only seem to make it worse; e.g. adding more if blocks to 400 line functions. Is there an experienced contributor that could spend 30 minutes walking through parts of the code? - Blueprint: https://review.openstack.org/#/c/82584/ - Nova code: https://review.openstack.org/#/c/74148/ - Devstack code: https://review.openstack.org/#/c/89434/ Thanks, ~ Scott ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
Are the two NICs on the same or different networks? Currently there is a limitation of Nova that does not permit two NICs to be attached to the same Neutron network. -- Kevin Benton On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.comwrote: So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
They are on separate Networks. Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Kevin Benton blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, April 21, 2014 at 16:54 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working Are the two NICs on the same or different networks? Currently there is a limitation of Nova that does not permit two NICs to be attached to the same Neutron network. -- Kevin Benton On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.com wrote: So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][Summit] Topic review for Atlanta
I've pulled the summit talks into an etherpad (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who can review these within the system itself? Anyhow - please put comments in the etherpad and help select the sessions we'll do during the summit. I think we need to ensure reasonable coverage for: - CI - Finishing HA - Upgrades - Tuskar which arguably leaves just 2 slots for $whatever It seems to me we should focus on things where either: - we need to build basic consensus - crowdsourcing is at play I say that because we have many things being tackled and face time in the summit is precious - things that are straight engineering are not a particularly effective use of the time of a room with 30-80 people in it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Selecting Compute tests by driver/hypervisor
On Mon, Apr 21, 2014 at 10:52:39PM +, Daryl Walleck wrote: I nearly opened a spec for this, but I'd really like to get some feedback first. One of the challenges I've seen lately for Nova teams not using KVM or Xen (Ironic and LXC are just a few) is how to properly run the subset of Compute tests that will run for their hypervisor or driver. Regexes are what Ironic went with, but I'm not sure how well that will work long term since it's very much dependent on naming conventions. The good thing is that the capabilities for each hypervisor/driver are well defined (https://wiki.openstack.org/wiki/HypervisorSupportMatrix), so it's just a matter of how to convey that information. I see a few ways forward from here: If you're willing to drive this effort then please submit a spec review for it. These kind of discussions are perfect for doing in a spec review. 1. Expand the compute_features_group config section to include all Compute actions and make sure all tests that require specific capabilities have skipIfs or raise a skipException. This options seems it would require the least work within Tempest, but the size of the config will continue to grow as more Nova actions are added. This is the only path forward I can see for this issue. We're going to have to get better about consistently skipping based on config feature flags. This is also a big part of what is required moving forward with the branchless tempest work. [1] The config growth is really unavoidable considering the myriad of configuration possibilities and new features we get in OpenStack. We will just have to come up with some new ways and tooling to deal with the rapid growth in config file size. I honestly think the best approach for doing this is probably abstracting away individual conditional skip calls and make a unified feature skip decorator. Similar to what we already do for the requires_ext() decorator. That way we can have consistent logic and style around how to annotate what a test requires. 2. Create a new decorator class like was done with service tags that defines what drivers the test does or does not work for, and have the definitions of the different driver capabilities be referenced by the decorator. This is nice because it gets rid of the config creep, but it's also yet another decorator, which may not be desirable. The problem with this approach is that tempest isn't supposed to care about what is underneath the api layer. You should just tell it what the OpenStack deployment is capable of and let it go. If a driver or any other backend configuration doesn't support certain functionality then that should be an explicit knob in the config file. Also, another harm with this approach is that in effect we end up codifying in tempest, through decorators which seems really messy, the set of features that should work for a particular configuration/driver; which feels way outside the scope of tempest. I'm going to continue working through both of these possibilities, but any feedback either solution would be appreciated. Thanks, Matt Treinish [1] https://github.com/openstack/qa-specs/blob/master/specs/branchless-tempest.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Nova][Cold Migration] What about enable cold migration with taraget host
Just uploaded a nova-specs for review related to this topic: https://review.openstack.org/#/c/88755/ Can any of you help review and show your comments if any? 2014-01-13 22:56 GMT+08:00 Jay Lau jay.lau@gmail.com: Thanks Russell, will add this to V3 api ad leave V2 API as it is. Regards, Jay 2014/1/13 Russell Bryant rbry...@redhat.com On 01/13/2014 03:16 AM, Jay Lau wrote: Greetings, Now cold migration do not support migrate a VM instance with target host, what about add this feature to enable cold migration with a target host? Sounds reasonable to me. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Service VMs
On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 答复: 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Thanks very much. I have register the blueprints for nova. https://blueprints.launchpad.net/nova/+spec/add-tags-for-os-resources The simple plan is: 1. Add the tags api (create tags/delete tags/describe tags) for v3 api 2. Change the implement for instance from “metadata” to “tags” Your suggestions? Thanks 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月22日 3:46 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? Absolutely. Feel free. On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua huangtian...@huawei.commailto:huangtian...@huawei.com wrote: I plan to register a blueprints in nova for record this. Can I? -邮件原件- 发件人: Jay Pipes [mailto:jaypi...@gmail.commailto:jaypi...@gmail.com] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: Hi all: Currently, the EC2 API of OpenStack only has tags support (metadata) for instances. And there has already a blueprint about to add support for volumes and volume snapshots using “metadata”. There are a lot of resources such as image/subnet/securityGroup/networkInterface(port) are supported add tags for AWS. I think we should support tags for these resources. There may be no property “metadata for these resources, so we should to add “metadata” to support the resource tags, the change related API. Hi Tianhua, In OpenStack, generally, the choice was made to use maps of key/value pairs instead of lists of strings (tags) to annotate objects exposed in the REST APIs. OpenStack REST APIs inconsistently call these maps of key/value pairs: * properties (Glance, Cinder Image, Volume respectively) * extra_specs (Nova InstanceType) * metadata (Nova Instance, Aggregate and InstanceGroup, Neutron) * metadetails (Nova Aggregate and InstanceGroup) * system_metadata (Nova Instance -- differs from normal metadata in that the key/value pairs are 'owned' by Nova, not a user...) Personally, I think tags are a cleaner way of annotating objects when the annotation is coming from a normal user. Tags represent by far the most common way for REST APIs to enable user-facing annotation of objects in a way that is easy to search on. I'd love to see support for tags added to any searchable/queryable object in all of the OpenStack APIs. I'd also like to see cleanup of the aforementioned inconsistencies in how maps of key/value pairs are both implemented and named throughout the OpenStack APIs. Specifically, I'd like to see this implemented in the next major version of the Compute API: * Removal of the metadetails term * All key/value pairs can only be changed by users with elevated privileged system-controlled (normal users should use tags) * Call all these key/value pair combinations properties -- technically, metadata is data about data, like the size of an integer. These key/value pairs are just data, not data about data. * Identify key/value pairs that are relied on by all of Nova to be a specific key and value combination, and make these things actual real attributes on some object model -- since that is a much greater guard for the schema of an object and enables greater performance by allowing both type safety of the underlying data and removes the need to search by both a key and a value. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [neutron] Service VMs
+1 for its own project for service VM. On Tue, Apr 22, 2014 at 9:41 AM, Kyle Mestery mest...@noironetworks.comwrote: On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com wrote: For the upcoming Summit there are 3 sessions filed around Service VMs in Neutron. After discussing this with a few different people, I'd like to propose the idea that the Service VM work be moved out of Neutron and into it's own project on stackforge. There are a few reasons for this: How long do you anticipate the project needing to live on stackforge before it can move to a place where we can introduce symmetric gating with the projects that use it? The patches for this (look at the BP here [1]) have been in review for a while now as WIP. I think it's reasonable to expect that moving this to stackforge would let the authors and others interested collaborate faster. I expect this would take a cycle on stackforge before we could talk about other projects using this. But honestly, that's a better question for Isaku and Bob. Who is going to drive the development work? For that, I'm thinking Isaku and Bob (copied above) would be the ones driving it. But anyone else who is interested should feel free to jump in as well. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms Doug 1. There is nothing Neutron specific about service VMs. 2. Service VMs can perform services for other OpenStack projects. 3. The code is quite large and may be better served being inside it's own project. Moving the work out of Neutron and into it's own project would allow for separate velocity for this project, and for code to be shared for the Service VM work for things other than Neutron services. I'm starting this email thread now to get people's feedback on this and see what comments other have. I've specifically copied Isaku and Bob, who both filed summit sessions on this and have done a lot of work in this area to date. Thanks, Kyle ___ 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 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] [Neutron][LBaas] Single call API discussion
Hello Eugene! Are you talking about seeing the code in a simplified approach for a single create call using the current API objects, or one that uses objects created based on the proposal? I was experimenting over the weekend on getting a single create call in the current API model. I was able to implement it pretty easy but did run into some issues. Now, since this was just a quick test, and to save time I did not implement it the correct way, only a way in which it accepted a single create call and did everything else the usual way. If it were actually a blueprint and up for a merge I would have done it the proper way (and with everyone else's input). If you want to see that code let me know, its just on a branch of a fork. Nothing really much to see though, implemented in the easiest way possible. For what its worth though, it did speed up the creation of an actual load balancer by 75% on average. The current way to define an extension's resources and objects is using a dictionary that defines the resource, object expected for POSTs and PUTs, and plugin methods to be implemented. This dictionary is passed to the neutron API controller that does validation, defaulting, and checks if an attribute of an object is required and if it can be changed on posts and puts. This currently does not support defaults for 2nd level nested dictionary objects, and doesn't support validation, defaulting, or required attributes for any nesting level after the 2nd. This can easily be added in obviously (smells like recursion will come in handy), but it should be noted that just the resource and API object schema definitions for what we need for a single create call are not supported right now. Maybe there's some way to allow the extensions to define their own validation for their own resources and objects. That's probably another topic for another day, though. On Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote: 3. Could you describe the most complicated use case that your single-call API supports? Again, please be very specific here. Same data can be derived from the link above. Ok, I'm actually not seeing and complicated examples, but I'm guessing that any attributes at the top of the page could be expanded on according the the syntax described. Hmmm... one of the draw-backs I see with a one-call approach is you've got to have really good syntax checking for everything right from the start, or (if you plan to handle primitives one at a time) a really solid roll-back strategy if anything fails or has problems, cleaning up any primitives that might already have been created before the whole call completes. The alternative is to not do this with primitives... but then I don't see how that's possible either. (And certainly not easy to write tests for: The great thing about small primitives is their methods tend to be easier to unit test.) These are the good arguments! That's why I'd like to actually see the code (even simplified approach will could work as a first step), i thing it could do a lot of things clearer. Thanks, Eugene. ___ 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] [nova] Nova and LVM thin support
Just for live snapshot, my understanding is the instance state will not be saved. From: Cristian Tomoiaga [mailto:ctomoi...@gmail.com] Sent: Sunday, April 20, 2014 6:20 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova] Nova and LVM thin support Hello everyone, Before going any further with my implementation I would like to ask the community about the LVM thin support in Nova (not Cinder). The current implementation of the LVM backend does not support thin LVs. Does anyone believe it is a good idea to add support for this in Nova ? (I plan on adding support for my implementation anyway). I would also like to know where Red Hat stands on this, since they are primarily working on LVM. I've seen that LVM thin would be supported in RHEL 7 (?) so we may consider the thin target stable enough for production in Juno (cinder already has support for this since last year). I know there was ongoing work to bring a common storage library implementation to oslo or nova directly (Cinder's Brick library) but I heard nothing new for some time now. Maybe John Griffith has some thoughts on this. The reasons why support for LVM thin would be a nice addition should be well known especially to people working with LVM. Another question is related to how Nova treats snapshots when LVM is used as a backend (I hope I didn't miss anything in the code): Right now if we can't do a live snapshot, the instance state (memory) is being saved (libvirt virDomainManagedSave) and qemu-img is used to backup the instance disk(s). After that we resume the instance. Can we insert code to snapshot the instance disk so we only keep the instance offline just for a memory dump and copy the disk content from the snapshot created ? -- Regards, Cristian Tomoiaga ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [gantt] scheduler sub-group meeting agenda 4/22
Sorry for the late notice but I can't make it this week (I got called for jury duty). If people want to hang out on the IRC channel (#openstack-meeting at 1500 UTC) the list of things I wanted to go over was: 1) Open action items a. The wiki page is there (https://wiki.openstack.org/wiki/Gantt) with a link to an etherpad listing the current Juno summit scheduler session proposals. 2) Status on forklift efforts 3) Juno summit design sessions 4) Opens Topic vault (so we don't forget) 1 - no-db scheduler -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working
Hi, I'm guessing the scripts inside your guest is only setup to configure dhcp on the first interface. See /etc/network/interfaces Best, Aaron On Mon, Apr 21, 2014 at 4:59 PM, Hopper, Justin justin.hop...@hp.comwrote: They are on separate Networks. Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper From: Kevin Benton blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, April 21, 2014 at 16:54 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Openstack][Neutron] 2 NICs on Instance Creation not working Are the two NICs on the same or different networks? Currently there is a limitation of Nova that does not permit two NICs to be attached to the same Neutron network. -- Kevin Benton On Mon, Apr 21, 2014 at 4:44 PM, Hopper, Justin justin.hop...@hp.comwrote: So we are trying to create an instance (Precise Cloud Image) via nova with two NICs. It appears that the second Interface does not get configured. Does the Image Itself need to contain the configuration for the 2nd Interface or is this something the Neuton/Nova should take care of us automatically. I guess the same issue would arise if you would attach a 2nd Interface to the Instance after it was created (via nova interface-attach). Thanks, Justin Hopper Software Engineer - DBaaS irc: juice | gpg: EA238CF3 | twt: @justinhopper ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ 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] [gantt] scheduler sub-group meeting agenda 4/22
No worries, I'll handle it. -Sylvain Le 22 avr. 2014 06:29, Dugger, Donald D donald.d.dug...@intel.com a écrit : Sorry for the late notice but I can't make it this week (I got called for jury duty). If people want to hang out on the IRC channel (#openstack-meeting at 1500 UTC) the list of things I wanted to go over was: 1) Open action items a. The wiki page is there (https://wiki.openstack.org/wiki/Gantt) with a link to an etherpad listing the current Juno summit scheduler session proposals. 2) Status on forklift efforts 3) Juno summit design sessions 4) Opens Topic vault (so we don't forget) 1 - no-db scheduler -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ 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] [Neutron][LBaaS] SSL re-encryption scenario question
On Apr 21, 2014, at 1:51 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Despite there are some good use cases for the re-encryption I think it’s out of scope for a Load Balancer. We can defer that functionality to the VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node we should get all kind of encryption infrastructure “for free”. I think the feature should be apart of the API but I think it should be up to the vender to implement the feature or not since some venders can't. Plus an end user might not be able to append a vpn tunnel on the tail of the loadbalancer. I like the Unix philosophy of little programs doing one task very well and can be chained. So in our case we might want to chain a firewall to a load balancer to a VPN to get the functionality we want. I like that philosophy as well but must admit that the chains do break when versions or interactions of these components change. GNU's Autotools for example is a nightmare compared to Maven for Java. Even simpler tools like sort, tail, broke some tools I used to use. Monolithic tools like emacs likewise seem to be doing daily well. I get the impression that a the simple chained tool philosophy came from the era where individual programs had to be small enough to fit in memory and data would be spooled to tape as the intermediary pipe. Still a nice idea though for admins. Thoughts? German From: Stephen Balukoff [mailto:sbaluk...@bluebox.nethttp://bluebox.net] Sent: Friday, April 18, 2014 9:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question Hi y'all! Carlos: When I say 'client cert' I'm talking about the certificate / key combination the load balancer will be using to initiate the SSL connection to the back-end server. The implication here is that if the back-end server doesn't like the client cert, it will reject the connection (as being not from a trusted source). By 'CA cert' I'm talking about the certificate (sans key) that the load balancer will be using the authenticate the back-end server. If the back-end server's server certificate isn't signed by the CA, then the load balancer should reject the connection. Of course, the use of a client cert or CA cert on the load balancer should be optional: As Clint pointed out, for some users, just using SSL without doing any particular authentication (on either the part of the load balancer or back-end) is going to be good enough. Anyway, the case for supporting re-encryption on the load-balancers has been solidly made, and the API proposal we're making will reflect this capability. Next question: When specific client certs / CAs are used for re-encryption, should these be associated with the pool or member? I could see an argument for either case: Pool (ie. one client cert / CA cert will be used for all members in a pool): * Consistency of back-end nodes within a pool is probably both extremely common, and a best practice. It's likely all will be accessed the same way. * Less flexible than certs associated with members, but also less complicated config. * For CA certs, assumes user knows how to manage their own PKI using a CA. Member (ie. load balancer will potentially use a different client cert / CA cert for each member individually): * Customers will sometimes run with inconsistent back-end nodes (eg. local nodes in a pool treated differently than remote nodes in a pool). * More flexible than certs associated with members, more complicated configuration. * If back-end certs are all individually self-signed (ie. no single CA used for all nodes), then certs must be associated with members. What are people seeing in the wild? Are your users using inconsistently-signed or per-node self-signed certs in a single pool? Thanks, Stephen On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Apr 18, 2014, at 12:36 PM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Dang. I was hoping this wasn't the case. (I personally think it's a little silly not to trust your service provider to secure a network when they have root access to all the machines powering your cloud... but I digress.) Part of the reason I was hoping this wasn't the case, isn't just because it consumes a lot more CPU on the load balancers, but because now we potentially have to manage client certificates and CA certificates (for authenticating from the proxy to back-end app servers). And we also have to decide whether we allow the proxy to use a different client cert / CA per pool, or per member. If you choose to support re-encryption on your service then you are free to charge for the extra CPU cycles. I'm convinced re-encryption and SslTermination is general needs to be mandatory but I think the API
Re: [openstack-dev] 退出邮件列表
Hi xueyan, You can do it by yourself via the following link: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Li Ma - Original Message - From: l adolphxue...@163.com To: openstack-dev@lists.openstack.org Sent: 星期一, 2014年 4 月 21日 上午 10:56:08 Subject: [openstack-dev] 退出邮件列表 您好： 由于一些情况，我想退出该邮件列表。谢谢！ xueyan 2014.4.21 ___ 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
