[openstack-dev] [meghdwar] use case for meghdwar API irc call agenda

Hi all, Please join the meeting  for API and codes decision  Meeting Wednesday 3rd August      (14 Hr-15 Hr UTC )   [7AM-8AM PDT] irc #openstck-megdwar Follow up on same points with updates aslast meeting.Since we had a irc issues last week we plan to conduct this meeting instead of skipping and

Re: [openstack-dev] [Openstack-operators] [neutron][horizon][announce] Introducing DON

Great! This is much needed. We will be glad to help in anyway possible. Regards, Amit On Wed, Aug 3, 2016 at 12:02 AM, Ihar Hrachyshka wrote: > Amit Kumar Saha (amisaha) wrote: > > Hi, >> >> We would like to introduce the community to a new Python based

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

I still have a problem about the fg device with private ip address. In DVR mode, there is a external ip address in fq device, because we need to figure out the default route. If the fg device with a private ip address, how do we figure out the default route in fip namespace? Default route is

Re: [openstack-dev] How to create a image using http img file

As the error said, you need to see the disk_format and container_format. I haven't digged the code, but I think you should try to set the container_format and disk_format when you create the image like this: image = self.glance.images.create(name="myNewImage",

[openstack-dev] How to create a image using http img file

refer to: glance client Python API v2 http://docs.openstack.org/developer/python-glanceclient/ref/v2/images.html add_location(image_id, url, metadata) Add a new location entry to an image’s list of locations. It is an error to add a URL that is already present in the list of locations.

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

On Aug 2, 2016 6:52 PM, "Kevin Benton" wrote: > > >It might be the wrong impression, but it was already given and there are drivers which have been written under it. That's why I tend toward fixing rollback instead of eliminating it. > > The reason I thought it was relevant to

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

>It might be the wrong impression, but it was already given and there are drivers which have been written under it. That's why I tend toward fixing rollback instead of eliminating it. The reason I thought it was relevant to bring up is because it's going to be difficult to actually fix it. If any

Re: [openstack-dev] [horizon] Angular panel enable/disable not overridable in local_settings

On 3 August 2016 at 00:32, Rob Cresswell wrote: > Hi all, > > So we seem to be adopting a pattern of using UPDATE_HORIZON_CONFIG in the > enabled files to add a legacy/angular toggle to the settings. I don't like > this, because in settings.py the enabled files are

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On Tue, Aug 2, 2016 at 6:15 AM, huangdenghui wrote: > hi john and brain >thanks for your information, if we get patch[1],patch[2] merged,then fg > can allocate private ip address. after that, we need consider floating ip > dataplane, in current dvr implementation, fg is

Re: [openstack-dev] [Neutron][IPAM] Pluggable IPAM rollback issue

On Tue, Aug 2, 2016 at 2:50 AM, Kevin Benton wrote: > >Given that it shares the session, it wouldn't have to do anything. But, > again, it wouldn't behave like an external driver. > Why not? The only additional thing an external driver would be doing at > this step is calling

Re: [openstack-dev] [TripleO] Improving Swift deployments with TripleO

On Tue, Aug 02, 2016 at 09:36:45PM +0200, Christian Schwede wrote: > Hello everyone, > > I'd like to improve the Swift deployments done by TripleO. There are a > few problems today when deployed with the current defaults: Thanks for digging into this, I'm aware this has been something of a

Re: [openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options

If operator haven't explicitly defined live_migration_tunnelled param in nova.conf, after upgrade is done it's default value will be set to False. If operator set this param explicitly, everything will be unchanged. To notify about this change I'm proposing to use release notes, as It's usually

[openstack-dev] [ironic] Priorities for the rest of the cycle

Hey all, There's some deadlines coming up: * non-client library freeze in 3 weeks * client library freeze in 4 weeks * final releases in 8 weeks http://releases.openstack.org/newton/schedule.html As usual, we don't do a hard feature freeze at the normal feature freeze date (4 weeks from now),

Re: [openstack-dev] [nova] os-virtual-interfaces isn't deprecated in 2.36

On 8/2/2016 9:09 AM, Matt Riedemann wrote: On 8/2/2016 2:41 AM, Alex Xu wrote: A little strange we have two API endpoints, one is '/servers/{uuid}/os-interfaces', another one is '/servers/{uuid}/os-virtual-interfaces'. I prefer to keep os-attach-interface. Due to I think we should deprecate

Re: [openstack-dev] [gnocchi] typical length of timeseries data

On Tue, Aug 02 2016, gordon chung wrote: > so from very rough testing, we can choose to lower it to 3600points which > offers better split opportunities with negligible improvement/degradation, or > even more to 900points with potentially small write degradation (massive > batching). 3600 points

[openstack-dev] [tc] Stepping Down.

Based upon my personal time demands among a number of other reasons I will be stepping down from the Technical Committee. This is planned to take effect with the next TC election so that my seat will be up to be filled at that time. For those who elected me in, thank you. Regards, --Morgan

Re: [openstack-dev] [nova] Belated nova newton midcycle recap (part 2)

On 8/2/2016 12:25 PM, Jim Rollenhagen wrote: On Mon, Aug 01, 2016 at 09:15:46PM -0500, Matt Riedemann wrote: * Placement API for resource providers Jay's personal goal for Newton is for the resource tracker to be writing inventory and allocation data via the placement API. We want to get

Re: [openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options

On 08/02/2016 09:14 AM, Timofei Durakov wrote: Hi, Taking into account everything above I'd prefer to see live_migration_tunnelled(that corresponds to VIR_MIGRATE_TUNNELLED) defaulted to False. We just need to make a release note for this change, and on the host startup do LOG.warning to notify

[openstack-dev] [release][neutron][ipam][networking-infoblox] networking-infoblox 2.0.2

I am happy to announce that we have released version 2.0.2 of the Infoblox IPAM driver for OpenStack. This driver uses the pluggable IPAM framework delivered in Neutron's Liberty release, enabling the use of Infoblox for allocating subnets and IP addresses, and automatically creating DNS zones

[openstack-dev] [Ironic] v2 API - request for feedback on "problem description"

Hi all, Today's ironic-v2-api meeting was pretty empty, so I am posting a summary of our subteam's activity here. I have taken the midcycle notes about our API's current pain points / usability gaps, and written them up into the format we would use for a spec's "Problem Description", and posted

[openstack-dev] [TripleO] Improving Swift deployments with TripleO

Hello everyone, I'd like to improve the Swift deployments done by TripleO. There are a few problems today when deployed with the current defaults: 1. Adding new nodes (or replacing existing nodes) is not possible, because the rings are built locally on each host and a new node doesn't know about

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

On 08/01/2016 05:10 AM, Jim Rollenhagen wrote: > Hey all, > > Our nova patch for networking[0] got stuck for a bit, because Nova needs > to know which network interface is in use for the node, in order to > properly set up the port. > > The code landed for network_interface follows the following

Re: [openstack-dev] [Cinder] Pending removal of Scality volume driver

Tomorrow is the one week grace period. I just ran the last comment script and it still shows it's been 112 days since the Scality CI has reported on a patch. Please let me know the status of the CI. On Thu, Jul 28, 2016 at 07:28:26AM -0500, Sean McGinnis wrote: > On Thu, Jul 28, 2016 at

Re: [openstack-dev] [Cinder] Pending removal of X-IO volume driver

Thanks Richard. The removal patch has been abandoned. On Tue, Aug 02, 2016 at 03:20:41PM +, Hedlind, Richard wrote: > Status update. Our CI is back up and has been passing tests successfully for > ~18h now. I will keep a close eye on it to make sure it stays up. Sorry about > the down time.

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

On 08/02/2016 08:15 AM, huangdenghui wrote: hi john and brain thanks for your information, if we get patch[1],patch[2] merged,then fg can allocate private ip address. after that, we need consider floating ip dataplane, in current dvr implementation, fg is used to reachment testing for

Re: [openstack-dev] [all][tc] establishing project-wide goals

Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400: > On 08/01/2016 08:33 AM, Sean Dague wrote: > > On 07/29/2016 04:55 PM, Doug Hellmann wrote: > >> One of the outcomes of the discussion at the leadership training > >> session earlier this year was the idea that the TC should set some

Re: [openstack-dev] Nominate Vladimir Khlyunev for fuel-qa core

+1 On Tue, Aug 2, 2016 at 2:56 PM, Artem Panchenko wrote: > +1 > > On Tue, Aug 2, 2016 at 1:52 PM, Dmitry Tyzhnenko > wrote: > >> +1 >> >> On Tue, Aug 2, 2016 at 12:51 PM, Artur Svechnikov < >> asvechni...@mirantis.com> wrote: >> >>> +1 >>> >>>

Re: [openstack-dev] [neutron][horizon][announce] Introducing DON

Amit Kumar Saha (amisaha) wrote: Hi, We would like to introduce the community to a new Python based project called DON – Diagnosing OpenStack Networking. More details about the project can be found at https://github.com/openstack/python-don. DON, written primarily in

[openstack-dev] [new][oslo] oslotest 2.8.0 release (newton)

We are excited to announce the release of: oslotest 2.8.0: Oslo test framework This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslotest With package available at: https://pypi.python.org/pypi/oslotest Please report

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

We are exuberant to announce the release of: taskflow 2.4.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:

[openstack-dev] [new][oslo] oslosphinx 4.7.0 release (newton)

We are content to announce the release of: oslosphinx 4.7.0: OpenStack Sphinx Extensions and Theme This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslosphinx With package available at:

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

We are mirthful to announce the release of: tooz 1.42.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:

[openstack-dev] [new][oslo] stevedore 1.17.0 release (newton)

We are mirthful to announce the release of: stevedore 1.17.0: Manage dynamic plugins for Python applications This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/stevedore With package available at:

[openstack-dev] [new][oslo] oslo.service 1.14.0 release (newton)

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

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

We are happy to announce the release of: oslo.vmware 2.12.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

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

We are excited to announce the release of: oslo.messaging 5.6.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:

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

We are satisfied to announce the release of: oslo.versionedobjects 1.14.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:

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

We are jazzed to announce the release of: oslo.serialization 2.12.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:

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

We are pleased to announce the release of: oslo.reports 1.13.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

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

We are chuffed to announce the release of: oslo.privsep 1.11.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:

[openstack-dev] [new][oslo] oslo.db 4.9.0 release (newton)

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

[openstack-dev] [new][oslo] oslo.config 3.14.0 release (newton)

We are amped to announce the release of: oslo.config 3.14.0: Oslo Configuration API This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config

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

We are grateful to announce the release of: oslo.middleware 3.16.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:

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

We are thrilled to announce the release of: oslo.policy 1.13.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

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

We are stoked to announce the release of: oslo.log 3.13.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

Re: [openstack-dev] [nova] Belated nova newton midcycle recap (part 2)

On 08/01/2016 10:15 PM, Matt Riedemann wrote: Starting from where I accidentally left off: We also talked a bit about live migration with Neutron. There has been a fix up for live migration + DVR since Mitaka: https://review.openstack.org/#/c/275073 It's a bit of a hacky workaround but

[openstack-dev] [new][oslo] oslo.cache 1.12.0 release (newton)

We are enthusiastic to announce the release of: oslo.cache 1.12.0: Cache storage for Openstack projects. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.cache With package available at:

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On 08/02/2016 08:19 AM, Alex Xu wrote: Chris have a thought about using ResourceClass to describe Capabilities with an infinite inventory. In the beginning we brain storming the idea of Tags, Tan Lin have same thought, but we say no very quickly, due to the ResourceClass is really about

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

We are eager to announce the release of: oslo.concurrency 3.13.0: Oslo Concurrency library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.concurrency With package available at:

[openstack-dev] [new][oslo] mox3 0.18.0 release (newton)

We are glad to announce the release of: mox3 0.18.0: Mock object framework for Python This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/mox3 With package available at: https://pypi.python.org/pypi/mox3 Please report

[openstack-dev] [new][oslo] debtcollector 1.7.0 release (newton)

We are glowing to announce the release of: debtcollector 1.7.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. This release is part of the newton release series. With source available at:

[openstack-dev] [new][oslo] futurist 0.17.0 release (newton)

We are tickled pink to announce the release of: futurist 0.17.0: Useful additions to futures, from the future. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/futurist With package available at:

[openstack-dev] [new][oslo] automaton 1.4.0 release (newton)

We are joyful to announce the release of: automaton 1.4.0: Friendly state machines for python. This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/automaton With package available at:

Re: [openstack-dev] [gnocchi] typical length of timeseries data

On 29/07/16 03:29 PM, gordon chung wrote: i'm using Ceph. but i should mention i also only have 1 thread enabled because python+threading is... yeah. i'll give it a try again with threads enabled. I tried this again with 16 threads. as expected, python (2.7.x) threads do jack all. i also

Re: [openstack-dev] [nova] Belated nova newton midcycle recap (part 2)

On Mon, Aug 01, 2016 at 09:15:46PM -0500, Matt Riedemann wrote: > > > > * Placement API for resource providers > > Jay's personal goal for Newton is for the resource tracker to be writing > inventory and allocation data via the placement API. We want to get the data > writing into the

Re: [openstack-dev] [all][tc] establishing project-wide goals

Excerpts from Hayes, Graham's message of 2016-08-02 16:30:06 +: > On 02/08/2016 16:37, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: > >> On 02/08/2016 14:37, Doug Hellmann wrote: > >>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37

[openstack-dev] [neutron][horizon][announce] Introducing DON

Hi, We would like to introduce the community to a new Python based project called DON - Diagnosing OpenStack Networking. More details about the project can be found at https://github.com/openstack/python-don. DON, written primarily in Python, and available as a dashboard in OpenStack Horizon,

[openstack-dev] [Manila] Migration APIs 2-phase vs. 1-phase

It occurred to me that if we write the 2-phase migration APIs correctly, then it will be fairly trivial to implement 1-phase migration outside Manila (in the client, or even higher up). I would like to propose that we change the migration API to actually work that way, because I think it will

Re: [openstack-dev] [Openstack] [networking-sfc] Flow classifier conflict logic

Please send the tenant ids of all six neutron ports. >From admin:neutron port-show | grep tenant_id Thanks,Farhad. On Monday, August 1, 2016 7:44 AM, Artem Plakunov wrote: Thanks. You said though that classifier must be unique within a tenant. I tried

Re: [openstack-dev] [all][tc] establishing project-wide goals

On 02/08/2016 16:37, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: >> On 02/08/2016 14:37, Doug Hellmann wrote: >>> Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: On 29/07/2016 21:59, Doug Hellmann wrote: > One of the

Re: [openstack-dev] [HA] RFC: High Availability track at future Design Summits

Hi Thierry, Thierry Carrez wrote: > Adam Spiers wrote: > > I doubt anyone would dispute that High Availability is a really > > important topic within OpenStack, yet none of the OpenStack > > conferences or Design Summits so far have provided an "official" track > > or

Re: [openstack-dev] [all][tc] establishing project-wide goals

On 08/02/2016 11:29 AM, Thierry Carrez wrote: Doug Hellmann wrote: [...] Likewise, what if the Manila project team decides they aren't interested in supporting Python 3.5 or a particular greenlet library du jour that has been mandated upon them? Is the only filesystem-as-a-service project

Re: [openstack-dev] [tc] persistently single-vendor projects

> On 02 Aug 2016, at 17:13, Hayes, Graham wrote: > > On 02/08/2016 15:42, Flavio Percoco wrote: >> On 01/08/16 10:19 -0400, Sean Dague wrote: >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote: Thierry, Ben, Doug, How can we distinguish between. "Project is

Re: [openstack-dev] [tc] persistently single-vendor projects

On 02/08/2016 16:48, Steven Dake (stdake) wrote: > Responses inline: > > On 8/2/16, 8:13 AM, "Hayes, Graham" wrote: > >> On 02/08/2016 15:42, Flavio Percoco wrote: >>> On 01/08/16 10:19 -0400, Sean Dague wrote: On 08/01/2016 09:58 AM, Davanum Srinivas wrote: >

Re: [openstack-dev] [juju charms] How to configure glance charm for specific cnider backend?

James, thank you for your answer. I'll file bug to glance - but in current releases glance-charm have to do it himself, right? I'm not sure that I'm correctly understand your question. I suppose that deployment will have glance and cinder on different machines. Also there will be one relation

Re: [openstack-dev] [nova][ironic] A couple feature freeze exception requests

> Multitenant networking > == I haven't reviewed this one much either, but it looks smallish and if other people are good with it then I think it's probably something we should do. > Multi-compute usage via a hash ring > === I'm obviously +2

Re: [openstack-dev] [tc] persistently single-vendor projects

Responses inline: On 8/2/16, 8:13 AM, "Hayes, Graham" wrote: >On 02/08/2016 15:42, Flavio Percoco wrote: >> On 01/08/16 10:19 -0400, Sean Dague wrote: >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote: Thierry, Ben, Doug, How can we distinguish between.

Re: [openstack-dev] [nova][ironic] A couple feature freeze exception requests

On 8/1/2016 4:20 PM, Jim Rollenhagen wrote: Yes, I know this is stupid late for these. I'd like to request two exceptions to the non-priority feature freeze, for a couple of features in the Ironic driver. These were not requested at the normal time as I thought they were nowhere near ready.

Re: [openstack-dev] [all][tc] establishing project-wide goals

Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +: > On 02/08/2016 14:37, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: > >> On 29/07/2016 21:59, Doug Hellmann wrote: > >>> One of the outcomes of the discussion at the leadership

Re: [openstack-dev] [all][tc] establishing project-wide goals

Doug Hellmann wrote: > [...] >> Likewise, what if the Manila project team decides they aren't interested >> in supporting Python 3.5 or a particular greenlet library du jour that >> has been mandated upon them? Is the only filesystem-as-a-service project >> going to be booted from the tent? >

Re: [openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options

Hi, Taking into account everything above I'd prefer to see live_migration_tunnelled(that corresponds to VIR_MIGRATE_TUNNELLED) defaulted to False. We just need to make a release note for this change, and on the host startup do LOG.warning to notify the operator that there are no tunnels for

Re: [openstack-dev] [juju charms] How to configure glance charm for specific cnider backend?

Hi Andrey On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov wrote: > I need to add glance support via storing images in cinder instead of > local files. > (This works only from Mitaka version due to glance-store package) > OK > First step I've made here - >

Re: [openstack-dev] [Cinder] Pending removal of X-IO volume driver

Status update. Our CI is back up and has been passing tests successfully for ~18h now. I will keep a close eye on it to make sure it stays up. Sorry about the down time. Richard -Original Message- From: Hedlind, Richard [mailto:richard.hedl...@x-io.com] Sent: Thursday, July 28, 2016

[openstack-dev] [nova] Nova API sub-team meeting

Hi, We have weekly Nova API meeting tomorrow. The meeting is being held Wednesday UTC1300 and irc channel is #openstack-meeting-4. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

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

first agenda: > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160802 > > Feel free to add topics, and any outstanding bug and patch. > > See you tomorrow! > Thanks, > -- > Emilien Macchi -- Emilien Macchi

Re: [openstack-dev] [tc] persistently single-vendor projects

On 02/08/2016 15:42, Flavio Percoco wrote: > On 01/08/16 10:19 -0400, Sean Dague wrote: >> On 08/01/2016 09:58 AM, Davanum Srinivas wrote: >>> Thierry, Ben, Doug, >>> >>> How can we distinguish between. "Project is doing the right thing, but >>> others are not joining" vs "Project is actively

Re: [openstack-dev] [tc] persistently single-vendor projects

On 8/2/16, 7:17 AM, "Ed Leafe" wrote: >On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake) wrote: > >> For example tripleo is single-vendor, but is doing all the right things >>to >> dig out of single vendor by doing actual community building. They >>aren't >>

Re: [openstack-dev] [infra] Switch 'all?' openstack bots to errbot plugins?

On 29/07/16 13:57 -0400, Doug Hellmann wrote: Excerpts from Joshua Harlow's message of 2016-07-29 10:35:18 -0700: I prefer 'one bucket repo for OpenStack community Errbot plug-ins' since I don't like a bunch of repos (seems like a premature optimization ~at this time~), but I could see either

Re: [openstack-dev] pydotplus (taskflow) vs pydot-ng (fuel)

Hi Thomas, If I'm not mistaken, pydot-ng [1] has been made by ex-fueler in order to overcome some limitations of pydot ( and do not change much. If pydotplus is alive project and do the same thing, I vote for using it in Fuel. Thanks, Igor [1]: https://pypi.io/project/pydot-ng/ On Tue, Aug 2,

[openstack-dev] [juju charms] How to configure glance charm for specific cnider backend?

Hi All, I need to add glance support via storing images in cinder instead of local files. (This works only from Mitaka version due to glance-store package) First step I've made here - https://review.openstack.org/#/c/348336/ This patchset adds ability to relate glance-charm to cinder-charm (it's

Re: [openstack-dev] [tc] persistently single-vendor projects

On 02/08/16 09:17 -0500, Ed Leafe wrote: On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake) wrote: For example tripleo is single-vendor, but is doing all the right things to dig out of single vendor by doing actual community building. They aren't just trying, but are trying

Re: [openstack-dev] [tc] persistently single-vendor projects

On 01/08/16 10:28 -0400, Davanum Srinivas wrote: Sean, So we will programatically test the metrics (if we are not doing that already) to apply/remove "team:single-vendor" tag: https://governance.openstack.org/reference/tags/team_single-vendor.html And trigger exit when the tag is present for

Re: [openstack-dev] [tc] persistently single-vendor projects

On 01/08/16 10:19 -0400, Sean Dague wrote: On 08/01/2016 09:58 AM, Davanum Srinivas wrote: Thierry, Ben, Doug, How can we distinguish between. "Project is doing the right thing, but others are not joining" vs "Project is actively trying to keep people out"? I think at some level, it's not

[openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options

In Mitaka development cycle 'live_migration_flag' and 'block_migration_flag' have been marked as deprecated for removal. I'm working on a patch [1] to remove both of them and want to ask what we should do with live_migration_tunnelled logic. The default configuration of both flags contain

[openstack-dev] [horizon] Angular panel enable/disable not overridable in local_settings

Hi all, So we seem to be adopting a pattern of using UPDATE_HORIZON_CONFIG in the enabled files to add a legacy/angular toggle to the settings. I don't like this, because in settings.py the enabled files are processed *after* local_settings.py imports, meaning the angular panel will always be

Re: [openstack-dev] [docker] [magnum] Magnum account on Docker Hub

I just filed a ticket to acquire the username openstackmagnum. I included Hongbin's contact information explaining that he's the project's PTL. Thanks Steve, Spyros On 2 August 2016 at 13:29, Steven Dake (stdake) wrote: > Ton, > > I may or may not have set it up early in

Re: [openstack-dev] [requirements] race in keystone unit tests

Hi Sean, Thanks for the information. This obviously looks Fernet-related and I would be happy to spend some cycles on it. We recently landed a bunch of refactors in keystone to improve Fernet test coverage. This could be related to those refactors. Just double checking - but you haven't opened a

Re: [openstack-dev] [tc] persistently single-vendor projects

On Aug 2, 2016, at 8:50 AM, Steven Dake (stdake) wrote: > For example tripleo is single-vendor, but is doing all the right things to > dig out of single vendor by doing actual community building. They aren't > just trying, but are trying *very* hard with their activities.

Re: [openstack-dev] [Nova] Does this api modification need Microversion?

On Aug 2, 2016, at 1:11 AM, han.ro...@zte.com.cn wrote: > Allow "revert_resize" to recover error instance after resize/migrate. > > When resize/migrate instance, if error occurs on source compute node, > instance state can rollback to active currently. But if error occurs in > "finish_resize"

Re: [openstack-dev] [nova] os-virtual-interfaces isn't deprecated in 2.36

On 8/2/2016 2:41 AM, Alex Xu wrote: A little strange we have two API endpoints, one is '/servers/{uuid}/os-interfaces', another one is '/servers/{uuid}/os-virtual-interfaces'. I prefer to keep os-attach-interface. Due to I think we should deprecate the nova-network also. Actually we deprecate

Re: [openstack-dev] [ironic] [nova] [neutron] get_all_bw_counters in the Ironic virt driver

On 8/2/2016 6:22 AM, John Garbutt wrote: On 29 July 2016 at 19:58, Sean Dague wrote: On 07/29/2016 02:29 PM, Jay Pipes wrote: On 07/28/2016 09:02 PM, Devananda van der Veen wrote: On 07/28/2016 05:40 PM, Brad Morgan wrote: I'd like to solicit some advice about potentially

Re: [openstack-dev] [tc] persistently single-vendor projects

On 8/1/16, 8:38 AM, "Doug Hellmann" wrote: >Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +: >> I am struggling to understand why we would want to remove projects from >>our big tent at all, as long as they are being actively developed under >>the

Re: [openstack-dev] [all][tc] establishing project-wide goals

On 02/08/2016 14:37, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: >> On 29/07/2016 21:59, Doug Hellmann wrote: >>> One of the outcomes of the discussion at the leadership training >>> session earlier this year was the idea that the TC should set some

[openstack-dev] [ironic] weekly subteam status report

Hi, We are yodelling to present this week's subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) === - Stats (diff with 18 July 2016) - Ironic: 216 bugs (+15) + 204 wishlist items (+3). 21 new (+8), 160 in progress

[openstack-dev] pydotplus (taskflow) vs pydot-ng (fuel)

Hi, Fuel uses pydot-ng, and (at least) taskflow uses pydotplus. I believe both aren't using pydot because that's dead upstream. Could we have a bit of consistency here, and have one or the other component to switch, so we could get rid of one more package that does the same thing in downstream

[openstack-dev] [nova][tempest] testing different configurations by exploiting the mutate attribute?

IIUC, each gate testing job has a *fixed configuration* which will never be changed when executing *all* tempest tests. If I need to test a specific configuration, a new testing job is needed. As we have a limited amount of test nodes, this creates testing gaps as we cannot test all

Re: [openstack-dev] [tc] persistently single-vendor projects

Excerpts from Chris Dent's message of 2016-08-02 11:16:29 +0100: > On Mon, 1 Aug 2016, James Bottomley wrote: > > > Making no judgments about the particular exemplars here, I would just > > like to point out that one reason why projects exist with very little > > diversity is that they "just

Re: [openstack-dev] [all][tc] establishing project-wide goals

Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +: > On 29/07/2016 21:59, Doug Hellmann wrote: > > One of the outcomes of the discussion at the leadership training > > session earlier this year was the idea that the TC should set some > > community-wide goals for accomplishing

Re: [openstack-dev] [all][tc] establishing project-wide goals

Excerpts from Shamail's message of 2016-08-01 22:37:28 -0500: > Thanks Doug, > > > On Aug 1, 2016, at 10:44 AM, Doug Hellmann wrote: > > > > Excerpts from Shamail Tahir's message of 2016-08-01 09:49:35 -0500: > >>> On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann

[openstack-dev] [puppet] Temporarily unstable Fuel deployment test jobs

Dear colleagues, Please be informed that we are going to merge some patches on 08/02/2016 to Fuel repositories to switch from Mitaka to Newton packages. These patches will likely distabilize Fuel deployment tests for several days. We are going fix all major features till 08/08/2016 and get these

  1   2   >