[openstack-dev] [nova][neutron] Is it still valid/supported to create a network with a br- id?

[Matt Riedemann]

The nova create-server API allows passing a network id that's prefixed 
with br- [1]. That was added due to this bug from Folsom [2].


I'm wondering if that's still valid? Looking at the network.id data 
model in Neutron it doesn't look like it would be [3].


I'm trying to sort this out for the get me a network spec in nova [4] 
because as part of the jsonschema validation change for that 
microversion, I was going to require that network ID be a uuid, or the 
special 'auto' or 'none' values. Supporting br- type IDs would 
mess that up.


[1] 
https://github.com/openstack/nova/blob/82b0129f398817c03a9b8d43838a44646330c383/nova/api/openstack/compute/servers.py#L478-L485

[2] https://bugs.launchpad.net/nova/+bug/1021370
[3] 
https://github.com/openstack/neutron/blob/6bdbff27a8327e8fc5a9897046af3aeecbbb28d2/neutron/db/model_base.py#L33-L38

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

--

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] [tc] [all] [glance] On operating a high throughput or otherwise team

[Nikhil Komawar]

Hi all,


Lately I have been involved in discussions that have resulted in giving
a wrong idea to the approach I take in operating the (Glance) team(s).
While my approach is consistency, coherency and agility in getting
things done (especially including the short, mid as well as long term
plans), it appears that it wasn't something evident. So, I have decided
to write this email so that I can collectively gather feedback and share
my thoughts on the right(eous) approach.


My experience has been that OpenStack is relatively slow. In fact the
feedback I get from people who are secondary (short span contributors)
is that it's very slow. There's a genuine reason for that and it's not
as simple as you are an Open Source/Community project or that people are
unreasonable or that there's lot of bike-shedding, etc.


We are developing something that is usable, operationally friendly and
that it's easier to contribute & maintain but, many strong influencers
are missing on the most important need for OpenStack -- efficient way of
communication. I think we have the tools and right approach on paper and
we've mandated it in the charter too, but that's not enough to operate
things. Also, many people like to work on the assumption that all the
tools of communication are equivalent or useful and there are no
side-effects of using them ever. I strongly disagree. Please find the
reason below:


Let me start from scratch:-


* What is code really?

Code is nothing but a way to communicate your decisions. These decisions
(if, then, else, while, etc.) are nothing but a way to consistently
produce a repeatable output using a machine.  (
https://en.wikipedia.org/wiki/Turing_machine )


* If it's that simple, why is there even a problem?

Decisions when taken in tandem or in parallel can result into a more
complex phenomenon that is not perceptibly evident. That results into
assumptions.


* So, what can be the blocker?

Nothing, but working with these assumptions is really the blocker. That
is exactly why many people in their feedback say we have a "people
problem" in OpenStack. But it's not really the people problem, it is the
assumption problem.

Assumptions are very very bad:

With 'n' problems in a domain and 'm' people working on all those
problems, individually, we have the assumption problem of the order of
O((m*e)^n) where you can think of 'e' as the convergence factor.
Convergence factor being the ability of a group to come to an agreement
of the order of 'agree to agree', 'agree to disagree' (add percentages
to each for more granularity). There is also another assumption (for the
convergence factor) that everyone wants to work in the best interest of
solving the problems in that domain.


* How do I attempt to solve this situation?

I think the first and foremost step is understanding the 'intent' behind
every step -- whether it is a proposal, code, email, etc.

Another important step is to reduce the communication gap -- be it be
meetings, emails, chats, etc. I think the distinguishing factor of each
of these modes of communication should be taken place while
communicating. For example, the process of communication involves ->
intent, thought, ability to communicate, language barriers/restrictions
by the speaker and for the audience it is the other way around ->
language barrier/restrictions, ability to comprehend, internalize (give
it a shape in your thoughts) and then catch the intent. This is a long
process behind each and every step of the communication whether one
sentence or if it's a long review. So, when the intent is important to
communicate we need to use the medium of communication that is most
suitable to communicate the intent, in case of recommended tools it is
irc on regular basis and otherwise they are meetups. We sometimes use
video/audio conf calls etc. High bandwidth communication is extremely
important to increase the convergence factor and solve the problem.
Let's start using them more and more. Please.

I think people prefer to use ML a lot and I am not a great fan of the
same. It is a multi-cast way of communication and it has assumptions
around time, space, intent of the audience & intent to actually read
them. Same is for gerrit/etherpad.

Same applies to the broadcast media too but to a smaller extent as that
content is static and focuses on one thing.

Multi-cast medium of communication is more disruptive as it involves a
possibility of divergence from the topic, strongly polarizing opinions
due to the small possibility of catching of the intent. So, let us use
it 'judiciously' and preferably only as a newspaper.

Another step is to arrange/show-up in meetings, yes this is tedious but
extremely vital. This is the place where you can actually determine if
the convergence factor is more or less. I find that a lot of people take
meetings lightly and their approach isn't establishing a deterministic
behavior in the team. Many times, it becomes a disruptive behavior and
the convergence 

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Nikhil Komawar]

On 5/14/16 2:35 PM, Mike Perez wrote:
> On 18:46 May 12, Nikhil Komawar wrote:
>> I realized that I missed one of your questions earlier. Response for
>> that inline.
>>
>>
>> On 5/12/16 4:58 PM, Nikhil Komawar wrote:
>>>
>>> On 5/12/16 4:33 PM, Doug Hellmann wrote:
 Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
> Please find my response inline:
>
> On 5/12/16 1:10 PM, Doug Hellmann wrote:
>> Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
>>> Tim Bell wrote:
 [...]
 I think it will be really difficult to persuade the mainstream 
 projects to adopt
 a library if it is not part of Oslo. Developing a common library for 
 quota
 management outside the scope of the common library framework for 
 OpenStack
 does not seem to be encouraging the widespread use of delimiter.
 [...]
>>> I agree it's hard enough to get Oslo libraries used across the board, I 
>>> don't think the task would be any easier with an external library.
>>>
>>> One case that would justify being external is if the library was 
>>> generally useful rather than OpenStack-specific: then the Oslo branding 
>>> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
>>> that is the case here ?
>>>
>> In the past we've tried to encourage folks creating very specially
>> focused libraries for which areas where the existing Oslo team has no
>> real experience, such as os-win, to set up their own team. The Oslo team
>> doesn't have to own all libraries.
> Thanks for that pointer!
>
>> On the other hand, in this case I think quota management fits in Oslo as
>> well as messaging or policy do. We have a mechanism in place for managing
>> sub-teams so signing up to work on quotas doesn't have to mean signing
>> up to be oslo-core.
> Yes, I agree that this fits well into the cross-project consistency
> domain. And yes, thanks for proposing the sub-team strategy to move 
> forward.
>
> However, this library currently doesn't exist. We are still identifying
> what we want to achieve as a part of this scope, there's a ton of
> discussions in progress and we are on the advent of finding concrete
> tasks for people to pick up (so no second commit yet). Even after having
> done something we do not know if that's is something which will work for
> all the projects -- basically I am trying to say quotas is a big domain
> and now we are starting (very) small. We need a concrete implementation
> and it's adoption in a couple of projects to even say that it is a
> successful cross project implementation.
>
> The last thing we want to worry about is more process, governance and an
> approach to too-standardize things when we do not even have anything in
> tree. I think it makes sense as a part of somewhere _all_ projects can
> adopt but not until it's ready to be adopted.
 I'm not sure what processes you're talking about that might be a burden.
 Can you elaborate?
>> Currently, I do not have facts but only hints (anticipations, expected
>> hick-ups). If you think that's not the case, do you think we can be done
>> with all the processes, governance, etc. and yet be able to come up with
>> a POC release (dunno something like 0.0.3) within next 5 weeks that can
>> be experimented upon in one/two of the projects POC patches? We are
>> looking at that timeline and not sure how long the governance and specs
>> will take (do we need oslo spec?, how big is the process to setup
>> sub-cores? , how do we involve more folks without them thinking of oslo
>> standards?, etc.).
>>
>> My biggest concern is that this will be seen as something that is an
>> attempt to standardize things where we do not even have a standard but
>> want to create one. We wish to be agile in our workflow and do not care
>> where that exists.
> Reading this thread, Nikhil who is speaking for the quota team is worried 
> about
> the amount of overhead caused by governance, instead of first focusing on
> making something actually exist. I see quite a few people in this thread
> speaking up that it should be part of the big tent either standalone or oslo
> lib.
>
> I can't speak for the Oslo folks, but as a member of the TC here are the
> requirements for the standalone route [1]. You would propose an agenda item to
> the TC, and we would review that the project meets those requirements.
> Considering the project does Open Design and has an Open Community - my 
> guesses
> on "probably would be followed" is Open Development and Open Source since we
> don't have anything but a specification that exists to go off of.
>
> It sounds like the biggest hang up in going the oslo route is the oslo spec. 
> So
> question to the oslo folks, would you be interested in reviewing the
> cross-project specification and 

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

[Mike Perez]

On 18:46 May 12, Nikhil Komawar wrote:
> I realized that I missed one of your questions earlier. Response for
> that inline.
> 
> 
> On 5/12/16 4:58 PM, Nikhil Komawar wrote:
> >
> >
> > On 5/12/16 4:33 PM, Doug Hellmann wrote:
> >> Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
> >>> Please find my response inline:
> >>>
> >>> On 5/12/16 1:10 PM, Doug Hellmann wrote:
>  Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
> > Tim Bell wrote:
> >> [...]
> >> I think it will be really difficult to persuade the mainstream 
> >> projects to adopt
> >> a library if it is not part of Oslo. Developing a common library for 
> >> quota
> >> management outside the scope of the common library framework for 
> >> OpenStack
> >> does not seem to be encouraging the widespread use of delimiter.
> >> [...]
> > I agree it's hard enough to get Oslo libraries used across the board, I 
> > don't think the task would be any easier with an external library.
> >
> > One case that would justify being external is if the library was 
> > generally useful rather than OpenStack-specific: then the Oslo branding 
> > might hinder its out-of-OpenStack adoption. But it doesn't feel like 
> > that is the case here ?
> >
>  In the past we've tried to encourage folks creating very specially
>  focused libraries for which areas where the existing Oslo team has no
>  real experience, such as os-win, to set up their own team. The Oslo team
>  doesn't have to own all libraries.
> >>> Thanks for that pointer!
> >>>
>  On the other hand, in this case I think quota management fits in Oslo as
>  well as messaging or policy do. We have a mechanism in place for managing
>  sub-teams so signing up to work on quotas doesn't have to mean signing
>  up to be oslo-core.
> >>> Yes, I agree that this fits well into the cross-project consistency
> >>> domain. And yes, thanks for proposing the sub-team strategy to move 
> >>> forward.
> >>>
> >>> However, this library currently doesn't exist. We are still identifying
> >>> what we want to achieve as a part of this scope, there's a ton of
> >>> discussions in progress and we are on the advent of finding concrete
> >>> tasks for people to pick up (so no second commit yet). Even after having
> >>> done something we do not know if that's is something which will work for
> >>> all the projects -- basically I am trying to say quotas is a big domain
> >>> and now we are starting (very) small. We need a concrete implementation
> >>> and it's adoption in a couple of projects to even say that it is a
> >>> successful cross project implementation.
> >>>
> >>> The last thing we want to worry about is more process, governance and an
> >>> approach to too-standardize things when we do not even have anything in
> >>> tree. I think it makes sense as a part of somewhere _all_ projects can
> >>> adopt but not until it's ready to be adopted.
> >> I'm not sure what processes you're talking about that might be a burden.
> >> Can you elaborate?
> 
> Currently, I do not have facts but only hints (anticipations, expected
> hick-ups). If you think that's not the case, do you think we can be done
> with all the processes, governance, etc. and yet be able to come up with
> a POC release (dunno something like 0.0.3) within next 5 weeks that can
> be experimented upon in one/two of the projects POC patches? We are
> looking at that timeline and not sure how long the governance and specs
> will take (do we need oslo spec?, how big is the process to setup
> sub-cores? , how do we involve more folks without them thinking of oslo
> standards?, etc.).
> 
> My biggest concern is that this will be seen as something that is an
> attempt to standardize things where we do not even have a standard but
> want to create one. We wish to be agile in our workflow and do not care
> where that exists.

Reading this thread, Nikhil who is speaking for the quota team is worried about
the amount of overhead caused by governance, instead of first focusing on
making something actually exist. I see quite a few people in this thread
speaking up that it should be part of the big tent either standalone or oslo
lib.

I can't speak for the Oslo folks, but as a member of the TC here are the
requirements for the standalone route [1]. You would propose an agenda item to
the TC, and we would review that the project meets those requirements.
Considering the project does Open Design and has an Open Community - my guesses
on "probably would be followed" is Open Development and Open Source since we
don't have anything but a specification that exists to go off of.

It sounds like the biggest hang up in going the oslo route is the oslo spec. So
question to the oslo folks, would you be interested in reviewing the
cross-project specification and allowing to be an oslo lib? That way the team
can focus on working on the library, and 

Re: [openstack-dev] [tc] supporting Go

[Clint Byrum]

Excerpts from Dieterly, Deklan's message of 2016-05-14 01:18:20 +:
> Python 2.x will not be supported for much longer, and let¹s face it,
> Python is easy, but it just does not scale. Nor does Python have the
> performance characteristics that large, distributed systems require. Maybe
> Java could replace Python in OpenStack as the workhorse language.

Which is why we've been pushing toward python 3 for years now. It's
default for python apps in distros now, gates are holding the line at the
unit test level now, so we just need a push toward integration testing
and I truly believe we'll be seeing people use python3 and pypy to run
OpenStack in the next year.

And regarding not scaling: That's precisely what's being discussed,
and it seems like there are plenty of options for pushing python further
that aren't even half explored yet. Meanwhile, if enough people agree,
perhaps go is a good option for those areas where we just can't push
Python further without it already looking like another language anyway.

__
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] supporting Go

[Mark Casey]

Why is that?

Thank you,
Mark

On 5/13/2016 7:21 PM, Dieterly, Deklan wrote:

If we allow Go, then we should also consider allowing JVM based languages.
-- Deklan Dieterly Senior Systems Software Engineer HPE On 5/13/16, 
2:10 PM, "Adam Young"  wrote:

>Can we just up and support Go, please?  I'm a C++ and C buff, but I
>would not inflict either of those on other people, nor would I want to
>support their code. Go is designed to be native but readable/writable.
>
>
>There is nothing perfect in this world.
>
>Python for most things.
>Javascript for web out of necessity
>Go for native tuning.
>
>Yes, Flapper, I like Rust, too, but we have to pick something, and I am
>not the one trying to code this.
>
>It makes sense. Go is already packaged for Fedora and Debian.  We can
>deal with it.
>
>
>
>__
>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-dev] [Higgins] weekly team meeting time

[Hongbin Lu]

Hi all,

As discussed, we are going to hold weekly team meetings. I would like to invite 
you to the Doodle poll "Higgins team weekly meeting", in which you can choose 
your preferred meeting time.

Please follow the link in order to participate in the poll:
http://doodle.com/poll/36mrihhkpxhnf6rf
__
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]ad-hoc meeting of May 16

[Qiming Teng]

Hi,

I was thinking that autoscaling is the topic very relevant to senlin.

Regards,
 Qiming

On Fri, May 13, 2016 at 12:31:42PM +, Bruce Thompson (brucet) wrote:
> Qiming,
> 
> I don¹t think we will be discussing Senlin as part of the agenda in this
> meeting. Is there a Senlin topic that you believe should be covered?
> 
>   Bruce T
> 
> On 5/12/16, 8:37 PM, "Qiming Teng"  wrote:
> 
> >UTC 16:00 is too late for most of senlin developers to join.
> >Still interested in the outcomes from this discussion.
> >
> >Regards,
> >  Qiming
> >
> >On Thu, May 12, 2016 at 11:59:37PM +, Bruce Thompson (brucet) wrote:
> >> Hi,
> >> 
> >> IRC meeting: https://webchat.freenode.net/?channels=tacker on Monday 16
> >>starting from UTC 16:00.
> >> 
> >> Agenda:
> >> # Tacker Ceilometer Monitoring Driver and Autoscaling Sync
> >> 
> >> 
> >> 
> >> Best Regards
> >> Bruce Thompson ( brucet )
> >
> >> 
> >>_
> >>_
> >> 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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Paul Carver]

On Fri, 13 May 2016 17:13:59 -0700
"Armando M."  wrote:

> On 13 May 2016 at 16:10, Elzur, Uri  wrote:
> 
> > Hi Cathy
> >
> >
> >
> > Thank you for the quick response. This is the essence of my
> > question – does Neutron keep OvS as a gold standard and why
> >  
> 
> Not at all true. Neutron, the open source implementation, uses a
> variety of open components, OVS being one of them. If you know of any
> open component that supports NSH readily available today, I'd be
> happy to hear about it.

I agree with Armando and Cathy. There's nothing "gold standard" about
OvS. The networking-sfc approach is to separate the API from the
backend drivers and the OvS driver is only one of several. We have a
place in the API where we expect to capture the tenant's intent to use
NSH.

What we don't currently have is a backend, OvS or other, that supports
NSH. The actual dataplane forwarder is not part of networking-sfc. We
aren't going to maintain the out-of-tree OvS NSH code or depend on it.
When OvS accepts the NSH functionality upstream then our network-sfc
driver will be able to make use of it.

If any other vSwitch/vRouter that already supports NSH and if someone
wants to write a networking-sfc driver for, that code would be welcome.

We've also started discussing how to implement a capabilities discovery
API so that if some backends support a capability (e.g. NSH) and other
backends don't support it, we will provide the tenant with an abstract
way to query the networking-sfc API in order to determine whether
a particular capability can be provided by the current backend.

The thing networking-sfc won't take on is ownership of the
upstream dataplane forwarder projects. We'll simply provide an
abstraction so that a common API can invoke SFC across pre-existing
SFC-capable dataplanes.

__
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][QA] Call to action - Neutron/Tempest API tests dedup

[Assaf Muller]

On Sat, May 14, 2016 at 8:03 AM, zhi  wrote:
> hi, Muller.
>
> As you mentioned, is there will have a individual Tempest plugin named
> "Neutron Tempest plugin" in future?

It already exists :)

http://docs.openstack.org/developer/neutron/devref/development.environment.html#id3

The plugin was contributed by Daniel Mellado and we use it at the gate:
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/neutron.yaml#L34

>
>
> Thanks
> Zhi Chang
>
> 2016-05-14 6:53 GMT+08:00 Assaf Muller :
>>
>> TL;DR: I'm looking for volunteers for tasks 1, 2 and 3 listed below.
>> Help would be hugely appreciated and %(local_drink)s will be bought in
>> Barcelona. I've posted example patches that demonstrate the idea.
>> Needless to say I'm here to provide reviews and to answer questions.
>> Additionally, most of the discussions have been within the Neutron
>> community and I'm looking for feedback from Tempest folks.
>>
>>
>> The context:
>> The Neutron community has been engaged in a long running effort to
>> move some of the networking API tests to the Neutron tree. We started
>> by copying the api/network directory tree, later keeping only the
>> tests, importing the test infrastructure itself from Tempest. We
>> continued by minimizing the imports we do from Tempest (Excluding
>> tempest.lib), and introduced a Neutron Tempest plugin.
>>
>> One issue that remains is that some of the tests are still found in
>> both repositories. This confuses contributors and wastes compute
>> resources. Since the tests run against stable/{liberty|mitaka} and
>> master, it should be safe to dedup. I proposed a line in the sand so
>> that 'core resources' remain to be tested in Tempest and more
>> 'advanced' APIs are tested in Neutron. The concept was agreed upon by
>> the Neutron and (Then) Tempest PTLs, and the specifics were discussed
>> and a consensus was found in patch [2]. Here is the resulting doc for
>> your viewing pleasure [5].
>>
>>
>> The work:
>> After I removed the API tests for core resources from the Neutron
>> tree, there remain three tasks to finish the de-dup:
>>
>> 1*) Remove tests for advanced APIs from Tempest. The full list of
>> tests that I propose be removed from Tempest is tracked here [1] (With
>> the rationale found at [2]), and an example patch may be found here
>> [4].
>> 2) Push tests for Neutron core resources that were added after the
>> fork from Tempest, then delete these from Neutron. This is also
>> tracked in [1], with example patches found here [6]. This is not a
>> strict cut/paste as the way Tempest and Neutron interact with clients
>> is slightly different. Fun!
>> 3) Sync tests for Neutron core resources that were updated after the
>> fork from Tempest. Test modifications include: Bug fixes for raceful
>> tests, py3 fixes, doc string typos and more. This is also tracked in
>> [1], with example patches found here [3].
>>
>> * I believe that as far as the Tempest test removal criteria found at
>> [7], this case falls under the first exception: 'The class of testing
>> has been decided to be outside the scope of tempest' and we may skip
>> the three prong rule for removal. Input welcome.
>>
>> [1] https://etherpad.openstack.org/p/neutron-tempest-defork
>> [2] https://review.openstack.org/#/c/280427/
>> [3] https://review.openstack.org/#/c/316280/ +
>> https://review.openstack.org/#/c/316283/
>> [4] https://review.openstack.org/#/c/316183/
>> [5]
>> docs.openstack.org/developer/neutron/devref/development.environment.html#api-tests
>> [6] https://review.openstack.org/#/c/316265/ +
>> https://review.openstack.org/#/c/316269/
>> [7] https://wiki.openstack.org/wiki/QA/Tempest-test-removal
>>
>> The work is tracked via:
>> * https://review.openstack.org/#/q/topic:bug/1552960
>> * https://bugs.launchpad.net/neutron/+bug/1552960
>> * https://etherpad.openstack.org/p/neutron-tempest-defork
>> * My head
>>
>> __
>> 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] [Docs] Enhance Docs Landing Page Descriptive Text

[Spyros Trigazis]

Hi.

Short answer: Very good idea, I'd like to see the spec.

Slightly longer:
Moving this information to the docs landing page, it will increase the
visibility
of Big Tent projects and it's a way for operators to know what's available.
It
partially addresses our concern about treating Big Tent projects as
OpenStack
first-class citizens in the install-guide. Finally, an operator who want's
to install
a Big Tent project, should be informed about the project's prerequisites as
early
as possible.

Cheers,
Spyros Trigazis
(Member of Magnum)


On 14 May 2016 at 00:08, Laura Clymer  wrote:

> Hi everyone,
>
> In the current Ubuntu install guide, there is this section:
> http://docs.openstack.org/mitaka/install-guide-ubuntu/common/app_support.html
>
> It contains a good deal of description on the type of information
> contained in each of the release-level docs. This type of description is
> very helpful to new users in that it helps them understand where to look
> for information. Given the major re-design for the Install Guide coming up,
> I would like to propose that the text in this section is migrated (and
> perhaps enhanced) to the docs landing page.
>
> I am happy to write up a specification for the suggested text and submit
> it for further review, but I wanted to see if anyone else thinks this is a
> good idea?
>
> Thanks,
>
> Laura Clymer
>
> __
> 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][QA] Call to action - Neutron/Tempest API tests dedup

[zhi]

hi, Muller.

As you mentioned, is there will have a individual Tempest plugin
named "Neutron
Tempest plugin" in future?

Thanks
Zhi Chang

2016-05-14 6:53 GMT+08:00 Assaf Muller :

> TL;DR: I'm looking for volunteers for tasks 1, 2 and 3 listed below.
> Help would be hugely appreciated and %(local_drink)s will be bought in
> Barcelona. I've posted example patches that demonstrate the idea.
> Needless to say I'm here to provide reviews and to answer questions.
> Additionally, most of the discussions have been within the Neutron
> community and I'm looking for feedback from Tempest folks.
>
>
> The context:
> The Neutron community has been engaged in a long running effort to
> move some of the networking API tests to the Neutron tree. We started
> by copying the api/network directory tree, later keeping only the
> tests, importing the test infrastructure itself from Tempest. We
> continued by minimizing the imports we do from Tempest (Excluding
> tempest.lib), and introduced a Neutron Tempest plugin.
>
> One issue that remains is that some of the tests are still found in
> both repositories. This confuses contributors and wastes compute
> resources. Since the tests run against stable/{liberty|mitaka} and
> master, it should be safe to dedup. I proposed a line in the sand so
> that 'core resources' remain to be tested in Tempest and more
> 'advanced' APIs are tested in Neutron. The concept was agreed upon by
> the Neutron and (Then) Tempest PTLs, and the specifics were discussed
> and a consensus was found in patch [2]. Here is the resulting doc for
> your viewing pleasure [5].
>
>
> The work:
> After I removed the API tests for core resources from the Neutron
> tree, there remain three tasks to finish the de-dup:
>
> 1*) Remove tests for advanced APIs from Tempest. The full list of
> tests that I propose be removed from Tempest is tracked here [1] (With
> the rationale found at [2]), and an example patch may be found here
> [4].
> 2) Push tests for Neutron core resources that were added after the
> fork from Tempest, then delete these from Neutron. This is also
> tracked in [1], with example patches found here [6]. This is not a
> strict cut/paste as the way Tempest and Neutron interact with clients
> is slightly different. Fun!
> 3) Sync tests for Neutron core resources that were updated after the
> fork from Tempest. Test modifications include: Bug fixes for raceful
> tests, py3 fixes, doc string typos and more. This is also tracked in
> [1], with example patches found here [3].
>
> * I believe that as far as the Tempest test removal criteria found at
> [7], this case falls under the first exception: 'The class of testing
> has been decided to be outside the scope of tempest' and we may skip
> the three prong rule for removal. Input welcome.
>
> [1] https://etherpad.openstack.org/p/neutron-tempest-defork
> [2] https://review.openstack.org/#/c/280427/
> [3] https://review.openstack.org/#/c/316280/ +
> https://review.openstack.org/#/c/316283/
> [4] https://review.openstack.org/#/c/316183/
> [5]
> docs.openstack.org/developer/neutron/devref/development.environment.html#api-tests
> [6] https://review.openstack.org/#/c/316265/ +
> https://review.openstack.org/#/c/316269/
> [7] https://wiki.openstack.org/wiki/QA/Tempest-test-removal
>
> The work is tracked via:
> * https://review.openstack.org/#/q/topic:bug/1552960
> * https://bugs.launchpad.net/neutron/+bug/1552960
> * https://etherpad.openstack.org/p/neutron-tempest-defork
> * My head
>
> __
> 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] [group-based-policy] Can PTs move to other PTGs?

[Duarte Cardoso, Igor]

Hi GBP,

While I was working on the QoS PoC for GBP I observed that policy targets 
require to be associated to a PTG. They also don't seem to be updatable with a 
different PTG, at least not with the CLI. However, looking at the API I see, 
for policy targets:

'policy_target_group_id': {'allow_post': True, 'allow_put': True,
   'validate': {'type:uuid_or_none': None},
   'required': True, 'is_visible': True},

The PTG seems to be updatable, and can even be None. Both Horizon and the CLI 
don't seem to allow/offer a way to change the PTG or even detach the PT from 
the PTG. So, my questions are, should PTs be allowed to move to other PTGs? Or 
even not belong to any at all? Depending on the answer, should the snippet 
above be corrected?

Best regards,
Igor.

__
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] [tricircle] [Blueprint] Stateless design definition

[Shinobu Kinjo]

Hi Team,

Sorry for this spam -;
Please ignore previous message.

I will file that as a doc bug.

Cheers,
S


On Sat, May 14, 2016 at 3:36 PM, Shinobu Kinjo  wrote:
> Hi Team,
>
> In page1, we define "stateless design" as follows:
>
> Note: Stateless proposal is working on the “experiment” branch:
> https://github.com/openstack/tricircle/tree/experiment
>
> But, in section 7, we define this design as follows:
>
> A PoC was done to verify the feasibility of stateless architecture.
> Since the feedback of this PoC was very positive, sorce codes of the
> stateless design was moved to the master branch of the Tricircle git
> repository
>
> Since that, I am thinking of deleting former description (definition in 
> page1).
>
> Make sense?
>
> Cheers,
> Shinobu
>
> --
> Email:
> shin...@linux.com
> shin...@redhat.com



-- 
Email:
shin...@linux.com
shin...@redhat.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-dev] [tricircle] [Blueprint] Stateless design definition

[Shinobu Kinjo]

Hi Team,

In page1, we define "stateless design" as follows:

Note: Stateless proposal is working on the “experiment” branch:
https://github.com/openstack/tricircle/tree/experiment

But, in section 7, we define this design as follows:

A PoC was done to verify the feasibility of stateless architecture.
Since the feedback of this PoC was very positive, sorce codes of the
stateless design was moved to the master branch of the Tricircle git
repository

Since that, I am thinking of deleting former description (definition in page1).

Make sense?

Cheers,
Shinobu

-- 
Email:
shin...@linux.com
shin...@redhat.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