Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

On 06/09/2015 04:07 PM, Mathieu Gagné wrote: > On 2015-06-08 2:48 AM, Yanis Guenane wrote: >> If we look at openstacklib::db::postgresql[1] or >> openstackib::db::mysql[2] they are simple wrapper around >> puppet resources with no extra logic, but a common resource across all >> modules. > I see

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

Sorry for late response here, 2015-06-20 9:14 GMT+09:00 Devananda van der Veen : > > Long version... > Every HTTP response from Ironic today includes three headers: min, max, and > version. The service can present an older API version, as long as it is > greater-than-or-equal-to the minimum suppor

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Hi, > If renaming "Ironic" to the other, is it still necessary to keep the > name in the header? > There are some projects which are already renamed like Neutron, Zaqar > and the others. > So "OpenStack-API-Version" which doesn't contain project name seems > reasonable for me. I don't think we sh

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: Sorry for late response here, 2015-06-20 9:14 GMT+09:00 Devananda van der Veen : Long version... Every HTTP response from Ironic today includes three headers: min, max, and version. The service can present an older API version, as long as it is g

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 06/24/2015 10:17 PM, Joe Gordon wrote: > > > On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy > wrote: > > On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote: > > > > > > On 6/24/2015 9:09 AM, Kashyap Chamarthy wrote: > > >On Wed

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes : > Hi, > >> If renaming "Ironic" to the other, is it still necessary to keep the >> name in the header? >> There are some projects which are already renamed like Neutron, Zaqar >> and the others. >> So "OpenStack-API-Version" which doesn't contain pro

Re: [openstack-dev] [Nova] The unbearable lightness of specs

Maxim Nestratov wrote: > 24.06.2015 20:21, Daniel P. Berrange пишет: >> On Wed, Jun 24, 2015 at 04:46:57PM +, Michael Krotscheck wrote: >>> First: Overhead >>> - 1 week for vacation >>> - 1 week for holidays. >>> - 4 weeks for feature freeze. >>> - 4 weeks of pre-summit roadmap planning. >>> -

Re: [openstack-dev] [Nova] The unbearable lightness of specs

Joe Gordon wrote: > On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe > wrote: >> [...] >> Other emails have touched on the biggest disconnect in the process: that >> an approved spec magically becomes unapproved on a particular calendar >> date. This makes no sense whatsoever. If

Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

Le 24/06/2015 19:56, Joe Gordon a écrit : On Tue, Jun 23, 2015 at 3:41 AM, Sylvain Bauza > wrote: Hi team, Some discussion occurred over IRC about a bug which was publicly open related to TrustedFilter [1] I want to take the opportunity for raising

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Hi folks, How is the project going? openstack/magnum-ui is still empty for now. -zhenguo From: Bradley Jones (bradjone) [mailto:[email protected]] Sent: Friday, June 12, 2015 6:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][horizon]

[openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

Hi Sahara, I'm working under UI. I have a tenant "demo", with two users: admin(role = admin) & demo. I'm working as user "demo". When I try to create a datasource, it ask me to add username and password for swift. My question is: Why Sahara didn't use current username("demo") and password

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-25 17:31 GMT+09:00 Dmitry Tantsur : > On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: >> >> Sorry for late response here, >> >> 2015-06-20 9:14 GMT+09:00 Devananda van der Veen >> : >>> >>> >>> Long version... >>> Every HTTP response from Ironic today includes three headers: min, max, >>> a

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/25/2015 11:11 AM, Ken'ichi Ohmichi wrote: 2015-06-25 17:31 GMT+09:00 Dmitry Tantsur : On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: Sorry for late response here, 2015-06-20 9:14 GMT+09:00 Devananda van der Veen : Long version... Every HTTP response from Ironic today includes three

Re: [openstack-dev] [Nova][Keystone] The unbearable lightness of specs

On 06/24/2015 09:00 PM, Adam Young wrote: > On 06/24/2015 12:25 PM, Daniel P. Berrange wrote: >> Which happened repeatedly. You could say that >> the first patch submitted to the code repository should simply be a doc >> file addition, that describes the feature proposal and we should discuss >> th

Re: [openstack-dev] [Nova][Keystone] The unbearable lightness of specs

On Wed, Jun 24, 2015 at 06:30:06PM -0700, James Bottomley wrote: > On Wed, 2015-06-24 at 17:25 +0100, Daniel P. Berrange wrote: > > On Wed, Jun 24, 2015 at 11:52:37AM -0400, Adam Young wrote: > > > On 06/24/2015 06:28 AM, Nikola Đipanov wrote: > > > >Gerrit and our spec template are a horrible tool

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-25 18:16 GMT+09:00 Dmitry Tantsur : > On 06/25/2015 11:11 AM, Ken'ichi Ohmichi wrote: >> >> 2015-06-25 17:31 GMT+09:00 Dmitry Tantsur : >>> >>> On 06/25/2015 10:18 AM, Ken'ichi Ohmichi wrote: Sorry for late response here, 2015-06-20 9:14 GMT+09:00 Devananda van der

Re: [openstack-dev] [Nova][Keystone] The unbearable lightness of specs

On 25 June 2015 at 10:19, Daniel P. Berrange wrote: > On Wed, Jun 24, 2015 at 06:30:06PM -0700, James Bottomley wrote: >> On Wed, 2015-06-24 at 17:25 +0100, Daniel P. Berrange wrote: >> > On Wed, Jun 24, 2015 at 11:52:37AM -0400, Adam Young wrote: >> > > On 06/24/2015 06:28 AM, Nikola Đipanov wrot

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 25 June 2015 at 09:49, Thierry Carrez wrote: > Maxim Nestratov wrote: >> 24.06.2015 20:21, Daniel P. Berrange пишет: >>> On Wed, Jun 24, 2015 at 04:46:57PM +, Michael Krotscheck wrote: First: Overhead - 1 week for vacation - 1 week for holidays. - 4 weeks for feature fre

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 25 June 2015 at 09:58, Thierry Carrez wrote: > Joe Gordon wrote: >> On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe > > wrote: >>> [...] >>> Other emails have touched on the biggest disconnect in the process: that >>> an approved spec magically becomes unapproved on a particul

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum- need a vote from the core team

Looking forward to this feature, too. -tobe -- Original -- From: "niuzhenguo"; Date: Thu, Jun 25, 2015 05:05 PM To: "openstack-dev@lists."; Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum- need a vote from the core team H

[openstack-dev] [oslo] About app-agnostic-logging-parameters

Hi, Doug Hellmann, and oslo.log team members, I'm Daisuke Fujita of Fujitsu. May I ask you about this Blueprint? https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters This patch has been already implemented in master branch of oslo_log. But, blueprint status is " Start

Re: [openstack-dev] [Manila][Infra] A proposal for 3rd-party vendor CI in Manila

Hi, please find our plan here: https://github.com/csabahenk/manila/wiki/CI-plan-for-Manila-glusterfs-drivers Csaba - Original Message - > From: "Ben Swartzlander" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Wednesday, May 13, 2015 11:23:07 PM > Subj

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role

Hi, Samuel, We use magic words in node names for Fuel Contrail plugin. It uses the "bare" role to deploy Contrail controllers. Unfortunately, we don't have node tags in 6.1, but we are going to implement custom roles from a plugin in 7.0. Please see a spec https://blueprints.launchpad.net/fuel/+s

Re: [openstack-dev] [oslo] About app-agnostic-logging-parameters

Hi, Daisuke, * 'resource' is not necessary in logging_context_format_string. * IMO, I think 'resource' could satisfy your requrement, like this: LOG.info(_LI('begin some operation'), resource= {'type': 'volume', 'id': '40e0f194-0ccb-422f-a543-c5f9022acb6f'}) On Thu, Jun 25, 2015

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role

Hi guys, And also for 7.0 there is a spec in review [1] about custom labels that may be interesting to differentiate nodes with the same role if labels are exposed via the astute.yaml. Regards, [1] https://review.openstack.org/#/c/184076/ On Thu, Jun 25, 2015 at 12:47 PM, Andrey Danin wrote:

Re: [openstack-dev] [Nova] The unbearable lightness of specs

Apologies to go back in time in this thread, but I feel like I should respond directly to this original email... On 24 June 2015 at 11:28, Nikola Đipanov wrote: > Hey Nova, > > I'll cut to the chase and keep this email short for brevity and clarity: > > Specs don't work! In many cases, specs rea

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 06/24/2015 03:42 PM, Daniel P. Berrange wrote: On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote: Hey Nova, I'll cut to the chase and keep this email short for brevity and clarity: Specs don't work! They do nothing to facilitate good design happening, if anything they prevent i

[openstack-dev] [neutron][oslo][all] publisher/subscriber mechanism for resources (fanout+versioned objects)

Hi all, Within the neutron/QoS design I've been working on the messaging bits trying to design an architecture [1][2] which allowed (in combination with oslo versioned objects) easy distribution of resource changes across interested subscribers. Our use case is neutron-server (or servi

Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

Hi, Sahara doesn't have user's username and password, only user's token, that could expire in some time. The simplest installation requires you to specify credentials explicitly, but you could configure Sahara to access Swift using proxy user and trusts, more info in docs - http://docs.openstack.o

Re: [openstack-dev] [Nova] The unbearable lightness of specs

> > >>> I've repeatedly stated that the fact that we created an even smaller >>> clique of people to approve specs (nova-drivers which is a tiny subset >>> of the already fr too small nova-core) is madness, as it creates >>> an even worse review burden on them, and thus worsens the bottleneck >

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote: > 2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes : >> Hi, >> >>> If renaming "Ironic" to the other, is it still necessary to keep the >>> name in the header? >>> There are some projects which are already renamed like Neutron, Zaqar >>> and the others.

Re: [openstack-dev] [Nova] The unbearable lightness of specs

We are not in a good way. The 'drivers' team is very small and just have a small handful of people approving these specs is a huge bottleneck. Taking into the fact that the core team is relatively small the cores will most probably not even get to reviewing the code when it is posted, so it will

Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

On 24 June 2015 at 09:35, Dulko, Michal wrote: >> -Original Message- >> From: Sylvain Bauza [mailto:[email protected]] >> Sent: Wednesday, June 24, 2015 9:39 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [nova] How to properly detect

[openstack-dev] [Tricircle]New branch added

Hi Team, Zhiyuan just added a new branch "experiment" for the purpose of hacking new ideas, check it out at https://github.com/stackforge/tricircle/tree/experiment. -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: huangzhip...

Re: [openstack-dev] [Nova] The unbearable lightness of specs

25.06.2015 14:58, Sergey Nikitin пишет: I've repeatedly stated that the fact that we created an even smaller clique of people to approve specs (nova-drivers which is a tiny subset of the already fr too small nova-core) is madness,

[openstack-dev] [Magnum] Python 3 support

Hello team, I’ve submitted a blueprint[1] for adding python 3 compatibility to Magnum. Many of the other integrate release OpenStack projects have started on this[2] journey and it would be great to add ourselves to that list. This will entail refactoring a fairly small amount of code throughout

Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

> -Original Message- > From: John Garbutt [mailto:[email protected]] > Sent: Thursday, June 25, 2015 2:22 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] How to properly detect and fence a > compromised host (and why I dislike T

Re: [openstack-dev] [Nova] The unbearable lightness of specs

+1. Not closing the spec process and alowing work to continue is good. Open Source works by allowing developers to scratch itches. If you impeed that itch scratching long enough they will go somewhere else to be able to meet their needs. The window between missed spec deadline and next open wind

Re: [openstack-dev] [Nova] The unbearable lightness of specs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/24/2015 04:41 PM, Joe Gordon wrote: > We currently have the fast track process, where if a spec was > previously approved we will quickly re-approve it. (I do a git diff > between the previous version and make sure the diff is trivial). By > m

[openstack-dev] [neutron] new project: networking-macvtap

I want to proclaim a new networking project that we plan to start: It's called 'networking-macvtap'. This project will contain a neutron ml2 driver and an corresponding neutron l2 agent. It's aim is to allow instance network attachments via macvtap in bridge mode independent of the physical netwo

Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

On 25 June 2015 at 14:09, Dulko, Michal wrote: >> -Original Message- >> From: John Garbutt [mailto:[email protected]] >> Sent: Thursday, June 25, 2015 2:22 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [nova] How to properly detec

Re: [openstack-dev] [nova] import OVA/OVF into openstack

Hi, On 06/24/2015 11:19 PM, Xingjun Chu wrote: Hi, Not sure if I should send this to glance or nova project, anyways ... As far as I know, Openstack today does not support OVA/OVF image natively (correct me if I were wrong). I am wondering if there is any plan to support them? Also Any reco

[openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Hi all, Recent neutron third party CI issues have got me thinking again about a topic which we discussed in Vancouver: Should any Third Party CI have voting rights for neutron patches in gerrit? I’d like to suggest that they shouldn’t. A -1 from a third party CI tool can often be an indication

Re: [openstack-dev] [nova] import OVA/OVF into openstack

Thank you Rado! -Xingjun Chu -Original Message- From: Radoslav Gerganov [mailto:[email protected]] Sent: Thursday, June 25, 2015 9:44 AM To: [email protected] Subject: Re: [openstack-dev] [nova] import OVA/OVF into openstack Hi, On 06/24/2015 11:19 PM, Xingjun Chu wr

Re: [openstack-dev] [Sahara] Why Sahara request user to give username/password for accessing the job binary in Swift ?

hi Chen, i agree with Sergey has said, also i have posted a small article[1] about how i configure proxy domains. i hope this may help clear the confusion surrounding this feature. regards, mike [1]: https://elmiko.github.io/2015/06/25/configuring-sahara-with-proxy-domains.html __

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Hi, just wanted to mention another tool to work with 'Puppetfile' - r10k: https://github.com/puppetlabs/r10k/blob/master/doc/puppetfile.mkd Regards, Alex On Wed, Jun 24, 2015 at 11:04 PM, Paul Belanger wrote: > On 06/23/2015 01:51 PM, Alex Schultz wrote: > >> Hello everyone, >> >> I took some

[openstack-dev] Scheduler hints, API and Objects

I have been growing concerned recently with some attempts to formalize scheduler hints, both with API validation and Nova objects defining them, and want to air those concerns and see if others agree or can help me see why I shouldn't worry. Starting with the API I think the strict input valid

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

On 25 June 2015 at 16:08, John Davidge (jodavidg) wrote: > Hi all, > > Recent neutron third party CI issues have got me thinking again about a > topic which we discussed in Vancouver: > > Should any Third Party CI have voting rights for neutron patches in > gerrit? > Why should this be a deci

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Hi, I agree, and only vote +1 myself, but I don’t agree on mandating it. If someone has invested enough in their CI to be confident, we just supply rope. Thanks, doug > On Jun 25, 2015, at 8:08 AM, John Davidge (jodavidg) > wrote: > > Hi all, > > Recent neutron third party CI issues have g

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

I think this make sense. I have lost any faith on third party CIs after the Vancouver decision of not police them (I was doing that for a while and I was fine doing it). So, why to keep them with voting rights? I will say, let’s remove voting rights for all of them. Edgar From: "John Davidge (

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Thank for your response Salvatore. I am not sure what is your position in this topic? Are you fine removing voting rights to all Cis? Edgar From: Salvatore Orlando Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, June 25, 2015 at 7:59 AM To: "OpenStack Dev

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague wrote: > On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote: > > 2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes : > >> Hi, > >> > >>> If renaming "Ironic" to the other, is it still necessary to keep the > >>> name in the header? > >>> There are some project

Re: [openstack-dev] [Neutron] Modular L2 Agent

On Mon, Jun 22, 2015 at 06:42:11AM MDT, Kyle Mestery wrote: > Is there an RFE files for this? At this point, since Liberty-1 is this > week, an RFE would be the best approach forward. My gut is leaning towards > this not being in-scope for Liberty at this point, but an RFE would allow > us to have

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 11:33 AM, Anne Gentle wrote: Also I hadn't discovered X-OpenStack-Nova-API-Version until now -- and I don't think that we should use project names in end-user-facing messaging, ever. They then have to do a look up for "nova" among over 20 project names. [1] Since that got unmarked e

[openstack-dev] [Ironic] Mid-Cycle Sprint

Hello Fellow Ironic-ers, I am confirming the Mid-Cycle Sprint, hosted in the HP Seattle, WA [USA] Office on Aug 12-14, 2015. We look forward to seeing everyone there! Cheers! John Stafford Engineering Manager |HP Helion Openstack | Openstack-Ironic E: [email protected]

Re: [openstack-dev] Scheduler hints, API and Objects

On 06/25/2015 10:22 AM, Andrew Laski wrote: > I have been growing concerned recently with some attempts to formalize > scheduler hints, both with API validation and Nova objects defining > them, and want to air those concerns and see if others agree or can help > me see why I shouldn't worry. > >

[openstack-dev] Nova Spec Freeze Exception Request for Instance Users

In OpenStack, we have a very common problem of VM's needing to talk to OpenStack Services. Heat, Trove, Sahara, Octavia, Magnum, other services that provision vm's, all have need to either have a guest agent talk to a controller via Zaqar using a Keystone credential, or fetch Secrets from Barbi

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 05:33 PM, Anne Gentle wrote: On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague mailto:[email protected]>> wrote: On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote: > 2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes mailto:[email protected]>>: >> Hi, >> >>> If re

Re: [openstack-dev] [oslo] About app-agnostic-logging-parameters

Excerpts from Fujita, Daisuke's message of 2015-06-25 10:42:05 +: > Hi, Doug Hellmann, and oslo.log team members, > > I'm Daisuke Fujita of Fujitsu. > > May I ask you about this Blueprint? > > https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters > > This patch has

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur wrote: > On 06/25/2015 05:33 PM, Anne Gentle wrote: > >> >> >> On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague > > wrote: >> >> On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote: >> > 2015-06-25 17:25 GMT+09:00 Lucas Alvare

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 06:04 PM, Anne Gentle wrote: On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur mailto:[email protected]>> wrote: On 06/25/2015 05:33 PM, Anne Gentle wrote: On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague mailto:[email protected]>

Re: [openstack-dev] Interconnecting projects

I'll defer to Kevin, the spec author, but you should know that the implementation is not merged yet. - Original Message - > Hi Assaf, > > Now reading the rbac network specs carefully, I believe it does allow private > networks to be shared to other tenants by non-admin users. > > So the

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 12:04 PM, Anne Gentle wrote: > > > On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur > wrote: > > > I'm not sure where the assumption comes from that people will know > "compute" better than "nova". > > > I have been supporting developer end

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On 25/06/15 09:49, "Thierry Carrez" wrote: >Maxim Nestratov wrote: >> 24.06.2015 20:21, Daniel P. Berrange пишет: >>> On Wed, Jun 24, 2015 at 04:46:57PM +, Michael Krotscheck wrote: First: Overhead - 1 week for vacation - 1 week for holidays. - 4 weeks for feature freeze

Re: [openstack-dev] [neutron] new project: networking-macvtap

On Thu, Jun 25, 2015 at 7:39 AM, Andreas Scheuring < [email protected]> wrote: > > I want to proclaim a new networking project that we plan to start: > It's called 'networking-macvtap'. > > Cool! > This project will contain a neutron ml2 driver and an corresponding > neutron l2 agent.

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Aleksandr Didenko wrote: just wanted to mention another tool to work with 'Puppetfile' - r10k: I am a big fan of r10k - it is what we use internally @ Puppet and we encourage our users to do the same. https://github.com/puppetlabs/r10k Regards, Richard SysOps Engineer @ Puppet Labs _

Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)

>-Original Message- >From: ext John Garbutt [mailto:[email protected]] >Sent: Thursday, June 25, 2015 4:39 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [nova] How to properly detect and fence a >compromised host (and why I dislike T

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

Sean's point and Dmitri's are similar. There are APIs for projects which do not have official team or "program" names. And some teams may produce more than one forward-facing service. Naming the API based in the team name doesn't make sense. My previous point is that restricting the API name to t

[openstack-dev] Why doesn't Swift cache object data?

Hi, I have noticed that even though account/container information is cached using memcached in Swift, it doesn't cache any actual object data. Could someone enlighten me what's the consideration behind this decision? Because it seems like it might be useful... Thanks a lot Suli -- Suli Y

Re: [openstack-dev] [neutron][hyper-v] Instance can't get fixed ip on hyper-v compute node

Hello, ml2 conf file looks fine. nova logs look fine. neutron logs also seem fine, but this worries me a bit: 2015-06-24 20:45:18.556 4116 DEBUG hyperv.neutron.security_groups_driver [req-3786da36-6b03-433d-941e-00327839603c ] Creating port 3 rules prepare_port_filter C:\Program Files (x86)\C

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 06/25/2015 01:35 PM, Devananda van der Veen wrote: > Sean's point and Dmitri's are similar. > > There are APIs for projects which do not have official team or "program" > names. And some teams may produce more than one forward-facing service. > Naming the API based in the team name doesn't make

[openstack-dev] [TripleO] package based overcloud upgrades

Hi, I put together a quick etherpad to help outline the remaining patches left to support package based upgrades within the TripleO heat templates: https://etherpad.openstack.org/p/tripleo-package-upgrades The etherpad includes a brief overview of the upgrade approach, a list of patches related

[openstack-dev] [keystone] SPF exception: Extend endpoint filtering to Service Providers

Hi all, Endpoint filtering is a keystone extension since the Havana release, in Juno it was expanded by the Multi-Attribute Endpoint Grouping spec [1] that improves the filtering flexibility. Since Kilo, we added the concept of Service Providers to keystone, the list of such resources is returned

Re: [openstack-dev] [TripleO] package based overcloud upgrades

Hi Dan, > I put together a quick etherpad to help outline the remaining patches > left to support package based upgrades within the TripleO heat > templates: > > https://etherpad.openstack.org/p/tripleo-package-upgrades > > The etherpad includes a brief overview of the upgrade approach, a list >

Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights

On Wed, Jun 24, 2015 at 12:22 PM, Znoinski, Waldemar < [email protected]> wrote: > Hi Kyle and Neutron Cores, > > > > I would like to nominate Intel-Networking-CI ( > https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-Networking-CI) to > have voting (non-gating) rights. > > It’s be

Re: [openstack-dev] Interconnecting projects

Hi, creating rbac entries by non-admins will be controlled by policy.json. So you can enable it or disable it there. > Also is the action access_as_external available now ? Not yet. The code is still under review. On Thu, Jun 25, 2015 at 10:15 AM, Assaf Muller wrote: > I'll defer to Kevin, the

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague wrote: > For someone that's extremely familiar with what they are doing, they'll > understand that http://service.provider/compute is Nova, and can find > their way to Nova docs on the API. But for new folks, I can only see > this adding to confusion. >

[openstack-dev] [keystone] SPF Exception: Project tree deletion

Hi all, We are proposing a spec[1], on which we describe how the deletion and disablement of a subtree will work. This change improves the usabilty of Reseller/Hierarchical Multitenancy that are two of the biggest Keystone additions in the last releases. This feature will make it easier for operat

Re: [openstack-dev] [Fuel] Ceph Public Network Setting

Zhou, On Wed, Jun 24, 2015 at 8:38 PM Zhou Zheng Sheng / 周征晟 < [email protected]> wrote: > Hi, > > I also notice that in latest ceph-deploy source code, it allows us to > define public_network and cluster_network argument when calling > 'ceph-deploy new'. It also checks if monitor IP addres

Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role

Samuel, We could likely extend NodeGroups to do some of theses things. It was initially intended to create separated underlay network schemes for multiple-cluster-networks [1] but you would not be prevented from using the same network addresses if you didn't need the partation from that. I'm not s

[openstack-dev] [devstack] failures in devstack with "tests_require' must be a string or...."

So this is also filed as https://bugs.launchpad.net/devstack/+bug/1468808 But I figure a lot of folk are going to be running into it. Its the interaction between the changes discussed in http://lists.openstack.org/pipermail/openstack-dev/2015-June/067823.html and dirty devstack VM's that already

[openstack-dev] [openstack-operators][chef] Pre-Release of knife-openstack is out (1.3.0.rc.0)

I have released the 1.3.0.rc.0 version of the knife-openstack[1] gem. If you find any uses or have questions don’t hesitate to email me directly or put an issue[2] in. We are planning on waiting for the floating-ip issue[3] to be resolved before the official release happens. [1]: https://ruby

Re: [openstack-dev] [Ironic] Mid-Cycle Sprint

Event signup page is now live -- please RSVP! *https://www.eventbrite.com/e/openstack-ironic-sprint-august-2015-tickets-17533862254 * -Devananda On Thu, Jun 25, 2015 at 8:46 AM Stafford, John Richard wrote: >

Re: [openstack-dev] [TripleO] package based overcloud upgrades

On Thu, Jun 25, 2015 at 12:01:45PM -0700, Dan Smith wrote: > Hi Dan, > > > I put together a quick etherpad to help outline the remaining patches > > left to support package based upgrades within the TripleO heat > > templates: > > > > https://etherpad.openstack.org/p/tripleo-package-upgrades > >

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On Thu, Jun 25, 2015 at 1:39 AM, Nikola Đipanov wrote: > On 06/24/2015 10:17 PM, Joe Gordon wrote: > > > > > > On Wed, Jun 24, 2015 at 11:42 AM, Kashyap Chamarthy > > wrote: > > > > On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote: > > > > >

Re: [openstack-dev] [TripleO] package based overcloud upgrades

> Yeah I think it's fair to say this is just the first step of probably > several iterations towards fully orchestrated upgrades such as you > describe, atm really it's just a way of pushing out minor updates not > version-to-version upgrades (yet). Okay, that's cool, I just wanted to make sure I

Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

On Tue, Jun 23, 2015 at 04:05:08PM -0400, Jay Dobies wrote: > I didn't want to hijack Steve Hardy's thread about the recursive validation, > but I wanted to summarize the needs that Tuskar and the UI have been trying > to answer and some of the problems we ran into. > > I think it's fairly common

Re: [openstack-dev] [TripleO] package based overcloud upgrades

On Thu, Jun 25, 2015 at 01:57:14PM -0700, Dan Smith wrote: > > Yeah I think it's fair to say this is just the first step of probably > > several iterations towards fully orchestrated upgrades such as you > > describe, atm really it's just a way of pushing out minor updates not > > version-to-versio

Re: [openstack-dev] [TripleO] package based overcloud upgrades

On Thu, 2015-06-25 at 12:01 -0700, Dan Smith wrote: > Hi Dan, > > > I put together a quick etherpad to help outline the remaining > > patches > > left to support package based upgrades within the TripleO heat > > templates: > > > > https://etherpad.openstack.org/p/tripleo-package-upgrades > > >

Re: [openstack-dev] [Neutron] Modular L2 Agent

Thanks Sean for creating the rfe. I think we can go beyond the OVS and LB agents and aim for providing a framework where any agent (if and when needed) can benefit from it. We can continue the discussion on launchpad. Best, Mohammad From: "Sean M. Collins" To: "OpenStack Development

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Edgar, in a nutshell my point is that if we want to remove voting rights from every CI I'm fine with it. However, I think what's being discussed in this thread is already captured very well by [1] and believe the policy it outlines is perfectly fine for Neutron purposes. Salvatore [1] http://git

[openstack-dev] [Neutron] new RFE on quota enforcement

Hi, since the quota enforcement patches for the 'better-quotas' blueprint did not merge by liberty-1, and I forgot to resubmit the already-approved kilo spec [1], I have submitted a RFE to comply with the process agreed for Liberty [2]. As the policy [3] does not explicitly state that the submit

[openstack-dev] [Nova] Deadline for mid-cycle meetup signup

Hi, I just wanted to let people know that we're setting a deadline of 7 July for mid-cycle meetup signups. So, if you're intending to sign up but haven't already I'd do it real soon now. You can sign up at: https://www.eventbrite.com.au/e/openstack-nova-liberty-mid-cycle-developer-meetup-ti

Re: [openstack-dev] Why doesn't Swift cache object data?

You're right. Caching object data is one way to really speed up reads to content that is stored in Swift and accessed frequently. Often time, deployers use existing tools like squid, varnish, or a CDN to do that. But that still leaves the question "why don't we cache the object data in Swift?".

[openstack-dev] App Catalog IRC meeting minutes - 6/25/2015

Thank you to those who joined in the conversation today, I thought it was pretty productive. Today we focused on two things - creating a Horizon plugin that would allow for browsing and consuming catalog contents, and expanding the catalog framework to accommodate more asset types[1]. In the shor

[openstack-dev] [Mistral][Murano] What's the latest/greatest on YAQL?

Folks, it’s been some time,what’s the news: * Is Murano moving YAQL 1.0 in this cycle? * What’s your recommendation for this cycle - stay on 0.2.6 or move on? * Any progress on documentation? Thanks, DZ> __ OpenStack D

[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/25/2015

Hi Everyone, Thanks for joining the service chaining project meeting on 6/25/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ OpenStack Development M

Re: [openstack-dev] Why doesn't Swift cache object data?

Thanks a lot for your answer. I guess that is an excellent answer on "why does swift explicitly disable object data caching at the page cache level". But my question is a bit different "Why doesn't swift use memcached to cache object data?" Not that it is a bit different than implementing it yours

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Sat, Jun 20, 2015 at 9:14 AM, Devananda van der Veen wrote: > Almost all of our discussions so far on this topic have left something out, > which Monty pointed out to me last week. I'm following up now because > E_TRAVEL... > > tldr; > What we're versioning here are API's, not packages. It's no

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi wrote: > Sorry for late response here, > > 2015-06-20 9:14 GMT+09:00 Devananda van der Veen : >> >> Long version... >> Every HTTP response from Ironic today includes three headers: min, max, and >> version. The service can present an older API vers

  1   2   >