date:20160811

Re: [openstack-dev] [Kuryr] Need help in jenkins failure

2016-08-11 Thread Vikas Choudhary

On Fri, Aug 12, 2016 at 11:13 AM, Liping Mao (limao) 
wrote:

> Just guess, Maybe you install "kuryr-lib” by manually from offical repo?
> :-)
>
> Nope, i was not installing manually andwas just doing 'tox -e py27'.
I uncommented that and 'recheck' on patch. Lets see :)


> Regards,
> Liping Mao
>
> From: Vikas Choudhary 
> Date: 2016年8月12日 星期五 下午1:33
> To: Liping Mao 
> Cc: OpenStack List , Irena Berezovsky <
> ir...@midokura.com>, Antoni Segura Puimedon ,
> Gal Sagie , Mohammad Banikazemi 
> Subject: Re: [Kuryr] Need help in jenkins failure
>
> Thanks Liping, this seems to be the reason for sure.
>
> Still wondering how come it works on local system. Let me check  again.
>
>
> -Vikas
>
>
>
>
> On Fri, Aug 12, 2016 at 10:58 AM, Liping Mao (limao) 
> wrote:
>
>> Hi Vikas,
>>
>> Not sure , but is it because this line?
>> https://github.com/vikaschoudhary16/kuryr/blob/drop_libnet_
>> specific_code/ku
>> ryr/lib/config.py#L105
>> 
>>
>> Thanks.
>>
>>
>>
>> Regards,
>> Liping Mao
>>
>>
>> From:  Vikas Choudhary 
>> Date:  2016年8月12日 星期五 下午12:32
>> To:  OpenStack List , Irena Berezovsky
>> , Antoni Segura Puimedon
>> , Gal Sagie ,
>> Mohammad
>> Banikazemi , Liping Mao 
>> Subject:  [Kuryr] Need help in jenkins failure
>>
>>
>> Hello Everybody,
>>
>>
>> I am not able to reproduce jenkins failure (tox -e py27) on this,[1] ,
>> patch when trying locally. I have tried "recheck" also. There is something
>> wrong which i am not able to catch. I have spent a good effort on
>> analysing this but no clue.
>>
>>
>>
>> Will appreciate if anybody try this patch locally and provide some input
>> on how can i fix this?
>>
>>
>>
>> Regards
>>
>> Vikas Choudhary
>>
>> [1] https://review.openstack.org/#/c/350406/
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Need help in jenkins failure

2016-08-11 Thread Liping Mao (limao)

Just guess, Maybe you install "kuryr-lib” by manually from offical repo? :-)

Regards,
Liping Mao

From: Vikas Choudhary 
>
Date: 2016年8月12日 星期五 下午1:33
To: Liping Mao >
Cc: OpenStack List 
>, 
Irena Berezovsky >, Antoni Segura 
Puimedon >, 
Gal Sagie >, Mohammad 
Banikazemi >
Subject: Re: [Kuryr] Need help in jenkins failure

Thanks Liping, this seems to be the reason for sure.

Still wondering how come it works on local system. Let me check  again.

-Vikas

On Fri, Aug 12, 2016 at 10:58 AM, Liping Mao (limao) 
> wrote:
Hi Vikas,

Not sure , but is it because this line?
https://github.com/vikaschoudhary16/kuryr/blob/drop_libnet_specific_code/ku
ryr/lib/config.py#L105

Thanks.

Regards,
Liping Mao

From:  Vikas Choudhary 
>
Date:  2016年8月12日 星期五 下午12:32
To:  OpenStack List 
>, 
Irena Berezovsky
>, Antoni Segura Puimedon
>, Gal 
Sagie >, Mohammad
Banikazemi >, Liping Mao 
>
Subject:  [Kuryr] Need help in jenkins failure

Hello Everybody,

I am not able to reproduce jenkins failure (tox -e py27) on this,[1] ,
patch when trying locally. I have tried "recheck" also. There is something
wrong which i am not able to catch. I have spent a good effort on
analysing this but no clue.

Will appreciate if anybody try this patch locally and provide some input
on how can i fix this?

Regards

Vikas Choudhary

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

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

Re: [openstack-dev] [Kuryr] Need help in jenkins failure

2016-08-11 Thread Vikas Choudhary

Thanks Liping, this seems to be the reason for sure.

Still wondering how come it works on local system. Let me check  again.


-Vikas




On Fri, Aug 12, 2016 at 10:58 AM, Liping Mao (limao) 
wrote:

> Hi Vikas,
>
> Not sure , but is it because this line?
> https://github.com/vikaschoudhary16/kuryr/blob/
> drop_libnet_specific_code/ku
> ryr/lib/config.py#L105
>
> Thanks.
>
>
>
> Regards,
> Liping Mao
>
>
> From:  Vikas Choudhary 
> Date:  2016年8月12日 星期五 下午12:32
> To:  OpenStack List , Irena Berezovsky
> , Antoni Segura Puimedon
> , Gal Sagie , Mohammad
> Banikazemi , Liping Mao 
> Subject:  [Kuryr] Need help in jenkins failure
>
>
> Hello Everybody,
>
>
> I am not able to reproduce jenkins failure (tox -e py27) on this,[1] ,
> patch when trying locally. I have tried "recheck" also. There is something
> wrong which i am not able to catch. I have spent a good effort on
> analysing this but no clue.
>
>
>
> Will appreciate if anybody try this patch locally and provide some input
> on how can i fix this?
>
>
>
> Regards
>
> Vikas Choudhary
>
> [1] https://review.openstack.org/#/c/350406/
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] mcollective configuration on slaves

2016-08-11 Thread Georgy Kibardin

Guys,

Currently, at the time of the first boot Mcollective on slaves is
configured by Cloud-init (host, port etc.) and by Nailgun agent when node
identity is written. This happens in any order and already caused several
problem which were fixed in bounds of
https://bugs.launchpad.net/fuel/+bug/1455489. The last fix relies on
hostname to figure that the provisioning is over and prevent Nailgun agent
from messing with Mcollective. This solution is quite hacky and, I think,
we need to come up with a better fix. So, the options are:

1. Do nothing
  + No effort, no regression
  - Existing solution is fragile and not simple enough to be sure that
there are obviously no more bugs.
  - Cloud-init does things on early boot stages which is a bit hard to
debug.

2. "Manual" Mcollective configuration, triggered by Nailgun agent.
  + Quite simple
  - Not "cross-distro"
  - Not consistent with the remaining configuration tasks (rewriting them
worsens the problem above)

3. Use Puppet to configure Mcollective. (copy necessary input data into the
chroot env and run puppet inside it)
  + Using puppet is consistent with the way Fuel configures things
  - It is not consistent with remaining configuration tasks, which is done
via Cloud-init and moving them to Puppet takes some time.

4. Some other tool?

New options, cons and pros are very welcome!

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

Re: [openstack-dev] [Kuryr] Need help in jenkins failure

2016-08-11 Thread Liping Mao (limao)

Hi Vikas,

Not sure , but is it because this line?
https://github.com/vikaschoudhary16/kuryr/blob/drop_libnet_specific_code/ku
ryr/lib/config.py#L105

Thanks.



Regards,
Liping Mao 


From:  Vikas Choudhary 
Date:  2016年8月12日 星期五 下午12:32
To:  OpenStack List , Irena Berezovsky
, Antoni Segura Puimedon
, Gal Sagie , Mohammad
Banikazemi , Liping Mao 
Subject:  [Kuryr] Need help in jenkins failure


Hello Everybody,


I am not able to reproduce jenkins failure (tox -e py27) on this,[1] ,
patch when trying locally. I have tried "recheck" also. There is something
wrong which i am not able to catch. I have spent a good effort on
analysing this but no clue.



Will appreciate if anybody try this patch locally and provide some input
on how can i fix this?



Regards

Vikas Choudhary

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

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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-11 Thread Andreas Jaeger

On 08/12/2016 04:25 AM, Robert Collins wrote:
> On 11 Aug 2016 3:13 PM, "Ben Swartzlander"  > wrote:
>>
>> ...
>>
>> I still don't agree with this stance. Code doesn't just magically stop
> working. Code breaks when things change which aren't version controlled
> properly or when you have undeclared dependencies.
> 
> Well this is why the constraints work was and is being done. It's not
> 100%rolled out as far as I know though, and stable branch support feels
> all the gaps.

As announced yesterday:

Constraints work is *now* 100 % rolled out from the infra side, it's up
to projects to use it fully now,

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


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

[openstack-dev] What's Up, Doc? 12 August

2016-08-11 Thread Lana Brindley

Hi everyone,

I have been struck down with flu yet again this week, so a quiet one from me 
(I'll be glad when winter is over, let me tell you!). Anne, however, has been 
kicking it out of the park with her work on the API docs; I suggest you take a 
look at the update she sent to the mailing lists the other day to catch up: 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101380.html

== Progress towards Newton ==

54 days to go!

Bugs closed so far: 365

Newton deliverables: 
https://wiki.openstack.org/wiki/Documentation/NewtonDeliverables
Feel free to add more detail and cross things off as they are achieved 
throughout the release.

== Speciality Team Reports ==

'''HA Guide: Andrew Beekhof'''
No report this week.

'''Install Tutorials: Lana Brindley'''
Next meeting: 16 August 0600UTC

'''Networking Guide: Edgar Magana'''
No report this week.

'''Security Guide: Nathaniel Dillon'''
Bug hunt continued, all contributions are welcome, grammatical and technical 
alike! Focusing on the last half of the SecurityGuide, and the 'freshness' of 
code examples
Threat analysis documentation and templates added

'''User Guides: Joseph Robinson'''
The Consistency and Editing patch is ready to merge, and just needs more 
reviews https://review.openstack.org/#/c/347641/ .
Some pages in the User Guides are resulting in 404s (dashboard manage shares 
for example), and this bug is tracking the changes 
https://bugs.launchpad.net/openstack-manuals/+bug/1611792
Thanks to Maria for taking on the file name changes to the User Guide, and Anne 
for also patching the Admin Guide file names!

'''Ops Guide: Shilla Saebi, Darren Chan'''
Working on storage, networking, and compute sections in the Arch Guide. 
Arch Guide working group proposed a series of short sprints, working in pairs 
as SME/writer. Dates TBD
Waiting on enterprise ops documentation to migrate to the Ops Guide.

'''API Guide: Anne Gentle'''
Ceilometer migrated content has landed! \o/ https://review.openstack.org/334028 
Many thanks to Khushbu Parakh for sticking with it, and to Julien Danjou and 
Gordon Chung for accepting the (rather outdated) migrated content and taking 
responsiblity for it from now on.
Working on a template for http-status.yaml file that teams can use for new 
pretty HTTP Status code tables that just landed last week. 
https://review.openstack.org/#/c/351835/
Ever closer to landing the API reference navigation. 
https://review.openstack.org/#/c/329508/ 
Refer to status report on -dev and -docs mailing lists: 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101380.html

'''Config/CLI Ref: Tomoyuki Kato'''
Closed a few bugs with mitaka backport.

'''Training labs: Pranav Salunke, Roger Luethi'''
No report this week.

'''Training Guides: Matjaz Pancur'''
Updating Upstream training for the next OpenStack Summit 
(https://etherpad.openstack.org/p/upstream-university-improvements)
Next meeting: Monday 15 August 1700 UTC in #openstack-meeting 

'''Hypervisor Tuning Guide: Blair Bethwaite
No report this week.

'''UX/UI Guidelines: Michael Tullis, Rodrigo Caballero'''
No report this week.

== Site Stats ==

This week, 385 visitors came to the docs site from Stack Overflow, 423 visitors 
came via searching on duckduckgo, and 508 came from ask.openstack.org.

== Doc team meeting ==

Next meetings:

The APAC meeting failed to make quorum this week, but thanks to Darren for 
trying anyway :)

Next meetings:
US: Wednesday 17 August, 19:00 UTC
APAC: Wednesday 24 August, 00:30 UTC

Please go ahead and add any agenda items to the meeting page here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#12_August_2016
-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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] [Kuryr] Need help in jenkins failure

2016-08-11 Thread Vikas Choudhary

Hello Everybody,

I am not able to reproduce jenkins failure (tox -e py27) on this,[1] ,
patch when trying locally. I have tried "recheck" also. There is something
wrong which i am not able to catch. I have spent a good effort on analysing
this but no clue.

Will appreciate if anybody try this patch locally and provide some input on
how can i fix this?


Regards
Vikas Choudhary

[1] https://review.openstack.org/#/c/350406/
__
OpenStack Development Mailing 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][Higgins] Proposing Sudipta Biswas and Wenzhi Yu for Zun core reviewer team

2016-08-11 Thread Yanyan Hu

+1 for both, welcome, Sudipta and Wenzhi :)

2016-08-11 13:55 GMT+08:00 Kumari, Madhuri :

> +1 from me for both.
>
>
>
> *From:* Hongbin Lu [mailto:hongbin...@gmail.com]
> *Sent:* Wednesday, August 10, 2016 8:40 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [Zun][Higgins] Proposing Sudipta Biswas and
> Wenzhi Yu for Zun core reviewer team
>
>
>
> Hi all,
>
>
>
> Both Sudipta and Wenzhi have been actively contributing to the Zun project
> for a while. Sudipta provided helpful advice for the project roadmap and
> architecture design. Wenzhi consistently contributed high quality patches
> and insightful reviews. I think both of them are qualified to join the core
> team.
>
>
>
> I am happy to propose Sudipta and Wenzhi to be core reviewers of Zun team.
> 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, Sudipta and Wenzhi are not able to join the core team and needs to
> wait 30 days to reapply.
>
>
>
> The voting is open until Wednesday August 17st.
>
>
>
> [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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-11 Thread Robert Collins

On 11 Aug 2016 3:13 PM, "Ben Swartzlander"  wrote:
>
> ...
>
> I still don't agree with this stance. Code doesn't just magically stop
working. Code breaks when things change which aren't version controlled
properly or when you have undeclared dependencies.

Well this is why the constraints work was and is being done. It's not
100%rolled out as far as I know though, and stable branch support feels all
the gaps.
__
OpenStack Development Mailing 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] os-capabilities library created

2016-08-11 Thread Jay Pipes


On 08/11/2016 05:50 PM, John Dickinson wrote:

On 3 Aug 2016, at 16:47, Jay Pipes wrote:

Hi Novas and anyone interested in how to represent capabilities in
a consistent fashion.

I spent an hour creating a new os-capabilities Python library this
evening:

http://github.com/jaypipes/os-capabilities

Please see the README for examples of how the library works and how
I'm thinking of structuring these capability strings and symbols. I
intend os-capabilities to be the place where the OpenStack
community catalogs and collates standardized features for hardware,
devices, networks, storage, hypervisors, etc.

Let me know what you think about the structure of the library and
whether you would be interested in owning additions to the library
of constants in your area of expertise.

Next steps for the library include:

* Bringing in other top-level namespaces like disk: or net: and
working with contributors to fill in the capability strings and
symbols. * Adding constraints functionality to the library. For
instance, building in information to the os-capabilities interface
that would allow a set of capabilities to be cross-checked for set
violations. As an example, a resource provider having DISK_GB
inventory cannot have *both* the disk:ssd *and* the disk:hdd
capability strings associated with it -- clearly the disk storage
is either SSD or spinning disk.

Anyway, lemme know your initial thoughts please.


Is this intended to be a cross-project thing? The message is tagged
"[nova]", so I'm kinda surprised I saw it,


Sorry about that, John. I've been focused on Nova usage at first, but 
for sure I'd like the library to contain cross-project, standardized 
string constants for various compute, storage, hardware, network, 
device, etc capabilities. It's literally just an hour of work and 
totally just spitballing ideas right now, so please don't see it as 
intentionally trying to exclude anyone.


> but the library seems to

be called openstack capabilities. So if this is going to be a big
thing for everyone, please update the ML subject tag (and help me
understand how it applies to more than just nova). And if it's just
for nova (err... "compute"), then naming it something that doesn't
imply every project will need to use it could help prevent future
misunderstanding.


As Ed mentioned, this library comes from use cases in the broken-out 
scheduler component (the placement API/engine) that we've been working 
on in Nova this release. Once the scheduler is broken out and being used 
by Nova for quantitative request matching, we will move on to supporting 
the qualitative side of the request -- and that's where the capabilities 
library comes into play. We are aiming to get this part of the placement 
API done in Ocata and I was just getting a head start.


Best,
-jay

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

Re: [openstack-dev] [requirements] near term gate optimization opportunity

2016-08-11 Thread Tony Breeds

On Thu, Aug 11, 2016 at 08:59:04PM -0400, Sean Dague wrote:
> That seems like a further optimization. Honestly, I would rarely expect
> these to be in merge conflict, and at worse, they would be so until the next
> requirements push.

Cool, we'll try to make it so.

Yours Tony.


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

Re: [openstack-dev] [nova] os-capabilities library created

2016-08-11 Thread Jay Pipes


On 08/11/2016 05:25 PM, Ed Leafe wrote:

On Aug 3, 2016, at 6:47 PM, Jay Pipes  wrote:


Please see the README for examples of how the library works and how I'm 
thinking of structuring these capability strings and symbols. I intend 
os-capabilities to be the place where the OpenStack community catalogs and 
collates standardized features for hardware, devices, networks, storage, 
hypervisors, etc.


Overall this looks good, although it seems a bit odd to have ALL_CAPS_STRINGS 
to represent all:caps:strings throughout.


ALL_CAPS is generally used for constant symbols in many (most?) 
programming languages, AFAIK.



The example you gave:


print os_caps.HW_CPU_X86_SSE42

hw:cpu:x86:sse42

begs the question: is the rule going to be that capability for any constant 
will always be: CONST.lower().replace(“_”, “:”) ? If so, I’m not sure I see how 
the capabilities are not themselves constants.


Because you can make a typo with a string and it can go unnoticed. A 
typo in a constant means the code won't compile/import because of an 
unknown symbol.


That's the reason for having these strings represented as constant 
symbols in a shared library.



The namespacing is ugly, but I guess it’s necessary given that names are not 
simple tags, but nested data structures in string form.


Yeah, it's ugly-ish. I'm certainly open to suggestions for how to better 
nest/represent these groups of capability constants.


Best,
-jay

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

Re: [openstack-dev] [nova] os-capabilities library created

2016-08-11 Thread Jay Pipes


On 08/11/2016 05:46 PM, Clay Gerrard wrote:

On Thu, Aug 11, 2016 at 2:25 PM, Ed Leafe > wrote:


Overall this looks good, although it seems a bit odd to have
ALL_CAPS_STRINGS to represent all:caps:strings throughout. The
example you gave:

>>> print os_caps.HW_CPU_X86_SSE42
hw:cpu:x86:sse42


Just to be clear, this project doesn't *do* anything right?  Like it
won't parse `/proc/cpuinfo` and actually figure out a machines cpu flags
that can then be broadcast as "capabilities"?

Like, TBH I think it took me longer than I would prefer to honestly
admit to find out about /sys/block//queue/rotational [1]

So if there was a library about standardizing how hardware capabilities
are discovered and reported - that maybe seems like a sane sort of thing
for a collection of related projects to agree on.  But I'm not sure if
this does that?


Hi Clay!

It does not currently do that, but I'm interested in adding this 
capability (pun intended).


Best,
-jay

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

Re: [openstack-dev] [requirements] near term gate optimization opportunity

2016-08-11 Thread Sean Dague

On 08/11/2016 07:56 PM, Tony Breeds wrote:

On Thu, Aug 11, 2016 at 09:13:12AM +0200, Andreas Jaeger wrote:

On 2016-08-10 23:06, Sean Dague wrote:

Based on reading some logs, it looks like requirements updates are
getting regenerated on every requirements land for all open patches,
even if they aren't impacted by it -
https://review.openstack.org/#/c/351991/

patch 10,11,12 in that series are just rebases, all happening within a
couple of hours.

With the check queue at ... 505 changes as of this email, this is
definitely adding some extra load to the system.

It would be a great optimization for someone to look at the script -
https://github.com/openstack-infra/project-config/blob/ab89ab40ed74db306ce10e36341d39f23231f012/jenkins/scripts/propose_update.sh
and make it so that if the commit did not change, don't push a rebased
review.

Good idea!

One thing to keep in mind: You want to rebase if there's a merge conflict...

What about adding a check and only rebasing if and only if the chnage in
question has a -1 from Jenkins?

That'd mean that in-flight reviews don't get rebased but we *do* rebase if
we're in merge conflict.

The downside to this is we'll be doing *more* gerrit queries but that's
probably ok.

That seems like a further optimization. Honestly, I would rarely expect
these to be in merge conflict, and at worse, they would be so until the
next requirements push.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][elections] Requirements PTL Results

2016-08-11 Thread Tony Breeds

On Thu, Aug 11, 2016 at 09:33:29AM -0400, Anita Kuno wrote:
> We'd like to thank all those folks who came out to participate in this
> election on very brief notice. Thank you. The participation rate is
> impressive.
> 
> Thank you to all candidates who put themselves forward, showing their
> enthusiasm for the role. It is plain to see this new team has a lot of
> leadership available to it as it moves forward. Congratulations Requirements
> team.
> 
> Please join me in welcoming your new Requirements PTL, Tony Breeds (tonyb).

Thanks to Matthew Thode (prometheanfire) and Swapnil Kulkarni (coolsvap).  I
think the requirements team is in a good place!

I'd also like to thank Anita and Doug for running the election!

And of course thanks to everyone that voted!  We got close to 50% turnout which
certainly indicates that people care about how requirements are managed.

Yours Tony.

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

Re: [openstack-dev] [nova] os-capabilities library created

2016-08-11 Thread Tripp, Travis S

Excerpts from Jay Pipes's message of 2016-08-03 19:47:37 -0400:
>>  Hi Novas and anyone interested in how to represent capabilities in a 
>>  consistent fashion.
>>
>>  I spent an hour creating a new os-capabilities Python library this 
evening:
> 
>>  http://github.com/jaypipes/os-capabilities
>> Anyway, lemme know your initial thoughts please.

   On 8/11/16, 3:52 PM, "Clint Byrum"  wrote:

> Did we ever resolve the similarities between this and Searchlight's
> similar goals of providing consistent metadata to the users?

> http://docs.openstack.org/developer/glance/metadefs-concepts.html

> I understand your library is for operators and developers to
> collaborate, but it seems like there should be some alignment with this
> UI that wants to do the same thing for the end user where appropriate.

The metadefs catalog wasn’t written just as a UI construct, it was actually
a derivative of an effort called graffiti [0] that was entirely about
capability and requirement matching and providing a way for portability
across clouds.

The Graffiti project was proposed at the Atlanta (Juno) OpenStack summit.
Since then quite a bit of the concepts have been adopted and are covered as
part of multiple different OpenStack Projects. 

[0] https://wiki.openstack.org/wiki/Graffiti/Architecture

A key concept is to both support defining standard metadata that can
be attached to various resources as well as providing a common service
for deployers to register their own metadata with visibility restrictions.
This can be anything from “Gold, Silver, Bronze” to “some hardware
capability”. Ultimately it is up to the deployer to activate, publish,
or discover the capabilities in their environment and enable them in the 
catalog.

Glance Metadata Definition Catalog (Box 1 in the workflow diagram)
 * http://docs.openstack.org/developer/glance/metadefs-concepts.html
* https://github.com/openstack/glance/tree/master/etc/metadefs
* https://youtu.be/zJpHXdBOoeM

Horizon features (Box 2 in the diagram – but also CLI)
* An admin UI for managing the catalog
* (Admin —> Metadata Definitions) (Kilo)
* A widget for associating metadata to different resources
* (Update Metadata action on each row item below)
* admin -> images (Juno)
* admin -> flavors (Kilo)
* admin —> Host Aggregates (Kilo)
* project —> images (Liberty)
* project —> instances (Mitaka)
* The ability to add metadata at launch time
* project —> Launch Instance (ng launch instance enabled) (Mitaka)

Searchlight (Box 3 in the workflow diagram)
* http://launchpad.net/searchlight
* https://wiki.openstack.org/wiki/Searchlight

The Searchlight project is primarily intended for high performance
searching across the cloud. Fulfilling the concepts of Graffiti is a side
effect, but did provide some of the original inspiration for the project.
We actually have blueprint we will do in “O” that will provide
data mapping from metadefs to the schemas in ElasticSearch [1].

* [1] 
https://blueprints.launchpad.net/searchlight/+spec/configurable-dynamic-properties

In addition, when this popped up in my mailbox today, a search revealed
This message from last August with a few points that I’d like to help clarify 
below:

On 8/10/15, 8:05 AM, "Jay Pipes"  wrote:

>  The Glance metadefs stuff is problematic in a number of ways:

> 1) It wasn't written with Nova in mind at all, but rather for UI needs.
> This means it introduces a bunch of constants that are different from
> the constants in Nova.

This is actually not the case. This was originally co-sponsored by Intel
to help expose out all the CPU capabilities in Nova. The constants in
the metadef catalog all come from combing through the code in Nova
was a complete maze and were not available at the time from
Nova (or cinder or glance or …) See overview here [2]:

 [2] https://wiki.openstack.org/wiki/Graffiti

> 2) It uses a custom JSON format instead of JSONSchema, so we now need to
> figure out the schema for these metadef documents and keep up to date
> with that schema as it changes.

It uses JSON schema, but surrounds it with a very lightweight envelope.
The envelope is called a namespace and is simply a container of JSON
schema, allowing us to manage it as a programmatic unit and as a way
for cloud deployers to share the capabilities across clouds very easily.

We did place a limitation on it that it cannot support nested objects. This
was primarily due to the extreme difficulty of representing that construct
to users in an easy to understand way:

http://docs.openstack.org/developer/glance/metadefs-concepts.html#catalog-terminology

> 3) It mixes qualitative things -- CPU model, features, etc -- with
> quantitative things -- amount of cores, threads, etc. These two things
> are precisely what we are trying to decouple from each other in the next
> generation of Nova's "flavors".
>
> 4) It is still missing the user-facing

Re: [openstack-dev] [requirements] near term gate optimization opportunity

2016-08-11 Thread Tony Breeds

On Thu, Aug 11, 2016 at 09:13:12AM +0200, Andreas Jaeger wrote:
> On 2016-08-10 23:06, Sean Dague wrote:
> > Based on reading some logs, it looks like requirements updates are
> > getting regenerated on every requirements land for all open patches,
> > even if they aren't impacted by it -
> > https://review.openstack.org/#/c/351991/
> > 
> > patch 10,11,12 in that series are just rebases, all happening within a
> > couple of hours.
> > 
> > With the check queue at ... 505 changes as of this email, this is
> > definitely adding some extra load to the system.
> > 
> > It would be a great optimization for someone to look at the script -
> > https://github.com/openstack-infra/project-config/blob/ab89ab40ed74db306ce10e36341d39f23231f012/jenkins/scripts/propose_update.sh
> > and make it so that if the commit did not change, don't push a rebased
> > review.
> 
> Good idea!
> 
> One thing to keep in mind: You want to rebase if there's a merge conflict...

What about adding a check and only rebasing if and only if the chnage in
question has a -1 from Jenkins?

That'd mean that in-flight reviews don't get rebased but we *do* rebase if
we're in merge conflict.

The downside to this is we'll be doing *more* gerrit queries but that's
probably ok.

Yours Tony.


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

Re: [openstack-dev] [nova] Possible REST API design change for get-me-a-network (2.37)

2016-08-11 Thread Andrew Laski



On Thu, Aug 11, 2016, at 06:54 PM, Chris Friesen wrote:
> On 08/11/2016 03:53 PM, Matt Riedemann wrote:
> > I wanted to bring this up for awareness since we're getting close to feature
> > freeze and want consensus before it gets too late.
> >
> > Ken'ichi brought up a good question on my REST API change for the 2.37
> > microversion:
> >
> > https://review.openstack.org/#/c/316398/
> >
> > The way I had written this was to just add special auto/none values for the
> > networks 'uuid' field in the server create request schema.
> >
> > The catch with using auto/none is that they can't be specified with any 
> > other
> > values, like other networks, or a port, or really anything else. It's just a
> > list with a single entry and that's either uuid=auto or uuid=none.
> >
> > Ken'ichi's point was, why not just make "networks" in this case map to 
> > 'auto' or
> > 'none' or the list that exists today.
> >
> > I like the idea, it's cleaner and it probably allows moving some of the
> > validation from the REST API code into the json schema (I think, not totally
> > sure about that yet).
> >
> > It is a change for how networks are requested today so there would be some
> > conditional logic change pushed on the client - my tempest test change and
> > novaclient changes would have to be updated for sure.
> >
> > So I'm looking for input on that idea before we get too late, is that 
> > difference
> > worth the work and syntax change in how the client requests a network when
> > creating a server?
> 
> I like the idea...having magic values for 'uuid' that aren't actually
> uuids and 
> magically don't work with other parameters is sort of gross.

+1. It's cleaner and better represents what's being requested IMO.

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

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

Re: [openstack-dev] [magnum] ssh and http connection lost

2016-08-11 Thread Ton Ngo

Hi Yasemin,
It sounds like your environment has some special networking
customization.  The docker0 bridge is used
to connect the containers and should have no effect on your network
connectivity.  In the Swarm bay, it shows up
on all the VM's.  On your devstack, it should not be there unless you have
installed Docker on your devstack
server.  Even then, it should not cause connectivity problem.
   For more help, you may want to use the IRC channel
#openstack-containers.
Ton Ngo,



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

Date:   08/11/2016 10:52 AM
Subject:Re: [openstack-dev] [magnum] ssh and http connection lost



Hi
I want to use docker swarm bay. i must be configure because of our network
system configuration, docker bridge broken my ssh connection.
  On Aug 11, 2016, at 4:53 PM, Ton Ngo  wrote:



  Hi Yasemin,
  How would you like to configure the networking? Which COE are you
  using?
  You may want to consult the Networking section in the user guide:
  
https://github.com/openstack/magnum/blob/master/doc/source/userguide.rst#networking


  Ton Ngo,

  Yasemin DEMİRAL (BİLGEM BTE) ---08/11/2016 03:39:24
  AM---docker0 bridge is 172.24.. network, it is default. What can i
  configure network settings ? - Or

  From: Yasemin DEMİRAL (BİLGEM BTE) 
  To: "OpenStack Development Mailing List (not for usage questions)" <
  openstack-dev@lists.openstack.org>
  Date: 08/11/2016 03:39 AM
  Subject: Re: [openstack-dev] [magnum] ssh and http connection lost






  docker0 bridge is 172.24.. network, it is default. What can i
  configure network settings ?


  Kimden: "taget" 
  Kime: openstack-dev@lists.openstack.org
  Gönderilenler: 11 Ağustos Perşembe 2016 11:26:07
  Konu: Re: [openstack-dev] [magnum] ssh and http connection lost

  Seems there's no relationship with Magnum service at all, you may
  need to fix figure out why you can not access your test machine.

  As for as I know, bay-create won't block your network access.

  - Eli.

  On 2016年08月11日 16:13, Yasemin DEMİRAL (BİLGEM BTE) wrote:

  Hi

  I installed magnum on devstack successfully. I tired the
  "magnum bay-create --name k8sbay --baymodel k8sbaymodel
  --node-count 1 " command in the guide .
  but in i lost my ssh connection for my test machine and
  http connection for horizon. what can i do ? i can not
  connect to terminal screen my test machine ?

  Can you help me?

  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

  --
  Best Regards,
  Eli Qiao (乔立勇), Intel OTC.

  __

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

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



  __

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


__
OpenStack Development Mailing 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] Possible REST API design change for get-me-a-network (2.37)

2016-08-11 Thread Chris Friesen


On 08/11/2016 03:53 PM, Matt Riedemann wrote:

I wanted to bring this up for awareness since we're getting close to feature
freeze and want consensus before it gets too late.

Ken'ichi brought up a good question on my REST API change for the 2.37
microversion:

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

The way I had written this was to just add special auto/none values for the
networks 'uuid' field in the server create request schema.

The catch with using auto/none is that they can't be specified with any other
values, like other networks, or a port, or really anything else. It's just a
list with a single entry and that's either uuid=auto or uuid=none.

Ken'ichi's point was, why not just make "networks" in this case map to 'auto' or
'none' or the list that exists today.

I like the idea, it's cleaner and it probably allows moving some of the
validation from the REST API code into the json schema (I think, not totally
sure about that yet).

It is a change for how networks are requested today so there would be some
conditional logic change pushed on the client - my tempest test change and
novaclient changes would have to be updated for sure.

So I'm looking for input on that idea before we get too late, is that difference
worth the work and syntax change in how the client requests a network when
creating a server?


I like the idea...having magic values for 'uuid' that aren't actually uuids and 
magically don't work with other parameters is sort of gross.


Chris


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

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-11 Thread Chris Friesen

On 08/11/2016 04:13 PM, Ben Swartzlander wrote:

On 08/10/2016 01:57 PM, Matthew Treinish wrote:

On Wed, Aug 10, 2016 at 09:52:55AM -0700, Clay Gerrard wrote:

On Wed, Aug 10, 2016 at 7:42 AM, Ben Swartzlander
wrote:

A big source of problems IMO is that tempest doesn't have stable branches.
We use the master branch of tempest to test stable branches of other
projects, and tempest regularly adds new features.

How come not this +1000 just fix this?

Well, mostly because it's actually not a problem and ignores the history on why
tempest is branchless. We actually used to do this pre-icehouse and it actually
made things much worse. What was happening back then was we didn't have enough
activity to keep the stable branches working at all. So we'd go very long
periods where nothing actually could land. We also often wedged ourselves where
master tempest changed to a point where we couldn't sanely backport a fix to
the stable branch. This would often mean that up until right before a stable
release things just couldn't land until someone was actually motivated to try
and dig us out. But, what more often happened was we had to just disable tempest
on the branch, because we didn't have another option. It also turns out that
having different tests across a release boundary meant we weren't actually
validating that the OpenStack APIs were consistent and worked the same. We had
many instances where a projects API just changed between release boundaries,
which violates our API consistency and backwards compatibility guidelines.
Tempest is about verifying the API and just like an other API client it should
work against any OpenStack release.

Doing this has been a huge benefit for making things actually work on the stable
branches. (in fact just thinking back about how broken everything was all the
time back then makes me appreciate it even more) We also test every incoming
tempest change on all the stable branches, and nothing can land unless it works
on all supported branches. It means we have a consistent and stable api across
releases. We do have occasional bugs where a new test or change in tempest
triggers a new race in a project's stable branch. But, that's a real bug and
normally a fix can be backported.(which is the whole point of doing stable
branches) If it can't and the race is bad enough to actively interfere with
things, we have a mechanism to skip the test. (but that's normally a last
resort) Although, these issues tend to come up pretty infrequently in practice,
especially as we slowly ramp up the stability of things over time.

FWIW, a lot of these details are covered in the original spec for implementing
this: (although it's definitely assumes a bit of prior knowledge about the
state of things going on when it was written)

http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/branchless-tempest.html

I still don't agree with this stance. Code doesn't just magically stop working.
Code breaks when things change which aren't version controlled properly or when
you have undeclared dependencies.

Or testcases breaks when you change the timing of your tests, which exposes
latent bugs that were always there but by fluke weren't being hit.

In this case the code was previously broken, we just weren't hitting it in the
testcases.

Chris

Re: [openstack-dev] [nova] os-capabilities library created

2016-08-11 Thread Ed Leafe

On Aug 11, 2016, at 5:29 PM, John Dickinson  wrote:

>> I will let Jay speak for himself (as if I could somehow prevent that!), but 
>> the intent here is that this won’t be for Nova specifically; it is targeted 
>> primarily for the forthcoming placement service (you might know it as the 
>> scheduler). The goal is to have a standard way of representing *qualitative* 
>> aspects of resources. So while we are not actively trying to make this a 
>> placement engine for all OpenStack services yet, the goal is to not be 
>> Nova-specific, so that once we have this up and running, we can offer it as 
>> a general placement service for any other project that has such needs.
> 
> Sounds great! How can I get involved with the new general purpose placement 
> scheduler engine and share Swift's requirements?

The main work being done now is on moving Nova from hard-coded CPU, disk, etc., 
to use Resource Provider classes instead. You can see the current work at 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/generic-resource-pools

You can also join the scheduler subteam meeting Mondays at 1400 UTC in 
@openstack-meeting-alt, where we discuss our current efforts. If you have a 
specific question or topic to bring up, add it to the meeting agenda at 
https://wiki.openstack.org/wiki/Meetings/NovaScheduler.

-- Ed Leafe

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

Re: [openstack-dev] [nova] os-capabilities library created

2016-08-11 Thread John Dickinson



On 11 Aug 2016, at 15:14, Ed Leafe wrote:

> On Aug 11, 2016, at 4:50 PM, John Dickinson  wrote:
>
>> Is this intended to be a cross-project thing? The message is tagged 
>> "[nova]", so I'm kinda surprised I saw it, but the library seems to be 
>> called openstack capabilities. So if this is going to be a big thing for 
>> everyone, please update the ML subject tag (and help me understand how it 
>> applies to more than just nova). And if it's just for nova (err... 
>> "compute"), then naming it something that doesn't imply every project will 
>> need to use it could help prevent future misunderstanding.
>
> I will let Jay speak for himself (as if I could somehow prevent that!), but 
> the intent here is that this won’t be for Nova specifically; it is targeted 
> primarily for the forthcoming placement service (you might know it as the 
> scheduler). The goal is to have a standard way of representing *qualitative* 
> aspects of resources. So while we are not actively trying to make this a 
> placement engine for all OpenStack services yet, the goal is to not be 
> Nova-specific, so that once we have this up and running, we can offer it as a 
> general placement service for any other project that has such needs.


Sounds great! How can I get involved with the new general purpose placement 
scheduler engine and share Swift's requirements?

--john



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] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-11 Thread Ben Swartzlander

On 08/10/2016 01:57 PM, Matthew Treinish wrote:

On Wed, Aug 10, 2016 at 09:52:55AM -0700, Clay Gerrard wrote:

On Wed, Aug 10, 2016 at 7:42 AM, Ben Swartzlander
wrote:

A big source of problems IMO is that tempest doesn't have stable branches.
We use the master branch of tempest to test stable branches of other
projects, and tempest regularly adds new features.

How come not this +1000 just fix this?

FWIW, a lot of these details are covered in the original spec for implementing
this: (although it's definitely assumes a bit of prior knowledge about the
state of things going on when it was written)

http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/branchless-tempest.html

I still don't agree with this stance. Code doesn't just magically stop
working. Code breaks when things change which aren't version controlled
properly or when you have undeclared dependencies.

Yes, managing dependencies and doing version control is a lot of work. I
understand that the tempest team is strapped for resources. However
simply declaring that the solution is to stop doing version control is
an epic failure. I read the spec above and it sounds like cry for help
rather than a well thought out idea.

Personally I would be interested in helping improve this situation, but
I think the proper way to improve it is to actually do version control
of everything that matters and use dependency management. If you do this
correctly, then maintaining the old stuff stops being a chore because it
never breaks. By definition, if a stable branch breaks without a change
going into it, you failed at doing dependency management.

I'm not sure how I even could help with the current situation. It feels
like we've dug ourselves into a hole and the plan of record is to get
used to living underground. Does anyone have a will to make thing better
and get to a place where stable branches could reasonably expected to
remain stable for months or years without constant fixing?

-Ben Swartzlander

-Matt Treinish

Re: [openstack-dev] [nova] Possible REST API design change for get-me-a-network (2.37)

2016-08-11 Thread Ken'ichi Ohmichi

2016-08-11 14:53 GMT-07:00 Matt Riedemann :
> I wanted to bring this up for awareness since we're getting close to feature
> freeze and want consensus before it gets too late.
>
> Ken'ichi brought up a good question on my REST API change for the 2.37
> microversion:
>
> https://review.openstack.org/#/c/316398/
>
> The way I had written this was to just add special auto/none values for the
> networks 'uuid' field in the server create request schema.
>
> The catch with using auto/none is that they can't be specified with any
> other values, like other networks, or a port, or really anything else. It's
> just a list with a single entry and that's either uuid=auto or uuid=none.
>
> Ken'ichi's point was, why not just make "networks" in this case map to
> 'auto' or 'none' or the list that exists today.
>
> I like the idea, it's cleaner and it probably allows moving some of the
> validation from the REST API code into the json schema (I think, not totally
> sure about that yet).

Yeah, that also is a nice point.
Current json-schema [1] shows "uuid" parameter accepts not only
uuid-format string but also 'auto' and 'none'.
That seems fair from the naming.

> It is a change for how networks are requested today so there would be some
> conditional logic change pushed on the client - my tempest test change and
> novaclient changes would have to be updated for sure.

You have already work so much for this feature and client
implementation including Tempest.
Sorry for pointing this out lately, but after implementing, it is more
harder to change.
It is nice to avoid more microversions if we can.

Thanks
Ken Omichi

---
[1]: 
https://review.openstack.org/#/c/316398/35/nova/api/openstack/compute/schemas/servers.py


> So I'm looking for input on that idea before we get too late, is that
> difference worth the work and syntax change in how the client requests a
> network when creating a server?
> __
> OpenStack Development Mailing 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] os-capabilities library created

2016-08-11 Thread Ed Leafe

On Aug 11, 2016, at 4:50 PM, John Dickinson  wrote:

> Is this intended to be a cross-project thing? The message is tagged "[nova]", 
> so I'm kinda surprised I saw it, but the library seems to be called openstack 
> capabilities. So if this is going to be a big thing for everyone, please 
> update the ML subject tag (and help me understand how it applies to more than 
> just nova). And if it's just for nova (err... "compute"), then naming it 
> something that doesn't imply every project will need to use it could help 
> prevent future misunderstanding.

I will let Jay speak for himself (as if I could somehow prevent that!), but the 
intent here is that this won’t be for Nova specifically; it is targeted 
primarily for the forthcoming placement service (you might know it as the 
scheduler). The goal is to have a standard way of representing *qualitative* 
aspects of resources. So while we are not actively trying to make this a 
placement engine for all OpenStack services yet, the goal is to not be 
Nova-specific, so that once we have this up and running, we can offer it as a 
general placement service for any other project that has such needs.

-- Ed Leafe

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

Re: [openstack-dev] [all] versioning the api-ref?

2016-08-11 Thread John Dickinson



On 11 Aug 2016, at 15:02, Brian Rosmaita wrote:

> I have a question about the api-ref. Right now, for example, the new
> images v1/v2 api-refs are accurate for Mitaka.  But DocImpact bugs are
> being generated as we speak for changes in master that won't be
> available to consumers until Newton is released (unless they build from
> source). If those bug fixes get merged, then the api-ref will no longer
> be accurate for Mitaka API consumers (since it's published upon update).
>
> My question is, how should we handle this? We want the api-ref to be
> accurate for users, but we also want to move quickly on updates (so that
> the updates actually get made in a timely fashion).
>
> My suggestion is that we should always have an api-ref available that
> reflects the stable releases, that is, one for each stable branch.  So
> right now, for instance, the default api-ref page would display the
> api-ref for Mitaka, with links to "older" (Liberty) and "development"
> (master).  But excellent as that suggestion is, it doesn't help right
> now, because the most accurate Mitaka api-ref for Glance, for instance,
> is in Glance master as part of the WADL to RST migration project.  What
> I'd like to do is publish a frozen version of that somewhere as we make
> the Newton updates along with the Newton code changes.
>
> Thus I guess I have two questions:
>
> (1) How should we version (and publish multiple versions of) the api-ref
> in general?
>
> (2) How do we do it right now?
>
> thanks,
> brian
>

I was working with the oslosphinx project to try and solve this issue in a 
cross-project way for the dev docs. I think the ideas there could be useful 
here.

Basically, if you have docs built every commit (instead of every release, like 
normally happens with library projects), you can set show_other_versions to 
True and get a sidebar link of versions based on tags. (Yeah, I know it wasn't 
working earlier, but that should be fixed now).

So with this process, keep building docs per commit so you have the latest 
available. But turn on the sidebar links for other versions, and you can have a 
place for docs from the last few releases in your project. I'm not sure that it 
would work well for stable branches that are updated (but really, if you're 
updating stable, how "stable" is it?)


--John




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


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] [all] versioning the api-ref?

2016-08-11 Thread Brian Rosmaita

I have a question about the api-ref. Right now, for example, the new
images v1/v2 api-refs are accurate for Mitaka.  But DocImpact bugs are
being generated as we speak for changes in master that won't be
available to consumers until Newton is released (unless they build from
source). If those bug fixes get merged, then the api-ref will no longer
be accurate for Mitaka API consumers (since it's published upon update).

My question is, how should we handle this? We want the api-ref to be
accurate for users, but we also want to move quickly on updates (so that
the updates actually get made in a timely fashion).

My suggestion is that we should always have an api-ref available that
reflects the stable releases, that is, one for each stable branch.  So
right now, for instance, the default api-ref page would display the
api-ref for Mitaka, with links to "older" (Liberty) and "development"
(master).  But excellent as that suggestion is, it doesn't help right
now, because the most accurate Mitaka api-ref for Glance, for instance,
is in Glance master as part of the WADL to RST migration project.  What
I'd like to do is publish a frozen version of that somewhere as we make
the Newton updates along with the Newton code changes.

Thus I guess I have two questions:

(1) How should we version (and publish multiple versions of) the api-ref
in general?

(2) How do we do it right now?

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

2016-08-11 Thread John Dickinson

On 10 Aug 2016, at 8:29, Doug Hellmann wrote:

> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
>> One of the outcomes of the discussion at the leadership training
>> session earlier this year was the idea that the TC should set some
>> community-wide goals for accomplishing specific technical tasks to
>> get the projects synced up and moving in the same direction.
>>
>> After several drafts via etherpad and input from other TC and SWG
>> members, I've prepared the change for the governance repo [1] and
>> am ready to open this discussion up to the broader community. Please
>> read through the patch carefully, especially the "goals/index.rst"
>> document which tries to lay out the expectations for what makes a
>> good goal for this purpose and for how teams are meant to approach
>> working on these goals.
>>
>> I've also prepared two patches proposing specific goals for Ocata
>> [2][3].  I've tried to keep these suggested goals for the first
>> iteration limited to "finish what we've started" type items, so
>> they are small and straightforward enough to be able to be completed.
>> That will let us experiment with the process of managing goals this
>> time around, and set us up for discussions that may need to happen
>> at the Ocata summit about implementation.
>>
>> For future cycles, we can iterate on making the goals "harder", and
>> collecting suggestions for goals from the community during the forum
>> discussions that will happen at summits starting in Boston.
>>
>> Doug
>>
>> [1] https://review.openstack.org/349068 describe a process for managing 
>> community-wide goals
>> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
>> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo 
>> libraries"
>>
>
> The proposal was discussed at the TC meeting yesterday [4], and
> left open to give more time to comment. I've added all of the PTLs
> for big tent projects as reviewers on the process patch [1] to
> encourage comments from them.
>
> Please also look at the associated patches with the specific goals
> for this cycle (python 3.5 support and cleaning up Oslo incubated
> code).  So far most of the discussion has focused on the process,
> but we need folks to think about the specific things they're going
> to be asked to do during Ocata as well.
>
> Doug
>
> [4] 
> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.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

Commonality in goals and vision is what unites any community. I
definitely support the TC's effort to define these goals for OpenStack
and to champion them. However, I have a few concerns about the process
that has been proposed.

I'm concerned with the mandate that all projects must prioritize these
goals above all other work. Thinking about this from the perspective of
the employers of OpenStack contributors, and I'm finding it difficult
to imagine them (particularly smaller ones) getting behind this
prioritization mandate. For example, if I've got a user or deployer
issue that requires an upstream change, am I to prioritize Py35
compatibility over "broken in production"? Am I now to schedule my own
work on known bugs or missing features only after these goals have
been met? Is that what I should ask other community members to do too?

I agree with Hongbin Lu's comments that the resulting goals might fit
into the interests of the majority but fundamentally violate the
interests of a minority of project teams. As an example, should the TC
decide that a future goal is for projects to implement a particular
API-WG document, that may be good for several projects, but it might
not be possible or advisable for others.

I know the TC has no malicious intent here, and I do support the idea
of having cross-project goals. The first goals proposed seem like
great goals.  And I understand the significant challenges of
coordinating goals between a multitude of different projects. However,
I haven't yet added my own +1 to the proposed goals because the
current process means that I am committing that every Swift project
team contributor is now to prioritize that work above all else, no
matter what is happening to their customers, their products, or their
communities.

--John

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] [nova] Possible REST API design change for get-me-a-network (2.37)

2016-08-11 Thread Matt Riedemann

I wanted to bring this up for awareness since we're getting close to 
feature freeze and want consensus before it gets too late.


Ken'ichi brought up a good question on my REST API change for the 2.37 
microversion:


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

The way I had written this was to just add special auto/none values for 
the networks 'uuid' field in the server create request schema.


The catch with using auto/none is that they can't be specified with any 
other values, like other networks, or a port, or really anything else. 
It's just a list with a single entry and that's either uuid=auto or 
uuid=none.


Ken'ichi's point was, why not just make "networks" in this case map to 
'auto' or 'none' or the list that exists today.


I like the idea, it's cleaner and it probably allows moving some of the 
validation from the REST API code into the json schema (I think, not 
totally sure about that yet).


It is a change for how networks are requested today so there would be 
some conditional logic change pushed on the client - my tempest test 
change and novaclient changes would have to be updated for sure.


So I'm looking for input on that idea before we get too late, is that 
difference worth the work and syntax change in how the client requests a 
network when creating a server?


--

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] os-capabilities library created

2016-08-11 Thread Clint Byrum

Excerpts from Jay Pipes's message of 2016-08-03 19:47:37 -0400:
> Hi Novas and anyone interested in how to represent capabilities in a 
> consistent fashion.
> 
> I spent an hour creating a new os-capabilities Python library this evening:
> 
> http://github.com/jaypipes/os-capabilities
> 
> Please see the README for examples of how the library works and how I'm 
> thinking of structuring these capability strings and symbols. I intend 
> os-capabilities to be the place where the OpenStack community catalogs 
> and collates standardized features for hardware, devices, networks, 
> storage, hypervisors, etc.
> 
> Let me know what you think about the structure of the library and 
> whether you would be interested in owning additions to the library of 
> constants in your area of expertise.
> 
> Next steps for the library include:
> 
> * Bringing in other top-level namespaces like disk: or net: and working 
> with contributors to fill in the capability strings and symbols.
> * Adding constraints functionality to the library. For instance, 
> building in information to the os-capabilities interface that would 
> allow a set of capabilities to be cross-checked for set violations. As 
> an example, a resource provider having DISK_GB inventory cannot have 
> *both* the disk:ssd *and* the disk:hdd capability strings associated 
> with it -- clearly the disk storage is either SSD or spinning disk.
> 
> Anyway, lemme know your initial thoughts please.

Did we ever resolve the similarities between this and Searchlight's
similar goals of providing consistent metadata to the users?

http://docs.openstack.org/developer/glance/metadefs-concepts.html

I understand your library is for operators and developers to
collaborate, but it seems like there should be some alignment with this
UI that wants to do the same thing for the end user where appropriate.

__
OpenStack Development Mailing 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] os-capabilities library created

2016-08-11 Thread John Dickinson



On 3 Aug 2016, at 16:47, Jay Pipes wrote:

> Hi Novas and anyone interested in how to represent capabilities in a 
> consistent fashion.
>
> I spent an hour creating a new os-capabilities Python library this evening:
>
> http://github.com/jaypipes/os-capabilities
>
> Please see the README for examples of how the library works and how I'm 
> thinking of structuring these capability strings and symbols. I intend 
> os-capabilities to be the place where the OpenStack community catalogs and 
> collates standardized features for hardware, devices, networks, storage, 
> hypervisors, etc.
>
> Let me know what you think about the structure of the library and whether you 
> would be interested in owning additions to the library of constants in your 
> area of expertise.
>
> Next steps for the library include:
>
> * Bringing in other top-level namespaces like disk: or net: and working with 
> contributors to fill in the capability strings and symbols.
> * Adding constraints functionality to the library. For instance, building in 
> information to the os-capabilities interface that would allow a set of 
> capabilities to be cross-checked for set violations. As an example, a 
> resource provider having DISK_GB inventory cannot have *both* the disk:ssd 
> *and* the disk:hdd capability strings associated with it -- clearly the disk 
> storage is either SSD or spinning disk.
>
> Anyway, lemme know your initial thoughts please.

Is this intended to be a cross-project thing? The message is tagged "[nova]", 
so I'm kinda surprised I saw it, but the library seems to be called openstack 
capabilities. So if this is going to be a big thing for everyone, please update 
the ML subject tag (and help me understand how it applies to more than just 
nova). And if it's just for nova (err... "compute"), then naming it something 
that doesn't imply every project will need to use it could help prevent future 
misunderstanding.

--john


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


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] [nova] os-capabilities library created

2016-08-11 Thread Clay Gerrard

On Thu, Aug 11, 2016 at 2:25 PM, Ed Leafe  wrote:

>
> Overall this looks good, although it seems a bit odd to have
> ALL_CAPS_STRINGS to represent all:caps:strings throughout. The example you
> gave:
>
> >>> print os_caps.HW_CPU_X86_SSE42
> hw:cpu:x86:sse42
>
>
Just to be clear, this project doesn't *do* anything right?  Like it won't
parse `/proc/cpuinfo` and actually figure out a machines cpu flags that can
then be broadcast as "capabilities"?

Like, TBH I think it took me longer than I would prefer to honestly admit
to find out about /sys/block//queue/rotational [1]

So if there was a library about standardizing how hardware capabilities are
discovered and reported - that maybe seems like a sane sort of thing for a
collection of related projects to agree on.  But I'm not sure if this does
that?

-Clay

1. https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
__
OpenStack Development Mailing 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] os-capabilities library created

2016-08-11 Thread Ed Leafe

On Aug 3, 2016, at 6:47 PM, Jay Pipes  wrote:

> Please see the README for examples of how the library works and how I'm 
> thinking of structuring these capability strings and symbols. I intend 
> os-capabilities to be the place where the OpenStack community catalogs and 
> collates standardized features for hardware, devices, networks, storage, 
> hypervisors, etc.

Overall this looks good, although it seems a bit odd to have ALL_CAPS_STRINGS 
to represent all:caps:strings throughout. The example you gave:

>>> print os_caps.HW_CPU_X86_SSE42
hw:cpu:x86:sse42

begs the question: is the rule going to be that capability for any constant 
will always be: CONST.lower().replace(“_”, “:”) ? If so, I’m not sure I see how 
the capabilities are not themselves constants.

The namespacing is ugly, but I guess it’s necessary given that names are not 
simple tags, but nested data structures in string form.

-- Ed Leafe

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

Re: [openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

2016-08-11 Thread Carl Baldwin

The Neutron L3 meeting will be canceled. We will still hold the routed
networks meeting on Tuesday.

Carl

On Thu, Aug 11, 2016 at 12:19 PM, Henry Gessau  wrote:

> Armando M.  wrote:
> > Hi Neutrinos,
> >
> > The meetings will be cancelled due to the mid-cycle.
>
> The neutron-lib meeting will also skip next week.
>
>
> __
> OpenStack Development Mailing 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] proposal: start gating on puppet4

2016-08-11 Thread Emilien Macchi

On Tue, Aug 9, 2016 at 1:39 PM, Emilien Macchi  wrote:
> Hi,
>
> Today Puppet OpenStack CI is running unit and functional test jobs
> against puppet 3 and puppet 4.
> Unit jobs for puppet 4 are currently voting and pretty stable.
> Functional jobs for puppet 4 are not voting but also stable.
>
> Even if Puppet4 has not been largely adopted by our community [1] yet,
> I would like to encourage our users to upgrade the version of Puppet.
> Fedora ships it by default [2] and for Ubuntu, it's also the default
> since yakkety [3].
>
> [1] 
> https://docs.google.com/spreadsheets/d/1iIQ6YmpdOVctS2-wCV6SGPP1NSj8nKD9nv_xtZH9loY/edit?usp=sharing
> [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=3529
> [3] http://packages.ubuntu.com/yakkety/puppet
>
> So here's my proposal, feel free to bring any feedback:
> - For stable/mitaka CI and stable/liberty nothing will change.
> - For current master (future stable/newton in a few months), transform
> non-voting puppet4 jobs into voting and add them to the gate. Also
> keep puppet3 unit tests jobs, as voting.

I have noticed this change ^ is going to consume a lot more CI jobs
and I'm not sure we want it.

> - After Newton release (during Ocata cycle), change master CI to only
> gate functional jobs on puppet4 (and remove puppet3 jobs for
> puppet-openstack-integration); but keep puppet3 unit tests jobs, as
> voting.
> - During Ocata cycle, implement a periodic job that will nightly check
> we can deploy with Puppet3. The periodic job is something our
> community interested by Puppet 3 will have to monitor and report any
> new failure so we can address it.

That's something we could even do now if nobody is against, to save CI
resources.
So we would have puppet4 jobs voting from newton and beyond, but
puppet3 jobs only in periodic pipeline...

Moving forward is a good thing but we need to continue to test puppet3
for newton, otherwise the message is too rigid for our users imho.

I'll try to find a middleground between what we want without consuming
too much resources.

> That way, we tell our users:
> - don't worry if you deploy Liberty, Mitaka, Newton, we will
> officially support Puppet 3.
> - if you plan to deploy Puppet 4, we'll officially support you
> starting from Newton.
> - if you plan to deploy Ocata with Puppet 3, we won't support you
> anymore since our functional testing jobs will be gone. Though we'll
> make our best to be backward compatible thanks to our unit  and
> periodic functional testing jobs.
>
> Regarding packaging:
> - on Ubuntu, we'll continue rely on what provides Puppetlabs because
> Xenial doesn't provide Puppet4.
> - on CentOS7, we are working on getting Puppet 4 packaged in RDO and
> our CI will certainly use it.
>
> Any feedback is welcome,
> --
> Emilien Macchi



-- 
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] [release] Release countdown for week R-7, 15-19 Aug

2016-08-11 Thread Doug Hellmann

Focus
-

Major feature work should be well under way as we approach the third
milestone.

General Notes
-

Prepare for the non-client library freeze coming up on 25 Aug. by
finishing any feature work that requires library changes.

We freeze releases of all libraries between the third milestone and
the final release to give downstream packagers time to vet the
libraries. Only emergency bug fix updates are allowed during that
period, not releases for FFEs.

Release Actions
---

None

Important Dates
---

Library release freeze date starting R-6, Aug 25.

Newton 3 milestone, Sept 1

Newton release schedule: http://releases.openstack.org/newton/schedule.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

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-11 Thread Amrith Kumar


> -Original Message-
> From: John Dickinson [mailto:m...@not.mn]
> Sent: Thursday, August 11, 2016 2:09 PM
> To: OpenStack Development Mailing List 
> Subject: Re: [openstack-dev] [all][infra] Constraints are ready to be used
> for tox.ini
> 
> 
> 
> On 11 Aug 2016, at 10:03, Andreas Jaeger wrote:
> 
> > TL;DR: upper-constraints can be used now for all tox based jobs
> >
> > With any software package, you will need additional packages to run it.
> > Often, there's a tight coupling: The software package will only run with
> > specific other package versions. This dependency information is
> > sometimes found in README files, in code, or in package metadata. If you
> > install the package, you need to figure out the dependency and
> > handle it properly.
> >
> > The Python package installer pip uses a list of requirements to install
> > dependent Python packages. This list not only contains the name of
> > packages but also limits which versions to use, or not to use.
> > In OpenStack we handle these dependencies in a global requirements list
> > and use it for most of the repositories. During initial testing a
> > specific package version is tested but at a later point, another one
> > might be used, or during deployment again another one.
> >
> > To document what was tested, give guidenance for deployment, and help to
> > figure out breakage by upstream projects, the OpenStack requirements
> > projects maintains a set of constraints with packages pinned to specific
> > package versions that are known to be working.
> > These are in the upper-constraints.txt file.
> >
> > Devstack already handles upper-constraints.txt when installing packages
> > and I'm happy to say that tox, the Python testing framework used in
> > OpenStack, can now handle upper-constraints as well everywhere.
> >
> >
> > Constraints for tox based jobs
> > ==
> > To use constraints, change in tox.ini the install command to:
> >
> > install_command = pip install
> > -
> c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requ
> irements/plain/upper-constraints.txt}
> > {opts} {packages}
> 
> I've proposed a patch to Swift to do this:
> 
> https://review.openstack.org/#/c/354291/
> 
> I'd appreciate any advice on it.

[amrith] Ditto for Trove, I've proposed

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

> 
> 
> >
> > Caveat
> > ==
> >
> > Note that constraints are used for the installation of each packages, so
> > if you want to install a package from source and have constraints for a
> > specific version in the constraints file, it will not work. This happens
> > with some of  the OpenStack python client packages: When they install
> > their dependencies, those might have a dependency on the client package
> > itself. And this then will cause an error since the client package
> > should get installed from source.
> >
> > So, projects need to remove the constraints file for themselves if they
> > run into this. Packages like python-novaclient and python-glanceclient
> > therefore use a wrapper (tools/tox_install.sh) as
> > install command to edit the constraints file first and remove their own
> > project from it.
> >
> > Also, be aware that this only for those jobs that have been enabled for
> > it in the project-config repository. It's done for all the generic tox
> > enabled targets and should be done for all custom tox targets as well.
> > Some repositories are not using constraints like project-config
> > itself, so those jobs are not set up.
> >
> > Constraints for DevStack jobs
> > =
> > Devstack-gate takes care using constraints, there is nothing for a
> > repository to do to honor constraints.
> >
> > Check the devstacklog.txt file, if constraints are in use it will use
> > lines like:
> >
> > Collecting oslo.context===2.7.0 (from -c
> > /opt/stack/new/requirements/upper-constraints.txt (line 204))
> >
> > References
> > ==
> >
> > http://docs.openstack.org/developer/requirements/
> > https://specs.openstack.org/openstack/openstack-
> specs/specs/requirements-management.html
> >
> >
> > Thanks
> > ==
> > As usual in OpenStack, such work is a team work of many people. I'd like
> > to thank especially:
> >
> > *Robert Collins 'lifeless': For writing the initial spec, implementation
> > work, and giving guideance on many of these details.
> > * Sean Dague: He was bold enough to try using constraints everywhere and
> > showing us where it failed.
> > * Sachi King for making zuul-cloner usable in the post queue. This was a
> > missing part in the last months.
> > * The OpenStack infra team for many reviews and design discussions -
> > especially to Jeremy Stanley and Jim Blair.
> >
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-11 Thread Jeremy Stanley

On 2016-08-11 20:19:51 +0200 (+0200), Ihar Hrachyshka wrote:
> Do I read it right that we can now use constraints for post queue too
> (releasenotes, cover, venv targets)?

Yes, that was the hardest part to get working, but thanks to
tireless efforts on the part of a number of people that has now been
fixed and tested.
-- 
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] [Tripleo] Tripleo HA Federation Proof-of-Concept

2016-08-11 Thread Emilien Macchi

Nice work Adam, as usual.

I'm dropping some comments about how we could automate it in TripleO:

# Identity Provider Registration and Metadata
This script could be called by Puppet or Heat at the right time, but
now I don't have the best answer.

# Federation Operations
We can achieve it with puppet-keystone thanks to Sofer's awesome work:
https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_identity_provider/openstack.rb

# Dashboard
We need to expose new parameters to puppet-horizon and consume them in
THT horizon service.

# Redirect Support for SAML
We can easily do it in puppet-tripleo re-using current bits for haproxy config.

# Federation Mapping
Gilles started that a long time ago: https://review.openstack.org/#/c/202409/
We'll need to finish it.
Other actions can be handled by puppet-keystone.

# deploy-env.yml
Please submit the missing keystone.conf parameters into puppet-keystone.

Conclusion: I think we can achieve almost (if not all) everything in
TripleO and Puppet modules without crazy pain.
Please create launchpads bugs for every piece, it will help PTLs
(Puppet + TripleO) to prioritize/task the work that needs to be done.

HTH

On Thu, Aug 11, 2016 at 2:20 PM, Adam Young  wrote:
>  http://adam.younglogic.com/2016/08/ooo-ha-fed-poc/
>
>
> It is painful, sloppy, Mitaka based.  Have at it, and lets make Federation a
> reality for Newton based deployments.  Feedback eagerly sought.
>
> Thanks for all the people that helped get me through this.  Won't list you
> all, as it would start to sound like an Oscars acceptance speech.
>
>
> __
> OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Telles Nobrega

Thanks Vitaly and everyone else.

On Thu, Aug 11, 2016 at 3:22 PM, Vitaly Gridnev 
wrote:

> Since it's was discussed at meeting, and there is no objections, welcome!
>
> On Thu, Aug 11, 2016 at 9:15 PM, Trevor McKay  wrote:
>
>> +2
>>
>> On Fri, 2016-08-12 at 00:56 +0800, lu jander wrote:
>> > +2 from me thx Telles
>> >
>> > 2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak
>> > :
>> > +2 from me
>> >
>> > 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov
>> > :
>> > +2
>> >
>> > On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford
>> >  wrote:
>> > Hearty +2. Telles has been working on Sahara
>> > for years, and has been a consistent and
>> > incisive reviewer and code contributor.
>> >
>> >
>> > Congratulations Telles; very well deserved!
>> >
>> >
>> > - Elise
>> >
>> >
>> > On Thu, Aug 11, 2016 at 11:37 AM, Vitaly
>> > Gridnev  wrote:
>> >
>> > Hello core team,
>> >
>> >
>> > I'd like to nominate Telles Mota Vidal
>> > Nóbrega for core reviewer team. Let's
>> > vote with +2/-2 for his candidacy.
>> > Review/Commits stats can be found at
>> > [0].
>> >
>> >
>> > [0] http://stackalytics.com/?modul
>> e=sahara-group_id=tellesmvn
>> >
>> > --
>> > Best Regards,
>> >
>> > Vitaly Gridnev,
>> > Project Technical Lead of OpenStack
>> > DataProcessing Program (Sahara)
>> > Mirantis, Inc
>> >
>> >
>> > _
>> _
>> > OpenStack Development Mailing List
>> > (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request@lists.o
>> penstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cg
>> i-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > _
>> _
>> > OpenStack Development Mailing List (not for
>> > usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request@lists.o
>> penstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cg
>> i-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Sincerely yours,
>> > Sergey Lukjanov
>> > Sr. Development Manager
>> > Mirantis Inc.
>> >
>> > _
>> _
>> > OpenStack Development Mailing List (not for usage
>> > questions)
>> > Unsubscribe:
>> > OpenStack-dev-request@lists.o
>> penstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cg
>> i-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/opensta
>> ck-dev
>> >
>> >
>> >
>> > 
>> __
>> > 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
>>
>>
>>
>> 
>> __
>> 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
>>
>
>
>
> --
> Best Regards,
> Vitaly Gridnev,
> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
> Mirantis, Inc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

2016-08-11 Thread Ihar Hrachyshka


Henry Gessau  wrote:


Armando M.  wrote:

Hi Neutrinos,

The meetings will be cancelled due to the mid-cycle.


The neutron-lib meeting will also skip next week.



…and neutron upgrades meeting is NOT going to be skipped.

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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Telles Nobrega

Thank you all!!!

On Thu, Aug 11, 2016 at 3:15 PM, Trevor McKay  wrote:

> +2
>
> On Fri, 2016-08-12 at 00:56 +0800, lu jander wrote:
> > +2 from me thx Telles
> >
> > 2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak
> > :
> > +2 from me
> >
> > 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov
> > :
> > +2
> >
> > On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford
> >  wrote:
> > Hearty +2. Telles has been working on Sahara
> > for years, and has been a consistent and
> > incisive reviewer and code contributor.
> >
> >
> > Congratulations Telles; very well deserved!
> >
> >
> > - Elise
> >
> >
> > On Thu, Aug 11, 2016 at 11:37 AM, Vitaly
> > Gridnev  wrote:
> >
> > Hello core team,
> >
> >
> > I'd like to nominate Telles Mota Vidal
> > Nóbrega for core reviewer team. Let's
> > vote with +2/-2 for his candidacy.
> > Review/Commits stats can be found at
> > [0].
> >
> >
> > [0] http://stackalytics.com/?
> module=sahara-group_id=tellesmvn
> >
> > --
> > Best Regards,
> >
> > Vitaly Gridnev,
> > Project Technical Lead of OpenStack
> > DataProcessing Program (Sahara)
> > Mirantis, Inc
> >
> >
> > __
> 
> > OpenStack Development Mailing List
> > (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request@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-request@lists.
> openstack.org?subject:unsubscribe
> > http://lists.openstack.org/
> cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sr. Development Manager
> > Mirantis Inc.
> >
> > __
> 
> > OpenStack Development Mailing List (not for usage
> > questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
[image: Red Hat] 
Telles Nobrega | Software Engineer
Red Hat Brasil
T: +55 11 3529-6000 | M: +55 11 9 9910-1689
Av. Brigadeiro Faria Lima 3900, 8° Andar. São Paulo, Brasil.
RED HAT | TRIED. TESTED. TRUSTED. Saiba porque em redhat.com

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

Re: [openstack-dev] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Chad Roberts

Absolutely +2.  Telles has been a proven contributor for quite some time
now.  Thanks for all the work, Telles!

On Thu, Aug 11, 2016 at 2:15 PM, Trevor McKay  wrote:

> +2
>
> On Fri, 2016-08-12 at 00:56 +0800, lu jander wrote:
> > +2 from me thx Telles
> >
> > 2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak
> > :
> > +2 from me
> >
> > 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov
> > :
> > +2
> >
> > On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford
> >  wrote:
> > Hearty +2. Telles has been working on Sahara
> > for years, and has been a consistent and
> > incisive reviewer and code contributor.
> >
> >
> > Congratulations Telles; very well deserved!
> >
> >
> > - Elise
> >
> >
> > On Thu, Aug 11, 2016 at 11:37 AM, Vitaly
> > Gridnev  wrote:
> >
> > Hello core team,
> >
> >
> > I'd like to nominate Telles Mota Vidal
> > Nóbrega for core reviewer team. Let's
> > vote with +2/-2 for his candidacy.
> > Review/Commits stats can be found at
> > [0].
> >
> >
> > [0] http://stackalytics.com/?
> module=sahara-group_id=tellesmvn
> >
> > --
> > Best Regards,
> >
> > Vitaly Gridnev,
> > Project Technical Lead of OpenStack
> > DataProcessing Program (Sahara)
> > Mirantis, Inc
> >
> >
> > __
> 
> > OpenStack Development Mailing List
> > (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request@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-request@lists.
> openstack.org?subject:unsubscribe
> > http://lists.openstack.org/
> cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sr. Development Manager
> > Mirantis Inc.
> >
> > __
> 
> > OpenStack Development Mailing List (not for usage
> > questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Vitaly Gridnev

Since it's was discussed at meeting, and there is no objections, welcome!

On Thu, Aug 11, 2016 at 9:15 PM, Trevor McKay  wrote:

> +2
>
> On Fri, 2016-08-12 at 00:56 +0800, lu jander wrote:
> > +2 from me thx Telles
> >
> > 2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak
> > :
> > +2 from me
> >
> > 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov
> > :
> > +2
> >
> > On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford
> >  wrote:
> > Hearty +2. Telles has been working on Sahara
> > for years, and has been a consistent and
> > incisive reviewer and code contributor.
> >
> >
> > Congratulations Telles; very well deserved!
> >
> >
> > - Elise
> >
> >
> > On Thu, Aug 11, 2016 at 11:37 AM, Vitaly
> > Gridnev  wrote:
> >
> > Hello core team,
> >
> >
> > I'd like to nominate Telles Mota Vidal
> > Nóbrega for core reviewer team. Let's
> > vote with +2/-2 for his candidacy.
> > Review/Commits stats can be found at
> > [0].
> >
> >
> > [0] http://stackalytics.com/?
> module=sahara-group_id=tellesmvn
> >
> > --
> > Best Regards,
> >
> > Vitaly Gridnev,
> > Project Technical Lead of OpenStack
> > DataProcessing Program (Sahara)
> > Mirantis, Inc
> >
> >
> > __
> 
> > OpenStack Development Mailing List
> > (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request@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-request@lists.
> openstack.org?subject:unsubscribe
> > http://lists.openstack.org/
> cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sr. Development Manager
> > Mirantis Inc.
> >
> > __
> 
> > OpenStack Development Mailing List (not for usage
> > questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-11 Thread Ihar Hrachyshka

Do I read it right that we can now use constraints for post queue too  
(releasenotes, cover, venv targets)?


Ihar

Andreas Jaeger  wrote:


TL;DR: upper-constraints can be used now for all tox based jobs

With any software package, you will need additional packages to run it.
Often, there's a tight coupling: The software package will only run with
specific other package versions. This dependency information is
sometimes found in README files, in code, or in package metadata. If you
install the package, you need to figure out the dependency and
handle it properly.

The Python package installer pip uses a list of requirements to install
dependent Python packages. This list not only contains the name of
packages but also limits which versions to use, or not to use.
In OpenStack we handle these dependencies in a global requirements list
and use it for most of the repositories. During initial testing a
specific package version is tested but at a later point, another one
might be used, or during deployment again another one.

To document what was tested, give guidenance for deployment, and help to
figure out breakage by upstream projects, the OpenStack requirements
projects maintains a set of constraints with packages pinned to specific
package versions that are known to be working.
These are in the upper-constraints.txt file.

Devstack already handles upper-constraints.txt when installing packages
and I'm happy to say that tox, the Python testing framework used in
OpenStack, can now handle upper-constraints as well everywhere.


Constraints for tox based jobs
==
To use constraints, change in tox.ini the install command to:

install_command = pip install
-c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
{opts} {packages}

Caveat
==

Note that constraints are used for the installation of each packages, so
if you want to install a package from source and have constraints for a
specific version in the constraints file, it will not work. This happens
with some of  the OpenStack python client packages: When they install
their dependencies, those might have a dependency on the client package
itself. And this then will cause an error since the client package
should get installed from source.

So, projects need to remove the constraints file for themselves if they
run into this. Packages like python-novaclient and python-glanceclient
therefore use a wrapper (tools/tox_install.sh) as
install command to edit the constraints file first and remove their own
project from it.

Also, be aware that this only for those jobs that have been enabled for
it in the project-config repository. It's done for all the generic tox
enabled targets and should be done for all custom tox targets as well.
Some repositories are not using constraints like project-config
itself, so those jobs are not set up.

Constraints for DevStack jobs
=
Devstack-gate takes care using constraints, there is nothing for a
repository to do to honor constraints.

Check the devstacklog.txt file, if constraints are in use it will use
lines like:

Collecting oslo.context===2.7.0 (from -c
/opt/stack/new/requirements/upper-constraints.txt (line 204))

References
==

http://docs.openstack.org/developer/requirements/
https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html


Thanks
==
As usual in OpenStack, such work is a team work of many people. I'd like
to thank especially:

*Robert Collins 'lifeless': For writing the initial spec, implementation
work, and giving guideance on many of these details.
* Sean Dague: He was bold enough to try using constraints everywhere and
showing us where it failed.
* Sachi King for making zuul-cloner usable in the post queue. This was a
missing part in the last months.
* The OpenStack infra team for many reviews and design discussions -
especially to Jeremy Stanley and Jim Blair.

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


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




__
OpenStack Development Mailing 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] Team and Driver meetings for the week of Aug 15th

2016-08-11 Thread Henry Gessau

Armando M.  wrote:
> Hi Neutrinos,
> 
> The meetings will be cancelled due to the mid-cycle.

The neutron-lib meeting will also skip next week.


__
OpenStack Development Mailing 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] Tripleo HA Federation Proof-of-Concept

2016-08-11 Thread Adam Young


 http://adam.younglogic.com/2016/08/ooo-ha-fed-poc/


It is painful, sloppy, Mitaka based.  Have at it, and lets make 
Federation a reality for Newton based deployments.  Feedback eagerly sought.


Thanks for all the people that helped get me through this.  Won't list 
you all, as it would start to sound like an Oscars acceptance speech.



__
OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Trevor McKay

+2

On Fri, 2016-08-12 at 00:56 +0800, lu jander wrote:
> +2 from me thx Telles 
> 
> 2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak
> :
> +2 from me
> 
> 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov
> :
> +2
> 
> On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford
>  wrote:
> Hearty +2. Telles has been working on Sahara
> for years, and has been a consistent and
> incisive reviewer and code contributor.
> 
> 
> Congratulations Telles; very well deserved!
> 
> 
> - Elise
> 
> 
> On Thu, Aug 11, 2016 at 11:37 AM, Vitaly
> Gridnev  wrote:
> 
> Hello core team,
> 
> 
> I'd like to nominate Telles Mota Vidal
> Nóbrega for core reviewer team. Let's
> vote with +2/-2 for his candidacy.
> Review/Commits stats can be found at
> [0].
> 
> 
> [0] 
> http://stackalytics.com/?module=sahara-group_id=tellesmvn
> 
> -- 
> Best Regards,
> 
> Vitaly Gridnev,
> Project Technical Lead of OpenStack
> DataProcessing Program (Sahara)
> Mirantis, Inc
> 
> 
> 
> __
> OpenStack Development Mailing List
> (not for usage questions)
> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for
> usage questions)
> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> -- 
> Sincerely yours,
> Sergey Lukjanov
> Sr. Development Manager
> Mirantis Inc.
> 
> 
> __
> OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-11 Thread John Dickinson



On 11 Aug 2016, at 10:03, Andreas Jaeger wrote:

> TL;DR: upper-constraints can be used now for all tox based jobs
>
> With any software package, you will need additional packages to run it.
> Often, there's a tight coupling: The software package will only run with
> specific other package versions. This dependency information is
> sometimes found in README files, in code, or in package metadata. If you
> install the package, you need to figure out the dependency and
> handle it properly.
>
> The Python package installer pip uses a list of requirements to install
> dependent Python packages. This list not only contains the name of
> packages but also limits which versions to use, or not to use.
> In OpenStack we handle these dependencies in a global requirements list
> and use it for most of the repositories. During initial testing a
> specific package version is tested but at a later point, another one
> might be used, or during deployment again another one.
>
> To document what was tested, give guidenance for deployment, and help to
> figure out breakage by upstream projects, the OpenStack requirements
> projects maintains a set of constraints with packages pinned to specific
> package versions that are known to be working.
> These are in the upper-constraints.txt file.
>
> Devstack already handles upper-constraints.txt when installing packages
> and I'm happy to say that tox, the Python testing framework used in
> OpenStack, can now handle upper-constraints as well everywhere.
>
>
> Constraints for tox based jobs
> ==
> To use constraints, change in tox.ini the install command to:
>
> install_command = pip install
> -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
> {opts} {packages}

I've proposed a patch to Swift to do this:

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

I'd appreciate any advice on it.


>
> Caveat
> ==
>
> Note that constraints are used for the installation of each packages, so
> if you want to install a package from source and have constraints for a
> specific version in the constraints file, it will not work. This happens
> with some of  the OpenStack python client packages: When they install
> their dependencies, those might have a dependency on the client package
> itself. And this then will cause an error since the client package
> should get installed from source.
>
> So, projects need to remove the constraints file for themselves if they
> run into this. Packages like python-novaclient and python-glanceclient
> therefore use a wrapper (tools/tox_install.sh) as
> install command to edit the constraints file first and remove their own
> project from it.
>
> Also, be aware that this only for those jobs that have been enabled for
> it in the project-config repository. It's done for all the generic tox
> enabled targets and should be done for all custom tox targets as well.
> Some repositories are not using constraints like project-config
> itself, so those jobs are not set up.
>
> Constraints for DevStack jobs
> =
> Devstack-gate takes care using constraints, there is nothing for a
> repository to do to honor constraints.
>
> Check the devstacklog.txt file, if constraints are in use it will use
> lines like:
>
> Collecting oslo.context===2.7.0 (from -c
> /opt/stack/new/requirements/upper-constraints.txt (line 204))
>
> References
> ==
>
> http://docs.openstack.org/developer/requirements/
> https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
>
>
> Thanks
> ==
> As usual in OpenStack, such work is a team work of many people. I'd like
> to thank especially:
>
> *Robert Collins 'lifeless': For writing the initial spec, implementation
> work, and giving guideance on many of these details.
> * Sean Dague: He was bold enough to try using constraints everywhere and
> showing us where it failed.
> * Sachi King for making zuul-cloner usable in the post queue. This was a
> missing part in the last months.
> * The OpenStack infra team for many reviews and design discussions -
> especially to Jeremy Stanley and Jim Blair.
>
> -- 
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [magnum] ssh and http connection lost

2016-08-11 Thread yasemin

Hi
I want to use docker swarm bay. i must be configure because of our network 
system configuration, docker bridge broken my ssh connection.  
> On Aug 11, 2016, at 4:53 PM, Ton Ngo  wrote:
> 
> Hi Yasemin,
> How would you like to configure the networking? Which COE are you using? 
> You may want to consult the Networking section in the user guide:
> https://github.com/openstack/magnum/blob/master/doc/source/userguide.rst#networking
>  
> 
> 
> Ton Ngo, 
> 
> Yasemin DEMİRAL (BİLGEM BTE) ---08/11/2016 03:39:24 AM---docker0 
> bridge is 172.24.. network, it is default. What can i configure network 
> settings ? - Or
> 
> From: Yasemin DEMİRAL (BİLGEM BTE) 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 08/11/2016 03:39 AM
> Subject: Re: [openstack-dev] [magnum] ssh and http connection lost
> 
> 
> 
> 
> 
> docker0 bridge is 172.24.. network, it is default. What can i configure 
> network settings ? 
> 
> 
> Kimden: "taget" 
> Kime: openstack-dev@lists.openstack.org
> Gönderilenler: 11 Ağustos Perşembe 2016 11:26:07
> Konu: Re: [openstack-dev] [magnum] ssh and http connection lost
> 
> Seems there's no relationship with Magnum service at all, you may need to fix 
> figure out why you can not access your test machine.
> 
> As for as I know, bay-create won't block your network access.
> 
> - Eli.
> 
> On 2016年08月11日 16:13, Yasemin DEMİRAL (BİLGEM BTE) wrote:
> 
> Hi
> 
> I installed magnum on devstack successfully. I tired the "magnum bay-create 
> --name k8sbay --baymodel k8sbaymodel --node-count 1 " command in the guide  
> .
> but in i lost my ssh connection for my test machine and http connection for 
> horizon. what can i do ? i can not connect to terminal screen my test machine 
> ? 
> 
> Can you help me?
> 
> 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 
> 
> 
> -- 
> Best Regards, 
> Eli Qiao (乔立勇), Intel OTC.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [ironic] Driver composition defaults call

2016-08-11 Thread Julia Kreger

Yesterday as a group (jroll, rloo, dtantsur, matt128, devananda,
vdrok, and myself) discussed defaults for driver composition.

The options we discussed were:

* The existing specification[0] - Global and hardware_type
default_FOO_interface configuration, global enabled_FOO_interfaces in
configs, supported_FOO_interface in the hardware_type.

* Sambetts proposal[1] - To base any defaults on the intersection of
enabled_FOO_interfaces and the supported_FOO_interface lists taking
the first common option.

During the discussion the group came to the conclusion that if we were
to enable the ability to set defaults solely by list ordering, as put
forth in sambetts proposal, the question would then shift to who knows
best. The operator, or the vendor via the hardware_type. This further
evolved into substantial amounts of potential configuration which we
seemed to agree was confusing and unrealistic. We eventually circled
back to the original intent of the global configuration
default_FOO_interface which was to make an operator’s life easier by
allowing the definition of what would by in large be an explicitly
chosen environmental or operating default.

Circling back to the intent allowed us to focus the discussion further
and decide the following:

1. If the client creating the node does not set an explicit
FOO_interface, we must save whatever is determined as the default, in
node.FOO_interface.

2. To determine a default if one is not explicitly set via a
default_FOO_interface, the intersection between the hardware_type
definition supported_FOO_interfaces and the enabled_FOO_interfaces
global configuration would be used to determine the default.

Having determined the two preceding items, we reached a consensus that
the resulting default that is determined, must be present in
enabled_FOO_interfaces list. The result of this is that there should
be no implicit enablement of drivers, and the operator should be
selecting the interfaces possible for their environment in the
enabled_FOO_interfaces global configuration setting.

In following up with sambetts this morning and discussing the concerns
that drove his proposal initially, Sam and I determined that any
implicit enablement of drivers was not ideal, that an operator
explicit default override for its intended purpose seemed okay, and
that the determination of any default should come from the the
intersection of what is supported versus what is enabled, as the
larger group reached a consensus on.  That this would ultimately
result in default_FOO_interface dropping from the hardware_type and
only being present as global configuration option for an operator to
use if they so choose to do so.  This seems in-line with what the
group reached while on the call yesterday.

Conceptually, this leaves us with something that looks like the
following when nodes are created without a valid FOO_interface in the
initial API post.

1. The hardware_type's supported_FOO_interfaces is in order of
preference by the vendor, for example: supported_FOO_interface = [BAR,
CAR, DAR] this represents: if BAR enabled then use BAR else if CAR
enabled then use CAR else if DAR enabled then use DAR.

2. possible_FOO_interfaces to use for a hardware_type are calculated
by intersecting enabled_FOO_interfaces and the hardware_type's
supported_FOO_interfaces, order as in supported_FOO_interface is
maintained.

3. If configuration option default_FOO_interface is set AND
default_FOO_interface is in possible_FOO_interfaces THEN
node.FOO_interface is set to default_FOO_interface

4. If configuration option default_FOO_interface is set AND
default_FOO_interface is NOT in possible_FOO_interfaces THEN node
create fails

5. If configuration option default_FOO_interface is NOT set THEN
node.FOO_interface is set to the first interface in
possible_FOO_interface

Thank you Sam for typing out the above logic.  I think this means we
seem to have some consensus on the direction to move forward, at least
I hope. :)

-Julia

[0] 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099257.html

On Mon, Aug 8, 2016 at 8:51 AM, Julia Kreger
 wrote:
> Thank you for sending the corrected link Mathieu!  I thought I fixed it
> before I sent the email, but... *shrug*
>
> Anyway!  Looking at the doodle, the mutually available time is 4 PM UTC on
> this Wednesday (8/10/16).  If there are no objections, I guess we will hear
> those seeking to discuss defaults on conferencing[0] bridge number  at
> that time.
>
> -Julia
>
> [0] https://wiki.openstack.org/wiki/Infrastructure/Conferencing

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

Re: [openstack-dev] [cinder] [neutron] [ironic] [api] [doc] API status report

2016-08-11 Thread Sean McGinnis

> 
> Sorry, in reviewing further today I found another project that does not
> have a publish job but has in-tree source files:
> 
> cinder
> 
> Team cinder: can you let me know where you are in your publishing comfort
> level? Please add an api-ref-jobs: line with a target of block-storage
> to jenkins/jobs/projects.yaml in the project-config repo to ensure
> publishing is correct.

Thanks Anne. I need to catch up on that one. We had one person looking
into moving things over and they have since stepped away from OpenStack,
at least lately. I'll put it on my todo list to figure out the condition
of what's there, and if I'm comfortable with where things tand I'll get
an api-ref-job added.

Thanks for bringing it to my attention.

Sean

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

[openstack-dev] [all][api] POST /api-wg/news

2016-08-11 Thread Everett Toews

Greetings OpenStack community,

Our main new topic for today was making sure that we take a more active role in 
curating the bugs that are now being kept in launchpad [4] by including review 
of those bugs in the workshopping that we do in each meeting. If you find 
issues in the existing guidelines or think a guideline is missing, make a bug.

The meeting logs are in the usual place. [5]

# New guidelines

* A guideline for links
  https://review.openstack.org/354266

# API guidelines proposed for freeze

The following guidelines are available for broader review by interested 
parties. These will be merged in one week if there is no further feedback.

* Add the beginning of a set of guidlines for URIs
  https://review.openstack.org/#/c/322194/

# Guidelines currently under review

These are guidelines that the working group are debating and working on for 
consistency and language. We encourage any interested parties to join in the 
conversation.

* Clarify backslash usage for 'in' operator
  https://review.openstack.org/#/c/353396/
* Clear the case if the version string isn't parsable
  https://review.openstack.org/#/c/346846/

# API Impact reviews currently open

Reviews marked as APIImpact [1] are meant to help inform the working group 
about changes which would benefit from wider inspection by group members and 
liaisons. While the working group will attempt to address these reviews 
whenever possible, it is highly recommended that interested parties attend the 
API-WG meetings [2] to promote communication surrounding their reviews.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [3].

Thanks for reading and see you next week!

[1] 
https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
[2] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
[3] http://specs.openstack.org/openstack/api-wg/
[4]: https://bugs.launchpad.net/openstack-api-wg
[5]: http://eavesdrop.openstack.org/meetings/api_wg/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-11 Thread Andreas Jaeger

TL;DR: upper-constraints can be used now for all tox based jobs

With any software package, you will need additional packages to run it.
Often, there's a tight coupling: The software package will only run with
specific other package versions. This dependency information is
sometimes found in README files, in code, or in package metadata. If you
install the package, you need to figure out the dependency and
handle it properly.

The Python package installer pip uses a list of requirements to install
dependent Python packages. This list not only contains the name of
packages but also limits which versions to use, or not to use.
In OpenStack we handle these dependencies in a global requirements list
and use it for most of the repositories. During initial testing a
specific package version is tested but at a later point, another one
might be used, or during deployment again another one.

To document what was tested, give guidenance for deployment, and help to
figure out breakage by upstream projects, the OpenStack requirements
projects maintains a set of constraints with packages pinned to specific
package versions that are known to be working.
These are in the upper-constraints.txt file.

Devstack already handles upper-constraints.txt when installing packages
and I'm happy to say that tox, the Python testing framework used in
OpenStack, can now handle upper-constraints as well everywhere.


Constraints for tox based jobs
==
To use constraints, change in tox.ini the install command to:

install_command = pip install
-c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
{opts} {packages}

Caveat
==

Note that constraints are used for the installation of each packages, so
if you want to install a package from source and have constraints for a
specific version in the constraints file, it will not work. This happens
with some of  the OpenStack python client packages: When they install
their dependencies, those might have a dependency on the client package
itself. And this then will cause an error since the client package
should get installed from source.

So, projects need to remove the constraints file for themselves if they
run into this. Packages like python-novaclient and python-glanceclient
therefore use a wrapper (tools/tox_install.sh) as
install command to edit the constraints file first and remove their own
project from it.

Also, be aware that this only for those jobs that have been enabled for
it in the project-config repository. It's done for all the generic tox
enabled targets and should be done for all custom tox targets as well.
Some repositories are not using constraints like project-config
itself, so those jobs are not set up.

Constraints for DevStack jobs
=
Devstack-gate takes care using constraints, there is nothing for a
repository to do to honor constraints.

Check the devstacklog.txt file, if constraints are in use it will use
lines like:

Collecting oslo.context===2.7.0 (from -c
/opt/stack/new/requirements/upper-constraints.txt (line 204))

References
==

http://docs.openstack.org/developer/requirements/
https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html


Thanks
==
As usual in OpenStack, such work is a team work of many people. I'd like
to thank especially:

*Robert Collins 'lifeless': For writing the initial spec, implementation
work, and giving guideance on many of these details.
* Sean Dague: He was bold enough to try using constraints everywhere and
showing us where it failed.
* Sachi King for making zuul-cloner usable in the post queue. This was a
missing part in the last months.
* The OpenStack infra team for many reviews and design discussions -
especially to Jeremy Stanley and Jim Blair.

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


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

Re: [openstack-dev] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread lu jander

+2 from me thx Telles

2016-08-12 0:20 GMT+08:00 Sergey Reshetnyak :

> +2 from me
>
> 2016-08-11 19:15 GMT+03:00 Sergey Lukjanov :
>
>> +2
>>
>> On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford 
>> wrote:
>>
>>> Hearty +2. Telles has been working on Sahara for years, and has been a
>>> consistent and incisive reviewer and code contributor.
>>>
>>> Congratulations Telles; very well deserved!
>>>
>>> - Elise
>>>
>>> On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev 
>>> wrote:
>>>
 Hello core team,

 I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
 Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
 at [0].

 [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn

 --
 Best Regards,
 Vitaly Gridnev,
 Project Technical Lead of OpenStack DataProcessing Program (Sahara)
 Mirantis, Inc

 
 __
 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


>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Sr. Development Manager
>> Mirantis Inc.
>>
>> 
>> __
>> 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] [openstack-operators][Sahara] Deprecation notes for Newton cycle

2016-08-11 Thread Vitaly Gridnev

Hello team,

The aim of this letter is to provide all needed information about features
which were deprecated in Sahara in the Newton release cycle, and several
important notes from the Mitaka release cycle.

1. In Mitaka, all old CLI commands were marked as deprecated. We are not
removing them in the Newton release cycle, but we will remove this CLI in
the beginning of the Ocata release cycle.

Please use the OpenStackClient plugin instead; it has all features included
in the old CLI. Please refer to [0] to track status of this support removal.

2. In Newton, MapR 5.0.0 was marked as deprecated. If there are no
objections, it can be removed in the Ocata release (since this version of
the plugin was not stable). MapR 5.1.0 mrv2 should be used instead.

3. In Newton, CDH 5, CDH 5.3, CDH 5.4  were marked as deprecated. If there
are no objections, it will be removed in the P release. CDH 5.5 and CDH 5.7
should be used instead.

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

-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] The deprecation of proxy API related CLI

2016-08-11 Thread Matt Riedemann


On 8/10/2016 11:01 PM, Alex Xu wrote:

Hi, guys,

We have agreement on how to deprecate the CLI for the proxy APIs which
were deprecated in 2.36 when mid-cycle. But I still feels that we have
something isn't very clear. So I just want to summary the situation at
here, and to be clear the final goal.

Here are the patches https://review.openstack.org/347514
and https://review.openstack.org/#/c/348499

So the agreement is:

When user executes the network related CLI without specific version or
with specific version > 2.35, the CLI will fallback to 2.35 automatically.

For the API part, we won't do any workaround, so that means we will stop
to support those after 2.35, we need add decorator like
this 
https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L917

But the agreement is only talk about network related thing, we also
deprecate image/volume/snapshot/baremetal/fping stuff. So what is the
plan for them? I guess we just no workaround also, stop the support
after 2.35.

So the final status will be as below:

* Network CLI: Auto fallback to 2.35 in the patch
* Quota/Limit CLI: Remove network quotas after 2.35 in the current patch
* Image CLI: Currently the CLI emit the deprecated message in the code,
but it still break in 2.36(get a 404 message). We should stop support it
after 2.35
* Baremetal CLI: Same as Image CLI, there is message, but will break in
2.36. Stop to support it after 2.35


For image and baremetal CLIs, we might need to just cap those at 2.35.


* No Volume/Snapshot/fping related CLI

* Network/Image/Quota/Limit/Baremetal/Volumes/fping API: No workaround.
Stop to support them after 2.35.

Thanks
Alex



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



Another thing I just ran into while testing this, is that novaclient 
itself calls to these proxy APIs, like for validating that the image 
uuid you passed in on boot is available. The CLI does the same for doing 
name translation (you pass a network name, we get the ID and pass that 
to the REST API).


So with 2.36 being the default for the CLI actually breaks the CLI since 
it's using these proxies which now return a 404.


I considered capping the default for the CLI at 2.35 until novaclient 
itself is no longer using the deprecated proxy APIs, but Sean pointed 
out that we then don't have support for the get-me-a-network feature 
(2.37) by default, which sucks.


So I think we're probably going to have to land some changes to move 
novaclient itself off of the nova proxy APIs before we can land the 
support for 2.36 as the default in the CLI.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [kolla] FW: [all][ptl][tc] extra ATCs for newton

2016-08-11 Thread Steven Dake (stdake)

Koalligans,

I can't think of anyone off the top of my head that hasn't submitted a
patch for Newton that would qualify for an ATC pass under the bylaws [1]
and TC Charter [2], but would like to open up nominations from core
reviewers since I am not omnipotent.

The only candidates that even come to mind are the folks in OSIC that
facilitated the usage of the OSIC 131 node cluster for Kolla scale testing
under work in this review:
https://review.openstack.org/#/c/352101/


Please see inside for more details.

Apologies or short deadline, but nominations close August 14th, 2016 - in
time for me to prepare a patch, if one needs to be prepared.

Thanks!
-steve

On 8/10/16, 9:24 AM, "Doug Hellmann"  wrote:

>It's time to make sure we have all of our active technical contributors
>(ATCs) identified for Newton.
>
>Following the Foundation bylaws [1] and TC Charter [2], Project
>teams should identify contributors who have had a significant impact
>this cycle but who would not qualify for ATC status using the regular
>process because they have not submitted a patch.  Contributions
>might include, but aren't limited to, bug triage, design work, and
>documentation -- there is a lot of leeway in how teams define
>contribution for ATC status.
>
>The resulting list of names should be submitted as a patch to the
>"extra-atcs" section in openstack/governance/reference/projects.yaml
>for review by the TC.
>
>Although extra ATCs can be nominated at any point, there is a
>deadline to be included in the electorate for the next release
>cycle. The ATC list needs to be approved by the TC by 25 Aug, and
>in order to appear on the TC agenda to be discussed, the proposals
>need to be submitted by 16 Aug.
>
>PTLs can delegate preparing the patch to the governance repository, but
>please +1 the patch indicating that you agree with the list to avoid
>delays in the TC review.
>
>Thanks,
>Doug
>
>[1] http://www.openstack.org/legal/technical-committee-member-policy/
>[2] 
>http://governance.openstack.org/reference/charter.html#voters-for-tc-seats
>-atc
>
>__
>OpenStack Development Mailing 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][taas]

2016-08-11 Thread Varsha Jayaraj

Hi,

When we create a tap-service, a VLAN ID will be associated with that
tap-service. In case we want to identify the flows associated with that
VLAN ID, so that we can add additional filters, the response returned after
creating a tap-service must include the VLAN ID information as well. Can
this be incorporated?

Thanks.

Regards,
Varsha
__
OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Sergey Reshetnyak

+2 from me

2016-08-11 19:15 GMT+03:00 Sergey Lukjanov :

> +2
>
> On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford 
> wrote:
>
>> Hearty +2. Telles has been working on Sahara for years, and has been a
>> consistent and incisive reviewer and code contributor.
>>
>> Congratulations Telles; very well deserved!
>>
>> - Elise
>>
>> On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev 
>> wrote:
>>
>>> Hello core team,
>>>
>>> I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
>>> Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
>>> at [0].
>>>
>>> [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn
>>>
>>> --
>>> Best Regards,
>>> Vitaly Gridnev,
>>> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
>>> Mirantis, Inc
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sr. Development Manager
> Mirantis Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Sergey Lukjanov

+2

On Thu, Aug 11, 2016 at 8:48 AM, Elise Gafford  wrote:

> Hearty +2. Telles has been working on Sahara for years, and has been a
> consistent and incisive reviewer and code contributor.
>
> Congratulations Telles; very well deserved!
>
> - Elise
>
> On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev 
> wrote:
>
>> Hello core team,
>>
>> I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
>> Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
>> at [0].
>>
>> [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn
>>
>> --
>> Best Regards,
>> Vitaly Gridnev,
>> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
>> Mirantis, Inc
>>
>> 
>> __
>> 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
>
>


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

[openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

2016-08-11 Thread Armando M.

Hi Neutrinos,

The meetings will be cancelled due to the mid-cycle.

Cheers,
Armando
__
OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Elise Gafford

Hearty +2. Telles has been working on Sahara for years, and has been a
consistent and incisive reviewer and code contributor.

Congratulations Telles; very well deserved!

- Elise

On Thu, Aug 11, 2016 at 11:37 AM, Vitaly Gridnev 
wrote:

> Hello core team,
>
> I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
> Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
> at [0].
>
> [0] http://stackalytics.com/?module=sahara-group_id=tellesmvn
>
> --
> Best Regards,
> Vitaly Gridnev,
> Project Technical Lead of OpenStack DataProcessing Program (Sahara)
> Mirantis, Inc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

2016-08-11 Thread Rosensweig, Elisha (Nokia - IL)

This is on purpose. 

When Vitrage is started, it first runs a "consistency" round where it gets all 
the resources from its datasources and inserts them into the entity graph. Once 
this initial phase is over, the evaluator is run over all the entity graph to 
check for meaningful patterns based on it's templates.

The reason for this process is to avoid too much churn during the initial phase 
when Vitrage comes up. With so many changes done to the entity graph, it's best 
to wait for the initial collection phase to finish and then to do the analysis.

Elisha

> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
> Sent: Thursday, August 11, 2016 5:49 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [vitrage] scenario evaluator not enabled by 
> default
>
> Sorry for having put a url from forked repo. It should be 
> https://github.com/openstack/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff>
>  -6f1a277a2f6e9a567b38d646f19728bcL36

> But the content is the same
> --
> Yujun

> On Thu, Aug 11, 2016 at 10:43 PM Yujun Zhang  wrote:
> It seems the scenario evaluator is not enabled when vitrage is started in 
> devstack installer.
>
> I dig a bit in the history, it seems the default value for the evaluator is 
> changed from True to False > in a history commit [1].
>
> Is it breaking the starting of evaluator or I have missed some steps to 
> enable it explictily?
>
> - [1] 
> https://github.com/openzero-zte/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff-
>  6f1a277a2f6e9a567b38d646f19728bcL36

> --
> Yujun
__
OpenStack Development Mailing 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] [sahara] Nominate Telles Mota Vidal Nóbrega for core team

2016-08-11 Thread Vitaly Gridnev

Hello core team,

I'd like to nominate Telles Mota Vidal Nóbrega for core reviewer team.
Let's vote with +2/-2 for his candidacy. Review/Commits stats can be found
at [0].

[0] http://stackalytics.com/?module=sahara-group_id=tellesmvn

-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Feature Classification

2016-08-11 Thread Darek Śmigiel


> On Aug 10, 2016, at 1:21 PM, Armando M.  wrote:
> 
> 
> 
> On 10 August 2016 at 10:20, Gupta, Ankur  > wrote:
> Hello Neutrinos,
> 
>  
> 
> One of the things, that is required to have ease of use, is good 
> documentation.
> 
> Similar to what's done for Nova [4], I've decided to prepare Feature 
> Classification for Neutron.
> 
> Work was already approved, and it got greenlit [1], but we still lack of 
> final approval. In the light of N-3 [5] approaching, it would be nice to have 
> it merged sooner than later.
> 
>  
> 
> What's Feature Matrix Classification?
> 
> The feature classification matrix will provide information about backend 
> plugins and the features they support.
> 
> It acts as a launching point for users to read about the intent of the matrix 
> before reviewing the matrix to find features and plugins that meet their 
> needs.
> 
> This document will allow deployers and operators to figure out which backend 
> plugins will fit their specific use case.
> 
>  
> 
> Framework for documentation is ready [2] and can be merged. It will allow to 
> render final version of Feature Matrix.
> 
> Feature Matrix is also prepared to be merged [3]. It's rough, initial version 
> after several iterations. There are still missing pieces of information, but 
> even though, it's better to have something, where we can start, than nothing.
> 
> 
> Thanks for working on this! I realize that I have not given the attention 
> this deserved, I hope to make it up to you during the mid-cycle.

Great, I’ve added this topic to list of work items for mid-cycle. [1]

[1] https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems 
 #79

> 
> Cheers,
> Armando
>  
> 
>  
> 
>  
> 
> [1] https://launchpad.net/bugs/1580327 
> [2] https://review.openstack.org/#/c/318192/ 
> 
> [3] https://review.openstack.org/#/c/324048/ 
> 
> [4] http://docs.openstack.org/developer/nova/feature_classification.html 
> 
> [5] http://releases.openstack.org/newton/schedule.html 
> 
>  
> 
>  
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing 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] test strategy for the serial console feature

2016-08-11 Thread Daniel P. Berrange

On Thu, Aug 11, 2016 at 04:46:02PM +0200, Markus Zoeller wrote:
> On 11.08.2016 13:31, Daniel P. Berrange wrote:
> > On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote:
> >> On 08/11/2016 05:45 AM, Markus Zoeller wrote:
> >>> On 26.07.2016 12:16, Jordan Pittier wrote:
>  Hi Markus
>  You don"t really need a whole new job for this. Just turn that flag to 
>  True
>  on existing jobs.
> 
>  30/40 seconds is acceptable. But I am surprised considering a VM usually
>  boots in 5 sec or so. Any idea of where that slowdown comes from ?
> 
>  On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller <
>  mzoel...@linux.vnet.ibm.com> wrote:
> >>
> >> We just had a big chat about this in the #openstack-nova IRC channel. To
> >> summarize:
> >>
> >> The class of bugs that are really problematic are:
> >>
> >>  * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252
> >> in OpenStack Compute (nova) "enabling serial console breaks live
> >> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui)
> >>
> >> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962
> >> in OpenStack Compute (nova) "live migration with disabled vnc/spice not
> >> possible" [Undecided,In progress] - Assigned to Markus Zoeller
> >> (markus_z) (mzoeller)
> >>
> >> Which are both in the category of serial console breaking live
> >> migration. It's the serial device vs. live migration that's most
> >> problematic. Serial consoles themselves haven't broken badly recently.
> >> Given that we don't do live migration testing in most normal jobs, the
> >> Tempest jobs aren't really going to help here.
> >>
> >> The dedicated live-migration job is being targeted.
> >>
> >> Serial console support is currently a function at the compute level.
> >> Which is actually a little odd. Because it means that all guests on a
> >> compute must be serial console, or must not. Imagine a compute running
> >> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to
> >> force serial console one way or another on all of those the same way.
> >> This is probably something that makes sense to add as an image
> >> attribute, because images will need guest configuration to support
> >> serial consoles. As an image attribute this would also help on testing
> >> because we could mix / match in a single run.
> > 
> > There is actually image properties for this, but the way it is all
> > implemented right now is just insane.
> 
> You're talking about "hw_serial_port_count" I assume? I'm not aware of
> any other property for that. Sean was talking about enabling the serial
> console per image/flavor property IIUC.

If hw_serial_port_count allowed a value of '0', and we fixed the
problem of the other random serial port with type=pty we create,
then we'd get the full serial console per image support Sean
wants when nova.conf was set to serial_console.enabled=True.

We could also discuss / notify users that we're intending to set
that nova.conf to default to True in a future release, and
then eventually delete the nova.conf setting entirely.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing 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] [infra] Project tailored VM image for Jenkins jobs

2016-08-11 Thread Jeremy Stanley

On 2016-08-11 02:30:07 -0500 (-0500), e...@itsonlyme.name wrote:
[...]
> So it seems the way to go is:
> 1. Upload what we need to e.g.:
> http://tarballs.openstack.org/storlet/images/docker/ubuntu_14.04.tar.gz

Yep, generally you'd have a CI job build and upload that, not
generate it by hand. If this is something that already exists in the
wild on the Internet, then you'd use whatever the actual URL to it
is instead of putting a copy on our tarballs site.

> 2. Add the corresponding IMAGE_URL entry to stackrc
[...]

Correct, as long as you're talking about the stackrc in the
openstack-dev/devstack repo. If this is not something of general
utility for other users of DevStack then its core reviewers may not
go for that option so best to discuss with them.

> The .tar.gz we need is ~65MB, would that be ok?

That's probably in line with the size of other images DevStack
currently uses, though there is the risk that lots of projects want
their own special images cached on disk and at some point we have to
make some hard decisions as to what we can reasonably keep embedding
in our nodepool images.
-- 
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] [nova] test strategy for the serial console feature

2016-08-11 Thread Markus Zoeller

On 11.08.2016 16:46, Markus Zoeller wrote:
> On 11.08.2016 13:31, Daniel P. Berrange wrote:
>> On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote:
>>> On 08/11/2016 05:45 AM, Markus Zoeller wrote:
 On 26.07.2016 12:16, Jordan Pittier wrote:
> Hi Markus
> You don"t really need a whole new job for this. Just turn that flag to 
> True
> on existing jobs.
>
> 30/40 seconds is acceptable. But I am surprised considering a VM usually
> boots in 5 sec or so. Any idea of where that slowdown comes from ?
>
> On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller <
> mzoel...@linux.vnet.ibm.com> wrote:
>>>
>>> We just had a big chat about this in the #openstack-nova IRC channel. To
>>> summarize:
>>>
>>> The class of bugs that are really problematic are:
>>>
>>>  * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252
>>> in OpenStack Compute (nova) "enabling serial console breaks live
>>> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui)
>>>
>>> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962
>>> in OpenStack Compute (nova) "live migration with disabled vnc/spice not
>>> possible" [Undecided,In progress] - Assigned to Markus Zoeller
>>> (markus_z) (mzoeller)
>>>
>>> Which are both in the category of serial console breaking live
>>> migration. It's the serial device vs. live migration that's most
>>> problematic. Serial consoles themselves haven't broken badly recently.
>>> Given that we don't do live migration testing in most normal jobs, the
>>> Tempest jobs aren't really going to help here.
>>>
>>> The dedicated live-migration job is being targeted.
>>>
>>> Serial console support is currently a function at the compute level.
>>> Which is actually a little odd. Because it means that all guests on a
>>> compute must be serial console, or must not. Imagine a compute running
>>> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to
>>> force serial console one way or another on all of those the same way.
>>> This is probably something that makes sense to add as an image
>>> attribute, because images will need guest configuration to support
>>> serial consoles. As an image attribute this would also help on testing
>>> because we could mix / match in a single run.
>>
>> There is actually image properties for this, but the way it is all
>> implemented right now is just insane.
> 
> You're talking about "hw_serial_port_count" I assume? I'm not aware of
> any other property for that. Sean was talking about enabling the serial
> console per image/flavor property IIUC.

Nvm, I understand it now. The crucial point should be this one:

https://github.com/openstack/nova/blob/a059c8453ea3739e45ea1cc56eacc82603a25b0f/nova/virt/libvirt/driver.py#L4101-L4103

in combination with:

https://github.com/openstack/nova/blob/ad0047e97b2847412ee28bad6a3bfb48395add35/nova/virt/hardware.py#L198-L198

> 
>> For QEMU/KVM (on x86) currently, by default you get
>>
>>  - a serial port which is connected to a file
>>  - a serial port which is connected to a pty
>>
>> If you turned on the serial_console option in nova.conf you instead get
>>
>>  - one or more serial ports connected to a tcp port
>>  - a serial port which is connected to a pty
>>
>> The number of serial ports is based off an image property (
>> hw_serial_port_count), but strangely the code doesn't honour a
>> value of 0 for that. In addition the last serial port connected
>> to a pty should really not even exist at that point.
>>
>> We should aim to get to a place where we have 'serial_console.enabled'
>> default to True in nova.conf and hw_serial_port_count setting how many
>> are created, with 0 being a valid number. Never create any other serial
>> ports that were not requested.
>>
>> Regards,
>> Daniel
>>
> 
> Allowing '0' as property value sounds like a good approach.
> 

Let me check with a PoC how this could look like.


-- 
Regards, Markus Zoeller (markus_z)


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

[openstack-dev] [cinder] [neutron] [ironic] [api] [doc] API status report

2016-08-11 Thread Anne Gentle

On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle 
wrote:

> Hi all,
> I wanted to report on status and answer any questions you all have about
> the API reference and guide publishing process.
>
> The expectation is that we provide all OpenStack API information on
> developer.openstack.org. In order to meet that goal, it's simplest for
> now to have all projects use the RST+YAML+openstackdocstheme+os-api-ref
> extension tooling so that users see available OpenStack APIs in a sidebar
> navigation drop-down list.
>
> --Migration--
> The current status for migration is that all WADL content is migrated
> except for trove. There is a patch in progress and I'm in contact with the
> team to assist in any way. https://review.openstack.org/#/c/316381/
>
> --Theme, extension, release requirements--
> The current status for the theme, navigation, and Sphinx extension tooling
> is contained in the latest post from Graham proposing a solution for the
> release number switchover and offers to help teams as needed:
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101112.html
> I hope to meet the requirements deadline to get those changes landed.
> Requirements freeze is Aug 29.
>
> --Project coverage--
> The current status for project coverage is that these projects are now
> using the RST+YAML in-tree workflow and tools and publishing to
> http://developer.openstack.org/api-ref/ so they will be
> included in the upcoming API navigation sidebar intended to span all
> OpenStack APIs:
>
> designate http://developer.openstack.org/api-ref/dns/
> glance http://developer.openstack.org/api-ref/image/
> heat http://developer.openstack.org/api-ref/orchestration/
> ironic http://developer.openstack.org/api-ref/baremetal/
> keystone http://developer.openstack.org/api-ref/identity/
> manila http://developer.openstack.org/api-ref/shared-file-systems/
> neutron-lib http://developer.openstack.org/api-ref/networking/
> nova http://developer.openstack.org/api-ref/compute/
> sahara http://developer.openstack.org/api-ref/data-processing/
> senlin http://developer.openstack.org/api-ref/clustering/
> swift http://developer.openstack.org/api-ref/object-storage/
> zaqar http://developer.openstack.org/api-ref/messaging/
>
> These projects are using the in-tree workflow and common tools, but do not
> have a publish job in project-config in the jenkins/jobs/projects.yaml file.
>
> ceilometer
>

Sorry, in reviewing further today I found another project that does not
have a publish job but has in-tree source files:

cinder

Team cinder: can you let me know where you are in your publishing comfort
level? Please add an api-ref-jobs: line with a target of block-storage
to jenkins/jobs/projects.yaml in the project-config repo to ensure
publishing is correct.

Another issue is the name of the target directory for the final URL. Team
ironic can I change your api-ref-jobs: line to bare-metal instead of
baremetal? It'll be better for search engines and for alignment with the
other projects URLs: https://review.openstack.org/354135

I've also uncovered a problem where a neutron project's API does not have
an official service name, and am working on a solution but need help from
the neutron team: https://review.openstack.org/#/c/351407
Thanks,
Anne


>
> --Projects not using common tooling--
> These projects have API docs but are not yet using the common tooling, as
> far as I can tell. Because of the user experience, I'm making a judgement
> call that these cannot be included in the common navigation. I have patched
> the projects.yaml file in the governance repo with the URLs I could
> screen-scrape, but if I'm incorrect please do patch the projects.yaml in
> the governance repo.
>
> astara
> cloudkitty
> congress
> magnum
> mistral
> monasca
> solum
> tacker
> trove
>
> Please reach out if you have questions or need assistance getting started
> with the new common tooling, documented here: http://docs.openstack.
> org/contributor-guide/api-guides.html.
>
> For searchlight, looking at http://developer.openstack.org/api-ref/search/
> they have the build job, but the info is not complete yet.
>
> One additional project I'm not sure what to do with is networking-nfc,
> since I'm not sure it is considered a neutron API. Can I get help to sort
> that question out?
>
> --Redirects from old pages--
> We have been adding .htaccess redirects from the old
> api-ref-servicename.html on developer.openstack.org as teams are
> comfortable with the accuracy of information and build stability. Please
> help out by patching the api-site repository's .htaccess file when you are
> ready to redirect. These projects could be ready for redirects but do not
> have them:
>
> designate
> glance
> heat
> sahara
> senlin
> swift
>
> I'm available for questions so please reach out as needed. I hope this
> covers our current status.
>
> A million thank yous to everyone who got us this far! Great teamwork,
> great docs work, great UI work,

Re: [openstack-dev] [vitrage] scenario evaluator not enabled by default

2016-08-11 Thread Yujun Zhang

Sorry for having put a url from forked repo. It should be
https://github.com/openstack/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff-6f1a277a2f6e9a567b38d646f19728bcL36

But the content is the same
--
Yujun

On Thu, Aug 11, 2016 at 10:43 PM Yujun Zhang 
wrote:

> It seems the scenario evaluator is not enabled when vitrage is started in
> devstack installer.
>
> I dig a bit in the history, it seems the default value for the evaluator
> is changed from True to False in a history commit [1].
>
> Is it breaking the starting of evaluator or I have missed some steps to
> enable it explictily?
>
> - [1]
> https://github.com/openzero-zte/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff-6f1a277a2f6e9a567b38d646f19728bcL36
>
> --
> Yujun
>
__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Duncan Thomas

Given the options, I'd agree with Sean and John that removing the tag is a
far lesser evil than changing our policy.

If we leave broken drivers in the tree, the end user (operator) is no
better off - the thing they evaluated won't work - but it will be harder to
tell why. The storage vendor won't suffer the pressure that comes from
driver removal, so will have less incentive to fix their driver (there's
enough examples of the threat of driver removal causing the immediate fix
of things that have remained broken for months that we know, for certain
that the policy works).

I'd prefer to make the meaning of the tag sane WRT third party drivers,
which I think would help other projects to be able to police their drivers
and CI better too, without risking losing / not gaining the tag, which is
likely to hurt a newer project far more than it will cinder.



On 11 August 2016 at 17:29, John Griffith  wrote:

>
>
> On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja  wrote:
>
>> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis 
>> wrote:
>> >> >>
>> >> >> As follow up on the mailing list discussion [0], gerrit activity
>> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
>> >> >> discussion how Cinder follows, or rather does not follow, the
>> standard
>> >> >> deprecation policy [4] as the project has been tagged on the assert
>> >> >> page [5].
>> >> >>
>> > 
>> >> >>
>> >> >> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-Augu
>> st/100717.html
>> >> >> [1] https://review.openstack.org/#/c/348032/
>> >> >> [2] https://review.openstack.org/#/c/348042/
>> >> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>> >> >> [4] https://governance.openstack.org/reference/tags/assert_follo
>> ws-standard-deprecation.html#requirements
>> >> >> [5] https://governance.openstack.org/reference/tags/assert_follo
>> ws-standard-deprecation.html#application-to-current-projects
>> >> >>
>> >> >
>> >> > Can you be more specific about what you mean? Are you saying that
>> >> > the policy isn't being followed because the drivers were removed
>> >> > without a deprecation period, or is there something else to it?
>> >> >
>> >> > Doug
>> >> >
>> >>
>> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
>> >> be removed without any warning to the consumers while the standard
>> >> deprecation policy defines quite strict lines about informing the
>> >> consumer of the functionality deprecation before it gets removed.
>> >>
>> >> - Erno
>> >
>> > It is a good point. I think it highlights a common thread though with
>> > the other discussion that, at least so far, third party drivers are
>> > treated differently than the rest of the code.
>> >
>> > For any other functionality we certainly follow the deprecation policy.
>> > Even in existing drivers we try to enforce that any driver renames,
>> > config setting changes, and similar non-backwards compatible changes go
>> > through the normal deprecation cycle before being removed.
>> >
>> > Ideally I would love it if we could comply with the deprecation policy
>> > with regards to driver removal. But the reality is, if we don't see that
>> > a driver is being supported and maintained by its vendor, then that
>> > burden can't fall on the wider OpenStack and Cinder community that has
>> > no way of validating against physical hardware.
>> >
>> > I think third party drivers need to be treated differently when it comes
>> > to the deprecation policy. If that is not acceptable, then I suppose we
>> > do need to remove that tag. Tag removal would be the lesser of the two
>> > versus keeping around drivers that we know aren't really being
>> > maintained.
>> >
>> > If it came to that, I would also consider creating a new cinder-drivers
>> > project under the Cinder umbrella and move all of the drivers not tested
>> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
>> > would try to avoid that if possible. But it would at least allow us to
>> > still get code reviews and all of the benefits of being in tree. Just
>> > some thoughts.
>> >
>> > Sean
>> >
>>
>> Sean,
>>
>> As said on my initial opening, I do understand and agree with the
>> reasoning/treatment of the 3rd party drivers. My request for that tag
>> removal is out of the remains of my ops hat.
>>
>> Lets say I was ops evaluating different options as storage vendor for
>> my cloud and I get told that "Here is the list of supported drivers
>> for different OpenStack Cinder back ends delivered by Cinder team", I
>> start looking what the support level of those drivers are and see that
>> Cinder follows standard deprecation which is fairly user/ops friendly
>> with decent warning etc. I'm happy with that, not knowing OpenStack I
>> would not even look if different subcomponents of Cinder happens to
>> follow different policy. Now I buy storage vendor X HW and at Oct I
>> realize that the

Re: [openstack-dev] [nova] test strategy for the serial console feature

2016-08-11 Thread Markus Zoeller

On 11.08.2016 13:31, Daniel P. Berrange wrote:
> On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote:
>> On 08/11/2016 05:45 AM, Markus Zoeller wrote:
>>> On 26.07.2016 12:16, Jordan Pittier wrote:
 Hi Markus
 You don"t really need a whole new job for this. Just turn that flag to True
 on existing jobs.

 30/40 seconds is acceptable. But I am surprised considering a VM usually
 boots in 5 sec or so. Any idea of where that slowdown comes from ?

 On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller <
 mzoel...@linux.vnet.ibm.com> wrote:
>>
>> We just had a big chat about this in the #openstack-nova IRC channel. To
>> summarize:
>>
>> The class of bugs that are really problematic are:
>>
>>  * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252
>> in OpenStack Compute (nova) "enabling serial console breaks live
>> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui)
>>
>> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962
>> in OpenStack Compute (nova) "live migration with disabled vnc/spice not
>> possible" [Undecided,In progress] - Assigned to Markus Zoeller
>> (markus_z) (mzoeller)
>>
>> Which are both in the category of serial console breaking live
>> migration. It's the serial device vs. live migration that's most
>> problematic. Serial consoles themselves haven't broken badly recently.
>> Given that we don't do live migration testing in most normal jobs, the
>> Tempest jobs aren't really going to help here.
>>
>> The dedicated live-migration job is being targeted.
>>
>> Serial console support is currently a function at the compute level.
>> Which is actually a little odd. Because it means that all guests on a
>> compute must be serial console, or must not. Imagine a compute running
>> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to
>> force serial console one way or another on all of those the same way.
>> This is probably something that makes sense to add as an image
>> attribute, because images will need guest configuration to support
>> serial consoles. As an image attribute this would also help on testing
>> because we could mix / match in a single run.
> 
> There is actually image properties for this, but the way it is all
> implemented right now is just insane.

You're talking about "hw_serial_port_count" I assume? I'm not aware of
any other property for that. Sean was talking about enabling the serial
console per image/flavor property IIUC.


> For QEMU/KVM (on x86) currently, by default you get
> 
>  - a serial port which is connected to a file
>  - a serial port which is connected to a pty
> 
> If you turned on the serial_console option in nova.conf you instead get
> 
>  - one or more serial ports connected to a tcp port
>  - a serial port which is connected to a pty
> 
> The number of serial ports is based off an image property (
> hw_serial_port_count), but strangely the code doesn't honour a
> value of 0 for that. In addition the last serial port connected
> to a pty should really not even exist at that point.
> 
> We should aim to get to a place where we have 'serial_console.enabled'
> default to True in nova.conf and hw_serial_port_count setting how many
> are created, with 0 being a valid number. Never create any other serial
> ports that were not requested.
> 
> Regards,
> Daniel
> 

Allowing '0' as property value sounds like a good approach.

-- 
Regards, Markus Zoeller (markus_z)


__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Hayes, Graham

On 11/08/2016 15:35, John Griffith wrote:
>
>
> On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja  > wrote:
>
> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis
> > wrote:
> >> >>
> >> >> As follow up on the mailing list discussion [0], gerrit activity
> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> >> discussion how Cinder follows, or rather does not follow, the
> standard
> >> >> deprecation policy [4] as the project has been tagged on the
> assert
> >> >> page [5].
> >> >>
> > 
> >> >>
> >> >> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> 
> 
> >> >> [1] https://review.openstack.org/#/c/348032/
> 
> >> >> [2] https://review.openstack.org/#/c/348042/
> 
> >> >> [3]
> https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> 
> >> >> [4]
> 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> 
> 
> >> >> [5]
> 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> 
> 
> >> >>
> >> >
> >> > Can you be more specific about what you mean? Are you saying that
> >> > the policy isn't being followed because the drivers were removed
> >> > without a deprecation period, or is there something else to it?
> >> >
> >> > Doug
> >> >
> >>
> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
> >> be removed without any warning to the consumers while the standard
> >> deprecation policy defines quite strict lines about informing the
> >> consumer of the functionality deprecation before it gets removed.
> >>
> >> - Erno
> >
> > It is a good point. I think it highlights a common thread though with
> > the other discussion that, at least so far, third party drivers are
> > treated differently than the rest of the code.
> >
> > For any other functionality we certainly follow the deprecation
> policy.
> > Even in existing drivers we try to enforce that any driver renames,
> > config setting changes, and similar non-backwards compatible
> changes go
> > through the normal deprecation cycle before being removed.
> >
> > Ideally I would love it if we could comply with the deprecation policy
> > with regards to driver removal. But the reality is, if we don't
> see that
> > a driver is being supported and maintained by its vendor, then that
> > burden can't fall on the wider OpenStack and Cinder community that has
> > no way of validating against physical hardware.
> >
> > I think third party drivers need to be treated differently when it
> comes
> > to the deprecation policy. If that is not acceptable, then I
> suppose we
> > do need to remove that tag. Tag removal would be the lesser of the two
> > versus keeping around drivers that we know aren't really being
> > maintained.
> >
> > If it came to that, I would also consider creating a new
> cinder-drivers
> > project under the Cinder umbrella and move all of the drivers not
> tested
> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> > would try to avoid that if possible. But it would at least allow us to
> > still get code reviews and all of the benefits of being in tree. Just
> > some thoughts.
> >
> > Sean
> >
>
> Sean,
>
> As said on my initial opening, I do understand and agree with the
> reasoning/treatment of the 3rd party drivers. My request for that tag
> removal is out of the remains of my ops hat.
>
> Lets say I was ops evaluating different options as storage vendor for
> my cloud and I get told that "Here is the list of supported drivers
> for different OpenStack Cinder back ends delivered by Cinder team", I
> start looking what the support level of those drivers are and see that
> Cinder follows standard deprecation which is fairly user/ops friendly
> with decent warning etc. I'm happy with that, not knowing OpenStack I
> would not even look if different subcomponents of Cinder happens to
> follow different policy. Now I buy storage vendor X HW and at Oct I
> realize that the vendor's driver is not shipped, nor any

[openstack-dev] [vitrage] scenario evaluator not enabled by default

2016-08-11 Thread Yujun Zhang

It seems the scenario evaluator is not enabled when vitrage is started in
devstack installer.

I dig a bit in the history, it seems the default value for the evaluator is
changed from True to False in a history commit [1].

Is it breaking the starting of evaluator or I have missed some steps to
enable it explictily?

- [1]
https://github.com/openzero-zte/vitrage/commit/bdba10cb71b2fa3744e4178494fa860303ae0bbe#diff-6f1a277a2f6e9a567b38d646f19728bcL36

--
Yujun
__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread John Griffith

On Thu, Aug 11, 2016 at 7:14 AM, Erno Kuvaja  wrote:

> On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis 
> wrote:
> >> >>
> >> >> As follow up on the mailing list discussion [0], gerrit activity
> >> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> >> discussion how Cinder follows, or rather does not follow, the
> standard
> >> >> deprecation policy [4] as the project has been tagged on the assert
> >> >> page [5].
> >> >>
> > 
> >> >>
> >> >> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> August/100717.html
> >> >> [1] https://review.openstack.org/#/c/348032/
> >> >> [2] https://review.openstack.org/#/c/348042/
> >> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> >> >> [4] https://governance.openstack.org/reference/tags/assert_
> follows-standard-deprecation.html#requirements
> >> >> [5] https://governance.openstack.org/reference/tags/assert_
> follows-standard-deprecation.html#application-to-current-projects
> >> >>
> >> >
> >> > Can you be more specific about what you mean? Are you saying that
> >> > the policy isn't being followed because the drivers were removed
> >> > without a deprecation period, or is there something else to it?
> >> >
> >> > Doug
> >> >
> >>
> >> Yes, that's how I see it. Cinder's own policy is that the drivers can
> >> be removed without any warning to the consumers while the standard
> >> deprecation policy defines quite strict lines about informing the
> >> consumer of the functionality deprecation before it gets removed.
> >>
> >> - Erno
> >
> > It is a good point. I think it highlights a common thread though with
> > the other discussion that, at least so far, third party drivers are
> > treated differently than the rest of the code.
> >
> > For any other functionality we certainly follow the deprecation policy.
> > Even in existing drivers we try to enforce that any driver renames,
> > config setting changes, and similar non-backwards compatible changes go
> > through the normal deprecation cycle before being removed.
> >
> > Ideally I would love it if we could comply with the deprecation policy
> > with regards to driver removal. But the reality is, if we don't see that
> > a driver is being supported and maintained by its vendor, then that
> > burden can't fall on the wider OpenStack and Cinder community that has
> > no way of validating against physical hardware.
> >
> > I think third party drivers need to be treated differently when it comes
> > to the deprecation policy. If that is not acceptable, then I suppose we
> > do need to remove that tag. Tag removal would be the lesser of the two
> > versus keeping around drivers that we know aren't really being
> > maintained.
> >
> > If it came to that, I would also consider creating a new cinder-drivers
> > project under the Cinder umbrella and move all of the drivers not tested
> > by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> > would try to avoid that if possible. But it would at least allow us to
> > still get code reviews and all of the benefits of being in tree. Just
> > some thoughts.
> >
> > Sean
> >
>
> Sean,
>
> As said on my initial opening, I do understand and agree with the
> reasoning/treatment of the 3rd party drivers. My request for that tag
> removal is out of the remains of my ops hat.
>
> Lets say I was ops evaluating different options as storage vendor for
> my cloud and I get told that "Here is the list of supported drivers
> for different OpenStack Cinder back ends delivered by Cinder team", I
> start looking what the support level of those drivers are and see that
> Cinder follows standard deprecation which is fairly user/ops friendly
> with decent warning etc. I'm happy with that, not knowing OpenStack I
> would not even look if different subcomponents of Cinder happens to
> follow different policy. Now I buy storage vendor X HW and at Oct I
> realize that the vendor's driver is not shipped, nor any remains of it
> is visible anymore, I'd be reasonably pissed off. If I knew that the
> risk is there I would select my HW based on the negotiations that my
> HW is contractually tied to maintain that driver and it's CI, and that
> would be fine as well or if not possible I'd select some other
> solution I could get reasonably guarantee that it will be
> supported/valid at it's expected life time. As said I don't think
> there is anything wrong with the 3rd party driver policy, but
> maintaining that and the tag about standard-deprecation project wide
> is sending wrong message to those who do not know better to safeguard
> their rear ends.
>
> The other option would be to leave the drivers in tree, tag them with
> deprecation message, something like "This driver has not been tested
> by vendor CI since 15.3.2016 and cannot be guaranteed working. Unless
> testing will be resumed the driver will be removed on Unicorn
> release". Which would give as clear indication that the driver

Re: [openstack-dev] [octavia] Multi-node controller testing

2016-08-11 Thread Roman Vasilets

Hi,
  "need to have something (tempest-plugin) to make sure that integration
works with nova & neutron" - Its easy to write scenarios that will test
that octavia works with nova and neutron
  "I guess rally is more suited to make sure that things work at scale, to
uncover any sort of race conditions (This would be specially beneficial in
multinode controllers)" - Rally is suitable for many kind of tests=)
Especially for testing at scale! If you have any question how to use Rally
feel free to ask Rally team!

- Best regards, Roman Vasylets. Rally team member

On Thu, Aug 11, 2016 at 11:46 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> On Wed, Aug 10, 2016 at 9:51 PM, Stephen Balukoff 
> wrote:
> > Miguel--
> >
> > There have been a number of tempest patches in the review queue for a
> long
> > time now, but I think the reason they're not getting attention is that we
> > don't want to have to import a massive amount of tempest code into our
> > repository (which will become stale and need hot-fixing, as has happened
> > with neutron-lbaas on many occasions), and it appears tempest-lib doesn't
> > yet support all the stuff we would need to do with it.
>
> I guess you mean [1]
>
>
> > People have suggested Rally, but so far nobody has come forth with code,
> or
> > a strong desire to push it through.
>
> I guess rally is more suited to make sure that things work at scale,
> to uncover any sort of race conditions (This would be specially
> beneficial in multinode controllers).
>
> But I understand (I can be wrong) that we still need to have something
> (tempest-plugin) to make sure that integration works with nova &
> neutron. I'm going to check those patches to see what was the
> discussion and issues over there (I see this one [1] to start with,
> which is probably the most important)
>
> [1] https://review.openstack.org/#/q/status:open+project:
> openstack/octavia+branch:master+topic:octavia_basic_lb_scenario
>
> [2] https://review.openstack.org/#/c/172199/66..75/.testr.conf
>
>
> > Stephen
> >
> > On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo
> >  wrote:
> >>
> >> On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz  >
> >> wrote:
> >> > Great work with that multi-node setup Miguel.
> >>
> >> Thanks, I have to get my hands dirtier with octavia, it's just a tiny
> >> thing.
> >>
> >> > About that multinode Infra is supporting two nodes setup used
> currently
> >> > by grenade jobs but in my opinion we don’t have any tests which can
> cover
> >> > that type of testing. We’re still struggling with selecting proper
> tool to
> >> > test Octavia from integration/functional perspective so probably it’s
> too
> >> > early to make it happen.
> >>
> >>
> >> Well, any current tests we run should pass equally well in a multi
> >> node controller, and that's the point, that, regardless of the
> >> deployment architecture the behaviour shall not change at all. We may
> >> not need any specific test.
> >>
> >>
> >> > Maybe it’s great start to finally make some decision about testing
> tools
> >> > and there will be a lot of work for you after that also with setting
> up an
> >> > infra multi-node job for that.
> >>
> >> I'm not fully aware of what are we running today for octavia, so if
> >> you can give me some pointers about where are those jobs configured,
> >> and what do they target, it could be a start, to provide feedback.
> >>
> >> What are the current options/tools we're considering?
> >>
> >>
> >> >
> >> > Cheers,
> >> > Lubosz Kosnik
> >> > Cloud Software Engineer OSIC
> >> > lubosz.kos...@intel.com
> >> >
> >> >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo
> >> >>  wrote:
> >> >>
> >> >> Recently, I sent a series of patches [1] to make it easier for
> >> >> developers to deploy a multi node octavia controller with
> >> >> n_controllers x [api, cw, hm, hk] with an haproxy in front of the
> API.
> >> >>
> >> >> Since this is the way the service is designed to work (with
> horizontal
> >> >> scalability in mind), and we want to have a good guarantee that any
> >> >> bug related to such configuration is found early, and addressed, I
> was
> >> >> thinking that an extra job that runs a two node controller deployment
> >> >> could be beneficial for the project.
> >> >>
> >> >>
> >> >> If we all believe it makes sense, I would be willing to take on this
> >> >> work but I'd probably need some pointers and light help, since I've
> >> >> never dealt with setting up or modifying existing jobs.
> >> >>
> >> >> How does this sound?
> >> >>
> >> >>
> >> >> [1]
> >> >> https://review.openstack.org/#/q/status:merged+project:
> openstack/octavia+branch:master+topic:multinode-devstack
> >> >>
> >> >>
> >> >> 
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >>

Re: [openstack-dev] [nova] Nova mascot - nominations and voting

2016-08-11 Thread Sean Dague

On 08/10/2016 11:46 AM, Sean Dague wrote:
> On 08/10/2016 11:36 AM, Sean Dague wrote:
>> On 08/09/2016 07:30 PM, Heidi Joy Tretheway wrote:
>>> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll
>>> be missed. :-)
>>>
>>> A few notes following up on Matt Riedemann, Clint Byrum, Daniel
>>> Berrange’s conversation regarding the Nova mascot…
>>>
>>> Nova doesn’t have to have a mascot if the majority of the team doesn’t
>>> want one. I’m not sure if the Nova community took a vote or if it was
>>> more of an informal discussion. We have 53 projects with confirmed
>>> logos, and we’re planning some great swag associated with the new
>>> project mascots. (I’m surprised the Nova team didn’t immediately request
>>> a star nova as their mascot. I’ll give you three guesses what Swift
>>> picked...)
>>
>> Ok, we've been having a bit of a nova core private email thread just to
>> figure out where everyone stood.

So... I overstepped here and jumped to a conclusion based on an
incorrect understanding of people's sentiments. And there has been some
concern expressed that part of this conversation was private, which is a
valid concern. I'm sorry about all of that.

Let's start afresh...

What's been publicly suggested so far (from all ML posts that seem to
contain a suggestion):

ant - alexis (already chosen by infra)
bee - alexis (already chosen by refstack)
star - heidi
supernova - markus, auggy, bob ball
octopus - chris (already chosen by UX)

I'd suggest that we actually combine star/supernova into one item to
give the graphic designers some flexibility and creativity. With less
distinctive features than animals, the freedom is probably needed to
make something cool.

Are there other suggestions? Those items already chosen by other teams
are out of bounds per the FAQ
(http://www.openstack.org/project-mascots). We can leave this open for
the rest of the week, and if there are additional valid options do an
ATC poll next week.

-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Erno Kuvaja

On Thu, Aug 11, 2016 at 2:47 PM, Sean McGinnis  wrote:
>> >>
>> >> As follow up on the mailing list discussion [0], gerrit activity
>> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
>> >> discussion how Cinder follows, or rather does not follow, the standard
>> >> deprecation policy [4] as the project has been tagged on the assert
>> >> page [5].
>> >>
> 
>> >>
>> >> [0] 
>> >> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
>> >> [1] https://review.openstack.org/#/c/348032/
>> >> [2] https://review.openstack.org/#/c/348042/
>> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>> >> [4] 
>> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
>> >> [5] 
>> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
>> >>
>> >
>> > Can you be more specific about what you mean? Are you saying that
>> > the policy isn't being followed because the drivers were removed
>> > without a deprecation period, or is there something else to it?
>> >
>> > Doug
>> >
>>
>> Yes, that's how I see it. Cinder's own policy is that the drivers can
>> be removed without any warning to the consumers while the standard
>> deprecation policy defines quite strict lines about informing the
>> consumer of the functionality deprecation before it gets removed.
>>
>> - Erno
>
> It is a good point. I think it highlights a common thread though with
> the other discussion that, at least so far, third party drivers are
> treated differently than the rest of the code.
>
> For any other functionality we certainly follow the deprecation policy.
> Even in existing drivers we try to enforce that any driver renames,
> config setting changes, and similar non-backwards compatible changes go
> through the normal deprecation cycle before being removed.
>
> Ideally I would love it if we could comply with the deprecation policy
> with regards to driver removal. But the reality is, if we don't see that
> a driver is being supported and maintained by its vendor, then that
> burden can't fall on the wider OpenStack and Cinder community that has
> no way of validating against physical hardware.
>
> I think third party drivers need to be treated differently when it comes
> to the deprecation policy. If that is not acceptable, then I suppose we
> do need to remove that tag. Tag removal would be the lesser of the two
> versus keeping around drivers that we know aren't really being
> maintained.
>
> If it came to that, I would also consider creating a new cinder-drivers
> project under the Cinder umbrella and move all of the drivers not tested
> by Jenkins over to that. That wouldn't be a trivial undertaking, so I
> would try to avoid that if possible. But it would at least allow us to
> still get code reviews and all of the benefits of being in tree. Just
> some thoughts.
>
> Sean
>

Sean,

As said on my initial opening, I do understand and agree with the
reasoning/treatment of the 3rd party drivers. My request for that tag
removal is out of the remains of my ops hat.

Lets say I was ops evaluating different options as storage vendor for
my cloud and I get told that "Here is the list of supported drivers
for different OpenStack Cinder back ends delivered by Cinder team", I
start looking what the support level of those drivers are and see that
Cinder follows standard deprecation which is fairly user/ops friendly
with decent warning etc. I'm happy with that, not knowing OpenStack I
would not even look if different subcomponents of Cinder happens to
follow different policy. Now I buy storage vendor X HW and at Oct I
realize that the vendor's driver is not shipped, nor any remains of it
is visible anymore, I'd be reasonably pissed off. If I knew that the
risk is there I would select my HW based on the negotiations that my
HW is contractually tied to maintain that driver and it's CI, and that
would be fine as well or if not possible I'd select some other
solution I could get reasonably guarantee that it will be
supported/valid at it's expected life time. As said I don't think
there is anything wrong with the 3rd party driver policy, but
maintaining that and the tag about standard-deprecation project wide
is sending wrong message to those who do not know better to safeguard
their rear ends.

The other option would be to leave the drivers in tree, tag them with
deprecation message, something like "This driver has not been tested
by vendor CI since 15.3.2016 and cannot be guaranteed working. Unless
testing will be resumed the driver will be removed on Unicorn
release". Which would give as clear indication that the driver seems
abandoned, but still provide the consumer easier way to test in their
staging if the driver is something they still dare to use in
production or not.

IMHO this is purely to set the expectations right for our consumers so
that they know what

Re: [openstack-dev] [ironic] About third-party CI

2016-08-11 Thread Mathieu Mitchell


Noticed something had slipped :)

On 2016-08-10 9:21 AM, Jim Rollenhagen wrote:

4) The drivers that use pyghmi (pxe_ipminative and agent_pyghmi) currently are
   not tested in ironic's CI. We have multiple jobs for each of the ipmitool
   drivers. Instead of making new jobs, we could just move one of the ipmitool
   drivers to use the pyghmi drivers (since they both use IPMI, it should be
   simple to do so). As with above, I'm happy to do this if there are no
   volunteers.


I will take care of converting it and addressing failures that come up.

Mathieu

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

Re: [openstack-dev] [puppet] Why do we have two providers for openstack_config ?

2016-08-11 Thread Emilien Macchi

On Thu, Aug 11, 2016 at 9:26 AM, Sofer Athlan-Guyot  wrote:
> Hi,
>
> I stumbled on the fact that there are two providers for the
> openstack_config type: ruby[1]; ini_setting.rb[2].
>
> The ruby's one has a fork of the inifile ruby's provider is there[3].
>
> It is currently used by those 6 types:
>
>  - neutron_lbaas_service_config
>  - nova_config
>  - neutron_vpnaas_service_config
>  - neutron_config
>  - ceilometer_config
>  - barbican_config
>
> They all have in common to define the value type as an array, for
> instance in [4].
>
> A basic support for :array_matching => all in ini_setting is not hard to
> do (added there [5]).
>
> So, are there other reasons I missed, that force us to keep the second
> provider ?
>
> For instance that could be places where this array_matching => all is
> currently used in any config setting like:
>
> nova_config { 'foo/bar' => ['1','2','3'] }
>
> Or, digging into the code, I've got the impression that it's able to
> "collect" configuration like this:
>
> [foo]
> bar = 1
> bar = 2
> bar = 3
>
> but then again, not sure and didn't have to test it all.
>
> If someone has some answer to the why and how of the ruby.rb provider,
> that would be awesome.  At the very least we could add it to the README.

It seems like it comes from:
https://github.com/openstack/puppet-openstacklib/commit/029c6a74cce2dceff5ae78c138a050d9eb7a6f9b

"This patch add support for parsing configuration files of projects
which use oslo.config.cfg.MultiStrOpt (currently Neutron LBaaSv2)"

Which is exactly what you're talking about.

I'm 100% in favor of removing this provider and add the feature into
ini_setting if possible.

Thanks,

> Thanks for reading this far,
> Regards,
>
> [1] 
> https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ruby.rb
> [2] 
> https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ini_setting.rb
> [3] 
> https://github.com/openstack/puppet-openstacklib/tree/master/lib/puppet/util
> [4] 
> https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/type/neutron_lbaas_service_config.rb#L10
> [5] https://review.openstack.org/#/c/354018/
> --
> Sofer Athlan-Guyot
>
> __
> OpenStack Development Mailing 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] [puppet] Why do we have two providers for openstack_config ?

2016-08-11 Thread Sofer Athlan-Guyot

Hi,

I kinda answered all my question myself.  Here a sum up of what I have
understood https://review.openstack.org/#/c/354094/

Feel free to review.

Regards,

Sofer Athlan-Guyot  writes:

> Hi,
>
> I stumbled on the fact that there are two providers for the
> openstack_config type: ruby[1]; ini_setting.rb[2].
>
> The ruby's one has a fork of the inifile ruby's provider is there[3].
>
> It is currently used by those 6 types:
>
>  - neutron_lbaas_service_config
>  - nova_config
>  - neutron_vpnaas_service_config
>  - neutron_config
>  - ceilometer_config
>  - barbican_config
>
> They all have in common to define the value type as an array, for
> instance in [4].
>
> A basic support for :array_matching => all in ini_setting is not hard to
> do (added there [5]).
>
> So, are there other reasons I missed, that force us to keep the second
> provider ?
>
> For instance that could be places where this array_matching => all is
> currently used in any config setting like:
>
> nova_config { 'foo/bar' => ['1','2','3'] }
>
> Or, digging into the code, I've got the impression that it's able to
> "collect" configuration like this:
>
> [foo]
> bar = 1
> bar = 2
> bar = 3
>
> but then again, not sure and didn't have to test it all.
>
> If someone has some answer to the why and how of the ruby.rb provider,
> that would be awesome.  At the very least we could add it to the README.
>
> Thanks for reading this far,
> Regards,
>
> [1] 
> https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ruby.rb
> [2] 
> https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ini_setting.rb
> [3] 
> https://github.com/openstack/puppet-openstacklib/tree/master/lib/puppet/util
> [4] 
> https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/type/neutron_lbaas_service_config.rb#L10
> [5] https://review.openstack.org/#/c/354018/

-- 
refos

__
OpenStack Development Mailing 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] The deprecation of proxy API related CLI

2016-08-11 Thread Matt Riedemann


On 8/10/2016 11:01 PM, Alex Xu wrote:

Hi, guys,

We have agreement on how to deprecate the CLI for the proxy APIs which
were deprecated in 2.36 when mid-cycle. But I still feels that we have
something isn't very clear. So I just want to summary the situation at
here, and to be clear the final goal.

Here are the patches https://review.openstack.org/347514
and https://review.openstack.org/#/c/348499

So the agreement is:

When user executes the network related CLI without specific version or
with specific version > 2.35, the CLI will fallback to 2.35 automatically.

For the API part, we won't do any workaround, so that means we will stop
to support those after 2.35, we need add decorator like
this 
https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L917


I hadn't considered capping the python APIs in novaclient like this, but 
it was something I was wondering about. The image and baremetal CLI/APIs 
in novaclient have already been deprecated, but we don't cap those in 
the API, nor do we try and make it a soft landing for the CLIs. The only 
reason the network stuff gets a temporary pass on the CLI side is for 
nova-network users.


That's also because the CLI defaults to 2.latest, the API doesn't. So 
for the API you have to opt into use newer versions, right? If that's 
the case, then you would need to consciously request 2.36 on those proxy 
APIs for them to fail, which I'm hoping people aren't going to be doing, 
or at least they should be reading the REST API version history first to 
see what they are opting into.




But the agreement is only talk about network related thing, we also
deprecate image/volume/snapshot/baremetal/fping stuff. So what is the
plan for them? I guess we just no workaround also, stop the support
after 2.35.

So the final status will be as below:

* Network CLI: Auto fallback to 2.35 in the patch
* Quota/Limit CLI: Remove network quotas after 2.35 in the current patch
* Image CLI: Currently the CLI emit the deprecated message in the code,
but it still break in 2.36(get a 404 message). We should stop support it
after 2.35
* Baremetal CLI: Same as Image CLI, there is message, but will break in
2.36. Stop to support it after 2.35
* No Volume/Snapshot/fping related CLI

* Network/Image/Quota/Limit/Baremetal/Volumes/fping API: No workaround.
Stop to support them after 2.35.

Thanks
Alex



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




--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [vitrage] aodh datasource properties

2016-08-11 Thread Yujun Zhang

OK, I have assigned myself for this issue and hope to resolve it soon.
--
Yujun

On Thu, Aug 11, 2016 at 6:30 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
> There are few ways to create Aodh alarms. You are referring to
> event-alarms, and I believe you are right about the bug.
>
> Note, however, that for threshold-alarm, the resource_id appears without
> the “traits” prefix, so Vitrage Aodh datasource should be able to handle
> both cases. An example for creating a threshold alarm:
> ceilometer alarm-threshold-create --name 'cpu_alarm' --description 'CPU
> utilization is above 70%' -m 'cpu_util' --period 60 --threshold 0.7
>  --comparison-operator gt --query
> 'resource_id=5f6db701-19d6-4a98-895b-8094f2bd7304'
>
> Hope it helped,
> Ifat.
>
> From: Yujun Zhang
> Date: Thursday, 11 August 2016 at 12:36
>
>
> It seems the aodh properties definition in vitrage [1] is not consistent
> with the latest ceilometer spec [2].
>
> The response_id is now encapsulated in `traits` and we must prepend the
> scope in query to make it a valid alarm condition, e.g. `query: [{u'field':
> u'traits.resource_id', u'type': u'string', u'value': u'...'`
>
> But in vitrage, the resource id is parsed from key 'resource_id' [3] and
> always get an empty result.
>
> Could anybody confirm whether this is a bug or not? Tracked in
> https://bugs.launchpad.net/vitrage/+bug/1612152
>
> - [1]
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/aodh/properties.py#L27
> - [2]
>
> https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/event_definitions.yaml#L76
> - [3]
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/aodh/driver.py#L66
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] ssh and http connection lost

2016-08-11 Thread Ton Ngo

Hi Yasemin,
   How would you like to configure the networking?  Which COE are you
using?
You may want to consult the Networking section in the user guide:
https://github.com/openstack/magnum/blob/master/doc/source/userguide.rst#networking

Ton Ngo,



From:   Yasemin DEMİRAL (BİLGEM BTE) 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   08/11/2016 03:39 AM
Subject:Re: [openstack-dev] [magnum] ssh and http connection lost




docker0 bridge is 172.24.. network, it is default. What can i configure
network settings ?


Kimden: "taget" 
Kime: openstack-dev@lists.openstack.org
Gönderilenler: 11 Ağustos Perşembe 2016 11:26:07
Konu: Re: [openstack-dev] [magnum] ssh and http connection lost

Seems there's no relationship with Magnum service at all, you may need to
fix figure out why you can not access your test machine.

As for as I know, bay-create won't block your network access.

- Eli.

On 2016年08月11日 16:13, Yasemin DEMİRAL (BİLGEM BTE) wrote:

  Hi

  I installed magnum on devstack successfully. I tired the "magnum
  bay-create --name k8sbay --baymodel k8sbaymodel --node-count 1 "
  command in the guide  .
  but in i lost my ssh connection for my test machine and http
  connection for horizon. what can i do ? i can not connect to terminal
  screen my test machine ?

  Can you help me?

  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


--
Best Regards,
Eli Qiao (乔立勇), Intel OTC.

__
OpenStack Development Mailing 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] [tc][cinder][stable] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Doug Hellmann

Excerpts from Erno Kuvaja's message of 2016-08-11 13:59:54 +0100:
> On Thu, Aug 11, 2016 at 1:32 PM, Doug Hellmann  wrote:
> > Excerpts from Erno Kuvaja's message of 2016-08-11 12:26:59 +0100:
> >> Hi all,
> >>
> >> As follow up on the mailing list discussion [0], gerrit activity
> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> discussion how Cinder follows, or rather does not follow, the standard
> >> deprecation policy [4] as the project has been tagged on the assert
> >> page [5].
> >>
> >> I'm not here to argue about the justification or rightfulness of the
> >> Cinder policy regarding the drivers with 3rd party CI. (quite frankly
> >> I think the Cinder policy makes lots of sense and thus propose the
> >> removal of the tag rather than change of that policy) Just stating the
> >> obvious that the Cinder policy does not comply with the
> >> follows-standard-deprecation and thus the tag should be removed from
> >> Cinder.
> >>
> >> Best,
> >> Erno (jokke) Kuvaja
> >>
> >> [0] 
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> >> [1] https://review.openstack.org/#/c/348032/
> >> [2] https://review.openstack.org/#/c/348042/
> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> >> [4] 
> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> >> [5] 
> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> >>
> >
> > Can you be more specific about what you mean? Are you saying that
> > the policy isn't being followed because the drivers were removed
> > without a deprecation period, or is there something else to it?
> >
> > Doug
> >
> 
> Yes, that's how I see it. Cinder's own policy is that the drivers can
> be removed without any warning to the consumers while the standard
> deprecation policy defines quite strict lines about informing the
> consumer of the functionality deprecation before it gets removed.
> 
> - Erno
> 

Those policies do seem to be in conflict. We should consider whether
it makes sense to adjust Cinder's policy on drivers or remove the
stable tag.

I've added "[stable]" to the subject to get the stable team's input.
I think Tony's TZ means he's likely at the end of his day already,
by maybe some other members of the team will have something to add.

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] [tc][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Sean McGinnis

> >>
> >> As follow up on the mailing list discussion [0], gerrit activity
> >> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> >> discussion how Cinder follows, or rather does not follow, the standard
> >> deprecation policy [4] as the project has been tagged on the assert
> >> page [5].
> >>

> >>
> >> [0] 
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> >> [1] https://review.openstack.org/#/c/348032/
> >> [2] https://review.openstack.org/#/c/348042/
> >> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> >> [4] 
> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> >> [5] 
> >> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> >>
> >
> > Can you be more specific about what you mean? Are you saying that
> > the policy isn't being followed because the drivers were removed
> > without a deprecation period, or is there something else to it?
> >
> > Doug
> >
> 
> Yes, that's how I see it. Cinder's own policy is that the drivers can
> be removed without any warning to the consumers while the standard
> deprecation policy defines quite strict lines about informing the
> consumer of the functionality deprecation before it gets removed.
> 
> - Erno

It is a good point. I think it highlights a common thread though with
the other discussion that, at least so far, third party drivers are
treated differently than the rest of the code.

For any other functionality we certainly follow the deprecation policy.
Even in existing drivers we try to enforce that any driver renames,
config setting changes, and similar non-backwards compatible changes go
through the normal deprecation cycle before being removed.

Ideally I would love it if we could comply with the deprecation policy
with regards to driver removal. But the reality is, if we don't see that
a driver is being supported and maintained by its vendor, then that
burden can't fall on the wider OpenStack and Cinder community that has
no way of validating against physical hardware.

I think third party drivers need to be treated differently when it comes
to the deprecation policy. If that is not acceptable, then I suppose we
do need to remove that tag. Tag removal would be the lesser of the two
versus keeping around drivers that we know aren't really being
maintained.

If it came to that, I would also consider creating a new cinder-drivers
project under the Cinder umbrella and move all of the drivers not tested
by Jenkins over to that. That wouldn't be a trivial undertaking, so I
would try to avoid that if possible. But it would at least allow us to
still get code reviews and all of the benefits of being in tree. Just
some thoughts.

Sean

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

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

Re: [openstack-dev] [tc][cinder][stable] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Anita Kuno


On 16-08-11 09:36 AM, Doug Hellmann wrote:

Excerpts from Erno Kuvaja's message of 2016-08-11 13:59:54 +0100:

On Thu, Aug 11, 2016 at 1:32 PM, Doug Hellmann  wrote:

Excerpts from Erno Kuvaja's message of 2016-08-11 12:26:59 +0100:

Hi all,

As follow up on the mailing list discussion [0], gerrit activity
[1][2] and cinder 3rd party CI policy [3] I'd like to initiate
discussion how Cinder follows, or rather does not follow, the standard
deprecation policy [4] as the project has been tagged on the assert
page [5].

I'm not here to argue about the justification or rightfulness of the
Cinder policy regarding the drivers with 3rd party CI. (quite frankly
I think the Cinder policy makes lots of sense and thus propose the
removal of the tag rather than change of that policy) Just stating the
obvious that the Cinder policy does not comply with the
follows-standard-deprecation and thus the tag should be removed from
Cinder.

Best,
Erno (jokke) Kuvaja

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
[1] https://review.openstack.org/#/c/348032/
[2] https://review.openstack.org/#/c/348042/
[3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[4] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
[5] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects


Can you be more specific about what you mean? Are you saying that
the policy isn't being followed because the drivers were removed
without a deprecation period, or is there something else to it?

Doug


Yes, that's how I see it. Cinder's own policy is that the drivers can
be removed without any warning to the consumers while the standard
deprecation policy defines quite strict lines about informing the
consumer of the functionality deprecation before it gets removed.

- Erno


Those policies do seem to be in conflict. We should consider whether
it makes sense to adjust Cinder's policy on drivers or remove the
stable tag.

I've added "[stable]" to the subject to get the stable team's input.
I think Tony's TZ means he's likely at the end of his day already,
by maybe some other members of the team will have something to add.

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


I think Cinder's approach to removing third party drivers is to be 
commended. I consider Cinder to be the example to follow in how to 
interact with and address third party drivers and third party driver 
maintainers (or not maintainers).


I would hope other projects follow Cinder's example here, rather than 
perceive themselves as being deterred.


Thank you,
Anita.

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

[openstack-dev] [requirements][elections] Requirements PTL Results

2016-08-11 Thread Anita Kuno

We'd like to thank all those folks who came out to participate in this 
election on very brief notice. Thank you. The participation rate is 
impressive.


Thank you to all candidates who put themselves forward, showing their 
enthusiasm for the role. It is plain to see this new team has a lot of 
leadership available to it as it moves forward. Congratulations 
Requirements team.


Please join me in welcoming your new Requirements PTL, Tony Breeds (tonyb).

Full election results can be found here: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_02dbd8750c568757


Thank you for a great election,
Anita and 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-dev] [puppet] Why do we have two providers for openstack_config ?

2016-08-11 Thread Sofer Athlan-Guyot

Hi,

I stumbled on the fact that there are two providers for the
openstack_config type: ruby[1]; ini_setting.rb[2].

The ruby's one has a fork of the inifile ruby's provider is there[3].

It is currently used by those 6 types:

 - neutron_lbaas_service_config
 - nova_config
 - neutron_vpnaas_service_config
 - neutron_config
 - ceilometer_config
 - barbican_config

They all have in common to define the value type as an array, for
instance in [4].

A basic support for :array_matching => all in ini_setting is not hard to
do (added there [5]).

So, are there other reasons I missed, that force us to keep the second
provider ?

For instance that could be places where this array_matching => all is
currently used in any config setting like:

nova_config { 'foo/bar' => ['1','2','3'] }

Or, digging into the code, I've got the impression that it's able to
"collect" configuration like this:

[foo]
bar = 1
bar = 2
bar = 3

but then again, not sure and didn't have to test it all.

If someone has some answer to the why and how of the ruby.rb provider,
that would be awesome.  At the very least we could add it to the README.

Thanks for reading this far,
Regards,

[1] 
https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ruby.rb
[2] 
https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack_config/ini_setting.rb
[3] https://github.com/openstack/puppet-openstacklib/tree/master/lib/puppet/util
[4] 
https://github.com/openstack/puppet-neutron/blob/master/lib/puppet/type/neutron_lbaas_service_config.rb#L10
[5] https://review.openstack.org/#/c/354018/
-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing 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] proposal: start gating on puppet4

2016-08-11 Thread Iury Gregory

+1, Awesome idea Emilien.

2016-08-11 9:45 GMT-03:00 Sofer Athlan-Guyot :

> +1 for me also.  We have to push forward to have puppet 4 as a first
> class citizen.
>
> Matt Fischer  writes:
>
> > +1 from me also. This will help everyone who is trying to transition
> > to it.
> >
> > On Wed, Aug 10, 2016 at 1:46 AM, Javier Pena 
> > wrote:
> >
> >
> >
> >
> > - Original Message -
> > > Hi,
> > >
> > > Today Puppet OpenStack CI is running unit and functional test
> > jobs
> > > against puppet 3 and puppet 4.
> > > Unit jobs for puppet 4 are currently voting and pretty stable.
> > > Functional jobs for puppet 4 are not voting but also stable.
> > >
> > > Even if Puppet4 has not been largely adopted by our community
> > [1] yet,
> > > I would like to encourage our users to upgrade the version of
> > Puppet.
> > > Fedora ships it by default [2] and for Ubuntu, it's also the
> > default
> > > since yakkety [3].
> > >
> > > [1]
> > >
> > https://docs.google.com/spreadsheets/d/1iIQ6YmpdOVctS2-
> wCV6SGPP1NSj8nKD9nv_xtZH9loY/
> >edit?usp=sharing
> > > [2]
> > http://koji.fedoraproject.org/koji/packageinfo?packageID=3529
> > > [3] http://packages.ubuntu.com/yakkety/puppet
> > >
> > > So here's my proposal, feel free to bring any feedback:
> > > - For stable/mitaka CI and stable/liberty nothing will change.
> > > - For current master (future stable/newton in a few months),
> > transform
> > > non-voting puppet4 jobs into voting and add them to the gate.
> > Also
> > > keep puppet3 unit tests jobs, as voting.
> > > - After Newton release (during Ocata cycle), change master CI to
> > only
> > > gate functional jobs on puppet4 (and remove puppet3 jobs for
> > > puppet-openstack-integration); but keep puppet3 unit tests jobs,
> > as
> > > voting.
> > > - During Ocata cycle, implement a periodic job that will nightly
> > check
> > > we can deploy with Puppet3. The periodic job is something our
> > > community interested by Puppet 3 will have to monitor and report
> > any
> > > new failure so we can address it.
> > >
> > > That way, we tell our users:
> > > - don't worry if you deploy Liberty, Mitaka, Newton, we will
> > > officially support Puppet 3.
> > > - if you plan to deploy Puppet 4, we'll officially support you
> > > starting from Newton.
> > > - if you plan to deploy Ocata with Puppet 3, we won't support
> > you
> > > anymore since our functional testing jobs will be gone. Though
> > we'll
> > > make our best to be backward compatible thanks to our unit and
> > > periodic functional testing jobs.
> > >
> > > Regarding packaging:
> > > - on Ubuntu, we'll continue rely on what provides Puppetlabs
> > because
> > > Xenial doesn't provide Puppet4.
> > > - on CentOS7, we are working on getting Puppet 4 packaged in RDO
> > and
> > > our CI will certainly use it.
> > >
> > > Any feedback is welcome,
> >
> >
> > I like the idea. It gives distros enough time to prepare to Puppet
> > 4, and we're supposed to write compatible manifests anyway.
> >
> > Javier
> >
> >
> >
> > > --
> > > 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
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Sofer Athlan-Guyot
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~

Re: [openstack-dev] I want to consult ironic problems

2016-08-11 Thread Mathieu Mitchell


Hi Paul,

It seems you are having issues running Ironic and as Jeremy pointed out 
in a previous reply, the proper mailing list for this is 
openst...@lists.openstack.org.


On the technical side, keep in mind the kernel and ramdisks are part of 
a complete solution and should be used by Ironic for baremetal 
deployment. They are not intended for standalone usage.


We also have a very active IRC channel (#openstack-ironic on freenode) 
where you can get help.


Lastly, I suggest you have a look at our wiki page 
(https://wiki.openstack.org/wiki/Ironic) for more general information 
about Ironic.


Mathieu

On 2016-08-01 3:00 AM, paul schlacter wrote:

the mirror have ramdisk and kernel and image,
I want to know what do these images are used
ironic python agent on ramdisk, he is how to run up in the machine after
the deployment is complete, ironic python agent will run it?

On Fri, Jul 29, 2016 at 6:00 PM, paul schlacter  wrote:


I want to consult ironic problems
do there have bare metal management man?





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



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

Re: [openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Erno Kuvaja

On Thu, Aug 11, 2016 at 1:32 PM, Doug Hellmann  wrote:
> Excerpts from Erno Kuvaja's message of 2016-08-11 12:26:59 +0100:
>> Hi all,
>>
>> As follow up on the mailing list discussion [0], gerrit activity
>> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
>> discussion how Cinder follows, or rather does not follow, the standard
>> deprecation policy [4] as the project has been tagged on the assert
>> page [5].
>>
>> I'm not here to argue about the justification or rightfulness of the
>> Cinder policy regarding the drivers with 3rd party CI. (quite frankly
>> I think the Cinder policy makes lots of sense and thus propose the
>> removal of the tag rather than change of that policy) Just stating the
>> obvious that the Cinder policy does not comply with the
>> follows-standard-deprecation and thus the tag should be removed from
>> Cinder.
>>
>> Best,
>> Erno (jokke) Kuvaja
>>
>> [0] 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
>> [1] https://review.openstack.org/#/c/348032/
>> [2] https://review.openstack.org/#/c/348042/
>> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>> [4] 
>> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
>> [5] 
>> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
>>
>
> Can you be more specific about what you mean? Are you saying that
> the policy isn't being followed because the drivers were removed
> without a deprecation period, or is there something else to it?
>
> Doug
>

Yes, that's how I see it. Cinder's own policy is that the drivers can
be removed without any warning to the consumers while the standard
deprecation policy defines quite strict lines about informing the
consumer of the functionality deprecation before it gets removed.

- Erno

__
OpenStack Development Mailing 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] proposal: start gating on puppet4

2016-08-11 Thread Sofer Athlan-Guyot

+1 for me also.  We have to push forward to have puppet 4 as a first
class citizen.

Matt Fischer  writes:

> +1 from me also. This will help everyone who is trying to transition
> to it.
>
> On Wed, Aug 10, 2016 at 1:46 AM, Javier Pena 
> wrote:
>
> 
> 
> 
> - Original Message -
> > Hi,
> >
> > Today Puppet OpenStack CI is running unit and functional test
> jobs
> > against puppet 3 and puppet 4.
> > Unit jobs for puppet 4 are currently voting and pretty stable.
> > Functional jobs for puppet 4 are not voting but also stable.
> >
> > Even if Puppet4 has not been largely adopted by our community
> [1] yet,
> > I would like to encourage our users to upgrade the version of
> Puppet.
> > Fedora ships it by default [2] and for Ubuntu, it's also the
> default
> > since yakkety [3].
> >
> > [1]
> >
> 
> https://docs.google.com/spreadsheets/d/1iIQ6YmpdOVctS2-wCV6SGPP1NSj8nKD9nv_xtZH9loY/
>edit?usp=sharing
> > [2]
> http://koji.fedoraproject.org/koji/packageinfo?packageID=3529
> > [3] http://packages.ubuntu.com/yakkety/puppet
> >
> > So here's my proposal, feel free to bring any feedback:
> > - For stable/mitaka CI and stable/liberty nothing will change.
> > - For current master (future stable/newton in a few months),
> transform
> > non-voting puppet4 jobs into voting and add them to the gate.
> Also
> > keep puppet3 unit tests jobs, as voting.
> > - After Newton release (during Ocata cycle), change master CI to
> only
> > gate functional jobs on puppet4 (and remove puppet3 jobs for
> > puppet-openstack-integration); but keep puppet3 unit tests jobs,
> as
> > voting.
> > - During Ocata cycle, implement a periodic job that will nightly
> check
> > we can deploy with Puppet3. The periodic job is something our
> > community interested by Puppet 3 will have to monitor and report
> any
> > new failure so we can address it.
> >
> > That way, we tell our users:
> > - don't worry if you deploy Liberty, Mitaka, Newton, we will
> > officially support Puppet 3.
> > - if you plan to deploy Puppet 4, we'll officially support you
> > starting from Newton.
> > - if you plan to deploy Ocata with Puppet 3, we won't support
> you
> > anymore since our functional testing jobs will be gone. Though
> we'll
> > make our best to be backward compatible thanks to our unit and
> > periodic functional testing jobs.
> >
> > Regarding packaging:
> > - on Ubuntu, we'll continue rely on what provides Puppetlabs
> because
> > Xenial doesn't provide Puppet4.
> > - on CentOS7, we are working on getting Puppet 4 packaged in RDO
> and
> > our CI will certainly use it.
> >
> > Any feedback is welcome,
> 
> 
> I like the idea. It gives distros enough time to prepare to Puppet
> 4, and we're supposed to write compatible manifests anyway.
> 
> Javier
> 
> 
> 
> > --
> > 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
> 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Sofer Athlan-Guyot

__
OpenStack Development Mailing 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][cinder] tag:follows-standard-deprecation should be removed

2016-08-11 Thread Doug Hellmann

Excerpts from Erno Kuvaja's message of 2016-08-11 12:26:59 +0100:
> Hi all,
> 
> As follow up on the mailing list discussion [0], gerrit activity
> [1][2] and cinder 3rd party CI policy [3] I'd like to initiate
> discussion how Cinder follows, or rather does not follow, the standard
> deprecation policy [4] as the project has been tagged on the assert
> page [5].
> 
> I'm not here to argue about the justification or rightfulness of the
> Cinder policy regarding the drivers with 3rd party CI. (quite frankly
> I think the Cinder policy makes lots of sense and thus propose the
> removal of the tag rather than change of that policy) Just stating the
> obvious that the Cinder policy does not comply with the
> follows-standard-deprecation and thus the tag should be removed from
> Cinder.
> 
> Best,
> Erno (jokke) Kuvaja
> 
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-August/100717.html
> [1] https://review.openstack.org/#/c/348032/
> [2] https://review.openstack.org/#/c/348042/
> [3] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
> [4] 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements
> [5] 
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#application-to-current-projects
> 

Can you be more specific about what you mean? Are you saying that
the policy isn't being followed because the drivers were removed
without a deprecation period, or is there something else to it?

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-dev] [new][oslo] osprofiler 1.4.0 release (newton)

2016-08-11 Thread no-reply

We are happy to announce the release of:

osprofiler 1.4.0: OpenStack Profiler Library

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/osprofiler

With package available at:

https://pypi.python.org/pypi/osprofiler

Please report issues through launchpad:

http://bugs.launchpad.net/osprofiler

For more details, please see below.

Changes in osprofiler 1.3.0..1.4.0
--

8027a1d Add tests for mongodb driver
b57ebf9 Add connection string usage to osprofiler-cli
f1824b9 Add overall profiler stats by operation
fa5bccb Fix typos on spec directory
fa40453 Fix title of index page
8f3e213 Add MongoDB driver
aca7aeb OSprofiler initialization method
a23d829 Add Ceilometer driver
676a239 Add backward compatible drivers structure
e5ae569 Expose osprofiler middleware as entrypoint
4844e85 Remove discover from test-requirements
16d639d Fix typo: 'Olso' to 'Oslo'
e8079b2 Don't set html_last_updated_fmt without git
147b96b Add exception type to stop trace info
5b3086e doc: Log warning when can't get informaiton from git
1984abe Improve unit test coverage


Diffstat (except docs and test files)
-

.../in-progress/better_devstack_integration.rst|   2 +-
osprofiler/cmd/commands.py |  47 ++-
osprofiler/cmd/exc.py  |  24 --
osprofiler/cmd/shell.py|   4 +-
osprofiler/drivers/__init__.py |   4 +
osprofiler/drivers/base.py | 238 
osprofiler/drivers/ceilometer.py   |  81 
osprofiler/drivers/messaging.py|  62 +++
osprofiler/drivers/mongodb.py  |  92 +
osprofiler/exc.py  |  24 ++
osprofiler/initializer.py  |  42 +++
osprofiler/notifier.py |  19 +-
osprofiler/opts.py |  21 +-
osprofiler/parsers/__init__.py |   0
osprofiler/parsers/ceilometer.py   | 138 ---
osprofiler/profiler.py |  33 +-
requirements.txt   |   1 +
setup.cfg  |   2 +
test-requirements.txt  |   6 +-
34 files changed, 1653 insertions(+), 673 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index d59f2f3..04ea584 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,0 +2 @@ six>=1.9.0 # MIT
+oslo.messaging>=5.2.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 8e36aa8..aa8aa1e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -4 +3,0 @@ coverage>=3.6
-discover
@@ -14 +13,4 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-bandit>=0.17.3 # Apache-2.0
\ No newline at end of file
+bandit>=0.17.3 # Apache-2.0
+
+python-ceilometerclient>=2.2.1 # Apache-2.0
+pymongo>=3.0.2,!=3.1  # Apache-2.0



__
OpenStack Development Mailing 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] additional git repo(s) for tripleo-quickstart

2016-08-11 Thread Wesley Hayutin

On Wed, Aug 10, 2016 at 9:45 PM, Lars Kellogg-Stedman 
wrote:

> On Wed, Aug 10, 2016 at 03:26:18PM -0400, Wesley Hayutin wrote:
> > I'm proposing the creation of a repo called tripleo-quickstart-extras
> that
> > would contain some or all of the current third party roles used with
> > TripleO-Quickstart.
>
> Which roles in particular would you place in this -extras repository?
> One of our goals in moving roles *out* of the quickstart was to move
> them into a one-repository-per-role model that makes things easily
> composable (install only those roles you need) and that
> compartmentalizes related sets of changes.
>

Lars, I'm thinking about this with the following priorities in mind..
1. TripleO-Quickstart code needs to be upstream and governed by the TripleO
project
2. TripleO-Quickstart itself is a replacement for instack-virt-setup
3. TripleO-Quickstart's roles need to be composable
4. TripleO-Quickstart needs to be composable for 3rd party git repositories

If we can get one additional git repo under the TripleO umbrella I think
we've accomplished 1-3.  We can prove #4 with yum repos outside of
OpenStack.

Compartmentalizing changes in their own git repositories is nice, but also
has disadvantages.  For instance, there is less governance across the roles
by oooq core members.  If I had to weigh compartmentalizing the roles vs. a
tripleo-quickstart-extras repo in TripleO, my vote would be for the
latter.  This is just my opinion though.

James made it clear that if TripleO-Quickstart is to provide automatically
generated documentation for the TripleO project the src code has to be
under the TripleO project and the execution itself must run in the TripleO
CI environment.

It would be great if TripleO cores could weigh in and assist us in getting
one additional git repo so we can proceed with determining if automatically
generated documentation would be something TripleO would like.

Thanks

>
> Is this just a convenience for a bunch of roles that are typically
> installed together?
>
> --
> Lars Kellogg-Stedman  | larsks @
> {freenode,twitter,github}
> Cloud Engineering / OpenStack  | http://blog.oddbit.com/
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [tripleo] Host configuration for CPUAffinity and IRQ Pinning

2016-08-11 Thread Kostiantyn.Volenbovskyi

Hi,
maybe [1] and [2]/[3]?
 [2]/[3] however states
"On $::osfamily == 'RedHat', no attempt is made to manage 
/etc/sysconfig/irqbalance. This is arguably a bug."

BR, 
Konstantin
[1] https://github.com/camptocamp/puppet-systemd
[2] https://forge.puppet.com/jhoblitt/irqbalance
[3] https://github.com/jhoblitt/puppet-irqbalance 


> -Original Message-
> From: Saravanan KR [mailto:skram...@redhat.com]
> Sent: Monday, August 08, 2016 12:08 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [puppet] [tripleo] Host configuration for CPUAffinity
> and IRQ Pinning
> 
> Hello,
> 
> For using DPDK, CPUs on compute host has to be isolated between Host, DPDK
> PMD and Guests. In order, to configure the host to use only specified CPUs, 
> the
> CPUAffinity [1] configuration in /etc/systemd/system.conf needs to be used.
> Along with CPUAffinity, IRQ repining[2] needs to be done, to pin the interrupt
> requests to the CPUs dedicated to host processes.
> 
> We are planning to do the changes for configuring CPUAffinity and IRQ repining
> via puppet. We couldn't relate this configuration to any existing module. 
> Could
> you please help us with the direction to enable these configurations?
> 
> Regards,
> Saravanan KR
> 
> 
> Note: It is possible to use isolcpus via grub parameter, but it has 
> implications [3]
> on load balancing. So it is recommended to use CPUAffinity to restrict CPUs 
> for
> host process.
> 
> [1] https://www.freedesktop.org/software/systemd/man/systemd-
> system.conf.html#CPUAffinity=
> [2] https://access.redhat.com/documentation/en-
> US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-
> Realtime_Tuning_Guide-General_System_Tuning-
> Interrupt_and_Process_Binding.html
> [3] https://lists.freedesktop.org/archives/systemd-devel/2016-July/037187.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 >

1 - 100 of 126 matches

Mail list logo