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

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

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

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 > > wrote: > > > > On Feb

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

[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

[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,

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

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

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

[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

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

+1 From: Bertrand LALLAU > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Friday, February 5, 2016 at 12:26 AM To: "OpenStack

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

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 >>

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: > >

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".

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,

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

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

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.

[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

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

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

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,

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 >

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

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

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 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

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

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 > 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

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)" >

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

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

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

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 >

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

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

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. > >

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 >

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: > >

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] [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

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 > > > Reply-To: "OpenStack Development

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

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

[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

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:

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.

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 > 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

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

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

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

+1 On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley wrote: > +1 > > Doug > > > > On Feb 4, 2016, at 7:06 PM, Brandon Logan > wrote: > > > > +1 > > > >> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote: > >> +1 from me! > >>

Re: [openstack-dev] [kolla] Location of Heka Lua plugins

On Thu, Feb 4, 2016 at 5:13 PM, Jeff Peeler wrote: > On Thu, Feb 4, 2016 at 9:22 AM, Michał Jastrzębski wrote: >> TLDR; +1 to have lua in tree of kolla, not sure if we want to switch later >> >> So I'm not so sure about switching. If these git repos are in

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,

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, >>>

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".

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

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

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

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

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

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

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

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)"

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] [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

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] [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,

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"

[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

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

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,

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

[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:

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: > >> > >> > >>

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] [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

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 > wrote: I've been looking through the reviews on and where it's gotten to -

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 - >> >>

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

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 > wrote: I think this discussion is dancing around the edges

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

Re: [openstack-dev] [neutron][db]Why can't I see ports which belongs router's gateway?

Hi! How do you try to get details about it? I don't have any problems with that, see http://paste.openstack.org/show/486069/ On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang wrote: > hi, all. > Neutron will create a port when setting router gateway to a router. > This

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

Simon, >> Any plan to have a nicer experience in future Fuel releases? I haven't heard about any plans on improvements for that, but management team should know better whether it's on roadmap or not. Thanks, On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier wrote: >

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

Hi, I'm testing the ability to install Fuel plugins in a an environment that is already deployed. My starting environment is quite simple: 1 controller + 1 compute. After the initial deployment, I've installed the 4 LMA plugins: - LMA collector - Elasticsearch-Kibana [*] - InfluxDB-Grafana [*] -

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

Hi, thanks for your reply. In my db, data is right. But when I run cmd, data is empty. see: http://paste.openstack.org/show/486072/ Thanks Zhi Chang -- Original -- From: "Anna Kamyshnikova"; Date: Fri, Feb 5, 2016 06:29 PM To:

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

All, I like to announce that SUSE joins these efforts, we're going to provide rooms in Nuremberg/Germany and have developers from our side available to contribute to the Mitaka bug smash. The etherpad page [1] is updated, the etherpad page for the location [2] is under construction. Hope to

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

On 5 February 2016 at 04:12, Armando M. wrote: > > > On 4 February 2016 at 08:22, John Belamaric > wrote: > >> >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: >> > >> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar

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

Hi Simon, As far as I know it's expected behaviour (at least for the current release), and it's expected that user reruns deployment on required nodes using fuel cli, in order to install plugin on a live environment. It depends on specific role, but "update_required" field may help you, it can be

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

Thanks Evgeniy. On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L wrote: > Hi Simon, > > As far as I know it's expected behaviour (at least for the current > release), and it's expected that user reruns deployment on required nodes > using fuel cli, in order to install plugin on a

Re: [openstack-dev] [openstack][Magnum] ways to get CA certificate in make-cert.sh from Magnum

I'm not sure I understand the use case. Can you explain the use case you are trying to solve? Corey On Fri, Feb 5, 2016, 02:07 王华 wrote: > Hi Corey, > > The user is root on those nodes and can get any credentials on those > nodes. We can not avoid that, but by this

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

Hello, In a RHEL-7, getting this error: 2016-02-05 11:08:00.385 | Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. 2016-02-05 11:08:00.385 | Could not determine a suitable URL for the plugin 2016-02-05 11:08:00.403

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

This seems strange, do you use admin user to run the command? On Fri, Feb 5, 2016 at 1:57 PM, Zhi Chang wrote: > Hi, thanks for your reply. > > In my db, data is right. But when I run cmd, data is empty. see: > http://paste.openstack.org/show/486072/ > > Thanks > Zhi

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongsrouter's gateway?

hmm... yes. I miss admin role in my user. sorry ;-) -- Original -- From: "Jerzy Mikolajczak"; Date: Fri, Feb 5, 2016 07:59 PM To: "openstack-dev"; Subject: Re: [openstack-dev] [neutron][db]Why

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

Thanks Matt’s, I was able to get system to vanilla state again …. And also isolated initial problem, my first puppet deployment failed on following error: Debug: Executing '/usr/bin/openstack image list --quiet --format csv --long' Debug: Executing '/usr/bin/openstack image create --format shell

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

Missing admin role on Your user maybe? http://paste.openstack.org/show/486081/ Jerzy On 05.02.2016 11:57, Zhi Chang wrote: Hi, thanks for your reply. In my db, data is right. But when I run cmd, data is empty. see: http://paste.openstack.org/show/486072/ Thanks Zhi Chang --

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

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, production-grade open

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

I'm not sure tbh, we don't have to deal with a proxy, but why not just comment this part out for now? Please file a bug on this against puppet-glance if there is a config option we could add. On Feb 5, 2016 4:59 AM, "Ptacek, MichalX" wrote: > Thanks Matt’s, I was able

[openstack-dev] [Ironic] A strange transition in Ironic FSM

Hi. We have a followed transition in common/states.py: # An errored instance can be rebuilt # ironic/conductor/manager.py:do_node_deploy() machine.add_transition(ERROR, DEPLOYING, 'rebuild') At first glance it looks correct. But ERROR state is used only for error after deleting, see

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   2   >