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 >> /openstack/ namespace, then sure, oth

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! > >> > >> From: Michael Johnson >

Re: [openstack-dev] [neutron][neutron-*] Notice! pylint breakage

Thanks for all! However I'm developing on stable/liberty and it failed with running "tox -e pep8" because of this issue. And I found it is pylint==1.4.5 on master branch. Could we cherry-pick this test-requirements update back to stable/liberty? On Wed, Dec 2, 2015 at 12:04 AM, Paul Michali wrot

Re: [openstack-dev] [docs][all] Software design in openstack

Joshua Harlow wrote: Clint Byrum wrote: Note that many of us have lamented the lack of an agreed upon "architecture" in OpenStack. While Josh is right that Oslo often facilitates many of our agreed upon technology choices, it doesn't really shape the overall picture. We also have recently starti

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 se

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 >> wrote: >> >> I am trying to bring more attention to [1] to make final d

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

> -Original Message- > From: Sean Dague [mailto:[email protected]] > > On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote: > > > > Keystone is just one service, but we want to run a test, in which it > > is setup in HA – two services running at different versions, using the same > DB. > > Let

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

hi, all. Neutron will create a port when setting router gateway to a router. This port's device_owner is "network:router_gateway". And, I can see this port in db. But, why cmd says "Unable to find port with name xxx" when I want to get the detail info about this port? Does there

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

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] [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 port's device_owner is "netw

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

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

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 this mean in 2016 ? Back in 2010 when OpenS

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

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: > Thanks Evgeniy. > > On Fri, F

[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] [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 way we can disallow those use

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

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

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 can't I see ports whichbelongsrouter's gateway? Missing admi

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

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 other node roles, you may try to workaround that by using reexecute_o

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

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 some of our stated goals about creating in

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

On Thu, 4 Feb 2016, gordon chung wrote: my concern with #2 is, we will just end up going to thesaurus.com and searching for alternate words that mean the same general thing and this will be equally confusing. with the big tent, we essentially agreed that duplication is possible, so no matter how

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

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. > > Upside, collision problem is solved. Downside, you need a secret decoder > ring to figure out what project does what. This is my preference. Yes, it means that there

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

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 around the separation of 'API' from 'implementation'. There is a long-standing disagreement on whether OpenSt

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

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. > > > > Upside, collision problem is solved. Downside, you need a secret decoder > > ring to figure out what p

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

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 to see this and try to pick to my review/patches count. Be

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

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 to get system to vanilla s

[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 http://docs

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

On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote: > > >> -Original Message- >> From: Sean Dague [mailto:[email protected]] >> >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote: >>> >>> Keystone is just one service, but we want to run a test, in which it >>> is setup in HA – two services runnin

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

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

[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] 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 < > [email protected]> wrote: > >> On 2016-02-03 14:32:36 + (+), Sam Yaple wrote: >> [...] >> > Luckily, digging into it it appears cinder

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

[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

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

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

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] [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] [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] [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:[email protected]] > >> > >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote: > >>> > >>> Keystone is just one service, but we want

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] [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:[email protected]>> wrote: > > > > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > m

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] [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] [all] [tc] "No Open Core" in 2016

Dean Troyer wrote: On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez mailto:[email protected]>> 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] [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

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

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 >> <[email protected]> w

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] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

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

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

[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

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] [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] [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] [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:[email protected]>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > mailto:openstack-d

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

> > 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] [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 [[email protected]] Sent: Friday, February 05, 2016 9:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [o

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] [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] [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 projects.ym

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] [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] [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] [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] 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:[email protected]>> 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] [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] [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] [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] [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] [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] [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] [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:[email protected]>> 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] [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] [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] [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] 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] 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:[email protected]>> wrote: I think this discussion is dancing around the edges of a referendum on t

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

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

  1   2   >