Re: [openstack-dev] Call for papers already closed?

[Christian Berendt]

On 02/01/2016 08:46 AM, Wang, Shane wrote:

Yes, I was confused too. The time is yet up.


It should not be closed, but it is at the moment :/ I forwarded my 
previous mail to sum...@openstack.org and hope that somebody can take 
care of this issue.


Christian.

--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
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] Call for papers already closed?

[Wang, Shane]

Yes, I was confused too. The time is yet up.

--
Shane
-Original Message-
From: Christian Berendt [mailto:christ...@berendt.io] 
Sent: Sunday, January 31, 2016 11:43 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Call for papers already closed?

Hello.

I am a little bit confused, according to openstack.org:

FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST)

I tried to edit a submitted talk and got the following message:

Call for speaker closed!

Also I have the following note in my interface:

Warning! You reached presentations submissions limit (3).

Is it not possible to submit more than 3 talks? Anyway, at the moment I only 
have 2 talks (1 submitted be my, 1 submitted by a other person). I am 
submitting the talks for all of my colleagues and we prepared more than 3 talks.

Christian.

--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
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] [mistral] Promoting Anastasia Kuznetsova to core reviewers

[Nikolay Makhotkin]

Hi, great work, Anastasia!

+1 for you!

On Fri, Jan 29, 2016 at 11:27 AM, Lingxian Kong 
wrote:

> +1 from me, welcome Anastasia!
>
> On Fri, Jan 29, 2016 at 9:00 PM, Igor Marnat  wrote:
>
>> Folks,
>> I'm not a core reviewer, but if I was, I'd definitely vote with +1.
>>
>> Good job, Anastasia! Keep going!
>>
>> Regards,
>> Igor Marnat
>>
>> On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) <
>> moshe.eli...@nokia.com> wrote:
>>
>>> A very big +1
>>> 
>>> From: Renat Akhmerov [rakhme...@mirantis.com]
>>> Sent: Friday, January 29, 2016 8:13 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to
>>> core   reviewers
>>>
>>> Team,
>>>
>>> I’d like to promote Anastasia Kuznetsova to the core team. What she’s
>>> been doing for 2 years is hard to overestimate. She’s done a huge amount of
>>> work reviewing code, bugfixing and participating in public discussions
>>> including our IRC channel #openstack-mistral. She is very reliable,
>>> diligent and consistent about her work.
>>>
>>> Please vote.
>>>
>>> Renat Akhmerov
>>> @ Mirantis Inc.
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> *Regards!*
> *---*
> *Lingxian Kong*
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Nikolay
__
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] Call for papers already closed?

[Christian Berendt]

Hello.

I am a little bit confused, according to openstack.org:

FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST)

I tried to edit a submitted talk and got the following message:

Call for speaker closed!

Also I have the following note in my interface:

Warning! You reached presentations submissions limit (3).

Is it not possible to submit more than 3 talks? Anyway, at the moment I 
only have 2 talks (1 submitted be my, 1 submitted by a other person). I 
am submitting the talks for all of my colleagues and we prepared more 
than 3 talks.


Christian.

--
Christian Berendt
Cloud Solution Architect
Mail: bere...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

__
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] [mistral] Team meeting - 02/01/2016

[Renat Akhmerov]

Hi,

This is a reminder about a team meeting that we’ll have today at 16.00 UTC.

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Review M-3 BPs and bugs
Open discussion



Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

[Juvonen, Tomi (Nokia - FI/Espoo)]

Hi Whang Hao,

OPNFV Doctor meeting details can be found here:
https://wiki.opnfv.org/meetings/doctor

Br,
Tomi

From: EXT hao wang [mailto:sxmatch1...@gmail.com]
Sent: Monday, February 01, 2016 9:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] the spec of Add-ServiceGroup-using-Tooz

Hi, dong.wenjuan

Sounds very interesting about "doctor" project. What's timezone about the 
weekly meeting?
I want to join it if I have time by then.

Thanks
Wang Hao


2016-02-01 14:43 GMT+08:00 
mailto:dong.wenj...@zte.com.cn>>:

Hi all,

I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1].

Project doctor[2] in OPNFV community is its upstream.
The goal of this project is to build fault management and maintenance 
framework for high availability of Network Services on top of virtualized 
infrastructure.
The key feature is immediate notification of unavailability of virtualized 
resources from VIM, to process recovery of VNFs on them.

But in Cinder, the service reports it's status with a delay. So I proposed 
adding Tooz as cinder ServiceGroup driver to report the service states without 
a dely.

I'm a new in Cinder. :) So I wants to invite some Cinder exports to discuss 
the spec in the doctor's weekly meeting at 14:00 on Tuesday this week. Is 
anyone interested in it? Thanks~

[1]https://review.openstack.org/#/c/258968/
[2]https://wiki.opnfv.org/doctor



董文娟   Wenjuan Dong

控制器四部 / 无线产品   Controller Dept Ⅳ. / Wireless Product Operation

[icon]

[logo]
上海市浦东新区碧波路889号中兴通讯D3
D3, ZTE, No. 889, Bibo Rd.
T: +86 021 85922M: +86 13661996389
E: dong.wenj...@zte.com.cn
www.ztedevice.com








ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.




__
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] [Cinder] the spec of Add-ServiceGroup-using-Tooz

[hao wang]

Hi, dong.wenjuan

Sounds very interesting about "doctor" project. What's timezone about the
weekly meeting?
I want to join it if I have time by then.

Thanks
Wang Hao


2016-02-01 14:43 GMT+08:00 :

>
> Hi all,
>
> I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1].
>
> Project doctor[2] in OPNFV community is its upstream.
> The goal of this project is to build fault management and maintenance
> framework for high availability of Network Services on top of virtualized
> infrastructure.
> The key feature is immediate notification of unavailability of
> virtualized resources from VIM, to process recovery of VNFs on them.
>
> But in Cinder, the service reports it's status with a delay. So I
> proposed adding Tooz as cinder ServiceGroup driver to report the service
> states without a dely.
>
> I'm a new in Cinder. :) So I wants to invite some Cinder exports to
> discuss the spec in the doctor's weekly meeting at 14:00 on Tuesday this
> week. Is anyone interested in it? Thanks~
>
> [1]https://review.openstack.org/#/c/258968/
> [2]https://wiki.opnfv.org/doctor
>
>
>
> *董文娟   Wenjuan Dong*
>
> 控制器四部 / 无线产品   Controller Dept Ⅳ. / Wireless Product Operation
>
> [image: icon] [image: logo]
> 上海市浦东新区碧波路889号中兴通讯D3
> D3, ZTE, No. 889, Bibo Rd.
> T: +86 021 85922M: +86 13661996389
> E: dong.wenj...@zte.com.cn
> *www.ztedevice.com* 
>
>
>
> 
> ZTE Information Security Notice: The information contained in this mail (and 
> any attachment transmitted herewith) is privileged and confidential and is 
> intended for the exclusive use of the addressee(s).  If you are not an 
> intended recipient, any disclosure, reproduction, distribution or other 
> dissemination or use of the information contained is strictly prohibited.  If 
> you have received this mail in error, please delete it and notify us 
> immediately.
>
>
>
>
> __
> 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] [Cinder] the spec of Add-ServiceGroup-using-Tooz

[dong . wenjuan]

Hi all,

I proposed the spec of Add-ServiceGroup-using-Tooz in Ciner[1].

Project doctor[2] in OPNFV community is its upstream. 
The goal of this project is to build fault management and maintenance 
framework for high availability of Network Services on top of virtualized 
infrastructure. 
The key feature is immediate notification of unavailability of 
virtualized resources from VIM, to process recovery of VNFs on them. 

But in Cinder, the service reports it's status with a delay. So I 
proposed adding Tooz as cinder ServiceGroup driver to report the service 
states without a dely.

I'm a new in Cinder. :) So I wants to invite some Cinder exports to 
discuss the spec in the doctor's weekly meeting at 14:00 on Tuesday this 
week. Is anyone interested in it? Thanks~

[1]https://review.openstack.org/#/c/258968/
[2]https://wiki.opnfv.org/doctor



董文娟   Wenjuan Dong
控制器四部 / 无线产品   Controller Dept Ⅳ. / Wireless Product Operation
 


上海市浦东新区碧波路889号中兴通讯D3
D3, ZTE, No. 889, Bibo Rd.
T: +86 021 85922M: +86 13661996389
E: dong.wenj...@zte.com.cn
www.ztedevice.com



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
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] [Magnum]Remove node object from Magnum

[王华]

Hi all,

I want to remove node object from Magnum. The node object represents either
a bare metal or virtual machine node that is provisioned with an OS to run
the containers, or alternatively,
run kubernetes. Magnum use Heat to deploy the nodes, so it is unnecessary
to maintain node object in Magnum. Heat can do the work for us. The code
about node object is useless now, so let's remove it from Magnum.

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

[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 2/1

[Dugger, Donald D]

Meeting on #openstack-meeting-alt at 1400 UTC (7:00AM MDT)

1) Mid-cycle meetup report back.
2) Spec & BPs & Patches - 
https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
3) Bugs - https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler
4) Opens


--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786



__
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] [stable][trove] Need help with replication API test failures on stable/liberty

[Matt Riedemann]

I opened this bug awhile back:

https://bugs.launchpad.net/trove/+bug/1538506

The periodic stable jobs have been failing for trove on stable/liberty.

It looks like this could be a related change on master that we might 
want to get into stable/liberty, basically to disable these tests:


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

It's not a clean backport. I also see it's related to a 
python-troveclient change, and I'm not really familiar what hoops need 
to be jumped through for those changes on master and troveclient to work 
together, because the troveclient change hasn't been released yet.


Also, trove on master is tested against released versions of troveclient 
whereas trove on stable/liberty is still installing troveclient from 
source, so latest tarball from master.


Anyway, this is a request for help from the trove team to sort some of 
this out. I think we basically just want to skip or remove these tests 
on stable/liberty - they sound like they've been known to be race issues 
and can't be trusted.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova][API] Question about HTTPNotImplementError

[Ken'ichi Ohmichi]

Hi Chen,

The API guideline came from this Nova's implementation.
501 case is not exception of microversion bumping[1] on Nova's rule
now, so I feeling we need a new microversion if changing the 501
response to the other on *current rule*.
However, such microversion seems a little overkill for me.
So I'm not sure when we can change these 501 code.

Thanks
Ken Ohmichi

---
[1]: 
http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion

2016-01-30 4:20 GMT+09:00 Chen CH Ji :
> In reading some API guide line doc [1] seems we should not return 501 to
> client
> but nova still doing so at API layer [2], any discussion before about this
> can be referred ?
>
> [1]https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#use-of-501---not-implemented
> [2]https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L536
>
>
> __
> 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] [api] service type vs. project name for use in headers

[Ken'ichi Ohmichi]

2016-01-28 5:37 GMT+09:00 Ryan Brown :
>>
>> I think we would be better served in selecting these things thinking
>> about the API consumers first.  We already have  enough for them to wade
>> through, the API-WG is making great gains in herding those particular
>> cats, I would hate to see giving back some of that here.
>>
>> so, instead of using examples where we have header names like
>> "OpenStack-Some-[SERVICE_TYPE]-Header", maybe we should suggest
>> "OpenStack-Some-[SERVICE_TYPE or PROJECT_NAME]-Header" as our
>> guideline.
>>
>>
>> I think the listed reviews have it right, only referencing service
>> type.  We have attempted to reduce the visible surface area of project
>> names in a LOT of areas, I do not think this is one that needs to be an
>> exception to that.
>
>
> +1, I prefer service type over project name. Among other benefits, it leaves
> room for multiple implementations without being totally baffling to
> consumers.

+1 from me.
We are working for microversions testing on Tempest side now, and the
testing framework can be useful for all projects which implement
microversions mechanism.
In our idea, each project will pass service_type to the testing
framework and Tempest will send a request with the microversion header
which contains the service_type.
If the guideline doesn't clarify service_type or project_name, the
implementation ways of Tempest are different between projects and
users/developers are confused when implementing new tests.
I am feeling the guideline is for avoiding this kind of situation.

As cdent said on previous mail, the api-wg guideline is just best
practice, not rule.
That seems just a recommendation, so it is nice to clarify it from our
experience.

Thanks
Ken Ohmichi

__
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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Martinx - ジェームズ]

On 31 January 2016 at 18:23, Steve Baker  wrote:
> On 29/01/16 09:45, Martinx - ジェームズ wrote:
>>
>> Guys,
>>
>>   This is important and Kilo is missing it:
>>
>>   https://review.openstack.org/#/c/179989/
>>
>>   Is it possible to backport it to Kilo 2015.1.3?
>>
>>   Currently, I am manually patching Kilo / Heat by using the following
>> diff:
>>
>>
>> https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=811c8714aa2442e68980561d3e8dd435378f164c
>>
>>   But it is a pain to maintain...
>>
>>
> Rather than carrying a backport you can always modify your templates to set
> port_security_enabled via the value_specs property:
>
>   value_specs: {port_security_enabled: false}

WoW! That is cool! I'm gonna try it now! Thank you!

__
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] [keystone][cross-project] Standardized role names and policy

[Adam Young]

On 01/30/2016 08:24 PM, Henry Nash wrote:


On 30 Jan 2016, at 21:55, Adam Young > wrote:


On 01/30/2016 04:14 PM, Henry Nash wrote:

Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples 
of when there is more than one (target) scope check, e.g.: an API 
that might operate on an object that maybe global, domain or project 
specific - in which case you need to “match up with scope checks 
with the object in question”, for example for a given API:


If cloud admin, allow the API
If domain admin and the object is domain or project specific, then 
allow the API

If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m 
not clear how the “scope check in code” will work in this kind of 
situation.
I originally favored an approach that a user would need to get a 
token scoped to a resource in order to affect change on that 
resource, and admin users could get tokens scoped to anything,  but I 
know that makes things harder for Administrators trying to fix broken 
deployments. So I backed off on that approach.


I think the right answer would be that the role check would set some 
value to indicate it was an admin override.  So long as the check 
does not need the actual object from the database, t can perform 
whatever logic we like.


The policy check deep in the code can be as strict or permissive as 
it desires.  If there is a need to re-check the role for an admin 
check there, policy can still do so.  A role check that passes at the 
Middleware level can still be blocked at the in-code level.


"If domain admin and the object is domain or project specific, then 
allow the API" is trh tricky one, but I don't think we even have a 
solution for that now.  Domain1->p1->p2->p3 type hierarchies don't 
allow operations on p3 with a token scoped to Domain1.


So we do actually support things like that, e.g. (from the domain 
specific role additions):


”identity:some_api": role:admin 
and project_domain_id:%(target.role.domain_id)s(which means I’m 
project admin and the domain specific role I am going to manipulate is 
specific to my domain)


….and although we don’t have this in our standard policy, you could 
also write


”identity:some_api": role:admin and 
domain_id:%(target.project.domain_id)s(which means I’m domain 
admin and I can do some operation on any project in my domain)


Yeah, we do some things like this in the Keystone policy file, but not 
in remote services, yet, and it would only work for Domain of the 
project, not for any arbitrary project in the chain under Domain1:  
roles on p1 or P2 would have to be inherited in order to affect any 
change on resources in 3.






I think that in those cases, I would still favor the user getting a 
token from Keystone scoped to p3, and use the 
inherited-role-assignment approach.





Henry

On 30 Jan 2016, at 17:44, Adam Young > wrote:


I'd like to bring people's attention to a Cross Project spec that 
has the potential to really strengthen the security story for 
OpenStack in a scalable way.


"A common policy scenario across all projects" 
https://review.openstack.org/#/c/245629/


The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not 
real humans
{service_type}_admin :  identity_admin, 
compute_admin, network_admin etc.

{service_type}_{api_resource}_manager: identity_user_manager,
   compute_server_manager, 
network_subnet_manager

observer :  read only access
{service_type}_observer  : identity_observer, 
image_observer



Jamie Lennox originally wrote the spec that got the ball rolling, 
and Dolph Matthews just took it to the next level.  It is worth a read.


I think this is the way to go.  There might be details on how to 
get there, but the granularity is about right.
If we go with that approach, we might want to rethink about how we 
enforce policy.  Specifically, I think we should split the policy 
enforcement up into two stages:


1.  Role check.  This only needs to know the service and the api 
resource.  As such, it could happen in middleware.


2. Scope check:  for user or project ownership.  This happens in 
the code where it is currently called.  Often, an object needs to 
be fetched from the database


The scope check is an engineering decision:  Nova developers need 
to be able to say where to find the scope on the virtual machine, 
Cinder developers on the volume objects.


Ideally, The python-*clients, Horizon and other tools would be able 
to determine what capabilities a given token would pr

Re: [openstack-dev] [keystone] changes to keystone-core!

[Lance Bragstad]

++

I'm happy to see this go through! Samuel and Dave have been helping me out
a lot lately. Both make great additions to the team!

On Thu, Jan 28, 2016 at 9:12 AM, Brad Topol  wrote:

> CONGRATULATIONS Dave and Samuel. Very well deserved!!!
>
> --Brad
>
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
>
> [image: Inactive hide details for "Steve Martinelli" ---01/27/2016
> 05:17:12 PM---Hello everyone! We've been talking about this for a lo]"Steve
> Martinelli" ---01/27/2016 05:17:12 PM---Hello everyone! We've been talking
> about this for a long while, and I am very pleased to
>
> From: "Steve Martinelli" 
> To: openstack-dev 
> Date: 01/27/2016 05:17 PM
> Subject: [openstack-dev] [keystone] changes to keystone-core!
> --
>
>
>
> Hello everyone!
>
> We've been talking about this for a long while, and I am very pleased to
> announce that at the midcycle we have made changes to keystone-core. The
> project has grown and our review queue grows ever longer. Effective
> immediately, we'd like to welcome the following new Guardians of the Gate
> to keystone-core:
>
> + Dave Chen (davechen)
> + Samuel de Medeiros Queiroz (samueldmq)
>
> Happy code reviewing!
>
> Steve Martinelli
> OpenStack Keystone Project Team Lead
> __
> 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] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

[gordon chung]

On 30/01/2016 7:54 AM, Dave Walker wrote:
> On 29 January 2016 at 20:36, Jeremy Stanley  wrote:
>> On 2016-01-29 19:34:01 + (+), gordon chung wrote:
>>> hmm.. that's unfortunate... anything we need to update so this doesn't
>>> happen again? or just a matter of lesson learned, let's keep an eye out
>>> next time?
>> Well, I backported the downloadcache removal to the stable/kilo
>> branch after discovering this issue, and while that's too late to
>> solve it for 2015.1.3 it will at least no longer prevent a 2015.1.4
>> tarball from being built.
>>
>>> i guess the question is can users wait (a month?) for next release? i'm
>>> willing to poll operator list (or any list) to query for demand if
>>> that's easier on your end? if there's very little interest we can defer
>>> -- i do have a few patches lined up for next kilo release window so i
>>> would expect another release.
>> I'm perfectly okay uploading a tarball I or someone else builds for
>> this, as long as it's acceptable to leadership from stable branch
>> management, Telemetry and the community at large. Our infrastructure
>> exists to make things more consistent and convenient, but it's there
>> to serve us and so we shouldn't be slaves to it.
> Unless anyone else objects, I'd be really happy if you are willing to
> scp a handrolled tarball.
>
> I'm happy to help validate it's pristine-state locally here.
>
> Thanks Jeremy!
>
> --
> Kind Regards,
> Dave Walker
>
> __
> 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 is fine with me. please let me know if there is anything i can do 
to help. thanks to both for all the work so far.

cheers,

-- 
gord


__
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] [Cinder] Nominating Patrick East to Cinder Core

[John Griffith]

On Sat, Jan 30, 2016 at 12:58 PM, Jay Bryant 
wrote:

> +1. Patrick's contributions to Cinder have been notable since he joined us
> and he is a pleasure to work with!   Welcome to the core team Patrick!
>
> Jay
>
>
> On Fri, Jan 29, 2016, 19:05 Sean McGinnis  wrote:
>
>> Patrick has been a strong contributor to Cinder over the last few
>> releases, both with great code submissions and useful reviews. He also
>> participates regularly on IRC helping answer questions and providing
>> valuable feedback.
>>
>> I would like to add Patrick to the core reviewers for Cinder. Per our
>> governance process [1], existing core reviewers please respond with any
>> feedback within the next five days. Unless there are no objections, I will
>> add Patrick to the group by February 3rd.
>>
>> Thanks!
>>
>> Sean (smcginnis)
>>
>> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>>
>> __
>> 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
>
> ​+1 Patrick would make a great addition IMHO​
__
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] [oslo] nominating Alexis Lee for oslo-core

[Matt Riedemann]

On 1/31/2016 4:24 PM, Matt Riedemann wrote:



On 1/30/2016 3:44 PM, Davanum Srinivas wrote:

Sylvain,

Let's agree to disagree. This works for Oslo, so lets leave it at that.

Also, *please* switch Subject as this is not fair to Alexis's
nomination if you wish to continue.


I agree, and apologize both to Alexis and the broader team for
side-tracking this thread, that wasn't my intent.

I was just curious as to the overall oslo-core vs project-specific core
teams, and trust that oslo-core doesn't overstep their bounds and
approve changes they aren't sure about, much like nova cores shouldn't
approve areas of a very large code base where none of us are experts.


*none of us are experts over the whole thing I meant.



Anyway, let's move on - and sorry again for diverting this.



-- Dims

On Sat, Jan 30, 2016 at 6:55 AM, Sylvain Bauza
 wrote:


Le 30 janv. 2016 09:32, "Julien Danjou"  a écrit :


On Fri, Jan 29 2016, Sylvain Bauza wrote:


While my heart is about that, my brain thinks about some regressions
could
be happening because of a +W even for a small change.


I suggest you read the git-revert manpage then, you might discover
something interesting there. :)



I suggest you look how to revert an RPC API change by thinking of our
continuous deployers, you might discover something interesting there. :)


The "shit happened" (e.g. bad thing merged) rate difference between a
"permission" policy and a "forgiveness" policy is based on my very
precise guessed estimation probably close to +1% in disfavor of
"forgiveness". Right.



I would like to understand your 1% estimate. Do you think that only one
merged change is bad vs. 100 others good ?
If so, how can you be sure that having an expert could not avoid the
problem
?


But at the same time, the velocity rate difference is close to +50% for
that same policy. So I've picked my side. :)



I disagree with you. Say that one change will raise an important gate
issue
if merged.
Of course the change looks good. It's perfectly acceptable from a python
perspective and Jenkins is happy.
Unfortunately, merging that change would create lots of problems
because it
would wedge all the service projects CIs because that would be a
behavioral
change that wouldn't have a backwards compatibility.

If we have your forgiveness policy, it could have this change merged
earlier, sure. But wouldn't you think that all the respective service
projects velocities would be impacted by far more than this single
change ?

-Sylvain


--
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info



__

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









--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

[Matt Riedemann]

On 1/30/2016 3:44 PM, Davanum Srinivas wrote:

Sylvain,

Let's agree to disagree. This works for Oslo, so lets leave it at that.

Also, *please* switch Subject as this is not fair to Alexis's
nomination if you wish to continue.


I agree, and apologize both to Alexis and the broader team for 
side-tracking this thread, that wasn't my intent.


I was just curious as to the overall oslo-core vs project-specific core 
teams, and trust that oslo-core doesn't overstep their bounds and 
approve changes they aren't sure about, much like nova cores shouldn't 
approve areas of a very large code base where none of us are experts.


Anyway, let's move on - and sorry again for diverting this.



-- Dims

On Sat, Jan 30, 2016 at 6:55 AM, Sylvain Bauza  wrote:


Le 30 janv. 2016 09:32, "Julien Danjou"  a écrit :


On Fri, Jan 29 2016, Sylvain Bauza wrote:


While my heart is about that, my brain thinks about some regressions
could
be happening because of a +W even for a small change.


I suggest you read the git-revert manpage then, you might discover
something interesting there. :)



I suggest you look how to revert an RPC API change by thinking of our
continuous deployers, you might discover something interesting there. :)


The "shit happened" (e.g. bad thing merged) rate difference between a
"permission" policy and a "forgiveness" policy is based on my very
precise guessed estimation probably close to +1% in disfavor of
"forgiveness". Right.



I would like to understand your 1% estimate. Do you think that only one
merged change is bad vs. 100 others good ?
If so, how can you be sure that having an expert could not avoid the problem
?


But at the same time, the velocity rate difference is close to +50% for
that same policy. So I've picked my side. :)



I disagree with you. Say that one change will raise an important gate issue
if merged.
Of course the change looks good. It's perfectly acceptable from a python
perspective and Jenkins is happy.
Unfortunately, merging that change would create lots of problems because it
would wedge all the service projects CIs because that would be a behavioral
change that wouldn't have a backwards compatibility.

If we have your forgiveness policy, it could have this change merged
earlier, sure. But wouldn't you think that all the respective service
projects velocities would be impacted by far more than this single change ?

-Sylvain


--
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info



__
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







--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Steve Baker]

On 29/01/16 09:45, Martinx - ジェームズ wrote:

Guys,

  This is important and Kilo is missing it:

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

  Is it possible to backport it to Kilo 2015.1.3?

  Currently, I am manually patching Kilo / Heat by using the following diff:

  
https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=811c8714aa2442e68980561d3e8dd435378f164c

  But it is a pain to maintain...


Rather than carrying a backport you can always modify your templates to 
set port_security_enabled via the value_specs property:


  value_specs: {port_security_enabled: false}

__
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] [ceilometer] ceilometer-powervm translations

[Andreas Jaeger]

I noticed that ceilometer-powervm has translations in the tree but is 
not using our usual translation setup.


Do you want to enable translations using our translation server? Since 
ceilometer-powervm is part of ceilometer, you can make use of our 
infrastructure instead of having to do manually import translations.


Details about setup are at:

http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
https://review.openstack.org/273759

If you have questions, feel free to ask. I'm happy to review your changes,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [senlin] translatin setup

[Andreas Jaeger]

I noticed that senlin and python-senline havepot file in the tree but is 
not using our usual translation setup - and have no translations.


Do you want to enable translations using our translation server? Since 
senlin is an official team under governance, you can make use of that 
instead of having to do manually import translations.


Details about setup are at:

http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
https://review.openstack.org/273759

If you have questions, feel free to ask. I'm happy to review your changes,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][i18n] networking-powervm: Manual Translations?

[Andreas Jaeger]

I noticed that networking-powervm has translations in the tree but is 
not using our usual translation setup.


Do you want to enable translations using our translation server? Since 
networking-powervm is part of neutron, you can make use of that instead 
of having to do manually import translations.


Details about setup are at:

http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
https://review.openstack.org/273759

If you have questions, feel free to ask. I'm happy to review your changes,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] do not account compute resource of instances in state SHELVED_OFFLOADED

[John Garbutt]

On 27 January 2016 at 16:59, Sascha Vogt  wrote:
> Hi Andrew,
>
> Am 27.01.2016 um 10:38 schrieb Andrew Laski:
>> 1. This allows for a poor experience where a user would not be able to
>> turn on and use an instance that they already have due to overquota.
>> This is a change from the current behavior where they just can't create
>> resources, now something they have is unusable.
> That is a valid point, though I think if it's configurable it is up to
> the operator to use that feature.

We need to make sure we don't have configuration values that change
the semantic of our API.
Such things, at a minimum, need to be discoverable, but are best avoided.

>
>> 2. I anticipate a further ask for a separate quota for the number of
>> offloaded resources being used to prevent just continually spinning up
>> and shelving instances with no limit.  Because while disk/ram/cpu
>> resources are not being consumed by an offloaded instance network and
>> volume resources remain consumed and storage is required is Glance for
>> the offloaded disk.  And adding this additional quota adds more
>> complexity to shelving which is already overly complex and not well
>> understood.
> I think an off-loaded / shelved resource should still count against the
> quota being used (instance, allocated floating IPs, disk space etc) just
> not the resources which are no longer consumed (CPU and RAM)

OK, but that does mean unshelve can fail due to qutoa. Maybe thats OK?

> In addition I think it would make sense to introduce a quota for Glance
> and ephemeral disk size and a shelved instance could (should) still
> count against those quotas.

The quota really should live with the project that owns the resource.
i.e. nova has the "ephemeral" disk quota, but glance should have the
glance quota.

Thanks,
John

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

Re: [openstack-dev] [Nova][Neutron] Scheduling with routed networks

[John Garbutt]

On 29 January 2016 at 16:09, Armando M.  wrote
> On 29 January 2016 at 12:16, Jay Pipes  wrote:
>> On 01/28/2016 09:15 PM, Carl Baldwin wrote:
>>>
>>> Hi Nova and Neutron,
>>> It was a pleasure to attend the Nova mid-cycle in Bristol this week.
>> Indeed, I thought the mid-cycle was super-productive.

+1

Many thanks for you both making the journey to be with us.
That was super helpful towards getting a plan for Newton.

> Yup, I always thought that Nova folks had tails, horns and pitchforks...it
> turns out I was wrong!

:-P

>>> I think we made a lot of progress.  I spent a little time capturing
>>> the highlights of what we discussed about scheduling and routed
>>> networks in a new revision to the backlog spec [1] that I created a
>>> couple of weeks ago.
>>>
>>> I also captured my understanding of the discussion we had this
>>> afternoon as things were winding down.  I remember Jay Pipes, Andrew
>>> Laskey, Dan Smith, John Garbutt, and Armando Migliaccio actively
>>> participating in that discussion with me.  I would appreciate it if
>>> you could visit this spec and record any thoughts or conclusions that
>>> I might have missed or mis-understood.
>>
>>
>> Will do for sure. I'll also keep you updated on the progress of the
>> generic-resource-pools work which intersects with the routed networks
>> features.
>
> It's my intention of going over the spec whilst my memory is fresh...I need
> some _light reading_ for my journey back anyway :)

Just traveling back from FOSDEM, but that looks good.

There only major thing left is that niggle around how Neutron updates
claims and the reservation count, but that looks close. I added
comments on the review.

Thanks,
johnthetubaguy

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

Re: [openstack-dev] [puppet] Stepping down from Puppet Core

[Xingchao Yu]

Mathieu,

Thank you for everything you've done during the past years, your excellent work
makes puppet community more better.
And personally, you give me lots of guidance when I get started.
Wish you all the best in the new journey.



2016-01-28 4:13 GMT+08:00 Mathieu Gagné :

> Hi,
>
> I would like to ask to be removed from the core reviewers team on the
> Puppet for OpenStack project.
>
> My day to day tasks and focus no longer revolve solely around Puppet and
> I lack dedicated time to contribute to the project.
>
> In the past months, I stopped actively reviewing changes compared to
> what I used to at the beginning when the project was moved to
> StackForge. Community code of conduct suggests I step down
> considerately. [1]
>
> I'm very proud of what the project managed to achieve in the past
> months. It would be a disservice to the community to pretend I'm still
> able or have time to review changes. A lot changed since and I can no
> longer keep up or pretend I can review changes pedantically or
> efficiently as I used to.
>
> Today is time to formalize and face the past months reality by
> announcing my wish to be removed from the core reviewers team.
>
> I will be available to answer questions or move ownership of anything I
> still have under my name.
>
> Wishing you the best.
>
> Mathieu
>
> [1] http://www.openstack.org/legal/community-code-of-conduct/
>
> __
> 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
>



-- 

Xingchao Yu
__
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] Upstream University: Signup for Mentors and Mentees

[Victoria Martínez de la Cruz]

Hi there!

This is awesome! I participated in previous Upstream Training events and
it's a very exciting and enriching experience. I'm looking forward to join
this time again and I hope to see many people joining this initiative.

Count on me for organization or anything else beyond mentoring.

Best,

Victoria

2016-01-30 16:04 GMT-03:00 Mike Perez :

> Hello all!
>
> I'm trying to gather how much interest there is do an Upstream University
> at
> the Austin summit as we've done at the summits since Paris. Here's an
> excerpt
> from the training guides about the program [1]:
>
> We've designed a training program to help professional developers negotiate
> this hurdle. It shows them how to ensure their bug fix or feature is
> accepted
> in the OpenStack project in a minimum amount of time. The educational
> program
> requires students to work on real-life bug fixes or new features during two
> days of real-life classes and online mentoring, until the work is accepted
> by
> OpenStack. The live two-day class teaches them to navigate the intricacies
> of
> the project's technical tools and social interactions. In a followup
> session,
> the students benefit from individual online sessions to help them resolve
> any
> remaining problems they might have.
>
> In order for this program to be successful, we need mentors and
> students/mentees. If you're available April 23-24 before the summit starts
> in
> Austin, TX and want to help others and mentor or just want to learn more on
> contributing to OpenStack, please sign up and check the box that indicates
> you're interested in the Upstream University.
>
> https://openstackfoundation.formstack.com/forms/mentoring
>
> Even if you're unable to participate, please consider spreading the word so
> this event can be a success!
>
> [1] -
> https://github.com/openstack/training-guides/blob/master/doc/upstream-training/upstream-details.rst#first-day
>
> --
> Mike Perez
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Non-priority Feature Freeze update (including deadlines)

[John Garbutt]

Hi,

We have recently past the deadline for the non-priority Feature Freeze:
http://docs.openstack.org/releases/schedules/mitaka.html#m-nova-npff

We do this to make sure we prioritise review and developer bandwidth
for Bug Fixes and our agreed release priorities:
http://specs.openstack.org/openstack/nova-specs/priorities/mitaka-priorities.html

Many blueprints that were not in a position to merge and/or looked to
have had little review, have already been deferred, and a -2 applied.

If you want a FFE, please justify why on this etherpad:
https://etherpad.openstack.org/p/mitaka-nova-non-priority-ff-tracking

Core reviews, please +2 patches you think deserve a FFE. Let me know
if that means I need to remove a -2 I may have applied.

There are some blueprints I have left in limbo, while I iterate again
through the list of all approved blueprints until will get to a list
that is a sensible size for this point in the release.

Any questions, please do ask (on IRC, or whatever).

Thanks,
johnthetubaguy

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

Re: [openstack-dev] [Horizon] It's already too late for ... Updating XStatic packages

[Thomas Goirand]

On 01/06/2016 06:18 PM, Rob Cresswell (rcresswe) wrote:
> Hi all,
> 
> While the automated system is broken, I’d like to work on manually
> releasing a few of the XStatic packages. This will *only* be the release
> stage; we will still use gerrit to review the package content as usual.
> 
> List of packages current versions, and their upstreams, can be found
> here: https://etherpad.openstack.org/p/horizon-libs
> 
> If anyone has spare time, please consider investigating some of the
> dependencies listed above. To update an XStatic package, propose a
> change to its repo as you would with Horizon; they are all in the
> OpenStack namespace. For example, Xstatic-Angular can be found
> at http://git.openstack.org/cgit/openstack/xstatic-angular/
> 
> Thanks,
> Rob

Guys,

We're now in February, *after* the end of the Beta 2 cycle.

I'd like to remind you that now is *too late already* to update or
change any dependency on Horizon. If you want to do so, please do that
*after* the Mitaka release.

I don't want to suffer spending half of my package maintainer time on
Horizon, in a hurry, at the end of a dev cycle again. These things
should be changed before b1 or at least before b2, not after.

By the way, is there a document where I can see the changes already made?

Cheers,

Thomas Goirand (zigo)


__
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] [Kuryr] IRC Meeting - Monday (2/1) 1500 UTC (#openstack-meeting-4)

[Fawad Khaliq]

On Sun, Jan 31, 2016 at 12:57 PM, Gal Sagie  wrote:

>
> Hello All,
>
> We are going to have an IRC Meeting tomorrow (2/1) at 1500 UTC
> in #openstack-meeting-4
>
> The meeting agenda can be seen here [1].
> We are going to focus most of the meeting on the Kubernetes-Kuryr
> integration.
> You can view the logs from our specific Kuryr-Kubernetes integration IRC
> meeting [2]
>
> Please come with some modeling ideas, i think this topic will take most of
> the time.
>
> I would also like us to discuss about Fawad spec about Magnum-Kuryr
> integration. [3]
> and nested containers support.
>

+1. Thanks Gal. I see good discussion and comments on the spec.
I will resolve the comments before the meeting and add some more
detail.


> I have CCed Adrian/Danyeon from the Magnum team here, hopefully you guys
> can provide some feedback as well.
>
> Thanks and see you there!
> Gal.
>
> [1] https://wiki.openstack.org/wiki/Meetings/Kuryr
> [2]
> http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html
> [3] https://review.openstack.org/#/c/269039/3
>
>
__
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] [Kuryr] IRC Meeting - Monday (2/1) 1500 UTC (#openstack-meeting-4)

[Gal Sagie]

Hello All,

We are going to have an IRC Meeting tomorrow (2/1) at 1500 UTC
in #openstack-meeting-4

The meeting agenda can be seen here [1].
We are going to focus most of the meeting on the Kubernetes-Kuryr
integration.
You can view the logs from our specific Kuryr-Kubernetes integration IRC
meeting [2]

Please come with some modeling ideas, i think this topic will take most of
the time.

I would also like us to discuss about Fawad spec about Magnum-Kuryr
integration. [3]
and nested containers support.

I have CCed Adrian/Danyeon from the Magnum team here, hopefully you guys
can provide some feedback as well.

Thanks and see you there!
Gal.

[1] https://wiki.openstack.org/wiki/Meetings/Kuryr
[2]
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html
[3] https://review.openstack.org/#/c/269039/3
__
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