Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi Ifat, > > > Let me see if I got this right: are you suggesting that we create > > > on-the-fly alarm definitions with no alarm_actions, for every > > > deduced > > alarm that we want to raise? And this will spare us the extra alarm > > evaluation in AODH? > > > > Yes. But, please note that cou

Re: [openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys wrote: > Hi all, > > Trying to prepare moving our repos to the OpenStack infrastructure, I > got reminded just how many repos we have in our GitHub organization > [1] - and how many of those seem to be deprecated or tangential. > > Now, do we still wan

Re: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

Here it is (I posted this in today's IRC meeting too). https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining Thanks, Cathy From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Thursday, December 03, 2015 10:34 AM To: openstack-dev@lists.openstack.org Subject: [op

[openstack-dev] [horizon][release][infra] New xstatic package release proposal

TL;DR: "Releasing xstatic packages" https://review.openstack.org/#/c/253296/ xstatic is an existing standard for packaging up static resources for web development (HTML, Javascript and CSS) as Python modules. Horizon makes use of two dozen xstatic packages. We need a be

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

Hi Major, Thanks for the steps. To add a new container, we have followed the steps as mentioned in the extra_container.yml.example. Please find the sample designate.yml file attached and created as per the steps. To add the new roles in openstack-ansible repository, shall I create the directo

[openstack-dev] [Congress] Python 3 ready

Congress can finally pass python34 gating. Here¹s the last patch needed to make it happen. https://review.openstack.org/#/c/253298/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-r

Re: [openstack-dev] [nova] jsonschema for scheduler hints

2015-12-02 23:12 GMT+08:00 Sylvain Bauza : > > > Le 02/12/2015 15:23, Sean Dague a écrit : > >> We have previously agreed that scheduler hints in Nova are an open ended >> thing. It's expected for sites to have additional scheduler filters >> which expose new hints. The way we handle that with our

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

On Thu, Dec 03, 2015 at 07:42:43PM -0600, Matt Riedemann wrote: > I already mentioned this to sdague before the nova meeting today (these are > the things I think about while driving in the middle of nowhere), but option > #3 won't work because boot from UEFI requires libvirt>=1.9.0, which we don'

Re: [openstack-dev] [murano]How to use Murano to transmit files to Mistral and execute scripts on Mistral

Stan, I got it. Thanks for your information. ☺ Thanks, Tony From: Stan Lagun [mailto:sla...@mirantis.com] Sent: Tuesday, December 01, 2015 4:21 PM To: WANG, Ming Hao (Tony T) Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [murano]How to use Murano t

[openstack-dev] [murano] Is there blueprint to add argument collection UI for action

Dear Stan and Murano developers, The current murano-dashboards can add the action button for the actions defined in Murano class definition automatically, which is great. Is there any blueprint to add argument collection UI for the action? Currently, the murano-dashboards only uses environment_id

[openstack-dev] [ironic]How to deploy bare metal physical machines by using Ironic?

Hi, all I have installed Ironic in my devstack a few days ago. And everything goes okay. Now, I want to deploy bare metal physical machines by using Ironic. But I find no documentation about how to deploy physical machines by using Ironic. Could someone give me some advice? Thank you Zhi C

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

On 12/3/2015 9:35 AM, Matt Riedemann wrote: The boot from UEFI spec [1] is stalled a bit on testing concerns. I've asked that there is integration testing (either upstream or Intel hosts a 3rd party job for it), or we log a warning when it's used saying it's untested and therefore considered ex

Re: [openstack-dev] [all] making project_id optional in API URLs

> On Dec 3, 2015, at 12:06, Sean Dague wrote: > > For folks that don't know, we've got an effort under way to look at some > of what's happened with the service catalogue, how it's organically grown, > and do some pruning and tuning to make sure it's going to support what > we want to do with Op

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

Angus, I took a stab at it: https://review.openstack.org/#/c/253070/ Also, can you please request a oslo.privsep release in the openstack/releases repo for the library with a specific SHA when you think we are ready? Thanks, Dims On Thu, Dec 3, 2015 at 6:01 PM, Angus Lees wrote: > On Tue, 1 De

Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

I know my vote doesn't count, Athlan help me very much providing great feedback. 2015-12-03 18:54 GMT-03:00 Rich Megginson : > On 12/03/2015 01:05 PM, Emilien Macchi wrote: > > Hi, > > For some months, Puppet OpenStack group has been very lucky to have > Sofer working with us. > He became a huge

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

Not really sure. If its reproducible with hammer+, I'd say yes. giant's keystone support was very basic, and it may not work against Mitaka anyway? It only supports v2. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, December 02, 2015

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 14:20, Ryan Moats wrote: > I missed this the first time around, but I concur with the comments of the > other deputies - > the effort only took me about an hour or two a day and I think it's been > rather helpful :) > Btw, have a look at [1,2] to see if that suits your subs

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

Zane I want to echo your sentiments exactly below. I agree with all of the things basically. The only thing I'd add is that no matter how good you make Heat's rollback API, it will never be as good as git. So I would suggest that you just have people roll forward from Heat's perspective, and let V

[openstack-dev] [release] Release countdown for week R-17, Dec 7-11

The Mitaka 1 milestone tagging is almost complete. Check http://docs.openstack.org/releases/releases/mitaka.html for a list of the projects with tags. Congratulations to all of the project teams for completing the milestone! Matt Treinish and Brant Knudson identified an issue with reno's treatment

Re: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

Igor, I suggest you add the installation instructions here. https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining -Louis From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Thursday, December 03, 2015 10:34 AM To: openstack-dev@lists.openstack.org Subject:

Re: [openstack-dev] [Fuel] CentOS7 Merging Plan

Hello, Status update for Dec, 3 - we're on track. There were issues with passing swarm test in the beginning of the day caused by various reasons, not all of them related to CentOS7 itself. We've fixed all issues we've found, at EOD we've got several successful ISOs built from master (with our pa

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

On Tue, 1 Dec 2015 at 00:20 Thierry Carrez wrote: > Sean Dague wrote: > > Right, so to me this seems that privsep just needs a NULL mode, and > > we're done. If oslo.rootrwap was never supported on windows, I don't > > think privsep really needs to be in a real way. > > +1 > Agreed. I need to m

Re: [openstack-dev] [Neutron] Bug deputy process

I missed this the first time around, but I concur with the comments of the other deputies - the effort only took me about an hour or two a day and I think it's been rather helpful :) Ryan Moats (regXboi) __ OpenStack Developme

Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes

Excerpts from Barrett, Carol L's message of 2015-12-03 21:06:22 +: > I'm a bit confused as to the role of Themes today. If they emerge as a result > of Project plans, then it seems like documentation, not trying to provide > input to set priorities/directions for Projects. > > Doug: Can you

Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

On 12/03/2015 01:05 PM, Emilien Macchi wrote: Hi, For some months, Puppet OpenStack group has been very lucky to have Sofer working with us. He became a huge contributor to puppet-keystone, he knows the module perfectly and wrote insane amount of code recently, to bring new features that our com

Re: [openstack-dev] [neutron] StandardAttributes overlap with existing data models

Just to keep things consistent, I would say either just add a new column to SecurityGroupRule or add the column to standard attribute table and migrate all of the existing data. Between those two I would probably vote for the first for the time being while we get all of the patterns worked out for

[openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

Hello Trovers and Horizoneers,   The intention of this email is to get everyone on the same page so we are all aware of what is going on. As many of you are probably already aware, Horizon is moving toward the plugin model for all of its dashboards (including existing dashboards). This release cycl

[openstack-dev] [neutron] StandardAttributes overlap with existing data models

Hi Devs, I've got an open RFE[1] to allow descriptions on Security Group Rules. It was suggested that I add a new StandardAttribute instead of modifying the SecurityGroupRule data model to add a description. My questions are: 1. Will a new 'description' StandardAttribute leave resources that al

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

+1, solid reasoning (surface area that infra hits vs osc), would love to have the infra-core team onboard stevemar From: Monty Taylor To: "OpenStack Development Mailing List (not for usage questions)" Date: 2015/12/03 11:53 AM Subject:[openstack-dev] [os-client-co

Re: [openstack-dev] [os-client-config] Proposing Morgan Fainberg forcore

well said, +1 from me (via the osc-core team) stevemar From: Monty Taylor To: "OpenStack Development Mailing List (not for usage questions)" Date: 2015/12/03 11:55 AM Subject:[openstack-dev] [os-client-config] Proposing Morgan Fainberg for core Hey

Re: [openstack-dev] [tripleo] stable/liberty branches are open

On 12/03/2015 09:47 AM, Steven Hardy wrote: > All, > > After quite a long battle, the stable/liberty CI is now working, as of this > patch: > > https://review.openstack.org/#/c/247694/ > > We still need to verify that CI works properly on all other repos, because > we had to go ahead and land

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On 04/12/15 03:41, Steven Hardy wrote: On Thu, Dec 03, 2015 at 08:11:41AM -0500, Dan Prince wrote: On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote: So, chatting with Giulio today about https://bugs.launchpad.net/heat/ +bug/1521944 has be thinking about $subject. The root case of that iss

Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes

I'm a bit confused as to the role of Themes today. If they emerge as a result of Project plans, then it seems like documentation, not trying to provide input to set priorities/directions for Projects. Doug: Can you clarify this for me? My interest is to provide input to Project planning, and ag

Re: [openstack-dev] [release] preparing your mitaka-1 milestone tag

Excerpts from Robert Collins's message of 2015-12-04 09:13:26 +1300: > On 28 November 2015 at 03:32, Doug Hellmann wrote: > > Next week (Dec 1-3) is the Mitaka 1 milestone deadline. Release > > liaisons for all managed projects using the cycle-with-milestones > > release model will need to propose

Re: [openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

+1 from me. On Thu, Dec 3, 2015 at 3:05 PM, Emilien Macchi wrote: > Hi, > > For some months, Puppet OpenStack group has been very lucky to have > Sofer working with us. > He became a huge contributor to puppet-keystone, he knows the module > perfectly and wrote insane amount of code recently, to

Re: [openstack-dev] [nova]New Quota Subteam on Nova

On Thu, 2015-12-03 at 12:33 -0800, melanie witt wrote: > On the parallel request bug [2], if you check out alaski's comment #3, > he mentions the keypairs and security groups apis check quota without > using the reservation system. We should investigate why they don't and > whether we can convert t

Re: [openstack-dev] [TripleO] workflow

On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote: > On 23 November 2015 at 14:37, Dan Prince wrote: > > There are lots of references to "workflow" within TripleO > > conversations > > these days. We are at (or near) the limit of what we can do within > > Heat > > with regards to upgrades.

Re: [openstack-dev] [nova]New Quota Subteam on Nova

-@openstack On Dec 1, 2015, at 11:45, Vilobh Meshram wrote: > If you can share the details of the bug that Joe mentioned, to reproduce > quota bugs locally, it would be helpful. Here's the bug comment I was thinking of, #15 by jogo on the script he used to make quotas go out of sync while re

[openstack-dev] [horizon] Proposal to add Richard Jones to horizon-core

+1 from me for Richard!! - Original message - From: David Lyle To: OpenStack Development Mailing List Cc: Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-core Date: Wed, Dec 2, 2015 10:54 AM Let's try that again. I propose adding Richard Jones[1] to

[openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-core

+1 from me for Timur! - Original message - From: David Lyle To: OpenStack Development Mailing List Cc: Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-core Date: Wed, Dec 2, 2015 10:54 AM I propose adding Timur Sufiev[1] to horizon-core. Over the la

Re: [openstack-dev] [release] preparing your mitaka-1 milestone tag

On 28 November 2015 at 03:32, Doug Hellmann wrote: > Next week (Dec 1-3) is the Mitaka 1 milestone deadline. Release > liaisons for all managed projects using the cycle-with-milestones > release model will need to propose tags for their repositories by > Thursday. Tag requests submitted after Dec

[openstack-dev] [puppet] proposing Sofer Athlan Guyot part of puppet-keystone core team

Hi, For some months, Puppet OpenStack group has been very lucky to have Sofer working with us. He became a huge contributor to puppet-keystone, he knows the module perfectly and wrote insane amount of code recently, to bring new features that our community requested (some stats: [1]). He's always

[openstack-dev] [TripleO] Summary of In-Progress TripleO Workflow and REST API Development

Hey all, Over the past few months, there's been a lot of discussion and work around creating a new REST API-supported TripleO deployment workflow. However most of that discussion has been fragmented within spec reviews and weekly IRC meetings, so I thought it might make sense to provide a high-le

Re: [openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

+1 * a million for more keystone knowledge and active reviewing. -Dave On 12/03/2015 11:44 AM, Monty Taylor wrote: Hey all, I'd like to propose that we include Morgan Fainberg as core on os-client-config. He's in the over/under on matching other active reviewers on the project, and he's got

Re: [openstack-dev] [Neutron] Bug deputy process

> One concern I have is ensuring we rotate people, because it does take some > time, and if the same handful of rotate, they will burn out. So I actively > encourage more people to volunteer, you don't even have to be a Neutron > core reviewer to do this! I actually didn't realize that it didn't r

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

Hi, Roman. On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov wrote: > I've selected 13 real-world tasks from customer (i.e. update flag X in > nova.conf): > - 6/13 require fuel-library patching (or is #2 unusable) > - 3/13 are OK and can be done with #2 > - 4/13 can be done with some limitations. >

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 10:48, Johnston, Nate wrote: > I second that - I don’t have the ability to triage a bug. But I would be > happy to take a watch if I could. > Anyone has the ability to triage bugs, but some don't have full privileges (like assigning milestones, owner or severity) as they d

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 10:42, Smigiel, Dariusz wrote: > > From: Kyle Mestery [mailto:mest...@mestery.com] > [...] > > One concern I have is ensuring we rotate people, because it does take > some time, and if the same handful of rotate, they will burn out. So I > actively encourage more people to v

Re: [openstack-dev] [Neutron] Bug deputy process

On Thu, Dec 03, 2015 at 10:58:07AM EST, Ihar Hrachyshka wrote: > The thing I would like us to see enhanced is making sure that tags set to > bugs are actively tracked by corresponding teams. Thanks - you just reminded me to tag two bugs that I had just touched. :) -- Sean M. Collins __

Re: [openstack-dev] [Neutron][DVR]

Hi Carl, Sounds reasonable suggestion. Thanks Swami -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Thursday, December 03, 2015 10:47 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][DVR] I was going to bring this up in the meeting this

Re: [openstack-dev] [horizon] Proposal to add Richard Jones tohorizon-core

An equally BIG +1 from me! Thanks for all the reviews and patches from your minions Richard!   - Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-coreDate: Wed, Dec 2, 2015 10:57 AM  I pr

Re: [openstack-dev] [nova]New Quota Subteam on Nova

I have been working in Nova Quotas for more than a year, and I also think that Nova Quota sub-team is a good idea. Let us form the team and work together. best regards

Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev tohorizon-core

BIG +1 for me. Thanks for all of the great work Timur!   - Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-coreDate: Wed, Dec 2, 2015 10:54 AM  I propose adding Timur Sufiev[1] to horizon

Re: [openstack-dev] [Neutron] Bug deputy process

I can only agree with the opinions others already expressed. It’s been a very good initiative. Going through the bugs everyday during my week opened my eyes to how the end users face bugs, an the kind of issues we have. I got myself educated into following the incoming bug stream from launchpad

Re: [openstack-dev] [nova] Contribution to improve Nova's config option space

OK, got it Do you have a generic IDE for remote debugging of nova, like pycharm? Or how do you actually debug the code? Regards Esra ÇELİK www.bilgem.tubitak.gov.tr celik.e...@tubitak.gov.tr - Orijinal Mesaj - > Kimden: "Markus Zoeller" > Kime: "OpenStack Development Mailing Li

[openstack-dev] [Fuel] FFE for Ubuntu bootstrap

Hi folks, Let me clarify the situation with Ubuntu bootstrap feature. First of all, I would like to highlight that all functional commits for this feature were merged. This means that starting from yesterday everyone has an ability to switch to Ubuntu-based bootstrap manually and start using it.

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

On 12/03/2015 10:07 AM, arkady_kanev...@dell.com wrote: > Emilien, > > So what is the statement we (OpenStack) wants to provide about UI for OOO? > > If we will not provide it people outside our community and compatitors > to OpenStack will fill the void. We're working on a new UI, but it won't

[openstack-dev] [Neutron][DVR]

I was going to bring this up in the meeting this morning but IRC troubles prevented it. After chatting with Armando, I'd like to suggest a few enhancements to how we're tackling DVR during this cycle. I'm hoping that these changes help us to get things done faster and more efficiently. Let me kn

Re: [openstack-dev] [Neutron] Bug deputy process

I second that - I don’t have the ability to triage a bug. But I would be happy to take a watch if I could. —N. > On Dec 3, 2015, at 1:42 PM, Smigiel, Dariusz > wrote: > >> From: Kyle Mestery [mailto:mest...@mestery.com] > [...] >> One concern I have is ensuring we rotate people, because it

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 12/03/2015 07:40 AM, Duncan Thomas wrote: On 3 December 2015 at 11:14, Li, Xiaoyan mailto:xiaoyan...@intel.com>> wrote: Just to clear the data operations cinder needs to touch plaintext data are: 1) Create volume from glance image 2) Create glance image from volume 3

Re: [openstack-dev] [Neutron] Bug deputy process

> From: Kyle Mestery [mailto:mest...@mestery.com] [...] > One concern I have is ensuring we rotate people, because it does take some > time, and if the same handful of rotate, they will burn out. So I actively > encourage more people to volunteer, you don't even have to be a Neutron core > revi

[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 12/3/2015

This morning we had a brief meeting but did have a chance to touch on a little bit of the Glare back-end work for the App Catalog. Additionally I mentioned we're going to start working to include TOSCA elements in the catalog soon. We could still really use a volunteer to chair a meeting time conv

Re: [openstack-dev] [Neutron] Bug deputy process

Roughly an hour a day, and super useful. I’d echo that anyone can volunteer, since a lot of the job is reaching out to various folks for input (docs/policies/neutron-teams.rst is the map of truth.) I found a lot of bugs that I care about in the pre-mitaka backlog, that I didn’t know existed. Th

[openstack-dev] [neutron] [networking-sfc] Temporary instructions

Hi networking-sfc, What is the recommended place to host the temporary installation instructions? Best regards, Igor. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.o

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

Hi, Roman So here is how we think we are going to tackle this. The whole idea is to make Fuel architecture much more flexible. We are actively working on this and are going to present draft of initial documents pretty shortly before the end of the year. * *Short (very-very short) summary of our

[openstack-dev] [Neutron] Rename tenant to project: discussion

Hey Neutrinos (thanks armax for this word :), Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], and probably forever. It will stay at least four releases, but we need to decide, how to conquer problem of renaming... And more important: consider if it's a problem for Ne

[openstack-dev] [neutron] Multiple locations for documentation of features

Hi, I've noticed that a lot of features are now being documented as RSTs inside of devref. Like the following: https://review.openstack.org/#/c/251859/ But there are lots already present. Can someone point out to me what the criteria is for these documents? I am a little confused about the relat

Re: [openstack-dev] [puppet] Puppet 4 and Beaker testing

Cody Herriges wrote: > Today we do unit testing against all kinds of puppet versions but > beaker's acceptance testing is currently limited to the 3.8.x series. > The is because we install "latest" Puppet from Puppet Labs repositories > but do so using the old packaging style which relied on depend

Re: [openstack-dev] [horizon]

It all depends on Glance support, you'd better ask them. On Thu, Dec 3, 2015 at 7:08 PM Kyrylo Galanov wrote: > Looks great. What is the estimated date / release for this feature to be > delivered? > > On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev wrote: > >> Please take a look at >> https://blu

Re: [openstack-dev] [nova] Contribution to improve Nova's config option space

Esra Celik wrote on 12/03/2015 06:50:49 PM: > From: Esra Celik > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 12/03/2015 06:51 PM > Subject: Re: [openstack-dev] [nova] Contribution to improve Nova's > config option space > > Hi Markus, > > This seems to be a

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On 03/12/15 09:41, Steven Hardy wrote: On Thu, Dec 03, 2015 at 08:11:41AM -0500, Dan Prince wrote: On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote: So, chatting with Giulio today about https://bugs.launchpad.net/heat/ +bug/1521944 has be thinking about $subject. The root case of that iss

Re: [openstack-dev] [nova] Contribution to improve Nova's config option space

Hi Markus, This seems to be a good one for me to start contributing to nova. And happily it will be useful for me as an openstack operator too. I couldn't find you at IRC, maybe a little late.. Where do you think should I start? I can see a list for config options at etherpad. Thanks in ad

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

On Thu, Dec 3, 2015 at 10:33 AM, Ihar Hrachyshka wrote: > Akihiro Motoki wrote: > > Hi, >> >> python-neutronclient still has XML support of Neutron API. >> I would like to discuss when we drop XML support in neutronclient. >> >> Neutron API XML suppoort was marked as deprecated in Icehouse and J

Re: [openstack-dev] [neutron][tap-as-a-service] Tap-as-a-service API

Thanks Yamamoto. Yes, agree it makes sense to keep it in the TaaS tree. Would be great though to have broader audience come and review it. Seems like there is not much activity. I can go ahead and take a stab at reviving it [1] and then we can iterate over and improve. [1] https://review.openstac

Re: [openstack-dev] [Neutron][TaaS] Query regarding TaaS API

Hi Reedip, I believe TaaS API will go through a round of reviews when the spec is introduced. It will be good to discuss these points there. Fawad Khaliq On Wed, Nov 25, 2015 at 12:45 PM, reedip banerjee wrote: > Dear Members of Neutron-TaaS community, > I have a few queries related to the Ta

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

I'm ok with that. The current core group is small and the project is critical enough to have them as backup. Ghe Rivero Quoting Monty Taylor (2015-12-03 17:50:17) > Hey all, > > os-client-config is now in the critical path for Infra's Nodepool, > meaning that there are some places where a bug sur

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

Sounds like a great idea. On Thu, Dec 3, 2015 at 9:50 AM, Monty Taylor wrote: > Hey all, > > os-client-config is now in the critical path for Infra's Nodepool, meaning > that there are some places where a bug surfacing in it can take down the > entire CI infrastructure. Infra also uses many more

Re: [openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

+1 Quoting Monty Taylor (2015-12-03 17:44:13) > Hey all, > > I'd like to propose that we include Morgan Fainberg as core on > os-client-config. He's in the over/under on matching other active > reviewers on the project, and he's got a good understanding of the > related problem space. Also, he's i

Re: [openstack-dev] [Fuel] CentOS7: merge freeze announcement

All, Just an update: we successfully passed *Decision point 3* in Centos7 merge plan [1], QA didn't find significant regressions after yesterday's merge party. The latest SWARM pass rate - 73% so we decided to proceed with merging CentOS7 commits on Fri Dec 4. Please note that any other commits (

Re: [openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

On 11/20/2015 10:37 AM, Matt Riedemann wrote: On 11/20/2015 10:20 AM, Matt Riedemann wrote: On 11/20/2015 3:48 AM, Matthew Booth wrote: I wrote this a while back, which implements 'migrate everything off this compute host' in the most robust manner I could come up with using only the exte

Re: [openstack-dev] [ironic] specs process for ironic-inspector

Hi Dmitry, should we also configure Launchpad to have blueprints references there (for release/milestone targeting etc)? Or is it not needed? Cheers, On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur wrote: > FYI: the process is in effect now. > > Please submit specs to > https://github.com/openst

[openstack-dev] [all] making project_id optional in API URLs

For folks that don't know, we've got an effort under way to look at some of what's happened with the service catalogue, how it's organically grown, and do some pruning and tuning to make sure it's going to support what we want to do with OpenStack for the next 5 years (wiki page to dive deeper here

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

I would love TripleO support on this topic On 12/03/2015 11:07 AM, arkady_kanev...@dell.com wrote: > Emilien, > > So what is the statement we (OpenStack) wants to provide about UI for OOO? AFIK, Tuskar won't be continued to be the TripleO UI but I might have misunderstood something. > If we wil

[openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

Hey all, os-client-config is now in the critical path for Infra's Nodepool, meaning that there are some places where a bug surfacing in it can take down the entire CI infrastructure. Infra also uses many more of the advanced features in clouds.yaml than most other people, so the surface area

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

On 3 December 2015 at 08:33, Ihar Hrachyshka wrote: > Akihiro Motoki wrote: > > Hi, >> >> python-neutronclient still has XML support of Neutron API. >> I would like to discuss when we drop XML support in neutronclient. >> >> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno

[openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

Hey all, I'd like to propose that we include Morgan Fainberg as core on os-client-config. He's in the over/under on matching other active reviewers on the project, and he's got a good understanding of the related problem space. Also, he's interested and active, which for a low-volume project

Re: [openstack-dev] [Sender Auth Failure] Re: [neutron] How could an L2 agent extension access agent methods ?

Ihar, This is brilliant. The complexity of doing graceful CRUD on the OVS flow table especially when other features are active is so complex, that abstracting the management of it into functionality optimized for that task is an incredibly good idea, especially for those of us like me who are

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

Akihiro Motoki wrote: Hi, python-neutronclient still has XML support of Neutron API. I would like to discuss when we drop XML support in neutronclient. Neutron API XML suppoort was marked as deprecated in Icehouse and Juno and was dropped in Kilo. Juno is now EOL and we have no gate testing w

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

On Thu, Dec 3, 2015 at 7:59 AM, Akihiro Motoki wrote: > Hi, > > python-neutronclient still has XML support of Neutron API. > I would like to discuss when we drop XML support in neutronclient. > > Neutron API XML suppoort was marked as deprecated in Icehouse and Juno > and was dropped in Kilo. Jun

Re: [openstack-dev] [Neutron] Bug deputy process

On Wed, Dec 2, 2015 at 10:49 AM, Armando M. wrote: > Hi neutrinos, > > It's been a couple of months that the Bug deputy process has been in place > [1,2]. Since the beginning of Mitaka we have collected the following > statistics (for neutron and neutronclient): > > Total bug reports: 373 > >

Re: [openstack-dev] [reno] using 'releasenotes' directive in documents for released tarball (without git info)

Excerpts from Akihiro Motoki's message of 2015-12-04 01:03:40 +0900: > Hi, > > python-neutronclient recently added reno support and > I added the reno directive " . release-notes::" to the neutronclient > documentation. > As a result, this prevents users from building the documentation from > rele

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 01:42, Rossella Sblendido wrote: > Hi Armando, > > On 12/02/2015 07:49 PM, Armando M. wrote: > >> Hi neutrinos, >> >> It's been a couple of months that the Bug deputy process has been in >> place [1,2]. Since the beginning of Mitaka we have collected the >> following statist

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 07:58, Ihar Hrachyshka wrote: > Armando M. wrote: > > Hi neutrinos, >> >> It's been a couple of months that the Bug deputy process has been in >> place [1,2]. Since the beginning of Mitaka we have collected the following >> statistics (for neutron and neutronclient): >> >>

[openstack-dev] [glance] Auth_version from 'old style' URLs in the database

Hi, Currently glance will use an auth_url if in the database. Eg. 10.0.0.8:5000/v2.0 However glance currently takes the auth_version from the config files. Therefore this can lead to a mismatch of keystone version to be used between the url and the config files. This is problematic due to a diffe

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

Emilien, So what is the statement we (OpenStack) wants to provide about UI for OOO? If we will not provide it people outside our community and compatitors to OpenStack will fill the void. Thanks, Arkady -Original Message- From: Emilien Macchi [mailto:emil...@redhat.com] Sent: Wednesday, D

Re: [openstack-dev] [Neutron] Bug deputy process

On 2 December 2015 at 17:38, Sean M. Collins wrote: > I was not a deputy - but I had been subscribed to launchpad bugs for > years, but had a procmail filter set so it went into a folder that prior > to this new initiative, had remained unread for years. As part of this > new effort I try and spe

Re: [openstack-dev] [Neutron] Bug deputy process

On 2 December 2015 at 11:02, Salvatore Orlando wrote: > I only have some historical, anecdotal, and rapidly waning memory of > previous releases. > Nevertheless my feeling is that the process has been a success so far. > In past times it would not have been a surprise if a bug fell under the > ra

Re: [openstack-dev] Looking to contribute

Lisa Jenkins wrote on 11/02/2015 08:06:57 PM: > From: Lisa Jenkins > To: openstack-dev@lists.openstack.org > Date: 11/02/2015 08:11 PM > Subject: [openstack-dev] Looking to contribute > > Hi new dev looking to contribute and am open to anything. Which > projects need resources and have some l

[openstack-dev] [nova] Contribution to improve Nova's config option space

Who === If you are a new contributor and are still searching for a way to contribute to Nova, this mail is for you. If you are not a newbie but have a bit bandwidth available, you're welcome too :) Why === Why you should bother? * It's an easy way to start contributing * I can offer you to help wi

Re: [openstack-dev] [Neutron] Scaling our testing needs

Armando M. wrote: Hi Neutrinos, I would like to share a proposal with you on how we could scale our ever-growing testing needs, and at the same time, provide guidance to the developers who care about the quality of the work they produce, and how they can protect it from the dreadful regr

  1   2   >