Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

There are a lot of good questions and points being raised in this thread but I think it might be appropriate to say we've opened a can of worms. As mentioned by Doug there is a rather specific case[1] being considered that I think provides some important context and framing. It is clear that there

Re: [openstack-dev] [stable] Kilo gate doesn't like testtools 2.0.0

On February 6, 2016 4:29:34 PM GMT+11:00, Matt Riedemann wrote: > > >On 2/4/2016 11:23 PM, Tony Breeds wrote: >> Hi All, >> Just a quick heads up that the kilo gate (and therefore anything >that >> relies on kilo)[1] is a little busted. >> >> This was originally noticed in 1541879[2] and a

Re: [openstack-dev] [stable] Kilo gate doesn't like testtools 2.0.0

On 2/4/2016 11:23 PM, Tony Breeds wrote: Hi All, Just a quick heads up that the kilo gate (and therefore anything that relies on kilo)[1] is a little busted. This was originally noticed in 1541879[2] and a quick cap for g-r was proposed, however if my analysis is correct this can't land b

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

Tim, swift3 calls keystone for authentication (in similar way as ec2api) Andrey. On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell wrote: > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ? > > Tim > > > > On 05/02/16 20:57, "Andrey Pavlov" wrote: > >>As I know 'swift3' project implem

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/06/2016 10:41 AM, Jay Pipes wrote: > I'm no fan of open core. Never have been. So it irks me that Poppy can't > work with any non-proprietary backend. But, as others have said, that > isn't the Poppy team's fault. I don't agree. Poppy could leverage a multi-datacneter OpenStack deployment, a

[openstack-dev] What's Up, Doc? 6 Feb 2016

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, A busy week here in docs, with today marking only two months left until Mitaka goes out. I've been working on the DocImpact script, the core team review, and a whole lot of general chasing things up and tidying around the place. I als

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 06:57 PM, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". W

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 06:57 PM, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". W

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 02:16 PM, Sean Dague wrote: On 02/05/2016 01:17 PM, Doug Hellmann wrote: So, is Poppy "open core"? Whether or not it is, I'm not sure how it is part of a Ubiquitous Open Source Cloud Platform. Because it only enables the use of commerical services. It's fine that it's open sourc

[openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC

Hi neutrinos, A kind reminder for next week's meeting. More on the agenda [1]. Cheers, Armando [1] https://wiki.openstack.org/wiki/Network/Meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] Neutron: (br-int) connection from VM

The instance is directly connected to br-int. Thanks, Kevin From: Atif Saeed [i_at...@hotmail.com] Sent: Friday, February 05, 2016 4:50 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Neutron: (br-int) connection from VM Hi all! I am running my

[openstack-dev] Neutron: (br-int) connection from VM

Hi all! I am running my own testbed and want to ask a simple question. Can I bypass the hypervisor just to access the br-int directly from Instance. Thanks, A. __ OpenStack Develop

[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 2/4/2016

This week we had a really great meeting, including some folks from the Horizon team stepping in to help make the Horizon plugin better. We discussed some of the work relating to the UI piece, and adding tests to app-catalog-ui to ensure future changes are tested properly against Horizon. We also

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 02:41 PM, Doug Hellmann wrote: > Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600: >> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann >> wrote: >> >>> So, is Poppy "open core"? >>> >> >> It doesn't follow the 'spirit' of open core, but it does have some of the >> chara

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 12:14 PM, Ryan Brown wrote: > On 02/05/2016 05:57 AM, Thierry Carrez wrote: >> Hi everyone, >> >> Even before OpenStack had a name, our "Four Opens" principles were >> created to define how we would operate as a community. The first open, >> "Open Source", added the following precisio

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 2016-02-05 13:17:40 -0500 (-0500), Doug Hellmann wrote: [...] > My understanding of the "no open core" requirement is about the > intent of the contributor. We don't want separate community and > "enterprise" editions of components (services or drivers). The > Poppy situation doesn't seem to b

Re: [openstack-dev] [Openstack] [Installation] RHEL-7 devstack installation failed in bootstrap_keystone

I'm assuming this isn't being run on a new machine. 1) Ensure you don't have a clouds.yaml file in ~/.config/openstack 2) Check you don't have any OS_ environment variables when running ./stack.sh 3) Running ./clean.sh should clean up those two above issues and a bunch more potential causes the

Re: [openstack-dev] [all] the trouble with names

Sorry. SWIFT beat you to it. ;) Kevin From: gordon chung [g...@live.ca] Sent: Friday, February 05, 2016 1:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] the trouble with names On 05/02/2016 1:22 PM, Ryan Brown wrote: > For e

Re: [openstack-dev] [Installation] RHEL-7 devstack installation failed in bootstrap_keystone

It's better to send this kind of topic to: openst...@lists.openstack.org not *dev* from the next. Rgds, Shinobu - Original Message - From: "Pradip Mukhopadhyay" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Friday, February 5, 2016 8:17:03 PM Subject: [ope

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 5 February 2016 at 05:41, Gal Sagie wrote: > Armando, > > I think that contributing and innovating in Dragonflow to implement > Neutron in an open way and serve as an alternative and as an example > for distributed networking patterns IS driving Neutron forward, i am very > sad that you fail

Re: [openstack-dev] [all] the trouble with names

On Fri, 5 Feb 2016, Sean Dague wrote: I feel like this is gone a bit "dead horse" of track from the question at hand. Which brings us in danger of ending up on solution #3 (do nothing, we're all burned out from having to discuss things anyway, lets farm goats). We should revisit this ^ issue a

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

On 2016-02-05 03:42:21 + (+), Wang, Shane wrote: > After discussing with TC members and other community guys, we > thought March 2-4 might not be a good timing for bug smash. So we > decided to change the dates to be March 7 - 9 (Monday - Wednesday) > in R4. Please join our efforts to fix b

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

On Fri, Feb 5, 2016 at 1:03 PM, Dolph Mathews wrote: > > On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov > wrote: > >> swift3(s3) works like ec2-api. >> >> 1. swift3/ec2-api recieves AWS request >> 2. it parses signature and access_key (and other headers) >> 3. it sends these values (and token th

Re: [openstack-dev] [api] microversion spec

On 02/05/2016 03:00 PM, michael mccune wrote: > On 02/03/2016 10:23 AM, Morgan Fainberg wrote: >> >> >> On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague > > wrote: >> >> I've been looking through the reviews on and where it's gotten to - >> >> https://review.openstack.org/#

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 5 February 2016 at 17:58, Neil Jerram wrote: > On 05/02/16 16:31, Pavel Bondar wrote: > > On 05.02.2016 12:28, Salvatore Orlando wrote: > >> > >> > >> On 5 February 2016 at 04:12, Armando M. >> > wrote: > >> > >> > >> > >> On 4 February 2016 at 08:22, John Belama

Re: [openstack-dev] [all] the trouble with names

On 05/02/2016 1:22 PM, Ryan Brown wrote: > For example, I think "containers" will be one of those words that > everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for > projects to say "hm, someone else wants this" would be nice. too late, magnum[1] beat you to it. i'm not sure what

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ? Tim On 05/02/16 20:57, "Andrey Pavlov" wrote: >As I know 'swift3' project implements S3 for OpenStack over swift. Or >your mention something other? >(but it doesn't support some features - signature v4 for instance) > >Andrey.

[openstack-dev] [cinder] v2 image upload from url

We've been using the upload image from http url for a long time and when we upgraded to liberty we noticed it broke because the client's defaulting to v2 now. How do you do image upload via http with v2? Is there a different command/method? Thanks, Kevin

[openstack-dev] RFC 2616 was *so* 2010

... really more like 1999, but when OpenStack started back in '10 - RFC 2616 was the boss. Since then (circa '14) we've got 7230 et. al. - a helpful attempt to disambiguate things! Hooray progress! But when someone recently opened this bug I got confused: https://bugs.launchpad.net/swift/+bug/1

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 14:41 Feb 05, Doug Hellmann wrote: > Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600: > > On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann > > wrote: > > > > > So, is Poppy "open core"? > > > > > > > It doesn't follow the 'spirit' of open core, but it does have some of the > >

Re: [openstack-dev] [all] the trouble with names

On 05/02/16 20:09, "Jay Pipes" wrote: >On 02/05/2016 08:38 AM, Dean Troyer wrote: >> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote: >> >> I think this discussion is dancing around the edges of a referendum on >> the "duplication" aspect of the big t

Re: [openstack-dev] [api] microversion spec

On 02/03/2016 10:23 AM, Morgan Fainberg wrote: On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague mailto:s...@dague.net>> wrote: I've been looking through the reviews on and where it's gotten to - https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst A coup

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

As I know 'swift3' project implements S3 for OpenStack over swift. Or your mention something other? (but it doesn't support some features - signature v4 for instance) Andrey. On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell wrote: > > > > > > On 05/02/16 20:15, "Andrey Pavlov" wrote: > >>Can it be imp

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

On 05/02/16 20:15, "Andrey Pavlov" wrote: >Can it be implemented as keystone plugin? >Is it possible to 'get' AUTH_TOKEN outside of keystone? >Will this code use keystone DB or it should create own? > >So we will need one 'auth' module for swift3/ec2-api. >Sounds good but we need to understa

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Sean Dague's message of 2016-02-05 14:16:12 -0500: > On 02/05/2016 01:17 PM, Doug Hellmann wrote: > > Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500: > >> On 02/05/2016 05:57 AM, Thierry Carrez wrote: > >>> Hi everyone, > >>> > >>> Even before OpenStack had a name, ou

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600: > On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann > wrote: > > > So, is Poppy "open core"? > > > > It doesn't follow the 'spirit' of open core, but it does have some of the > characteristics, in that the open code is not all that u

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 12:27 Feb 05, Dean Troyer wrote: > On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann > wrote: > > > So, is Poppy "open core"? > > > > It doesn't follow the 'spirit' of open core, but it does have some of the > characteristics, in that the open code is not all that useful, or maybe > even testabl

Re: [openstack-dev] [all] the trouble with names

#2 On 02/05/2016 02:24 PM, Sean Dague wrote: On 02/05/2016 02:09 PM, Jay Pipes wrote: On 02/05/2016 08:38 AM, Dean Troyer wrote: On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent mailto:cdent...@anticdent.org>> wrote: I think this discussion is dancing around the edges of a referendum on t

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 02:09 PM, Jay Pipes wrote: > On 02/05/2016 08:38 AM, Dean Troyer wrote: >> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote: >> >> I think this discussion is dancing around the edges of a >> referendum on >> the "duplication" aspect of the bi

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 01:17 PM, Doug Hellmann wrote: > Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500: >> On 02/05/2016 05:57 AM, Thierry Carrez wrote: >>> Hi everyone, >>> >>> Even before OpenStack had a name, our "Four Opens" principles were >>> created to define how we would operate as

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

Can it be implemented as keystone plugin? Is it possible to 'get' AUTH_TOKEN outside of keystone? Will this code use keystone DB or it should create own? So we will need one 'auth' module for swift3/ec2-api. Sounds good but we need to understand some details before implementation. On Fri, Feb 5,

Re: [openstack-dev] [Magnum] Bug 1541105 options

- Original Message - > From: "Steven Dake (stdake)" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Steve, > > Comments inline > > On 2/3/16, 3:08 PM, "Steve Gordon" wrote: > > >- Original Message - > >> From: "Hongbin Lu" > >> To: "OpenStack Deve

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 08:38 AM, Dean Troyer wrote: On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent mailto:cdent...@anticdent.org>> wrote: I think this discussion is dancing around the edges of a referendum on the "duplication" aspect of the big tent. It is also dancing around the separation of 'API'

Re: [openstack-dev] [all] the trouble with names

I have the benefit here of being a beginner to openstack and having experienced AWS as a user. I think that the current "nova", "cinder" etc naming was confusing to me at first, but that it's a needed stumbling block for devs and deployers/ops to be precise. However, for end-users, probably mo

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

What have we done? On Fri, 2016-02-05 at 10:30 -0800, Stephen Balukoff wrote: > Thanks guys! I appreciate the support and vote of confidence! > > On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson > wrote: > That is quorum from the Octavia cores. > > Congratulations Stephen

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov wrote: > swift3(s3) works like ec2-api. > > 1. swift3/ec2-api recieves AWS request > 2. it parses signature and access_key (and other headers) > 3. it sends these values (and token that calculated from request) to > keystone > 4. keystone gets secret

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 14:23 Feb 05, Tim Bell wrote: > I think defining 'fully-functional' is easy enough until you allow 'vendor > extensions' into the API. But there is still an amount of objective criteria > to look at to make it something that a group of, say 13 judges, might arrive > at a reasonable answer. I t

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 07:57 Feb 05, Dean Troyer wrote: > On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez > wrote: > > > My personal take on that is that we can draw a line in the sand for what > > is acceptable as an official project in the upstream OpenStack open source > > effort. It should have a fully-functional

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

swift3(s3) works like ec2-api. 1. swift3/ec2-api recieves AWS request 2. it parses signature and access_key (and other headers) 3. it sends these values (and token that calculated from request) to keystone 4. keystone gets secret_key from DB, then calculates signature by recieved access_key and to

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 02/05/2016 11:38 AM, Sam Yaple wrote: On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On 02/05/2016 09:58 AM, Sam Yaple wrote: Since Nova has no backup mechanism this is clearly a gap and that was the issue Ekko wants to solve. N

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 01:17 PM, Doug Hellmann wrote: Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500: On 02/05/2016 05:57 AM, Thierry Carrez wrote: Hi everyone, Even before OpenStack had a name, our "Four Opens" principles were created to define how we would operate as a community. The

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

On 01/02/16 14:11, Kevin Benton wrote: > Hi all, > > I've been working on an implementation of the multiple L3 backends > RFE[1] using the flavor framework and I've run into some snags with the > use-cases.[2] Is there any good documentation for flavors yet? I recall looking unsuccessfully, a fe

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

Thanks guys! I appreciate the support and vote of confidence! On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson wrote: > That is quorum from the Octavia cores. > > Congratulations Stephen! > > Michael > > On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German > wrote: > > +1 > > > > From: Bertrand LA

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann wrote: > So, is Poppy "open core"? > It doesn't follow the 'spirit' of open core, but it does have some of the characteristics, in that the open code is not all that useful, or maybe even testable, without the commercial component(s) (at this time).

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 01:00 PM, Sean Dague wrote: On 02/05/2016 12:16 PM, Ryan Brown wrote: On 02/05/2016 09:08 AM, michael mccune wrote: On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: [snipped lots] This isn't a perfect solution, but maybe instead of projects.ym

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500: > On 02/05/2016 05:57 AM, Thierry Carrez wrote: > > Hi everyone, > > > > Even before OpenStack had a name, our "Four Opens" principles were > > created to define how we would operate as a community. The first open, > > "Open Source",

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 12:16 PM, Ryan Brown wrote: > On 02/05/2016 09:08 AM, michael mccune wrote: >> On 02/04/2016 12:57 PM, Hayes, Graham wrote: >>> On 04/02/2016 15:40, Ryan Brown wrote: > [snipped lots] This isn't a perfect solution, but maybe instead of projects.yml there could be a `registry

Re: [openstack-dev] [Horizon] Recent integration tests failures

Okay, with https://review.openstack.org/#/c/276123/ finally merged tests should pass more predictably now. Please, recheck and reverify your patches now. I hope that recheck/reverify alone is enough to consume merged test fix, if I'm wrong please correct me. On Thu, Feb 4, 2016 at 5:46 PM Timur Su

Re: [openstack-dev] [keystone][ec2-api][heat] Moving EC2 Auth and S3Token to Externally supported

Might double check with the heat folks. I think they use some of it with wait conditions still? Thanks, Kevin From: Tim Bell [tim.b...@cern.ch] Sent: Friday, February 05, 2016 9:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [o

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

> > Is it certain that there is no need for the functions with the new EC2-API > functions ? > > The S3 functions are somewhat separated from the EC2 API. How does SWIFT > implement the S3 compatibility layer ? > > Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make > sur

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

... On "production-grade": I'd be (strongly) in favor of defining a target deployment configuration and size which we find representative of the minimum bar for "production-grade." Anything less concrete and specific becomes more nuisance than help. I'd hope that specs might look like the foll

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

On Feb 5, 2016 09:43, "Tim Bell" wrote: > > > Is it certain that there is no need for the functions with the new EC2-API functions ? > > The S3 functions are somewhat separated from the EC2 API. How does SWIFT implement the S3 compatibility layer ? > > Getting a ‘to be deprecated’ log entry into M

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

Is it certain that there is no need for the functions with the new EC2-API functions ? The S3 functions are somewhat separated from the EC2 API. How does SWIFT implement the S3 compatibility layer ? Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make sure we’re not usin

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

That is quorum from the Octavia cores. Congratulations Stephen! Michael On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German wrote: > +1 > > From: Bertrand LALLAU > mailto:bertrand.lal...@gmail.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > mailto:openstack-d

Re: [openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

I don't think you need to bump the major version per OpenStack release. If the functionalities is backward-compatible, from the context of the semantic versioning you don't need to bump the major version, i.e. 1.x.y to 2.x.y. According to your description, Mitaka version can be 1.1.0. I am not sure

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 09:08 AM, michael mccune wrote: On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: [snipped lots] This isn't a perfect solution, but maybe instead of projects.yml there could be a `registry.yml` project that would (of course) have all the project.

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

I think that will become a clear definition but not a strict one :) In Huawei, each release of product will be evaluated by availability, security, usability, maintainability and something else. Those design ideas looks difficult but could drive projects stronger. On Sat, Feb 6, 2016 at 12:49 AM,

[openstack-dev] [fuel] Fuel 8.0 Hard Code Freeze

Fuel 8.0 (based on Liberty) is now in Hard Code Freeze [0]. [0] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze While we're in HCF, only Critical bugfixes may be merged into stable/8.0 branch. Please be conscientious about bug severity and do not upgrade bugs just to get them in, use our bu

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 05:57 AM, Thierry Carrez wrote: Hi everyone, Even before OpenStack had a name, our "Four Opens" principles were created to define how we would operate as a community. The first open, "Open Source", added the following precision: "We do not produce 'open core' software". What does t

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On "production-grade": > On Feb 5, 2016, at 6:23 AM, Tim Bell wrote: > > From: Dean Troyer > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Friday 5 February 2016 at 14:57 > To: "OpenStack Development Mailing List (not for usage questions)" > Subject: Re: [opens

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

+1 From: Bertrand LALLAU mailto:bertrand.lal...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, February 5, 2016 at 12:26 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:op

Re: [openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric wrote: > Hi all, > > Back in November, there was a discussion [1] on the mailing list around > release:independent projects, which was wrapped up by Thierry in [2]. > However, I have a couple lingering questions that have come up. > > In networking

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 05/02/16 16:31, Pavel Bondar wrote: > On 05.02.2016 12:28, Salvatore Orlando wrote: >> >> >> On 5 February 2016 at 04:12, Armando M. > > wrote: >> >> >> >> On 4 February 2016 at 08:22, John Belamaric >> <jbelama...@infoblox.com> w

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 02/05/2016 10:36 AM, Neil Jerram wrote: > As some others have said, I see the current discussion as being about > the chain of accountability, from a stadium project, through Neutron, up > to the OpenStack TC and board. IIUC, Armando and other cores feel that > there is a gap there - because th

[openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

Hi all, Back in November, there was a discussion [1] on the mailing list around release:independent projects, which was wrapped up by Thierry in [2]. However, I have a couple lingering questions that have come up. In networking-infoblox, we have a 1.0.0 version of our driver that we released a

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 05:57 AM, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". W

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Dean Troyer wrote: On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez mailto:thie...@openstack.org>> wrote: My personal take on that is that we can draw a line in the sand for what is acceptable as an official project in the upstream OpenStack open source effort. It should have a fully-

Re: [openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

On 3 February 2016 at 18:49, Armando M. wrote: > > > On 3 February 2016 at 04:28, Sean Dague wrote: > >> On 02/02/2016 10:03 PM, Matthew Treinish wrote: >> > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote: >> >> Folks, >> >> >> >> We have some IPv6 related bugs [1,2,3] that have been

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes wrote: > On 02/05/2016 09:58 AM, Sam Yaple wrote: > >> Since Nova has no backup mechanism this is clearly a gap and that was the >> issue >> Ekko wants to solve. >> > > Nova has had backups for a long time: > > http://developer.openstack.org/api-ref-compu

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 05.02.2016 12:28, Salvatore Orlando wrote: > > > On 5 February 2016 at 04:12, Armando M. > wrote: > > > > On 4 February 2016 at 08:22, John Belamaric > mailto:jbelama...@infoblox.com>> wrote: > > > > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > m

Re: [openstack-dev] [Magnum] gate issues

Corey, Thanks for investigating the gate issues and summarizing it. It looks there are multiple problems to solve, and tickets were created for each one. 1. https://bugs.launchpad.net/magnum/+bug/1542384 2. https://bugs.launchpad.net/magnum/+bug/1541964 3. https://bugs.launc

Re: [openstack-dev] [grenade][keystone] Keystone multinode grenade

On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague wrote: > On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote: > > > > > >> -Original Message- > >> From: Sean Dague [mailto:s...@dague.net] > >> > >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote: > >>> > >>> Keystone is just one service, but we want

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

+1 this is a totally logical move, especially given that the current implementation back to the /v3/credentials API anyway. On Friday, February 5, 2016, Morgan Fainberg wrote: > Looking over the state [and relatively untested nature] of the Keystone > EC2 API and S3Token APIs, I want to propose

Re: [openstack-dev] [Docs] Changes for OpenStack API guides

On Fri, Feb 5, 2016 at 9:50 AM, Smigiel, Dariusz wrote: > Hello Anne, > > I’m working on “moving to Keystone v3 API” spec for Neutron [1]. > > HenryG mentioned, that in next release or so, there will be change how to > describe changes connected to API [2]. > > In spec I’m mentioning, that some c

Re: [openstack-dev] [Docs] Changes for OpenStack API guides

Hi -- Here's some specs for you to peruse to get a lot of background, and the blog post and -dev mailing list post that went out. You can also ask me directly, annegentle on IRC or through email. It's a lot and only two-three people are working on this effort centrally with the rest of the work acr

Re: [openstack-dev] [all] the trouble with names

On 05/02/16 13:50, Dean Troyer wrote: > On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram > wrote: > > On 04/02/16 11:40, Sean Dague wrote: > > What options do we have? > > > > 1) Use the names we already have: nova, glance, swift, etc. > > > >

[openstack-dev] [Docs] Changes for OpenStack API guides

Hello Anne, I'm working on "moving to Keystone v3 API" spec for Neutron [1]. HenryG mentioned, that in next release or so, there will be change how to describe changes connected to API [2]. In spec I'm mentioning, that some changes are required to Networking API v2 [3], so would like to know, how

[openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

Looking over the state [and relatively untested nature] of the Keystone EC2 API and S3Token APIs, I want to propose deprecating these mechanisms of auth within Keystone at this time. These systems have been historically poorly tested and supported and have remained broken / incompatible for long p

[openstack-dev] [kolla] Make "central logging" optional

Hi Kolla devs The other day inc0 said that we would like "central logging" to be optional in Mitaka, and still use Rsyslog and keep the current behavior if "central logging" is disabled. I would like to propose an alternative, where we do remove Rsyslog as planned in the spec. I like the idea of

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 05/02/16 10:59, Thierry Carrez wrote: > Hi everyone, > > Even before OpenStack had a name, our "Four Opens" principles were > created to define how we would operate as a community. The first open, > "Open Source", added the following precision: "We do not produce 'open > core' software". What

Re: [openstack-dev] [Neutron] Evolving the stadium concept

On 04/02/16 22:39, Assaf Muller wrote: > On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins wrote: >> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote: >> >>> Currently I don't understand why >>> being a part of the stadium is good or bad for a networking project, >>> or why does it matter.

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 02/05/2016 09:58 AM, Sam Yaple wrote: Since Nova has no backup mechanism this is clearly a gap and that was the issue Ekko wants to solve. Nova has had backups for a long time: http://developer.openstack.org/api-ref-compute-v2.1.html#createBackup Best, -jay ___

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On Thu, Feb 4, 2016 at 2:23 PM, gordon chung wrote: > > > On 03/02/2016 10:38 AM, Sam Yaple wrote: > > On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley < > fu...@yuggoth.org> wrote: > >> On 2016-02-03 14:32:36 + (+), Sam Yaple wrote: >> [...] >> > Luckily, digging into it it appears cinder

[openstack-dev] [nova] How to enforce that no new legacy notification is added

Hi, Background: Versioned notification infra [1] is merged and on the midcycle we agreed that we don't allow new legacy notification [2]. I promised to create some automated way to detect if a new legacy notification is proposed in a review. I implemented [3] a monkey patch in the test that che

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Hi Simon. For running selected tasks on already deployed nodes you can use the following command of CLI (fuel command-line utility): fuel node --node node_id1[,node_idN] --tasks task1[,taskN] where node_id - is the unique identifier of node, where specified tasks shall be run. Any plan t

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

From: Dean Troyer Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Friday 5 February 2016 at 14:57 To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016 On Fri, Feb 5, 2016 at 4:57 AM,

Re: [openstack-dev] [all] the trouble with names

On 02/05/2016 07:56 AM, Chris Dent wrote: On Thu, 4 Feb 2016, Sean Dague wrote: 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. This is the only option presented thus far which meets the needs of end users and also

Re: [openstack-dev] [nova] Authorization by user_id does not work in V2.1 API

On 02/05/2016 02:46 AM, Takashi Natsume wrote: > Hi Nova developers, > > I have already submitted a bug report[1], > authorization by user_id when deleting a VM instance does not work in Nova > V2.1 API > although it works in Nova V2.0 API. > > Has this change been done intentionally? > > [1] A

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

On Fri, Feb 5, 2016 at 1:54 PM, Igor Kalnitsky wrote: > Simon, > > > Nope, it doesn't work for me since it should run for *all* the nodes, > > irrespective of their roles. AFAIK update_required doesn't support '*'. > > If your plugin provides a new node role as well as additional tasks > for othe

Re: [openstack-dev] [all] the trouble with names

On 02/04/2016 12:57 PM, Hayes, Graham wrote: On 04/02/2016 15:40, Ryan Brown wrote: On 02/04/2016 09:32 AM, michael mccune wrote: On 02/04/2016 08:33 AM, Thierry Carrez wrote: Hayes, Graham wrote: On 04/02/2016 13:24, Doug Hellmann wrote: Excerpts from Hayes, Graham's message of 2016-02-04 1

  1   2   >