Re: [openstack-dev] [mistral] September PTG in Denver

[András Kövi]

Hi Dougal,

Very likely, I will join over the phone.

Thanks,
Andras


From: Renat Akhmerov 
Sent: Tuesday, April 24, 2018 2:46:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [mistral] September PTG in Denver

Dougal,

Most likely, I’ll go.

Thanks

Renat Akhmerov
@Nokia

24 апр. 2018 г., 17:05 +0700, Dougal Matthews , писал:


On 23 April 2018 at 20:58, Sean McGinnis 
> wrote:
On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> Hey Dougal,
>
> I think I had said May 2nd in my initial email asking about attendance. If
> you can get an answer out of your team by then I would greatly appreciate
> it! If you need more time please let me know by then (May 2nd) instead.

Whoops - thanks for the correction.

>
> -Kendall (diablo_rojo)
>

Do we need to collect this data for September already by the beginning of May?

Granted, the sooner we know details and can start planning, the better. But as
I started looking over the survey, it just seems really early to predict where
things will be 5 months from now. Especially considering we will have a
different set of PTLs for many projects by then, and it is too early for some
of those hand off discussions to have started yet.

Good question! I don't mean to ask people to commit 100% or not, I just want to 
know their intentions so I have more information when filling out the survey.


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

__
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] Changes to keystone-stable-maint members

[Sean McGinnis]

> >
> >Additions
> >===
> >Lance Bragstad
> >
> >Lance is the PTL and also highly aware (and does reviews for stable
> >keystone when I ask, so we have a second pair of eyes on them) of the
> >differences/stable policy.
> >
> >This will bring us to a solid 2 contributors for Keystone that are
> >looking at the stable-maint reviews and ensuring we're not letting too
> >much sit in limbo (or dumping it all on the main stable-core team).
> >
> >Long term I'd like to see a 3rd keystone stable maint, but I am unsure
> >who else should be nominated. Getting to a full 2 members actively
> >engaged is a big win for ensuring stable branches get appropriate love
> >within Keystone.
> >
> >Cheers,
> >--Morgan
> >
> 
> This looks OK to me. I know Lance is active on stable reviews for Keystone
> and is aware of the guidelines.
> 

I am very comfortable with this too. I know Lance and I have talked over a few
stable backports and he has a good understanding of the policies around those.


__
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] [cyborg]Weekly Team Meeting 2018.04.25

[Zhipeng Huang]

Hi Team,

Team meeting starting UTC1400 as usual at #openstack-cyborg, initial agenda
as follows:

1. KubeCon preparation for resource mgmt wg discussion
2. subteam meeting arrangement for more agile meeting time/logistic
3. Rocky critical spec update
4. open patches/bug review

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [neutron] Change of control over network-onos (was: How to take over a project?)

[Sangho Shin]

Thank you, Jeremy

I did not think that it takes so long. :-)

Sangho


> On 24 Apr 2018, at 11:39 PM, Jeremy Stanley  wrote:
> 
> On 2018-04-20 01:01:33 +0900 (+0900), Sangho Shin wrote:
>> Dear Neutron-Release team,
>> 
>> I wonder if any of you can add me to the network-onos-release member.
>> It seems that Vikram is busy. :-)
> [...]
> 
> I've adjusted the subject line here in hopes the thread might better
> catch their attention.
> -- 
> 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] [tc] campaign question: How can we make contributing to OpenStack easier?

[Zhipeng Huang]

I think many projects are now beginning to develop the sub-team structure
(e.g Nova, Ironic and Cyborg) and that might be part of the answer here.

Having a sub-team structure and also have volunteer as sub team leads could
also help people that are not good at code review to contribute
significantly and get recognized in another way.

On Tue, Apr 24, 2018 at 7:24 PM, Davanum Srinivas  wrote:

> Thierry,
>
> please see below:
>
> On Tue, Apr 24, 2018 at 6:24 AM, Thierry Carrez 
> wrote:
> > Fox, Kevin M wrote:
> >> OpenStack has created artificial walls between the various Projects. It
> shows up, for example, as holes in usability at a user level or extra
> difficulty for operators juggling around so many projects. Users and for
> the most part, Operators don't really care about project organization, or
> ptls, or cores or such.  OpenStack has made some progress this direction
> with stuff like the unified cli. But OpenStack is not very unified.
> >
> > I've been giving this some thought (in the context of a presentation I
> > was giving on hard lessons learned from 8 years of OpenStack). I think
> > that organizing development around project teams and components was the
> > best way to cope with the growth of OpenStack in 2011-1015 and get to a
> > working set of components. However it's not the best organization to
> > improve on the overall "product experience", or for a maintenance phase.
> >
> > While it can be confusing, I like the two-dimensional approach that
> > Kubernetes followed (code ownership in one dimension, SIGs in the
> > other). The introduction of SIGs in OpenStack, beyond providing a way to
> > build closer feedback loops around specific topics, can help us tackle
> > this "unified experience" problem you raised. The formation of the
> > upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
> > we need to push in that direction even more aggressively and start
> > thinking about de-emphasizing project teams themselves.
>
> Big +1. Another thing to check into is how can we split some of the
> work the PTL does into multiple roles ... that are short term and is
> rotated around. Hoping that will help with the problem where we need
> folks to be totally available full time to do meaningful work in a
> project.
>
> > --
> > 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
>
>
>
> --
> 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
>



-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] campaign question: How can we make contributing to OpenStack easier?

[Zane Bitter]

On 24/04/18 12:04, Fox, Kevin M wrote:

Yeah, I agree k8s seems to have hit on a good model where interests are 
separately grouped from the code bases. This has allowed architecture to not to 
be too heavily influenced by the logical groups interest.

I'll go ahead and propose it again since its been a little while. In order to 
start breaking down the barriers between Projects and start working more 
towards integration, should the TC come up with an architecture group? Get 
folks from all the major projects involved in it and sharing common 
infrastructure.

One possible pie in the sky goal of that group could be the following:

k8s has many controllers. But they compile almost all of them into one service. 
the kube-apiserver. Architecturally they could break them out at any point, but 
so far they have been able to scale just fine without doing so. Having them 
combined has allowed much easier upgrade paths for users though. This has 
spurred adoption and contribution. Adding a new controller isn't a huge lift to 
an operator. they just upgrade to the newest version which has the new 
controller built in.

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?


In the pre-containers era one of the most common complaints I heard from 
operators was that they were forced to upgrade stuff in lock-step 
(because of library version dependencies) when they really wanted to 
upgrade each service independently. So this definitely wouldn't work for 
everyone.


Another idea that has been floated on occasion is of combining all of 
the bits of services that run on a compute node (which include parts of 
Nova, Cinder, Neutron, Ceilometer, ) into a single... thing. I wonder 
if that wouldn't be a more interesting place to start.



The idea would be to take Constellations idea one step farther. That the 
Projects would deliver python libraries(and a binary for stand alone operation).


In the sense that we've switched most things with a REST API to running 
in Apache using wsgi, that's _technically_ what's happening already ;)



Constilations would actually provide a code deliverable, not just reference 
architecture, combining the libraries together into a single usable entity. 
Operators most likely would consume the Constilations version rather then the 
individual Project versions.


If I'm reading right, you're suggesting that users who just want a quick 
way to install a small cloud would use a turn-key controller node 
package, while those who need something more sophisticated could 
continue to install the individual services separately?


It's an interesting idea, but users of the first sort have a tendency to 
turn into users of the second sort, and they want a smooth upgrade path 
when that happens. I suspect that's why there aren't any deployment 
tools that use this model, even though there are probably no technical 
obstacles to it even today.



What do you think?


With respect to the db_sync specifically, I think the main problem is 
that it exists at all. You want to be able to do a simple rolling update 
where you start containers containing new versions of the code, and then 
shut down containers containing old versions of the code. Right now you 
have to somehow run db_sync with the new code but make sure it happens 
before starting the service with the new code - and in some cases you 
may have to shut down the old code first. (And as non-conducive as that 
is to orchestrated container deployments, it was 10 times worse 
pre-containers when it was virtually impossible to install the two 
versions of the code side-by-side.) But once your deployment tool has 
solved that horrible problem, it's not difficult for it to add a 
for-loop to do it for every service.


What would be a bigger win would be to get rid of db_sync altogether. It 
was born in an era when we did massive data migrations between versions. 
We've now adopted guidelines for rolling updates saying that we should 
only do fast operations like adding/dropping tables/columns during 
db_sync, and that deprecation periods must permit the DB to be upgraded 
while instances of the previous version of the service are still 
running. Once services comply with those guidelines is there any reason 
we can't just always update the DB schema during service start-up and 
ditch the separate `-manage db_sync` commands? Maybe that would 
be a good project-wide goal for an upcoming release.


cheers,
Zane.

__
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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Zane Bitter]

On 19/04/18 08:59, Harald Jensås wrote:

The problem is getting there using heat ...


The real answer is to make everything explicit - create a Subnet 
resource and a Port resource and don't allow Neutron/Nova to make any 
decisions for you that would have the effect of hiding data that you 
need. However, since that's impractical in this particular case...



a couple of ideas:

a) Use heat's ``external_resource`` to create a port resource,
and then  a external subnet resource. Then get the data
from the external resources. We probably would have to make
it possible for a ``external_resource`` depend on the server
resource, and verify that these resource have the required
attributes.


Yeah, I don't know why we don't allow depends_on for resources with 
external_id. (There's also a bug where we don't recognise dependencies 
contributed by any functions used in the external_id field, like 
get_resource or get_attr, even though we allow those functions.) 
Apparently somebody had a brain explosion at a design summit session 
that nobody remembers attending, and here we are :D


The difficulty is that the fix should be tied to a template version, but 
the offending check is in the template-independent part of the code base.


Nevertheless, a workaround is trivial:

  ext_port:
type: OS::Neutron::Port
external_id: {get_attr: [, addresses, , 0, port]}
metadata:
  do_something_to_add_a_dependency: {get_resource: }


b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
well probably) to include the data.

If we do this we should probably aim to be in parity with
what is made available to clients getting the configuration
from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
etc.)


This makes sense to me. If we're allowing people to let Nova/Neutron 
make implicit choices for them then we also need to allow them to see 
the result.



c) Create a new heat function to read properties of any
openstack resource, without having to make use of the
external_resource in heat.


I'm pretty -1 on this, because I think you want to have the same caching 
behaviour as a resource, not a function. At that point you're just 
implementing syntactic sugar that makes things _less_ consistent, not to 
mention the enormous implementation hacks required.


cheers,
Zane.

__
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] campaign question: How can we make contributing to OpenStack easier?

[Mathieu Gagné]

On Tue, Apr 24, 2018 at 3:51 PM, Fox, Kevin M  wrote:
> I support 12 factor. But 12 factor only works if you can commit to always 
> deploying on top of 12 factor tools. If OpenStack committed to only ever 
> deploying api services on k8s then my answer might be different. but so far 
> has been unable to do that. Barring that, I think simplifying the operators 
> life so you get more users/contributors has priority over pure 12 factor 
> ideals.
>
> It also is about getting Project folks working together to see how their 
> parts fit (or not) in the greater constilation. Just writing a document on 
> how you could fit things together doesn't show the kinds of suffering that 
> actually integrating it into a finished whole could show.
>
> Either way though, I think a unified db-sync would go a long way to making 
> OpenStack easier to maintain as an Operator.

Yes please. Or any task that's remotely similar.

--
Mathieu

__
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] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

I support 12 factor. But 12 factor only works if you can commit to always 
deploying on top of 12 factor tools. If OpenStack committed to only ever 
deploying api services on k8s then my answer might be different. but so far has 
been unable to do that. Barring that, I think simplifying the operators life so 
you get more users/contributors has priority over pure 12 factor ideals.

It also is about getting Project folks working together to see how their parts 
fit (or not) in the greater constilation. Just writing a document on how you 
could fit things together doesn't show the kinds of suffering that actually 
integrating it into a finished whole could show.

Either way though, I think a unified db-sync would go a long way to making 
OpenStack easier to maintain as an Operator.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Tuesday, April 24, 2018 9:13 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

On 04/24/2018 12:04 PM, Fox, Kevin M wrote:
> Could the major components, nova-api, neutron-server, glance-apiserver, etc 
> be built in a way to have 1 process for all of them, and combine the upgrade 
> steps such that there is also, one db-sync for the entire constellation?

So, basically the exact opposite of the 12-factor app design that
"cloud-native" people espouse?

-jay

__
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] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

[Zane Bitter]

On 23/04/18 14:09, Dan Sneddon wrote:


Yes, the port is currently created as part of the Ironic server 
resource. We would have more flexibility if this were a separate Neutron 
port, but we need to be able to support upgrades. This would require the 
ability in Heat to detach the implicit port from the Ironic resource, 
and attach a Neutron port resource with the same IP to a node without 
rebuilding the entire node. This isn't currently possible.


I believe it's possible using a two-step migration. First create an 
OS::Neutron::Port resource with external_id as the current port ID. Then 
use get_resource to pass the ID of the Port explicitly to the Server in 
its network config. On update, Heat will recognise this as an unchanged 
config thanks to the fixes that Harald made in Queens. Second, do 
another update removing the external_id to allow Heat to manage this 
port (or don't, I guess, since Nova will clean up the port when the 
server is deleted regardless).


This process is pretty horrible though, and more suited to a manual 
fix-up than something like TripleO.


I can see another use case for this Heat functionality, which is that I 
would like to be able to generate a report using Heat that lists all the 
ports in use in the entire deployment. This would be generated 
post-deployment, and could be used to populate an external DNS server, 
or simply to report on which IPs belong to which nodes.


You can get IPs from the servers already. (Also, you should use 
Designate resources to populate your external DNS server ;)
The issue here AIUI is that you can't get info from the subnet, like the 
CIDR, and in fact you may not even know the subnet because of the 
magical way Neutron will implicitly allocate stuff for you.


cheers,
Zane.

__
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] Changes to keystone-stable-maint members

[Matt Riedemann]

On 4/24/2018 12:58 PM, Morgan Fainberg wrote:

Hi,

I am proposing making some changes to the Keystone Stable Maint team.
A lot of this is cleanup for contributors that have moved on from
OpenStack. For the most part, I've been the only one responsible for
Keystone Stable Maint reviews, and I'm not comfortable being this
bottleneck

Removals

Dolph Matthews
Steve Martinelli
Brant Knudson

Each of these members have left/moved on from OpenStack, or in the
case of Brant, less involved with Keystone (and I believe OpenStack as
a whole).

Additions
===
Lance Bragstad

Lance is the PTL and also highly aware (and does reviews for stable
keystone when I ask, so we have a second pair of eyes on them) of the
differences/stable policy.

This will bring us to a solid 2 contributors for Keystone that are
looking at the stable-maint reviews and ensuring we're not letting too
much sit in limbo (or dumping it all on the main stable-core team).

Long term I'd like to see a 3rd keystone stable maint, but I am unsure
who else should be nominated. Getting to a full 2 members actively
engaged is a big win for ensuring stable branches get appropriate love
within Keystone.

Cheers,
--Morgan

__
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



This looks OK to me. I know Lance is active on stable reviews for 
Keystone and is aware of the guidelines.


--

Thanks,

Matt

__
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] Changes to keystone-stable-maint members

[Morgan Fainberg]

Hi,

I am proposing making some changes to the Keystone Stable Maint team.
A lot of this is cleanup for contributors that have moved on from
OpenStack. For the most part, I've been the only one responsible for
Keystone Stable Maint reviews, and I'm not comfortable being this
bottleneck

Removals

Dolph Matthews
Steve Martinelli
Brant Knudson

Each of these members have left/moved on from OpenStack, or in the
case of Brant, less involved with Keystone (and I believe OpenStack as
a whole).

Additions
===
Lance Bragstad

Lance is the PTL and also highly aware (and does reviews for stable
keystone when I ask, so we have a second pair of eyes on them) of the
differences/stable policy.

This will bring us to a solid 2 contributors for Keystone that are
looking at the stable-maint reviews and ensuring we're not letting too
much sit in limbo (or dumping it all on the main stable-core team).

Long term I'd like to see a 3rd keystone stable maint, but I am unsure
who else should be nominated. Getting to a full 2 members actively
engaged is a big win for ensuring stable branches get appropriate love
within Keystone.

Cheers,
--Morgan

__
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][Election] Rocky TC Election Voting Begins!

[Jeremy Stanley]

On 2018-04-24 00:03:55 + (+), Kendall Nelson wrote:
> The poll for the TC Election is now open and will remain open until Apr 30,
> 2018 23:45 UTC.
> 
> We are selecting 7 TC members, please rank all candidates in
> your order of preference.
[...]

Please note that the poll was configured slightly incorrectly to
indicate only one winner, but we will be using the resulting ranking
to pick the top 7 candidates to fill the open seats. The poll
description has been amended to mention "the top 7 candidates will
win." We've already had nearly 300 votes cast prior to noticing this
mistake (sorry!), and determined that restarting the poll and
issuing new ballots to everyone would be more disruptive for a
mostly aesthetic benefit.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] Notification update week 17

[Matt Riedemann]

On 4/23/2018 8:07 AM, Balázs Gibizer wrote:

Add versioned notifications for removing a member from a server group
-
The specless bp
https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications 


is pending approval as we would like to see the POC code first. Takashi
has been proposed the POC code https://review.openstack.org/#/c/559076/
so we have to look at it.


I took a look at the patch and am -1 for the new "up-call" introduced 
from the compute service when deleting a server. Overall I'm against 
this blueprint for three reasons:


1. I don't see what need we have for this blueprint since I'm not 
hearing a request from a user for it. Maybe it's just for parity with 
the server group member add notification? I don't think that is 
sufficient justification though.


2. The discussion in the blueprint whiteboard mentions that we don't 
need the remove member notification for rolling back on over-quota 
during server create.


3. The new up-call from nova-compute is a non-starter for me. We need to 
shrink the list of things that perform calls up from a child cell to the 
API database.


--

Thanks,

Matt

__
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-ansible] Proposing Mohammed Naser as core reviewer

[Jesse Pretorius]

On 4/24/18, 4:08 PM, "Jean-Philippe Evrard"  wrote:

>I’d like to propose Mohammed Naser [1] as a core reviewer for 
> OpenStack-Ansible.

A happy +2 from me. (



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] campaign question: How can we make contributing to OpenStack easier?

[Jay Pipes]

On 04/24/2018 12:04 PM, Fox, Kevin M wrote:

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?


So, basically the exact opposite of the 12-factor app design that 
"cloud-native" people espouse?


-jay

__
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] campaign question: How can we make contributing to OpenStack easier?

[Fox, Kevin M]

Yeah, I agree k8s seems to have hit on a good model where interests are 
separately grouped from the code bases. This has allowed architecture to not to 
be too heavily influenced by the logical groups interest.

I'll go ahead and propose it again since its been a little while. In order to 
start breaking down the barriers between Projects and start working more 
towards integration, should the TC come up with an architecture group? Get 
folks from all the major projects involved in it and sharing common 
infrastructure.

One possible pie in the sky goal of that group could be the following:

k8s has many controllers. But they compile almost all of them into one service. 
the kube-apiserver. Architecturally they could break them out at any point, but 
so far they have been able to scale just fine without doing so. Having them 
combined has allowed much easier upgrade paths for users though. This has 
spurred adoption and contribution. Adding a new controller isn't a huge lift to 
an operator. they just upgrade to the newest version which has the new 
controller built in.

Could the major components, nova-api, neutron-server, glance-apiserver, etc be 
built in a way to have 1 process for all of them, and combine the upgrade steps 
such that there is also, one db-sync for the entire constellation?

The idea would be to take Constellations idea one step farther. That the 
Projects would deliver python libraries(and a binary for stand alone 
operation). Constilations would actually provide a code deliverable, not just 
reference architecture, combining the libraries together into a single usable 
entity. Operators most likely would consume the Constilations version rather 
then the individual Project versions.

What do you think?

Thanks,
Kevin


From: Thierry Carrez [thie...@openstack.org]
Sent: Tuesday, April 24, 2018 3:24 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] campaign question: How can we make 
contributing to OpenStack easier?

Fox, Kevin M wrote:
> OpenStack has created artificial walls between the various Projects. It shows 
> up, for example, as holes in usability at a user level or extra difficulty 
> for operators juggling around so many projects. Users and for the most part, 
> Operators don't really care about project organization, or ptls, or cores or 
> such.  OpenStack has made some progress this direction with stuff like the 
> unified cli. But OpenStack is not very unified.

I've been giving this some thought (in the context of a presentation I
was giving on hard lessons learned from 8 years of OpenStack). I think
that organizing development around project teams and components was the
best way to cope with the growth of OpenStack in 2011-1015 and get to a
working set of components. However it's not the best organization to
improve on the overall "product experience", or for a maintenance phase.

While it can be confusing, I like the two-dimensional approach that
Kubernetes followed (code ownership in one dimension, SIGs in the
other). The introduction of SIGs in OpenStack, beyond providing a way to
build closer feedback loops around specific topics, can help us tackle
this "unified experience" problem you raised. The formation of the
upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
we need to push in that direction even more aggressively and start
thinking about de-emphasizing project teams themselves.

--
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 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] [tripleo] The Weekly Owl - 18th Edition

[Emilien Macchi]

Note: this is the eighteenth edition of a weekly update of what happens in
TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn where
we are and what we're doing.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129450.html

+-+
| General announcements |
+-+

+--> Rocky milestone 1 was released last week! We're currently in milestone
2 cycle: https://releases.openstack.org/rocky/schedule.html

+--+
| Continuous Integration |
+--+

+--> Ruck is panda and Rover is quiquell. Please let them know any new CI
issue.
+--> Master promotion is 4 day, Queens is 0 day, Pike is 7 days and Ocata
is 4 days.
+--> Still working on libvirt based multinode reproducer, see
https://goo.gl/DYCnkx
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

+-+
| Upgrades |
+-+

+--> No updates this week, some reviews are still needed.
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Still working on UX and parity topics.
+--> Upgrade job is waiting for a promotion on master to work.
+--> Still prototyping container updates before undercloud deployment.
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> config-download now the default with tripleoclient!
+--> ceph jobs migrated to external_deploy_tasks
+--> CI jobs almost all converted (experimental in progress)
+--> octavia and skydive still in progress
+--> finalizing tripleo-ui integration, tripleo-common patches are now
stable
+--> need workflows to cancel deployment and undeploy
+--> More:
https://etherpad.openstack.org/p/tripleo-config-download-squad-status

+--+
| Integration |
+--+

+--> No updates.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Finishing config-download integration
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> Custom validations/swift storage work.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> Working on neutron sidecar container.
+--> NFV deployments testing config-download.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> No updates.
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> No updates.
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact  |
++

Owls May Have Coexisted With Dinosaurs!
"We do know that owl-like birds like Berruornis and Ogygoptynx lived 60
million years ago, during the Paleocene epoch, which means it's entirely
possible that the ultimate ancestors of owls coexisted with dinosaurs
toward the end of the Cretaceous period.
Technically speaking, owls are one of the most ancient groups of
terrestrial birds, rivaled only by the gamebirds (i.e., chickens, turkeys
and pheasants) of the order Galliformes."
Source: https://www.thoughtco.com/fascinating-facts-about-owls-4107228


Thanks all for reading and stay tuned!
--
Your fellow reporter, Emilien Macchi
__
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] [designate] Meeting Times - change to office hours?

[Ben Nemec]

I prefer 14:00 to 22:00 UTC, although depending on the time of year I 
may have some flexibility on that.


On 04/24/2018 01:37 AM, Erik Olof Gunnar Andersson wrote:
I can do anytime ranging from 16:00 UTC to 03:00 UTC, Mon-Fri, maybe up 
to 07:00 UTC assuming that it's once bi-weekly.



*From:* Jens Harbott 
*Sent:* Monday, April 23, 2018 10:49:25 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [designate] Meeting Times - change to 
office hours?

2018-04-23 13:11 GMT+02:00 Graham Hayes :

Hi All,

We moved our meeting time to 14:00UTC on Wednesdays, but attendance
has been low, and it is also the middle of the night for one of our
cores.

I would like to suggest we have an office hours style meeting, with
one in the UTC evening and one in the UTC morning.

If this seems reasonable - when and what frequency should we do
them? What times suit the current set of contributors?


My preferred range would be 06:00UTC-14:00UTC, Mon-Thu, though
extending a couple of hours in either direction might be possible for
me, too.

If we do alternating times, with the current amount of work happening
we maybe could make each of them monthly, so we end up with a roughly
bi-weekly schedule.

I also have a slight preference for continuing to use one of the
meeting channels as opposed to meeting in the designate channel, if
that is what "office hours style meeting" is meant to imply.

__
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] [openstack-ansible] Proposing Mohammed Naser as core reviewer

[Marc Gariepy]

+2 from me.

Marc Gariépy

On 2018-04-24 11:05 AM, Jean-Philippe Evrard wrote:

Hi everyone,

I’d like to propose Mohammed Naser [1] as a core reviewer for OpenStack-Ansible.

He has been working actively on fixing the telemetry stack, and is now
willing to step up to improve the CentOS platform which is now in a
very degraded state.

I feel that it’s important that he’s able to safeguard the existing
and future work about CentOS
and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mnaser=rocky=person-day

Best regards,

Jean-Philippe Evrard
IRC: evrardjp

__
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] [barbican] Hangout Barbican team

[na...@vn.fujitsu.com]

Hi Barbican team,

In order to be easy for reviewing some patch sets in Barbican, we propose that 
it should have a hangout meeting on 10pm EDT - Monday 30 April. So i would like 
to send an email to notify everyone that feel free to join with us by leaving 
your email.


Cheers,
Nam?

__
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-ansible] Proposing Mohammed Naser as core reviewer

[Amy Marrich]

+2 from me!

Amy (spotz)

On Tue, Apr 24, 2018 at 10:05 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:

> Hi everyone,
>
> I’d like to propose Mohammed Naser [1] as a core reviewer for
> OpenStack-Ansible.
>
> He has been working actively on fixing the telemetry stack, and is now
> willing to step up to improve the CentOS platform which is now in a
> very degraded state.
>
> I feel that it’s important that he’s able to safeguard the existing
> and future work about CentOS
> and help grow the maintenance community for it.
>
> [1] http://stackalytics.com/?module=openstackansible-group;
> user_id=mnaser=rocky=person-day
>
> Best regards,
>
> Jean-Philippe Evrard
> IRC: evrardjp
>
> __
> 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] campaign question: How "active" should the TC be?

[Sean McGinnis]

On Mon, Apr 23, 2018 at 10:12:49PM +, Jeremy Stanley wrote:
> On 2018-04-23 16:56:28 -0500 (-0500), Sean McGinnis wrote:
> [...]
> > I think Howard had an excellent idea of the TC coming up with
> > themes for each cycle. I think that could be used to create a good
> > cadence or focus to make sure we are making progress in key areas.
> > 
> > It struck me that we came up with the long term vision, but there
> > really isn't too much attention paid to it. At least not in a
> > regular way that keeps some of these goals in mind.
> > 
> > We could use the idea of cycle themes to make sure we are
> > targetting key areas of that long term vision to help us move
> > towards bringing that vision to reality.
> 
> So (straw man!) we can make Rocky "the constellations cycle"?
> -- 
> Jeremy Stanley

That sounds good to me. The idea has kind of languished for a while now, but I
think there are a couple of people getting more interested lately and trying to
move forward with a couple more definitions. It might be good to take that
start and try to get some more momentum behind it to get things going.

__
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] [FEMDC] Wed. 25 Apr - FEMDC IRC Meeting 15:00 UTC

[Dimitri Pertin]

Dear all,

Here is a gentle reminder for the FEMDC meeting tomorrow at 15:00 UTC.

A draft of the agenda is available at line 466 and you are very welcome 
to add any item:

https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2018

Best regards,

Dimitri

__
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] [openstack-ansible] Proposing Mohammed Naser as core reviewer

[Jean-Philippe Evrard]

Hi everyone,

I’d like to propose Mohammed Naser [1] as a core reviewer for OpenStack-Ansible.

He has been working actively on fixing the telemetry stack, and is now
willing to step up to improve the CentOS platform which is now in a
very degraded state.

I feel that it’s important that he’s able to safeguard the existing
and future work about CentOS
and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mnaser=rocky=person-day

Best regards,

Jean-Philippe Evrard
IRC: evrardjp

__
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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Eric Fried]

Alex-

On 04/24/2018 09:21 AM, Alex Xu wrote:
> 
> 
> 2018-04-24 20:53 GMT+08:00 Eric Fried  >:
> 
> > The problem isn't just checking the traits in the nested resource
> > provider. We also need to ensure the trait in the exactly same child
> > resource provider.
> 
> No, we can't get "granular" with image traits.  We accepted this as a
> limitation for the spawn aspect of this spec [1], for all the same
> reasons [2].  And by the time we've spawned the instance, we've lost the
> information about which granular request groups (from the flavor) were
> satisfied by which resources - retrofitting that information from a new
> image would be even harder.  So we need to accept the same limitation
> for rebuild.
> 
> [1] "Due to the difficulty of attempting to reconcile granular request
> groups between an image and a flavor, only the (un-numbered) trait group
> is supported. The traits listed there are merged with those of the
> un-numbered request group from the flavor."
> 
> (http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html#proposed-change
> 
> )
> [2]
> 
> https://review.openstack.org/#/c/554305/2/specs/rocky/approved/glance-image-traits.rst@86
> 
> 
> 
> 
> Why we can return a RP which has a specific trait but we won't consume
> any resources on it?
> If the case is that we request two VFs, and this two VFs have different
> required traits, then that should be granular request.

We don't care about RPs we're not consuming resources from.  Forget
rebuild - if the image used for the original spawn request has traits
pertaining to VFs, we folded those traits into the un-numbered request
group, which means the VF resources would have needed to be in the
un-numbered request group in the flavor as well.  That was the
limitation discussed at [2]: trying to correlate granular groups from an
image to granular groups in a trait would require nontrivial invention
beyond what we're willing to do at this point.  So we're limited at
spawn time to VFs (or whatever) where we can't tell which trait belongs
to which.  The best we can do is ensure that the end result of the
un-numbered request group will collectively satisfy all the traits from
the image.  And this same limitation exists, for the same reasons, on
rebuild.  It even goes a bit further, because if there are *other* VFs
(or whatever) that came from numbered groups in the original request, we
have no way to know that; so if *those* guys have traits required by the
new image, we'll still pass.  Which is almost certainly okay.

-efried

__
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][vote]Retire kolla-kubernetes project

[Surya Singh]

+1

As we don't have active core team in Kolla-kubernetes since months,
unfortunately going for sunset is reasonable.

Though happy to help in running OpenStack on kubernetes.

---
Thanks
Surya



On Wed, Apr 18, 2018 at 7:21 AM, Jeffrey Zhang  wrote:
> Since many of the contributors in the kolla-kubernetes project are moved to
> other things. And there is no active contributor for months.  On the other
> hand, there is another comparable project, openstack-helm, in the community.
> For less confusion and disruptive community resource, I propose to retire
> the kolla-kubernetes project.
>
> More discussion about this you can check the mail[0] and patch[1]
>
> please vote +1 to retire the repo, or -1 not to retire the repo. The vote
> will be open until everyone has voted, or for 1 week until April 25th, 2018.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128822.html
> [1] https://review.openstack.org/552531
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] campaign question related to new projects

[Jeremy Stanley]

On 2018-04-24 09:59:57 -0400 (-0400), Zane Bitter wrote:
[...]
> the PTG has limited attendance from operators
[...]

I have high hopes that will not be the case for the next PTG.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [neutron] Change of control over network-onos (was: How to take over a project?)

[Jeremy Stanley]

On 2018-04-20 01:01:33 +0900 (+0900), Sangho Shin wrote:
> Dear Neutron-Release team,
> 
> I wonder if any of you can add me to the network-onos-release member.
> It seems that Vikram is busy. :-)
[...]

I've adjusted the subject line here in hopes the thread might better
catch their attention.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] Proposing Marius Cornea core on upgrade bits

[Marius Cornea]

Thanks everyone for your trust and support.

On Mon, Apr 23, 2018 at 5:35 PM, Emilien Macchi  wrote:
> Thanks everyone for your positive feedback.
> I've updated Gerrit!
>
> Welcome Marius and thanks again for your hard work!
>
> On Mon, Apr 23, 2018 at 4:55 AM, James Slagle 
> wrote:
>>
>> On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi 
>> wrote:
>> > Greetings,
>> >
>> > As you probably know mcornea on IRC, Marius Cornea has been contributing
>> > on
>> > TripleO for a while, specially on the upgrade bits.
>> > Part of the quality team, he's always testing real customer scenarios
>> > and
>> > brings a lot of good feedback in his reviews, and quite often takes care
>> > of
>> > fixing complex bugs when it comes to advanced upgrades scenarios.
>> > He's very involved in tripleo-upgrade repository where he's already
>> > core,
>> > but I think it's time to let him +2 on other tripleo repos for the
>> > patches
>> > related to upgrades (we trust people's judgement for reviews).
>> >
>> > As usual, we'll vote!
>> >
>> > Thanks everyone for your feedback and thanks Marius for your hard work
>> > and
>> > involvement in the project.
>>
>> +1
>>
>>
>> --
>> -- James Slagle
>> --
>>
>> __
>> 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
>
>
>
>
> --
> Emilien Macchi
>
> __
> 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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Alex Xu]

2018-04-24 20:53 GMT+08:00 Eric Fried :

> > The problem isn't just checking the traits in the nested resource
> > provider. We also need to ensure the trait in the exactly same child
> > resource provider.
>
> No, we can't get "granular" with image traits.  We accepted this as a
> limitation for the spawn aspect of this spec [1], for all the same
> reasons [2].  And by the time we've spawned the instance, we've lost the
> information about which granular request groups (from the flavor) were
> satisfied by which resources - retrofitting that information from a new
> image would be even harder.  So we need to accept the same limitation
> for rebuild.
>
> [1] "Due to the difficulty of attempting to reconcile granular request
> groups between an image and a flavor, only the (un-numbered) trait group
> is supported. The traits listed there are merged with those of the
> un-numbered request group from the flavor."
> (http://specs.openstack.org/openstack/nova-specs/specs/
> rocky/approved/glance-image-traits.html#proposed-change)
> [2]
> https://review.openstack.org/#/c/554305/2/specs/rocky/
> approved/glance-image-traits.rst@86


Why we can return a RP which has a specific trait but we won't consume any
resources on it?
If the case is that we request two VFs, and this two VFs have different
required traits, then that should be granular request.


>
>
> __
>

> 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] campaign question related to new projects

[Zane Bitter]

On 24/04/18 05:55, Thierry Carrez wrote:

Zane Bitter wrote:

[...]
I would love to see us have a conversation as a community to figure out
what we all, collectively, think that list should look like and document
it. Ideally new projects shouldn't have to wait until they've applied to
join OpenStack to get a sense of whether we believe they're furthering
our mission or not.


I agree that we are not really (collectively) taking a step back and
looking at the big picture. Forcing myself to work on a map over the
past year really helped me reframe how I perceive OpenStack, and I think
we should do that sort of exercise more often.

What do you think should be the right forum for continuing that
discussion? Is that something you think we should discuss at the
Forum[tm] ? Or more as an asynchronous discussion at the TC level ?


I think we need the widest audience possible, so if I had to pick one 
forum I would tend toward an asynchronous discussions e.g. on the 
mailing list. The Forum has limited attendance from developers, the PTG 
has limited attendance from operators, and both of those offer the 
opportunity for only a comparatively small number of people to speak, so 
I don't recommend that we try to have the discussion primarily 
in-person. It probably doesn't hurt to try to discuss it whenever we can 
with literally anybody who will listen though :)


cheers,
Zane.

__
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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Sylvain Bauza]

Sorry folks for the late reply, I'll try to also weigh in the Gerrit change.

On Tue, Apr 24, 2018 at 2:55 PM, Jay Pipes  wrote:

> On 04/23/2018 05:51 PM, Arvind N wrote:
>
>> Thanks for the detailed options Matt/eric/jay.
>>
>> Just few of my thoughts,
>>
>> For #1, we can make the explanation very clear that we rejected the
>> request because the original traits specified in the original image and the
>> new traits specified in the new image do not match and hence rebuild is not
>> supported.
>>
>
> I believe I had suggested that on the spec amendment patch. Matt had
> concerns about an error message being a poor user experience (I don't
> necessarily disagree with that) and I had suggested a clearer error message
> to try and make that user experience slightly less sucky.
>
> For #3,
>>
>> Even though it handles the nested provider, there is a potential issue.
>>
>> Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), another
>> one with some kind of offload feature(VF2).(Described by alex)
>>
>> Initial instance launch happens with VF:1 allocated, rebuild launches
>> with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want
>> the instance to be allocated VF2.
>>
>> But the original allocation happens against VF1 and since in rebuild the
>> original allocations are not changed, we have wrong allocations.
>>
>
> Yep, that is certainly an issue. The only solution to this that I can see
> would be to have the conductor ask the compute node to do the pre-flight
> check. The compute node already has the entire tree of providers, their
> inventories and traits, along with information about providers that share
> resources with the compute node. It has this information in the
> ProviderTree object in the reportclient that is contained in the compute
> node resource tracker.
>
> The pre-flight check, if run on the compute node, would be able to grab
> the allocation records for the instance and determine if the required
> traits for the new image are present on the actual resource providers
> allocated against for the instance (and not including any child providers
> not allocated against).
>
>
Yup, that. We also have pre-flight checks for move operations like live and
cold migrations, and I'd really like to keep all the conditionals in the
conductor, because it knows better than the scheduler which operation is
asked.
I'm not really happy with adding more in the scheduler about "yeah, it's a
rebuild, so please do something exceptional", and I'm also not happy with
having a filter (that can be disabled) calling the Placement API.


> Or... we chalk this up as a "too bad" situation and just either go with
> option #1 or simply don't care about it.


Also, that too. Maybe just provide an error should be enough, nope?
Operators, what do you think ? (cross-calling openstack-operators@)

 -Sylvain


>
> Best,
> -jay
>
> __
> 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] [OSSN-0083] Keystone policy rule "identity:get_identity_providers" was ignored

[Luke Hinds]

Keystone policy rule "identity:get_identity_providers" was ignored
---

### Summary ###
A policy rule in Keystone did not behave as intended leading to a less
secure configuration than would be expected.

### Affected Services / Software ###
OpenStack Identity Service (Keystone) versions through Mitaka, as well
as Newton (<= 10.0.3), and Ocata (<= 11.0.3).

### Discussion ###
Deployments were unaffected by this problem if the default rule was
changed or the "get_identity_providers" rule was manually changed to
be "get_identity_provider" (singular) in keystone's `policy.json`.

A spelling mistake in the default policy configuration caused these
rules to be ignored. As a result operators that attempted to restrict
this API were unlikely to actually enforce it.

### Recommended Actions ###
Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this
fix has been backported to Ocata (11.0.3) and Newton (10.0.3).

Fix any lingering rules: `identity:get_identity_providers` should
be changed to `identity:get_identity_provider`.

### Contacts / References ###
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369
Mailing List : [Security] tag on openstack-dev@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
__
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] [mistral] September PTG in Denver

[Renat Akhmerov]

Dougal,

Most likely, I’ll go.

Thanks

Renat Akhmerov
@Nokia

24 апр. 2018 г., 17:05 +0700, Dougal Matthews , писал:
>
>
> > On 23 April 2018 at 20:58, Sean McGinnis  wrote:
> > > On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> > > > Hey Dougal,
> > > >
> > > > I think I had said May 2nd in my initial email asking about attendance. 
> > > > If
> > > > you can get an answer out of your team by then I would greatly 
> > > > appreciate
> > > > it! If you need more time please let me know by then (May 2nd) instead.
> >
> > Whoops - thanks for the correction.
> >
> > > >
> > > > -Kendall (diablo_rojo)
> > > >
> > >
> > > Do we need to collect this data for September already by the beginning of 
> > > May?
> > >
> > > Granted, the sooner we know details and can start planning, the better. 
> > > But as
> > > I started looking over the survey, it just seems really early to predict 
> > > where
> > > things will be 5 months from now. Especially considering we will have a
> > > different set of PTLs for many projects by then, and it is too early for 
> > > some
> > > of those hand off discussions to have started yet.
> >
> > Good question! I don't mean to ask people to commit 100% or not, I just 
> > want to know their intentions so I have more information when filling out 
> > the survey.
> >
> > >
> > > 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
>
> __
> 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] Bug deputy report

[Takashi Yamamoto]

oops, i forgot to add the critical one.

Critical
https://bugs.launchpad.net/neutron/+bug/1765008 Tempest API tests
failing for stable/queens branch

On Tue, Apr 24, 2018 at 9:11 PM, Takashi Yamamoto  wrote:
> hi,
>
> here's a summary of this week.
>
> RFEs for drivers team:
> https://bugs.launchpad.net/neutron/+bug/1766380 [RFE] Create
> host-routes for routed networks (segments)
> https://bugs.launchpad.net/neutron/+bug/1764738 routed provider
> networks limit to one host
>
> Medium:
> https://bugs.launchpad.net/neutron/+bug/1764330 Cannot set --no-share
> on shared network covered also by "access_as_shared" RBAC policy
> https://bugs.launchpad.net/neutron/+bug/1763627 neutron
> service-provider-list return duplicated entries
> https://bugs.launchpad.net/neutron/+bug/1763604 neutron-ovs-cleanup
> failing when there are too many ports in bridge
> https://bugs.launchpad.net/neutron/+bug/1765452 Unable to use
> project_id as sort_key
>
> Low:
> https://bugs.launchpad.net/neutron/+bug/1765208 IPtables firewall code
> sometimes tries to remove non-existent rules
>
> Wishlist:
> https://bugs.launchpad.net/neutron/+bug/1765519 Add fullstack tests
> for shared networks API
>
> Incomplete / waiting a feedback from the submitter:
> https://bugs.launchpad.net/neutron/+bug/1762708 Unable to ssh/ping IP
> assigned to VM deployed on flat network
> https://bugs.launchpad.net/neutron/+bug/1762733 l3agentscheduler
> doesn't return a response body with POST
> /v2.0/agents/{agent_id}/l3-routers
> https://bugs.launchpad.net/neutron/+bug/1765691 OVN vlan networks use
> geneve tunneling for SNAT traffic
> https://bugs.launchpad.net/neutron/+bug/1765530 VM failed to reboot
> after compute host reboot in Queens

__
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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Jay Pipes]

On 04/23/2018 05:51 PM, Arvind N wrote:

Thanks for the detailed options Matt/eric/jay.

Just few of my thoughts,

For #1, we can make the explanation very clear that we rejected the 
request because the original traits specified in the original image and 
the new traits specified in the new image do not match and hence rebuild 
is not supported.


I believe I had suggested that on the spec amendment patch. Matt had 
concerns about an error message being a poor user experience (I don't 
necessarily disagree with that) and I had suggested a clearer error 
message to try and make that user experience slightly less sucky.



For #3,

Even though it handles the nested provider, there is a potential issue.

Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), 
another one with some kind of offload feature(VF2).(Described by alex)


Initial instance launch happens with VF:1 allocated, rebuild launches 
with modified request with traits=HW_NIC_OFFLOAD_X, so basically we want 
the instance to be allocated VF2.


But the original allocation happens against VF1 and since in rebuild the 
original allocations are not changed, we have wrong allocations.


Yep, that is certainly an issue. The only solution to this that I can 
see would be to have the conductor ask the compute node to do the 
pre-flight check. The compute node already has the entire tree of 
providers, their inventories and traits, along with information about 
providers that share resources with the compute node. It has this 
information in the ProviderTree object in the reportclient that is 
contained in the compute node resource tracker.


The pre-flight check, if run on the compute node, would be able to grab 
the allocation records for the instance and determine if the required 
traits for the new image are present on the actual resource providers 
allocated against for the instance (and not including any child 
providers not allocated against).


Or... we chalk this up as a "too bad" situation and just either go with 
option #1 or simply don't care about it.


Best,
-jay

__
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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Eric Fried]

> The problem isn't just checking the traits in the nested resource
> provider. We also need to ensure the trait in the exactly same child
> resource provider.

No, we can't get "granular" with image traits.  We accepted this as a
limitation for the spawn aspect of this spec [1], for all the same
reasons [2].  And by the time we've spawned the instance, we've lost the
information about which granular request groups (from the flavor) were
satisfied by which resources - retrofitting that information from a new
image would be even harder.  So we need to accept the same limitation
for rebuild.

[1] "Due to the difficulty of attempting to reconcile granular request
groups between an image and a flavor, only the (un-numbered) trait group
is supported. The traits listed there are merged with those of the
un-numbered request group from the flavor."
(http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/glance-image-traits.html#proposed-change)
[2]
https://review.openstack.org/#/c/554305/2/specs/rocky/approved/glance-image-traits.rst@86

__
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] [os-upstream-institute] Prep call for Vancouver today - Minutes

[Ildiko Vancsa]

Hi All,

I would like to thank all of you who were able to join to our planning call 
yesterday for the Vancouver training.

For meeting minutes please visit the following etherpad: 
https://etherpad.openstack.org/p/OUI-AIO-guide-planning

We also recorded the call, so those of you who couldn’t dial in can listen to 
the whole discussion here: 
https://zoom.us/recording/share/7ysh3YPRjhCh8cS7iJcT9EttcJ7cC3IBIpgshOCD9CuwIumekTziMw

As we have only a couple of weeks and a lot of tasks to complete left, please 
look in to the corresponding StoryBoard project and pick an item to complete: 
https://storyboard.openstack.org/#!/project/913

We are planning one more sync call the week of the training. We are aiming for 
May 14 at 2200 UTC, but it’s still subject to change so stay tuned for further 
info.

Also please note that __until the Vancouver training we will keep all our 
meetings on Mondays at 2000 UTC__.

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)


> On 2018. Apr 23., at 22:08, Ildiko Vancsa  wrote:
> 
> Hi Training Team,
> 
> It is a friendly reminder that we will have a conference call on Zoom today 
> at 2200 UTC as opposed to the weekly meeting to better sync up before the 
> training in Vancouver.
> 
> You can find the call details here: 
> https://etherpad.openstack.org/p/openstack-upstream-institute-meetings
> 
> Please let me know if you have any questions.
> 
> Thanks,
> Ildikó
> (IRC: ildikov)
> 
> 


__
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] TC Report 18-17

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-17.html

The main TC-related activity over the past week has been the
[elections](https://governance.openstack.org/election/) currently in
progress. A quiet campaigning period burst into late activity with a
series of four questions posted in email by Doug Hellman:

* [campaign question related to new
  
projects](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129622.html)
* [How "active" should the TC
  
be?](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129658.html)
* [How should we handle projects with overlapping feature
  
sets?](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html)
* [How can we make  contributing to OpenStack
  
easier?](http://lists.openstack.org/pipermail/openstack-dev/2018-April/129664.html)

I feel we should be working with these sorts of questions and
conversations more frequently. There are many good ideas and
observations in the threads.

Voting continues until the end of the day on April 30th. If you're
eligible to vote, please do. You should receive an email with the
subject "Poll: Rocky TC Election" that includes a link to vote. If
you feel you are eligible but did not receive a link contact the
[election
officials](https://governance.openstack.org/election/#election-officials).

Acknowledgement that OpenStack needs to make some changes, and
willingness to consider new options is evident in the above emails.
These are interesting times and your vote will help drive change.

Through the week there have been many different bits of conversation
related to the election. [Scan the
logs](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/index.html)
to get all the details.

There have been a few other topics throughout the week.

# Python 3

There's been [some
discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-17.log.html#t2018-04-17T11:56:56)
on how to proceed with the migration to Python 3, including [a
review](https://review.openstack.org/#/c/561922/) to allow projects
to choose to only support Python 3. There are some differences of
opinion on this, some of which are driven by positions on the extent
to which the upstream OpenStack community should adapt its schedule
to the velocity of downstreams (in this case, RHEL).

# Kolla K8s

The fate of the kolla-kubernetes repo remained a big topic of
conversation. More people are getting involved, leading to some more
informed decisions. See discussion on
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-18.log.html#t2018-04-18T12:31:35)
(including quite a bit about the use of containers in OpenStack, for
OpenStack) and
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-19.log.html#t2018-04-19T15:01:03)

# Next

If I get elected to another term on the TC I plan to continue
writing these weekly reports, and even if not I'll endeavor to keep
track of things and report on the highlights, but perhaps less
regularly.  However, for the next two weeks there will be no
reporting: my brother is visiting and I'm going to take some time
off with him to walk around and think about something besides
OpenStack. I'll pick things back up in mid-May.

--
Chris Dent   ٩◔̯◔۶   https://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

[openstack-dev] [neutron] Bug deputy report

[Takashi Yamamoto]

hi,

here's a summary of this week.

RFEs for drivers team:
https://bugs.launchpad.net/neutron/+bug/1766380 [RFE] Create
host-routes for routed networks (segments)
https://bugs.launchpad.net/neutron/+bug/1764738 routed provider
networks limit to one host

Medium:
https://bugs.launchpad.net/neutron/+bug/1764330 Cannot set --no-share
on shared network covered also by "access_as_shared" RBAC policy
https://bugs.launchpad.net/neutron/+bug/1763627 neutron
service-provider-list return duplicated entries
https://bugs.launchpad.net/neutron/+bug/1763604 neutron-ovs-cleanup
failing when there are too many ports in bridge
https://bugs.launchpad.net/neutron/+bug/1765452 Unable to use
project_id as sort_key

Low:
https://bugs.launchpad.net/neutron/+bug/1765208 IPtables firewall code
sometimes tries to remove non-existent rules

Wishlist:
https://bugs.launchpad.net/neutron/+bug/1765519 Add fullstack tests
for shared networks API

Incomplete / waiting a feedback from the submitter:
https://bugs.launchpad.net/neutron/+bug/1762708 Unable to ssh/ping IP
assigned to VM deployed on flat network
https://bugs.launchpad.net/neutron/+bug/1762733 l3agentscheduler
doesn't return a response body with POST
/v2.0/agents/{agent_id}/l3-routers
https://bugs.launchpad.net/neutron/+bug/1765691 OVN vlan networks use
geneve tunneling for SNAT traffic
https://bugs.launchpad.net/neutron/+bug/1765530 VM failed to reboot
after compute host reboot in Queens

__
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] campaign question: How can we make contributing to OpenStack easier?

[Davanum Srinivas]

Thierry,

please see below:

On Tue, Apr 24, 2018 at 6:24 AM, Thierry Carrez  wrote:
> Fox, Kevin M wrote:
>> OpenStack has created artificial walls between the various Projects. It 
>> shows up, for example, as holes in usability at a user level or extra 
>> difficulty for operators juggling around so many projects. Users and for the 
>> most part, Operators don't really care about project organization, or ptls, 
>> or cores or such.  OpenStack has made some progress this direction with 
>> stuff like the unified cli. But OpenStack is not very unified.
>
> I've been giving this some thought (in the context of a presentation I
> was giving on hard lessons learned from 8 years of OpenStack). I think
> that organizing development around project teams and components was the
> best way to cope with the growth of OpenStack in 2011-1015 and get to a
> working set of components. However it's not the best organization to
> improve on the overall "product experience", or for a maintenance phase.
>
> While it can be confusing, I like the two-dimensional approach that
> Kubernetes followed (code ownership in one dimension, SIGs in the
> other). The introduction of SIGs in OpenStack, beyond providing a way to
> build closer feedback loops around specific topics, can help us tackle
> this "unified experience" problem you raised. The formation of the
> upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
> we need to push in that direction even more aggressively and start
> thinking about de-emphasizing project teams themselves.

Big +1. Another thing to check into is how can we split some of the
work the PTL does into multiple roles ... that are short term and is
rotated around. Hoping that will help with the problem where we need
folks to be totally available full time to do meaningful work in a
project.

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



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

Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier?

[Thierry Carrez]

Fox, Kevin M wrote:
> OpenStack has created artificial walls between the various Projects. It shows 
> up, for example, as holes in usability at a user level or extra difficulty 
> for operators juggling around so many projects. Users and for the most part, 
> Operators don't really care about project organization, or ptls, or cores or 
> such.  OpenStack has made some progress this direction with stuff like the 
> unified cli. But OpenStack is not very unified.

I've been giving this some thought (in the context of a presentation I
was giving on hard lessons learned from 8 years of OpenStack). I think
that organizing development around project teams and components was the
best way to cope with the growth of OpenStack in 2011-1015 and get to a
working set of components. However it's not the best organization to
improve on the overall "product experience", or for a maintenance phase.

While it can be confusing, I like the two-dimensional approach that
Kubernetes followed (code ownership in one dimension, SIGs in the
other). The introduction of SIGs in OpenStack, beyond providing a way to
build closer feedback loops around specific topics, can help us tackle
this "unified experience" problem you raised. The formation of the
upgrades SIG, or the self-healing SIG is a sign that times change. Maybe
we need to push in that direction even more aggressively and start
thinking about de-emphasizing project teams themselves.

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

Re: [openstack-dev] [tc] campaign question: How "active" should the TC be?

[Thierry Carrez]

Zane Bitter wrote:
> [...]> I definitely don't want to get rid of office hours, and I think the
> reasons for dropping the meeting (encouraging geographically diverse
> participation) are still valid. I'd like to see the TC come up with a
> program of work for the term after each Summit, and actively track the
> progress of it using asynchronous tools - perhaps Storyboard supported
> by follow-ups on the mailing list.

FWIW we did translate the work items we discussed in Dublin into a set
of StoryBoard stories at:

https://storyboard.openstack.org/#!/project/923

But it's pretty recent :)

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

Re: [openstack-dev] [mistral] September PTG in Denver

[Dougal Matthews]

On 23 April 2018 at 20:58, Sean McGinnis  wrote:

> On Mon, Apr 23, 2018 at 07:32:40PM +, Kendall Nelson wrote:
> > Hey Dougal,
> >
> > I think I had said May 2nd in my initial email asking about attendance.
> If
> > you can get an answer out of your team by then I would greatly appreciate
> > it! If you need more time please let me know by then (May 2nd) instead.
>

Whoops - thanks for the correction.


> >
> > -Kendall (diablo_rojo)
> >
>
> Do we need to collect this data for September already by the beginning of
> May?
>
> Granted, the sooner we know details and can start planning, the better.
> But as
> I started looking over the survey, it just seems really early to predict
> where
> things will be 5 months from now. Especially considering we will have a
> different set of PTLs for many projects by then, and it is too early for
> some
> of those hand off discussions to have started yet.
>

Good question! I don't mean to ask people to commit 100% or not, I just
want to know their intentions so I have more information when filling out
the survey.


>
> 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
>
__
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] campaign question related to new projects

[Thierry Carrez]

Zane Bitter wrote:
> [...]
> I would love to see us have a conversation as a community to figure out
> what we all, collectively, think that list should look like and document
> it. Ideally new projects shouldn't have to wait until they've applied to
> join OpenStack to get a sense of whether we believe they're furthering
> our mission or not.

I agree that we are not really (collectively) taking a step back and
looking at the big picture. Forcing myself to work on a map over the
past year really helped me reframe how I perceive OpenStack, and I think
we should do that sort of exercise more often.

What do you think should be the right forum for continuing that
discussion? Is that something you think we should discuss at the
Forum[tm] ? Or more as an asynchronous discussion at the TC level ?

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

Re: [openstack-dev] [tc] campaign question: How should we handle projects with overlapping feature sets?

[Thierry Carrez]

Rico Lin wrote:
> I think we have a start now with providing a decent map to show services
> in OpenStack and fill in with projects. What we should have and will be
> nice is to ask projects to search through the map (with a brief
> introduction of services) when they're registering. To prevent
> overlapping from the very beginning seems to be the most ideal, which
> might also mean it's actually our responsibility to search through what
> exactly a project aims to and what kind of feature it will provide when
> we allow people to register a project.

I like the idea of asking a new project to tell us where they expect to
fit in the OpenStack Map[1]. Projects don't exist in a vacuum and the
more they fit in the existing layout / buckets the best the overall
"product" (framework of cooperating components) will look.

Personally I find that every time I have trouble placing a new project
on the map, it's symptomatic of a deeper issue (like unclear scope /
usage definition) that needs to be discussed early rather than late.

[1] https://www.openstack.org/openstack-map

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

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 15:36:32 +0100:
>> I think as an add on to this, would to ask the board to talk to members
>> and see what contributions they have made to the technical side of
>> OpenStack.
>>
>> This should not just be Number of commits / reviews / bugs etc but
>> also the motivation for the work, e.g. - Feature for a product, bug fix
>> found in a product, cross project work or upstream project maintenance.
> 
> A while back Jay Pipes suggested that we ask contributing companies
> to summarize their work. I think that was in the context of
> understanding what platinum members are doing, but it could apply
> to everyone. By leaving the definition of "contribution" open-ended
> and asking as a way to celebrate those contributions, we could avoid
> any sense of shaming as well as see what the companies consider to
> be important.

Yes, we discussed this in Sydney and I took the action to try to include
it in the Foundation annual report. You can find the result in the
Foundation annual report this year:

https://www.openstack.org/assets/reports/OpenStack-AnnualReport2017.pdf

See pages 7-9. Obviously not optimal (not everybody answered, and some
of the responses are a bit off-topic), but we had limited time to pull
it off and I think it's a good first step. We can take that as a basis
for the next stage of discussion.

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

Re: [openstack-dev] [neutron] Gate-failure bugs spring cleaning

[Jakub Libosvar]

On 21/04/2018 14:16, Slawomir Kaplonski wrote:
> Hi Neutrinos,
> 
> There is time for some spring cleaning now so I went through list of Neutron 
> bugs with „gate-failure” tag https://tinyurl.com/y826rccx 
> I mark some of them as incomplete if there was not hits of same errors in 
> last 30 days. Please reopen them with proper comment if You think that it is 
> still valid bug or if You will spot similar error in some recent test runs.
> 
> About some of them I’m not sure if are still valid so please check it and 
> maybe update comment or close it if it’s already fixed somehow :)
> 
> Below detailed summary of bugs which I checked:
> 
> I removed Neutron from affected projects:
> * https://bugs.launchpad.net/tempest/+bug/1660612 
> 
> I marked as incomplete:
> * https://bugs.launchpad.net/neutron/+bug/1687027
> * https://bugs.launchpad.net/neutron/+bug/1693931
> * https://bugs.launchpad.net/neutron/+bug/1676966
> 
> Bugs which needs check of owner:
> * https://bugs.launchpad.net/neutron/+bug/1711463 - @Miguel, is it still 
> valid? Can we close it?
> * https://bugs.launchpad.net/neutron/+bug/1717302 - @Brian, no action since 
> 2017-12-12, is it failing still?
> 
> Bug which IMO should be reported against Cinder instead of Neutron, can 
> someone check and confirm that:
> * https://bugs.launchpad.net/neutron/+bug/1726462 - Is it related to Neutron 
> really, IMO it look like error with Cinder and it happens also in other than 
> neutron jobs, like „devstack-platform-opensuse-tumbleweed” and 
> „nova-multiattach” for example
> 
> Still valid bugs probably:
> * https://bugs.launchpad.net/neutron/+bug/1693950 - not exactly same error 
> but same tests failures I found recently so I think it is still valid to check
> * https://bugs.launchpad.net/neutron/+bug/1756301 - @Miguel: Can You check 
> and confirm that this is still valid
> * https://bugs.launchpad.net/neutron/+bug/1569621 - should be fixed by 
> https://review.openstack.org/#/c/562220/ - @Jakub can You confirm that?

That is correct - it's tracked as a fix for
https://bugs.launchpad.net/neutron/+bug/1708731
> 
> — 
> Best regards
> Slawek Kaplonski
> skapl...@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 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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Balázs Gibizer]

On Tue, Apr 24, 2018 at 9:08 AM, Alex Xu  wrote:



2018-04-24 5:51 GMT+08:00 Arvind N :

Thanks for the detailed options Matt/eric/jay.

Just few of my thoughts,

For #1, we can make the explanation very clear that we rejected the 
request because the original traits specified in the original image 
and the new traits specified in the new image do not match and hence 
rebuild is not supported.


For #2,

Other Cons:
None of the filters currently make other API requests and my 
understanding is we want to avoid reintroducing such a pattern. But 
definitely workable solution.
If the user disables the image properties filter, then traits based 
filtering will not be run in rebuild case

For #3,

Even though it handles the nested provider, there is a potential 
issue.


Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), 
another one with some kind of offload feature(VF2).(Described by 
alex)


Initial instance launch happens with VF:1 allocated, rebuild 
launches with modified request with traits=HW_NIC_OFFLOAD_X, so 
basically we want the instance to be allocated VF2.


But the original allocation happens against VF1 and since in rebuild 
the original allocations are not changed, we have wrong allocations.



Yes, that is the case what I said, and none of #1,2,3,4 and the 
proposal in this threads works also.


The problem isn't just checking the traits in the nested resource 
provider. We also need to ensure the trait in the exactly same child 
resource provider. Or we need to adjust allocations for the child 
resource provider.


I agree that in_tree only ensure that the compute node tree has the 
required traits but it does not take into account that only some of 
those RPs from the tree provides resources for the current allocation. 
The algorithm Eric provided in a previous mail do the filtering for the 
RPs that are part of the instance allocation so that sounds good to me.


I think we should not try to adjust allocations during a rebuild. 
Changing the allocation would mean it is not a rebuild any more but a 
resize.


Cheers,
gibi






for #4, there is good amount of pushback against modifying the 
allocation_candiadates api to not have resources.


Jay:
for the GET 
/resource_providers?in_tree==, 
nested resource providers and allocation pose a problem see #3 above.


I will investigate erics option and update the spec.
--
Arvind N

__
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] [openstack-infra] How to take over a project?

[Sangho Shin]

Dear Neutron-Release team members, 

Can any of you handle the issue below?

Thank you so much for your help in advance.

Sangho


> On 20 Apr 2018, at 10:01 AM, Sangho Shin  wrote:
> 
> Dear Neutron-Release team,
> 
> I wonder if any of you can add me to the network-onos-release member.
> It seems that Vikram is busy. :-)
> 
> Thank you,
> 
> Sangho
> 
> 
> 
>> On 19 Apr 2018, at 9:18 AM, Sangho Shin  wrote:
>> 
>> Ian, 
>> 
>> Thank you so much for your help.
>> I have requested Vikram to add me to the release team. 
>> He should be able to help me. :-)
>> 
>> Sangho
>> 
>> 
>>> On 19 Apr 2018, at 8:36 AM, Ian Wienand  wrote:
>>> 
>>> On 04/19/2018 01:19 AM, Ian Y. Choi wrote:
 By the way, since the networking-onos-release group has no neutron
 release team group, I think infra team can help to include neutron
 release team and neutron release team can help to create branches
 for the repo if there is no reponse from current
 networking-onos-release group member.
>>> 
>>> This seems sane and I've added neutron-release to
>>> networking-onos-release.
>>> 
>>> I'm hesitant to give advice on branching within a project like neutron
>>> as I'm sure there's stuff I'm not aware of; but members of the
>>> neutron-release team should be able to get you going.
>>> 
>>> Thanks,
>>> 
>>> -i
>> 
> 


__
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] [Vitrage] Vitrage graph error

[MinWookKim]

Hello Ifat, 

 

I have not checked the alarm yet. (I think it does not work.)

 

However, i confirmed that the entity graph and the topology do not work.

 

Additionally, the CLI does not seem to work either.

 

I'll check it out with you. : )

 

Thank you.

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, April 24, 2018 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Vitrage] Vitrage graph error

 

Hi Minwook,

 

Is the problem only in the Entity Graph? Do the Alarms view and the
Topology view work?

And what about the CLI?

 

I’ll check it and get back to you.

 

Thanks,

Ifat

 

 

From: MinWookKim  >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
 >
Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'"
 >
Subject: [openstack-dev] [Vitrage] Vitrage graph error

 

Hello Vitrage team,

 

A few days ago I used Devstack to install the Openstack master version,
which included Vitrage.

 

However, I found that the Vitrage graph does not work on the
Vitrage-dashboard.

 

The state of all Vitrage components is active.

 

Could you check it once?

 

Thanks.

 

Best Regards,

 

Minwook.

<>__
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] [publiccloud-wg]KubeCon EU Public Cloud Meetup ?

[Zhipeng Huang]

Hi,

I'm wondering for people who will attend KubeCon EU is there any interest
for a public cloud meetup ? We could discuss many items listed in the ptg
summary I just sent out via the meetup :)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [Vitrage] Vitrage graph error

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Minwook,

Is the problem only in the Entity Graph? Do the Alarms view and the Topology 
view work?
And what about the CLI?

I’ll check it and get back to you.

Thanks,
Ifat


From: MinWookKim 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, 23 April 2018 at 16:02
To: "'OpenStack Development Mailing List (not for usage questions)'" 

Subject: [openstack-dev] [Vitrage] Vitrage graph error

Hello Vitrage team,

A few days ago I used Devstack to install the Openstack master version, which 
included Vitrage.

However, I found that the Vitrage graph does not work on the Vitrage-dashboard.

The state of all Vitrage components is active.

Could you check it once?

Thanks.

Best Regards,

Minwook.
__
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][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

[Alex Xu]

2018-04-24 5:51 GMT+08:00 Arvind N :

> Thanks for the detailed options Matt/eric/jay.
>
> Just few of my thoughts,
>
> For #1, we can make the explanation very clear that we rejected the
> request because the original traits specified in the original image and the
> new traits specified in the new image do not match and hence rebuild is not
> supported.
>
> For #2,
>
> Other Cons:
>
>1. None of the filters currently make other API requests and my
>understanding is we want to avoid reintroducing such a pattern. But
>definitely workable solution.
>2. If the user disables the image properties filter, then traits based
>filtering will not be run in rebuild case
>
> For #3,
>
> Even though it handles the nested provider, there is a potential issue.
>
> Lets say a host with two SRIOV nic. One is normal SRIOV nic(VF1), another
> one with some kind of offload feature(VF2).(Described by alex)
>
> Initial instance launch happens with VF:1 allocated, rebuild launches with
> modified request with traits=HW_NIC_OFFLOAD_X, so basically we want the
> instance to be allocated VF2.
>
> But the original allocation happens against VF1 and since in rebuild the
> original allocations are not changed, we have wrong allocations.
>


Yes, that is the case what I said, and none of #1,2,3,4 and the proposal in
this threads works also.

The problem isn't just checking the traits in the nested resource provider.
We also need to ensure the trait in the exactly same child resource
provider. Or we need to adjust allocations for the child resource provider.



> for #4, there is good amount of pushback against modifying the
> allocation_candiadates api to not have resources.
>
> Jay:
> for the GET /resource_providers?in_tree==,
> nested resource providers and allocation pose a problem see #3 above.
>
> I will investigate erics option and update the spec.
> --
> Arvind N
>
> __
> 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] [designate] Meeting Times - change to office hours?

[Erik Olof Gunnar Andersson]

I can do anytime ranging from 16:00 UTC to 03:00 UTC, Mon-Fri, maybe up to 
07:00 UTC assuming that it's once bi-weekly.


From: Jens Harbott 
Sent: Monday, April 23, 2018 10:49:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] Meeting Times - change to office hours?

2018-04-23 13:11 GMT+02:00 Graham Hayes :
> Hi All,
>
> We moved our meeting time to 14:00UTC on Wednesdays, but attendance
> has been low, and it is also the middle of the night for one of our
> cores.
>
> I would like to suggest we have an office hours style meeting, with
> one in the UTC evening and one in the UTC morning.
>
> If this seems reasonable - when and what frequency should we do
> them? What times suit the current set of contributors?

My preferred range would be 06:00UTC-14:00UTC, Mon-Thu, though
extending a couple of hours in either direction might be possible for
me, too.

If we do alternating times, with the current amount of work happening
we maybe could make each of them monthly, so we end up with a roughly
bi-weekly schedule.

I also have a slight preference for continuing to use one of the
meeting channels as opposed to meeting in the designate channel, if
that is what "office hours style meeting" is meant to imply.

__
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] [all][ptl][release][masakari][murano][qinling][searchlight][zaqar] reminder for rocky-1 milestone deadline

[Sam P]

Hi Doug and ALL,

Thank you for the reminder.
This was my mistake and really
​s
orry for any inconvenience this may have caused.
This will not happen again.​​
​Patches are up to review for following projects.​
>
masakari-monitors
​> ​
masakari

--- Regards,
Sampath


On Sat, Apr 21, 2018 at 3:04 AM, Doug Hellmann 
wrote:

> Excerpts from Doug Hellmann's message of 2018-04-19 09:15:49 -0400:
> > Today is the deadline for proposing a release for the Rocky-1 milestone.
> > Please don't forget to include your libraries (client or otherwise) as
> > well.
> >
> > Doug
>
> A few projects have missed the first milestone tagging deadline:
>
> ​​
>   masakari-monitors
>   masakari
>
>   murano-dashboard
>
>   qinling
>
>   searchlight-ui
>   searchlight
>
>   zaqar-ui
>   zaqar
>
> The policy on missing deadlines this cycle is changing [1]:
>
>   Projects using milestones are expected to tag at least 2 out of
>   the 3 for each cycle, or risk being dropped as an official project.
>   The release team will remind projects that miss the first milestone,
>   and force tags on any later milestones by tagging HEAD at the
>   time of the deadline.
>
> The masakari, murano, qinling, searchlight, and zaqar teams should
> consider this your reminder.
>
> We really don't want to be making decisions for you about what
> constitutes a good release, but we also do not want to have projects
> that are not preparing releases. Please keep up with the deadlines.
>
> Doug
>
> [1] https://review.openstack.org/#/c/561258
>
__
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