Re: [openstack-dev] [OpenStack-Infra] Upcoming changes now that Jenkins has retired

[Steven Dake (stdake)]

On 6/16/16, 6:13 PM, "James E. Blair"  wrote:

>Now that we have retired Jenkins, we have some upcoming changes:
>
>* Console logs are now available via TCP
>
>  The status page now has "telnet" protocol links to running jobs.  If
>  you connect to the host and port specified in that link, you will be
>  sent the console log for that job up to that point in time and it
>  will continue to stream over that connection in real time.  If your
>  browser doesn't understand "telnet://" URLs, just grab the host and
>  port and type "telnet  " or better yet, "nc 
>  " into your terminal.  You can also grep through in progress
>  console logs with "nc   | grep ".
>
>* Console logs will soon be available over the WWW
>
>  Netcatting to Grep is cool, but sometimes if you're already in a
>  browser, it may be easier to click on a link and have that just open
>  up in your existing browser.  Monty has been working on a websocket
>  interface to the console log stream that we hope to have in place
>  soon.
>
>* Zuul will stop using the name "Jenkins"
>
>  There is a new user in Gerrit named "Zuul".  Zuul has been
>  masquerading as Jenkins for the past few years, but now that we no
>  longer run any software named "Jenkins" it is the right time to
>  change the name to Zuul.  If you have any programs, scripts,
>  dashboards, etc, that look for either the full name "Jenkins" or
>  username "jenkins" from Gerrit, you should immediately update them
>  to also use the full name "Zuul" or username "zuul" in order to
>  prepare for the change.

Jim,

Apologies for the confusion on my end, but does this also apply to the
gate jenkins user?

Thanks
-steve

>
>-Jim
>
>___
>OpenStack-Infra mailing list
>openstack-in...@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] our 3 voting processes in detail

[Steven Dake (stdake)]

Thanks for the suggestion.  I think it merits further work to write our
policies down in git.  I wanted to get this out a little more quickly
since these are our foundational policies and there is some confusion
among the cores about them - even though we have been using them for the
better part of 2+ years :)

I'll see what I can do to get our policies put into our documentation.

Regards,
-steve

On 6/17/16, 7:36 PM, "Gerard Braad"  wrote:

>On Sat, Jun 18, 2016 at 9:49 AM, Assaf Muller  wrote:
>> I would recommend in-tree policies .rsts instead of Wiki entries.
>> There is a higher cost to make changes, but they have to go through
>> the review process, and the content will survive as long as the .git
>> repo does.
>
>Good point. The higher cost is probably even desirable. +1
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Matthew Treinish]

On Fri, Jun 17, 2016 at 04:26:49PM -0700, Mike Perez wrote:
> On 15:12 Jun 14, Matthew Treinish wrote:
> > On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> > > Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> 
> 
> 
> > > We have basically three options.
> > > 
> > > 1. Tell deployers who are trying to do the right for their immediate
> > >users that they can't use the trademark.
> > > 
> > > 2. Flag the related tests or remove them from the DefCore enforcement
> > >suite entirely.
> > > 
> > > 3. Be flexible about giving consumers of Tempest time to meet the
> > >new requirement by providing a way to disable the checks.
> > > 
> > > Option 1 goes against our own backwards compatibility policies.
> > 
> > I don't think backwards compatibility policies really apply to what what 
> > define
> > as the set of tests that as a community we are saying a vendor has to pass 
> > to
> > say they're OpenStack. From my perspective as a community we either take a 
> > hard
> > stance on this and say to be considered an interoperable cloud (and to get 
> > the
> > trademark) you have to actually have an interoperable product. We slowly 
> > ratchet
> > up the requirements every 6 months, there isn't any implied backwards
> > compatibility in doing that. You passed in the past but not in the newer 
> > stricter
> > guidelines.
> > 
> > Also, even if I did think it applied, we're not talking about a change which
> > would fall into breaking that. The change was introduced a year and half ago
> > during kilo and landed a year ago during liberty:
> > 
> > https://review.openstack.org/#/c/156130/
> > 
> > That's way longer than our normal deprecation period of 3 months and a 
> > release
> > boundary.
> 
> 
> 
> What kind of communication happens today for these changes? There are so many
> channels/high volume mailing lists a downstream deployer is expected by the
> community to listening in. Some disruptive change being introduced a year or
> longer ago can still be communicated poorly.

Sure, I agree with that, but I don't think this was necessarily communicated
poorly. This has been already mentioned a few times on this thread but:

It was talked about on openstack-dev:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html

On the defcore list: (which is definitely not high volume/traffic ML)

http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html

This was also raised as an issue for 1 vendor ~6 months ago. (which is also the
same duration of the hard deadline being discussed in this thread):

http://lists.openstack.org/pipermail/defcore-committee/2016-January/000986.html

IMHO, this was more than enough time to introduce a fix or workaround on their
end. Likely the easiest being just adding an extra nova-api endpoint with the
extensions disabled.

I don't have any links or other evidence to point to, but I know that this
exact topic has been discussed with with people from the vendors having
difficulties during sessions at at least one of the 2 summits and/or 2 QA
midcycle meetups since this change landed. I really don't think this is a
communication problem or unfair surprise for anyone.

There might be more too, but I don't remember every conversation that I've had
in the community over the past year. (or where to find the links to point to)

> 
> Just like we've done with Reno in communicating better about disruptive 
> changes
> in release notes, what tells teams like DefCore about changes with Tempest?
> (I looked in release.o.o for tempest release notes, although maybe I missed
> it?)

Yes, tempest has release notes, they are here:

http://docs.openstack.org/releasenotes/tempest/

But, the change in question predates the existence of reno and centralized
release notes for everything in openstack.

If this change were pushed today it would definitely be included in the release
notes. We also would do the same things, put it on the dev list, put it on the
defcore list. (although probably as a standalone thread this time) I also think
we'd probably ping hogepodge on irc about it too just so he could also raise it
up on the defcore side. (which we might have done back then too) Defcore and
tempest are tightly coupled so we do have pretty constant communication around
changes being made. But, I do admit we have better mechanisms in place today
to communicate this kind of change, and hopefully this would be handled better
now.

> 
> Since some members of DefCore have interest in making the market place 
> healthy,
> what is DefCore doing today to communicate these disruptive changes early to
> deployers? Did it not happen in this particular case because:
> 
> * DefCore has no one working closely in the Tempest project to flag things?
> * Defcore does work closely with Tempest, but somehow the communication for
>   this was missed?
> * Not having clear 

Re: [openstack-dev] [kolla] our 3 voting processes in detail

[Gerard Braad]

On Sat, Jun 18, 2016 at 9:49 AM, Assaf Muller  wrote:
> I would recommend in-tree policies .rsts instead of Wiki entries.
> There is a higher cost to make changes, but they have to go through
> the review process, and the content will survive as long as the .git
> repo does.

Good point. The higher cost is probably even desirable. +1

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] our 3 voting processes in detail

[Assaf Muller]

On Fri, Jun 17, 2016 at 9:41 PM, Gerard Braad  wrote:
> Thanks Steve,
>
>
> Very useful. Would be great if for future reference we would only need
> to pint people to an URL on the Wiki for instance... what do you
> think?

I would recommend in-tree policies .rsts instead of Wiki entries. We
do that in Neutron-land and the resulting HTML is published here:
http://docs.openstack.org/developer/neutron/policies/index.html

There is a higher cost to make changes, but they have to go through
the review process, and the content will survive as long as the .git
repo does.

>
> regards,
>
>
> Gerard
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] our 3 voting processes in detail

[Gerard Braad]

Thanks Steve,


Very useful. Would be great if for future reference we would only need
to pint people to an URL on the Wiki for instance... what do you
think?

regards,


Gerard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] our 3 voting processes in detail

[Steven Dake (stdake)]

Hey core reviewers,

I was speaking with one of the core reviewers of Kolla today who said "only you 
can nominate people for core reviewer".  By you, he meant me :)  This is 
absolutely not true and I'd like to set the record straight on our three voting 
processes we have developed over the last 3 years of the project's existence:

For core reviewer nominations:
If you have someone in mind you would like to propose, please contact the PTL 
via email or irc or cellphone or carrier pigeon.  Feel free to make a short 
writeup about the individual's accomplishments or if you don't the PTL will.  I 
will send it on or craft a message for the mailing list.  The core reviewer 
nominations while originating from my email address represent a nomination from 
the community, not me personally.

Requires majority of core reviewers to vote +1 with no veto vote within 1 week 
window.  Voting closes early on unanimous vote or veto.

For policy matters:
If you want to trigger a policy change, please either send an email to the 
mailing list with the [kolla][vote] tag with your proposal or contact the PTL 
to execute the vote.

Requires majority of core reviewers to vote +1 within 1 week window.  No veto 
is permitted.  Voting closes early when majority is reached.

For technical specifications of a contentious nature or that are highly complex 
changes:
Kolla uses specifications as a last resort mechanism when other forms of 
communication have failed.  Another use of specifications is to discuss highly 
complex topics that touch a whole lot of Kolla.  Many times after the 
specification is created and discussed in gerrit, it is abandoned as the review 
process itself sets a direction that breaks the logjam.

Anyone may submit a specification for review.

Requires majority of core reviewers to vote +2.  There is no time window.  The 
final majority vote may workflow the specification.  No veto (A vote of -2)  is 
permitted.

NB: The reason no veto is permitted on specs or policy matters is to break 
logjams.  Democracies operate best when there are no veto abilities.  This 
prevents dictatorships.
NB: The reason veto is permitted on core review nominations is related to how 
OpenStack operates and has a whole lot to do with trust.
NB: If the PTL is unresponsive (Ill, on vacation for 3 months in the bahamas, 
whatever) please feel free to take it upon yourself to execute the actions 
declared above that the PTL would typically do.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] No Neutron Common Flow Classifier meeting on 6/21 UTC 1700

[Cathy Zhang]

Hi everyone,

Since we have had the meeting discussion on Common Flow classifier on 
6/14/2016, we will not have another meeting on 6/21/2016. 
We will have our next meeting on 7/5/2016 and then have one every odd week. 

Here is the link to the feature wiki page. 
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier

Thanks,
Cathy 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?

[Kosnik, Lubosz]

Here is a bug for that - https://bugs.launchpad.net/octavia/+bug/1585804
You’re more than welcome to fix this issue.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

On Jun 17, 2016, at 6:37 PM, Jiahao Liang 
> wrote:

Added more related topics to the original email.

-- Forwarded message --
From: Jiahao Liang (Frankie) 
>
Date: Fri, Jun 17, 2016 at 4:30 PM
Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and gateway 
are required but not used?
To: openstack-dev@lists.openstack.org


Hi community,

I am going over the Octavia amphora backend code. There is one thing really 
confused me. In 
https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/plug.py#L45,
 plug_vip() method doesn't use the cidr and gateway from the REST request. But 
in the haproxy amphora api, those two fields are required values (an 
assert
 will perform on the server).

What is the design considerations for this api? Could we safely remove these 
two values to avoid ambiguity?

Thank you,
Jiahao Liang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker][nfv][midcycle] Straw poll on F2F vs Virtual midcycle meetup

[Sridhar Ramaswamy]

Thanks for all those who responded. The poll is closed now. It was a
unanimous pick for a Virtual midcycle meetup. I'll send out another doodle
poll to pick date & time in late July for the meetup.

- Sridhar

On Tue, Jun 7, 2016 at 5:15 PM, Sridhar Ramaswamy  wrote:

> Tackers,
>
> Please respond to this straw poll to gauge general interest for a midcycle
> meetup in this dev cycle,
>
> http://doodle.com/poll/2p62zzgevg6h5xkn
>
> Based on this outcome, if there is enough interest, will send another poll
> to zoom on a date (roughly 2nd half of July).
>
> thanks,
> Sridhar
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS][Octavia]In amphora plugin_vip(), why cidr and gateway are required but not used?

[Jiahao Liang]

Added more related topics to the original email.

-- Forwarded message --
From: Jiahao Liang (Frankie) 
Date: Fri, Jun 17, 2016 at 4:30 PM
Subject: [openstack-dev][Octavia]In amphora plugin_vip(), why cidr and
gateway are required but not used?
To: openstack-dev@lists.openstack.org


Hi community,

I am going over the Octavia amphora backend code. There is one thing really
confused me. In
https://github.com/openstack/octavia/blob/stable/mitaka/octavia/amphorae/backends/agent/api_server/plug.py#L45,
plug_vip() method doesn't use the cidr and gateway from the REST request.
But in the haproxy amphora api, those two fields are required values (an
assert

will
perform on the server).

What is the design considerations for this api? Could we safely remove
these two values to avoid ambiguity?

Thank you,
Jiahao Liang
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[Mike Perez]

On 15:12 Jun 14, Matthew Treinish wrote:
> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> > Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:



> > We have basically three options.
> > 
> > 1. Tell deployers who are trying to do the right for their immediate
> >users that they can't use the trademark.
> > 
> > 2. Flag the related tests or remove them from the DefCore enforcement
> >suite entirely.
> > 
> > 3. Be flexible about giving consumers of Tempest time to meet the
> >new requirement by providing a way to disable the checks.
> > 
> > Option 1 goes against our own backwards compatibility policies.
> 
> I don't think backwards compatibility policies really apply to what what 
> define
> as the set of tests that as a community we are saying a vendor has to pass to
> say they're OpenStack. From my perspective as a community we either take a 
> hard
> stance on this and say to be considered an interoperable cloud (and to get the
> trademark) you have to actually have an interoperable product. We slowly 
> ratchet
> up the requirements every 6 months, there isn't any implied backwards
> compatibility in doing that. You passed in the past but not in the newer 
> stricter
> guidelines.
> 
> Also, even if I did think it applied, we're not talking about a change which
> would fall into breaking that. The change was introduced a year and half ago
> during kilo and landed a year ago during liberty:
> 
> https://review.openstack.org/#/c/156130/
> 
> That's way longer than our normal deprecation period of 3 months and a release
> boundary.



What kind of communication happens today for these changes? There are so many
channels/high volume mailing lists a downstream deployer is expected by the
community to listening in. Some disruptive change being introduced a year or
longer ago can still be communicated poorly.

Just like we've done with Reno in communicating better about disruptive changes
in release notes, what tells teams like DefCore about changes with Tempest?
(I looked in release.o.o for tempest release notes, although maybe I missed
it?)

Since some members of DefCore have interest in making the market place healthy,
what is DefCore doing today to communicate these disruptive changes early to
deployers? Did it not happen in this particular case because:

* DefCore has no one working closely in the Tempest project to flag things?
* Defcore does work closely with Tempest, but somehow the communication for
  this was missed?
* Not having clear deprecation notices because release notes in the Tempest
  don't exist (see above)?

This all just sounds like a communication problem, and it makes me sad to
interpret this thread as people being angry with deployers as a result. How
about we not think the worse of people that are trying to prove our project
being successful and start working with them?

With that said I agree with this strict checking in tests. Deployments need to
stop defining the community defined APIs.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Joshua Harlow]

Thanks for getting this started Clint,

I'm happy and excited to be involved in helping try to guide the whole 
ecosystem together (it's also why I like being in oslo) to a 
architecture that is more cohesive (and is more of something that we can 
say to our current or future children that we were all involved and 
proud to be involved in creating/maturing...).


At a start, for said first meeting, any kind of agenda come to mind, or 
will it be more a informal gathering to start (either is fine with me)?


-Josh

Clint Byrum wrote:

ar·chi·tec·ture
ˈärkəˌtek(t)SHər/
noun
noun: architecture

 1.

 the art or practice of designing and constructing buildings.

 synonyms:building design, building style, planning, building, construction;

 formalarchitectonics

 "modern architecture"

 the style in which a building is designed or constructed, especially with 
regard to a specific period, place, or culture.

 plural noun: architectures

 "Victorian architecture"

 2.

 the complex or carefully designed structure of something.

 "the chemical architecture of the human brain"

 the conceptual structure and logical organization of a computer or 
computer-based system.

 "a client/server architecture"

 synonyms:structure, construction, organization, layout, design, build, 
anatomy, makeup;

 informalsetup

 "the architecture of a computer system"


Introduction
=

OpenStack is a big system. We have debated what it actually is [1],
and there are even t-shirts to poke fun at the fact that we don't have
good answers.

But this isn't what any of us wants. We'd like to be able to point
at something and proudly tell people "This is what we designed and
implemented."

And for each individual project, that is a possibility. Neutron can
tell you they designed how their agents and drivers work. Nova can
tell you that they designed the way conductors handle communication
with API nodes and compute nodes. But when we start talking about how
they interact with each other, it's clearly just a coincidental mash of
de-facto standards and specs that don't help anyone make decisions when
refactoring or adding on to the system.

Oslo and cross-project initiatives have brought some peace and order
to the implementation and engineering processes, but not to the design
process. New ideas still start largely in the project where they are
needed most, and often conflict with similar decisions and ideas in other
projects [dlm, taskflow, tooz, service discovery, state machines, glance
tasks, messaging patterns, database patterns, etc. etc.]. Often times this
creates a log jam where none of the projects adopt a solution that would
align with others. Most of the time when things finally come to a head
these things get done in a piecemeal fashion, where it's half done here,
1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
looks like  chaos, because that's precisely what it is.

And this isn't always a technical design problem. OpenStack, for instance,
isn't really a micro service architecture. Of course, it might look like
that in diagrams [2], but we all know it really isn't. The compute node is
home to agents for every single concern, and the API interactions between
the services is too tightly woven to consider many of them functional
without the same lockstep version of other services together. A game to
play is ask yourself what would happen if a service was isolated on its
own island, how functional would its API be, if at all. Is this something
that we want? No. But there doesn't seem to be a place where we can go
to actually design, discuss, debate, and ratify changes that would help
us get to the point of gathering the necessary will and capability to
enact these efforts.

Maybe nova-compute should be isolated from nova, with an API that
nova, cinder and neutron talk to. Maybe we should make the scheduler
cross-project aware and capable of scheduling more than just nova
instances. Maybe we should have experimental groups that can look at how
some of this functionality could perhaps be delegated to non-openstack
projects. We hear that Mesos, for example to help with the scheduling
aspects, but how do we discuss these outside hijacking threads on the
mailing list? These are things that we all discuss in the hallways
and bars and parties at the summit, but because they cross projects at
the design level, and are inherently a lot of social and technical and
exploratory work, Many of us fear we never get to a place of turning
our dreams into reality.

So, with that, I'd like to propose the creation of an Architecture Working
Group. This group's charge would not be design by committee, but a place
for architects to share their designs and gain support across projects
to move forward with and ratify architectural decisions. That includes
coordinating exploratory work that may turn into being the base of further
architectural decisions for 

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

[Steven Dake (stdake)]

Ricardo,

As one of the original authors of Magnum, I'm super pleased to hear Magnum 
works at this scale with a kubernetes bay.  I don't think it would have done 
that when I finished working on Magnum - a testament to the great community 
around Magnum.

Regards
-steve

From: Ton Ngo >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, June 17, 2016 at 9:06 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes


Thanks Ricardo for sharing the data, this is really encouraging!
Ton,

[Inactive hide details for Ricardo Rocha ---06/17/2016 08:16:15 AM---Hi. Just 
thought the Magnum team would be happy to hear :)]Ricardo Rocha ---06/17/2016 
08:16:15 AM---Hi. Just thought the Magnum team would be happy to hear :)

From: Ricardo Rocha >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: 06/17/2016 08:16 AM
Subject: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes





Hi.

Just thought the Magnum team would be happy to hear :)

We had access to some hardware the last couple days, and tried some
tests with Magnum and Kubernetes - following an original blog post
from the kubernetes team.

Got a 200 node kubernetes bay (800 cores) reaching 2 million requests / sec.

Check here for some details:
https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html

We'll try bigger in a couple weeks, also using the Rally work from
Winnie, Ton and Spyros to see where it breaks. Already identified a
couple issues, will add bugs or push patches for those. If you have
ideas or suggestions for the next tests let us know.

Magnum is looking pretty good!

Cheers,
Ricardo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] Action parameter missing in generated stonith fence manifests

[Devon Mizelle]

Greetings,

I was directed here from #puppet-openstack to submit an e-mail.

Noted here, there is an 'action' parameter defined for fence_ifmib:

https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/agent_generator/src_xml/fence_ifmib.xml#L83

However, in the generated manifest here, it seems that the 'action'
parameter is missing:

https://github.com/openstack/puppet-pacemaker/blob/f62805f678f6fd8a260118279f6e0dbb05bff3d1/manifests/stonith/fence_ifmib.pp

It looks like the 'action' parameter is missing in every fence_*
manifest (and has never existed.) I need this available to me so that
I can override the default action of fence_ifmib (which is 'reboot')
and set it to 'off'.

It looks like that in the agent_generator.rb script, action is being
specifically ignored in addition to 'help' and 'version' parameters.
I've attached a quick plain-text patch. I don't think this is the
norm, but considering that its such a small one word change I'm hoping
it would be OK.

Thanks for your time and for a wonderful project,
Devon

diff --git a/agent_generator/agent_generator.rb
b/agent_generator/agent_generator.rb
index 9c1ab0a..171ca50 100755
--- a/agent_generator/agent_generator.rb
+++ b/agent_generator/agent_generator.rb
@@ -40,7 +40,7 @@ class FencingMetadataParser
   param['default'] = REXML::XPath.match(p, 'string(./content/@default)')[0]
   param['description'] = REXML::XPath.match(p, 'string(./shortdesc)')[0]
   ## remove parameters that are not usable during automatic execution
-  @params.push(param) unless %w(help version
action).include?(param['name'])
+  @params.push(param) unless %w(help version).include?(param['name'])
 }
 @params
   end

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

[Joshua Harlow]

Hi folks,

I was noticing that its possible to do something like:

$ nova meta josh-testr3 set "e=f"

Then inside the VM I can do the following to eventually see that this 
changes shows up in the instance metadata exposed at the following:


$ curl -s http://169.254.169.254/openstack/latest/meta_data.json | 
python -mjson.tool


{
...
"hostname": "josh-testr3.cloud.phx3.gdg",
"launch_index": 0,
"meta": {
...
"e": "f",
..
 }
 ...
}

Now if I am using the configdrive instead of the metadata server at that 
special/magic ip that same metadata never seems to change (I assume the 
configdrive would have to be 'ejected' and then a new configdrive 
created and then that configdrive 'reinserted'); was anyone aware of a 
bug that would solve this (it does appear to be a feature difference 
that could/should? be solved)?


Why this is something useful (from my view) is that we (at godaddy) have 
a cron job that polls that metadata periodically and it generates a 
bunch of polling traffic (especially when each VM does this) and that 
traffic could be removed if such a 'eject' and 'reinsert' happens 
instead (since then the cron job could become a small program that 
listens for devices being inserted/removed and does the needed actions 
then, which is better than polling endlessly for data that hasn't changed).


-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Proposal: Architecture Working Group

[Clint Byrum]

ar·chi·tec·ture
ˈärkəˌtek(t)SHər/
noun
noun: architecture

1. 

the art or practice of designing and constructing buildings.

synonyms:building design, building style, planning, building, construction; 

formalarchitectonics 

"modern architecture"

the style in which a building is designed or constructed, especially with 
regard to a specific period, place, or culture.

plural noun: architectures

"Victorian architecture"

2. 

the complex or carefully designed structure of something.

"the chemical architecture of the human brain"

the conceptual structure and logical organization of a computer or 
computer-based system.

"a client/server architecture"

synonyms:structure, construction, organization, layout, design, build, 
anatomy, makeup; 

informalsetup 

"the architecture of a computer system"


Introduction
=

OpenStack is a big system. We have debated what it actually is [1],
and there are even t-shirts to poke fun at the fact that we don't have
good answers.

But this isn't what any of us wants. We'd like to be able to point
at something and proudly tell people "This is what we designed and
implemented."

And for each individual project, that is a possibility. Neutron can
tell you they designed how their agents and drivers work. Nova can
tell you that they designed the way conductors handle communication
with API nodes and compute nodes. But when we start talking about how
they interact with each other, it's clearly just a coincidental mash of
de-facto standards and specs that don't help anyone make decisions when
refactoring or adding on to the system.

Oslo and cross-project initiatives have brought some peace and order
to the implementation and engineering processes, but not to the design
process. New ideas still start largely in the project where they are
needed most, and often conflict with similar decisions and ideas in other
projects [dlm, taskflow, tooz, service discovery, state machines, glance
tasks, messaging patterns, database patterns, etc. etc.]. Often times this
creates a log jam where none of the projects adopt a solution that would
align with others. Most of the time when things finally come to a head
these things get done in a piecemeal fashion, where it's half done here,
1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
looks like  chaos, because that's precisely what it is.

And this isn't always a technical design problem. OpenStack, for instance,
isn't really a micro service architecture. Of course, it might look like
that in diagrams [2], but we all know it really isn't. The compute node is
home to agents for every single concern, and the API interactions between
the services is too tightly woven to consider many of them functional
without the same lockstep version of other services together. A game to
play is ask yourself what would happen if a service was isolated on its
own island, how functional would its API be, if at all. Is this something
that we want? No. But there doesn't seem to be a place where we can go
to actually design, discuss, debate, and ratify changes that would help
us get to the point of gathering the necessary will and capability to
enact these efforts.

Maybe nova-compute should be isolated from nova, with an API that
nova, cinder and neutron talk to. Maybe we should make the scheduler
cross-project aware and capable of scheduling more than just nova
instances. Maybe we should have experimental groups that can look at how
some of this functionality could perhaps be delegated to non-openstack
projects. We hear that Mesos, for example to help with the scheduling
aspects, but how do we discuss these outside hijacking threads on the
mailing list? These are things that we all discuss in the hallways
and bars and parties at the summit, but because they cross projects at
the design level, and are inherently a lot of social and technical and
exploratory work, Many of us fear we never get to a place of turning
our dreams into reality.

So, with that, I'd like to propose the creation of an Architecture Working
Group. This group's charge would not be design by committee, but a place
for architects to share their designs and gain support across projects
to move forward with and ratify architectural decisions. That includes
coordinating exploratory work that may turn into being the base of further
architectural decisions for OpenStack. I would expect that the people
in this group would largely be senior at the companies involved and,
if done correctly, they can help prioritize this work by advocating for
people/fellow engineers to actually make it 'real'. This will give weight
to specs and implementation changes to make these designs a reality,
and thus I believe this group would do well to work closely with the
Oslo Team, where many of the cross-cutting efforts will need to happen.

How to get involved
===

If the idea is well received, I'd like to propose 

[openstack-dev] OpenStack Developer Mailing List Digest May 14 to June 17

[Mike Perez]

HTML render: 
http://www.openstack.org/blog/2016/06/openstack-developer-mailing-list-digest-20160617/

SuccessBot Says
===
* Qiming: Senlin has completed API migration from WADL.
* Mugsie: Kiall Fixed the gate - development can now continue!!!
* notmyname: exactly 6 years ago today, Swift was put into production
* kiall: DNS API reference is live [1].
* sdague: Nova legacy v2 api code removed [2].
* HenryG: Last remnant of oslo incubator removed from Neutron [3].
* dstanek: I was able to perform a roundtrip between keystone and testshib.org
  using my new SAML2 middleware!
* Sdague: Nova now defaults to Glance v2 for image operations [4].
* Ajaeger: First Project Specific Install Guide is published - congrats to the
  heat team!
* Jeblair: There is no Jenkins, only Zuul.
* All: https://wiki.openstack.org/wiki/Successes


Require A Level Playing Field for OpenStack Projects

* Thierry Carrez proposes a new requirement [5] for OpenStack “official”
  projects.
* An important characteristic of open collaboration grounds is they need to be
  a level playing field. No specific organization can be given an unfair
  advantage.

  - Projects that are blessed as “official” project teams need to operate in
a fair manner. Otherwise they could be essentially a trojan horse for
a given organization.
  - If in a given project, developers from one specific organization benefit
from access specific knowledge or hardware, then the project should be
rejected under the “open community” rule.
  - Projects like Cinder provide an interesting grey area, but as long as all
drivers are in and there is a fully functional (and popular) open source
implementation there is likely no specific organization considered as
unfairly benefiting.

* Neutron plugin targeting a specific piece of networking hardware would likely
  given an unfair advantage to developers of the hardware's manufacturer
  (having access to hardware for testing and being able to see and make changes
  to its proprietary source code).
* Open source projects that don't meet the open community requirement can still
  exist in the ecosystem (developed using gerrit and openstack/* git
  repository, gate testing, but as an unofficial project.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-June/thread.html#97307


Add Option to Disable Some Strict Response Checking for Interop Testing

* Nova introduced their API micro version change [6]
* QA team adds strict API schema checking to Tempest to ensure no additional
  Nova API responses [7][8].
  - In the last year, three vendors participating in the OpenStack powered
trademark program were impacted by this [9].
* DefCore working group determines guidelines for the OpenStack powered
  program.

  - Includes capabilities with associated functional tests from Tempest that
must pass.
  - There is a balance of future direction of development with lagging
indicators of deployments and user adoption.

* A member of the working group Chris Hoge would like to implement a temporary
  waiver for strict API checking requirements.

  - While this was discussed publicly in the developer community and took some
time to implement. It still landed quickly, and broke several existing
deployments overnight.
  - It's not viable for downstream deployers to use older versions of Tempest
that don't have these strict response checking, due to the TC resolution
passed [10] to advise DefCore to use Tempest as the single source of

capability testing.
* Proposal:
  - Short term:
+ There will be a blueprint and patch to Tempest that allows configuration
  of a grey-list of Nova APIs which strict response checking on additional
  properties will be disabled.
+ Using this code will emit a deprecation warning.
+ This will be removed 2017.01.
+ Vendors are required to submit the grey-list of APIs with additional
  response data that would be published to their marketplace entry.

  - Long term:
+ Vendors will be expected to work with upstream to update the API
  returning additional data.
+ The waiver would no longer be allowed after the release of 2017.01
guidleine.

* Former QA PTL Matthew Treinish feels this a big step backwards.
  - Vendors who have implemented out of band extensions or injected additional
things in responses believe that by doing so they're interoperable. The API
is not a place for vendor differentation.
  - Being a user of several clouds, random data in the response makes it more
difficult to write code against. Which are the vendor specific responses?
* Alternatives to not giving vendors more time in the market:
  - Having some vendors leave the the Powered program unnecessarily weakening
it.
  - Force DefCore to adopt non-upstream testing, either as a fork

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Sylvain Bauza]

Le 17/06/2016 18:11, Dean Troyer a écrit :
On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza > wrote:


In the review, you explain why you don't trust Routes and I
respect that. That said, are those issues logged as real problems
for our API consumers, which are mostly client libraries that we
own and other projects we know, like Horizon ?


I feel a bit compelled to say that the assumption that the API 
consumers are mostly 'our code' is a faulty one and not true.  Just 
within the collection of client projects in the openstack/ repo 
namespace, there are at least 4 different codebases talking to compute 
endpoints.


I'm not picking on you Sylvain, this is just something that I think 
needs periodic reinforcement among our developer community.




No worries at all, Dean. Thanks for explaining your opinion. To be 
clear, I used "we" for saying "We are OpenStack", ie. an excellent 
ecosystem.




dt

--

Dean Troyer
dtro...@gmail.com 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

John McDowall  wrote on 06/17/2016 04:07:38
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: discuss , Na Zhu ,
> "OpenStack Development Mailing List (not for usage questions)"
> , Srilatha Tangirala/San
> Francisco/IBM@IBMUS
> Date: 06/17/2016 04:07 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Ryan,
>
> See inline
>
> Regards
>
> John
>
> From: Ryan Moats 
> Date: Friday, June 17, 2016 at 7:26 AM
> To: John McDowall 
> Cc: discuss , Na Zhu ,
> "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, Srilatha Tangirala

> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Apologies for being delayed on replying and in-line back as well
>
> Ryan
>
> John McDowall  wrote on 06/15/2016
> 05:58:35 PM:
>
> > From: John McDowall 
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Na Zhu , Srilatha Tangirala/San Francisco/
> > IBM@IBMUS, "OpenStack Development Mailing List (not for usage
> > questions)" , discuss
> > 
> > Date: 06/15/2016 05:58 PM
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> >
> > Ryan,
> >
> > In-line
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats 
> > Date: Tuesday, June 14, 2016 at 9:42 PM
> > To: John McDowall 
> > Cc: Na Zhu , Srilatha Tangirala  > >, "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>, discuss 
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> >
> > "discuss"  wrote on 06/14/2016
10:31:40 PM:
> >
> > > From: John McDowall 
> > > To: Na Zhu 
> > > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> > > Development Mailing List \(not for usage questions\)"  > > d...@lists.openstack.org>, discuss 
> > > Date: 06/14/2016 10:48 PM
> > > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > > [networking-sfc] SFC andOVN
> > > Sent by: "discuss" 
> > >
> > > Juno,
> > >
> > > It is a container for port-pair-groups and flow-classifier. I
> > > imagine there could be more the than one port-chain per switch. Also
> > > we may want to extend the model beyond a single lswitch
> >
> > I agree that there could be more than one port-chain per switch,
determined
> > by the flow classifier.
> >
> > What I'm confused by is:
> >
> > 1. Why are items only recorded in logical switches?  I would think
> > that I could also attach an SFC to a logical router - although I admit
> > that the current neutron model for ports doesn't really allow that
> > easily.  Couple that with the change of name from Logical_Port to
> > Logical_Switch_Port, and I'm left wondering if we aren't better off
> > with the following "weak" links instead:
> > -the Port_Chain includes the logical switch as an external_id
> > -each Port_Pair_Group includes the Port_Chain as an external_id
> > -each Port_Pair includes the PPG as an external_id
> > -each Logical_Switch_Port includes the PP as an external_id
> >
> > I *think* that *might* allow me (in the future) to attach a port chain
> > to a logical router by setting the logical router as an external_id and
> > using Logical_Router_Ports to make up the PPs...
> >
> > JED> If there are “port-chain” tables for switches and routers I
> > think I agree. Not sure how this is impacted by the type of VNF (see
> > the last email to Juno). I struggle a bit with imagining the flows.
>
> RM> Back in the day when we discussed this internally here, SFCs could
> RM> be inserted as BiW (which we do a good job with currently) and at
> RM> network boundaries (which I'm not sure how I could do with the
> RM> current model) - my router question is more one of leaving the
> RM> door open for the boundary case (sorry for the pun) in the future.
>
> JED> Lets leave the door open and see what we can do once we have
> the basic model working?
>
> > 2. I still don't see what Logical_Flow_Classifier is buying me that
> > ACL doesn't - I can codify all of the classifiers given in the match
> > criteria of an ACL entry and codify the first PPG of the SFC as
> > the action of the ACL entry...
> > JED> Flow classifiers do map to an ACL entry – just need additional
> > metadata, I.e. Action of the ACL and 

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[John McDowall]

Ryan,

In-line below.

Regards

John

From: Ryan Moats >
Date: Friday, June 17, 2016 at 7:35 AM
To: John McDowall 
>
Cc: Na Zhu >, Srilatha Tangirala 
>, "OpenStack Development 
Mailing List (not for usage questions)" 
>, 
discuss >
Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN


In-line below

"discuss" 
> wrote 
on 06/15/2016 05:51:20 PM:

> From: John McDowall 
> >
> To: Na Zhu >
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, discuss 
> >
> Date: 06/15/2016 05:51 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
> >
>
> Juno,
>
> Apologies - I see your issue now, also I have got nothing done today
> - got sucked into an all day meeting. I was thinking very much from
> a  ovs/ovn perspective and also my first prototype was very simple.
>
> So while in networking=sfc/ovn the port-cahin does not have a switch
> I think port-chain needs a lswitch context as that is where the
> port-chain table is created. Let me try and lay this out. I am not
> sure if I am getting this right but it is a starting point for
> discussion and comment by the community.
>
> The first thing is that there could be three different types of
> VNF's, L3, L2, and Bump in the Wire (BITW). I am not sure if it
> would be possible to mix and match these different types in a series
> of port-pair-groups. Also as a first phase I have been trying to
> remove the need for the VNF to participate in the service chain (or
> be aware of it). In addition I also wanted to remove the need for
> any "proxy" as documented in the NSH model, by moving a lot of the
> functionality to the ovn-northd.
>
> Mode 1: BITW
> Port-Pairs: The logical ports need to be on the same logical switch
> Port-pair-groups: They are made up of sets of port-pairs, until we
> see the load-balancing proposal for ovs/ovn not sure if port-pairs
> can be on different logical switches or not. This translates to a
> set of rules in the port-chain table that chains output ports of one
> VNF to the input port of the next VNF, until the last VNF when the
> traffic is forwarded to the final destination of the packet. If the
> port-chain is bi-directional then the rule set has to be implemented
> in reverse (many VNF's Firewalls, Load Balancers etc need to see
> both legs of the traffic).
> Flow-classifier: Is a set of rules that are set as an ACL rule with
> first logical port of the first pair in the first port-pair-group.
> Likewise if the port-chain is bi-directional then the rules have to
> be symmetric to steer the traffic in both directions.
> Port-chain: defined on the same logical switch as the first logical-
> source-port of the flow-classifier, as this is where the port-chain
> table is created and the rules for traffic steering are inserted.
> Mode 2: L2
>
> I think this would be similar to the BITH case but instead of
> steering by logical ports the steering would be done by VLAN tags.
> This would also mean that the VNFs would have to be aware of the
> steering rules and be able to manipulate VLAN tags.
>
> Mode 3: L3
>
> This would require the VNF's to be aware of the routing rules and
> set static routes/net hop rules for each step in the service chain.
>
> Modes 2 & 3 would require a much more sophisticated control plane to
> program both OVN and the VNFs.

[Snip to save BW]

I'm not so sure John.  I agree that OVN would have to know about the
VF type (BiW/L2/L3) and further that OVN would need to be told about
the appropriate L2/L3 "next port" information - either VLAN tags or
IP addresses, but once I have that, I think the actual vswitch
programming is fairly straightforward:  for L2, the vswitch is
programmed to use the VLAN tag to select the next PPG bucket and
for L3, the existing template for programming static routes can be
leveraged.

JED> I mentioned this in a reply to Cathy too, the issue I worry about is when 
the VNF is acting as a router or a switch. Then we have
JED> multiple actors that need to coordinate with each other. If we decide that 
VNFs must support BitW then there is not an issue.

Ryan
__

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[John McDowall]

Ryan,

See inline

Regards

John

From: Ryan Moats >
Date: Friday, June 17, 2016 at 7:26 AM
To: John McDowall 
>
Cc: discuss >, Na Zhu 
>, "OpenStack Development Mailing 
List (not for usage questions)" 
>, 
Srilatha Tangirala >
Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN


Apologies for being delayed on replying and in-line back as well

Ryan

John McDowall 
> wrote 
on 06/15/2016 05:58:35 PM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Na Zhu >, Srilatha 
> Tangirala/San Francisco/
> IBM@IBMUS, "OpenStack Development Mailing List (not for usage
> questions)" 
> >,
>  discuss
> >
> Date: 06/15/2016 05:58 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Ryan,
>
> In-line
>
> Regards
>
> John
>
> From: Ryan Moats >
> Date: Tuesday, June 14, 2016 at 9:42 PM
> To: John McDowall 
> >
> Cc: Na Zhu >, Srilatha Tangirala 
> 
> >, "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, 
> discuss >
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> "discuss" 
> > 
> wrote on 06/14/2016 10:31:40 PM:
>
> > From: John McDowall 
> > >
> > To: Na Zhu >
> > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> > Development Mailing List \(not for usage questions\)"  > d...@lists.openstack.org>, discuss 
> > >
> > Date: 06/14/2016 10:48 PM
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> > Sent by: "discuss" 
> > >
> >
> > Juno,
> >
> > It is a container for port-pair-groups and flow-classifier. I
> > imagine there could be more the than one port-chain per switch. Also
> > we may want to extend the model beyond a single lswitch
>
> I agree that there could be more than one port-chain per switch, determined
> by the flow classifier.
>
> What I'm confused by is:
>
> 1. Why are items only recorded in logical switches?  I would think
> that I could also attach an SFC to a logical router - although I admit
> that the current neutron model for ports doesn't really allow that
> easily.  Couple that with the change of name from Logical_Port to
> Logical_Switch_Port, and I'm left wondering if we aren't better off
> with the following "weak" links instead:
> -the Port_Chain includes the logical switch as an external_id
> -each Port_Pair_Group includes the Port_Chain as an external_id
> -each Port_Pair includes the PPG as an external_id
> -each Logical_Switch_Port includes the PP as an external_id
>
> I *think* that *might* allow me (in the future) to attach a port chain
> to a logical router by setting the logical router as an external_id and
> using Logical_Router_Ports to make up the PPs...
>
> JED> If there are “port-chain” tables for switches and routers I
> think I agree. Not sure how this is impacted by the type of VNF (see
> the last email to Juno). I struggle a bit with imagining the flows.

RM> Back in the day when we discussed this internally here, SFCs could
RM> be inserted as BiW (which we do a good job with currently) and at
RM> network boundaries (which I'm not sure how I could do with the
RM> current model) - my router question is more one of leaving the
RM> door open for the boundary case (sorry for the pun) in the future.

JED> Lets leave the door open and see what we can do once we have the basic 
model working?

> 2. I still don't see what Logical_Flow_Classifier is buying me that
> ACL doesn't - I can codify all of the classifiers given in the match
> criteria of an ACL entry and codify the first PPG of the SFC as
> the action of the ACL entry...
> JED> 

Re: [openstack-dev] [nova] Question about redundant API samples tests for microversions

[Andrew Laski]

On Fri, Jun 17, 2016, at 04:16 PM, Matt Riedemann wrote:
> I was reviewing this today:
> 
> https://review.openstack.org/#/c/326940/
> 
> And I said to myself, 'self, do we really need to subclass the API 
> samples functional tests for this microversion given this change doesn't 
> modify the request/response body, it's only adding paging support?'.
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/functional/api_sample_tests/test_hypervisors.py
> 
> The only change here is listing hypervisors, and being able to page on 
> those if the microversion is high enough. So the API samples don't 
> change at all, they are just running against a different microversion.
> 
> The same goes for the REST API unit tests really:
> 
> https://review.openstack.org/#/c/326940/6/nova/tests/unit/api/openstack/compute/test_hypervisors.py
> 
> I'm not sure if the test subclassing is just done like this for new 
> microversions because it's convenient or if it's because of regression 
> testing - knowing that we aren't changing a bunch of other REST methods 
> in the process, so the subclassed tests aren't testing anything 
> different from the microversion that came before them.
> 
> The thing I don't like about the test subclassing is all of the 
> redundant testing that goes on, and people might add tests to the parent 
> class not realizing it's subclassed and thus duplicating test cases with 
> no functional change.

I agree that the naive subclassing is wasteful. I would rather see tests
that purposely check the changes not just duplicate things at a
different microversion. If there's a concern about regressions I think a
better approach would be to have a check against 'latest' which would
catch accidental changes, not check unchanged request/reponses against
microversions where they aren't intended to change. For my own curiosity
I checked the timings and the duplicated tests took about 20 seconds to
run. That could quickly add up to the point where a significant amount
of time is spent on unnecessary testing.

> 
> Am I just having some Friday crazies? Ultimately this doesn't hurt 
> anything really but thought I'd ask.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Do we need a config option for use_usb_tablet/pointer_model?

[Matt Riedemann]

I was reviewing the last change in this blueprint series today:

https://review.openstack.org/#/c/174854/

And started to question why we even have a config option for this 
anymore. The blueprint didn't have a spec but there are some details in 
the description about the use cases:


https://blueprints.launchpad.net/nova/+spec/virt-configure-usb-tablet-from-image

From the code and help text for the option I realize that there is some 
per-compute enablement required for this to work (VNC or SPICE enabled 
and the SPICE agent disabled). But otherwise it seems totally 
image-specific, which is why the blueprint is adding support for 
calculating whether or not to enable USB support in the guest based on 
the image metadata properties.


But do we still need the configuration option then?

The tricky scenario I have in mind is I create my Windows instance on a 
host that has use_usb_table=True and I can use my USB pointer mouse and 
I'm happy, yay! Then that host goes under maintenance, the admin 
migrates it to another host that has use_usb_tablet=False and now I 
can't use my USB mouse anymore. I guess the chance of this happening are 
pretty slim given use_usb_tablet defaults to True.


However, in https://review.openstack.org/#/c/176242/ use_usb_table is 
deprecated in favor of the new 'pointer_model' config option which 
defaults to None, so it's not backward compatible with use_usb_tablet 
and when we remove use_usb_tablet as an option in Ocata, the default 
behavior has changed.


Anyway, my point is, why do we even need a config option for this at all 
if the image metadata can tell us what to do now?


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Grenade non-voting test results

[Jay Faulkner]

+1 lets get it voting. Feel free to add me as a reviewer to the project-config 
patch to make the change if you want me to vote officially :).


Thanks,

Jay


From: Villalovos, John L 
Sent: Friday, June 17, 2016 10:49:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ironic] Grenade non-voting test results

TL;DR: In my opinion Grenade job is performing reliably.

Using the table at:
http://ci-watch.tintri.com/project?project=ironic=7+days
Note: Unable to extract the data out of the web page to do more thorough data 
evaluation.

The Grenade job appears to be performing successfully. On Thursday evening it 
may appear that grenade was failing without reason, but the cause is: 
https://bugs.launchpad.net/ironic/+bug/1590139

This bug was fixed in master, but the patch to stable/mitaka had not yet 
landed. And since Grenade runs tests on stable/mitaka it continued to fail. 
This morning the patch to fix stable/mitaka landed and the Grenade job is 
passing again.

Unfortunately https://bugs.launchpad.net/ironic/+bug/1590139 (which started 
around 6-June-2016) would cause random Ironic jobs to fail, as only some jobs 
would get sent to the new Zuul builders. Any job to the new Zuul builders would 
fail.  So some jobs would pass and some fail for the same patch.

I did my best to take all of that into account and in my opinion the grenade 
job is performing reliably. If I can figure out how to extract better 
statistics I will update this email.

Please let me know if you have questions or if I'm wrong :)

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [manila]: questions on update-access() changes

[Ben Swartzlander]

Ramana, I think your questions got answered in a channel discussion last 
week, but I just wanted to double check that you weren't still expecting 
any answers here. If you were, please reply and we'll keep this thread going.



On June 2, 2016 9:30:39 AM Ramana Raja  wrote:


Hi,

There are a few changes that seem to be lined up for Newton to make manila's
share access control, update_access(), workflow better [1] --
reduce races in DB updates, avoid non-atomic state transitions, and
possibly enable the workflow fit in a HA active-active manila
configuration (if not already possible).

The proposed changes ...

a) Switch back to per rule access state (from per share access state) to
   avoid non-atomic state transition.

   Understood problem, but no spec or BP yet.


b) Use Tooz [2] (with Zookeeper?) for distributed lock management [3]
   in the access control workflow.

   Still under investigation and for now fits the share replication workflow 
[4].


c) Allow drivers to update DB models in a restricted manner (only certain
   fields can be updated by a driver API).

   This topic is being actively discussed in the community, and there should be
   a consensus soon on figuring out the right approach, following which there
   might be a BP/spec targeted for Newton.


Besides these changes, there's a update_access() change that I'd like to revive
(started in Mitaka), storing access keys (auth secrets) generated by a storage
backend when providing share access, i.e.  during update_access(), in the
``share_access_map`` table [5]. This change as you might have figured is a
smaller and a simpler change than the rest, but seems to depend on the 
approaches

that might be adopted by a) and c).

For now, I'm thinking of allowing a driver's update access()  to return a
dictionary of {access_id: access_key, ...} to (ShareManager)access_helper's
update_access(), which would then update the DB iteratively with access_key
per access_id. Would this approach be valid with changes a) and c) in
Newton? change a) would make the driver report access status per rule via
the access_helper, during which an 'access_key' can also be returned,
change c) might allow the driver to directly update the `access_key` in the
DB.

For now, should I proceed with implementing the approach currently outlined
in my spec [5], have the driver's update_access() return a dictionary of
{access_id: access_key, ...} or wait for approaches for changes a) and c)
to be outlined better?

Thanks,
Ramana

[1] https://etherpad.openstack.org/p/newton-manila-update-access

[2] 
https://blueprints.launchpad.net/openstack/?searchtext=distributed-locking-with-tooz


[3] https://review.openstack.org/#/c/209661/38/specs/chronicles-of-a-dlm.rst

[4] https://review.openstack.org/#/c/318336/

[5] https://review.openstack.org/#/c/322971/
http://lists.openstack.org/pipermail/openstack-dev/2015-October/077602.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Question about redundant API samples tests for microversions

[Matt Riedemann]

I was reviewing this today:

https://review.openstack.org/#/c/326940/

And I said to myself, 'self, do we really need to subclass the API 
samples functional tests for this microversion given this change doesn't 
modify the request/response body, it's only adding paging support?'.


https://review.openstack.org/#/c/326940/6/nova/tests/functional/api_sample_tests/test_hypervisors.py

The only change here is listing hypervisors, and being able to page on 
those if the microversion is high enough. So the API samples don't 
change at all, they are just running against a different microversion.


The same goes for the REST API unit tests really:

https://review.openstack.org/#/c/326940/6/nova/tests/unit/api/openstack/compute/test_hypervisors.py

I'm not sure if the test subclassing is just done like this for new 
microversions because it's convenient or if it's because of regression 
testing - knowing that we aren't changing a bunch of other REST methods 
in the process, so the subclassed tests aren't testing anything 
different from the microversion that came before them.


The thing I don't like about the test subclassing is all of the 
redundant testing that goes on, and people might add tests to the parent 
class not realizing it's subclassed and thus duplicating test cases with 
no functional change.


Am I just having some Friday crazies? Ultimately this doesn't hurt 
anything really but thought I'd ask.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Re: [fuel] [kolla] Containerized OpenStack on Kubernetes experimental project proposal

[Steven Dake (stdake)]

On 6/17/16, 11:38 AM, "Jeremy Stanley"  wrote:

>On 2016-06-17 18:04:25 + (+), Steven Dake (stdake) wrote:
>[...]
>> The technical committee has set precedent that competition is
>> acceptable in the "outer ring" of services (i.e. The TC doesn't
>> want Big Tent projects competing with nova for example but
>> deployment is fair game). I agree with that decision completely.
>> However, I can't help but wonder wouldn't this require at-least a
>> Fuel mission change to the governance repository?
>[...]
>
>His original message explained it:
>
>"As for the governance - Fuel CCP will be just a separated
>experimental project under OpenStack namespace with own specs
>and core team. The nearest example of the same governance is 3rd
>party Fuel plugin done not by Mirantis."
>
>So basically it's not officially part of Fuel, and isn't (currently)
>even trying to officially be part of OpenStack.
>--

Jeremy

Cool thanks for the info.

Sergey please disregard the commentary about mission statement - I
apologize for misunderstanding your original intent.

Regards
-steve

> 
>Jeremy Stanley
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

[Robert Collins]

Sure. +1

On 17 June 2016 at 02:44, Davanum Srinivas  wrote:
> Folks,
>
> At Austin the Release Management team reached a consensus to spin off
> with some new volunteers to take care of the requirements process and
> repository [1]. The following folks showed up and worked with me on
> getting familiar with the issues/problems/tasks (see [1] and [2]) and
> help with the day to day work.
>
> Matthew Thode (prometheanfire)
> Dirk Mueller (dirk)
> Swapnil Kulkarni (coolsvap)
> Tony Breeds (tonyb)
> Thomas Bechtold (tbechtold)
>
> So, please cast your VOTE to grant them +2/core rights on the
> requirements repository and keep up the good work w.r.t speeding up
> reviews, making sure new requirements don't break etc.
>
> Also, please note that Thierry has been happy enough with our work to
> step down from core responsibilities :) Many thanks Thierry for
> helping with this effort and guidance. I'll make all the add/remove to
> the requirements-core team when this VOTE passes.
>
> Thanks,
> Dims
>
> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
> [2] https://etherpad.openstack.org/p/requirements-tasks
> [3] https://etherpad.openstack.org/p/requirements-cruft
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

[Sean M. Collins]

Doesn't look like anyone sets it. I don't see any references to it in
the provisioning tools (puppet, ansible, salt).

http://codesearch.openstack.org/?q=ipam_driver=nope==

So probably only very advanced users have done anything with it since
it would require manual configuration?
-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] provider networks

[Matt Kassawara]

Provider networks should operate the same whether using the conventional L3
agent (q-l3) or native L3 support in OVN. Provider networks only operate at
layer-2 and rely on a physical router on the same layer-2 segment to
provide layer-3 services such as a gateway.

On Fri, Jun 17, 2016 at 12:37 PM, Murali R  wrote:

> I think for provider networks we have to disable OVN_L3. Because devstack
> setup for neutron is creating a default router in the standard setup and
> conflicts with external router.
>
>
> On Fri, Jun 17, 2016 at 10:57 AM, Ryan Moats  wrote:
>
>> Murali R  wrote on 06/17/2016 12:33:09 PM:
>>
>> > From: Murali R 
>> > To: Ryan Moats/Omaha/IBM@IBMUS
>> > Cc: Ben Pfaff , discuss 
>> > Date: 06/17/2016 12:33 PM
>> > Subject: Re: [ovs-discuss] [ovn] provider networks
>> >
>> > > Your question makes me think that you are using provider networks
>>
>> > > in a way different from I have used them
>> >
>> > Actually it is standard
>> > Q_USE_PROVIDER_NETWORKING=True
>> > PHYSICAL_NETWORK=providernet
>> > PROVIDER_NETWORK_TYPE=flat
>> > OVS_PHYSICAL_BRIDGE=br-provider
>> > PROVIDER_SUBNET_NAME=provider-subnet
>> > FIXED_RANGE=10.145.253.0/24
>> > NETWORK_GATEWAY=10.145.253.1
>> > ALLOCATION_POOL=start=10.145.253.111,end=10.145.253.242
>> >
>> > So earlier, probably the full l3 support wasn't there. I made
>> > changes for logical flow additions in my own repo and use it for
>> > testing. I had to do a big merge for l3 extensions last night
>> > because networking-ovn eas expecting some idl extensions in new
>> updates.
>> >
>> > The setup now creates a logical router in OVN and assigns the
>> > gateway address given above. The gateway should not be used to
>> > allocate address for OVN router.
>> >
>> > If I create another private network, add a new router attach it to
>> > public network created, the traffic is hitting my external company
>> > gateway all the way out. Not sure what is happening. Can I just
>> > delete the default router1 that the devstack setup created? Looks
>> > like I may have to do some manual configs to get this setup working.
>> > Or should I disable OVN_L3 in devstack?
>>
>> I'm dropping the openvswitch discuss list and adding the openstack
>> dev list because this is very much now questions for that channel.
>>
>> Right now, my test cloud is in a state where I can't answer your
>> question directly, but my memory is that a router should not be
>> created and if it is, that would be a bug against something...
>>
>> Ryan
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

[Hongbin Lu]

Ricardo,

Thanks for sharing. It is good to hear that Magnum works well with a 200 nodes 
cluster.

Best regards,
Hongbin

> -Original Message-
> From: Ricardo Rocha [mailto:rocha.po...@gmail.com]
> Sent: June-17-16 11:14 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [magnum] 2 million requests / sec, 100s of
> nodes
> 
> Hi.
> 
> Just thought the Magnum team would be happy to hear :)
> 
> We had access to some hardware the last couple days, and tried some
> tests with Magnum and Kubernetes - following an original blog post from
> the kubernetes team.
> 
> Got a 200 node kubernetes bay (800 cores) reaching 2 million requests /
> sec.
> 
> Check here for some details:
> https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-
> kubernetes-2-million.html
> 
> We'll try bigger in a couple weeks, also using the Rally work from
> Winnie, Ton and Spyros to see where it breaks. Already identified a
> couple issues, will add bugs or push patches for those. If you have
> ideas or suggestions for the next tests let us know.
> 
> Magnum is looking pretty good!
> 
> Cheers,
> Ricardo
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Re: [fuel] [kolla] Containerized OpenStack on Kubernetes experimental project proposal

[Jeremy Stanley]

On 2016-06-17 18:04:25 + (+), Steven Dake (stdake) wrote:
[...]
> The technical committee has set precedent that competition is
> acceptable in the "outer ring" of services (i.e. The TC doesn't
> want Big Tent projects competing with nova for example but
> deployment is fair game). I agree with that decision completely.
> However, I can't help but wonder wouldn't this require at-least a
> Fuel mission change to the governance repository?
[...]

His original message explained it:

"As for the governance - Fuel CCP will be just a separated
experimental project under OpenStack namespace with own specs
and core team. The nearest example of the same governance is 3rd
party Fuel plugin done not by Mirantis."

So basically it's not officially part of Fuel, and isn't (currently)
even trying to officially be part of OpenStack.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] provider networks

[Murali R]

I think for provider networks we have to disable OVN_L3. Because devstack
setup for neutron is creating a default router in the standard setup and
conflicts with external router.


On Fri, Jun 17, 2016 at 10:57 AM, Ryan Moats  wrote:

> Murali R  wrote on 06/17/2016 12:33:09 PM:
>
> > From: Murali R 
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Ben Pfaff , discuss 
> > Date: 06/17/2016 12:33 PM
> > Subject: Re: [ovs-discuss] [ovn] provider networks
> >
> > > Your question makes me think that you are using provider networks
>
> > > in a way different from I have used them
> >
> > Actually it is standard
> > Q_USE_PROVIDER_NETWORKING=True
> > PHYSICAL_NETWORK=providernet
> > PROVIDER_NETWORK_TYPE=flat
> > OVS_PHYSICAL_BRIDGE=br-provider
> > PROVIDER_SUBNET_NAME=provider-subnet
> > FIXED_RANGE=10.145.253.0/24
> > NETWORK_GATEWAY=10.145.253.1
> > ALLOCATION_POOL=start=10.145.253.111,end=10.145.253.242
> >
> > So earlier, probably the full l3 support wasn't there. I made
> > changes for logical flow additions in my own repo and use it for
> > testing. I had to do a big merge for l3 extensions last night
> > because networking-ovn eas expecting some idl extensions in new updates.
> >
> > The setup now creates a logical router in OVN and assigns the
> > gateway address given above. The gateway should not be used to
> > allocate address for OVN router.
> >
> > If I create another private network, add a new router attach it to
> > public network created, the traffic is hitting my external company
> > gateway all the way out. Not sure what is happening. Can I just
> > delete the default router1 that the devstack setup created? Looks
> > like I may have to do some manual configs to get this setup working.
> > Or should I disable OVN_L3 in devstack?
>
> I'm dropping the openvswitch discuss list and adding the openstack
> dev list because this is very much now questions for that channel.
>
> Right now, my test cloud is in a state where I can't answer your
> question directly, but my memory is that a router should not be
> created and if it is, that would be a bug against something...
>
> Ryan
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Re: [fuel] [kolla] Containerized OpenStack on Kubernetes experimental project proposal

[Fox, Kevin M]

Ah. I didn't make it that far through the spec. Thanks for pointing that out.

It seems premature to me though to start proposing a new project when 
discussion of reusing of an existing project has just started. Only since 
yesterday as far as I can gather.

Yes, if there ends up being a difference between project goals that just can't 
be resolved, then a new project is called for. I don't think we're there yet 
though.

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Friday, June 17, 2016 11:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tc] Re: [fuel] [kolla] Containerized OpenStack on 
Kubernetes experimental project proposal

Kevin,

Why have one snowflake when you can have two?

Snarky comments aside :) Sergey did answer that question in the specification 
he linked (rest quoted):
"

Alternatives


This spec is actually describes an alternative experimental approach for
OpenStack deployment, but there are few questions to answer about alternatives.


1. Why not use Kolla's container images?
   There is a set of fundamental requirements for container images that is
   currently not covered or controversial to some Kolla principles. This list
   will be maintained and discussed with Kolla community under the following
   specification published to Kolla project:
   I18b319cb796192a1e61ecd516a485dc82d52652f

2. Why not contribute to Kolla-Kubernetes?
   It's based on the Kolla container images, while we need to solve list of
   requirements described in I18b319cb796192a1e61ecd516a485dc82d52652f
"

Sergey,

The technical committee has set precedent that competition is acceptable in the 
"outer ring" of services (i.e. The TC doesn't want Big Tent projects competing 
with nova for example but deployment is fair game).  I agree with that decision 
completely.  However, I can't help but wonder wouldn't this require at-least a 
Fuel mission change to the governance repository?  When (correct me if I am 
wrong) Kuryr started to encroach upon the mission of Magnum, Kuryr had to 
change their mission statement.  Now both mission statements overlap which is 
an unfortunate aspect of healthy growing projects.

The mission statement of Kolla is:
Kolla provides production-ready containers and deployment tools for operating 
OpenStack clouds.

That specification is a direct translation of Kolla's mission statement into 
more lines of text.

I am ok with competition, but please make and meet your commitments in the 
governance repository so folks in the community understand what each project is 
about.

Regards,
-steve



From: "Fox, Kevin M" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, June 17, 2016 at 9:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [fuel] [kolla] Containerized OpenStack on 
Kubernetes experimental project proposal

Um, why try and reimplement Kolla from scratch rather then use the existing 
Kolla system and make it available via Fuel?

There is already a project do deploy OpenStack containers in Kubernetes:
http://docs.openstack.org/developer/kolla-kubernetes/
https://review.openstack.org/#/c/304182/

Lets work together rather then creating more projects.

Thanks,
Kevin

From: Sergey Lukjanov [slukja...@mirantis.com]
Sent: Friday, June 17, 2016 6:56 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [fuel] Containerized OpenStack on Kubernetes 
experimental project proposal

Hi,

I'd like to share proposal on running the experimental project under the Fuel
umbrella for running OpenStack in containers on top of Kubernetes,
codename "Fuel CCP".

Here is a specification in Fuel: https://review.openstack.org/331139

CCP is the initiative to package OpenStack services in the containers and
use standard container management framework to run and manage them. It
includes following areas, but not limited to them:

* OpenStack containerization and container image building tooling
* CI/CD to produce properly layered and versioned containers for the supported
  stable and current master branches of OpenStack projects
* OpenStack deployment in containers on top of Kubernetes with HA for OpenStack
  services and their dependencies (e.g. MySQL, RabbitMQ, etc.)
* Tooling for deploying and operating OpenStack clusters with support for the
  upgrades, patching, scaling and changing configuration

As for the governance - Fuel CCP will be just a separated experimental project
under OpenStack namespace with own specs and core team. The nearest example of
the same governance is 3rd party Fuel plugin done not by Mirantis.

[openstack-dev] [tc] Re: [fuel] [kolla] Containerized OpenStack on Kubernetes experimental project proposal

[Steven Dake (stdake)]

Kevin,

Why have one snowflake when you can have two?

Snarky comments aside :) Sergey did answer that question in the specification 
he linked (rest quoted):
"

Alternatives


This spec is actually describes an alternative experimental approach for
OpenStack deployment, but there are few questions to answer about alternatives.


1. Why not use Kolla's container images?
   There is a set of fundamental requirements for container images that is
   currently not covered or controversial to some Kolla principles. This list
   will be maintained and discussed with Kolla community under the following
   specification published to Kolla project:
   I18b319cb796192a1e61ecd516a485dc82d52652f

2. Why not contribute to Kolla-Kubernetes?
   It's based on the Kolla container images, while we need to solve list of
   requirements described in I18b319cb796192a1e61ecd516a485dc82d52652f
"

Sergey,

The technical committee has set precedent that competition is acceptable in the 
"outer ring" of services (i.e. The TC doesn't want Big Tent projects competing 
with nova for example but deployment is fair game).  I agree with that decision 
completely.  However, I can't help but wonder wouldn't this require at-least a 
Fuel mission change to the governance repository?  When (correct me if I am 
wrong) Kuryr started to encroach upon the mission of Magnum, Kuryr had to 
change their mission statement.  Now both mission statements overlap which is 
an unfortunate aspect of healthy growing projects.

The mission statement of Kolla is:
Kolla provides production-ready containers and deployment tools for operating 
OpenStack clouds.

That specification is a direct translation of Kolla's mission statement into 
more lines of text.

I am ok with competition, but please make and meet your commitments in the 
governance repository so folks in the community understand what each project is 
about.

Regards,
-steve



From: "Fox, Kevin M" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, June 17, 2016 at 9:11 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [fuel] [kolla] Containerized OpenStack on 
Kubernetes experimental project proposal

Um, why try and reimplement Kolla from scratch rather then use the existing 
Kolla system and make it available via Fuel?

There is already a project do deploy OpenStack containers in Kubernetes:
http://docs.openstack.org/developer/kolla-kubernetes/
https://review.openstack.org/#/c/304182/

Lets work together rather then creating more projects.

Thanks,
Kevin

From: Sergey Lukjanov [slukja...@mirantis.com]
Sent: Friday, June 17, 2016 6:56 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [fuel] Containerized OpenStack on Kubernetes 
experimental project proposal

Hi,

I'd like to share proposal on running the experimental project under the Fuel
umbrella for running OpenStack in containers on top of Kubernetes,
codename "Fuel CCP".

Here is a specification in Fuel: https://review.openstack.org/331139

CCP is the initiative to package OpenStack services in the containers and
use standard container management framework to run and manage them. It
includes following areas, but not limited to them:

* OpenStack containerization and container image building tooling
* CI/CD to produce properly layered and versioned containers for the supported
  stable and current master branches of OpenStack projects
* OpenStack deployment in containers on top of Kubernetes with HA for OpenStack
  services and their dependencies (e.g. MySQL, RabbitMQ, etc.)
* Tooling for deploying and operating OpenStack clusters with support for the
  upgrades, patching, scaling and changing configuration

As for the governance - Fuel CCP will be just a separated experimental project
under OpenStack namespace with own specs and core team. The nearest example of
the same governance is 3rd party Fuel plugin done not by Mirantis.

Thanks.

--
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [networking-ovn] provider networks

[Ryan Moats]

Murali R  wrote on 06/17/2016 12:33:09 PM:

> From: Murali R 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff , discuss 
> Date: 06/17/2016 12:33 PM
> Subject: Re: [ovs-discuss] [ovn] provider networks
>
> > Your question makes me think that you are using provider networks
> > in a way different from I have used them
>
> Actually it is standard
> Q_USE_PROVIDER_NETWORKING=True
> PHYSICAL_NETWORK=providernet
> PROVIDER_NETWORK_TYPE=flat
> OVS_PHYSICAL_BRIDGE=br-provider
> PROVIDER_SUBNET_NAME=provider-subnet
> FIXED_RANGE=10.145.253.0/24
> NETWORK_GATEWAY=10.145.253.1
> ALLOCATION_POOL=start=10.145.253.111,end=10.145.253.242
>
> So earlier, probably the full l3 support wasn't there. I made
> changes for logical flow additions in my own repo and use it for
> testing. I had to do a big merge for l3 extensions last night
> because networking-ovn eas expecting some idl extensions in new updates.
>
> The setup now creates a logical router in OVN and assigns the
> gateway address given above. The gateway should not be used to
> allocate address for OVN router.
>
> If I create another private network, add a new router attach it to
> public network created, the traffic is hitting my external company
> gateway all the way out. Not sure what is happening. Can I just
> delete the default router1 that the devstack setup created? Looks
> like I may have to do some manual configs to get this setup working.
> Or should I disable OVN_L3 in devstack?

I'm dropping the openvswitch discuss list and adding the openstack
dev list because this is very much now questions for that channel.

Right now, my test cloud is in a state where I can't answer your
question directly, but my memory is that a router should not be
created and if it is, that would be a bug against something...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] Grenade non-voting test results

[Villalovos, John L]

TL;DR: In my opinion Grenade job is performing reliably.

Using the table at:
http://ci-watch.tintri.com/project?project=ironic=7+days
Note: Unable to extract the data out of the web page to do more thorough data 
evaluation.

The Grenade job appears to be performing successfully. On Thursday evening it 
may appear that grenade was failing without reason, but the cause is: 
https://bugs.launchpad.net/ironic/+bug/1590139

This bug was fixed in master, but the patch to stable/mitaka had not yet 
landed. And since Grenade runs tests on stable/mitaka it continued to fail. 
This morning the patch to fix stable/mitaka landed and the Grenade job is 
passing again.

Unfortunately https://bugs.launchpad.net/ironic/+bug/1590139 (which started 
around 6-June-2016) would cause random Ironic jobs to fail, as only some jobs 
would get sent to the new Zuul builders. Any job to the new Zuul builders would 
fail.  So some jobs would pass and some fail for the same patch.

I did my best to take all of that into account and in my opinion the grenade 
job is performing reliably. If I can figure out how to extract better 
statistics I will update this email.

Please let me know if you have questions or if I'm wrong :)

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[HADDLETON, Robert W (Bob)]

+1.  Kanagaraj will be a great addition to the team.

Bob

On 6/16/2016 1:45 PM, Karthik Natarajan wrote:


+1. Thanks Kanagaraj for making such a great impact during the Newton 
cycle.


*From:*Sripriya Seetharam [mailto:ssee...@brocade.com]
*Sent:* Thursday, June 16, 2016 10:35 AM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Subject:* Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam 
to Tacker core team


+1

-Sripriya

*From:*Sridhar Ramaswamy [mailto:sric...@gmail.com]
*Sent:* Wednesday, June 15, 2016 6:32 PM
*To:* OpenStack Development Mailing List (not for usage questions) 
>
*Subject:* [openstack-dev] [tacker] Proposing Kanagaraj Manickam to 
Tacker core team


Tackers,

It gives me great pleasure to propose Kanagaraj Manickam to join the 
Tacker core team. In a short time, Kanagaraj has grown into a key 
member of the Tacker team. His enthusiasm and dedication to get Tacker 
code base on par with other leading OpenStack projects is very much 
appreciated. He is already working on two important specs in Newton 
cycle and many more fixes and RFEs [1]. Kanagaraj is also a core 
member in the Heat project and this lends well as we heavily use Heat 
for many Tacker features.


Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks 





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


<>__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Proposing two new cores

[Julia Kreger]

On Thu, Jun 16, 2016 at 11:12 AM, Jim Rollenhagen 
wrote:

> Hi all,
>
> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
> ironic-core team.
>
>
+2 to both. :)

-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

[Kumari, Madhuri]

Hi Ricardo,

Thanks for sharing it. Result seems great and we will surely try to fix the 
issue.

Cheers!

Regards,
Madhuri

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com] 
Sent: Friday, June 17, 2016 8:44 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

Hi.

Just thought the Magnum team would be happy to hear :)

We had access to some hardware the last couple days, and tried some tests with 
Magnum and Kubernetes - following an original blog post from the kubernetes 
team.

Got a 200 node kubernetes bay (800 cores) reaching 2 million requests / sec.

Check here for some details:
https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html

We'll try bigger in a couple weeks, also using the Rally work from Winnie, Ton 
and Spyros to see where it breaks. Already identified a couple issues, will add 
bugs or push patches for those. If you have ideas or suggestions for the next 
tests let us know.

Magnum is looking pretty good!

Cheers,
Ricardo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Version header for OpenStack microversion support

[Ed Leafe]

On Jun 17, 2016, at 11:29 AM, Henry Nash  wrote:

> We are currently in the process of implementing microversion support in 
> keystone - and are obviously trying to follow the cross-projec spec for this 
> (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html).
>  
> 
> One thing I noticed was that the header specified in this spec is of the form:
> 
> OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> 
> for example:
> 
> OpenStack-API-Version: identity 3.7
> 
> However, from what i can see of the current implementations I have seen of 
> microversioning in OpenStack (Nova, Manilla), they use service-specific 
> headers, e.g.
> 
> X-OpenStack-Nova-API-Version: 2.12
> 
> My question is whether there a plan to converge on the generalized header 
> format….or are we keep with the service-specific headers? I’d obviously like 
> to implement the correct one for keystone.

Yes, the plan is to converge on the more generic headers. The Nova headers 
(don’t know about Manilla) pre-date the API WG spec, and were the motivation 
for development of that spec. We’ve even made it possible to accept both header 
formats [0] until things can be migrated to the recommended format.

[0] https://review.openstack.org/#/c/300077/

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Version header for OpenStack microversion support

[Henry Nash]

Hi

We are currently in the process of implementing microversion support in 
keystone - and are obviously trying to follow the cross-projec spec for this 
(http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
 
).
 

One thing I noticed was that the header specified in this spec is of the form:

OpenStack-API-Version: [SERVICE_TYPE] [X,Y]

for example:

OpenStack-API-Version: identity 3.7

However, from what i can see of the current implementations I have seen of 
microversioning in OpenStack (Nova, Manilla), they use service-specific 
headers, e.g.

X-OpenStack-Nova-API-Version: 2.12

My question is whether there a plan to converge on the generalized header 
format….or are we keep with the service-specific headers? I’d obviously like to 
implement the correct one for keystone.

Thanks

Henry





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][scheduler] Next Scheduler Sub-team Meeting: Monday June 20 at @1400 UTC

[Ed Leafe]

The meeting will be held in #openstack-meeting-alt at 1400 UTC.

We’ll be discussing the state of reviews and specs as in previous meetings. If 
you have something in particular that you’d like to make sure we discuss, 
please add it to the agenda:

https://wiki.openstack.org/wiki/Meetings/NovaScheduler


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Proposing two new cores

[Chris K]

Big +2 for both here.

-Chris

On Thu, Jun 16, 2016 at 8:12 AM, Jim Rollenhagen 
wrote:

> Hi all,
>
> I'd like to propose Jay Faulkner (JayF) and Sam Betts (sambetts) for the
> ironic-core team.
>
> Jay has been in the community as long as I have, has been IPA and
> ironic-specs core for quite some time. His background is operations, and
> he's getting good with Python. He's given great reviews for quite a
> while now, and the number is steadily increasing. I think it's a
> no-brainer.
>
> Sam has been in the ironic community for quite some time as well, with
> close ties to the neutron community as well. His background seems to be
> in networking, he's got great python skills as well. His reviews are
> super useful. He doesn't have quite as many as some people, but they are
> always thoughtful, and he often catches things others don't. I do hope
> to see more of his reviews.
>
> Both Sam and Jay are to the point where I consider their +1 or -1 as
> highly as any other core, so I think it's past time to allow them to +2
> as well.
>
> Current cores, please reply with your vote.
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] The Magnum Midcycle

[Ed Leafe]

On Jun 14, 2016, at 3:37 PM, Anita Kuno  wrote:
> 
> What other projects would make sense for you to host mid-cycles for
> should the opportunity arise? I can keep my ears open.

Nova! Nova! Nova!


-- Ed Leafe
(really wants to see the LHC!)





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Chris Dent]

On Fri, 17 Jun 2016, Sylvain Bauza wrote:

In the review, you explain why you don't trust Routes and I respect that. 
That said, are those issues logged as real problems for our API consumers, 
which are mostly client libraries that we own and other projects we know, 
like Horizon ?


The implication of your question here is that it is okay to do HTTP
incorrectly if people don't report problems with that lack of
correctness?

If that is a problem for those, is there something we could improve, instead 
of just getting rid of it ?


When I found the initial problem with Routes, it was because I was
doing some intial nova testing (with gabbi-tempest[1]) and
discovered it wasn't returning a 405 when it should. I made a bug

https://bugs.launchpad.net/nova/+bug/1567970

and tried to fix it but Routes fought me. If someone else can figure
it out more power to them.

In any case selector's behavior in this case is just better. Better
is better, right?


--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Dean Troyer]

On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza  wrote:
>
> In the review, you explain why you don't trust Routes and I respect that.
> That said, are those issues logged as real problems for our API consumers,
> which are mostly client libraries that we own and other projects we know,
> like Horizon ?
>

I feel a bit compelled to say that the assumption that the API consumers
are mostly 'our code' is a faulty one and not true.  Just within the
collection of client projects in the openstack/ repo namespace, there are
at least 4 different codebases talking to compute endpoints.

I'm not picking on you Sylvain, this is just something that I think needs
periodic reinforcement among our developer community.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] [kolla] Containerized OpenStack on Kubernetes experimental project proposal

[Fox, Kevin M]

Um, why try and reimplement Kolla from scratch rather then use the existing 
Kolla system and make it available via Fuel?

There is already a project do deploy OpenStack containers in Kubernetes:
http://docs.openstack.org/developer/kolla-kubernetes/
https://review.openstack.org/#/c/304182/

Lets work together rather then creating more projects.

Thanks,
Kevin

From: Sergey Lukjanov [slukja...@mirantis.com]
Sent: Friday, June 17, 2016 6:56 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [fuel] Containerized OpenStack on Kubernetes 
experimental project proposal

Hi,

I'd like to share proposal on running the experimental project under the Fuel
umbrella for running OpenStack in containers on top of Kubernetes,
codename "Fuel CCP".

Here is a specification in Fuel: https://review.openstack.org/331139

CCP is the initiative to package OpenStack services in the containers and
use standard container management framework to run and manage them. It
includes following areas, but not limited to them:

* OpenStack containerization and container image building tooling
* CI/CD to produce properly layered and versioned containers for the supported
  stable and current master branches of OpenStack projects
* OpenStack deployment in containers on top of Kubernetes with HA for OpenStack
  services and their dependencies (e.g. MySQL, RabbitMQ, etc.)
* Tooling for deploying and operating OpenStack clusters with support for the
  upgrades, patching, scaling and changing configuration

As for the governance - Fuel CCP will be just a separated experimental project
under OpenStack namespace with own specs and core team. The nearest example of
the same governance is 3rd party Fuel plugin done not by Mirantis.

Thanks.

--
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

[Ton Ngo]

Thanks Ricardo for sharing the data, this is really encouraging!
Ton,



From:   Ricardo Rocha 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   06/17/2016 08:16 AM
Subject:[openstack-dev]  [magnum] 2 million requests / sec, 100s of
nodes



Hi.

Just thought the Magnum team would be happy to hear :)

We had access to some hardware the last couple days, and tried some
tests with Magnum and Kubernetes - following an original blog post
from the kubernetes team.

Got a 200 node kubernetes bay (800 cores) reaching 2 million requests /
sec.

Check here for some details:
https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html


We'll try bigger in a couple weeks, also using the Rally work from
Winnie, Ton and Spyros to see where it breaks. Already identified a
couple issues, will add bugs or push patches for those. If you have
ideas or suggestions for the next tests let us know.

Magnum is looking pretty good!

Cheers,
Ricardo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] [murano-apps] Murano apps core changes

[Kirill Zaitsev]

Done, 

Sergey, feel free to add whoever you consider necessary in the group.

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 14 June 2016 at 14:21:18, Kirill Zaitsev (kzait...@mirantis.com) wrote:

Last week a patch [1] has been landed, that added murano-apps-core group, 
responsible for murano-apps repositories. Right now this group only includes 
murano-core. As a continuation of transition of responsibilities for 
murano-apps (started here [2]) I’m going to add Sergey Kraynev, who is leading 
the murano-apps separation initiative and allow him to nominate/add members to 
the team.

There is also one person, whom I would like to nominate for murano-apps-core 
myself — Dmytro Dovbii. Of all the murano team he has one of the greatest 
expertise with murano apps, and his contribution to their development and 
support is hard to underestimate [3]. I believe, that Dmytro would make a good 
foundation for the murano-apps-core team.

If there are no objections to these steps — I’m going to implement them by the 
end of this week.

[1] https://review.openstack.org/#/c/323340/ 
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-May/096268.html 
[3] http://stackalytics.com/?release=all=commits=murano-apps 

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Invitation to join Hangzhou Bug Smash

[Anita Kuno]

On 06/17/2016 12:00 AM, Wang, Shane wrote:
> Anita, sorry about replying to you slowly. Because we are a committee from a 
> couple of companies, and need discussion, which causes slowness.
> I am not the only decision maker. Thanks Anita;)
> 
> Regards.
> --
> Shane

No apology necessary, thank you Shane. You are doing a wonderful job
coordinating the event and if there is fault it is mine for not
following the rules.

Take all the time you need and rest assured I am fine if the response is
no. The decision is yours and your group's.

Thanks for your consideration,
Anita.


> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info] 
> Sent: Friday, June 17, 2016 7:18 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
> 
> On 06/16/2016 07:03 PM, Matt Riedemann wrote:
>> On 6/14/2016 9:03 PM, Anita Kuno wrote:
>>>
>>> I'll reply in private first because I am a core reviewer on the 
>>> project-config repo, which was not mentioned in your list but you 
>>> might consider useful to you at the bug smash nonetheless.
>>>
>>> Let me know if you would like me to attend and I'll reply in public, 
>>> if not no worries.
>>>
>>> Thank you,
>>> Anita
>>>
>>> _
>>> _
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Busted!
>>
> Yeah, I know. I was tired and wasn't paying attention to the to: field.
> Good thing I pretend like everything I say in private is public anyway.
> 
> Shane and folks are still welcome to tell me no, I didn't want them to feel 
> obliged and I still don't. Even if I fail at private.
> 
> Thanks Matt :)
> Anita.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Chris Dent]

On Fri, 17 Jun 2016, Andrey Volkov wrote:


IMHO selector is too young in terms of version (0.1) and too old in
terms of updates (3 years ago).


It's 0.10. When I contacted the author (see the comments on 
https://review.openstack.org/#/c/329386/ ) he said the reason there

were no recent releases is because nothing was broken and he is
continuing to actively use and maintain it.


Idea. I absolutely agree with you about flask and his magic.
And if we want to start totally new it can be werkzeug or webob.
And if we go further I wonder why in nova we don't use
asynchronous approach. All these API calls which just transfer
from one point to another are perfect candidates.


In this particular case async would be overkill and out of place.
The changes being made in the requests are quick and in an important
transaction.


About gabbi. Could you please give several procs on declarative style
in yaml vs declarative style in python?


Rather than me describing it, perhaps have a look at
https://review.openstack.org/#/c/329151/10/nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml
and then ask questions if you have any? I think that does a
relatively good job demonstrating the declarative style.

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

[Kirill Zaitsev]

Thanks everyone. Changes have been implemented.

-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 17 June 2016 at 10:13:22, Omar Shykhkerimov (oshykhkeri...@mirantis.com) 
wrote:

+1, agree with this proposition

On Thu, Jun 16, 2016 at 3:08 PM, Victor Ryzhenkin  
wrote:
It’s great to see this happen!
+1 for adding both! Well deserved, folks!

Also agreed to remove Steve from murano-core.

-- 
Victor Ryzhenkin
Quality Assurance Engineer
freerunner on #freenode

От 16 июня 2016 г. в 14:51:23, Tetiana Lashchova (tlashch...@mirantis.com) 
написал:

+1 for both

On Thu, Jun 16, 2016 at 11:26 AM, Nikolay Starodubtsev 
 wrote:
+1
Well deserved!
                                  
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.

Skype: dark_harlequine1

2016-06-15 19:42 GMT+03:00 Serg Melikyan :
+1

Finally!

On Wed, Jun 15, 2016 at 3:33 AM, Ihor Dvoretskyi  
wrote:
+1 for Alexander Tivelkov.

Good effort.

On Wed, Jun 15, 2016 at 1:08 PM, Artem Silenkov  wrote:
Hello! 

+1

Regards, 
Artem Silenkov
---
paas-team

On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii  wrote:
+1

15 июня 2016 г. 6:47 пользователь "Yang, Lin A"  написал:

+1 both for Alexander Tivelkov and Zhu Rong. Well deserved.

Regards,
Lin Yang

On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev  wrote:

Hello team, I want to annonce the following changes to murano core team:

1) I’d like to nominate Alexander Tivelkov for murano core. He has been part of 
the project for a very long time and has contributed to almost every part of 
murano. He has been fully committed to murano during mitaka cycle and continues 
doing so during newton [1]. His work on the scalable framework architecture is 
one of the most notable features scheduled for N release.

2) I’d like to nominate Zhu Rong for murano core. Last time he was nominated I 
-1’ed the proposal, because I believed he needed to start making more 
substantial contributions. I’m sure that Zhu Rong showed his commitment [2] to 
murano project and I’m happy to nominate him myself. His work on the separating 
cfapi from murano api and contributions headed at addressing murano’s technical 
debt are much appreciated.

3) Finally I would like to remove Steve McLellan[3] from murano core team. 
Steve has been part of murano from very early stages of it. However his focus 
has since shifted and he hasn’t been active in murano during last couple of 
cycles. I want to thank Steve for his contributions and express hope to see him 
back in the project in future.


Murano team, please respond with +1/-1 to the proposed changes.

[1] http://stackalytics.com/?user_id=ativelkov=marks
[2] http://stackalytics.com/?metric=marks_id=zhu-rong
[3] http://stackalytics.com/?user_id=sjmc7
-- 
Kirill Zaitsev
Software Engineer
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Best regards,

Ihor Dvoretskyi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Sylvain Bauza]

Le 17/06/2016 12:55, Chris Dent a écrit :


tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to
help move some placement API decisions along.

Not really that long, do read:

As part of the generic resource pools spec[1] a new, independent of
the rest of nova, API is being developed called the "Placement API".
The API will initially allow for the management of resource
providers. There are entities which provide classes of resources[2]
such as VPCU, DISK_GB, IPV4_ADDRESS.

At the Bristol mid-cycle it was decided that the placement api should
be developed in such a way that it will be easy™ to lift it into its
own project at some date in the future. In that future the placement
api will be able to help "place" lots of things, not just instances.

It was also decided that this lift and shift afforded an opportunity
to explore ways of hosting and testing an HTTP API that are different
from the modes originated in nova. Not for the sake of being different
but because the nova way has issues including inscrutability.

I started a WIP a few months back to start exploring this new
API. Recently it's been chunkified into smaller reviews[3].

For testing I've been using gabbi[4] because it does good TDD for
this kind of thing and also does a great job of satisfying the
declarative proposal in the api-wg testing guideline[5]. I hope this
is not controversial.

Where the controversy enters the picture has been in my choice of
how to structure the code that hosts the API. It's been clear from
the start that we want to use as little of the nova infrastructure
as possible. What's undecided is which of two strategies should be
followed. In broad strokes those strategies are:

* Go all in on a common framework, probably Flask[6], and use it in 
its own

  specific way.
* Don't use a framework at all. WSGI has never needed one. Just
  compose some WSGI-apps, middleware and utilities and let them do
  their work.

For now I've chosen the latter because it provides a level of
simplicity, inspectability, testability and control that I think is
lost when using a framework. I know for many people in the OpenStack
community not using a framework goes against the grain, but have a look
at the code[7], it's pretty simple Python.



+1000 yes to that. Now the devil could be in the details, in particular 
how we implement the WSGI server, the corresponding WSGI app and the 
associated routing, and that's exactly the problem below.
That said, I'm not expert in that domain, just had a bit of experience 
in that in the past. So, feel free to level my opinion by how you want :-)




One of the dependencies in this model is selector[8]. The discussion
around the review of getting it into global-requirements[9] is what
has prompted this email. Discussion there has suggested that the
resistance to the second strategy may be significant enough that we
should go with the first one. I think we need to decide that sooner
than later so this email is an invitation to join in the discussion,
either here or on the review of selector[9] or the initial API[3].



I certainly understand the concerns of adding yet another library. To be 
honest, I tend to even agree with the statement that we could possibly 
use Routes without explicitly use nova.wsgi, right ?


In the review, you explain why you don't trust Routes and I respect 
that. That said, are those issues logged as real problems for our API 
consumers, which are mostly client libraries that we own and other 
projects we know, like Horizon ?


If that is a problem for those, is there something we could improve, 
instead of just getting rid of it ?


-Sylvain


From my standpoint, as the person writing the initial code, it would be
great to get this resolved soon. If we need to make a change, making
a simple WSGI app into a working Flask app is something other than
trivial, but I value us having consensus over how to do this over my
feelings about Flask and frameworks.

To be clear: I don't like Flask, at all, it is too magic and too
obscuring of the way HTTP works. You have to commit to it all the way
to get the most benefit from it and when you do that a lot of 
inspectability

is lost behind implicit magic and you are stuck with it henceforth.
Implicit magic is absolutely horrible for long term maintenance,
especially in communities where many of the contributors come and go.
The code I've written in the WIP tries to break with many of code trends
that require readers to guess.

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
[2] 
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html
[3] https://review.openstack.org/#/c/329149/ and its descendants [4] 
https://gabbi.readthedocs.io/
[5] 
http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals

[6] http://flask.pocoo.org/
[7] 

[openstack-dev] [magnum] 2 million requests / sec, 100s of nodes

[Ricardo Rocha]

Hi.

Just thought the Magnum team would be happy to hear :)

We had access to some hardware the last couple days, and tried some
tests with Magnum and Kubernetes - following an original blog post
from the kubernetes team.

Got a 200 node kubernetes bay (800 cores) reaching 2 million requests / sec.

Check here for some details:
https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html

We'll try bigger in a couple weeks, also using the Rally work from
Winnie, Ton and Spyros to see where it breaks. Already identified a
couple issues, will add bugs or push patches for those. If you have
ideas or suggestions for the next tests let us know.

Magnum is looking pretty good!

Cheers,
Ricardo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

In-line below

"discuss"  wrote on 06/15/2016 05:51:20
PM:

> From: John McDowall 
> To: Na Zhu 
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, discuss 
> Date: 06/15/2016 05:51 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
>
> Juno,
>
> Apologies – I see your issue now, also I have got nothing done today
> – got sucked into an all day meeting. I was thinking very much from
> a  ovs/ovn perspective and also my first prototype was very simple.
>
> So while in networking=sfc/ovn the port-cahin does not have a switch
> I think port-chain needs a lswitch context as that is where the
> port-chain table is created. Let me try and lay this out. I am not
> sure if I am getting this right but it is a starting point for
> discussion and comment by the community.
>
> The first thing is that there could be three different types of
> VNF’s, L3, L2, and Bump in the Wire (BITW). I am not sure if it
> would be possible to mix and match these different types in a series
> of port-pair-groups. Also as a first phase I have been trying to
> remove the need for the VNF to participate in the service chain (or
> be aware of it). In addition I also wanted to remove the need for
> any “proxy” as documented in the NSH model, by moving a lot of the
> functionality to the ovn-northd.
>
> Mode 1: BITW
> Port-Pairs: The logical ports need to be on the same logical switch
> Port-pair-groups: They are made up of sets of port-pairs, until we
> see the load-balancing proposal for ovs/ovn not sure if port-pairs
> can be on different logical switches or not. This translates to a
> set of rules in the port-chain table that chains output ports of one
> VNF to the input port of the next VNF, until the last VNF when the
> traffic is forwarded to the final destination of the packet. If the
> port-chain is bi-directional then the rule set has to be implemented
> in reverse (many VNF’s Firewalls, Load Balancers etc need to see
> both legs of the traffic).
> Flow-classifier: Is a set of rules that are set as an ACL rule with
> first logical port of the first pair in the first port-pair-group.
> Likewise if the port-chain is bi-directional then the rules have to
> be symmetric to steer the traffic in both directions.
> Port-chain: defined on the same logical switch as the first logical-
> source-port of the flow-classifier, as this is where the port-chain
> table is created and the rules for traffic steering are inserted.
> Mode 2: L2
>
> I think this would be similar to the BITH case but instead of
> steering by logical ports the steering would be done by VLAN tags.
> This would also mean that the VNFs would have to be aware of the
> steering rules and be able to manipulate VLAN tags.
>
> Mode 3: L3
>
> This would require the VNF’s to be aware of the routing rules and
> set static routes/net hop rules for each step in the service chain.
>
> Modes 2 & 3 would require a much more sophisticated control plane to
> program both OVN and the VNFs.

[Snip to save BW]

I'm not so sure John.  I agree that OVN would have to know about the
VF type (BiW/L2/L3) and further that OVN would need to be told about
the appropriate L2/L3 "next port" information - either VLAN tags or
IP addresses, but once I have that, I think the actual vswitch
programming is fairly straightforward:  for L2, the vswitch is
programmed to use the VLAN tag to select the next PPG bucket and
for L3, the existing template for programming static routes can be
leveraged.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

[Monty Taylor]

On 06/16/2016 09:44 AM, Davanum Srinivas wrote:
> Folks,
> 
> At Austin the Release Management team reached a consensus to spin off
> with some new volunteers to take care of the requirements process and
> repository [1]. The following folks showed up and worked with me on
> getting familiar with the issues/problems/tasks (see [1] and [2]) and
> help with the day to day work.
> 
> Matthew Thode (prometheanfire)
> Dirk Mueller (dirk)
> Swapnil Kulkarni (coolsvap)
> Tony Breeds (tonyb)
> Thomas Bechtold (tbechtold)

+1 to all

> So, please cast your VOTE to grant them +2/core rights on the
> requirements repository and keep up the good work w.r.t speeding up
> reviews, making sure new requirements don't break etc.
> 
> Also, please note that Thierry has been happy enough with our work to
> step down from core responsibilities :) Many thanks Thierry for
> helping with this effort and guidance. I'll make all the add/remove to
> the requirements-core team when this VOTE passes.
> 
> Thanks,
> Dims
> 
> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
> [2] https://etherpad.openstack.org/p/requirements-tasks
> [3] https://etherpad.openstack.org/p/requirements-cruft
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

Apologies for being delayed on replying and in-line back as well

Ryan

John McDowall  wrote on 06/15/2016 05:58:35
PM:

> From: John McDowall 
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Na Zhu , Srilatha Tangirala/San Francisco/
> IBM@IBMUS, "OpenStack Development Mailing List (not for usage
> questions)" , discuss
> 
> Date: 06/15/2016 05:58 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Ryan,
>
> In-line
>
> Regards
>
> John
>
> From: Ryan Moats 
> Date: Tuesday, June 14, 2016 at 9:42 PM
> To: John McDowall 
> Cc: Na Zhu , Srilatha Tangirala  >, "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, discuss 
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> "discuss"  wrote on 06/14/2016 10:31:40
PM:
>
> > From: John McDowall 
> > To: Na Zhu 
> > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> > Development Mailing List \(not for usage questions\)"  > d...@lists.openstack.org>, discuss 
> > Date: 06/14/2016 10:48 PM
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> > Sent by: "discuss" 
> >
> > Juno,
> >
> > It is a container for port-pair-groups and flow-classifier. I
> > imagine there could be more the than one port-chain per switch. Also
> > we may want to extend the model beyond a single lswitch
>
> I agree that there could be more than one port-chain per switch,
determined
> by the flow classifier.
>
> What I'm confused by is:
>
> 1. Why are items only recorded in logical switches?  I would think
> that I could also attach an SFC to a logical router - although I admit
> that the current neutron model for ports doesn't really allow that
> easily.  Couple that with the change of name from Logical_Port to
> Logical_Switch_Port, and I'm left wondering if we aren't better off
> with the following "weak" links instead:
> -the Port_Chain includes the logical switch as an external_id
> -each Port_Pair_Group includes the Port_Chain as an external_id
> -each Port_Pair includes the PPG as an external_id
> -each Logical_Switch_Port includes the PP as an external_id
>
> I *think* that *might* allow me (in the future) to attach a port chain
> to a logical router by setting the logical router as an external_id and
> using Logical_Router_Ports to make up the PPs...
>
> JED> If there are “port-chain” tables for switches and routers I
> think I agree. Not sure how this is impacted by the type of VNF (see
> the last email to Juno). I struggle a bit with imagining the flows.

RM> Back in the day when we discussed this internally here, SFCs could
RM> be inserted as BiW (which we do a good job with currently) and at
RM> network boundaries (which I'm not sure how I could do with the
RM> current model) - my router question is more one of leaving the
RM> door open for the boundary case (sorry for the pun) in the future.

> 2. I still don't see what Logical_Flow_Classifier is buying me that
> ACL doesn't - I can codify all of the classifiers given in the match
> criteria of an ACL entry and codify the first PPG of the SFC as
> the action of the ACL entry...
> JED> Flow classifiers do map to an ACL entry – just need additional
> metadata, I.e. Action of the ACL and wether the rules should be uni
> or bi-directional. Though that information could be in the port-chain.

RM> yes and I see the action field of the ACL table being extended
RM> to include "enter port chain " to cover that metadata.
RM> Why couldn't bidirectional Flow Classifiers at SFC just be
RM> implemented as a pair of uni-directional ACLs in the NB DB?
RM> I'll back off on this point if I can see an example of an flow
RM> classifier that can't be made to fit in the ACL table, but to
RM> date, I've not been able to construct such a beast.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Andrey Volkov]

It's nice to hear about HTTP API.
I'm quite new in nova and openstack and don't grasp all that rpc
things yet and can miss something but anyway I have several thoughts about
API.

Boring standpoint. First to choose some technology I think we can look at
how widely
it's adopted and how many people at local community (openstack)
use it. I checked out several openstack projects (keystone, swift,
cinder) and it's Paste I think.
IMHO selector is too young in terms of version (0.1) and too old in
terms of updates (3 years ago).

Idea. I absolutely agree with you about flask and his magic.
And if we want to start totally new it can be werkzeug or webob.
And if we go further I wonder why in nova we don't use
asynchronous approach. All these API calls which just transfer
from one point to another are perfect candidates.

About API. It would be great for new service to have auto schema
description/validation and may be some optional stuff like duplicate
protection, call signature.

About gabbi. Could you please give several procs on declarative style
in yaml vs declarative style in python?

On Fri, Jun 17, 2016 at 1:55 PM, Chris Dent  wrote:

>
> tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to
> help move some placement API decisions along.
>
> Not really that long, do read:
>
> As part of the generic resource pools spec[1] a new, independent of
> the rest of nova, API is being developed called the "Placement API".
> The API will initially allow for the management of resource
> providers. There are entities which provide classes of resources[2]
> such as VPCU, DISK_GB, IPV4_ADDRESS.
>
> At the Bristol mid-cycle it was decided that the placement api should
> be developed in such a way that it will be easy™ to lift it into its
> own project at some date in the future. In that future the placement
> api will be able to help "place" lots of things, not just instances.
>
> It was also decided that this lift and shift afforded an opportunity
> to explore ways of hosting and testing an HTTP API that are different
> from the modes originated in nova. Not for the sake of being different
> but because the nova way has issues including inscrutability.
>
> I started a WIP a few months back to start exploring this new
> API. Recently it's been chunkified into smaller reviews[3].
>
> For testing I've been using gabbi[4] because it does good TDD for
> this kind of thing and also does a great job of satisfying the
> declarative proposal in the api-wg testing guideline[5]. I hope this
> is not controversial.
>
> Where the controversy enters the picture has been in my choice of
> how to structure the code that hosts the API. It's been clear from
> the start that we want to use as little of the nova infrastructure
> as possible. What's undecided is which of two strategies should be
> followed. In broad strokes those strategies are:
>
> * Go all in on a common framework, probably Flask[6], and use it in its own
>   specific way.
> * Don't use a framework at all. WSGI has never needed one. Just
>   compose some WSGI-apps, middleware and utilities and let them do
>   their work.
>
> For now I've chosen the latter because it provides a level of
> simplicity, inspectability, testability and control that I think is
> lost when using a framework. I know for many people in the OpenStack
> community not using a framework goes against the grain, but have a look
> at the code[7], it's pretty simple Python.
>
> One of the dependencies in this model is selector[8]. The discussion
> around the review of getting it into global-requirements[9] is what
> has prompted this email. Discussion there has suggested that the
> resistance to the second strategy may be significant enough that we
> should go with the first one. I think we need to decide that sooner
> than later so this email is an invitation to join in the discussion,
> either here or on the review of selector[9] or the initial API[3].
>
> From my standpoint, as the person writing the initial code, it would be
> great to get this resolved soon. If we need to make a change, making
> a simple WSGI app into a working Flask app is something other than
> trivial, but I value us having consensus over how to do this over my
> feelings about Flask and frameworks.
>
> To be clear: I don't like Flask, at all, it is too magic and too
> obscuring of the way HTTP works. You have to commit to it all the way
> to get the most benefit from it and when you do that a lot of
> inspectability
> is lost behind implicit magic and you are stuck with it henceforth.
> Implicit magic is absolutely horrible for long term maintenance,
> especially in communities where many of the contributors come and go.
> The code I've written in the WIP tries to break with many of code trends
> that require readers to guess.
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
> [2]
> 

Re: [openstack-dev] [nova] Initial oslo.privsep conversion?

[Matt Riedemann]

On 6/9/2016 6:51 PM, Tony Breeds wrote:

On Fri, Jun 10, 2016 at 08:24:34AM +1000, Michael Still wrote:

On Fri, Jun 10, 2016 at 7:18 AM, Tony Breeds 
wrote:


On Wed, Jun 08, 2016 at 08:10:47PM -0500, Matt Riedemann wrote:


Agreed, but it's the worked example part that we don't have yet,
chicken/egg. So we can drop the hammer on all new things until someone

does

it, which sucks, or hope that someone volunteers to work the first

example.

I'll work with gus to find a good example in nova and have patches up
before
the mid-cycle.  We can discuss next steps then.



Sorry to be a pain, but I'd really like that example to be non-trivial if
possible. One of the advantages of privsep is that we can push the logic
down closer to the privileged code, instead of just doing something "close"
and then parsing. I think reinforcing that idea in the sample code is
important.


I think *any* change will show that.  I wanted to pick something achievable in
the short timeframe.

The example I'm thinking of is nova/virt/libvirt/utils.py:update_mtime()

 * It will provide a lot of the boiler plate
 * Show that we can now now replace an exec with pure python code.
 * Show how you need to retrieve data from a trusted source on the priviledged
   side
 * Migrate testing
 * Remove an entry from compute.filters

Once that's implace chown() in the same file is probably a quick fix.

Is it super helpful? does it have a measurable impact on performance, security?
The answer is probably "no"

I still think it has value.

Handling qemu-img is probably best done by creating os-qemu (or similar) and
designing from the ground up with provsep in mind.  Glance and Cinder would
benefit from that also.  That howveer is waaay to big for this cycle.

Yours Tony.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



So I know we didn't want to block the virtuozzo resize patch for 
oslo.privsep conversion, but there is another vz package for their 
libvirt volume driver that's adding a new rootwrap filter:


https://review.openstack.org/#/c/190843/

We definitely don't want that one using rootwrap filters because it's 
going to couple os-brick / cinder / nova during upgrades, which is the 
reason we wanted to get oslo.privsep support into os-brick in the first 
place.


So I think we're going to have to convert that one to use oslo.privsep. 
I might be mistaken though.


Given where this is, however, it's going to run into the issue we have 
with sorting out upgrades from mitaka (see Sean's thread) so that nova 
can register the root helper early with oslo.privsep when nova-compute 
starts up.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] Containerized OpenStack on Kubernetes experimental project proposal

[Sergey Lukjanov]

Hi,

I'd like to share proposal on running the experimental project under the
Fuel
umbrella for running OpenStack in containers on top of Kubernetes,
codename "Fuel CCP".

Here is a specification in Fuel: https://review.openstack.org/331139

CCP is the initiative to package OpenStack services in the containers and
use standard container management framework to run and manage them. It
includes following areas, but not limited to them:

* OpenStack containerization and container image building tooling
* CI/CD to produce properly layered and versioned containers for the
supported
  stable and current master branches of OpenStack projects
* OpenStack deployment in containers on top of Kubernetes with HA for
OpenStack
  services and their dependencies (e.g. MySQL, RabbitMQ, etc.)
* Tooling for deploying and operating OpenStack clusters with support for
the
  upgrades, patching, scaling and changing configuration

As for the governance - Fuel CCP will be just a separated experimental
project
under OpenStack namespace with own specs and core team. The nearest example
of
the same governance is 3rd party Fuel plugin done not by Mirantis.

Thanks.

-- 
Sincerely yours,
Sergey Lukjanov
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Integration testing for Nova API os-assisted-volume-snapshots

[Matt Riedemann]

On 6/17/2016 2:44 AM, Silvan Kaiser wrote:

I'd be happy to help, too. Please drop e.g. a bug link in this thread we
can use to follow up on things, that would be great.
Best
Silvan

2016-06-15 22:44 GMT+02:00 Sean McGinnis >:

On Wed, Jun 15, 2016 at 07:01:17PM +0200, Jordan Pittier wrote:
> On Wed, Jun 15, 2016 at 6:21 PM, Matt Riedemann >
> wrote:
>
...
> > Does someone have a link to a successful job run for one of those 
drivers?
> > I'd like to see if they are testing volume snapshot and that it's 
properly
> > calling the nova API and everything is working. Because this is also
> > something that Nova could totally unknowingly break to that flow since 
we
> > have no CI coverage for it (we don't have those cinder 3rd party CI jobs
> > running against nova changes).
> >
> > --
> >
>
> Hi Matt,
> I am in charge of the Scality CI. It used to report to changes in Cinder. 
A
> change in devstack broke us a couple of months ago, so I had to turn off 
my
> CI (because it was reporting false negative) while developing a patch. The
> patch took a long time to develop and merge but was merged finally:
> https://review.openstack.org/#/c/310204/
>
> But in the mean time, something else crept in, hidden by the first 
failure.
> So the Scality CI is still broken, but it is my intention to find the
> commit that broke it and come up with a patch.
>
Jordan, please ping me when you have a patch for that and I will try to
make it a priority.

Thanks,
Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Dr. Silvan Kaiser
Quobyte GmbH
Hardenbergplatz 2, 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com

Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Getting back to the original intent of the thread, are there CI results 
with instance/volume snapshot for these volume drivers so we can see 
that os-assisted-volume-snapshots is passing?


I'm not particularly interested in the volume-backed instance snapshot 
scenario because unless I'm mistaken, that would do something like:


1. nova-api to snapshot the instance
2. calls to nova-compute to quiesce the instance
3. then calls to cinder to snapshot the volume
4. which then cinder calls back to nova's os-assisted-volume-snapshots API

If that's the actual flow it's quite a complicated back and forth 
between the two services where lots of things could break down and I 
doubt get rolled back properly, similar to how cinder volume migration / 
retype has to call the nova swap-volume API which then calls back to 
cinder to tell it that the migration is complete.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

[John Garbutt]

On 15 June 2016 at 02:37, Sean Dague  wrote:
> On 06/14/2016 07:28 PM, Monty Taylor wrote:
>>
>> On 06/14/2016 05:42 PM, Doug Hellmann wrote:
>
> 
>>
>> I think this is the most important thing to me as it relates to this.
>> I'm obviously a huge proponent of clouds behaving more samely. But I
>> also think that, as Doug nicely describes above, we've sort of backed in
>> to removing something without a deprecation window ... largely because
>> of the complexities involved with the system here - and I'd like to make
>> sure that when we are being clear about behavior changes that we give
>> the warning period so that people can adapt.

+1

> I also think that "pass" to "pass *"  is useful social incentive. While I
> think communication of this new direction has happened pretty broadly,
> organizations are complex places, and it didn't filter everywhere it needed
> to with the urgency that was probably needed.
>
> "pass *"  * - with a greylist which goes away in 6 months
>
> Will hopefully be a reasonable enough push to get the behavior we want,
> which is everyone publishing the same interface.

+1

I know I am going back in time, but +1 all the same.

I like how this pushes forward the of interoperability cause.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [UX] [TripleO] TripleO UI Initial Wireframes

[Liz Blanchard]

On Thu, Jun 16, 2016 at 11:27 AM, Dan Prince  wrote:

> I left some comments on the wireframes themselves. One general concept
> I would like to see capture is to make sure that things across the UI
> and CLI have parity.
>
> Specifically things like if I register nodes on the CLI we use a JSON
> file format:
>
> http://tripleo.org/environments/environments.html#instackenv
>
> Supporting individual nodes to be created is fine as well since a
> command line user could just run Ironic client commands directly too.
>
> I also left a comment about the screen with multiple plans. I like this
> idea and it is something that we can pursue but due to fact that we use
> a flat physical deployment network there would need to be some extra
> care in setting up the network ranges, vlans, etc across multiple
> plans. Again this is something I would like to see us support and
> document with the CLI before we go and expose the capability in the UI.
>

Thanks so much for the review, Dan. I responded to your comments in
InVision and I will work towards making updates to reflect my responses.

Liz


>
> Dan
>
>
> On Mon, 2016-06-06 at 15:03 -0400, Liz Blanchard wrote:
> > Hi All,
> >
> > I wanted to share some brainstorming we've done on the TripleO UI. I
> > put together wireframes[1] to reflect some ideas we have on moving
> > forward with features in the UI and would love to get any feedback
> > you all have. Feel free to comment via this email or comment within
> > InVision.
> >
> > Best,
> > Liz
> >
> > [1] https://invis.io/KW7JTXBBR
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Gabriel Samfira]

Hi James,


No problem on my side. This is a welcome change!

Regards,
Gabriel Samfira
Cloudbase Solutions SRL

On Mi, 2016-06-08 at 10:20 +, James Page wrote:
> Hi
> 
> We're currently blocked on becoming an OpenStack project under the
> big-tent by the licensing of the 26 OpenStack charms under GPL v3.
> 
> I'm proposing that we re-license the following code repositories as
> Apache 2.0:
> 
>   charm-ceilometer
>   charm-ceilometer-agent
>   charm-ceph
>   charm-ceph-mon
>   charm-ceph-osd
>   charm-ceph-radosgw
>   charm-cinder
>   charm-cinder-backup
>   charm-cinder-ceph
>   charm-glance
>   charm-hacluster
>   charm-heat
>   charm-keystone
>   charm-lxd
>   charm-neutron-api
>   charm-neutron-api-odl
>   charm-neutron-gateway
>   charm-neutron-openvswitch
>   charm-nova-cloud-controller
>   charm-nova-compute
>   charm-odl-controller
>   charm-openstack-dashboard
>   charm-openvswitch-odl
>   charm-percona-cluster
>   charm-rabbitmq-server
>   charm-swift-proxy
>   charm-swift-storage
> 
> The majority of contributors are from Canonical (from whom I have
> permission to make this switch) with a further 18 contributors from
> outside of Canonical who I will be directly contacting for approval
> in gerrit as reviews are raised for each repository.
> 
> Any new charms and supporting repositories will be licensed under
> Apache 2.0 from the outset.
> 
> Cheers
> 
> James
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Zaqar messages standardization

[Jiri Tomasek]

On 05/26/2016 12:18 PM, Thomas Herve wrote:

On Thu, May 26, 2016 at 11:48 AM, Jiri Tomasek  wrote:

On 05/25/2016 08:08 PM, Thomas Herve wrote:

Sorry for not responding earlier, but I have some inputs. In Heat we
publish events on Zaqar queue, and we defined this format:

  {
  'timestamp': $timestamp,
  'version': '0.1',
  'type': 'os.heat.event',
  'id': $uuid,
  'payload': {
  'XXX
  }
  }


Thanks, it totally makes sense. So when I convert my example to your usage
it looks like this:

{
 body: {
 'timestamp': $timestamp,
 'type': 'tripleo.validations.v1.run_validation',
 'id': $uuid,
 'payload': {
 execution_id: '123123123',
 validation_id: '123321'
 ...
  }
 }
}

I am not sure whether to separate the version from type as it would become
complicated to reconstruct the workflow name (at least for tripleo
workflows).
The most important is the 'type' as that is the key which we'd like to use
on client to identify what action to take.

Looks great to me, thanks!



So as the workflows start to shape up and we start to use Zaqar messages 
in clients, this is the mistral task we use to send a message:


send_message:
  action: zaqar.queue_post
  input:
  queue_name: <% $.queue_name %>
  messages:
body:
  type: tripleo.baremetal.v1.register_or_update
  execution_id: <% execution().id %>
  payload:
status: <% $.get('status', 'SUCCESS') %>
message: <% $.get('message', '') %>
registered_nodes: <% $.registered_nodes or [] %>

I am coming to a conclusion, that instead of passing just the execution 
ID, it would be much more beneficial to send the whole execution object, 
because
1. the client is going to have to fire up additional request to get the 
execution info
2. execution object itself often includes most of the information which 
this task explicitly includes in payload




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

[Thierry Carrez]

Davanum Srinivas wrote:

Matthew Thode (prometheanfire)
Dirk Mueller (dirk)
Swapnil Kulkarni (coolsvap)
Tony Breeds (tonyb)
Thomas Bechtold (tbechtold)


+1

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [api] [placement] strategy for placement api structure

[Chris Dent]

tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to
help move some placement API decisions along.

Not really that long, do read:

As part of the generic resource pools spec[1] a new, independent of
the rest of nova, API is being developed called the "Placement API".
The API will initially allow for the management of resource
providers. There are entities which provide classes of resources[2]
such as VPCU, DISK_GB, IPV4_ADDRESS.

At the Bristol mid-cycle it was decided that the placement api should
be developed in such a way that it will be easy™ to lift it into its
own project at some date in the future. In that future the placement
api will be able to help "place" lots of things, not just instances.

It was also decided that this lift and shift afforded an opportunity
to explore ways of hosting and testing an HTTP API that are different
from the modes originated in nova. Not for the sake of being different
but because the nova way has issues including inscrutability.

I started a WIP a few months back to start exploring this new
API. Recently it's been chunkified into smaller reviews[3].

For testing I've been using gabbi[4] because it does good TDD for
this kind of thing and also does a great job of satisfying the
declarative proposal in the api-wg testing guideline[5]. I hope this
is not controversial.

Where the controversy enters the picture has been in my choice of
how to structure the code that hosts the API. It's been clear from
the start that we want to use as little of the nova infrastructure
as possible. What's undecided is which of two strategies should be
followed. In broad strokes those strategies are:

* Go all in on a common framework, probably Flask[6], and use it in its own
  specific way.
* Don't use a framework at all. WSGI has never needed one. Just
  compose some WSGI-apps, middleware and utilities and let them do
  their work.

For now I've chosen the latter because it provides a level of
simplicity, inspectability, testability and control that I think is
lost when using a framework. I know for many people in the OpenStack
community not using a framework goes against the grain, but have a look
at the code[7], it's pretty simple Python.

One of the dependencies in this model is selector[8]. The discussion
around the review of getting it into global-requirements[9] is what
has prompted this email. Discussion there has suggested that the
resistance to the second strategy may be significant enough that we
should go with the first one. I think we need to decide that sooner
than later so this email is an invitation to join in the discussion,
either here or on the review of selector[9] or the initial API[3].


From my standpoint, as the person writing the initial code, it would be

great to get this resolved soon. If we need to make a change, making
a simple WSGI app into a working Flask app is something other than
trivial, but I value us having consensus over how to do this over my
feelings about Flask and frameworks.

To be clear: I don't like Flask, at all, it is too magic and too
obscuring of the way HTTP works. You have to commit to it all the way
to get the most benefit from it and when you do that a lot of inspectability
is lost behind implicit magic and you are stuck with it henceforth.
Implicit magic is absolutely horrible for long term maintenance,
especially in communities where many of the contributors come and go.
The code I've written in the WIP tries to break with many of code trends
that require readers to guess.

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
[2] 
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html
[3] https://review.openstack.org/#/c/329149/ and its descendants 
[4] https://gabbi.readthedocs.io/

[5] 
http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals
[6] http://flask.pocoo.org/
[7] 
https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py
[8] https://pypi.python.org/pypi/selector
[9] https://review.openstack.org/#/c/329386/

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Using image metadata to sanity check supplied authentication data at nova 'create' or 'recreate' time?

[John Garbutt]

On 7 June 2016 at 17:41, Jim Rollenhagen  wrote:
> On Tue, Jun 07, 2016 at 03:10:24PM +0100, Daniel P. Berrange wrote:
>> On Tue, Jun 07, 2016 at 09:37:25AM -0400, Jim Rollenhagen wrote:
>> > Right, so that's a third case. How I'd see this working is maybe an
>> > image property called "auth_requires" that could be one of ["none",
>> > "ssh_key", "x509_cert", "password"]. Or maybe it could be multiple
>> > values that are OR'd, so for example an image could require an ssh key
>> > or an x509 cert. If the "auth_requires" property isn't found, default to
>> > "none" to maintain compatibility, I guess.

That sounds reasonable to me.

>> NB, even if you have an image that requires an SSH key to be provided in
>> order to enable login, it is sometimes valid to not provide one. Not least
>> during development, I'm often testing images which would ordinarily require
>> an SSH key, but I don't actually need the ability to login, so I don't bother
>> to provide one.
>>
>> So if we provided this ability to tag images as needing an ssh key, and then
>> enforced that, we would then also need to extend the API to provide a way to
>> tell nova to explicitly ignore this and not bother enforcing it, despite what
>> the image metadata says.
>>
>> I'm not particularly convinced the original problem is serious enough to
>> warrant building such a solution. It feels like the kind of mistake that
>> people would do once, and then learn their mistake thereafter. IOW the
>> consequences of the mistake don't seem particularly severe really.

So the problem this is trying to resolve is reducing support calls /
reducing user frustration.

Doing that by making it harder to use our API in the "wrong" way seems
fine to me. It seems similar to the checks we do on neutron ports, to
make sure you have something that looks useful, to help avoid user
confusion.

By default, you would have no image_metadata, so there would be no
restriction, so I don't think it should impact most people's testing.
Once we get this spec done, the override should be simple:
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/virt-image-props-boot-override.html

>> > The bigger question here is around hitting the images API syncronously
>> > during a boot request, and where/how/if to cache the metadata that's
>> > returned so we don't have to do it so often. I don't have a good answer
>> > for that, though.
>>
>> Nova already uses image metadata for countless things during the VM boot
>> request, so there's nothin new in this respect. We only query glance
>> once, thereafter the image metadata is cached by Nova in the DB on a per
>> instance basis, because we need to be isolated from later changes to the
>> metadata in glance after the VM boots.

+1

> This is beyond the API though, right? The purpose of the spec here is to
> reject the request if there isn't enough information to boot the
> machine.

Its normal to access it anywhere you need it form the instance object.
Random example:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1585

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[John Garbutt]

On 16 June 2016 at 09:58, Thierry Carrez  wrote:
> Project team requirements are just guidelines, which are interpreted by
> humans. In the end, the TC members vote and use human judgment rather than
> blind 'rules'. I just want (1) to state that a level playing field is an
> essential part of what we call "open collaboration", and (2) to have TC
> members *consider* whether the project presents a fair playing field or not,
> as part of how they judge future project teams.

FWIW, I think this is what wins me over.
These are just guidelines to be considered by humans.

> There is a grey area that requires human judgment here. In your example
> above, if the open implementation was unusable open core bait to lure people
> into using the one and only proprietary driver, it would be a problem. If
> the open implementation was fully functional and nothing prevented adding
> additional proprietary drivers, there would be no problem.

This answers a lot of the questions I had after reading the idea.
Along with the fact this is only about official projects.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Upcoming changes now that Jenkins has retired

[Joshua Hesketh]

We can update those without any trouble. We just need to also update the
tests that check the usernames. You should be able to make all of the
changes (as per your first patchset) and then find where the tests also
need changing. Happy to help you on the review if you need more guidance.

To clarify though, these are just usernames used in the testing. They can
be anything arbitrarily. And as mentioned by James, it is still possible to
run Jenkins with zuul (in v2.5). So the tests aren't necessarily incorrect.

There are still some places in infra that do still use jenkins though. For
example, when uploading logs or assets zuul ssh's into the log server as
the user 'jenkins'. We could create a new user for zuul to use in these
cases.

On Fri, Jun 17, 2016 at 6:08 PM, Will Zhou  wrote:

> Hi James,
>
> I submitted a fix to openstack-infra/zuul via
> https://review.openstack.org/#/c/330853/. I found that username could not
> be changed from 'jenkins' to 'zuul' like
>
>
> https://github.com/openstack-infra/zuul/blob/master/tests/fixtures/layouts/good_require_approvals.yaml#L11
> review_gerrit:
> - event: comment-added
> require-approval:
> * - username: jenkins*
> older-than: 48h
> - event: comment-added
> require-approval:
> - email: jenk...@example.com
> newer-than: 48h
> It seems that it might be a little early for the fix?
>
> Thanks.
>
> On Fri, Jun 17, 2016 at 9:15 AM James E. Blair 
> wrote:
>
>> Now that we have retired Jenkins, we have some upcoming changes:
>>
>> * Console logs are now available via TCP
>>
>>   The status page now has "telnet" protocol links to running jobs.  If
>>   you connect to the host and port specified in that link, you will be
>>   sent the console log for that job up to that point in time and it
>>   will continue to stream over that connection in real time.  If your
>>   browser doesn't understand "telnet://" URLs, just grab the host and
>>   port and type "telnet  " or better yet, "nc 
>>   " into your terminal.  You can also grep through in progress
>>   console logs with "nc   | grep ".
>>
>> * Console logs will soon be available over the WWW
>>
>>   Netcatting to Grep is cool, but sometimes if you're already in a
>>   browser, it may be easier to click on a link and have that just open
>>   up in your existing browser.  Monty has been working on a websocket
>>   interface to the console log stream that we hope to have in place
>>   soon.
>>
>> * Zuul will stop using the name "Jenkins"
>>
>>   There is a new user in Gerrit named "Zuul".  Zuul has been
>>   masquerading as Jenkins for the past few years, but now that we no
>>   longer run any software named "Jenkins" it is the right time to
>>   change the name to Zuul.  If you have any programs, scripts,
>>   dashboards, etc, that look for either the full name "Jenkins" or
>>   username "jenkins" from Gerrit, you should immediately update them
>>   to also use the full name "Zuul" or username "zuul" in order to
>>   prepare for the change.
>>
>> -Jim
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Amrith Kumar]

Steve, this was exactly the point I wanted to make and the reason I chose the 
verbiage of "reasonably accessible" since I believe that this would classify as 
such. However, as Thierry pointed out in his response to the review that wasn't 
his primary focus.

Rather, he didn't want a project to benefit a single contributor, vendor, 
organization and I've submitted a revision for his comments.

But, your point is well taken, and I didn't realize that the RHEL free for 
developers was a recent change.

-amrith

> -Original Message-
> From: Steve Gordon [mailto:sgor...@redhat.com]
> Sent: Thursday, June 16, 2016 11:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all][tc] Require a level playing field for
> OpenStack projects
> 
> - Original Message -
> > From: "Jeremy Stanley" 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> 
> > Sent: Thursday, June 16, 2016 5:04:43 PM
> > Subject: Re: [openstack-dev] [all][tc] Require a level playing field
>   for OpenStack projects
> >
> > On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
> > [...]
> > > This is definitely a point worth clarifying in the general case,
> > > but tangentially for the specific case of the RHEL operating
> > > system please note that RHEL is available to developers for free:
> > >
> > > http://developers.redhat.com/products/rhel/get-started/
> > > http://developers.redhat.com/articles/no-cost-rhel-faq/
> > >
> > > This is a *relatively* recent advancement so I though I would
> > > mention it as folks may not be aware.
> >
> > Just to clarify, this is free-as-in-beer (gratis) and not
> > free-as-in-speech (libre)? If so, that's still proprietary so I'm
> > curious how that changes the situation. Would OpenStack welcome a
> > project built exclusively around a "free for developer use" product
> > into the tent?
> 
> Well, in the context of evaluating this specific proposed change that
> really depends on the final language used. Under the wording that is
> currently proposed the answer would seem to be "yes" if developers of all
> organizations have access to that same software - whether that's the
> intent or not is perhaps a different question. In reality of course such a
> hypothetical project would likely fall afoul of the earlier criteria
> around dependencies anyway...
> 
> -Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Upcoming changes now that Jenkins has retired

[Will Zhou]

Hi James,

I submitted a fix to openstack-infra/zuul via
https://review.openstack.org/#/c/330853/. I found that username could not
be changed from 'jenkins' to 'zuul' like

https://github.com/openstack-infra/zuul/blob/master/tests/fixtures/layouts/good_require_approvals.yaml#L11
review_gerrit:
- event: comment-added
require-approval:
* - username: jenkins*
older-than: 48h
- event: comment-added
require-approval:
- email: jenk...@example.com
newer-than: 48h
It seems that it might be a little early for the fix?

Thanks.

On Fri, Jun 17, 2016 at 9:15 AM James E. Blair  wrote:

> Now that we have retired Jenkins, we have some upcoming changes:
>
> * Console logs are now available via TCP
>
>   The status page now has "telnet" protocol links to running jobs.  If
>   you connect to the host and port specified in that link, you will be
>   sent the console log for that job up to that point in time and it
>   will continue to stream over that connection in real time.  If your
>   browser doesn't understand "telnet://" URLs, just grab the host and
>   port and type "telnet  " or better yet, "nc 
>   " into your terminal.  You can also grep through in progress
>   console logs with "nc   | grep ".
>
> * Console logs will soon be available over the WWW
>
>   Netcatting to Grep is cool, but sometimes if you're already in a
>   browser, it may be easier to click on a link and have that just open
>   up in your existing browser.  Monty has been working on a websocket
>   interface to the console log stream that we hope to have in place
>   soon.
>
> * Zuul will stop using the name "Jenkins"
>
>   There is a new user in Gerrit named "Zuul".  Zuul has been
>   masquerading as Jenkins for the past few years, but now that we no
>   longer run any software named "Jenkins" it is the right time to
>   change the name to Zuul.  If you have any programs, scripts,
>   dashboards, etc, that look for either the full name "Jenkins" or
>   username "jenkins" from Gerrit, you should immediately update them
>   to also use the full name "Zuul" or username "zuul" in order to
>   prepare for the change.
>
> -Jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Integration testing for Nova API os-assisted-volume-snapshots

[Silvan Kaiser]

I'd be happy to help, too. Please drop e.g. a bug link in this thread we
can use to follow up on things, that would be great.
Best
Silvan

2016-06-15 22:44 GMT+02:00 Sean McGinnis :

> On Wed, Jun 15, 2016 at 07:01:17PM +0200, Jordan Pittier wrote:
> > On Wed, Jun 15, 2016 at 6:21 PM, Matt Riedemann <
> mrie...@linux.vnet.ibm.com>
> > wrote:
> >
> ...
> > > Does someone have a link to a successful job run for one of those
> drivers?
> > > I'd like to see if they are testing volume snapshot and that it's
> properly
> > > calling the nova API and everything is working. Because this is also
> > > something that Nova could totally unknowingly break to that flow since
> we
> > > have no CI coverage for it (we don't have those cinder 3rd party CI
> jobs
> > > running against nova changes).
> > >
> > > --
> > >
> >
> > Hi Matt,
> > I am in charge of the Scality CI. It used to report to changes in
> Cinder. A
> > change in devstack broke us a couple of months ago, so I had to turn off
> my
> > CI (because it was reporting false negative) while developing a patch.
> The
> > patch took a long time to develop and merge but was merged finally:
> > https://review.openstack.org/#/c/310204/
> >
> > But in the mean time, something else crept in, hidden by the first
> failure.
> > So the Scality CI is still broken, but it is my intention to find the
> > commit that broke it and come up with a patch.
> >
> Jordan, please ping me when you have a patch for that and I will try to
> make it a priority.
>
> Thanks,
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dr. Silvan Kaiser
Quobyte GmbH
Hardenbergplatz 2, 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposed TripleO core changes

[Clint Byrum]

Excerpts from Steven Hardy's message of 2016-06-09 15:03:51 +0100:
> Also, while reviewing the core group[2] I noticed the following members who
> are no longer active and should probably be removed:
> 
> - Radomir Dopieralski
> - Martyn Taylor
> - Clint Byrum
> 
> I know Clint is still involved with DiB (which has a separate core group),
> but he's indicated he's no longer going to be directly involved in other
> tripleo development, and AFAIK neither Martyn or Radomir are actively
> involved in TripleO reviews - thanks to them all for their contribution,
> we'll gladly add you back in the future should you wish to return :)
> 

Indeed, I'd like to remain involved with diskimage-builder, but the rest
of TripleO isn't in my focus anymore.

If I need to step up diskimage-builder reviews let me know. But I'd hope
the simplest course of action would be to just move me over to the
diskimage builder core group.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

[Omar Shykhkerimov]

+1, agree with this proposition

On Thu, Jun 16, 2016 at 3:08 PM, Victor Ryzhenkin 
wrote:

> It’s great to see this happen!
> +1 for adding both! Well deserved, folks!
>
> Also agreed to remove Steve from murano-core.
>
> --
> Victor Ryzhenkin
> Quality Assurance Engineer
> freerunner on #freenode
>
> От 16 июня 2016 г. в 14:51:23, Tetiana Lashchova (tlashch...@mirantis.com)
> написал:
>
> +1 for both
>
> On Thu, Jun 16, 2016 at 11:26 AM, Nikolay Starodubtsev <
> nstarodubt...@mirantis.com> wrote:
>
>> +1
>> Well deserved!
>>
>>
>>
>> Nikolay Starodubtsev
>>
>> Software Engineer
>>
>> Mirantis Inc.
>>
>>
>> Skype: dark_harlequine1
>>
>> 2016-06-15 19:42 GMT+03:00 Serg Melikyan :
>>
>>> +1
>>>
>>> Finally!
>>>
>>> On Wed, Jun 15, 2016 at 3:33 AM, Ihor Dvoretskyi <
>>> idvorets...@mirantis.com> wrote:
>>>
 +1 for Alexander Tivelkov.

 Good effort.

 On Wed, Jun 15, 2016 at 1:08 PM, Artem Silenkov  wrote:

> Hello!
>
> +1
>
> Regards,
> Artem Silenkov
> ---
> paas-team
>
> On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii 
> wrote:
>
>> +1
>> 15 июня 2016 г. 6:47 пользователь "Yang, Lin A" 
>> написал:
>>
>> +1 both for Alexander Tivelkov and Zhu Rong. Well deserved.
>>>
>>> Regards,
>>> Lin Yang
>>>
>>> On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev 
>>> wrote:
>>>
>>> Hello team, I want to annonce the following changes to murano core
>>> team:
>>>
>>> 1) I’d like to nominate Alexander Tivelkov for murano core. He has
>>> been part of the project for a very long time and has contributed to 
>>> almost
>>> every part of murano. He has been fully committed to murano during 
>>> mitaka
>>> cycle and continues doing so during newton [1]. His work on the scalable
>>> framework architecture is one of the most notable features scheduled 
>>> for N
>>> release.
>>>
>>> 2) I’d like to nominate Zhu Rong for murano core. Last time he was
>>> nominated I -1’ed the proposal, because I believed he needed to start
>>> making more substantial contributions. I’m sure that Zhu Rong showed his
>>> commitment [2] to murano project and I’m happy to nominate him myself. 
>>> His
>>> work on the separating cfapi from murano api and contributions headed at
>>> addressing murano’s technical debt are much appreciated.
>>>
>>> 3) Finally I would like to remove Steve McLellan[3] from murano core
>>> team. Steve has been part of murano from very early stages of it. 
>>> However
>>> his focus has since shifted and he hasn’t been active in murano during 
>>> last
>>> couple of cycles. I want to thank Steve for his contributions and 
>>> express
>>> hope to see him back in the project in future.
>>>
>>>
>>> Murano team, please respond with +1/-1 to the proposed changes.
>>>
>>> [1] http://stackalytics.com/?user_id=ativelkov=marks
>>> [2] http://stackalytics.com/?metric=marks_id=zhu-rong
>>> [3] http://stackalytics.com/?user_id=sjmc7
>>> --
>>> Kirill Zaitsev
>>> Software Engineer
>>> Mirantis, Inc
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --
 Best regards,

 Ihor Dvoretskyi


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe