Re: [openstack-dev] [requirements][docs] updating the minimum version of sphinx

2017-01-24 Thread Andreas Jaeger
On 2017-01-25 08:24, Andreas Jaeger  wrote:
> On 2017-01-25 05:03, Matthew Thode  wrote:
>> On 01/24/2017 09:57 PM, Matthew Thode wrote:
>>> Basically I'd like to ask the docs people if they are fine with updating
>>> the minimum version of sphinx from sphinx>=1.2.1,!=1.3b1,<1.4 to
>>> sphinx>=1.5.1.  This change seems fairly major, especially given that
>>> there is no overlay between the 'before' and 'after' versions.
>>>
>>> I'd appreciate docs team reviews on this.  We plan on having a meeting
>>> soon at 10:00 UTC in #openstack-meeting-alt if you care to join.
>>>
>>> https://review.openstack.org/418772
>>>
>>
>> lesigh, was watching John's talk and mistyped...
>> https://www.youtube.com/watch?v=HRRbogFZEcU
>>
>> retitled...
> 
> 
> Docs is not part of requirements sync and has already switched - so this
> is fine for documentation team.
> 
> Also, translations work fine...
> 
> So, go ahead - I gave my +1 on the review again,

I remember one thing when we switched: Doc team Sphinx Builds error out
on warnings - and sphinx 1.5 gives a warning about :option: usage
without a corresponding ".. option::" declaration.

Looking at
http://codesearch.openstack.org/?q=%3Aoption%3A=nope==

We have quite a few projects that use :option: - and if those have
warnings enabled, will fail.

So, might be better to do this after the Ocata release,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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] [neutron] change in argument type for allocate_partially_specified_segment

2017-01-24 Thread Anna Taraday
I pushed https://review.openstack.org/#/c/425023 as one of approaches.

On Wed, Jan 25, 2017 at 10:29 AM Anna Taraday 
wrote:

> Thanks for bringing this up!
>
> I was assuming that from Ocata everyone should switch from usage 'old'
> TunnelTypeDriver to updated one.
>
> Revering both back to session means reverting all refactor and this is not
> in line with enginefacade work and as I remember some of OVO patches we
> waiting for this refactor too.
>
> I we can duplicate methods or we can check type of the argument if session
> or context and proceed differently. I will push patch for this ASAP.
>
> On Wed, Jan 25, 2017 at 2:15 AM Ihar Hrachyshka 
> wrote:
>
>> Hi Anna,
>>
>> I see that as part of [1], we changed the argument type for the $subj
>> function from session to context. Sadly, it turns out we still call it
>> with a session from the 'old' TunnelTypeDriver. I suspect the same
>> issue may affect allocate_fully_specified_segment.
>>
>> I assume that means all 'old' tunnel type drivers are broken. Should
>> we fix it by duplicating those two functions for old and new cases
>> too? Or should we revert both of them back to session? (I assume the
>> former, since the latter is not in line with enginefacade work.)
>>
>> [1]
>> https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py
>>
>> Thanks in advance,
>> Ihar
>>
> --
> Regards,
> Ann Taraday
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [requirements][docs] updating the minimum version of sphinx

2017-01-24 Thread Andreas Jaeger
On 2017-01-25 05:03, Matthew Thode  wrote:
> On 01/24/2017 09:57 PM, Matthew Thode wrote:
>> Basically I'd like to ask the docs people if they are fine with updating
>> the minimum version of sphinx from sphinx>=1.2.1,!=1.3b1,<1.4 to
>> sphinx>=1.5.1.  This change seems fairly major, especially given that
>> there is no overlay between the 'before' and 'after' versions.
>>
>> I'd appreciate docs team reviews on this.  We plan on having a meeting
>> soon at 10:00 UTC in #openstack-meeting-alt if you care to join.
>>
>> https://review.openstack.org/418772
>>
> 
> lesigh, was watching John's talk and mistyped...
> https://www.youtube.com/watch?v=HRRbogFZEcU
> 
> retitled...


Docs is not part of requirements sync and has already switched - so this
is fine for documentation team.

Also, translations work fine...

So, go ahead - I gave my +1 on the review again,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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] [infra] Problem with Jenkins

2017-01-24 Thread Anastasiya Balobashina
Hello!

I have 2 similar patches with different change_id. On the first case
Jenkins has failed: https://review.openstack.org/#/c/422481/ , on the
second case Jenkins has successfully passed:https://review.openstack.org/#
/c/424553/ . I can not understand the reason for it. Besides all test that
failed in the first case was run in the same thread.  Can anybody help me?

-- 
Best regards,
Balobashina Anastasia
__
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] change in argument type for allocate_partially_specified_segment

2017-01-24 Thread Anna Taraday
Thanks for bringing this up!

I was assuming that from Ocata everyone should switch from usage 'old'
TunnelTypeDriver to updated one.

Revering both back to session means reverting all refactor and this is not
in line with enginefacade work and as I remember some of OVO patches we
waiting for this refactor too.

I we can duplicate methods or we can check type of the argument if session
or context and proceed differently. I will push patch for this ASAP.

On Wed, Jan 25, 2017 at 2:15 AM Ihar Hrachyshka  wrote:

> Hi Anna,
>
> I see that as part of [1], we changed the argument type for the $subj
> function from session to context. Sadly, it turns out we still call it
> with a session from the 'old' TunnelTypeDriver. I suspect the same
> issue may affect allocate_fully_specified_segment.
>
> I assume that means all 'old' tunnel type drivers are broken. Should
> we fix it by duplicating those two functions for old and new cases
> too? Or should we revert both of them back to session? (I assume the
> former, since the latter is not in line with enginefacade work.)
>
> [1]
> https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py
>
> Thanks in advance,
> Ihar
>
-- 
Regards,
Ann Taraday
__
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] Nova API sub-team meeting

2017-01-24 Thread Alex Xu
Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.

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


Re: [openstack-dev] [networking-sfc]

2017-01-24 Thread Michael Gale
Hello Bernard,
I believe the design docs and API parts are good and once I had the
environment up and running I didn't have any problems following the
examples or running the commands.

My biggest hurdle was around getting the devstack environment functioning,
I was following the steps here:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

I think the issues are related to using Ubuntu 16.04 instead of Ubuntu
14.04 and devstack now recommends 16.04. So the OVS steps seem out of place
and in my local.conf file I needed to set:
--snip--
export SFC_UPDATE_OVS=False
# Disable security groups
Q_USE_SECGROUP=False
LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
enable_plugin networking-sfc git://
git.openstack.org/openstack/networking-sfc stable/newton
--snip--

This could be related to my lack of experience with Devstack, also I was
concerned with having to set SFC_UPDATE_OVS=False in the configuration. Is
this affecting the underlying functionality of SFC.

Also the link to the Horizon add-on would be great.

Thanks
Michael


On Tue, Jan 24, 2017 at 6:30 AM, Bernard Cafarelli 
wrote:

> On 20 January 2017 at 00:06, Michael Gale  wrote:
> > Hello,
> >
> > Are there updated install docs for sfc? The only install steps for a
> > testbed I can find are here and they seem outdated:
> > https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
> There is also a SFC chapter in the networking guide:
> http://docs.openstack.org/newton/networking-guide/config-sfc.html
>
> Which parts do you find outdated? Some references to Ubuntu/OVS
> versions may need a cleanup, but the design and API parts should still
> be OK
> (OSC client, SFC graph API, symmetric ports and other goodies are
> still under review and not yed merged)
>
> > Also from the conference videos there seems to be some Horizon menu /
> > screens that are available?
> Not for networking-sfc directly, but there is a SFC tab in the tacker
> horizon plugin (or will be, someone from the tacker team can confirm
> that)
>
>
> --
> Bernard Cafarelli
>
> __
> 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
>



-- 

“The Man who says he can, and the man who says he can not.. Are both
correct”
__
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] Announcing my PTL candidacy for Pike

2017-01-24 Thread Diana Clarke
Thanks for stepping up again, Matt!

You've been an excellent Nova PTL: knowledgeable, diligent, pragmatic,
welcoming, (and fun!).

I look forward to working with you and learning from you in the next release.

Thanks for all you do (and thanks to your family too)!

Enjoy your time in Mexico; you deserve it.

All the best & thanks,

--diana





On Mon, Jan 23, 2017 at 1:54 PM, Matt Riedemann  wrote:
> Hi everyone,
>
> This is my self-nomination to continue running as Nova PTL for the Pike
> cycle.
>
> If elected, this would be a third term for me as Nova PTL. In Ocata I
> thought that I did a better job of keeping on top of a broader set of
> efforts than I was able to in Newton, including several non-priority
> vendor-specific blueprints.
>
> I have also tried to make regular communication a priority. The topics vary,
> but in general I try to keep people informed about the release schedule,
> upcoming deadlines, areas that need attention, and recaps of smaller group
> discussions back to the wider team. We have a widely distributed team and a
> lot of groups are impacted by decisions made within Nova so it's important
> to continue with that communication. Despite my best efforts I have also
> learned in Ocata that we need to get earlier feedback on changes which
> impact deployment tooling, and make documentation of such changes a high
> priority earlier in the development of new features so that people working
> on tooling are not left in the dark.
>
> Ocata has been a tough release, and I think we knew that was going to be the
> case going in. It was a shorter cycle but still had some very high-priority
> and high-visibility work items such as integrating the placement service
> with the scheduler and further integrating support for cells v2, along with
> making both of those required in a Nova deployment for Ocata. We also had to
> deal with losing some key people and filling those spots. But people have
> stepped up and we still made some incredible progress in Ocata despite the
> difficulties.
>
> For Pike I want to focus on the following:
>
> * Continue integration of the placement service into making scheduling
> decisions, including working with Neutron routed networks and work on
> defining traits for resource providers so we can model the qualitative
> aspects of resources in making placement decisions.
>
> * Continue working on cells v2 for multi-cell support including
> investigating the concept of auto-registration of compute nodes to simplify
> deployment automation, and also focus on multi-cell testing and Searchlight
> integration.
>
> * Work on volume multi-attach support with the new Cinder v3 APIs introduced
> in Ocata for creating and deleting volume attachments. I think we are
> finally at a place where we can make some solid progress on the Nova side
> with improved understanding between the Nova and Cinder teams.
>
> * There are going to be several efforts going on across several projects in
> the Pike release, including modeling capabilities in the REST API, and Nova
> is going to have to be a part of those efforts. We also need to get teams
> together to figure out what are the issues with hierarchical quotas and what
> progress can be made there since that is a high priority item that lots of
> operators have been requesting for a long time.
>
> In general, we are going to have to improve our review throughput,
> especially given the change in resources we experienced in Ocata. To me, a
> lot of this will have to do with mentoring people that are newer to Nova but
> are stepping into leadership positions, and having a shorter feedback loop
> on "leveling up".
>
> To summarize, I aim to be of service to those using and contributing to Nova
> and want to continue doing that in the PTL role for the project in the Pike
> release if you will have me for another round.
>
> Thank you for your consideration,
>
> 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 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] [Zun] Propose a change of the Zun core team membership

2017-01-24 Thread Kumari, Madhuri
+1 for both.

-Original Message-
From: Wenzhi Yu [mailto:wenzhi...@163.com] 
Sent: Tuesday, January 24, 2017 7:02 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Zun] Propose a change of the Zun core team 
membership

+1 from me! 
Kevin has made significant contribution to Zun, he deserves this!

Best Regards,
Wenzhi Yu(yuywz)
> 在 2017年1月24日,下午5:12,Shuu Mutou  写道:
> 
> +1 for both.
> 
> regards
> Shu
> 
> 
>> -Original Message-
>> From: Pradeep Singh [mailto:ps4openst...@gmail.com]
>> Sent: Tuesday, January 24, 2017 11:58 AM
>> To: OpenStack Development Mailing List (not for usage questions) 
>> 
>> Subject: Re: [openstack-dev] [Zun] Propose a change of the Zun core 
>> team membership
>> 
>> +1, welcome Kevin. I appreciate your work.
>> 
>> On Tuesday, January 24, 2017, Yanyan Hu >  > wrote:
>> 
>> 
>>  +1 for the change.
>> 
>> 
>>  2017-01-24 6:56 GMT+08:00 Hongbin Lu >  >:
>> 
>> 
>>  Hi Zun cores,
>> 
>> 
>> 
>>  I proposed a change of Zun core team membership as below:
>> 
>> 
>> 
>>  + Kevin Zhao (kevin-zhao)
>> 
>>  - Haiwei Xu (xu-haiwei)
>> 
>> 
>> 
>>  Kevin has been working for Zun for a while, and made 
>> significant 
>> contribution. He submitted several non-trivial patches with high 
>> quality. One of his challenging task is adding support of container 
>> interactive mode, and it looks he is capable to handle this 
>> challenging task (his patches are under reviews now). I think he is a 
>> good addition to the core team. Haiwei is a member of the initial 
>> core team. Unfortunately, his activity dropped down in the past a few months.
>> 
>> 
>> 
>>  According to the OpenStack Governance process [1], we require a 
>> minimum of 4 +1 votes from Zun core reviewers within a 1 week voting 
>> window (consider this proposal as a +1 vote from me). A vote of -1 is 
>> a veto. If we cannot get enough votes or there is a veto vote prior 
>> to the end of the voting window, this proposal is rejected.
>> 
>> 
>> 
>>  [1]
>> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>> 
>> 
>> 
>> 
>>  Best regards,
>> 
>>  Hongbin
>> 
>> 
>> 
>> 
>> 
>>  __
>> 
>>  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,
>> 
>>  Yanyan
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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


Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

2017-01-24 Thread Matt Riedemann

On 1/24/2017 2:57 PM, Matt Riedemann wrote:

On 1/24/2017 2:38 PM, Sylvain Bauza wrote:


It's litterally 2 days before FeatureFreeze and we ask operators to
change their cloud right now ? Looks difficult to me and like I said in
multiple places by email, we have a ton of assertions saying it's
acceptable to have not all the filters.

-Sylvain



I'm not sure why feature freeze in two days is going to make a huge
amount of difference here. Most large production clouds are probably
nowhere near trunk (I'm assuming most are on Mitaka or older at this
point just because of how deployments seem to tail the oldest supported
stable branch). Or are you mainly worried about deployment tooling
projects, like TripleO, needing to deal with this now?

Anyone upgrading to Ocata is going to have to read the release notes and
assess the upgrade impacts regardless of when we make this change, be
that Ocata or Pike.

Sylvain, are you suggesting that for Ocata if, for example, the
CoreFilter isn't in the list of enabled scheduler filters, we don't make
the request for VCPU when filtering resource providers, but we also log
a big fat warning in the n-sch logs saying we're going to switch over in
Pike and that cpu_allocation_ratio needs to be configured because the
CoreFilter is going to be deprecated in Ocata and removed in Pike?

[1]
https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact




To recap the discussion we had in IRC today, we're moving forward with 
the original plan of the *filter scheduler* always requesting VCPU, 
MEMORY_MB and DISK_GB* regardless of the enabled filters. The main 
reason being there isn't a clear path forward on straddling releases to 
deprecate or make decisions based on the enabled filters and provide a 
warning that makes sense.


For example, we can't deprecate the filters (at least yet) because the 
*caching scheduler* is still using them (it's not using placement yet). 
And if we logged a warning if you don't have the CoreFilter in 
CONF.filter_scheduler.enabled_filters, for example, but we don't want 
you to have it in that list, then what are you supposed to do? i.e. the 
goal is to not have the legacy primitive resource filters enabled for 
the filter scheduler in Pike, so you get into this weird situation of 
whether or not you have them enabled or not before Pike, and in what 
cases do you log a warning that makes sense. So we agreed at this point 
it's just simpler to say that if you don't enable these filters today, 
you're going to need to configure the appropriate allocation ratio 
configuration option prior to upgrading to Ocata. That will be in the 
upgrade section of the release notes and we can probably also work it 
into the placement devref as a deployment note. We can also work this 
into the nova-status upgrade check CLI.


*DISK_GB is special since we might have a flavor that's not specifying 
any disk or a resource provider with no DISK_GB allocations if the 
instances are all booted from volumes.


--

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] [placement] [operators] Optional resource asking or not?

2017-01-24 Thread Matt Riedemann

On 1/24/2017 2:57 PM, Matt Riedemann wrote:

On 1/24/2017 2:38 PM, Sylvain Bauza wrote:


It's litterally 2 days before FeatureFreeze and we ask operators to
change their cloud right now ? Looks difficult to me and like I said in
multiple places by email, we have a ton of assertions saying it's
acceptable to have not all the filters.

-Sylvain



I'm not sure why feature freeze in two days is going to make a huge
amount of difference here. Most large production clouds are probably
nowhere near trunk (I'm assuming most are on Mitaka or older at this
point just because of how deployments seem to tail the oldest supported
stable branch). Or are you mainly worried about deployment tooling
projects, like TripleO, needing to deal with this now?

Anyone upgrading to Ocata is going to have to read the release notes and
assess the upgrade impacts regardless of when we make this change, be
that Ocata or Pike.

Sylvain, are you suggesting that for Ocata if, for example, the
CoreFilter isn't in the list of enabled scheduler filters, we don't make
the request for VCPU when filtering resource providers, but we also log
a big fat warning in the n-sch logs saying we're going to switch over in
Pike and that cpu_allocation_ratio needs to be configured because the
CoreFilter is going to be deprecated in Ocata and removed in Pike?

[1]
https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact




To recap the discussion we had in IRC today, we're moving forward with 
the original plan of the *filter scheduler* always requesting VCPU, 
MEMORY_MB and DISK_GB* regardless of the enabled filters. The main 
reason being there isn't a clear path forward on straddling releases to 
deprecate or make decisions based on the enabled filters and provide a 
warning that makes sense.


For example, we can't deprecate the filters (at least yet) because the 
*caching scheduler* is still using them (it's not using placement yet). 
And if we logged a warning if you don't have the CoreFilter in 
CONF.filter_scheduler.enabled_filters, for example, but we don't want 
you to have it in that list, then what are you supposed to do? i.e. the 
goal is to not have the legacy primitive resource filters enabled for 
the filter scheduler in Pike, so you get into this weird situation of 
whether or not you have them enabled or not before Pike, and in what 
cases do you log a warning that makes sense. So we agreed at this point 
it's just simpler to say that if you don't enable these filters today, 
you're going to need to configure the appropriate allocation ratio 
configuration option prior to upgrading to Ocata. That will be in the 
upgrade section of the release notes and we can probably also work it 
into the placement devref as a deployment note. We can also work this 
into the nova-status upgrade check CLI.


*DISK_GB is special since we might have a flavor that's not specifying 
any disk or a resource provider with no DISK_GB allocations if the 
instances are all booted from volumes.


--

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] [requirements][docs] updating the minimum version of sphinx

2017-01-24 Thread Matthew Thode
On 01/24/2017 09:57 PM, Matthew Thode wrote:
> Basically I'd like to ask the docs people if they are fine with updating
> the minimum version of sphinx from sphinx>=1.2.1,!=1.3b1,<1.4 to
> sphinx>=1.5.1.  This change seems fairly major, especially given that
> there is no overlay between the 'before' and 'after' versions.
> 
> I'd appreciate docs team reviews on this.  We plan on having a meeting
> soon at 10:00 UTC in #openstack-meeting-alt if you care to join.
> 
> https://review.openstack.org/418772
> 

lesigh, was watching John's talk and mistyped...
https://www.youtube.com/watch?v=HRRbogFZEcU

retitled...

-- 
Matthew Thode (prometheanfire)



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


[openstack-dev] [requirements][docs] updating the minimum version of swift

2017-01-24 Thread Matthew Thode
Basically I'd like to ask the docs people if they are fine with updating
the minimum version of sphinx from sphinx>=1.2.1,!=1.3b1,<1.4 to
sphinx>=1.5.1.  This change seems fairly major, especially given that
there is no overlay between the 'before' and 'after' versions.

I'd appreciate docs team reviews on this.  We plan on having a meeting
soon at 10:00 UTC in #openstack-meeting-alt if you care to join.

https://review.openstack.org/418772

-- 
Matthew Thode (prometheanfire)



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] [tripleo] Mistral Workflow for deriving THT parameters

2017-01-24 Thread John Fulton

On 01/23/2017 05:07 AM, Saravanan KR wrote:

Thanks John for the info.

I am going through the spec in detail. And before that, I had few
thoughts about how I wanted to approach this, which I have drafted in
https://etherpad.openstack.org/p/tripleo-derive-params. And it is not
100% ready yet, I was still working on it.


Awesome. Thank you Saravanan for taking the time to review this. I
made some updates in the etherpad above.


As of now, there are few differences on top of my mind, which I want
to highlight, I am still going through the specs in detail:

* Profiles vs Features - Considering a overcloud node as a profiles
rather than a node which can host these features, would have
limitations to it. For example, if i need a Compute node to host both
Ceph (OSD) and DPDK, then the node will have multiple profiles or we
have to create a profile like -
hci_enterprise_many_small_vms_with_dpdk? The first one is not
appropriate and the later is not scaleable, may be something else in
your mind?


Why is the later not scaleable? It's analogous to composable roles.

With Composable Roles, if I want HCI, which is made from the Compute
and CephStorage roles, then I add a name for the new role and list
services they should have by borrowing from the examples shipped
in openstack-tripleo-heat-templates/roles_data.yaml. So I could call
my new role role OsdCompute and make:


https://github.com/RHsyseng/hci/blob/master/custom-templates/custom-roles.yaml#L168-L193

Similarly, if I want to make a new profile, then I give it a name and
then combine what I want. E.g. if the workload profiles file had
hci_throughput like this:

  hci_throughput:
workload::average_guest_flavor: 'm1.large'
workload::average_guest_memory_size_in_mb: 8192
workload::average_guest_CPU_utilization_percentage: 90
workload::tuned_profile: 'throughput-performance'

The deployer could easily compose their own hci_latency profile as:

  hci_latency:
workload::average_guest_flavor: 'm1.large'
workload::average_guest_memory_size_in_mb: 8192
workload::average_guest_CPU_utilization_percentage: 90
workload::tuned_profile: 'latency-performance'

The above is a simple example, but if more parameters were modified
the ability to add multiple tunables per profile would be useful as
the deployer would just need to specify they want just that name and
they'd get the other params that came with it. So, I was not
suggesting we ship every possible profile but that we provide a few
proven examples of known use-cases and also have one example with all
of them for CI tests (similar to CI for composable roles).

I think the above fits in with the notion of tags that you mentioned in
that they can be combined, e.g. "dpdk,osd" vs "sriov,osd".  The
difference is that the deployer could give any combination of them a
name. As the number of inputs for derived parameters grows, so does
the benefit of a name to refer to a set of them.

Perhaps the templates should not be for "Workload Profiles" but for
"Derived THT" and those templates should call different functions.
Then some of those functions would include derivations to optimize for
different workloads while other functions would make derivations for
DPDK or SRIOV deploys. Something like:

  hci_dpdk:
derive::workload::average_guest_flavor: 'm1.large'
derive::workload::average_guest_memory_size_in_mb: 8192
derive::workload::average_guest_CPU_utilization_percentage: 90
derive::tag::network: 'dpdk'

In something like the above, you could implement and support the tags
you described, and a user would not need to use performance profiles.
They could just include a new THT env file, e.g. derived_parmas.yaml,
and indicate which of the many derivable parameters they want to use.

What do you think of exposing the tags to the user as in the above?


* Independent - The initial plan of this was to be independent
execution, also can be added to deploy if needed.


I agree.


* Not to expose/duplicate parameters which are straight forward,
for example tuned-profile name should be associated with feature
internally, Workflows will decide it.


By "straight forward" do you mean non-derived?

I'd prefer to allow an advanced deployer to compose a performance
profile with whatever performance tweaks they need. So, I'd put
tuned in a workload profile because if I want to tune my overcloud for
that workload then I expect it to have the appropriate tuned profile.

I see a few ways this could go. Given tags or profiles, I think we
both want a way to refer to a set of parameters with a simple name
and we want either composability within the name or the ability to
combine more than one name in a deployment. However I see two options:

A. Do we want to only derive parameters that we think must be derived
and require users to manually set non-derived ones outside of this
spec?

B. Do we want to allow for any parameter to be derived if we unify
those parameters under a name and offer workflow that 

Re: [openstack-dev] [tripleo] Mistral Workflow for deriving THT parameters

2017-01-24 Thread John Fulton

On 01/24/2017 12:45 AM, Saravanan KR wrote:

Thanks Giulio for adding it to PTG discussion pad. I am not yet sure
of my presence in PTG. Hoping that things will fall in place soon.

We have spent a considerable about of time in moving from static roles
to composable roles. If we are planning to introduce static profiles,
then after a while we will end up with the same problem, and
definitely, it actually depends on how the features will be composed
on a role. Looking forward.


Hi Saravanan,

I wasn't planning to introduce static profiles. What's proposed
in the spec [1] is for the profiles to be easily composed so I
mimicked the composable roles pattern. I will reply to your message
from the 23rd with more details and an example.

  John

[1] https://review.openstack.org/#/c/423304/


On Mon, Jan 23, 2017 at 6:25 PM, Giulio Fidente  wrote:

On 01/23/2017 11:07 AM, Saravanan KR wrote:

Thanks John for the info.

I am going through the spec in detail. And before that, I had few
thoughts about how I wanted to approach this, which I have drafted in
https://etherpad.openstack.org/p/tripleo-derive-params. And it is not
100% ready yet, I was still working on it.


I've linked this etherpad for the session we'll have at the PTG


As of now, there are few differences on top of my mind, which I want
to highlight, I am still going through the specs in detail:
* Profiles vs Features - Considering a overcloud node as a profiles
rather than a node which can host these features, would have
limitations to it. For example, if i need a Compute node to host both
Ceph (OSD) and DPDK, then the node will have multiple profiles or we
have to create a profile like -
hci_enterprise_many_small_vms_with_dpdk? The first one is not
appropriate and the later is not scaleable, may be something else in
your mind?
* Independent - The initial plan of this was to be independent
execution, also can be added to deploy if needed.
* Not to expose/duplicate parameters which are straight forward, for
example tuned-profile name should be associated with feature
internally, Workflows will decide it.


for all of the above, I think we need to decide if we want the
optimizations to be profile-based and gathered *before* the overcloud
deployment is started or if we want to set these values during the
overcloud deployment basing on the data we have at runtime

seems like both approaches have pros and cons and this would be a good
conversation to have with more people at the PTG


* And another thing, which I couldn't get is, where will the workflow
actions be defined, in THT or tripleo_common?


to me it sounds like executing the workflows before stack creation is
started would be fine, at least for the initial phase

running workflows from Heat depends on the other blueprint/session we'll
have about the WorkflowExecution resource and once that will be
available, we could trigger the workflow execution from tht if beneficial


The requirements which I thought of, for deriving workflow are:
Parameter Deriving workflow should be
* independent to run the workflow
* take basic parameters inputs, for easy deployment, keep very minimal
set of mandatory parameters, and rest as optional parameters
* read introspection data from Ironic DB and Swift-stored blob

I will add these comments as starting point on the spec. We will work
towards bringing down the differences, so that operators headache is
reduced to a greater extent.


thanks

--
Giulio Fidente
GPG KEY: 08D733BA


__
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] Device tag in the API breaks in the old microversion

2017-01-24 Thread Matt Riedemann

On 1/24/2017 8:16 PM, Alex Xu wrote:



One other thing: we're going to need to also fix this in
python-novaclient, which we might want to do first, or work
concurrently, since that's going to give us the client side
perspective on how gross it will be to deal with this issue.




This is Andrey's patch to at least document the limitation:

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

We'll have to fix the client to use the new microversion in Pike (or at 
least release the fix in Pike) since the client release freeze is Thursday.


--

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] [networking-sfc]

2017-01-24 Thread Henry Fourie
Cathy,
   I believe Mohan Kumar did that work.
 - Louis

-Original Message-
From: Cathy Zhang 
Sent: Tuesday, January 24, 2017 5:39 PM
To: OpenStack Development Mailing List (not for usage questions); Henry Fourie; 
Vikram Choudhary
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [networking-sfc]

There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
Bernard Cafarelli

__
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] Device tag in the API breaks in the old microversion

2017-01-24 Thread Alex Xu
2017-01-25 0:27 GMT+08:00 Matt Riedemann :

> On 1/24/2017 9:18 AM, Matt Riedemann wrote:
>
>>
>> First, thanks to Kevin and Alex for finding this issue and explaining it
>> in detail so we can understand the scope.
>>
>> This is a nasty unfortunate issue which I really wish we could just fix
>> without a microversion bump but we have microversions for a reason,
>> which is to fix issues in the API. In thinking about if this were the
>> legacy 2.0 API, we always had a rule that you couldn't fix bugs in the
>> API if they changed the behavior, no matter how annoying.
>>
>> So let's fix this with a microversion. I don't think we need to hold it
>> to the feature freeze deadline as it's a microversion only for a bug
>> fix, it's not a new feature. So that's a compromise at least and gives
>> us some time to get this done correctly and still have it fixed in
>> Ocata. We'll also want to document this in the api-ref and REST API
>> version history in whatever way makes it clear about the limitations
>> between microversions.
>>
>> As for testing, I think using a mix of test inheritance and using
>> 2.latest is probably a good step to take. I know we've had a mix of that
>> in different places in the functional API samples tests, but there was
>> never a clear rule about what do to with testing microversions and if
>> you should use inheritance to build on existing tests.
>>
>>
> One other thing: we're going to need to also fix this in
> python-novaclient, which we might want to do first, or work concurrently,
> since that's going to give us the client side perspective on how gross it
> will be to deal with this issue.


+1, thanks for this good point!


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


Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-24 Thread Fei Long Wang
+1


On 25/01/17 02:36, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>
> __
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-24 Thread Nikhil Komawar
+1

She does good work and I will be happy to see this happen.

I am not so sure about the argument part :) (jk)


On 1/24/17 8:36 AM, Brian Rosmaita wrote:
> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>
> __
> 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,
Nikhil


__
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] [zaqar] PTL Candidacy

2017-01-24 Thread Fei Long Wang
Hi all,

I've had the pleasure of serving the Zaqar community as PTL for the past
three cycles, and I'd like to continue for Pike cycle, if you'll have me.

For Pike release, things I'd like to do:

1. Scalability
   A scalable service should be able to process increases in load
without obvious degradation of latency or availability. For Zaqar,
"load" can refer to various dimensions of usage:
   1) number of queues
   2) number of publishers
   3) number of subscribers
   4) number of messages
   5) size of messages
   6) rate of messages published or consumed
Luckily, we have merged the OSProfiler patch in Ocata, so it would be
nice to leverage it to do more benchmarks to improve above metrics.

2. Availability
   Fortunately, Zaqar has a simple architecture which makes keeping its
availability relatively easy. That said, we need to improve the
behaviors of Zaqar so that it can gracefully failing over in a way that
is unnoticeable to end users.

3. Latency
   Latency is a typical time-based measure for the performance of a
system. Obvious, Zaqar would like to minimize latency wherever possible.
There are two most important latency metrics I would like to improve in
Pike are:
   1) The amount of time to claim a message
   2) The amount of time to deliver a message from publisher Zaqar server
   3) The amount of time to deliver a message from Zaqar to subscriber

4. Encourage diversity in our Community
   We are still a small team needs to grow. I would like to encourage
more people, organizations to join Zaqar community to make sure we have
a good coverage.

It's a fantastic experience working with this amazing team and I know
without the dedication and hard work of everyone who has contributed to
Zaqar we can't make those success stories of Ocata happen. I would be
pleased to serve as PTL for another cycle and I'd appreciate your vote.

Thanks for your consideration!


-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
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] Device tag in the API breaks in the old microversion

2017-01-24 Thread Zhenyu Zheng
Thanks Alex for raising this up widely, as Chinese holiday is comming and
Alex and me might be away for a week, And it will be better to fix this
faster, so thanks Artom taking over to fix it :)

On Wed, Jan 25, 2017 at 7:50 AM, Ghanshyam Mann 
wrote:

>
> On Wed, Jan 25, 2017 at 1:18 AM, Matt Riedemann 
> wrote:
>
>> On 1/24/2017 2:05 AM, Alex Xu wrote:
>>
>>> Unfortunately the device tag support in the API was broken in the old
>>> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
>>> to Kevin Zheng to find out that.
>>>
>>> Actually there are two bugs, just all of them are about device tag. The
>>> first one [0] is a mistake in the initial introduce of device tag. The
>>> new schema only available for the version 2.32, when the request version
>>>
 2.32, the schema fallback to the old one.

>>>
>>> The second one [1] is that when we bump the API to 2.37, the network
>>> device tag was removed accidentally which also added in 2.32 [2].
>>>
>>> So the current API behavior is as below:
>>>
>>> 2.32: BDM tag and network device tag added.
>>> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
>>> works.
>>> 2.37: The network device tag disappeared also.
>>>
>>> There are few questions we should think about:
>>>
>>> 1. Should we fix that by Microversion?
>>> Thanks to Chris Dent point that out in the review. I also think we
>>> need to bump Microversion, which follow the rule of Microversion.
>>>
>>> 2. If we need Microversion, is that something we can do before release?
>>> We are very close to the feature freeze. And in normal, we need spec
>>> for microversion. Maybe we only can do that in Pike. For now we can
>>> update the API-ref, and microversion history to notice that, maybe a
>>> reno also.
>>>
>>> 2. How can we prevent that happened again?
>>>Both of those patches were reviewed multiple cycles. But we still
>>> miss that. It is worth to think about how to prevent that happened again.
>>>
>>>Talk with Sean. He suggests stop passing plain string version to the
>>> schema extension point. We should always pass APIVersionRequest object
>>> instead of plain string. Due to "version == APIVersionRequest('2.32')"
>>> is always wrong, we should remove the '__eq__'. The developer should
>>> always use the 'APIVersionRequest.matches' [3] method.
>>>
>>>That can prevent the first mistake we made. But nothing help for
>>> second mistake. Currently we only run the test on the specific
>>> Microversion for the specific interesting point. In the before, the new
>>> tests always inherits from the previous microversion tests, just like
>>> [4]. That can test the old API behavior won't be changed in the new
>>> microversion. But now, we said that is waste, we didn't do that again
>>> just like [5]. Should we change that back?
>>>
>>> Thanks
>>> Alex
>>>
>>> [0]
>>> https://review.openstack.org/#/c/304510/64/nova/api/openstac
>>> k/compute/block_device_mapping.py
>>> [1] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>>> k/compute/schemas/servers.py@88
>>> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>>> k/compute/schemas/servers.py@79
>>> [3] https://github.com/openstack/nova/blob/master/nova/api/opens
>>> tack/api_version_request.py#L219
>>> [4] https://github.com/openstack/nova/blob/master/nova/tests/uni
>>> t/api/openstack/compute/test_evacuate.py#L415
>>> [5] https://github.com/openstack/nova/blob/master/nova/tests/uni
>>> t/api/openstack/compute/test_serversV21.py#L3584
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> First, thanks to Kevin and Alex for finding this issue and explaining it
>> in detail so we can understand the scope.
>>
>> This is a nasty unfortunate issue which I really wish we could just fix
>> without a microversion bump but we have microversions for a reason, which
>> is to fix issues in the API. In thinking about if this were the legacy 2.0
>> API, we always had a rule that you couldn't fix bugs in the API if they
>> changed the behavior, no matter how annoying.
>>
>> So let's fix this with a microversion. I don't think we need to hold it
>> to the feature freeze deadline as it's a microversion only for a bug fix,
>> it's not a new feature. So that's a compromise at least and gives us some
>> time to get this done correctly and still have it fixed in Ocata. We'll
>> also want to document this in the api-ref and REST API version history in
>> whatever way makes it clear about the limitations between microversions.
>>
>
> ​+1 for fixing in Ocata itself. We have fix up just need to put that under
> new version. I can modify the tests to cover this bug scenario. ​
>
>
>
>>

Re: [openstack-dev] [networking-sfc]

2017-01-24 Thread Cathy Zhang
There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
Bernard Cafarelli

__
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] PTL candidacy

2017-01-24 Thread Kevin Benton
>I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions

The Neutron API is already very extensible and that's problematic. Right
now a vendor can write an out-of-tree service plugin or driver that adds
arbitrary fields and endpoints to the API that results in whatever behavior
they want. This is great for vendors because they can directly expose
features without having to make them vendor agnostic. However, it's
terrible for operators because it leads to lock-in and terrible for the
users because it leads to cross-cloud compatibility issues.

For a concrete example of what I mean, take a look at this extension here:
[1]. This is directly exposing vendor-specific things onto Neutron network
API payloads. Nobody can build any tooling that depends on those fields
without being locked into a specific vendor.

So what I would like to encourage is bringing API extension work into
Neutron-lib where we can ensure that the relevant abstractions are in place
and it's not just a pass-through to a bunch of vendor-specific features. I
would rather relax our constraint around requiring a reference
implementation for new extensions in neutron-lib than continue to encourage
developers to do expose whatever they want with the the existing extension
framework.

So I'm all for developing new APIs *as a community* to enable NFV use cases
not supported by the current APIs. However, I don't want to encourage or
make it easier for vendors to just build arbitrary extensions on top of
Neutron that expose backend details.

In my view, Neutron should provide a unified API for networking across
OpenStack clouds, not a platform for writing deployment-specific networking
APIs.

1.
https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22

Cheers,
Kevin Benton

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur 
wrote:

>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> cheers..
> -Sukhdev
>
>
>
>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>>
>
>
>
>
>>
>> Thanks for attention,
>> Ihar
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

2017-01-24 Thread Sridhar Ramaswamy
Tackers,

I'd like to propose following changes to the Tacker core team.

Stephen Wong

After being associated with Tacker project from its genesis, Stephen
Wong (irc: s3wong) has decided to step down from the core-team. I
would like to thank Stephen for his contribution to Tacker,
particularly for his help navigating the initial days splitting off
Neutron and in re-launching this project in Vancouver summit for
TOSCA-based NFV Orchestration. His recent effort in writing the SFC
driver to support VNF Forwarding Graph is much appreciated. Thanks
Stephen!

Dharmendra Kushwaha

It gives me great pleasure to propose Dharmendra (irc:  dkushwaha) to
join the Tacker core team. Dharmendra's contributions to tacker
started in Jan 2016. He is an active contributor across the board [1]
in bug fixes, code cleanups and, most recently, as a lead author of
the Network Services Descriptor blueprint.

Also, Dharmendra recently stepped up to take care of bug triage for
Tacker. There is an uptick in deployment issues reported through LP
[2] and in irc - which itself is a good healthy thing. Now we need to
respond by fixing the issues reported promptly. Dharmendra’s help will
be immensely valuable here.

Existing cores - please vote +1 / -1.

thanks,
Sridhar

[1] 
http://stackalytics.com/?module=tacker-group_id=dharmendra-kushwaha=marks
[2] https://answers.launchpad.net/tacker

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


Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

2017-01-24 Thread Michał Jastrzębski
Another file in our repo is just to provide this review mechanism for
now. All deliverables has to follow governance procedures as well.

On 24 January 2017 at 12:04, Doug Hellmann  wrote:
> Excerpts from Ian Cordasco's message of 2017-01-24 14:55:31 -0500:
>> -Original Message-
>> From: Michał Jastrzębski  
>> Reply: OpenStack Development Mailing List (not for usage questions)
>>  
>> Date: January 24, 2017 at 11:01:14
>> To: OpenStack Development Mailing List (not for usage questions)
>>  
>> Subject:  Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable
>>
>> > Hello everyone,
>> >
>> > We've reached our agreement!
>> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_28264d5a40d0088c
>> > New deliverable process will be lightweight - just normal +2+2+PTL
>> > vote is needed to add new deliverable. I'm going to create new
>> > deliverables.yaml file in Kolla repository which will allow us to keep
>> > track of deliverables. Review incoming:)
>>
>> Is Kolla not using openstack/releases to track deliverables? If so, why
>> duplicate that information?
>>
>> --
>> Ian Cordasco
>
> They need to be listed in openstack/governance in order to count for
> elections.
>
> Doug
>
> __
> 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] PTL candidacy

2017-01-24 Thread Jay Pipes

On 01/24/2017 06:42 PM, Sukhdev Kapur wrote:

Ihar and Kevin,

As our potential future PTLs, I would like to draw your attention to one
of the critical issue regarding Neutron as "the" networking service in
OpenStack.

I keep hearing off and on that Neutron is not flexible to address many
networking use cases and hence a new (or additional) networking project
is needed. For example, to address the use cases around NFV (rigid
resource inter-dependencies).  Another one keeps popping up is that it
is very hard/difficult to add/enhance Neutron API - hence, I picked this
one goal called out in Ihar's candidacy.

I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so
that vendors do not run around trying to figure out alternative
solutions


Big +1 from me on the above. Please work with the API working group, too!

Best,
-jay


* Explore alternative ways to evolve Neutron API.  Piling up
extensions and allowing third parties to completely change core
resource behaviour is not ideal, and now that api-ref and API
consolidation effort in neutron-lib are closer to completion, we may
have better answers to outstanding questions than during previous
attempts to crack the nut. I would like to restart the discussion some
time during Pike.






Thanks for attention,
Ihar

__
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] [kolla-ansible] [kolla] Am I doing this wrong?

2017-01-24 Thread Mooney, Sean K


> -Original Message-
> From: Paul Bourke [mailto:paul.bou...@oracle.com]
> Sent: Tuesday, January 24, 2017 11:49 AM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?
> 
> Ah, I think you may be misreading what Sean is saying there. What he means is
> kolla-ansible provides the bare minimum config templates to make the service
> work. To template every possible config option would be too much of a
> maintenance burden on the project.
> 
> Of course, users will want to customise these. But instead of modifying the
> templates directly, we recommend you use the "config override"
> mechanism [0]
> 
> This has a number of benefits, the main one being that you can pick up new
> releases of Kolla and not get stuck in merge hell, Ansible will pick up the 
> Kolla base
> templates and merge them with user provided overrides.
[Mooney, Sean K] paul is correct here, I did not intend to suggest that 
kolla-ansible should not
Be used to generate and manage config files. I simply wanted to point out that 
where
Customization is required to a config, it is preferable to use the config 
override mechanism
When possible vs modifying the ansible templates directly.
> 
> Wrt to the fact gathering, I understand your concern, we essentially have the 
> same
> problem in our team. It can be raised again for further discussion, I'm sure 
> there's
> other ways it can be solved.
[Mooney, Sean K] I belive you are intended to be able to use the ansible 
--limit and --tags flags,
To restrict the plays executed and node processed by a deploy and upgrade 
command.
I have used the --tags flags successfully in the past, I have had less success 
with the --limit flag.
In theory with the right combination of --limit and --tag you should be able to 
constrain  the node
On which facts are gathered to just those that would be modified e.g. 2-3 
instead of hundreds. 
> 
> [0]
> http://docs.openstack.org/developer/kolla-ansible/advanced-
> configuration.html#openstack-service-configuration-in-kolla
> 
> -Paul
> 
> On 23/01/17 18:03, Kris G. Lindgren wrote:
> > Hi Paul,
> >
> >
> >
> > Thanks for responding.
> >
> >
> >
> >> The fact gathering on every server is a compromise taken by Kolla to
> >
> >> work around limitations in Ansible. It works well for the majority of
> >
> >> situations; for more detail and potential improvements on this please
> >
> >> have a read of this post:
> >
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-November/1078
> >> 33.html
> >
> >
> >
> > So my problem with this is the logging in to the compute nodes.  While
> > this may be fine for a smaller deployment.  Logging into thousands,
> > even hundreds, of nodes via ansible to gather facts, just to do a
> > deployment against 2 or 3 of them is not tenable.  Additionally, in
> > our higher audited environments (pki/pci) will cause our auditors heartburn.
> >
> >
> >
> >> I'm not quite following you here, the config templates from
> >
> >> kolla-ansible are one of it's stronger pieces imo, they're reasonably
> >
> >> well tested and maintained. What leads you to believe they shouldn't
> >> be
> >
> >> used?
> >
> >>
> >
> >> > * Certain parts of it are 'reference only' (the config tasks),
> >
> >>  > are not recommended
> >
> >>
> >
> >> This is untrue - kolla-ansible is designed to stand up a stable and
> >
> >> usable OpenStack 'out of the box'. There are definitely gaps in the
> >
> >> operator type tasks as you've highlighted, but I would not call it
> >
> >> 'reference only'.
> >
> >
> >
> > http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack
> > -kolla.2017-01-09.log.html#t2017-01-09T21:33:15
> >
> >
> >
> >
> > This is where we were told the config stuff was "reference only"?
> >
> >
> >
> >
> ___
> >
> > Kris Lindgren
> >
> > Senior Linux Systems Engineer
> >
> > GoDaddy
> >
> >
> >
> >
> 
> __
> >  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] PTL Candidacy

2017-01-24 Thread Sukhdev Kapur
On Tue, Jan 24, 2017 at 3:24 PM, Edgar Magana 
wrote:

> You just made me remember my time as police man for Neutron plugins!  ☺
>

Now we can have distributed police men :-)

-Sukhdev



>
>
> Edgar
>
>
>
> *From: *Sukhdev Kapur 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, January 24, 2017 at 3:14 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Neutron] PTL Candidacy
>
>
>
> I remember good old days when CI was introduced in Neutron (during
> Icehouse time frame). There was excellent momentum behind it. We did not
> know some of the enforcement details, which created lots of
> confusion/havoc.
>
>
>
> Now that we have a better understanding of the past issues, and lots of
> good ideas to address them, I think it is appropriate to reactivate the
> process.
>
> As to Jeremy's options, I think option B makes the best sense - the driver
> author/owner should bare the burden of declaring a driver/plugin compatible.
>
>
>
> cheers..
>
> -Sukhdev
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley 
> wrote:
>
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> 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
> 

Re: [openstack-dev] [devstack] issues with requiring python3 only tool?

2017-01-24 Thread Sean M. Collins
Sean Dague wrote:
> I'll probably still default this to python3, it is the future direction
> we are headed.

Works for me  :)

-- 
Sean M. Collins

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


Re: [openstack-dev] [nova] Device tag in the API breaks in the old microversion

2017-01-24 Thread Ghanshyam Mann
On Wed, Jan 25, 2017 at 1:18 AM, Matt Riedemann  wrote:

> On 1/24/2017 2:05 AM, Alex Xu wrote:
>
>> Unfortunately the device tag support in the API was broken in the old
>> Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
>> to Kevin Zheng to find out that.
>>
>> Actually there are two bugs, just all of them are about device tag. The
>> first one [0] is a mistake in the initial introduce of device tag. The
>> new schema only available for the version 2.32, when the request version
>>
>>> 2.32, the schema fallback to the old one.
>>>
>>
>> The second one [1] is that when we bump the API to 2.37, the network
>> device tag was removed accidentally which also added in 2.32 [2].
>>
>> So the current API behavior is as below:
>>
>> 2.32: BDM tag and network device tag added.
>> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
>> works.
>> 2.37: The network device tag disappeared also.
>>
>> There are few questions we should think about:
>>
>> 1. Should we fix that by Microversion?
>> Thanks to Chris Dent point that out in the review. I also think we
>> need to bump Microversion, which follow the rule of Microversion.
>>
>> 2. If we need Microversion, is that something we can do before release?
>> We are very close to the feature freeze. And in normal, we need spec
>> for microversion. Maybe we only can do that in Pike. For now we can
>> update the API-ref, and microversion history to notice that, maybe a
>> reno also.
>>
>> 2. How can we prevent that happened again?
>>Both of those patches were reviewed multiple cycles. But we still
>> miss that. It is worth to think about how to prevent that happened again.
>>
>>Talk with Sean. He suggests stop passing plain string version to the
>> schema extension point. We should always pass APIVersionRequest object
>> instead of plain string. Due to "version == APIVersionRequest('2.32')"
>> is always wrong, we should remove the '__eq__'. The developer should
>> always use the 'APIVersionRequest.matches' [3] method.
>>
>>That can prevent the first mistake we made. But nothing help for
>> second mistake. Currently we only run the test on the specific
>> Microversion for the specific interesting point. In the before, the new
>> tests always inherits from the previous microversion tests, just like
>> [4]. That can test the old API behavior won't be changed in the new
>> microversion. But now, we said that is waste, we didn't do that again
>> just like [5]. Should we change that back?
>>
>> Thanks
>> Alex
>>
>> [0]
>> https://review.openstack.org/#/c/304510/64/nova/api/openstac
>> k/compute/block_device_mapping.py
>> [1] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>> k/compute/schemas/servers.py@88
>> [2] https://review.openstack.org/#/c/316398/37/nova/api/openstac
>> k/compute/schemas/servers.py@79
>> [3] https://github.com/openstack/nova/blob/master/nova/api/opens
>> tack/api_version_request.py#L219
>> [4] https://github.com/openstack/nova/blob/master/nova/tests/uni
>> t/api/openstack/compute/test_evacuate.py#L415
>> [5] https://github.com/openstack/nova/blob/master/nova/tests/uni
>> t/api/openstack/compute/test_serversV21.py#L3584
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> First, thanks to Kevin and Alex for finding this issue and explaining it
> in detail so we can understand the scope.
>
> This is a nasty unfortunate issue which I really wish we could just fix
> without a microversion bump but we have microversions for a reason, which
> is to fix issues in the API. In thinking about if this were the legacy 2.0
> API, we always had a rule that you couldn't fix bugs in the API if they
> changed the behavior, no matter how annoying.
>
> So let's fix this with a microversion. I don't think we need to hold it to
> the feature freeze deadline as it's a microversion only for a bug fix, it's
> not a new feature. So that's a compromise at least and gives us some time
> to get this done correctly and still have it fixed in Ocata. We'll also
> want to document this in the api-ref and REST API version history in
> whatever way makes it clear about the limitations between microversions.
>

​+1 for fixing in Ocata itself. We have fix up just need to put that under
new version. I can modify the tests to cover this bug scenario. ​



>
> As for testing, I think using a mix of test inheritance and using 2.latest
> is probably a good step to take. I know we've had a mix of that in
> different places in the functional API samples tests, but there was never a
> clear rule about what do to with testing microversions and if you should
> use inheritance to build on existing tests.

​
Also along with that, I'd like to add 

Re: [openstack-dev] [Neutron] PTL Candidacy

2017-01-24 Thread Sukhdev Kapur
I remember good old days when CI was introduced in Neutron (during Icehouse
time frame). There was excellent momentum behind it. We did not know some
of the enforcement details, which created lots of confusion/havoc.

Now that we have a better understanding of the past issues, and lots of
good ideas to address them, I think it is appropriate to reactivate the
process.
As to Jeremy's options, I think option B makes the best sense - the driver
author/owner should bare the burden of declaring a driver/plugin compatible.

cheers..
-Sukhdev


On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> 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] [neutron] PTL candidacy

2017-01-24 Thread Sukhdev Kapur
Ihar and Kevin,

As our potential future PTLs, I would like to draw your attention to one of
the critical issue regarding Neutron as "the" networking service in
OpenStack.

I keep hearing off and on that Neutron is not flexible to address many
networking use cases and hence a new (or additional) networking project is
needed. For example, to address the use cases around NFV (rigid resource
inter-dependencies).  Another one keeps popping up is that it is very
hard/difficult to add/enhance Neutron API - hence, I picked this one goal
called out in Ihar's candidacy.

I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions

cheers..
-Sukhdev




> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the discussion some
> time during Pike.
>




>
> Thanks for attention,
> Ihar
>
> __
> 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] PTL Candidacy

2017-01-24 Thread Edgar Magana
You just made me remember my time as police man for Neutron plugins!  ☺

Edgar

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

Date: Tuesday, January 24, 2017 at 3:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [Neutron] PTL Candidacy

I remember good old days when CI was introduced in Neutron (during Icehouse 
time frame). There was excellent momentum behind it. We did not know some of 
the enforcement details, which created lots of confusion/havoc.

Now that we have a better understanding of the past issues, and lots of good 
ideas to address them, I think it is appropriate to reactivate the process.
As to Jeremy's options, I think option B makes the best sense - the driver 
author/owner should bare the burden of declaring a driver/plugin compatible.

cheers..
-Sukhdev


On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley 
> wrote:
On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > I'm on board with getting visibility into the drivers with improvements to
> > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > 'validation'. Core reviewers don't frequently have access to the hardware or
> > software required to validate these drivers so we can't be sure if the
> > features really are working as expected.
> >
> > If validation is as flexible as you highlighted in the email, we can at
> > least get it to a point where all recent CI runs are linkable from driverlog
> > and people can see recent tempest runs. I don't foresee the Neutron team
> > getting to a point soon where we vouch for certain drivers though just
> > because it is so hard to keep up with their changes (even ignoring changes
> > in the vendor hardware itself).
>
> Good point. We may guide plugins and drivers on how to set up CI; we
> may help Foundation to set up Marketplace in such a way that would
> allow to automatically consume test artifacts from driver owners; we
> may provide guidance to Foundation about which features are more
> important to reflect that in Marketplace; but I would hope we don't
> put the Neutron team on the hook to validate each driver, or even
> police CI owners to produce consumable results. (The stick in the
> latter case would be driver not showing up in Marketplace, or showing
> up with no feature support information.)

I guess the question I have is who, then, can tell our
operators/users what Neutron drivers are reasonably supported? It
sounds like you're saying Neutron developers are not well-placed to
determine that, which leaves us with these other options:

A. Have the OpenStack Foundation as maintainers of the Marketplace
   decide which Neutron drivers are usable (they don't really staff
   for this purpose so would be throwing darts I think)

B. Trust the driver authors to declare whether they're supported and
   what features they provide (maybe that works better than I
   expect?)

C. Identify another party with a vested interest in validating
   driver support (a board of operators from different organizations
   maybe?)

D. Provide links/aggregation of QA/CI and let the consumers attempt
   to divine supportability for themselves (seems a bit downstream
   hostile)

Are any of those options preferable?
--
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] [neutron] PTL Candidacy

2017-01-24 Thread Sukhdev Kapur
In deed, excellent and well qualified candidates.

Best of Luck to both

-Sukhdev


On Tue, Jan 24, 2017 at 7:16 AM, Armando M.  wrote:

> Hi neutrinos,
>
> No, it's not what you might be thinking...I am just delighted to see two
> excellent candidates willing to take the reins of the project going forward
> [1,2].
>
> I couldn't hope for more enthusiasm; best of luck to both candidates and
> anyone else who is going to step up! This is exciting!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/423552/
> [2] https://review.openstack.org/#/c/424500/
>
> __
> 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] [tripleo] Update TripleO core members

2017-01-24 Thread Ryan Brady
On Mon, Jan 23, 2017 at 2:03 PM, Emilien Macchi  wrote:

> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
> --
> 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
>

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


Re: [openstack-dev] [tc][swg] Sessions for Atlanta PTG - writing a TC Vision/Other options

2017-01-24 Thread Colette Alexander
On Tue, Jan 24, 2017 at 11:53 AM, Alexis Monville <
alexis.monvi...@redhat.com> wrote:

>
> >
> > I spent quite a bit of our cross project session at the Ocata Summit
> doing a
> > quick recap of the concept of Servant Leadership and it seemed like
> plenty
> > of attendees appreciated that. Would a series of quick recaps of basic
> > leadership concepts (Servant Leadership, Visioning, Principles & Culture,
> > and Change Management) - if anyone is interested in having a small
> > discussion covering some of those topics, I'd love to hear from you!
>
> Thank you Colette!
> Do you think those discussions need to happen during the PTG in
> Atlanta, or could we also asked for online conversations on those
> topics?
>

We could certainly cover some of these topics online, whether in a
scheduled discussion in #openstack-swg or elsewhere. The advantages to
talking them through in a room are far less than organizing future work and
getting feedback from anyone who has ideas on what to do moving forward who
are at the PTG, so I'd place them last in my list of items to schedule,
unless there's remarkable interest in them.

Thanks Alexis!

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


Re: [openstack-dev] [magnum] CoreOS template v2

2017-01-24 Thread Spyros Trigazis
Or start writing down (in the BP) what you want to put in the driver.
Network, lbaas, scripts, the order of the scripts and then we can see
if it's possible to adapt to the current coreos driver.

Spyros

On Jan 24, 2017 22:54, "Hongbin Lu"  wrote:

> As Spyros mentioned, an option is to start by cloning the existing
> templates. However, I have a concern for this approach because it will
> incur a lot of duplication. An alternative approach is modifying the
> existing CoreOS templates in-place. It might be a little difficult to
> implement but it saves your overhead to deprecate the old version and roll
> out the new version.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* Spyros Trigazis [mailto:strig...@gmail.com]
> *Sent:* January-24-17 3:47 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum] CoreOS template v2
>
>
>
> Hi.
>
>
>
> IMO, you should add a BP and start by adding a v2 driver in /contrib.
>
>
>
> Cheers,
>
> Spyros
>
>
>
> On Jan 24, 2017 20:44, "Kevin Lefevre"  wrote:
>
> Hi,
>
> The CoreOS template is not really up to date and in sync with upstream
> CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes),
> it is more a port of th fedora atomic template but CoreOS has its own
> Kubernetes deployment method.
>
> I’d like to implement the changes to sync kubernetes deployment on CoreOS
> to latest kubernetes version (1.5.2) along with standards components
> according the CoreOS Kubernetes guide :
>   - « Defaults » add ons like kube-dns , heapster and kube-dashboard
> (kube-ui has been deprecated for a long time and is obsolete)
>   - Canal for network policy (Calico and Flannel)
>   - Add support for RKT as container engine
>   - Support sane default options recommended by Kubernetes upstream
> (admission control : https://kubernetes.io/docs/
> admin/admission-controllers/, using service account…)
>   - Of course add every new parameters to HOT.
>
> These changes are difficult to implement as is (due to the fragment
> concept and everything is a bit messy between common and specific template
> fragment, especially for CoreOS).
>
> I’m wondering if it is better to clone the CoreOS v1 template to a new v2
> template en build from here ?
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

2017-01-24 Thread Ihar Hrachyshka
Hi Anna,

I see that as part of [1], we changed the argument type for the $subj
function from session to context. Sadly, it turns out we still call it
with a session from the 'old' TunnelTypeDriver. I suspect the same
issue may affect allocate_fully_specified_segment.

I assume that means all 'old' tunnel type drivers are broken. Should
we fix it by duplicating those two functions for old and new cases
too? Or should we revert both of them back to session? (I assume the
former, since the latter is not in line with enginefacade work.)

[1] 
https://review.openstack.org/#/c/398873/10/neutron/plugins/ml2/drivers/helpers.py

Thanks in advance,
Ihar

__
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] [operators] Optional resource asking or not?

2017-01-24 Thread Matt Riedemann

On 1/24/2017 2:38 PM, Sylvain Bauza wrote:


It's litterally 2 days before FeatureFreeze and we ask operators to
change their cloud right now ? Looks difficult to me and like I said in
multiple places by email, we have a ton of assertions saying it's
acceptable to have not all the filters.

-Sylvain



I'm not sure why feature freeze in two days is going to make a huge 
amount of difference here. Most large production clouds are probably 
nowhere near trunk (I'm assuming most are on Mitaka or older at this 
point just because of how deployments seem to tail the oldest supported 
stable branch). Or are you mainly worried about deployment tooling 
projects, like TripleO, needing to deal with this now?


Anyone upgrading to Ocata is going to have to read the release notes and 
assess the upgrade impacts regardless of when we make this change, be 
that Ocata or Pike.


Sylvain, are you suggesting that for Ocata if, for example, the 
CoreFilter isn't in the list of enabled scheduler filters, we don't make 
the request for VCPU when filtering resource providers, but we also log 
a big fat warning in the n-sch logs saying we're going to switch over in 
Pike and that cpu_allocation_ratio needs to be configured because the 
CoreFilter is going to be deprecated in Ocata and removed in Pike?


[1] 
https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact


--

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] [magnum] CoreOS template v2

2017-01-24 Thread Hongbin Lu
As Spyros mentioned, an option is to start by cloning the existing templates. 
However, I have a concern for this approach because it will incur a lot of 
duplication. An alternative approach is modifying the existing CoreOS templates 
in-place. It might be a little difficult to implement but it saves your 
overhead to deprecate the old version and roll out the new version.

Best regards,
Hongbin

From: Spyros Trigazis [mailto:strig...@gmail.com]
Sent: January-24-17 3:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] CoreOS template v2

Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,
Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre" 
> wrote:
Hi,

The CoreOS template is not really up to date and in sync with upstream CoreOS « 
Best Practice » (https://github.com/coreos/coreos-kubernetes), it is more a 
port of th fedora atomic template but CoreOS has its own Kubernetes deployment 
method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS to 
latest kubernetes version (1.5.2) along with standards components according the 
CoreOS Kubernetes guide :
  - « Defaults » add ons like kube-dns , heapster and kube-dashboard (kube-ui 
has been deprecated for a long time and is obsolete)
  - Canal for network policy (Calico and Flannel)
  - Add support for RKT as container engine
  - Support sane default options recommended by Kubernetes upstream (admission 
control : https://kubernetes.io/docs/admin/admission-controllers/, using 
service account…)
  - Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment concept and 
everything is a bit messy between common and specific template fragment, 
especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2 
template en build from here ?
__
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] Officially support Python 3.5 in Pike

2017-01-24 Thread Emilien Macchi
OpenStack community decided to officially support Python 3.5 by the
end of Pike cycle:
https://governance.openstack.org/tc/goals/pike/python35.html

To track this work in TripleO, I created a blueprint:
https://blueprints.launchpad.net/tripleo/+spec/support-python-35

I'm also tracking the work completion in the governance repository:
https://review.openstack.org/#/c/424857/

I'll start the evaluation of work that needs to be done and document
it in the previous link.
Anyone volunteer to help on $topic is very welcome, ping me on IRC or
here by e-mail.

Thanks,
-- 
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] [nova] [placement] [operators] Optional resource asking or not?

2017-01-24 Thread Sylvain Bauza


Le 24/01/2017 22:22, Dan Smith a écrit :
>> No. Have administrators set the allocation ratios for the resources they
>> do not care about exceeding capacity to a very high number.
>>
>> If someone previously removed a filter, that doesn't mean that the
>> resources were not consumed on a host. It merely means the admin was
>> willing to accept a high amount of oversubscription. That's what the
>> allocation_ratio is for.
>>
>> The flavor should continue to have a consumed disk/vcpu/ram amount,
>> because the VM *does actually consume those resources*. If the operator
>> doesn't care about oversubscribing one or more of those resources, they
>> should set the allocation ratios of those inventories to a high value.
>>
>> No more adding configuration options for this kind of thing (or in this
>> case, looking at an old configuration option and parsing it to see if a
>> certain filter is listed in the list of enabled filters).
>>
>> We have a proper system of modeling these data-driven decisions now, so
>> my opinion is we should use it and ask operators to use the placement
>> REST API for what it was intended.
> 
> I agree with the above. I think it's extremely counter-intuitive to set
> a bunch of over-subscription values only to have them ignored because a
> scheduler filter isn't configured.
> 
> If we ignore some of the resources on schedule, the compute nodes will
> start reporting values that will make the resources appear to be
> negative to anything looking at the data. Before a somewhat-recent
> change of mine, the oversubscribed computes would have *failed* to
> report negative resources at all, which was a problem for a reconfigure
> event. I think the scheduler purposefully forcing computes into the red
> is a mistake.
> 
> Further, new users that don't know our sins of the past will wonder why
> the nice system they see in front of them isn't doing the right thing.
> Existing users can reconfigure allocation ratio values before they
> upgrade. We can also add something to our upgrade status tool to warn them.
> 

It's litterally 2 days before FeatureFreeze and we ask operators to
change their cloud right now ? Looks difficult to me and like I said in
multiple places by email, we have a ton of assertions saying it's
acceptable to have not all the filters.

-Sylvain

> --Dan
> 
> __
> 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] PTL Candidacy

2017-01-24 Thread Jeremy Stanley
On 2017-01-24 13:10:26 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:
[...]
> > I guess the question I have is who, then, can tell our
> > operators/users what Neutron drivers are reasonably supported? It
> > sounds like you're saying Neutron developers are not well-placed to
> > determine that, which leaves us with these other options:
> >
> > A. Have the OpenStack Foundation as maintainers of the Marketplace
> >decide which Neutron drivers are usable (they don't really staff
> >for this purpose so would be throwing darts I think)
> >
> > B. Trust the driver authors to declare whether they're supported and
> >what features they provide (maybe that works better than I
> >expect?)
> >
> > C. Identify another party with a vested interest in validating
> >driver support (a board of operators from different organizations
> >maybe?)
> >
> > D. Provide links/aggregation of QA/CI and let the consumers attempt
> >to divine supportability for themselves (seems a bit downstream
> >hostile)
> >
> > Are any of those options preferable?
> 
> I think it's B, but under Neutron team supervision. As a first step,
> we would need to come up with an objective way to compare existing
> drivers, and anarchy in how they execute tests, set up environment,
> and publish artifacts won't make it easy.
[...]

Thanks, that's reassuring. I took your previous statements to
indicate a much more hands-off approach than your reply suggests.
This does seem at least compatible with the mix of in-tree and
out-of-tree driver tracking and feature matrices being done or
planned by the teams responsible for other services, so I have hopes
we can ultimately come up with a converged model that's not too
onerous to aggregate in the Driver Marketplace.
-- 
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-dev] [Heat] Breaking change to 3rd-party Template plugin API

2017-01-24 Thread Zane Bitter
This email is directed at anyone who maintains a 3rd-party Template 
plugin for Heat. (Do such people exist?)


Good news: you know how it's never been clear what parts of the Stack 
and Resource interfaces you could rely on to be stable? I'm proposing to 
fix that in Pike.


Bad news: you know how it's never been clear what parts of the Stack and 
Resource interfaces you could rely on to be stable? If you relied on 
stuff that wasn't used by the built-in HOT or Cfn plugins then you 
probably guessed wrong and your plugin will break.



Details here:

https://review.openstack.org/#/c/424359/3/specs/pike/stack-definition.rst

Please comment on that review if there's anything additional you'd like 
to see in the stable API. I'm happy to try to accommodate where that's 
possible (and not crazy-inefficient).


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] [operators] Optional resource asking or not?

2017-01-24 Thread Dan Smith
> No. Have administrators set the allocation ratios for the resources they
> do not care about exceeding capacity to a very high number.
> 
> If someone previously removed a filter, that doesn't mean that the
> resources were not consumed on a host. It merely means the admin was
> willing to accept a high amount of oversubscription. That's what the
> allocation_ratio is for.
> 
> The flavor should continue to have a consumed disk/vcpu/ram amount,
> because the VM *does actually consume those resources*. If the operator
> doesn't care about oversubscribing one or more of those resources, they
> should set the allocation ratios of those inventories to a high value.
> 
> No more adding configuration options for this kind of thing (or in this
> case, looking at an old configuration option and parsing it to see if a
> certain filter is listed in the list of enabled filters).
> 
> We have a proper system of modeling these data-driven decisions now, so
> my opinion is we should use it and ask operators to use the placement
> REST API for what it was intended.

I agree with the above. I think it's extremely counter-intuitive to set
a bunch of over-subscription values only to have them ignored because a
scheduler filter isn't configured.

If we ignore some of the resources on schedule, the compute nodes will
start reporting values that will make the resources appear to be
negative to anything looking at the data. Before a somewhat-recent
change of mine, the oversubscribed computes would have *failed* to
report negative resources at all, which was a problem for a reconfigure
event. I think the scheduler purposefully forcing computes into the red
is a mistake.

Further, new users that don't know our sins of the past will wonder why
the nice system they see in front of them isn't doing the right thing.
Existing users can reconfigure allocation ratio values before they
upgrade. We can also add something to our upgrade status tool to warn them.

--Dan

__
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] PTL Candidacy

2017-01-24 Thread Ihar Hrachyshka
On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
>> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
>> > I'm on board with getting visibility into the drivers with improvements to
>> > driverlog, etc. What I'm uncertain of is providing much in the lines of
>> > 'validation'. Core reviewers don't frequently have access to the hardware 
>> > or
>> > software required to validate these drivers so we can't be sure if the
>> > features really are working as expected.
>> >
>> > If validation is as flexible as you highlighted in the email, we can at
>> > least get it to a point where all recent CI runs are linkable from 
>> > driverlog
>> > and people can see recent tempest runs. I don't foresee the Neutron team
>> > getting to a point soon where we vouch for certain drivers though just
>> > because it is so hard to keep up with their changes (even ignoring changes
>> > in the vendor hardware itself).
>>
>> Good point. We may guide plugins and drivers on how to set up CI; we
>> may help Foundation to set up Marketplace in such a way that would
>> allow to automatically consume test artifacts from driver owners; we
>> may provide guidance to Foundation about which features are more
>> important to reflect that in Marketplace; but I would hope we don't
>> put the Neutron team on the hook to validate each driver, or even
>> police CI owners to produce consumable results. (The stick in the
>> latter case would be driver not showing up in Marketplace, or showing
>> up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?

I think it's B, but under Neutron team supervision. As a first step,
we would need to come up with an objective way to compare existing
drivers, and anarchy in how they execute tests, set up environment,
and publish artifacts won't make it easy.

I believe that as long as vendor CI setups are in line with our
guidelines (execute all tests and pass them, configure api_extensions
in tempest.conf to explicitly enumerate supported extensions), then we
can feed test artifacts into Marketplace, where a driver would get a
'supported'/'tested' badge for each extension enumerated in
tempest.conf as long as the latest run is success. If test run failed,
or an extension was not enumerated, then we don't have information
about whether it works with the driver, and hence will show N/A or
Unsupported in corresponding per-feature column.

Of course I assume here that support information useful to users is of
extension granularity. I think that's a reasonable assumption and is
in line with how Networking API is supposed to be consumed. We may
introduce additional tempest flags for special cases like ipv6 support
(already present) if better granularity is needed.

Ihar

__
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] Update TripleO core members

2017-01-24 Thread James Slagle
On Mon, Jan 23, 2017 at 2:03 PM, Emilien Macchi  wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.

+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


Re: [openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread James Slagle
On Tue, Jan 24, 2017 at 12:03 PM, Juan Antonio Osorio
 wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.

+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


Re: [openstack-dev] [Neutron] PTL Candidacy

2017-01-24 Thread Armando M.
On 24 January 2017 at 12:46, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
>

Even though I am not the one running, I am replying here because I feel
compelled as outgoing PTL and member of the core team to help the soon PTL
elect through this process.

In my opinion, the first thing to address is to lay down the foundations
for an objective comparison across drivers. The neutron team is obviously
best position in doing that. This was started with how we chose to organize
the neutron project, what quality criteria mattered for the team, and how
qualifying neutron features can be tracked across releases (e.g. still work
in progress in [1]).

Only after we have these solid foundations in place, we can go about the
effort of tracking the wider ecosystem of neutron plugins, and identify who
is best positioned to keep that snapshot accurate over time.

My 2c
Armando

[1] https://review.openstack.org/#/c/318192/


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


Re: [openstack-dev] [Requirements] Freeze

2017-01-24 Thread Matthew Thode
On 01/24/2017 02:28 PM, Steve Martinelli wrote:
> 
> The OpenStackClient team will be posting patches to bump the minimum
> level of python-openstacksdk to the latest release 0.9.13 (out today).
> We'll also be releasing a new python-openstackclient version (3.8.0),
> which should also be the minimum version.

That's fine, I think we expected you to be a little late considering
what you consume.

-- 
Matthew Thode (prometheanfire)



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] [puppet] Thank you.

2017-01-24 Thread Matt Fischer
Cody,

Thank you for your contributions over the years.

On Fri, Jan 20, 2017 at 12:29 PM, Cody Herriges  wrote:

> I attempted to send this out last week but think I messed it up by sending
> from my work email address which isn't the one I am signed up to the lists
> with.  Seeing Alex's note in IRC this morning reminded me that I had
> probably screwed it up...
>
> I just wanted to let everyone know how much I truly appreciate the effort
> you've all put into these modules over the years.  For me its been a long
> standing example of the maturity and utility of Puppet.
>
> Also, thank you for accepting me back into the community as a core
> reviewer after a long absence.  Ironically, my push to be move involved in
> the OpenStack community started a movement for me inside Puppet that has
> resulted in a role change from being an operator and developer to being a
> manger in our Business Development team.  This has been happening
> gradually, which is the reason for my reduced presence for several of the
> past few months and became official last week.  Since it is now official it
> marks the completion of the hand off of management of our internal cluster
> to other individuals inside Puppet so I asked Alex to remove me from core.
>
> I'll likely still pop in and out of activity but it'll largely be for
> personal reasons.  I hope to get a more hobby like enjoyment out of the low
> level practioner bits of OpenStack from here on out.
>
> --
> Cody Herriges
>
> __
> 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] [aodh][vitrage] Aodh generic alarms

2017-01-24 Thread gordon chung


On 24/01/17 03:05 PM, Julien Danjou wrote:
> I think Aodh emits notifications when something happens so it can be in
> Panko indeed. I don't think it'd be fair to force Panko to have (a
> recent) history though. :)

i'm going to add a work item (for anyone): allow multiple notification 
topics on alarmchange... i actually have no idea what is consuming those 
alarm change notifications currently.

you mean, keep alarm history in aodh and also in panko if needed? i'm ok 
with that.

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] [magnum] CoreOS template v2

2017-01-24 Thread Spyros Trigazis
Hi.

IMO, you should add a BP and start by adding a v2 driver in /contrib.

Cheers,
Spyros

On Jan 24, 2017 20:44, "Kevin Lefevre"  wrote:

> Hi,
>
> The CoreOS template is not really up to date and in sync with upstream
> CoreOS « Best Practice » (https://github.com/coreos/coreos-kubernetes),
> it is more a port of th fedora atomic template but CoreOS has its own
> Kubernetes deployment method.
>
> I’d like to implement the changes to sync kubernetes deployment on CoreOS
> to latest kubernetes version (1.5.2) along with standards components
> according the CoreOS Kubernetes guide :
>   - « Defaults » add ons like kube-dns , heapster and kube-dashboard
> (kube-ui has been deprecated for a long time and is obsolete)
>   - Canal for network policy (Calico and Flannel)
>   - Add support for RKT as container engine
>   - Support sane default options recommended by Kubernetes upstream
> (admission control : https://kubernetes.io/docs/
> admin/admission-controllers/, using service account…)
>   - Of course add every new parameters to HOT.
>
> These changes are difficult to implement as is (due to the fragment
> concept and everything is a bit messy between common and specific template
> fragment, especially for CoreOS).
>
> I’m wondering if it is better to clone the CoreOS v1 template to a new v2
> template en build from here ?
> __
> 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] PTL Candidacy

2017-01-24 Thread Jeremy Stanley
On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > I'm on board with getting visibility into the drivers with improvements to
> > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > 'validation'. Core reviewers don't frequently have access to the hardware or
> > software required to validate these drivers so we can't be sure if the
> > features really are working as expected.
> >
> > If validation is as flexible as you highlighted in the email, we can at
> > least get it to a point where all recent CI runs are linkable from driverlog
> > and people can see recent tempest runs. I don't foresee the Neutron team
> > getting to a point soon where we vouch for certain drivers though just
> > because it is so hard to keep up with their changes (even ignoring changes
> > in the vendor hardware itself).
> 
> Good point. We may guide plugins and drivers on how to set up CI; we
> may help Foundation to set up Marketplace in such a way that would
> allow to automatically consume test artifacts from driver owners; we
> may provide guidance to Foundation about which features are more
> important to reflect that in Marketplace; but I would hope we don't
> put the Neutron team on the hook to validate each driver, or even
> police CI owners to produce consumable results. (The stick in the
> latter case would be driver not showing up in Marketplace, or showing
> up with no feature support information.)

I guess the question I have is who, then, can tell our
operators/users what Neutron drivers are reasonably supported? It
sounds like you're saying Neutron developers are not well-placed to
determine that, which leaves us with these other options:

A. Have the OpenStack Foundation as maintainers of the Marketplace
   decide which Neutron drivers are usable (they don't really staff
   for this purpose so would be throwing darts I think)

B. Trust the driver authors to declare whether they're supported and
   what features they provide (maybe that works better than I
   expect?)

C. Identify another party with a vested interest in validating
   driver support (a board of operators from different organizations
   maybe?)

D. Provide links/aggregation of QA/CI and let the consumers attempt
   to divine supportability for themselves (seems a bit downstream
   hostile)

Are any of those options preferable?
-- 
Jeremy Stanley

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


Re: [openstack-dev] [Requirements] Freeze

2017-01-24 Thread Steve Martinelli
Hey Matthew,

The OpenStackClient team will be posting patches to bump the minimum level
of python-openstacksdk to the latest release 0.9.13 (out today). We'll also
be releasing a new python-openstackclient version (3.8.0), which should
also be the minimum version.

On Tue, Jan 24, 2017 at 3:22 PM, Matthew Thode 
wrote:

> We are going to be freezing Thursday at ~20:00 UTC.
>
> So if you need any changes we'll be needing needing them in soon, with
> reasoning.  Thanks.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> 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] PTL Candidacy

2017-01-24 Thread Morales, Victor
Definitely, both are great candidates and my best wishes to both during this 
process.

Given the latest issues related with the memory consumption[1] in CI jobs, I’m 
just wondering if you have a plan to deal and/or improve it in Neutron.

Regards,
Victor Morales
irc: electrocucaracha





[1] https://bugs.launchpad.net/neutron/+bug/1656386


On 1/24/17, 12:51 PM, "Ihar Hrachyshka"  wrote:

>On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
>> I'm on board with getting visibility into the drivers with improvements to
>> driverlog, etc. What I'm uncertain of is providing much in the lines of
>> 'validation'. Core reviewers don't frequently have access to the hardware or
>> software required to validate these drivers so we can't be sure if the
>> features really are working as expected.
>>
>> If validation is as flexible as you highlighted in the email, we can at
>> least get it to a point where all recent CI runs are linkable from driverlog
>> and people can see recent tempest runs. I don't foresee the Neutron team
>> getting to a point soon where we vouch for certain drivers though just
>> because it is so hard to keep up with their changes (even ignoring changes
>> in the vendor hardware itself).
>
>Good point. We may guide plugins and drivers on how to set up CI; we
>may help Foundation to set up Marketplace in such a way that would
>allow to automatically consume test artifacts from driver owners; we
>may provide guidance to Foundation about which features are more
>important to reflect that in Marketplace; but I would hope we don't
>put the Neutron team on the hook to validate each driver, or even
>police CI owners to produce consumable results. (The stick in the
>latter case would be driver not showing up in Marketplace, or showing
>up with no feature support information.)
>
>Ihar
>
>__
>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] [Requirements] Freeze

2017-01-24 Thread Matthew Thode
We are going to be freezing Thursday at ~20:00 UTC.

So if you need any changes we'll be needing needing them in soon, with
reasoning.  Thanks.

-- 
Matthew Thode (prometheanfire)



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] [aodh][vitrage] Aodh generic alarms

2017-01-24 Thread Julien Danjou
On Tue, Jan 24 2017, gordon chung wrote:

> just curious, why doesn't vitrage send an event to aodh (on the error 
> topic) in this case rather than get nova to do it? if you created an 
> event alarm in aodh to check for vitrage error events could it solve the 
> use case? i don't know if we store the event details but i imagine we 
> could? or we could store the event id which can be linked to Panko 
> (Event storage) for full metadata information?

I imagine they are or they could be forwarded as a payload when
triggering the alarm action?

> tbh, i think the alarm history should be in panko since it seems like a 
> pretty common use case to correlate an alarm event with the other events 
> in the system.

I think Aodh emits notifications when something happens so it can be in
Panko indeed. I don't think it'd be fair to force Panko to have (a
recent) history though. :)

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


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] [tc] Re: [kolla] A new kolla-salt deliverable

2017-01-24 Thread Doug Hellmann
Excerpts from Ian Cordasco's message of 2017-01-24 14:55:31 -0500:
> -Original Message-
> From: Michał Jastrzębski  
> Reply: OpenStack Development Mailing List (not for usage questions)
>  
> Date: January 24, 2017 at 11:01:14
> To: OpenStack Development Mailing List (not for usage questions)
>  
> Subject:  Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable
> 
> > Hello everyone,
> >
> > We've reached our agreement!
> > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_28264d5a40d0088c
> > New deliverable process will be lightweight - just normal +2+2+PTL
> > vote is needed to add new deliverable. I'm going to create new
> > deliverables.yaml file in Kolla repository which will allow us to keep
> > track of deliverables. Review incoming:)
> 
> Is Kolla not using openstack/releases to track deliverables? If so, why
> duplicate that information?
> 
> -- 
> Ian Cordasco

They need to be listed in openstack/governance in order to count for
elections.

Doug

__
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 Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Ryan Brady
On Tue, Jan 24, 2017 at 12:03 PM, Juan Antonio Osorio 
wrote:

> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.
>
> Best Regards,
>
>
>
> --
> Juan Antonio Osorio R.
> jaosorior
>
>
> __
> 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

2017-01-24 Thread Ian Cordasco
-Original Message-
From: Michał Jastrzębski  
Reply: OpenStack Development Mailing List (not for usage questions)
 
Date: January 24, 2017 at 11:01:14
To: OpenStack Development Mailing List (not for usage questions)
 
Subject:  Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

> Hello everyone,
>
> We've reached our agreement!
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_28264d5a40d0088c
> New deliverable process will be lightweight - just normal +2+2+PTL
> vote is needed to add new deliverable. I'm going to create new
> deliverables.yaml file in Kolla repository which will allow us to keep
> track of deliverables. Review incoming:)

Is Kolla not using openstack/releases to track deliverables? If so, why
duplicate that information?

-- 
Ian Cordasco
__
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] CoreOS template v2

2017-01-24 Thread Kevin Lefevre
Hi,

The CoreOS template is not really up to date and in sync with upstream CoreOS « 
Best Practice » (https://github.com/coreos/coreos-kubernetes), it is more a 
port of th fedora atomic template but CoreOS has its own Kubernetes deployment 
method.

I’d like to implement the changes to sync kubernetes deployment on CoreOS to 
latest kubernetes version (1.5.2) along with standards components according the 
CoreOS Kubernetes guide :
  - « Defaults » add ons like kube-dns , heapster and kube-dashboard (kube-ui 
has been deprecated for a long time and is obsolete) 
  - Canal for network policy (Calico and Flannel)
  - Add support for RKT as container engine
  - Support sane default options recommended by Kubernetes upstream (admission 
control : https://kubernetes.io/docs/admin/admission-controllers/, using 
service account…)
  - Of course add every new parameters to HOT.

These changes are difficult to implement as is (due to the fragment concept and 
everything is a bit messy between common and specific template fragment, 
especially for CoreOS).

I’m wondering if it is better to clone the CoreOS v1 template to a new v2 
template en build from here ?
__
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] [telemetry] remaining ocata items

2017-01-24 Thread gordon chung


On 24/01/17 02:05 PM, Emilien Macchi wrote:
> I'm ok if you deprecate it in Ocata, as long:
>
> 1) it's properly document how to make a transition to the new services.
> 2) We don't remove it in Pike, because work to deprecate it would have
> been done end of Ocata.
>
> Deal?

no. period. (triple period?)

.
.
.

tbh, i don't care about configurable control exchanges since it's 
already there, just not obvious unless you've hacking that specific part 
of code. also, the collector work doesn't seem to be moving so i was 
just trying to force it anyways.

i would prefer to see to the polling definition work merged since it's 
something we've been talking about for over a year now and it still 
keeps old functionality but really it's more again to clear design up a 
bit as everyone seems to think the pipeline is relevant to polling 
agents when that has not been case for a while.

long story short: you win, congrats.

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] [telemetry] remaining ocata items

2017-01-24 Thread Pradeep Kilambi
On Tue, Jan 24, 2017 at 2:05 PM, Emilien Macchi  wrote:

> On Tue, Jan 24, 2017 at 12:52 PM, gordon chung  wrote:
> >
> >
> > On 24/01/17 11:53 AM, Emilien Macchi wrote:
> >> Yes, even outside TripleO, it's already hard to follow all changes
> >> made in projects, so please do not deprecate things at the end of a
> >> cycle.
> >> Let's take some time, we do it in Pike, making good communication, so
> >> folks like TripleO etc can have the whole Pike cycle to make
> >> adjustments and we can hopefully remove this service in Queen.
> >
> > sigh, this wasn't just a decision we came up with. just that work didn't
> > get done as quick as expected. ie. all the dependent work was done in
> > beginning of cycle. i suggest you read minds better :P.
>
> I'm ok if you deprecate it in Ocata, as long:
>
> 1) it's properly document how to make a transition to the new services.
> 2) We don't remove it in Pike, because work to deprecate it would have
> been done end of Ocata.
>
> Deal?
>

from what i understand, this would mean the default would change to setting
it via
pipeline and the dispatcher options wont take effect. So this will still
impact us and
we need to make changes to templates and puppet. Its not just about
deprecating it
and removing the code

So its better we wait for pike regardless.


> --
> 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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Ben Nemec

+1

On 01/24/2017 11:03 AM, Juan Antonio Osorio wrote:

Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
on the current CI solution and in getting tripleo-quickstart jobs for
it); So I would like to propose him as part of the TripleO CI core team.

I think he'll make a great addition to the team and will help move CI
issues forward quicker.

Best Regards,



--
Juan Antonio Osorio R.
jaosorior



__
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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Wesley Hayutin
+1

On Tue, Jan 24, 2017 at 2:10 PM, Brent Eagles  wrote:

>
>
> On Tue, Jan 24, 2017 at 1:33 PM, Juan Antonio Osorio 
> wrote:
>
>> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
>> on the current CI solution and in getting tripleo-quickstart jobs for
>> it); So I would like to propose him as part of the TripleO CI core team.
>>
>> I think he'll make a great addition to the team and will help move CI
>> issues forward quicker.
>>
>> Best Regards,
>>
>>
>>
>> --
>> Juan Antonio Osorio R.
>> jaosorior
>>
>>
> ​+1​
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

2017-01-24 Thread gordon chung


On 24/01/17 03:01 AM, Afek, Ifat (Nokia - IL) wrote:
> We understood that Aodh aims to be OpenStack alarming service, which is much 
> more than an ‘engine of alarm evaluation’ (as you wrote in your comment in 
> gerrit). If I may describe another use case for generic alarms - of OPNFV 
> Doctor: A monitor notifies about an alarm, e.g. a NIC failure. The inspector 
> (Vitrage in this case) receives the alarm, understands that the host is 
> affected, and raises an alarm on the host. This is currently implemented by 
> Vitrage calling nova force-down, and Nova sending a notification that is 
> converted to an event and then consumed by an Aodh event-alarm.
>

just curious, why doesn't vitrage send an event to aodh (on the error 
topic) in this case rather than get nova to do it? if you created an 
event alarm in aodh to check for vitrage error events could it solve the 
use case? i don't know if we store the event details but i imagine we 
could? or we could store the event id which can be linked to Panko 
(Event storage) for full metadata information?

tbh, i think the alarm history should be in panko since it seems like a 
pretty common use case to correlate an alarm event with the other events 
in the system.

> In his first commit, alexey_weyl suggested to add metadata, and you asked him 
> to call it ‘userdata’. Personally, I think that metadata is more accurate. It 
> is legitimate for an alarm to have additional data, in our example we need to 
> hold the resource id and an external alarm id. When you call it userdata, it 
> indeed sounds like ‘a user datastore’ (in your words), which is not the 
> purpose at all.
> How about renaming it back to metadata? and how about adding it only to the 
> generic alarm, instead of to all alarms?

i had no idea what 'userdata' field was... i'd much prefer it be 
'metadata' even though it's a bit ambiguous.

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] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Brent Eagles
On Tue, Jan 24, 2017 at 1:33 PM, Juan Antonio Osorio 
wrote:

> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.
>
> Best Regards,
>
>
>
> --
> Juan Antonio Osorio R.
> jaosorior
>
>
​+1​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Michele Baldessari
On Tue, Jan 24, 2017 at 07:03:56PM +0200, Juan Antonio Osorio wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
> 
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.

+1

Thanks,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] [telemetry] remaining ocata items

2017-01-24 Thread Emilien Macchi
On Tue, Jan 24, 2017 at 12:52 PM, gordon chung  wrote:
>
>
> On 24/01/17 11:53 AM, Emilien Macchi wrote:
>> Yes, even outside TripleO, it's already hard to follow all changes
>> made in projects, so please do not deprecate things at the end of a
>> cycle.
>> Let's take some time, we do it in Pike, making good communication, so
>> folks like TripleO etc can have the whole Pike cycle to make
>> adjustments and we can hopefully remove this service in Queen.
>
> sigh, this wasn't just a decision we came up with. just that work didn't
> get done as quick as expected. ie. all the dependent work was done in
> beginning of cycle. i suggest you read minds better :P.

I'm ok if you deprecate it in Ocata, as long:

1) it's properly document how to make a transition to the new services.
2) We don't remove it in Pike, because work to deprecate it would have
been done end of Ocata.

Deal?
-- 
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-dev] [murano] [ptl] PTL Candidacy for Pike

2017-01-24 Thread MONTEIRO, FELIPE C
Hi,

My name is Felipe Monteiro. I have decided to run for Murano PTL for the Pike
release cycle. I would like to continue to grow Murano in order to make the
project more stable, mature and performant, while exploring avenues to evolve
the project.

I've been working on the project for the past couple months. Working with
Murano is probably the most exciting thing I do professionally. When I first
joined OpenStack, I was overwhelmed by the sheer volume of code, as well
as the complexity involved in how the various services interact. Thanks
to the welcoming culture surrounding Murano, I was immediately given help,
advice and guidance, which, after a couple months of persistence and hard work,
has enabled me to feel like a solid contributor within OpenStack.

Over the past couple months, I've been heavily invested in improving Murano's
testing framework, in order to make the project more stable and more mature.
This has resulted in Murano and Murano Dashboard's unit test coverage having
approximately doubled, as well as having various gaps in Murano Dashboard's
functional testing filled via Selenium tests. I also regularly code review
other developers' work and take on the arduous task of editing Murano's
documentation, because, as a native speaker of English, I really have no excuse
but to help out in this regard.

I'm really excited to work with Murano further, and to grow the community
surrounding it. The more companies that contribute to Murano, the stronger the
community around it will be, capable of maintaining and enhancing Murano for
years to come.

The main goals I'd like to focus on for Murano during Pike are:
* Significantly improve Murano Tempest testing. This includes integrating
   Murano with a new OpenStack project called Patrole. Patrole, a Tempest
   plugin responsible for testing Role-Based Access Control, was spearheaded
   and founded by AT developers and contributors. Its purpose is to help
   harden the security underpinning various OpenStack services - Murano
   included.
 * Significantly improve Murano documentation.
* Improve Murano's (particularly Murano Dashboard's) integration with GLARE -
   there are a number of areas in the UI where GLARE is not supported.
   These areas should be fixed to provide users who use Murano and GLARE a
   better user experience.
* Focus on addressing a number of outstanding bugs in Murano. These include
   adding SIGHUP signal support to Murano, support multiple rabbit hosts in
   RabbitMQ for Murano Agent, and addressing other UI bugs, like abandon
   environment hanging issues.

My personal ambition leads me to want to also tackle the following items:
* Possibly integrate Murano with other OpenStack projects, including
   Ceilometer, Search Light, or Kolla-Kubernetes.
 * Investigate multi-cloud support for Murano, so that it works with different
   cloud services including VMWare and Amazon.
* Increase developer contribution in Murano through my own coding efforts,
   as well as through AT's resources.

Thanks for taking the time to read through this roadmap and to consider my
candidacy. Regardless of the outcome, I'm excited to continue contributing
to Murano, be it code or code reviews.

Thank You,
Felipe Monteiro
Associate-Applications Developer
TDP - Emerging Technologies Program
Centralized Development
Office: +1 (678) 917-1767

__
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] PTL Candidacy

2017-01-24 Thread Ihar Hrachyshka
On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> I'm on board with getting visibility into the drivers with improvements to
> driverlog, etc. What I'm uncertain of is providing much in the lines of
> 'validation'. Core reviewers don't frequently have access to the hardware or
> software required to validate these drivers so we can't be sure if the
> features really are working as expected.
>
> If validation is as flexible as you highlighted in the email, we can at
> least get it to a point where all recent CI runs are linkable from driverlog
> and people can see recent tempest runs. I don't foresee the Neutron team
> getting to a point soon where we vouch for certain drivers though just
> because it is so hard to keep up with their changes (even ignoring changes
> in the vendor hardware itself).

Good point. We may guide plugins and drivers on how to set up CI; we
may help Foundation to set up Marketplace in such a way that would
allow to automatically consume test artifacts from driver owners; we
may provide guidance to Foundation about which features are more
important to reflect that in Marketplace; but I would hope we don't
put the Neutron team on the hook to validate each driver, or even
police CI owners to produce consumable results. (The stick in the
latter case would be driver not showing up in Marketplace, or showing
up with no feature support information.)

Ihar

__
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 Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread John Trowbridge


On 01/24/2017 12:03 PM, Juan Antonio Osorio wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
> 
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.
> 

+1

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


Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-24 Thread Steve Lewis
Dharini has tackled sticky bugs and complex feature work with good
judgement, patience, and agility. Her work is highly valuable to the
project and community. I'm happy to offer a vote in favor.

On Tue, Jan 24, 2017 at 5:36 AM, Brian Rosmaita 
wrote:

> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core.  She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams.  Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it.  Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering.  She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know.  I plan to add Dharini to
> the core list after this week's Glance meeting.
>
> thanks,
> brian
>
> __
> 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
>



-- 
SteveL
__
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 Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Emilien Macchi
On Tue, Jan 24, 2017 at 12:03 PM, Juan Antonio Osorio
 wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.

+1 and thanks for the proposal!

> Best Regards,
>
>
>
> --
> Juan Antonio Osorio R.
> jaosorior
>
>
> __
> 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


Re: [openstack-dev] [telemetry] remaining ocata items

2017-01-24 Thread gordon chung


On 24/01/17 11:53 AM, Emilien Macchi wrote:
> Yes, even outside TripleO, it's already hard to follow all changes
> made in projects, so please do not deprecate things at the end of a
> cycle.
> Let's take some time, we do it in Pike, making good communication, so
> folks like TripleO etc can have the whole Pike cycle to make
> adjustments and we can hopefully remove this service in Queen.

sigh, this wasn't just a decision we came up with. just that work didn't 
get done as quick as expected. ie. all the dependent work was done in 
beginning of cycle. i suggest you read minds better :P.

-- 
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] [puppet] CI status for Ubuntu

2017-01-24 Thread Julien Danjou
On Tue, Jan 24 2017, Thomas Goirand wrote:

> Check this bug entry:
> https://bugs.debian.org/851032
>
> This may have been fixed since Newton though. The FTBFS was reported
> against packages aimed for Debian Stretch.

This is likely a race condition, it has nothing to do with webob IMHO.
We fixed a few of those, so I imagine it is now fixed indeed.

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


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] [all] [tc] [api] refreshing and revalidating api compatibility guidelines

2017-01-24 Thread Chris Dent

On Mon, 23 Jan 2017, Sean Dague wrote:


We all inherited a bunch of odd and poorly defined behaviors in the
system we're using. They were made because at the time they seemed like
reasonable tradeoffs, and a couple of years later we learned more, or
needed to address a different use case that people didn't consider before.


Thanks, as usual, for providing some well considered input Sean. I
think it captures well what we could describe as the "nova
aspirational model for managing change" which essentially means:

* don't change stuff unless you have to
* when you do change stuff, anything, use microversions to signal

This is a common position and I suspect if we were to use the
voices that have spoken up so far to form the new document[1] then
it would codify that, including specifying microversions as the
technology for managing boundaries.

That could very well be fine, but we have evidence that:

* some projects don't yet use microversions in their APIs
* some projects have no intention of using microversions or at least
  have internal conflict about doing so
* some projects would like to change things (irrespective of
  microversions)

What do we do about that? That's what I think we could be working
out here, and why I'm persisting in dragging this out. There's no
point making rules that a significant portion of the populace have
no interest in following.

So the options seem to be:

* codify the two rules above as the backbone for the
  api-compatibility assertion tag and allow several projects to not
  assert that, despite an overall OpenStack goal

* keep hashing things out for a bit longer until either we have
  different rules so we have more projects liking the rules or we
  justify the rules until we have more projects accepting them

More in response to Sean below, not to contradict what he's saying
but in the ever-optimistic hope of continuing and expanding the
conversation to get real rather than enforced consensus.


If you don't guaruntee that existing applications will work in the
future (for some reasonable window of time), it's a massive turn off to
anyone deciding to use this interface at all. You suppress your user base.


I think "reasonable window of time" is a key phrase here that
perhaps we can build into the guidelines somewhat. The problems of
course are that some clouds will move forward in time at different
rates and as Sean has frequently pointed out, time's arrow is not
unidirectional in the universe of many OpenStack clouds.

To what extent is the HEAD of OpenStack responsible to OpenStack two
or three years back?

Also, when suppressing or not suppressing which user base is more
important? The users that exist now or the users to come? This may
sound like a snarky or idle question, but it's a real one: Is it
true that we do, as a general rule, base our development on existing
users and not people who have chosen not to use "the product" for
some reason?


This is a real issue. A real issue raised by users and other project
teams. I do understand that in other contexts / projects that people
have been involved in, this may not have been considered an issue. But I
would assert it is one here.


I don't think anyone disagrees with it being a real issue. Perhaps
it would be more correct to say "I agree with your assertion". I
also, however, assert that we can learn from other approaches. Not
so that we can use different approaches, but so that we can clarify
and evolve the approaches we do use so that people more fully
understand the reasons, edge cases, etc. For some the problem (and
solutions) are very well understood and accepted, for others not so
much. The compare and constrast technique is a time honored and
tested way of expanding the mind.


So before reopening the exploration of approaches (or the need to do
anything at all), we should probably narrow the focus of whether
guaruntees to the user that their existing code will continue to work is
something that we need / want. I don't see any new data coming into our
community that this is less important than it was 4 years ago.


But we do have some data (recent glance visibility situation) that
sometimes changing stuff that violates the letter of the law (but
not really the spirit?) causes indecision and confusion when
evaluating changes. Are we going to declare this okay because glance
doesn't (and can't (yet) if we assert microversions) assert api
stability support?

We also have endless data that changing APIs is part and parcel of
what we do and that change of any kind is part and parcel of living
in the real world. I think even if we are maintaining that backwards
stability is critical we need to think about the cognitive cost of
multiple microversions to users. They are under no obligation to use
the new features or the bug fixes, but they do represent fairly
constant change that you only get access to if you choose to be
aware of microversions or use particular versions of supplied
clients.

A rough 

Re: [openstack-dev] [tripleo] Update TripleO core members

2017-01-24 Thread Brent Eagles
On Mon, Jan 23, 2017 at 3:33 PM, Emilien Macchi  wrote:

> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
> --
> Emilien Macchi
>
>
​+1​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [keystone] PTL candidacy

2017-01-24 Thread Samuel de Medeiros Queiroz
Hello everyone!

I have been involved in OpenStack since late 2013 and now it is time
to put my name forward as a candidate for keystone PTL during the Pike
development cycle. See my openstack/election change in [1].


As your PTL, I would like to see our team's focuses classified into
three categories, as enumerated and detailed below:

1. Community: keeping keystone a great place to contribute

As a team, we need to ensure our project is always a welcoming place
to new contributors.

I would like to encourage community members who have more experience
in the project to take leadership roles, such as mentoring GSoC and
Outreachy programs.

Regarding those programs, it would be great to elaborate a list of
projects we consider to be interesting and that can be scoped in an
internship.

In addition, I would like to keep identifying and rewarding community
members who have been doing an outstanding job, as this helps on
keeping them motivated and knowing how great and important they are
to our community.

2. Features and testing: establishing a consistent roadmap

In terms of features, I would like to see our team keeping hardening
some features that have landed in Ocata, such as PCI-DSS and federated
auto-provisioning.

Some others would be targeted to Pike, including continuing to work in
the solution for solving the issue with long-running operations and
token expiry, and improvements in the policy mechanisms.

In terms of testing, the team has been doing a great job. Some
functional tests have been added in Ocata. I would like to see our
team to continue improving our tests in order to make sure we continue
to deliver high quality code to our users.

3. Docs: revisiting and ensuring consistency and completeness

I would like to keep revisiting our developer docs in order to make
sure new contributors have a smoothly experience when onboarding.

Furthermore, I would like to note that there is no point in having a
code that behaviors correctly if we do not teach our users how to use
our service.

With that said, in order to keep improving usability, I would like to
see the team making sure the docs are accurate and complete for our
API consumers and deployers.

There are a few ideas on how to improve docs out there, such as
api-guide docs, which main goal is to conceptually explain the service.

--

I will hapilly discuss those goals with the team during our first PTG
in Atlanta. I am looking forward to seeing you there!

Thank you,
Samuel de Medeiros Queiroz - samueldmq


[1] https://review.openstack.org/#/c/424239/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [ironic] [ptl] Ironic PTL Candidacy for Pike

2017-01-24 Thread Dmitry Tantsur

Hi all!

I am announcing my candidacy for PTL for the Ironic team for the Pike release
cycle. In case you don't know me, I'm dtantsur on IRC. I started working on
Ironic around late spring or summer 2014, and I'm probably best known as a
founder of ironic-inspector sub-project. I work for Red Hat.

The Bare metal project has been moving with an incredible pace recently. We've
got very good at defining and following our priorities (thanks Jim!). As a PTL,
I will continue facilitating setting cycle goals. I would like to incorporate
even more input from operators and people actually using Ironic.

I would like to concentrate on driving the following efforts:

* CI and testing improvements.

  The number of our jobs keeps growing, but we still don't cover a lot of
  features that Ironic provides. We had some ideas the last cycle, but we
  haven't had a chance to implement all of these.

  Additionally, there is an OpenStack-wide effort to promote Tempest plugins
  to become a generic useful and convenient tool for testing OpenStack.
  It may require a mindset shift for the developers, extensive cross-team
  communications and certain technical decisions to be made. I would be happy
  to see more downstream teams adopting our Tempest plugins as a primary way
  to conduct testing of their bare metal cloud.

* Driver improvements and unification

  First of all, we need to finish the driver composition. It will involve
  deciding the fate of the classic drivers and 3rd party CI.

  I would also like us to think more about unification between drivers.
  Several non-core things very from driver to driver: UEFI support, RAID
  support and capabilities discovery immediately come to my mind as examples.

* Of specific features, I'd particularly want to help finishing the
  boot-from-volume work and deploy steps, with RAID and partitioning as two
  applications of it.

  The latter is not going to be an easy win. Opening opportunities for
  operators and/or users to override the actions taken on deploy may shift
  the focus of Ironic to where we don't want it to be. Both RAID and
  partitioning have to find their place in the Compute API for (most of) our
  users to be able to use them.

* As our bug triager for quite some time, I'd like us to start working on our
  bug backlog more consistently. This may involve setting up regular phone
  calls for bug triaging and quick spec reviews.

* But my primary goal will be not to get in a way of our wonderful team :)

-- Dmitry Tantsur

__
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] New deadline for PTG Travel Support Program

2017-01-24 Thread Thierry Carrez
Eran Rom wrote:
>> These submissions will be evaluated next week and grantees will be
>> notified by Friday, January 20th.
> Were people who were not granted also get notifications?
> I am not sure if I was not granted or if I simply did not apply as I
> thought I did.

Yes everyone gets notifications. You're on the lucky winner list, so you
should have received an email. Let me contact you privately.

-- 
Thierry Carrez (ttx)

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


[openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

2017-01-24 Thread Juan Antonio Osorio
Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
on the current CI solution and in getting tripleo-quickstart jobs for
it); So I would like to propose him as part of the TripleO CI core team.

I think he'll make a great addition to the team and will help move CI
issues forward quicker.

Best Regards,



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


Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

2017-01-24 Thread Michał Jastrzębski
Hello everyone,

We've reached our agreement!
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_28264d5a40d0088c
New deliverable process will be lightweight - just normal +2+2+PTL
vote is needed to add new deliverable. I'm going to create new
deliverables.yaml file in Kolla repository which will allow us to keep
track of deliverables. Review incoming:)

Regards,
Michal

On 22 January 2017 at 11:52, Michał Jastrzębski  wrote:
> Our voting ends in 2 days, but it's more about process how to include
> code rather than if Kolla-salt stays. Kolla-salt resonates with Kolla
> mission very well, whether it's under Kolla umbrella or outside of it,
> I don't think anybody will block it:)
>
> Bottom line - if there will be people working on it - it's going to stay.
>
> On 22 January 2017 at 08:36, Daniel Comnea  wrote:
>> So what the conclusion with kolla-salt deliverable, has this work started,
>> if yes where is the code etc etc ?
>>
>> On Mon, Jan 2, 2017 at 1:12 PM, Thierry Carrez 
>> wrote:
>>>
>>> Michał Jastrzębski wrote:
>>> > I agree this would make good PTG discussion for us, and maybe someone
>>> > from TC could join in. We are somehow special beast as Kolla itself is
>>> > just meant to be consumed. Kolla to me is similar to Oslo in that
>>> > matter. But still we don't have oslo-compute projects, we have nova,
>>> > but we would have kolla-salt, even tho core teams would be totally
>>> > different potentially. As Britt said, growing pains.
>>>
>>> Happy to join in any discussion at the PTG on that topic.
>>>
>>> As far as our governance is concerned, "teams" decide what git
>>> repositories they vouch for -- the team's opinion being represented by
>>> the PTL. Each team is of course free to add more complex ways of
>>> gathering the "team's opinion" :)
>>>
>>> Cheers,
>>>
>>> --
>>> 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 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] Thank you.

2017-01-24 Thread Emilien Macchi
On Fri, Jan 20, 2017 at 2:29 PM, Cody Herriges  wrote:
> I attempted to send this out last week but think I messed it up by sending
> from my work email address which isn't the one I am signed up to the lists
> with.  Seeing Alex's note in IRC this morning reminded me that I had
> probably screwed it up...
>
> I just wanted to let everyone know how much I truly appreciate the effort
> you've all put into these modules over the years.  For me its been a long
> standing example of the maturity and utility of Puppet.
>
> Also, thank you for accepting me back into the community as a core reviewer
> after a long absence.  Ironically, my push to be move involved in the
> OpenStack community started a movement for me inside Puppet that has
> resulted in a role change from being an operator and developer to being a
> manger in our Business Development team.  This has been happening gradually,
> which is the reason for my reduced presence for several of the past few
> months and became official last week.  Since it is now official it marks the
> completion of the hand off of management of our internal cluster to other
> individuals inside Puppet so I asked Alex to remove me from core.
>
> I'll likely still pop in and out of activity but it'll largely be for
> personal reasons.  I hope to get a more hobby like enjoyment out of the low
> level practioner bits of OpenStack from here on out.
>
> --
> Cody Herriges
>

Thanks Cody for your help over the years, your work on Puppet4 support
and your general expertise in Puppet has been appreciated!
-- 
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] [tripleo] Update TripleO core members

2017-01-24 Thread Ben Nemec

+1

On 01/23/2017 01:03 PM, Emilien Macchi wrote:

Greeting folks,

I would like to propose some changes in our core members:

- Remove Jay Dobies who has not been active in TripleO for a while
(thanks Jay for your hard work!).
- Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
docker bits.
- Add Steve Backer on os-collect-config and also docker bits in
tripleo-common and tripleo-heat-templates.

Indeed, both Flavio and Steve have been involved in deploying TripleO
in containers, their contributions are very valuable. I would like to
encourage them to keep doing more reviews in and out container bits.

As usual, core members are welcome to vote on the changes.

Thanks,



__
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][swg] Sessions for Atlanta PTG - writing a TC Vision/Other options

2017-01-24 Thread Alexis Monville
On Mon, Jan 23, 2017 at 2:00 PM, Colette Alexander
 wrote:
> Hello Stackers,
>
> As we move into the last four weeks of work before the PTG in Atlanta, I
> wanted to check in to talk about what the Stewardship Working Group has
> planned and what we're looking to accomplish during our one day (Monday) at
> the gathering.
>
> Currently, discussing among SWG members has focused around a few things:
>
> 1) Assisting the TC with writing a vision
> 2) Assessing our previous work list [0] and prioritizing future work for the
> SWG based on the community's interest in that list
> 3) Creating space for drop-in/community feedback on what we should work on
> next, and how it should be prioritized.
>
> 1) the TC Vision is on hold, and won't happen at the PTG. Since so many
> contributors would've been in other cross project sessions throughout Monday
> we thought it would be wiser to hold off, and do a facilitated vision during
> another time when the TC might be able to fully focus on it for a day. We're
> still working on timing for that, but I will keep everyone posted once I
> know what we've settled on.
>
> 2 and 3 are listed on our etherpad/vision for the PTG [1], with 2 currently
> scheduled in the morning, and 3 planned for a general availability for
> drop-in feedback in the afternoon (as we assume more people will have more
> sessions and less flexible schedules at that point, so drop-ins will be the
> easiest way to allow anyone who is interested in what we do to stop by and
> participate).
>
> I'd love feedback on that, scheduling wise, from any folks interested in
> participating. I'd also love to hear any other ideas about what we could
> cover during our day that might be useful.
>
> I spent quite a bit of our cross project session at the Ocata Summit doing a
> quick recap of the concept of Servant Leadership and it seemed like plenty
> of attendees appreciated that. Would a series of quick recaps of basic
> leadership concepts (Servant Leadership, Visioning, Principles & Culture,
> and Change Management) - if anyone is interested in having a small
> discussion covering some of those topics, I'd love to hear from you!

Thank you Colette!
Do you think those discussions need to happen during the PTG in
Atlanta, or could we also asked for online conversations on those
topics?

>
> Thanks so much, everyone - can't wait to see you all in Atlanta!
>
> -colette/gothicmindfood
>
>
> [0] https://etherpad.openstack.org/p/swg-short-list-deliverables
> [1] https://etherpad.openstack.org/p/AtlantaPTG-SWG
>
> __
> 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
>



-- 

Alexis


Alexis Monville
alexis.monvi...@redhat.com
c +1 978-735-7578
w +1 857-770-0416
irc: alexismonville
Linkedin: fr.linkedin.com/in/alexismonville
Twitter: https://twitter.com/alexismonville

__
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] [telemetry] remaining ocata items

2017-01-24 Thread Emilien Macchi
On Tue, Jan 24, 2017 at 10:53 AM, Julien Danjou  wrote:
> On Tue, Jan 24 2017, gordon chung wrote:
>
>> ceilometer
>> - polling definition file support [1]
>> - configurable control exchanges [2]
>> - deprecate collector [3]
>
> I've -2ed this for now because it is too late to have the TripleO
> changes pushed. That's a shame, but we'll do it first week in Pike.

Yes, even outside TripleO, it's already hard to follow all changes
made in projects, so please do not deprecate things at the end of a
cycle.
Let's take some time, we do it in Pike, making good communication, so
folks like TripleO etc can have the whole Pike cycle to make
adjustments and we can hopefully remove this service in Queen.

>> - equivalent publisher/dispatcher support [4]
>>
>> gnocchi
>> - creator(user+project) unique ids [5]
>
> Not required but https://review.openstack.org/#/c/417340/ is lying
> around for 2 weeks. :)
>
> --
> 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
>



-- 
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-dev] [puppet] Thank you.

2017-01-24 Thread Cody Herriges

I attempted to send this out last week but think I messed it up by sending from 
my work email address which isn't the one I am signed up to the lists with. 
Seeing Alex's note in IRC this morning reminded me that I had probably screwed 
it up...

I just wanted to let everyone know how much I truly appreciate the effort 
you've all put into these modules over the years. For me its been a long 
standing example of the maturity and utility of Puppet.

Also, thank you for accepting me back into the community as a core reviewer 
after a long absence. Ironically, my push to be move involved in the OpenStack 
community started a movement for me inside Puppet that has resulted in a role 
change from being an operator and developer to being a manger in our Business 
Development team. This has been happening gradually, which is the reason for my 
reduced presence for several of the past few months and became official last 
week. Since it is now official it marks the completion of the hand off of 
management of our internal cluster to other individuals inside Puppet so I 
asked Alex to remove me from core. 

I'll likely still pop in and out of activity but it'll largely be for personal 
reasons. I hope to get a more hobby like enjoyment out of the low level 
practioner bits of OpenStack from here on out.

--
Cody Herriges
__
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] Device tag in the API breaks in the old microversion

2017-01-24 Thread Matt Riedemann

On 1/24/2017 9:18 AM, Matt Riedemann wrote:


First, thanks to Kevin and Alex for finding this issue and explaining it
in detail so we can understand the scope.

This is a nasty unfortunate issue which I really wish we could just fix
without a microversion bump but we have microversions for a reason,
which is to fix issues in the API. In thinking about if this were the
legacy 2.0 API, we always had a rule that you couldn't fix bugs in the
API if they changed the behavior, no matter how annoying.

So let's fix this with a microversion. I don't think we need to hold it
to the feature freeze deadline as it's a microversion only for a bug
fix, it's not a new feature. So that's a compromise at least and gives
us some time to get this done correctly and still have it fixed in
Ocata. We'll also want to document this in the api-ref and REST API
version history in whatever way makes it clear about the limitations
between microversions.

As for testing, I think using a mix of test inheritance and using
2.latest is probably a good step to take. I know we've had a mix of that
in different places in the functional API samples tests, but there was
never a clear rule about what do to with testing microversions and if
you should use inheritance to build on existing tests.



One other thing: we're going to need to also fix this in 
python-novaclient, which we might want to do first, or work 
concurrently, since that's going to give us the client side perspective 
on how gross it will be to deal with this issue.


--

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] Device tag in the API breaks in the old microversion

2017-01-24 Thread Matt Riedemann

On 1/24/2017 2:05 AM, Alex Xu wrote:

Unfortunately the device tag support in the API was broken in the old
Microversion https://bugs.launchpad.net/nova/+bug/1658571, which thanks
to Kevin Zheng to find out that.

Actually there are two bugs, just all of them are about device tag. The
first one [0] is a mistake in the initial introduce of device tag. The
new schema only available for the version 2.32, when the request version

2.32, the schema fallback to the old one.


The second one [1] is that when we bump the API to 2.37, the network
device tag was removed accidentally which also added in 2.32 [2].

So the current API behavior is as below:

2.32: BDM tag and network device tag added.
2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
works.
2.37: The network device tag disappeared also.

There are few questions we should think about:

1. Should we fix that by Microversion?
Thanks to Chris Dent point that out in the review. I also think we
need to bump Microversion, which follow the rule of Microversion.

2. If we need Microversion, is that something we can do before release?
We are very close to the feature freeze. And in normal, we need spec
for microversion. Maybe we only can do that in Pike. For now we can
update the API-ref, and microversion history to notice that, maybe a
reno also.

2. How can we prevent that happened again?
   Both of those patches were reviewed multiple cycles. But we still
miss that. It is worth to think about how to prevent that happened again.

   Talk with Sean. He suggests stop passing plain string version to the
schema extension point. We should always pass APIVersionRequest object
instead of plain string. Due to "version == APIVersionRequest('2.32')"
is always wrong, we should remove the '__eq__'. The developer should
always use the 'APIVersionRequest.matches' [3] method.

   That can prevent the first mistake we made. But nothing help for
second mistake. Currently we only run the test on the specific
Microversion for the specific interesting point. In the before, the new
tests always inherits from the previous microversion tests, just like
[4]. That can test the old API behavior won't be changed in the new
microversion. But now, we said that is waste, we didn't do that again
just like [5]. Should we change that back?

Thanks
Alex

[0]
https://review.openstack.org/#/c/304510/64/nova/api/openstack/compute/block_device_mapping.py
[1] 
https://review.openstack.org/#/c/316398/37/nova/api/openstack/compute/schemas/servers.py@88
[2] 
https://review.openstack.org/#/c/316398/37/nova/api/openstack/compute/schemas/servers.py@79
[3] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/api_version_request.py#L219
[4] 
https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_evacuate.py#L415
[5] 
https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_serversV21.py#L3584



__
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



First, thanks to Kevin and Alex for finding this issue and explaining it 
in detail so we can understand the scope.


This is a nasty unfortunate issue which I really wish we could just fix 
without a microversion bump but we have microversions for a reason, 
which is to fix issues in the API. In thinking about if this were the 
legacy 2.0 API, we always had a rule that you couldn't fix bugs in the 
API if they changed the behavior, no matter how annoying.


So let's fix this with a microversion. I don't think we need to hold it 
to the feature freeze deadline as it's a microversion only for a bug 
fix, it's not a new feature. So that's a compromise at least and gives 
us some time to get this done correctly and still have it fixed in 
Ocata. We'll also want to document this in the api-ref and REST API 
version history in whatever way makes it clear about the limitations 
between microversions.


As for testing, I think using a mix of test inheritance and using 
2.latest is probably a good step to take. I know we've had a mix of that 
in different places in the functional API samples tests, but there was 
never a clear rule about what do to with testing microversions and if 
you should use inheritance to build on existing tests.


--

Thanks,

Matt Riedemann

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


Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

2017-01-24 Thread Mikhail Fedosin
Hey, Flavio :) Thanks for your questions!

As you said currently only Nokia's adopting Glare for its own platform, but
if we talk about OpenStack, that I believe Mistral will start to use it
soon.
In my opinion Glare's adoption is low due to the fact that the project is
not included under Big Tent. I think it will be changed soon, because now
I'm finishing Glare v1 API proposal, and when it's done we will apply under
BT.

About Glance v2 API - as I said they are +- the same with several cosmetic
differences (in Glance status is called 'queued', in Glare we renamed it to
'drafted', and so on). For this reason I'm going to implement a middleware,
that will provide a full Image API v2 for Glare (even with unnecessary
'/v2' prefix) and glance clients will be able to communicate with it as
with Glance. It's definitely doable and we can discuss it more detailed
during the PTG.

Best,
Mike

On Mon, Jan 23, 2017 at 11:51 AM, Flavio Percoco  wrote:

> On 19/01/17 12:48 +0300, Mikhail Fedosin wrote:
>
>> Hi Matt!
>>
>> This should be discussed, for sure, but there is a lot of potential. In
>> general, it depends on how far we are willing to go. In the minimum
>> approximation we can seamlessly replace Glance with Glare and operators
>> simply get additional features for versioning, validation (and conversion,
>> if necessary) of their uploaded images on the fly, as well as support for
>> storing files in different stores.
>>
>> If we dig a little deeper, then Glare allows you to store multiple files
>> in
>> a single artifact, so we can create a new type (ec2_image) and define
>> three
>> blobs inside: ami, ari, aki, and upload all three as a single object. This
>> will get rid of a large amount of legacy code and simplify the
>> architecture
>> of Nova. Plus Glare will control the integrity of such artifact.
>>
>
> Hey Mike,
>
> Thanks for bringing this up. While I think there's potential in Glare
> given it's
> being created during a more mature age of OpenStack and based on matured
> principles and standards, I believe you may be promoting Glare using the
> wrong
> arguments.
>
> As you mentioned in your first email on this thread, Glare has a set of
> functionalities that are already useful to a set of existing projects.
> This is
> great and I'd probably start from there.
>
> * How much have these projects adopted Glare?
> * Is Glare being deployed already?
> * What projects are the main consumers of Glare?
>
> Unfortunately, replacing Glance is not as simple as dropping Glare in
> because
> it's not only being used by Nova. Glance is also a public API (at least
> v2) and
> there are integrations that have been built by either cloud providers or
> cloud
> consumers on top of the existing Glance API.
>
> If Glare ships a Glance compatible API (as a way to make a drop-in
> replacement
> possible), it'll have to support it and live with it for a long time. In
> addition to this, Glare will have to keep up with the changes that may
> happen in
> Glance's API during that time.
>
> The next step could be full support for OVF and other formats that require
>> a large number of files. Here we can use artifact folders and put all the
>> files there.
>> "OpenStack Compute does not currently have support for OVF packages, so
>> you
>> will need to extract the image file(s) from an OVF package if you wish to
>> use it with OpenStack."
>> http://docs.openstack.org/image-guide/introduction.html
>>
>> Finally, I notice that there are a few nasty bugs in Glance (you know what
>> I mean), which make it extremely inconvenient for a number of deployments.
>>
>
> Not everyone is familiar with the issues of Glance's API. I believe I know
> what
> you're referring to but I'd recommend to expand here for the sake of
> discussion.
>
> That being said, I'd also like to point out that the flaws of Glance's API
> could
> be fixed so I'd rather focus the discussion on the benefits Glare would
> bring
> rather than how Glance's API may or may not be terrible. That's the kind of
> competition I'd prefer to see in this discussion.
>
> Cheers,
> Flavio
>
>
> On Wed, Jan 18, 2017 at 8:26 PM, Matt Riedemann <
>> mrie...@linux.vnet.ibm.com>
>> wrote:
>>
>> On 1/18/2017 10:54 AM, Mikhail Fedosin wrote:
>>>
>>> Hello!

 In this letter I want to tell you the current status of Glare project
 and discuss its future development within the entire OpenStack
 community.

 In the beginning I have to say a few words about myself - my name is
 Mike and I am the PTL of Glare. Currently I work as a consultant at
 Nokia, where we're developing the service as a universal catalog of
 binary data. As I understand it right, Nokia has big plans for this
 service, Moshe Elisha can tell you more about them.

 And here I want to ask the community - how exactly Glare may be useful
 in OpenStack? Glare was developed as a repository for all possible data
 types, and it has many possible 

Re: [openstack-dev] [puppet] CI status for Ubuntu

2017-01-24 Thread Thomas Goirand
On 01/24/2017 04:15 PM, Julien Danjou wrote:
> On Tue, Jan 24 2017, Thomas Goirand wrote:
> 
>> FYI, this was a very unfortunate upload of the latest webob version in
>> Sid, which was reverted. IMO though, OpenStack should prepare itself to
>> support the latest version to avoid failures once we decide that webob
>> 1.7.x should be uploaded again. Affected projects:
>>
>> - glance
>> - gnocchi
>> - keystone
>> - nova
>> - keystonemiddleware
>> - oslo.middleware
> 
> What are the failure with Gnocchi? We run the tests with WebOb 1.7.0 and
> everything works fine.
> 

Check this bug entry:
https://bugs.debian.org/851032

This may have been fixed since Newton though. The FTBFS was reported
against packages aimed for Debian Stretch.

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] [telemetry] remaining ocata items

2017-01-24 Thread Julien Danjou
On Tue, Jan 24 2017, gordon chung wrote:

> ceilometer
> - polling definition file support [1]
> - configurable control exchanges [2]
> - deprecate collector [3]

I've -2ed this for now because it is too late to have the TripleO
changes pushed. That's a shame, but we'll do it first week in Pike.

> - equivalent publisher/dispatcher support [4]
>
> gnocchi
> - creator(user+project) unique ids [5]

Not required but https://review.openstack.org/#/c/417340/ is lying
around for 2 weeks. :)

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


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] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Davanum Srinivas
Cool. Then i'd support a backport when the review against master
merges. Thanks Ann and Kirill.

-- Dims

On Tue, Jan 24, 2017 at 10:33 AM, Anna Taraday
 wrote:
> Nope, this won't be necessary.
>
> 0.8.10 - allows us to create pk on alembic_version table automatically, but
> only for new deployments.
>
> I propose manually add pk on this table if it is not existing.
>
> On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas  wrote:
>>
>> Ann,
>>
>> Don't you still need alembic>=0.8.10 to be present?
>>
>> -- Dims
>>
>> On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday
>>  wrote:
>> > We do not backport db changes, but if the existing migration does not
>> > work
>> > in certain circumstances, should not we fix it to make it work if it is
>> > possible?
>> > This will allow to deploy new deployments with Newton code on Galera.
>> >
>> > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas 
>> > wrote:
>> >>
>> >> Please see
>> >>
>> >> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
>> >>
>> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas 
>> >> wrote:
>> >> > Newton is already shipped!
>> >> >
>> >> > -- Dims
>> >> >
>> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
>> >> >  wrote:
>> >> >> Galera only supported since Ocata?
>> >> >>
>> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Kirill,
>> >> >>>
>> >> >>> "If OS wants support Galera, it needs to comply with the Galera
>> >> >>> requirements" <<< This is true for master/ocata NOT Newton.
>> >> >>>
>> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in
>> >> >>> the
>> >> >>> community to highlight the possibility of this situation.
>> >> >>> Downstream
>> >> >>> folks can do what they need/have to do for Newton.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> Dims
>> >> >>>
>> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin
>> >> >>>  wrote:
>> >> >>> > HI!
>> >> >>> >
>> >> >>> > Thing is, running Galera without enforcing it very bad idea for
>> >> >>> > production
>> >> >>> > use. Permissive mode was added more or less for testing purposes,
>> >> >>> > running
>> >> >>> > real production with it is dangerous, since it's not enforcing
>> >> >>> > the
>> >> >>> > mandatory
>> >> >>> > Galera requirement, one of them is a "All tables must have a
>> >> >>> > primary
>> >> >>> > key".
>> >> >>> > You cant disable a single check, you could only disable them all
>> >> >>> > and
>> >> >>> > this
>> >> >>> > could lead to some serious problems, like data loss or
>> >> >>> > corruption.
>> >> >>> >
>> >> >>> > If OS wants support Galera, it needs to comply with the Galera
>> >> >>> > requirements.
>> >> >>> >
>> >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> An alternative could also be, for Newton and earlier, to release
>> >> >>> >> a
>> >> >>> >> note saying that operators should not run the code against
>> >> >>> >> ENFORCING
>> >> >>> >> galera mode. What are the reasons to enable that mode in
>> >> >>> >> OpenStack
>> >> >>> >> scope that would not allow operators to live without it for
>> >> >>> >> another
>> >> >>> >> cycle?
>> >> >>> >>
>> >> >>> >> Ihar
>> >> >>> >>
>> >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday
>> >> >>> >>  wrote:
>> >> >>> >> > Hello everyone!
>> >> >>> >> >
>> >> >>> >> > Guys in our team faced an issue when they try to run alembic
>> >> >>> >> > migrations
>> >> >>> >> > on
>> >> >>> >> > Galera with ENFORCING mode. [1]
>> >> >>> >> >
>> >> >>> >> > This was an issue with Alembic [2], which was quickly fixed by
>> >> >>> >> > Mike
>> >> >>> >> > Bayer
>> >> >>> >> > (many thanks!) and new version of alembic was resealed [3].
>> >> >>> >> > The global requirements are updated [4].
>> >> >>> >> >
>> >> >>> >> > I think that it is desired to fix this for Newton at least. We
>> >> >>> >> > cannot
>> >> >>> >> > bump
>> >> >>> >> > requirements for Newton, so hot fix can be putting pk on this
>> >> >>> >> > table
>> >> >>> >> > in
>> >> >>> >> > the
>> >> >>> >> > first migration like proposed [5].  Any other ideas?
>> >> >>> >> >
>> >> >>> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610
>> >> >>> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406
>> >> >>> >> > [3] -
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
>> >> >>> >> > [4] - https://review.openstack.org/#/c/423118/
>> >> >>> >> > [5] - https://review.openstack.org/#/c/419320/
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> > --
>> >> >>> >> > Regards,
>> >> >>> >> > Ann Taraday
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> 

[openstack-dev] [telemetry] remaining ocata items

2017-01-24 Thread gordon chung
hi,

so i just wanted to create a list of items i'm tracking for ocata that 
i'd like to see in:

ceilometer
- polling definition file support [1]
- configurable control exchanges [2]
- deprecate collector [3]
- equivalent publisher/dispatcher support [4]

gnocchi
- creator(user+project) unique ids [5]

panko
- none

aodh
- none

are there any items missing? items that we don't care about?

[1] https://review.openstack.org/#/c/405682
[2] https://review.openstack.org/#/c/422411
[3] https://review.openstack.org/#/c/413920
[4] https://review.openstack.org/#/c/396771
[5] https://review.openstack.org/#/c/413017

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] [All projects that use Alembic] Absence of pk on alembic_version table

2017-01-24 Thread Anna Taraday
Nope, this won't be necessary.

0.8.10 - allows us to create pk on alembic_version table automatically, but
only for new deployments.

I propose manually add pk on this table if it is not existing.

On Tue, Jan 24, 2017 at 7:25 PM Davanum Srinivas  wrote:

> Ann,
>
> Don't you still need alembic>=0.8.10 to be present?
>
> -- Dims
>
> On Tue, Jan 24, 2017 at 10:05 AM, Anna Taraday
>  wrote:
> > We do not backport db changes, but if the existing migration does not
> work
> > in certain circumstances, should not we fix it to make it work if it is
> > possible?
> > This will allow to deploy new deployments with Newton code on Galera.
> >
> > On Tue, Jan 24, 2017 at 6:45 PM Davanum Srinivas 
> wrote:
> >>
> >> Please see
> >>
> http://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
> >>
> >> On Tue, Jan 24, 2017 at 9:34 AM, Davanum Srinivas 
> >> wrote:
> >> > Newton is already shipped!
> >> >
> >> > -- Dims
> >> >
> >> > On Tue, Jan 24, 2017 at 9:23 AM, Kirill Proskurin
> >> >  wrote:
> >> >> Galera only supported since Ocata?
> >> >>
> >> >> On Tue, Jan 24, 2017 at 4:30 PM, Davanum Srinivas  >
> >> >> wrote:
> >> >>>
> >> >>> Kirill,
> >> >>>
> >> >>> "If OS wants support Galera, it needs to comply with the Galera
> >> >>> requirements" <<< This is true for master/ocata NOT Newton.
> >> >>>
> >> >>> Ihar's response is perfectly acceptable thing to do for Newton in
> the
> >> >>> community to highlight the possibility of this situation. Downstream
> >> >>> folks can do what they need/have to do for Newton.
> >> >>>
> >> >>> Thanks,
> >> >>> Dims
> >> >>>
> >> >>> On Tue, Jan 24, 2017 at 4:49 AM, Kirill Proskurin
> >> >>>  wrote:
> >> >>> > HI!
> >> >>> >
> >> >>> > Thing is, running Galera without enforcing it very bad idea for
> >> >>> > production
> >> >>> > use. Permissive mode was added more or less for testing purposes,
> >> >>> > running
> >> >>> > real production with it is dangerous, since it's not enforcing the
> >> >>> > mandatory
> >> >>> > Galera requirement, one of them is a "All tables must have a
> primary
> >> >>> > key".
> >> >>> > You cant disable a single check, you could only disable them all
> and
> >> >>> > this
> >> >>> > could lead to some serious problems, like data loss or corruption.
> >> >>> >
> >> >>> > If OS wants support Galera, it needs to comply with the Galera
> >> >>> > requirements.
> >> >>> >
> >> >>> > On Mon, Jan 23, 2017 at 9:59 PM, Ihar Hrachyshka
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> An alternative could also be, for Newton and earlier, to release
> a
> >> >>> >> note saying that operators should not run the code against
> >> >>> >> ENFORCING
> >> >>> >> galera mode. What are the reasons to enable that mode in
> OpenStack
> >> >>> >> scope that would not allow operators to live without it for
> another
> >> >>> >> cycle?
> >> >>> >>
> >> >>> >> Ihar
> >> >>> >>
> >> >>> >> On Mon, Jan 23, 2017 at 10:12 AM, Anna Taraday
> >> >>> >>  wrote:
> >> >>> >> > Hello everyone!
> >> >>> >> >
> >> >>> >> > Guys in our team faced an issue when they try to run alembic
> >> >>> >> > migrations
> >> >>> >> > on
> >> >>> >> > Galera with ENFORCING mode. [1]
> >> >>> >> >
> >> >>> >> > This was an issue with Alembic [2], which was quickly fixed by
> >> >>> >> > Mike
> >> >>> >> > Bayer
> >> >>> >> > (many thanks!) and new version of alembic was resealed [3].
> >> >>> >> > The global requirements are updated [4].
> >> >>> >> >
> >> >>> >> > I think that it is desired to fix this for Newton at least. We
> >> >>> >> > cannot
> >> >>> >> > bump
> >> >>> >> > requirements for Newton, so hot fix can be putting pk on this
> >> >>> >> > table
> >> >>> >> > in
> >> >>> >> > the
> >> >>> >> > first migration like proposed [5].  Any other ideas?
> >> >>> >> >
> >> >>> >> > [1] - https://bugs.launchpad.net/neutron/+bug/1655610
> >> >>> >> > [2] - https://bitbucket.org/zzzeek/alembic/issues/406
> >> >>> >> > [3] -
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
> >> >>> >> > [4] - https://review.openstack.org/#/c/423118/
> >> >>> >> > [5] - https://review.openstack.org/#/c/419320/
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > --
> >> >>> >> > Regards,
> >> >>> >> > Ann Taraday
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> __
> >> >>> >> > 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] [glance] Propose Dharini Chandrasekar for Glance core

2017-01-24 Thread Ian Cordasco
-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 24, 2017 at 07:37:24
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

> I'd like to propose Dharini Chandrasekar (dharinic on IRC) for Glance
> core. She has been an active reviewer and contributor to the Glance
> project during the Newton and Ocata cycles, has contributed to other
> OpenStack projects, and has represented Glance in some interactions with
> other project teams. Additionally, she recently jumped in and saw
> through to completion a high priority feature for Newton when the
> original developer was unable to continue working on it. Plus, she's
> willing to argue with me (and the other cores) about points of software
> engineering. She will be a great addition to the Glance core reviewers
> team.
>
> If you have any concerns, please let me know. I plan to add Dharini to
> the core list after this week's Glance meeting.

0 concerns on my end.

Good work, Dharini!

--
Ian Cordasco

__
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] [vote][kolla] deprecation for Debian distro support

2017-01-24 Thread Steven Dake (stdake)
Gema,

Yes team meeting sounds good.

I am changing my vote from choice 2 to abstain until this is sorted out.

Regards
-steve


-Original Message-
From: Gema Gomez 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, January 24, 2017 at 7:42 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

Hi,

we had a brief conversation in the channel about this.

My team at Linaro is planning to start working with Kolla after the PTG
to produce fully deployable ARM64 containers. The preference for us is
to produce Debian based containers, as well as any others that are
required to meet the project requirements.

I'd like to discuss this a bit further, we may be able to help with the
lack of support, but we need to understand how much work would be required.

Can we discuss further at the team meeting tomorrow?

Thanks,
Gema


On 19/01/17 10:53, Christian Berendt wrote:
> As discussed in one of the last team meetings I want to propose the 
deprecation (this cycle) and removal (next cycle) of the Debian support in 
Kolla.
> 
> More than 1 week ago I sent a pre warning mail to the openstack-operators 
mailing list, without any reply [0].
> 
> Kolla core reviewers, please vote now. The vote will be open for 7 days 
(26.01.2017).
> 
> 1. Kolla needs support for Debian, it should not be deprecated
> 
> 2. Kolla should deprecate support for Debian
> 
> [0] 
http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html
> 

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


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


  1   2   >