Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Duan Li, We welcome to that contribution if you had. Just make sure that spec can be flexible handle 2 ~ N flavor cases. That could handle future requirements for N flavors, as in the ML, I found some ops had such requirements. Thanks Best Wishes, ---

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

+1, Looking forward for reviewing this cool feature. On 2016年04月21日 14:57, Kai Qiang Wu wrote: Hi Duan Li, We welcome to that contribution if you had. Just make sure that spec can be flexible handle 2 ~ N flavor cases. That could handle future requirements for N flavors, as in the ML, I foun

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

At Wed, 20 Apr 2016 14:12:07 +0200, Miguel Angel Ajo Pelayo wrote: > > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three things to look at: (sorry for the TL) > > 1) The generalization of traffic filters / traffic classif

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

AFAIK, there is proposal about adding a 'priority' option in the existing flow classifier rule. This can ensure the rule ordering. On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro wrote: > At Wed, 20 Apr 2016 14:12:07 +0200, > Miguel Angel Ajo Pelayo wrote: > > > > I think this is an interes

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

On Thu, Apr 21, 2016 at 9:54 AM, Vikram Choudhary wrote: > AFAIK, there is proposal about adding a 'priority' option in the existing > flow classifier rule. This can ensure the rule ordering. > > It's more complicated than that, there you're only considering Flow Classifiers, while we need to mak

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Hongbin, Thank you for your comments. I had thought about supporting multiple nova flavors, and as you pointed out, it introduces an additional challenge of expressing a map containing multiple flavors/resource groups with the corresponding node count. If we just support 2 nova flavor, we ca

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

Hello Andreas, Thanks for comment, I didn't know about other-requirements. There is a tool 'bindep' [0] that allows to parse other-requirements.txt It is possible to mix python/system dependencies in single other-requirements.txt. But mixing packages from different distros are not supported. Also

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

On 2016-04-21 10:20, Vasyl Saienko wrote: > Hello Andreas, > > Thanks for comment, I didn't know about other-requirements. > > There is a tool 'bindep' [0] that allows to parse other-requirements.txt > It is possible to mix python/system dependencies in single > other-requirements.txt. But mixing

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

Hi Vikram, Thanks for the response. I’m happy to provide enhancements instead of building the API from scratch, the semantics may change considerably though, resulting in what’s essentially a new API, but let’s see. I invite you to read the spec [1] thoroughly. Let’s continue there so we can be

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

It seems that all the drivers' dependencies currently present in ironic tree can be installed from binary packages, so maybe we could make use of bindep. But what if some driver will require addition of some custom repository, it will have to go directly to plugin.sh? Also, after e.g. gate switch t

[openstack-dev] [Performance] Austin Performance Team working group session - please comment

Folks, we're going to have Performance Working Group session during the upcoming summit - here is the event description . Our team was kicked off during Mitaka Summit, so that was our first cycle :) Please attend the session

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Joshua Harlow wrote: Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable c

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Hi Andreas, so if some projects, such as ceilometer, need babel even if they don't directly depend on it, just because they are setup in infra for translations? can you explain a bit more to me, or just provide some links, or keywords for search ? Thanks ZhiQiang On Tue, Apr 19, 2016 at 2:34 PM

Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?

+1 more example and documentation are welcomed On Tue, Apr 19, 2016 at 3:10 AM, John Griffith wrote: > > > On Thu, Apr 14, 2016 at 1:31 AM, Markus Zoeller > wrote: > >> Sometimes (especially when I try to reproduce bugs) I have the need >> to set up a local environment with devstack. Everytime

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

On 2016-04-21 13:22, ZhiQiang Fan wrote: > Hi Andreas, > > so if some projects, such as ceilometer, need babel even if they don't > directly depend on it, just because they are setup in infra for > translations? > > can you explain a bit more to me, or just provide some links, or > keywords for s

[openstack-dev] [Fuel][NFV] Features status

Hello, QA team are content to announce the stable status of next NFV features in Fuel Mitaka release: - NUMA and CPU pinning - Hugepages - SR-IOV pinning DPDK was decided to be experimental in Community Release -- Best Regards, Ksenia Demina ___

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Thanks for the confirm. On Thu, Apr 21, 2016 at 7:44 PM, Andreas Jaeger wrote: > On 2016-04-21 13:22, ZhiQiang Fan wrote: > > Hi Andreas, > > > > so if some projects, such as ceilometer, need babel even if they don't > > directly depend on it, just because they are setup in infra for > > transla

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

- Original Message - > From: "Hongbin Lu" > To: "OpenStack Development Mailing List (not for usage questions)" > > > -Original Message- > > From: Keith Bray [mailto:[email protected]] > > Sent: April-20-16 6:13 PM > > To: OpenStack Development Mailing List (not for usage q

Re: [openstack-dev] [nova] api-ref content verification phase doc push

On 4/20/2016 6:25 PM, Sean Dague wrote: This morning we finally cleaned up the last warnings in api-ref, so now we can enforce errors on warnings. Woot! That went much faster than I anticipated, and puts us at a really good place for summit. The next phase is the content verification phase. This

Re: [openstack-dev] [nova] api-ref content verification phase doc push

On 04/21/2016 09:54 AM, Matt Riedemann wrote: > How about an etherpad where they are listed and people can assign > themselves per file? I guess that gets messy when you have some changes > doing step 1 on multiple files... The giant etherpads become a mess to keep track of source of truth, and ge

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

Hi Igor, Thanks for understanding. Let's continue the discussion over the submitted spec. Thanks Vikram On Thu, Apr 21, 2016 at 3:04 PM, Duarte Cardoso, Igor < [email protected]> wrote: > Hi Vikram, > > > > Thanks for the response. I’m happy to provide enhancements instead of > buil

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On 04/18/2016 12:34 PM, Martin Millnert wrote: (** ECP is a new feature, not supported by all IdP's, that at (second) best requires reconfiguration of core authentication services at each customer, and at worst requires customers to change IdP software completely. This is a varying degree of show

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> On Apr 20, 2016, at 2:49 PM, Joshua Harlow wrote: > > Thierry Carrez wrote: >> Adrian Otto wrote: >>> This pursuit is a trap. Magnum should focus on making native container >>> APIs available. We should not wrap APIs with leaky abstractions. The >>> lowest common denominator of all COEs is an

[openstack-dev] JavaScript RoadMap for OpenStack Newton

This post contains the current working draft of the JavaScript roadmap which myself and Beth Elwell will be working on in Newton. It’s a big list, and we need help - Overall themes for this cycle are Consistency, Interoperability, and engaging with the JavaScript community at large. Our end goal is

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

FWIW, we were using retrying in oslo.concurrency at one point: https://review.openstack.org/#/c/130872 It looks like that got removed somewhere in the move to fasteners though. On 04/20/2016 04:29 PM, Doug Hellmann wrote: > Excerpts from Chris Dent's message of 2016-04-20 22:16:10 +0100: >> >> Wi

[openstack-dev] [tripleo] Launchpad cleanups for Newton

Hi all, So I've been attempting to beat our launchpad project into shape today, and have made a few changes with a view to making the tool more useful for tracking things during the Newton cycle: 1. New "TripleO Drivers" team I created https://launchpad.net/~tripleo-drivers which is a restricted

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Thu, Apr 21, 2016 at 10:22:46AM -0400, John Dennis wrote: > On 04/18/2016 12:34 PM, Martin Millnert wrote: > >(** ECP is a new feature, not supported by all IdP's, that at (second) > >best requires reconfiguration of core authentication services at each > >customer, and at worst requires custome

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On 4/20/16 3:29 PM, Doug Hellmann wrote: > Yes, please, let's try to make that work and contribute upstream if we > need minor modifications, before we create something new. We can leverage the 'retrying' module (already in global requirements). It lacks a few things we need, but those can be impl

[openstack-dev] [Fuel] Fuel 9.0 is released

Dear all, I am glad to announce Mitaka release of Fuel (a.k.a Fuel 9.0) - deployment and lifecycle management tool for OpenStack. This release introduces support for OpenStack Mitaka and adds a number of new features and enhancements. Some highlights: - Support lifecycle management operations

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

On 19/04/16 16:52, Irina Povolotskaya wrote: > Hi to everyone, > > as you possibly know (at least, those dev. teams working on their Fuel > plugins) we have a fuel-plugins Launchpad project [1] which serves as > all-in-one entry point for filing bugs, related > to plugin-specific problems. > > neve

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Steve Gordon [mailto:[email protected]] > Sent: April-21-16 9:39 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > - Original Messa

[openstack-dev] [sahara] IRC meetings for 28 Apr and 5 May SKIPPED

Hello folks. As we agreed at the last meeting [0], the next two meetings are skipped (28 Apr and 5 May) [0] http://eavesdrop.openstack.org/meetings/sahara/2016/sahara.2016-04-21-14.00.log.html#l-126 -- Best Regards, Vitaly Gridnev Mirantis, Inc __

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On 21/04/2016 15:39, Michael Krotscheck wrote: [...] > New: js-openstacklib > > This new project will be incubated as a single, gate-tested JavaScript > API client library for the OpenStack API’s. Its audience is software > engineers who wish to build their own user interface using modern > javascr

Re: [openstack-dev] [tc] Leadership training dates - please confirm attendance

> > > >> Colette Alexander wrote: > >>> Hi everyone! > >>> > >>> Quick summary of where we're at with leadership training: dates are > >>> confirmed as available with ZingTrain, and we're finalizing trainers > >>> with them right now. *June 28/29th in Ann Arbor, Michigan.* > >>> > >>> https://ether

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

+1 From: "Fox, Kevin M" mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Wednesday, April 20, 2016 at 6:14 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-d

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On 04/21/2016 10:05 AM, Hayes, Graham wrote: On 21/04/2016 15:39, Michael Krotscheck wrote: [...] New: js-openstacklib This new project will be incubated as a single, gate-tested JavaScript API client library for the OpenStack API’s. Its audience is software engineers who wish to build their ow

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On Thu, Apr 21, 2016 at 8:10 AM Hayes, Graham wrote: > On 21/04/2016 15:39, Michael Krotscheck wrote: > > python-openstackclient does require the creation of a new repo for each > project (unless you are one of the chosen few). > > Does this mean you will accept all projects to the library, or ju

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

The work on the plug-ins can still be done by Magnum core contributors (or anyone). My point is that the work doesn’t have to be code-coupled to Magnum except via the plug-in interface, which, like heat resources, should be relatively straight forward. Creating the plug-in framework in this way all

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Adrian Otto [mailto:[email protected]] > Sent: April-21-16 10:32 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > > > On Apr 2

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On Thu, Apr 21, 2016 at 8:28 AM Monty Taylor wrote: > On 04/21/2016 10:05 AM, Hayes, Graham wrote: > > On 21/04/2016 15:39, Michael Krotscheck wrote: > >> used piecemeal, however trying to maintain code consistency across > >> multiple different projects is a hard lesson that others have already

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 2016-04-21 14:05:17 +1200 (+1200), Robert Collins wrote: > On 20 April 2016 at 03:00, Jeremy Stanley wrote: [...] > > When we were firming up the constraints idea in Vancouver, if my > > memory is correct (which it quite often is not these days), part of > > the long tail Robert suggested was t

[openstack-dev] [RefStack] Weekly RefStack IRC meetings moved from Monday to Tuesday

Hello folks. As we agreed at the last IRC meeting [1], RefStack weekly IRC meetings will be moved to Tuesday at 19:00 UTC [2]. In addition, the next two meetings are skipped. We will resume weekly IRC meeting on Tuesday May 10, 2016. [1] http://eavesdrop.openstack.org/meetings/refstack/2016/r

Re: [openstack-dev] [heat]informal meetup during summit

+1 re Mon, though Fri could work as well. On Thu, Apr 21, 2016 at 3:55 AM, Jay Dobies wrote: > > > On 4/20/16 1:00 PM, Rico Lin wrote: > >> Hi team >> Let plan for more informal meetup(relax) time! Let all heaters and any >> other projects can have fun and chance for technical discussions togeth

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 21/04/16 17:38, "Hongbin Lu" wrote: > > >> -Original Message- >> From: Adrian Otto [mailto:[email protected]] >> Sent: April-21-16 10:32 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build uni

[openstack-dev] Summit Core Party after Austin

Hey everyone- So, HPE is seeking sponsors to continue the core party. The reasons are varied - internal sponsors have moved to other projects, the Big Tent has drastically increased the # of cores, and the upcoming summit format change creates quite a bit of uncertainty on everything surrounding t

Re: [openstack-dev] [heat]informal meetup during summit

On 20/04/16 13:00, Rico Lin wrote: Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or some

Re: [openstack-dev] Summit Core Party after Austin

On Thu, Apr 21, 2016 at 9:07 AM, Michael Krotscheck wrote: > Hey everyone- > > So, HPE is seeking sponsors to continue the core party. The reasons are > varied - internal sponsors have moved to other projects, the Big Tent has > drastically increased the # of cores, and the upcoming summit format

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

There¹s one more issue with lowest common denominator API. Every time a new version of native client is released, magnum will be responsible for making those sure the common denominator API works with that version of native client. Since the native client will always have more functions/features th

Re: [openstack-dev] Summit Core Party after Austin

Michael Krotscheck wrote: So, HPE is seeking sponsors to continue the core party. The reasons are varied - internal sponsors have moved to other projects, the Big Tent has drastically increased the # of cores, and the upcoming summit format change creates quite a bit of uncertainty on everything

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 21/04/16 12:26 +0200, Thierry Carrez wrote: Joshua Harlow wrote: Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an r

[openstack-dev] [Glance] Glare and future of artifacts in OpenStack.

Hello! Today I'm happy to present you a demo of a new service called Glare (means GLance Artifact REpository) which will be used as a unified catalog of artifacts in OpenStack. This service appeared in Mitaka in February and it succeeded Glance v3 API, that has become the experimental version of G

Re: [openstack-dev] Summit Core Party after Austin

Thierry Carrez wrote: [...] I think it's inappropriate because it gives a wrong incentive to become a core reviewer. Core reviewing should just be a duty you sign up to, not necessarily a way to get into a cool party. It was also a bit exclusive of other types of contributions. Apparently in Aus

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On 04/21/2016 10:32 AM, Michael Krotscheck wrote: On Thu, Apr 21, 2016 at 8:10 AM Hayes, Graham mailto:[email protected]>> wrote: On 21/04/2016 15:39, Michael Krotscheck wrote: python-openstackclient does require the creation of a new repo for each project (unless you are one of

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On 04/21/2016 10:35 AM, Michael Krotscheck wrote: On Thu, Apr 21, 2016 at 8:28 AM Monty Taylor mailto:[email protected]>> wrote: On 04/21/2016 10:05 AM, Hayes, Graham wrote: > On 21/04/2016 15:39, Michael Krotscheck wrote: >> used piecemeal, however trying to maintain code con

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 04/21/2016 11:01 AM, Flavio Percoco wrote: On 21/04/16 12:26 +0200, Thierry Carrez wrote: Joshua Harlow wrote: Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. Th

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 04/21/2016 11:03 AM, Tim Bell wrote: On 21/04/16 17:38, "Hongbin Lu" wrote: -Original Message- From: Adrian Otto [mailto:[email protected]] Sent: April-21-16 10:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][

Re: [openstack-dev] [Fuel] Newton Design Summit sessions planning

Folks, I'd like to request workroom sessions swap. I planned to lead a discussion of Fuel UI modularization on Wed 11.00-11.40, but at the same time there will be discussion of handling JS dependencies of Horizon which I'd really like to attend. So I request to swap my discussion with discussion

Re: [openstack-dev] Summit Core Party after Austin

Excerpts from Thierry Carrez's message of 2016-04-21 18:22:53 +0200: > Michael Krotscheck wrote: > > So, HPE is seeking sponsors to continue the core party. The reasons are > > varied - internal sponsors have moved to other projects, the Big Tent > > has drastically increased the # of cores, and th

Re: [openstack-dev] [tc] Leadership training dates - please confirm attendance

Excerpts from Colette Alexander's message of 2016-04-21 08:07:52 -0700: > > > > > > >> Colette Alexander wrote: > > >>> Hi everyone! > > >>> > > >>> Quick summary of where we're at with leadership training: dates are > > >>> confirmed as available with ZingTrain, and we're finalizing trainers > > >

Re: [openstack-dev] Summit Core Party after Austin

On 2016-04-21 13:40:15 -0400 (-0400), Doug Hellmann wrote: [...] > I didn't realize the tag was being used that way. I agree it's > completely inappropriate, and I wish someone had asked. [...] It's likely seen by some as a big-tent proxy for the old integrated vs. incubated distinction. -- Jerem

Re: [openstack-dev] [magnum] High Availability

Hi. The thread is a month old, but I sent a shorter version of this to Daneyon before with some info on the things we dealt with to get Magnum deployed successfully. We wrapped it up in a post (there's a video linked there with some demos at the end): http://openstack-in-production.blogspot.ch/20

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

On Thu, Apr 21, 2016 at 10:21 AM Monty Taylor wrote: > Neat! Maybe let's find a time at the summit to sit down and look through > things. I'm guessing that adding a second language consumer to the > config will raise a ton of useful questions around documentation, data > format, etc - but those w

Re: [openstack-dev] Question about OpenStack Code of Conduct

On 2016-04-21 17:54:56 + (+), Adrian Otto wrote: > Below is an excerpt from: > https://www.openstack.org/legal/community-code-of-conduct/ > > "When we disagree, we consult others. Disagreements, both social > and technical, happen all the time and the OpenStack community is > no exception.

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On 21 April 2016 at 16:54, Boden Russell wrote: > On 4/20/16 3:29 PM, Doug Hellmann wrote: > > Yes, please, let's try to make that work and contribute upstream if we > > need minor modifications, before we create something new. > > We can leverage the 'retrying' module (already in global requirem

[openstack-dev] [release] release hiatus

The release team is preparing for and traveling to the summit, just as many of you are. With that in mind, we are going to hold off on releasing anything until 2 May, unless there is some sort of critical issue or gate blockage. Please feel free to submit release requests to openstack/releases, but

Re: [openstack-dev] Summit Core Party after Austin

Excerpts from Jeremy Stanley's message of 2016-04-21 17:54:37 +: > On 2016-04-21 13:40:15 -0400 (-0400), Doug Hellmann wrote: > [...] > > I didn't realize the tag was being used that way. I agree it's > > completely inappropriate, and I wish someone had asked. > [...] > > It's likely seen by s

Re: [openstack-dev] [nova] Newton midcycle planning

On 4/11/2016 3:49 PM, Matt Riedemann wrote: A few people have been asking about planning for the nova midcycle for newton. Looking at the schedule [1] I'm thinking weeks R-15 or R-11 work the best. R-14 is close to the US July 4th holiday, R-13 is during the week of the US July 4th holiday, and R

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Salvatore Orlando wrote: On 21 April 2016 at 16:54, Boden Russell mailto:[email protected]>> wrote: On 4/20/16 3:29 PM, Doug Hellmann wrote: > Yes, please, let's try to make that work and contribute upstream if we > need minor modifications, before we create something new. W

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden Russell wrote: On 4/20/16 3:29 PM, Doug Hellmann wrote: Yes, please, let's try to make that work and contribute upstream if we need minor modifications, before we create something new. We can leverage the 'retrying' module (already in global requirements). It lacks a few things we need,

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Hi everyone, We have room 400 at 3:10pm on Thursday available for discussion of the two topics. Another option is to use the common room with roundtables in "Salon C" during Monday or Wednesday lunch time. Room 400 at 3:10pm is a closed room while the Salon C is a big open room which can host

Re: [openstack-dev] Summit Core Party after Austin

On 21/04/16 19:40, "Doug Hellmann" wrote: >Excerpts from Thierry Carrez's message of 2016-04-21 18:22:53 +0200: >> Michael Krotscheck wrote: >> >> >> So.. while I understand the need for calmer parties during the week, I >> think the general trends is to have less parties and more small group

Re: [openstack-dev] Summit Core Party after Austin

On Thu, Apr 21, 2016 at 2:43 PM, Tim Bell wrote: > > On 21/04/16 19:40, "Doug Hellmann" wrote: > > >Excerpts from Thierry Carrez's message of 2016-04-21 18:22:53 +0200: > >> Michael Krotscheck wrote: > >> > >> > >> So.. while I understand the need for calmer parties during the week, I > >> think

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

I vote for Monday to get the ball rolling, meet the interested parties, and Continue on Thursday at 3:10 in a quieter setting ... so we leave with some consensus. Thanks Cathy! Malini -Original Message- From: Cathy Zhang [mailto:[email protected]] Sent: Thursday, April 21, 2016 1

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

I haven't spent much time on this, so the answers below are a first approximation based on a quick visual inspection (e.g. subject to change when I get a chance to hack on some code). On 4/21/16 12:10 PM, Salvatore Orlando wrote: > Can you share more details on the "few things we need" that > retr

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Cathy Zhang wrote: Hi everyone, We have room 400 at 3:10pm on Thursday available for discussion of the two topics. Another option is to use the common room with roundtables in "Salon C" during Monday or Wednesday lunch time. Room 400 at 3:10pm is a closed room while the Salon C is a big

Re: [openstack-dev] Summit Core Party after Austin

On Thu, Apr 21, 2016 at 9:07 AM, Michael Krotscheck wrote: > Hey everyone- > > So, HPE is seeking sponsors to continue the core party. The reasons are > varied - internal sponsors have moved to other projects, the Big Tent has > drastically increased the # of cores, and the upcoming summit format

Re: [openstack-dev] [magnum] High Availability

Ricardo, That is great! It is good to hear Magnum works well in your side. Best regards, Hongbin > -Original Message- > From: Ricardo Rocha [mailto:[email protected]] > Sent: April-21-16 1:48 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openst

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

+1. From: Hongbin Lu [[email protected]] Sent: Thursday, April 21, 2016 7:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs > -Origi

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

The COE's have a pressure not to standardize their api's between competing COE's. If you can lock a user into your api, then they cant go to your competitor. The standard api really needs to come from those invested in not being locked in. OpenStack's been largely about that since the beginning

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden Russell wrote: I haven't spent much time on this, so the answers below are a first approximation based on a quick visual inspection (e.g. subject to change when I get a chance to hack on some code). On 4/21/16 12:10 PM, Salvatore Orlando wrote: Can you share more details on the "few thing

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I agree with that, and thats why providing some bare minimum abstraction will help the users not have to choose a COE themselves. If we can't decide, why can they? If all they want to do is launch a container, they should be able to script up "magnum launch-container foo/bar:latest" and get one.

Re: [openstack-dev] Summit Core Party after Austin

On 04/21/2016 02:08 PM, Devananda van der Veen wrote: On Thu, Apr 21, 2016 at 9:07 AM, Michael Krotscheck mailto:[email protected]>> wrote: Hey everyone- So, HPE is seeking sponsors to continue the core party. The reasons are varied - internal sponsors have moved to other project

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

If you don¹t want a user to have to choose a COE, can¹t we just offer an option for the operator to mark a particular COE as the ³Default COE² that could be defaulted to if one isn¹t specified in the Bay create call? If the operator didn¹t specify a default one, then the CLI/UI must submit one in

Re: [openstack-dev] Summit Core Party after Austin

On 04/21/2016 04:04 PM, Monty Taylor wrote: > On 04/21/2016 02:08 PM, Devananda van der Veen wrote: >> The first cross-project design summit tracks were held at the following >> summit, in Atlanta, though I recall it lacking the necessary >> participation to be successful. Today, we have many more

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On 4/21/16 1:38 PM, Joshua Harlow wrote: > This might be harder in retrying, but I think I can help u make > something that will work, since retrying has a way to provide a custom > delay function. Thanks for that. My question was if this might be useful as a new backoff in retrying (vs a custom

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Here's where we disagree. Your speaking for everyone in the world now, and all you need is one counter example. I'll be that guy. Me. I want a common abstraction for some common LCD stuff. Both Sahara and Trove have LCD abstractions for very common things. Magnum should too. You are falsely a

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

There are a few reasons, but the primary one that affects me is Its from the app-catalog use case. To gain user support for a product like OpenStack, you need users. The easier you make it to use, the more users you can potentially get. Traditional Operating Systems learned this a while back.

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I believe you just described Murano. On 04/21/2016 03:31 PM, Fox, Kevin M wrote: There are a few reasons, but the primary one that affects me is Its from the app-catalog use case. To gain user support for a product like OpenStack, you need users. The easier you make it to use, the more users

Re: [openstack-dev] [Fuel] snapshot tool

Team, A "bicycle" will have to be present anyway, as a code which interacts with Ansible, because as far as I understand Ansible on it's own cannot provide all the functionality in one go, so a wrapper for it will have to be present anyway. I think me and Alexander we will look into converting Ti

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

On 04/21/2016 03:18 PM, Fox, Kevin M wrote: Here's where we disagree. We may have to agree to disagree. Your speaking for everyone in the world now, and all you need is one counter example. I'll be that guy. Me. I want a common abstraction for some common LCD stuff. We also disagree on this

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

+1 on Wednesday lunch On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka wrote: > Cathy Zhang wrote: > > Hi everyone, >> >> We have room 400 at 3:10pm on Thursday available for discussion of the >> two topics. >> Another option is to use the common room with roundtables in "Salon C" >> during Mo

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I thought this was also what the goal of https://cncf.io/ was starting to be? Maybe to early to tell if that standardization will be an real outcome vs just an imagined outcome :-P -Josh Fox, Kevin M wrote: The COE's have a pressure not to standardize their api's between competing COE's. If

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

100% agreed on all your points… with the addition that the level of functionality you are asking for doesn’t need to be baked into an API service such as Magnum. I.e., Magnum doesn’t have to be the thing providing the easy-button app deployment — Magnum isn’t and shouldn’t be a Docker Hub alternat

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Keith Bray [mailto:[email protected]] > Sent: Thursday, April 21, 2016 5:11 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > >

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

As I was preparing some thoughts for the Board/TC meeting on Sunday that will discuss this topic, I made the notes below and was going to post them on a topic specific etherpad but I didn't find one. I want to represent the view point of a consumer of compute services in OpenStack. Trove is a c

[openstack-dev] [kolla] deploy kolla on ppc64

I've been using Kola to deploy Mitaka on x86 and it works great. Now I would like to do the same thing on IBM Power8 systems (ppc64). I've setup a local registry with an Ubuntu image. I've docker and a local registry running on a Power8 system. When I issue the following command: kolla-build -

Re: [openstack-dev] [infra] [releases] Behavior change in the bot for jenkins merge?

Thanks! somehow I missed it earlier. On 4/11/16 9:53 PM, Clark Boylan wrote: > On Mon, Apr 11, 2016, at 06:18 PM, Nikhil Komawar wrote: >> Hi, >> >> I noticed on a recent merge to glance [1] that the bot updated the bug >> [2] with comment from "in progress" to "fix released" vs. earlier >> behavi

Re: [openstack-dev] [kolla] deploy kolla on ppc64

On Thu, Apr 21, 2016 at 11:29 PM, Franck Barillaud wrote: > I've been using Kola to deploy Mitaka on x86 and it works great. Now I would > like to do the same thing on IBM Power8 systems (ppc64). I've setup a local > registry with an Ubuntu image. > I've docker and a local registry running on a Po

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Yeah. its good to disagree and talk through it. sometimes there just isn't a way to see eye to eye on something. thats fine too. I was just objecting to the assertion: "I do not believe anyone in the world wants us to build an > abstraction layer on top of the _use_ of swarm/k8s/mesos. People wh

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Hi Monty, I respect your position, but I want to point out that there is not only one human wants this. There are a group of people want this. I have been working for Magnum in about a year and a half. Along the way, I have been researching how to attract users to Magnum. My observation is ther

  1   2   >