Re: [openstack-dev] [cinder]The backend-group concept in Cinder

Hi John, User case 1: The backends in backend-group-1 have SSD disk, more memory . The backend-group-1 can provide higher performance to user. The other backends in backend-group-2 have HHD disk, more capacity. The backend-group-2 can provide more storage space to u

Re: [openstack-dev] [Higgins][Zun] Project roadmap

On 13/06/16 18:46 +, Hongbin Lu wrote: -Original Message- From: Sudipto Biswas [mailto:sbisw...@linux.vnet.ibm.com] Sent: June-13-16 1:43 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap On Monday 13 June 2016 06:57 PM, Flavio

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

> On 14 Jun 2016, at 07:34, Morgan Fainberg wrote: > > > > On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash > wrote: > So, I think it depends what level of compatibility we are aiming at. Let me > articulate them, and we can agree which we want: > > C1) In all version

Re: [openstack-dev] [cinder]The backend-group concept in Cinder

As long as each backend has a unique name, you can key the type to a list of backend names if there's no useful capabilities to key off. No restart required. On 14 June 2016 at 10:16, chen ying wrote: > Hi John, > > > > User case 1: > The backends in backend-group-1 have SSD disk,

Re: [openstack-dev] [nova] Let me know if you have an approved spec but unapproved blueprint

Hi https://blueprints.launchpad.net/nova/+spec/remove-compute-compute-communication - bp is not approved, but the spec is. Timofey On Tue, Jun 14, 2016 at 3:47 AM, joehuang wrote: > Hi, Matt, > > Thank you for the clarification. > > Best Regards > Chaoyi Huang ( Joe Huang ) > > > -Original

Re: [openstack-dev] [nova] Initial oslo.privsep conversion?

On Fri, Jun 10, 2016 at 09:51:03AM +1000, Tony Breeds wrote: > On Fri, Jun 10, 2016 at 08:24:34AM +1000, Michael Still wrote: > > On Fri, Jun 10, 2016 at 7:18 AM, Tony Breeds > > wrote: > > > > > On Wed, Jun 08, 2016 at 08:10:47PM -0500, Matt Riedemann wrote: > > > > > > > Agreed, but it's the wo

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

On Mon, Jun 13, 2016 at 11:35:17PM +, Peters, Rawlin wrote: > That said, there are currently a couple of vif-plugging strategies > we could go with for wiring trunk ports for OVS, each of them > requiring varying levels of os-vif augmentation: > > Strategy 1) When Nova is plugging a trunk port,

Re: [openstack-dev] [kolla][security] Finishing the job on threat analysis for Kolla

I have returned from #drownload and I'm super keen to get ontop of this, in this email I'll just try to tie a few different threads together. The etherpad we used at the summit, along with the Sequence Diagram texts are online [1] are we happy to continue using web sequence diagrams? I think the r

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

On Mon, Jun 13 2016, Doug Hellmann wrote: > I'm trying to pull together some information about contributions > that OpenStack community members have made *upstream* of OpenStack, > via code, docs, bug reports, or anything else to dependencies that > we have. At quick glance, I've contributed to M

Re: [openstack-dev] [heat][TripleO] Adding interfaces to environment files?

On 06/13/2016 03:51 PM, Ben Nemec wrote: On 06/08/2016 07:00 AM, Jiri Tomasek wrote: On Wed, Jun 8, 2016 at 11:23 AM, Steven Hardy mailto:sha...@redhat.com>> wrote: On Tue, Jun 07, 2016 at 04:53:12PM -0400, Zane Bitter wrote: > On 07/06/16 15:57, Jay Dobies wrote: > > > > >

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Strategy 1 is being pitched to make it easier to implement with the current internals of the Neutron OVS agent (using integration bridge plugging events). I'm not sure that's better architecturally long term because the OVS agent has to have logic to wire up patch ports for the sub-interfaces anywa

Re: [openstack-dev] [cinder]The backend-group concept in Cinder

Hi Duncan Thomas, Does you means we can create a volume type include list of backend names(such as: backend_name=" name1 name2 name3 name4"), so when we create a volume, we can use the volume type to choose one backend from these list of backend names(name1,name2,name3,name4)? But in th

Re: [openstack-dev] [nova] Let me know if you have an approved spec but unapproved blueprint

Hi, I just fixed up Timofei's BP. I went through all the specs and spotted another 5 or 6 that were out of sync. There may well be others I didn't spot. Thanks, johnthetubaguy On 14 June 2016 at 09:17, Timofei Durakov wrote: > Hi > > https://blueprints.launchpad.net/nova/+spec/remove-compute-co

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

On Tue, Jun 14, 2016 at 02:10:52AM -0700, Kevin Benton wrote: > Strategy 1 is being pitched to make it easier to implement with the current > internals of the Neutron OVS agent (using integration bridge plugging > events). I'm not sure that's better architecturally long term because the > OVS agent

Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

On Sun, Jun 12 2016, Monty Taylor wrote: > I will call hogwash on that. That we install files such as that which > are actually code has been a deployer nightmare since day one, and the > solution is not to make pip smarter, it's to stop installing such files. > > NOW - if it's quite literally a f

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

In strategy 2 we just pass 1 bridge name to Nova. That's the one that is ensures is created and plumbs the VM to. Since it's not responsible for patch ports it doesn't need to know anything about the other bridge. On Tue, Jun 14, 2016 at 2:30 AM, Daniel P. Berrange wrote: > On Tue, Jun 14, 2016

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote: > In strategy 2 we just pass 1 bridge name to Nova. That's the one that is > ensures is created and plumbs the VM to. Since it's not responsible for > patch ports it doesn't need to know anything about the other bridge. Ok, so we're alr

[openstack-dev] [neutron] VxLAN UDP port configuration

Hi everyone, this is actually a follow-up from this previous thread and bug: http://lists.openstack.org/pipermail/openstack-dev/2015-March/059623.html https://bugs.launchpad.net/neutron/+bug/1373359 The OVS agent supports the "vxlan_udp_port" parameter in its configuration file (for Linux Bridge

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Yep, and both strategies depend on that "create if not exists" logic so it makes sense to at least get that implemented while we continue to argue about which strategy to use. On Jun 14, 2016 02:43, "Daniel P. Berrange" wrote: > On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote: > > In

Re: [openstack-dev] [tempest] Discussion on to enable "Citrix XenServer CI" to vote openstack/tempest

Hi Jianghua and QA team, Thank you for bringing this up. IMO, it's good to make it voting in openstack/tempest. Because it's already a voting job in Nova and seems having enough stability. And we should keep test stability for projects. My concern is that the resource of "Citrix XenServer CI". D

Re: [openstack-dev] [tempest] Discussion on to enable "Citrix XenServer CI" to vote openstack/tempest

Hi Masayuki, We have been running against Tempest and commenting for many months (years?) and run in the Rackspace public cloud so have no capacity issues. Indeed the execution time is longer than other jobs, because we actually have to use double nesting (Devstack running on Ubuntu in a VM und

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1 On Tue, Jun 14, 2016 at 12:18 AM, Henry Fourie wrote: > +1 > > > > *From:* Cathy Zhang > *Sent:* Monday, June 13, 2016 11:36 AM > *To:* openstack-dev@lists.openstack.org; Cathy Zhang > *Subject:* [openstack-dev] [neutron][networking-sfc] Proposing Mohan > Kumar for networking-sfc core > > > >

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1 On Tue, Jun 14, 2016 at 4:01 PM, P. Ramanjaneya Reddy wrote: > +1 > > On Tue, Jun 14, 2016 at 12:18 AM, Henry Fourie > wrote: > >> +1 >> >> >> >> *From:* Cathy Zhang >> *Sent:* Monday, June 13, 2016 11:36 AM >> *To:* openstack-dev@lists.openstack.org; Cathy Zhang >> *Subject:* [openstack-dev

[openstack-dev] [TripleO] Delopment environment census refresh

Hi All, A while back we populated a etherpad[1] with details of our individual development environments, the idea here was that we can point newcomers to this page to give them an idea of what hard ware its possible to deploy triple on and what tools we use drive it. Its been just over 3 mo

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Well in terms of the ovs plugin change for strategy 2 that requires a single function call Here: https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L109 And here: https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L84 and one new function in https://github.co

[openstack-dev] Nova API extensions removal plan

Nova is getting towards it's final phases of the long term arc to really standardize the API, which includes removing the API extensions facility. This has been a long arc that was started in Atlanta. And has been talked about in a lot of channels, but some interactions this past week made us reali

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

On 06/14/2016 11:43 AM, Daniel P. Berrange wrote: Ok, so we're already passing that bridge name - all we need change is make sure it is actuall created if it doesn't already exist ? If so that sounds simple enough to add to os-vif - we already have exactly the same logic for the linux_bridge pl

[openstack-dev] [murano] [murano-apps] Murano apps core changes

Last week a patch [1] has been landed, that added murano-apps-core group, responsible for murano-apps repositories. Right now this group only includes murano-core. As a continuation of transition of responsibilities for murano-apps (started here [2]) I’m going to add Sergey Kraynev, who is leadi

Re: [openstack-dev] [Openstack] OpenStack Newton B1 for Ubuntu 16.04 LTS and Ubuntu 16.10

Very Cool! Wait this for long. we(kolla project) will enable the ubuntu binary deploy gate in the CI. On Mon, Jun 13, 2016 at 8:54 PM, Corey Bryant wrote: > Hi All, > > The Ubuntu OpenStack team is pleased to announce the general availability > of the OpenStack Newton B1 milestone in Ubuntu 16.1

Re: [openstack-dev] [Higgins][Zun] Project roadmap

Hi all, it looks like Glare may cover some (or all) your use cases. To understand the functionality proposed to Glare I suggest you to read this: https://review.openstack.org/#/c/283136/. It would be cool if Glare supports everything you need. If you need something else please add a comment, we wi

Re: [openstack-dev] [nova] theoretical race between live migration and resource audit?

Hi Chris, you are right – and I think there are several synchronization issues in the code there. The migration process should be synchronized as it is in build_run_instance etc. At the moment if pre_live_migrate fails due to an RPC timeout (i.e. it takes too long for some reason) the rollback

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Hi John, I submit one patch to every private repo, the create port chain can work now. Regards, Juno Zhu IBM China Development Labs (CDL) Cloud IaaS Lab Email: na...@cn.ibm.com 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, Shanghai, China (201203) From:

Re: [openstack-dev] [ceilometer] [stable] Re: [Openstack-stable-maint] Stable check of openstack/ceilometer failed

i don't know if anyone is looking at this -- i'm not sure where this test is even run. i usually let mriedem yell at me but i take it he has bigger things on his plate now :) this seems like a pretty simple fix from the error output[1]. i guess my question is: should the correct fix be to cap o

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

On 13 June 2016 at 22:22, Terry Wilson wrote: > > So basically, as long as we try to plug ports with different MTUs into > the same bridge, we are utilizing a bug in Open vSwitch, that may break us > any time. > > > > I guess our alternatives are: > > - either redesign bridge setup for openvswitc

[openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

os-brick 1.4 was released over the weekend, and was the first os-brick to include privsep. We got a really odd failure rate in the grenade-multinode jobs (1/3 - 1/2) after wards which was super non obvious why. Hemma looks to have figured it out (this is a summary of what I've seen on IRC to pull i

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

hi, i actually told him to raise it here. since our team is scattered pretty globally, we use the ML for this when we want a few more eyes on something debatable in a patch. for me, my concern is whether there's a strong desire to have ordering of severity to be done based on context vs alphab

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1 On 6/13/2016 14:35, Cathy Zhang wrote: Mohan has been working on networking-sfc project for over one year. He is a key contributor to the design/coding/testing of SFC CLI, SFC Horizon, as well as ONOS controller support for SFC functionality. He has been great at helping out with bug fixes,

[openstack-dev] [Performance] No IRC meeting today

Folks, today we should have the Performance working group IRC meeting, but I have to announce that I won't be able to attend it today as well as several more folks. Therefore let's decline this event for today and make it happen next week due to the usual schedule. I'm really sorry for the inconv

Re: [openstack-dev] [neutron][SFC]

Hi Mohan, Thanks your information. I see there is restriction check in OVS flow classifier driver, but you can see that in the flow classifier table, the column logical_source_port nullable is false, this affects every driver. Regards, Juno Zhu IBM China Development Labs (CDL) Cloud IaaS Lab

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1... Welcome Mohan! On Tue, Jun 14, 2016 at 4:07 PM, Antony Silvester wrote: > +1 > > > On Tue, Jun 14, 2016 at 4:01 PM, P. Ramanjaneya Reddy < > ramanji...@gmail.com> wrote: > >> +1 >> >> On Tue, Jun 14, 2016 at 12:18 AM, Henry Fourie >> wrote: >> >>> +1 >>> >>> >>> >>> *From:* Cathy Zhang >

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

Hi Doug, The pyngus library - it was originally designed as part of the oslo.messaging amqp1 driver but proved to be useful as a stand alone messaging API built for proton. https://pypi.python.org/pypi/pyngus On Mon, Jun 13, 2016 at 3:11 PM, Doug Hellmann wrote: > I'm trying to pull together so

[openstack-dev] [openstack-ansible] Deeper diffs in OSA releases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey folks, Every OpenStack-Ansible release consists of SHA bumps for roles as well as OpenStack services (like keystone, nova, and glance). However, tracking the diffs of the changes in those OpenStack services can be challenging. It's difficul

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote: [snip] > The crux of the problem is that os-brick 1.4 and privsep can't be used > without a config file change during the upgrade. Which violates our > policy, because it breaks rolling upgrades. os-vif support is going to face exactly

Re: [openstack-dev] [openstack-ansible] Deeper diffs in OSA releases

On 14 June 2016 at 13:50, Major Hayden wrote: > > > Every OpenStack-Ansible release consists of SHA bumps for roles as well as > OpenStack services (like keystone, nova, and glance). However, tracking > the diffs of the changes in those OpenStack services can be challenging. > It's difficult to t

Re: [openstack-dev] [Aodh] Ordering Alarm severity on context

On Tue, Jun 14 2016, gordon chung wrote: > for me, my concern is whether there's a strong desire to have ordering of > severity to be done based on context vs alphabetically, as it does now. if we > want ordering to be done by context, the followup would be whether we want to > support additional

[openstack-dev] [magnum] Stable/liberty functional tests

Hi, There was work on a patch [1] to fix the liberty stable branch. However, we are running into problems with the functional tests, because the functional tests were set up differently in liberty eg. The current [2] magnum.yaml compared to the old one [3]. This leads us with two options to t

Re: [openstack-dev] [TripleO] Proposal for a new tool: dlrn-repo

On 06/13/2016 05:58 PM, Derek Higgins wrote: > On 13 June 2016 at 21:29, Ben Nemec wrote: >> So our documented repo setup steps are three curls, a sed, and a >> multi-line bash command. And the best part? That's not even what we >> test. The commands we actually use in tripleo.sh --repo-setup c

[openstack-dev] [all][tc] Require a level playing field for OpenStack projects

Hi everyone, I just proposed a new requirement for OpenStack "official" projects, which I think is worth discussing beyond the governance review: https://review.openstack.org/#/c/329448/ From an upstream perspective, I see us as being in the business of providing open collaboration playing f

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200: > Hi everyone, > > I just proposed a new requirement for OpenStack "official" projects, > which I think is worth discussing beyond the governance review: > > https://review.openstack.org/#/c/329448/ > > From an upstream persp

Re: [openstack-dev] [openstack-ansible] Deeper diffs in OSA releases

On 06/14/2016 08:08 AM, Jesse Pretorius wrote: > That's neat Major! It'd be great to extend it to also do the diffs for the > included roles, both OpenStack and non-OpenStack to get full coverage. That shouldn't be too difficult to implement. I'd need to refactor the comparison code so that it

[openstack-dev] [ironic] Launchpad permissions

Hi all, This morning I did a quick audit of the launchpad projects for our various projects, and found some projects that have some incorrect permissions/ownership things. Can the current maintainers of these projects please change the "driver" and "maintainer" fields on the home page to "ironic-d

Re: [openstack-dev] [nova] NUMA, huge pages, and scheduling

On 06/13/2016 02:17 PM, Paul Michali wrote: Hmm... I tried Friday and again today, and I'm not seeing the VMs being evenly created on the NUMA nodes. Every Cirros VM is created on nodeid 0. I have the m1/small flavor (@GB) selected and am using hw:numa_nodes=1 and hw:mem_page_size=2048 flavor-ke

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On Jun 14, 2016, at 8:57 AM, Thierry Carrez wrote: > A few months ago we had the discussion about what "no open core" means in > 2016, in the context of the Poppy team candidacy. With our reading at the > time we ended up rejecting Poppy partly because it was interfacing with > proprietary tec

Re: [openstack-dev] [nova] theoretical race between live migration and resource audit?

Under normal circumstances a bit of resource tracking error is generally okay. However in the case of CPU pinning it's a major problem because it's not caught at instance boot time, so you end up with two instances that both think they have exclusive access to one or more host CPUs. If we get

Re: [openstack-dev] [Neutron] [sr-iov] rename *device* config options to *interface*

On 06/13/2016 01:22 AM, Andreas Scheuring wrote: While reviewing [1] I got hung up on the terms "device" and "interface". It seems like in sr-iov agent they are used in a different manner than in the linuxbridge agent. For Example the lb agent uses a config option "physical_interface_mappings" (

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On 14/06/2016 15:00, Thierry Carrez wrote: > Hi everyone, > > I just proposed a new requirement for OpenStack "official" projects, > which I think is worth discussing beyond the governance review: > > https://review.openstack.org/#/c/329448/ > > From an upstream perspective, I see us as being in t

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

On 06/13/2016 01:11 PM, Doug Hellmann wrote: I'm trying to pull together some information about contributions that OpenStack community members have made *upstream* of OpenStack, via code, docs, bug reports, or anything else to dependencies that we have. If you've made a contribution of that sort

[openstack-dev] [new][oslo] oslo.middleware 3.13.0 release (newton)

We are happy to announce the release of: oslo.middleware 3.13.0: Oslo Middleware library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware With package available at: https://pypi.python.org/pypi/oslo.mi

[openstack-dev] [new][oslo] oslo.privsep 1.8.0 release (newton)

We are delighted to announce the release of: oslo.privsep 1.8.0: OpenStack library for privilege separation This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at: https://pypi.python.

[openstack-dev] [new][oslo] oslo.policy 1.10.0 release (newton)

We are eager to announce the release of: oslo.policy 1.10.0: Oslo Policy library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.policy With package available at: https://pypi.python.org/pypi/oslo.policy Please

[openstack-dev] [new][oslo] oslo.vmware 2.9.0 release (newton)

We are amped to announce the release of: oslo.vmware 2.9.0: Oslo VMware library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware With package available at: https://pypi.python.org/pypi/oslo.vmware Please

[openstack-dev] [new][oslo] oslo.serialization 2.9.0 release (newton)

We are glad to announce the release of: oslo.serialization 2.9.0: Oslo Serialization library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.serialization With package available at: https://pypi.python.org/pypi/

[openstack-dev] [new][oslo] tooz 1.39.0 release (newton)

We are jubilant to announce the release of: tooz 1.39.0: Coordination library for distributed systems. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/tooz With package available at: https://pypi.python.org/pypi/tooz

[openstack-dev] [new][oslo] oslo.log 3.10.0 release (newton)

We are happy to announce the release of: oslo.log 3.10.0: oslo.log library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log With package available at: https://pypi.python.org/pypi/oslo.log Please report issu

[openstack-dev] [new][oslo] oslo.versionedobjects 1.11.0 release (newton)

We are overjoyed to announce the release of: oslo.versionedobjects 1.11.0: Oslo Versioned Objects library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects With package available at: https://pypi.

[openstack-dev] [new][oslo] taskflow 2.2.0 release (newton)

We are psyched to announce the release of: taskflow 2.2.0: Taskflow structured state management library. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow With package available at: https://pypi.python.org/pyp

[openstack-dev] [new][oslo] oslo.reports 1.10.0 release (newton)

We are glad to announce the release of: oslo.reports 1.10.0: oslo.reports library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.reports With package available at: https://pypi.python.org/pypi/oslo.reports Ple

[openstack-dev] [new][oslo] oslo.messaging 5.4.0 release (newton)

We are thrilled to announce the release of: oslo.messaging 5.4.0: Oslo Messaging API This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging With package available at: https://pypi.python.org/pypi/oslo.messagi

[openstack-dev] [puppet] Re: weekly meeting #85

On Mon, Jun 13, 2016 at 8:57 AM, Emilien Macchi wrote: > Hi Puppeteers! > > We'll have our weekly meeting tomorrow at 3pm UTC on > #openstack-meeting-4. > > Here's a first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160614 > >

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

On Jun 14, 2016 00:46, "Henry Nash" wrote: > > On 14 Jun 2016, at 07:34, Morgan Fainberg > wrote: > > > > On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash wrote: > >> So, I think it depends what level of compatibility we are aiming at. Let >> me articulate them, and we can agree which we want: >> >>

Re: [openstack-dev] [Higgins][Zun] Project roadmap

I think there's a weird cycle in plugging into nova too... Say the cloud has no native container support added except for Zun. The container api Zun provides could be mapped to a Zun plugin that: 1. nova boot --image centos --user-data 'yum install -y docker; yum start docker; ' 2. starts

Re: [openstack-dev] [Openstack] OpenStack Newton B1 for Ubuntu 16.04 LTS and Ubuntu 16.10

I can't wait to try "VLAN Aware VMs"... But it is not there yet... Maybe on Newton B2... https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms This is *very* important for NFV Instances on OpenStack... Many telcos needs this... Cheers! Thiago On 14 June 2016 at 07:25, Jeffrey Zhang wro

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

Some counter arguments for keeping them in: * It gives the developers of the code that's being plugged into a better view of how the plugin api is used and what might break if they change it. * Vendors don't tend to support drivers forever. Often they drop support for a driver once the "new" ha

[openstack-dev] [new][winstackers] os-win 1.0.0 release (newton)

We are happy to announce the release of: os-win 1.0.0: Windows / Hyper-V library for OpenStack projects. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/os-win With package available at: https://pypi.python.org/pypi/

[openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

Hello, I'd need some help with using the SFC implementation in openstack. I use liberty version of devstack + liberty branch of networking-sfc. It's not clear to me if the SFC instance and it's networks should be separated from the remaining virtual network topology or if it should be connected

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On 06/14/2016 10:44 AM, Hayes, Graham wrote: > On 14/06/2016 15:00, Thierry Carrez wrote: >> Hi everyone, >> >> I just proposed a new requirement for OpenStack "official" projects, >> which I think is worth discussing beyond the governance review: >> >> https://review.openstack.org/#/c/329448/ >> >

Re: [openstack-dev] [ceilometer] [stable] Re: [Openstack-stable-maint] Stable check of openstack/ceilometer failed

  -Original Message- From: gordon chung Reply: OpenStack Development Mailing List (not for usage questions) Date: June 14, 2016 at 06:51:08 To: openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] [ceilometer] [stable] Re: [Openstack-stable-maint] Stable check of openstack/

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

Excerpts from Hayes, Graham's message of 2016-06-14 14:44:36 +: > On 14/06/2016 15:00, Thierry Carrez wrote: > > Hi everyone, > > > > I just proposed a new requirement for OpenStack "official" projects, > > which I think is worth discussing beyond the governance review: > > > > https://review.o

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On 14/06/2016 17:14, Anita Kuno wrote: > On 06/14/2016 10:44 AM, Hayes, Graham wrote: >> On 14/06/2016 15:00, Thierry Carrez wrote: >>> Hi everyone, >>> >>> I just proposed a new requirement for OpenStack "official" projects, >>> which I think is worth discussing beyond the governance review: >>> >

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

On 06/14/2016 09:02 AM, Daniel P. Berrange wrote: > On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote: > > [snip] > >> The crux of the problem is that os-brick 1.4 and privsep can't be used >> without a config file change during the upgrade. Which violates our >> policy, because it break

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (berra...@redhat.com) wrote: > > On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote: > > In strategy 2 we just pass 1 bridge name to Nova. That's the one that > > is ensures is created and plumbs the VM to. Since it's not responsible

Re: [openstack-dev] [nova] NUMA, huge pages, and scheduling

Great info Chris and thanks for confirming the assignment of blocks of pages to a numa node. I'm still struggling with why each VM is being assigned to NUMA node 0. Any ideas on where I should look to see why Nova is not using NUMA id 1? Thanks! PCM On Tue, Jun 14, 2016 at 10:29 AM Chris Frie

Re: [openstack-dev] [glance] Proposal of a virtual mid-cycle instead of the co-located

Please note the details on the midcycle event are updated here: https://wiki.openstack.org/wiki/VirtualSprints#Glance_Virtual_midcycle_sync We will be using the etherpad (given in the link above) as a live wiki for central place of updated info. On 6/8/16 9:52 AM, Nikhil Komawar wrote: > This eve

Re: [openstack-dev] [VPNaaS] Support for Stronger hashes and combined mode ciphers

Certainly the ciphers and hashes could be enhanced for VPNaaS. This would require converting the user selections into options for the underlying device driver, modifying the neutron client (OSC) to allow entry of the new selections, updating unit tests, and likely adding some validators to reject t

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

On 6/14/2016 11:33 AM, Sean Dague wrote: On 06/14/2016 09:02 AM, Daniel P. Berrange wrote: On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote: [snip] The crux of the problem is that os-brick 1.4 and privsep can't be used without a config file change during the upgrade. Which violates

Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?

I just put up a WIP patch in os-brick that tests to see if os-privsep is configured with the helper_command. If it's not, then os-brick falls back to using processutils with the root_helper and run_as_root kwargs passed in. https://review.openstack.org/#/c/329586 If you can check this out that

[openstack-dev] [ironic] simple patches requiring only one +2/+A

Hi, There was a short discussion on IRC a few minutes ago [1] about when it would be acceptable for a patch to be approved with one +2 (as opposed to two +2s). The few of us that commented (I think all are cores in one or several ironic projects) agreed that it would be good to do that, but "us

Re: [openstack-dev] [VPNaaS] Support for Stronger hashes and combined mode ciphers

Hi Paul, On 06/14/16 10:27, Paul Michali wrote: Certainly the ciphers and hashes could be enhanced for VPNaaS. This would require converting the user selections into options for the underlying device driver, modifying the neutron client (OSC) to allow entry of the new selections, updating unit t

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

I committed a small change to systemd-nspawn to ensure kernel modules could be loaded by IPA hardware managers in an older version of our CoreOS-based ramdisk (note that we don't use systemd-nspawn anymore, but instead use a chroot inside the CoreOS ramdisk). Thanks, Jay Faulkner OSIC On 6/13

[openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

Last year, in response to Nova micro-versioning and extension updates[1], the QA team added strict API schema checking to Tempest to ensure that no additional properties were added to Nova API responses[2][3]. In the last year, at least three vendors participating the the OpenStack Powered Trademar

Re: [openstack-dev] [kolla][security] Finishing the job on threat analysis for Kolla

Rob, Do you have the source for reference #2 below? I believe the next step was to produce copies of #2 based upon the special different types of containers in the system and combine them into one coherent doc. I think continuing to use sequence diagrams makes sense. My phone (out of batterie

Re: [openstack-dev] [VPNaaS] Support for Stronger hashes and combined mode ciphers

I think Kyle polled operators and a few mentioned using VPNaaS for site-to-site IPSec - do a search in this ML for VPNaaS. AFAIK, no one so far is stepping up to work on VPNaaS. Regards, PCM On Tue, Jun 14, 2016 at 1:40 PM Mark Fenwick wrote: > Hi Paul, > > On 06/14/16 10:27, Paul Michali wro

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

Excerpts from Chris Hoge's message of 2016-06-14 10:57:05 -0700: > Last year, in response to Nova micro-versioning and extension updates[1], > the QA team added strict API schema checking to Tempest to ensure that > no additional properties were added to Nova API responses[2][3]. In the > last year

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote: > Last year, in response to Nova micro-versioning and extension updates[1], > the QA team added strict API schema checking to Tempest to ensure that > no additional properties were added to Nova API responses[2][3]. In the > last year, at

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400: > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote: > > Last year, in response to Nova micro-versioning and extension updates[1], > > the QA team added strict API schema checking to Tempest to ensure that > > no additi

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

On 06/14/2016 09:52 AM, Chris Friesen wrote: > On 06/13/2016 01:11 PM, Doug Hellmann wrote: >> I'm trying to pull together some information about contributions >> that OpenStack community members have made *upstream* of OpenStack, >> via code, docs, bug reports, or anything else to dependencies tha

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote: > Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400: > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote: > > > Last year, in response to Nova micro-versioning and extension updates[1], > > > the QA team a

[openstack-dev] [Manila] Midcycle call for topics

Our midcycle meetup is 2 weeks away! Please propose topics on the etherpad: https://etherpad.openstack.org/p/newton-manila-midcycle Depending on how much material we need to cover I'll decide if we need the third day or not. -Ben __

[openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

Hello team, I want to annonce the following changes to murano core team: 1) I’d like to nominate Alexander Tivelkov for murano core. He has been part of the project for a very long time and has contributed to almost every part of murano. He has been fully committed to murano during mitaka cycle

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

> On Jun 14, 2016, at 11:21 AM, Matthew Treinish wrote: > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote: >> Last year, in response to Nova micro-versioning and extension updates[1], >> the QA team added strict API schema checking to Tempest to ensure that >> no additional properti

  1   2   >