date:20151125

On 25 November 2015 at 03:09, Rossella Sblendido 
wrote:

>
>
> On 11/24/2015 06:53 PM, Armando M. wrote:
>
>>
>>
>> On 24 November 2015 at 04:13, Rossella Sblendido > > wrote:
>>
>>
>>
>> On 11/23/2015 06:38 PM, Armando M. wrote:
>>
>>
>>
>> On 23 November 2015 at 04:02, Rossella Sblendido
>> 
>> >> wrote:
>>
>>
>>
>>  On 11/20/2015 03:54 AM, Armando M. wrote:
>>
>>
>>
>>  On 19 November 2015 at 18:26, Assaf Muller
>> 
>>  >
>>  
>> >
>>   On Wed, Nov 18, 2015 at 9:14 PM, Armando M.
>>  
>> >
>>   >  > >   > Hi Neutrites,
>>   >
>>   > We are nearly two weeks away from the end of
>> Mitaka 1.
>>   >
>>   > I am writing this email to invite you to be
>> mindful to
>>  what you review,
>>   > especially in the next couple of weeks. Whenever
>> you have
>>  the time to review
>>   > code, please consider giving priority to the
>> following:
>>   >
>>   > Patches that target blueprints targeted for
>> Mitaka;
>>   > Patches that target bugs that are either
>> critical or high;
>>   > Patches that target rfe-approved 'bugs';
>>   > Patches that target specs that have followed the
>> most
>>  current submission
>>   > process;
>>
>>   Is it possible to create Gerrit dashboards for
>> patches that
>>  answer these
>>   criteria, and then persist the links in Neutron's
>>  dashboards devref
>>   page?
>> http://docs.openstack.org/developer/neutron/dashboards/index.html
>>   That'd be super useful.
>>
>>
>>  We should look into that, but to be perfectly honest I
>> am not
>>  sure how
>>  easy it would be, since we'd need to cross-reference
>> content
>>  that lives
>>  into gerrit as well as launchpad. Would that even be
>> possible?
>>
>>
>>  To cross-reference we can use the bug ID or the blueprint
>> name.
>>
>>  I created a script that queries launchpad to get:
>>  1) Bug number of the bugs tagged with approved-rfe
>>  2) Bug number of the critical/high bugs
>>  3) list of blueprints targeted for the current milestone
>> (mitaka-1)
>>
>>  With this info the script builds a .dash file that can be
>> used by
>>  gerrit-dash-creator [2] to produce a dashboard url .
>>
>>  The script prints also the queries that can be used in
>> gerrit UI
>>  directly, e.g.:
>>  Critical/High Bugs
>>  (topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421
>> OR
>>  topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100
>> OR
>>  topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790
>> OR
>>  topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678
>> OR
>>  topic:bug/1513765 OR topic:bug/1514810)
>>
>>
>>  This is the dashboard I get right now [3]
>>
>>  I tried in many ways to get Gerrit to filter patches if the
>> commit
>>  message contains a bug ID. Something like:
>>
>>  (message:"#1399249" OR message:"#1399280" OR
>> message:"#1443421" OR
>>  message:"#1453350" OR message:"#1462154" OR
>> message:"#1478100" OR
>>  message:"#1490051" OR message:"#1491131" OR
>> message:"#1498790" OR
>>  message:"#1505575" OR message:"#1505843" OR
>> message:"#1513678" OR
>>  message:"#1513765" OR message:"#1514810")
>>
>>  but it doesn't work well, the result of the filter contains
>> patches
>>  that have nothing to do with the bugs queried.
>>
>>
>> Try to drop the # and quote the bug

Re: [openstack-dev] Encouraging first-time contributors through bug tags/reviews

2015-11-25 Thread Maish Saidel-Keesing


This is an awesome idea!!!

On 11/25/15 16:15, Shamail Tahir wrote:

Hi everyone,

Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which 
discusses how one open-source project is encouraging contributions by 
new open-source contributors through a combination of a special tag 
(which is associated with work that is needed but can only be 
completed by someone who is a first-time contributor) and helpful 
comments in the review phase to ensure the contribution(s) eventually 
get merged.


While reading the article, I immediately thought about our 
low-hanging-fruit bug tag which is used for a very similar purpose in 
"bug fixing" section of  the "how to contribute" page[2].  The 
low-hanging-fruit tag is used to identify items that are generally 
suitable for first-time or beginner contributors but, in reality, 
anyone can pick them up.


I wanted to propose a new tag (or even changing the, existing, 
low-hanging fruit tag) that would identify items that we are reserving 
for first-time OpenStack contributors (e.g. a patch-set for the item 
submitted by someone who is not a first time contributor would be 
rejected)... The same article that Andrew shared mentions using an 
"up-for-grabs" tag which also populates the items at up-for-grabs[3] 
(a site where people looking to start working on open-source projects 
see entry-level items from multiple projects).  If we move forward 
with an exclusive tag for first-timers then it would be nice if we 
could use the up-for-grabs tag so that OpenStack also shows up on the 
list too.  Please let me know if this change should be proposed 
elsewhere, the tags are maintained in launchpad and the wiki I found 
related to bug tags[4] didn't indicate a procedure for submitting a 
change proposal.


Tyler Britten also suggested maybe even having a pool of reviewers who 
could monitor items being worked on that fall in this "first-timer" 
category who could further help the new contributors by helpful review 
comments and answering questions if the contributors get stuck on some 
part of the process.  Could this be the same people who helped make 
the upstream training[5] successful?  I look forward to thoughts on 
this matter.


[1] 
https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
[2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing 


[3] http://up-for-grabs.net/
[4] https://wiki.openstack.org/wiki/Bug_Tags
[5] http://docs.openstack.org/upstream-training/


--
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time


__
OpenStack Development Mailing 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,
Maish Saidel-Keesing
__
OpenStack Development Mailing 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] When to use parameters vs parameter_defaults

2015-11-25 Thread Dan Prince

On Fri, 2015-11-20 at 16:53 +0100, Jiri Tomasek wrote:
> On 11/16/2015 04:25 PM, Steven Hardy wrote:
> > Hi all,
> > 
> > I wanted to start some discussion re $subject, because it's been
> > apparrent
> > that we have a lack of clarity on this issue (and have done ever
> > since we
> > started using parameter_defaults).
> > 
> > Some context:
> > 
> > - Historically TripleO has provided a fairly comprehensive "top
> > level"
> >    parameters interface, where many per-role and common options are
> >    specified, then passed in to the respective ResourceGroups on
> > deployment
> > 
> > https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tre
> > e/overcloud-without-mergepy.yaml#n14
> > 
> > The nice thing about this approach is it gives a consistent API to
> > the
> > operator, e.g the parameters schema for the main overcloud template
> > defines
> > most of the expected inputs to the deployment.
> > 
> > The main disadvantage is a degree of template bloat, where we wire
> > dozens
> > of parameters into each ResourceGroup, and from there into whatever
> > nested
> > templates consume them.
> > 
> > - When we started adding interfaces (such as all the
> > OS::TripleO::*ExtraConfig*
> >    interfaces, there was a need to enable passing arbitrary
> > additional
> >    values to nested templates, with no way of knowing what they are
> > (e.g to
> >    enable wiring in third-party pieces we have no knowledge of or
> > which
> >    require implementation-specific arguments which don't make sense
> > for all
> >    deployments.
> > 
> > To do this, we made use of the heat parameter_defaults interface,
> > which
> > (unlike normal parameters) have global scope (visible to all nested
> > stacks,
> > without explicitly wiring in the values from the parent):
> > 
> > http://docs.openstack.org/developer/heat/template_guide/environment
> > .html#define-defaults-to-parameters
> > 
> > The nice thing about this approach is its flexibility, any
> > arbitrary
> > values can be provided without affecting the parent templates, and
> > it can
> > allow for a terser implementation because you only specify the
> > parameter
> > definition where it's actually used.
> > 
> > The main disadvantage of this approach is it becomes very much
> > harder to
> > discover an API surface for the operator, e.g the parameters that
> > must be
> > provided on deployment by any CLI/UI tools etc.  This has been
> > partially
> > addressed by the new-for-liberty nested validation heat feature,
> > but
> > there's still a bunch of unsolved complexity around how to actually
> > consume
> > that data and build a coherent consolidated API for user
> > interaction:
> > 
> > https://github.com/openstack/heat-specs/blob/master/specs/liberty/n
> > ested-validation.rst
> > 
> > My question is, where do we draw the line on when to use each
> > interface?
> > 
> > My position has always been that we should only use
> > parameter_defaults for
> > the ExtraConfig interfaces, where we cannot know what reasonable
> > parameters
> > are.  And for all other "core" functionality, we should accept the
> > increased
> > template verbosity and wire arguments in from overcloud-without-
> > mergepy.
> > 
> > However we've got some patches which fall into a grey area, e.g
> > this SSL
> > enablement patch:
> > 
> > https://review.openstack.org/#/c/231930/46/overcloud-without-mergep
> > y.yaml
> > 
> > Here we're actually removing some existing (non functional) top-
> > level
> > parameters, and moving them to parameter_defaults.
> > 
> > I can see the logic behind it, it does make the templates a bit
> > cleaner,
> > but at the expense of discoverablility of those (probably not
> > implementation dependent) parameters.
> > 
> > How do people feel about this example, and others like it, where
> > we're
> > enabling common, but not mandatory functionality?
> > 
> > In particular I'm keen to hear from Mainn and others interested in
> > building
> > UIs on top of TripleO as to which is best from that perspective,
> > and how
> > such arguments may be handled relative to the capabilities mapping
> > proposed
> > here:
> > 
> > https://review.openstack.org/#/c/242439/
> > 
> > Thanks!
> > 
> > Steve
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> I think I'll try to do a bit of a recap to make sure I understand 
> things. It may shift slightly off the topic of this thread but I
> think 
> it is worth it and it will describe what the GUI is able/expecting to
> work with.
> 
> Template defines parameters and passes them to child templates via 
> resource properties.
> Root template parameter values are set by (in order of precedence):
> 1. 'parameters' param in 'stack create' api call or 'parameters'
>

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

2015-11-25 Thread Brad Topol


Tom brings up a good point.   With a clear direction and support from the
foundation/Thierry I'm confident we can make any version of these models
work.  I know in the situation I described if the policy was clear that it
was okay and if I knew we could pull in Thierry to help resolve any
disputes then I'm comfortable we could resolve any issues with a trusting
model.   I do however hope most patches end up being reviewed by multiple
folks coming from different perspectives.  The distrust model helped force
that.  So even if we moved to a more trusting model I'm hoping we see lots
of reviews from folks coming from different perspectives and not lots of
reviews where a single perspective group think prevails.

Happy Thanksgiving!

--Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Tom Fifield 
To: openstack-dev@lists.openstack.org
Date:   11/25/2015 01:06 AM
Subject:Re: [openstack-dev] [keystone][all] Move from active
distrusting model to trusting model



On 24/11/15 19:20, Dolph Mathews wrote:
> Scenarios I've been personally involved with where the
> "distrustful" model either did help or would have helped:
>
> - Employee is reprimanded by management for not positively reviewing &
> approving a coworkers patch.
>
> - A team of employees is pressured to land a feature with as fast as
> possible. Minimal community involvement means a faster path to "merged,"
> right?
>
> - A large group of reviewers from the author's organization repeatedly
> throwing *many* careless +1s at a single patch. (These happened to not
> be cores, but it's a related organizational behavior taken to an
extreme.)
>
> I can actually think of a few more specific examples, but they are
> already described by one of the above.
>
> It's not cores that I do not trust, its the organizations they operate
> within which I have learned not to trust.

I think this is a good summary of people's fears and practical experience.

Though, It seems that those cases above are derived from not
understanding how we work, rather than out of deliberate malice. We can
fix this kind of stuff with education :)

Putting this out there - over at the Foundation, we're here to Protect
and Empower you. So, if you've ever been reprimanded by management for
choosing not to abuse the community process, perhaps we should arrange
an education session with that manager (or their manager) on how
OpenStack works.



> On Monday, November 23, 2015, Morgan Fainberg  > wrote:
>
> Hi everyone,
>
> This email is being written in the context of Keystone more than any
> other project but I strongly believe that other projects could
> benefit from a similar evaluation of the policy.
>
> Most projects have a policy that prevents the following scenario (it
> is a social policy not enforced by code):
>
> * Employee from Company A writes code
> * Other Employee from Company A reviews code
> * Third Employee from Company A reviews and approves code.
>
> This policy has a lot of history as to why it was implemented. I am
> not going to dive into the depths of this history as that is the
> past and we should be looking forward. This type of policy is an
> actively distrustful policy. With exception of a few potentially bad
> actors (again, not going to point anyone out here), most of the
> folks in the community who have been given core status on a project
> are trusted to make good decisions about code and code quality. I
> would hope that any/all of the Cores would also standup to their
> management chain if they were asked to "just push code through" if
> they didn't sincerely think it was a positive addition to the code
base.
>
> Now within Keystone, we have a fair amount of diversity of core
> reviewers, but we each have our specialities and in some cases
> (notably KeystoneAuth and even KeystoneClient) getting the required
> diversity of reviews has significantly slowed/stagnated a number of
> reviews.
>
> What I would like us to do is to move to a trustful policy. I can
> confidently say that company affiliation means very little to me
> when I was PTL and nominating someone for core. We should explore
> making a change to a trustful model, and allow for cores (regardless
> of company affiliation) review/approve code. I say this since we
> have clear steps to correct any abuses of this policy change.
>
> With all that said, here is the proposal I would like to set forth:
>
> 1. Code reviews still need 2x Core Reviewers (no change)
> 2. Code can be developed by a member of the same company as both
> core reviewers (and approvers).
> 3. If the trust that is being given via this new policy is violated,
> the code can [if

Re: [openstack-dev] [magnum]storage for docker-bootstrap

2015-11-25 Thread Daneyon Hansen (danehans)

From: 王华 >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 25, 2015 at 5:00 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [magnum]storage for docker-bootstrap

Hi all,

I am working on containerizing etcd and flannel. But I met a problem. As 
described in [1], we need a docker-bootstrap. Docker and docker-bootstrap can 
not use the same storage, so we need some disk space for it.

I reviewed [1] and I do not see where the bootstrap docker instance requires 
separate storage.

The docker in master node stores data in /dev/mapper/atomicos-docker--data and 
metadata in /dev/mapper/atomicos-docker--meta. The disk space left is too same 
for docker-bootstrap. Even if the root_gb of the instance flavor is 20G, only 
8G can be used in our image. I want to make it bigger. One way is we can add 
the disk space left in the vda as vda3 into atomicos vg after the instance 
starts and we allocate two logic volumes for docker-bootstrap. Another way is 
when we create the image, we allocate two logic volumes for docker-bootstrap. 
The second way has a advantage. It doesn't have to make filesystem when the 
instance is created which is time consuming.

What is your opinion?

Best Regards
Wanghua

[1] 
http://kubernetes.io/v1.1/docs/getting-started-guides/docker-multinode/master.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] [neutron][fwaas] No IRC meeting due to US holiday

2015-11-25 Thread Eichberger, German

In the meantime please keep reviewing the FWaaS V2 API spec - 
https://review.openstack.org/#/c/243873/7 - so we can close on that next 
Wednesday.

Thanks,
German



On 11/25/15, 6:01 AM, "Sean M. Collins"  wrote:

>We'll start again next week at the 18:30 UTC time
>-- 
>Sean M. Collins
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] When to use parameters vs parameter_defaults

2015-11-25 Thread Ben Nemec

On 11/25/2015 09:13 AM, Dan Prince wrote:
> On Fri, 2015-11-20 at 16:53 +0100, Jiri Tomasek wrote:
>> On 11/16/2015 04:25 PM, Steven Hardy wrote:
>>> Hi all,
>>>
>>> I wanted to start some discussion re $subject, because it's been
>>> apparrent
>>> that we have a lack of clarity on this issue (and have done ever
>>> since we
>>> started using parameter_defaults).
>>>
>>> Some context:
>>>
>>> - Historically TripleO has provided a fairly comprehensive "top
>>> level"
>>>parameters interface, where many per-role and common options are
>>>specified, then passed in to the respective ResourceGroups on
>>> deployment
>>>
>>> https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tre
>>> e/overcloud-without-mergepy.yaml#n14
>>>
>>> The nice thing about this approach is it gives a consistent API to
>>> the
>>> operator, e.g the parameters schema for the main overcloud template
>>> defines
>>> most of the expected inputs to the deployment.
>>>
>>> The main disadvantage is a degree of template bloat, where we wire
>>> dozens
>>> of parameters into each ResourceGroup, and from there into whatever
>>> nested
>>> templates consume them.
>>>
>>> - When we started adding interfaces (such as all the
>>> OS::TripleO::*ExtraConfig*
>>>interfaces, there was a need to enable passing arbitrary
>>> additional
>>>values to nested templates, with no way of knowing what they are
>>> (e.g to
>>>enable wiring in third-party pieces we have no knowledge of or
>>> which
>>>require implementation-specific arguments which don't make sense
>>> for all
>>>deployments.
>>>
>>> To do this, we made use of the heat parameter_defaults interface,
>>> which
>>> (unlike normal parameters) have global scope (visible to all nested
>>> stacks,
>>> without explicitly wiring in the values from the parent):
>>>
>>> http://docs.openstack.org/developer/heat/template_guide/environment
>>> .html#define-defaults-to-parameters
>>>
>>> The nice thing about this approach is its flexibility, any
>>> arbitrary
>>> values can be provided without affecting the parent templates, and
>>> it can
>>> allow for a terser implementation because you only specify the
>>> parameter
>>> definition where it's actually used.
>>>
>>> The main disadvantage of this approach is it becomes very much
>>> harder to
>>> discover an API surface for the operator, e.g the parameters that
>>> must be
>>> provided on deployment by any CLI/UI tools etc.  This has been
>>> partially
>>> addressed by the new-for-liberty nested validation heat feature,
>>> but
>>> there's still a bunch of unsolved complexity around how to actually
>>> consume
>>> that data and build a coherent consolidated API for user
>>> interaction:
>>>
>>> https://github.com/openstack/heat-specs/blob/master/specs/liberty/n
>>> ested-validation.rst
>>>
>>> My question is, where do we draw the line on when to use each
>>> interface?
>>>
>>> My position has always been that we should only use
>>> parameter_defaults for
>>> the ExtraConfig interfaces, where we cannot know what reasonable
>>> parameters
>>> are.  And for all other "core" functionality, we should accept the
>>> increased
>>> template verbosity and wire arguments in from overcloud-without-
>>> mergepy.
>>>
>>> However we've got some patches which fall into a grey area, e.g
>>> this SSL
>>> enablement patch:
>>>
>>> https://review.openstack.org/#/c/231930/46/overcloud-without-mergep
>>> y.yaml
>>>
>>> Here we're actually removing some existing (non functional) top-
>>> level
>>> parameters, and moving them to parameter_defaults.
>>>
>>> I can see the logic behind it, it does make the templates a bit
>>> cleaner,
>>> but at the expense of discoverablility of those (probably not
>>> implementation dependent) parameters.
>>>
>>> How do people feel about this example, and others like it, where
>>> we're
>>> enabling common, but not mandatory functionality?
>>>
>>> In particular I'm keen to hear from Mainn and others interested in
>>> building
>>> UIs on top of TripleO as to which is best from that perspective,
>>> and how
>>> such arguments may be handled relative to the capabilities mapping
>>> proposed
>>> here:
>>>
>>> https://review.openstack.org/#/c/242439/
>>>
>>> Thanks!
>>>
>>> Steve
>>>
>>> ___
>>> ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
>>> bscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> I think I'll try to do a bit of a recap to make sure I understand 
>> things. It may shift slightly off the topic of this thread but I
>> think 
>> it is worth it and it will describe what the GUI is able/expecting to
>> work with.
>>
>> Template defines parameters and passes them to child templates via 
>> resource properties.
>> Root template parameter values are set by (in order of precedence):
>> 1. 'parameters' param in 'stack

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

2015-11-25 Thread Brandon Logan

Sent from Nine

From: Kyle Mestery 
Sent: Nov 25, 2015 8:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon][Neutron] dashboard repository for 
neutron subprojects

On Wed, Nov 25, 2015 at 1:06 AM, Armando M. 
> wrote:

On 24 November 2015 at 21:46, Akihiro Motoki 
> wrote:
Hi,

Neutron has now various subprojects and some of them would like to
implement Horizon supports. Most of them are additional features.
I would like to start the discussion where we should have horizon support.

[Background]
Horizon team introduced a plugin mechanism and we can add horizon panels
from external repositories. Horizon team is recommending external repos for
additional services for faster iteration and features.
We have various horizon related repositories now [1].

In Neutron related world, we have neutron-lbaas-dashboard and
horizon-cisco-ui repos.

[Possible options]
There are several possible options for neutron sub-projects.
My current vote is (b), and the next is (a). It looks a good balance to me.
I would like to gather broader opinions,

(a) horizon in-tree repo
- [+] It was a legacy approach and there is no initial effort to setup a repo.
- [+] Easy to share code conventions.
- [-] it does not scale. Horizon team can be a bottleneck.

(b) a single dashboard repo for all neutron sub-projects
- [+] No need to set up a repo by each sub-project
- [+] Easier to share the code convention. Can get horizon reviewers.
- [-] who will be a core reviewer of this repo?

(c) neutron sub-project repo

All circumstances considered, I think c) is the only viable one.

+1

- [+] Each sub-project can develop a dashboard fast.
- [-] It is doable, but the directory tree can be complicated.

why? do you envision something else other than /horizon directory in the tree?

- [-] Lead to too many repos and the horizon team/liaison cannot cover all.

If that's true for horizon, shouldn't the same be true for the neutron team :)? 
IMO, the level of feedback/oversight provided is always going to be constant 
(you can't clone people) no matter how the efforts are distributed. I'd rather 
empower the individual projects.

+1000

Option C seems like the way forward here.

(d) a separate repo per neutron sub-project
Similar to (c)
- [+] A dedicate repo for dashboard simplifies the directory tree.
- [-] Need to setup a separate repo.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.

Note that this mail is not intended to move the current neutron
support in horizon
to outside of horizon tree. I would like to discuss Horizon support of
additional features.

Akihiro

[1] http://docs.openstack.org/developer/horizon/plugins.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

 I have to agree with C) as well.  I do worry about the scope of the projects 
becoming way too large though.  If this continues these projects are going to 
need to have people that are SMEs in all things OR implement something like the 
Lt system main neutron has right now.  I'm OK crossing that bridge when we get 
to it though.
__
OpenStack Development Mailing 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][nova]Move encryptors to os-brick

2015-11-25 Thread Ben Swartzlander


On 11/24/2015 03:27 PM, Nathan Reller wrote:

the cinder admin and the nova admin are ALWAYS the same people


There is interest in hybrid clouds where the Nova and Cinder services
are managed by different providers. The customer would place higher
trust in Nova because you must trust the compute service, and the
customer would place less trust in Cinder. One way to achieve this
would be to have all encryption done by Nova. Cinder would simply see
encrypted data and provide a good cheap storage solution for data.

Consider a company with sensitive data. They can run the compute nodes
themselves and offload Cinder service to some third-party service.
This way they are the only ones who can manage the machines that see
the plaintext.


If you have that level of paranoia, I suggest running LUKS inside the 
guest VM and not relying on OpenStack to handle your encryption. Then 
you don't have to worry about whether nova is sharing your keys with 
cinder because even nova won't have them.


Trying to design a system where we expect nova to do data encryption but 
not cinder will not work in the long run. The eventual result will be 
that nova will have to take on most of the functionality of cinder and 
we'll be back to the nova-volume days.


Also in case it's not obvious, if you use different providers for 
compute and storage, your performance is going to be absolutely terrible.


-Ben


-Nate

__
OpenStack Development Mailing 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]storage for docker-bootstrap

2015-11-25 Thread Hongbin Lu

Here is a bit more context.

Currently, at k8s and swarm bay, some required binaries (i.e. etcd and flannel) 
are built into image and run at host. We are exploring the possibility to 
containerize some of these system components. The rationales are (i) it is 
infeasible to build custom packages into an atomic image and (ii) it is 
infeasible to upgrade individual component. For example, if there is a bug in 
current version of flannel and we know the bug was fixed in the next version, 
we need to upgrade flannel by building a new image, which is a tedious process.

To containerize flannel, we need a second docker daemon, called 
docker-bootstrap [1]. In this setup, pods are running on the main docker 
daemon, and flannel and etcd are running on the second docker daemon. The 
reason is that flannel needs to manage the network of the main docker daemon, 
so it needs to run on a separated daemon.

Daneyon, I think it requires separated storage because it needs to run a 
separated docker daemon (unless there is a way to make two docker daemons share 
the same storage).

Wanghua, is it possible to leverage Cinder volume for that. Leveraging external 
storage is always preferred [2].

[1] 
http://kubernetes.io/v1.1/docs/getting-started-guides/docker-multinode.html#bootstrap-docker
[2] http://www.projectatomic.io/docs/docker-storage-recommendation/

Best regards,
Hongbin

From: Daneyon Hansen (danehans) [mailto:daneh...@cisco.com]
Sent: November-25-15 11:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum]storage for docker-bootstrap



From: 王华 >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 25, 2015 at 5:00 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [magnum]storage for docker-bootstrap

Hi all,

I am working on containerizing etcd and flannel. But I met a problem. As 
described in [1], we need a docker-bootstrap. Docker and docker-bootstrap can 
not use the same storage, so we need some disk space for it.

I reviewed [1] and I do not see where the bootstrap docker instance requires 
separate storage.

The docker in master node stores data in /dev/mapper/atomicos-docker--data and 
metadata in /dev/mapper/atomicos-docker--meta. The disk space left is too same 
for docker-bootstrap. Even if the root_gb of the instance flavor is 20G, only 
8G can be used in our image. I want to make it bigger. One way is we can add 
the disk space left in the vda as vda3 into atomicos vg after the instance 
starts and we allocate two logic volumes for docker-bootstrap. Another way is 
when we create the image, we allocate two logic volumes for docker-bootstrap. 
The second way has a advantage. It doesn't have to make filesystem when the 
instance is created which is time consuming.

What is your opinion?

Best Regards
Wanghua

[1] 
http://kubernetes.io/v1.1/docs/getting-started-guides/docker-multinode/master.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] [nova][neutron][upgrade] Grenade multinode partial upgrade

On 25 November 2015 at 08:42, Sean M. Collins  wrote:

> The first run for the multinode grenade job completed.
>
>
> http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/
>
> I'm still getting my bearings in the grenade log output, but if I
> understand it correctly, after upgrading Neutron, when spawning a new
> instance we do not get successful connectivity. The odd part is we see
> the failure twice. Once when upgrading Nova[1], then once when upgrading
> Cinder[2]. I would have thought Grenade would have exited after just
> failing the first time. It did do a call to worlddump.
>
> The odd part is that the first failure is a little strange - it pings
> then sleeps until it successfully gets a packet back. Which it does -
> but then it does a call to worlddump. Odd?
>
> Anyway, then it goes on to upgrade cinder, then tries to create an
> instance and ssh in, then it fails and grenade exits completely.
>
> I'll continue digging through the logs to see exactly why we don't get
> connectivity. I see some interesting warnings in the L3 agent log about
> cleaning up a non-existent router[3], which may be the culprit.
>
> [1]:
> http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_20_34_06_742
>
> [2]:
> http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_21_45_15_133
>
> [3]:
> http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING


Good stuff Sean.

A question:

if the workflow is: upgrade server first, run some connectivity tests to
then proceed to upgrading the rest to then re-run tempest, where's the log
of the new server?

All I can see is this one:

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-svc.txt.gz

And I see no restart in it.

On the subnode (compute), I only see 'old' logs.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/subnode-2/old/

Thoughts?


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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

2015-11-25 Thread Korzeniewski, Artur

I have run the multimode grenade job twice:
Failed: [1] 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/
Success: [2] 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/

The [1] failed because it couldn't ssh to VM. The connectivity issue happened 
during resource creation phase - even before upgrade.

Regards,
Artur

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Wednesday, November 25, 2015 5:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade

The first run for the multinode grenade job completed.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/

I'm still getting my bearings in the grenade log output, but if I understand it 
correctly, after upgrading Neutron, when spawning a new instance we do not get 
successful connectivity. The odd part is we see the failure twice. Once when 
upgrading Nova[1], then once when upgrading Cinder[2]. I would have thought 
Grenade would have exited after just failing the first time. It did do a call 
to worlddump.

The odd part is that the first failure is a little strange - it pings then 
sleeps until it successfully gets a packet back. Which it does - but then it 
does a call to worlddump. Odd?

Anyway, then it goes on to upgrade cinder, then tries to create an instance and 
ssh in, then it fails and grenade exits completely.

I'll continue digging through the logs to see exactly why we don't get 
connectivity. I see some interesting warnings in the L3 agent log about 
cleaning up a non-existent router[3], which may be the culprit.

[1]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_20_34_06_742

[2]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_21_45_15_133

[3]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING
--
Sean M. Collins


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

__
OpenStack Development Mailing 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] New [puppet] module for Magnum project

2015-11-25 Thread Ricardo Rocha

Hi.

We've started implementing a similar module here, i just pushed it to:
https://github.com/cernops/puppet-magnum

It already does a working magnum-api/conductor, and we'll add
configuration for additional conf options this week - to allow
alternate heat templates for the bays.

I've done some work before on puppet-ceph before and i'm happy to
start pushing patches to openstack/puppet-magnum. Is there already
something going on? I couldn't find any in:
https://review.openstack.org/#/q/status:open+project:openstack/puppet-magnum,n,z

Cheers,
  Ricardo

On Thu, Oct 29, 2015 at 4:58 PM, Potter, Nathaniel
 wrote:
> Hi Adrian,
>
>
>
> Basically it would fall under the same umbrella as all of the other
> puppet-openstack projects, which use puppet automation to configure as well
> as manage various OpenStack projects. An example of a mature one is here for
> the Cinder project: https://github.com/openstack/puppet-cinder. Right now
> there are about 35-40 such puppet modules for different projects in
> OpenStack, so one example of people who might make use of this project are
> people who have already used the existing puppet modules to set up their
> cloud and wish to incorporate Magnum into their cloud using the same tool.
>
>
>
> Thanks,
>
> Nate
>
>
>
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: Thursday, October 29, 2015 10:10 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] New [puppet] module for Magnum project
>
>
>
> Nate,
>
>
>
> On Oct 29, 2015, at 11:26 PM, Potter, Nathaniel 
> wrote:
>
>
>
> Hi everyone,
>
>
>
> I’m interested in starting up a puppet module that will handle the Magnum
> containers project. Would this be something the community might want?
> Thanks!
>
>
>
> Best,
>
> Nate Potter
>
>
>
> Can you elaborate a bit more about your concept? Who would use this? What
> function would it provide? My guess is that you are suggesting a puppet
> config for adding the Magnum service to an OpenStack cloud. Is that what you
> meant? If so, could you share a reference to an existing one that we could
> see as an example of what you had in mind?
>
>
>
> Thanks,
>
>
>
> Adrian
>
>
>
>
> __
> OpenStack Development Mailing 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] Time to increase our IRC Meetings infrastructure?

2015-11-25 Thread Ihar Hrachyshka

Thanks Tony for leading the effort. As you know, neutron-upgrades team
(well, me) actually confused -alt/-2 thing, and I registered a meeting for
-2.

I am generally for adding more channels assuming they are used wisely
(like: organizers check in advance they don’t overlap with related
initiatives), but if hygiene will do the job and give us some useful slot,
that would work fine too.

Ihar

Tony Breeds wrote:

Hello all,
I'd like you all to consider making a few changes to our IRC meeting
infrastructure

TL;DR: I think we need to add #openstack-meeting-5 and make sure people are
using it rather then per-project channels

Slightly longer version .

Capacity

I think we've reached the point in time where we need to consider adding
another meeting channel for general consumption. A very quick spot
check[1]

indicates that Mon->Thu from 14:00 -> 17:00 UTC we're at capacity.

We have 4 regular meeting channels:
#openstack-meeting, #openstack-meeting-alt, #openstack-meeting-3 and
#openstack-meeting-4.
A newly created "Cross Project" Channel
#openstack-meeting-cp, which isn't really for general consumption.

Also in the irc-meeting repo[2] we have 2 'office hours' events. which is
how

in some slots we have > 4 meetings.

I admit I don't have hard data on this but, with more projects being
added to

the big tent *and* several larger projects creating sub-teams, as an
irc-meetings reviewer it seems to be harder for people to find a slot in
one of

the official channels for meeting.

I understand that we want to keep the number of parallel meetings to a
minimum,

but is it time to add #openstack-meeting-5?

Where to hold meetings?
===

So this is loosely related to the above question in that we have a social
contract that meetings will happen in one of the regular channels. There
are

several reasons for this but they boil down to:
. Not impacting discussions with meetings and vice versa
. Limiting, where possible, number of rooms people need to be in "most of the
time"
. MeetBot only works correctly in these channels.

So while it's possible to hold a meeting in #openstack-nova it's a
deviation

form the social contract. Now it's clear that this hasn't been expressly
communicated recently. It's also clear that teams have been holding
meetings

outside of the regular channels.

Let me be clear this isn't a blamefest, no deep wrong has been committed,
no
one set out cause problems and if any problems were caused they were
minimal.

Having acknowledged that, It'd be great if we could move these meetings
back to

the regular places, and include them on the eavesdrop home page. These
meetings are serving their portion of the community well so they're going
to

move the disruption should be minimal.

I just wanted to:
. Remind people about the social contract of where to hold a meeting
. Add an additional data point to the capacity discussion.

Also I'm looking at adding code to MeetBot to add a warning when running
meetings outside of the regular channels to encourage the move.

Confusion
=
So this is really quite trivial. As you can see above we don't have an
#openstack-meeting-2 channel the ...-alt is clearly that, but still
people are
confused. How would people feel about creating #openstack-meeting-2 and
making

it redirect to #openstack-meeting-alt?

Yours Tony.

[1]
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit?usp=sharing

[2] http://git.openstack.org/cgit/openstack-infra/irc-meetings
__
OpenStack Development Mailing 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: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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] how to add/list drivers @ https://www.openstack.org/marketplace/drivers/

2015-11-25 Thread Neil Jerram

That reminds me of a follow-on question, as I added my driver's data to
the driverlog project a few weeks ago [1]: when does the content at
https://www.openstack.org/marketplace/drivers/ get rebuilt?

Thanks,
Neil

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


On 25/11/15 09:42, Ilya Shakhat wrote:
> Community-maintained list of drivers exists within the project
> DriverLog. The UI is available
> at http://stackalytics.com/report/driverlog , it has all options to
> filter the data.
>
>
> Thanks,
> Ilya
>
> 2015-11-25 11:48 GMT+03:00 Mohan Kumar  >:
>
> Hi Team,
>
>  In the following link, i can see only some vendor plug-ins, not
> all is listed here! ..
>
>  https://www.openstack.org/marketplace/drivers/
>
> So [1]  what is the criteria to get a vendor plug-in listed on
> this page? [2]  where can i see the supported vendor
> plugins/drivers for a given Openstack release (specfically Liberty) ??
>
> Thanks.,
> Mohankumar.N
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [Ironic][Neutron] Testing of Ironic/Neutron integration on devstack

2015-11-25 Thread Vasyl Saienko

Hello Community,

As you know Ironic/Neutron integration is planned in Mitaka. And at the
moment we don't have any CI that will test it. Unfortunately we can't test
Ironic/Neutron integration on HW as we don't have it.
So probably the best way is to develop ML2 driver that will work with OVS.

At the moment we have a PoC [1] of ML2 driver that works with Cisco and OVS
on linux.
Also we have some patches to devstack that allows to try Ironic/Neutron
integration on VM and real HW. And quick guide how to test it locally [0]

https://review.openstack.org/#/c/247513/
https://review.openstack.org/#/c/248048/
https://review.openstack.org/#/c/249717/
https://review.openstack.org/#/c/248074/

I'm interested in Neutron/Ironic integration. It would be great if we have
it in Mitaka.
I'm asking Community to check [0] and [1] and share your thoughts.

 Also I would like to request a repo on openstack.org for [1]


[0]
https://github.com/jumpojoy/ironic-neutron/blob/master/devstack/examples/ironic-neutron-vm.md
[1] https://github.com/jumpojoy/generic_switch

--
Sincerely
Vasyl Saienko
__
OpenStack Development Mailing 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] [Horizon][Access and Security] ICMP type, ICMP code 'ValidationError' query

2015-11-25 Thread Suraj Deshmukh

While inputing 'ICMP type' and 'ICMP code' at [1], validation is done
which raises 'ValidationError', at [2] so if validation fails
corresponding value is set to None. Then why is ValidationError raised
again in [3]. Where is 'ValidationError' at [3] caught?



[1] 
openstack_dashboard/dashboards/project/access_and_security/security_groups/forms.py
[1] 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/security_groups/forms.py#L180
[2] horizon/utils/validators.py -> validate_port_range()
[2] 
https://github.com/openstack/horizon/blob/master/horizon/utils/validators.py#L26
[3] 
openstack_dashboard/dashboards/project/access_and_security/security_groups/forms.py
-> AddRule._clean_rule_icmp
[3] 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/security_groups/forms.py#L293

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

[openstack-dev] [ironic] Releases and things

2015-11-25 Thread Jim Rollenhagen

Hi all,

We're approaching OpenStack's M-1 milestone, and as we have lots of good
stuff in the master branch, and no Mitaka release yet, I'd like to make
a release next Thursday, December 3.

First, I've caught us up (best I can tell) on missing release notes
since our last release. Please do review them:
https://review.openstack.org/#/c/250029/

Second, please make sure when writing and reviewing code, that we are
adding release notes for anything significant, including important bug
fixes. See the patch above for examples on things that could be
candidates for the release notes. Basically, if you think it's something
a deployer or operator might care about, we should have a note for it.

How to make a release note:
http://docs.openstack.org/developer/reno/usage.html

Last, I'd love if cores could help test the master branch and try to
dislodge any issues there, and also try to find any existing bug reports
that feel like they should definitely be fixed before the release.

I've got a small list of patches I'd like to see land before the
release:

* https://review.openstack.org/#/c/250029 - the release notes I
  mentioned earlier. Obviously required before release. :)

* https://review.openstack.org/#/c/249912 - fixes an issue with sample
  config generation, and updates the generated config

* https://review.openstack.org/#/c/235493 - completes the blueprint for
  agent-image-proxy; not a blocker for release but would be cool if it
  landed.

Feel free to reply with others that you think are a must-have.

Also, as a note, I'll be on vacation from (approximately) now until
December 7. Devananda has graciously agreed to manage this release for us.
If there's anything that absolutely needs my attention, him and some
other cores have ways to reach me. Otherwise, I'll pop in here and there
but consider me gone until the 7th. :)

After going through the commit log to build the release notes patch, I
think we've done a lot of great work since the 4.2 release. Thank you
all for that. Let's keep pushing hard on our priority list and have an
amazing rest of the cycle! :D

// jim

__
OpenStack Development Mailing 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] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Alessandro Pilotti

Hi Angus,

First thanks for your concern on code portability! It still happens that we 
have to ask to revert patches on Oslo projects due to some Linux specific code 
that we discover only when the actual Oslo modules are used by Nova, Neutron, 
Cinder or other projects. Typically a running Windows CI suddenly turns red on 
every patch and that’s how we get to find out. We’re working on adding many 
more projects under Windows CI tests, so at some point all the relevant Oslo 
ones will be covered and we’ll be able to prevent those situations before the 
code gets merged.

What about preparing some basic integration tests for oslo.privsep that we 
could add to our Windows CI infrastructure? This would give you peace of mind 
during development on Linux without needing to test manually all your patches 
on Windows, knowing that the Windows CI will give an error if the patch 
contains non portable code (or code that doesn’t behave as expected).

Alessandro

From: Angus Lees >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday 26 November 2015 at 01:56
To: Claudiu Belu 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

So I spent a day yesterday trying to get to the point where I could just run a 
no-change "tox" successfully on windows.  Unfortunately I gave up when I 
realised I still had several days of downloading+building things ahead of me 
and clearly I was doing it the hard way :(

Could you point me to the "dev environment how-to" doc for hyper-v work?  I'm 
thinking of something like 
http://docs.openstack.org/developer/nova/development.environment.html#setup 
with simple cut+paste instructions for the totally-windows-clueless like me ;)  
Or perhaps a pre-prepared disk image, if the Microsoft license allows such a 
thing.  In particular, the details on https://wiki.openstack.org/wiki/Hyper-V 
look out of date (Grizzly, and several 
docs.openstack.org links are broken), and the links 
to things like 
https://cloudbase.it/hyper-v-nova-compute-installer-unattended-setup/ look like 
deployment rather than development environments (?).

In particular, I think(?) I should be careful *not* to install too much of a 
cygwin-style environment, since I think(?) that might no longer be 
representative of the environment in which hyper-v is expected to operate.  If 
I'm wrong, and cygwin/msys is ok, then it looks like there are several 
free-software-on-windows "distributions" that would make life a whole lot 
simpler (by frankly being less like Windows).  Some guidance from people who 
understand the issues here would be appreciated.

 - Gus

On Tue, 24 Nov 2015 at 22:01 Claudiu Belu 
> wrote:
Hello,

Thanks Dims for raising the concern and Angus for reaching out. :)

Most of the time, python development on Windows is not too far off from Linux. 
But the two systems are quite different, which imply different modules (fcntl, 
pwd, grp modules do not exist in Windows) or different implementations of some 
modules (multiprocessing uses Popen instead of os.fork, os module is quite 
different) or some socket options and signals are different in Windows.

1.a. As I've said earlier, some modules do not exist in Windows. All, or at 
least most standard modules document the fact that they are strictly for Linux. 
[1][2][3]
b. At the very least, running the unit tests in a Windows environment can at 
least detect simple problems (e.g. imports). Secondly, there is a Hyper-V / 
Windows CI running on some of the OpenStack projects (nova, neutron, 
networking_hyperv, cinder) that can be checked before merging.

2. This is a bit more complicated question. Well, for functions, you could have 
separate modules for Linux specific functions and Windows specific functions. 
This has been done before: [4] As for object-oriented implementations, I'd 
suggest having the system-specific calls be done in private methods, which will 
be overriden by Windows / Linux subclasses with their specific implementations. 
We've done something like this before, but solutions were pretty much 
straight-forward; it might not be as simple for oslo_privsep, since it is very 
Linux-specific.

3. Typically, the OpenStack services on Hyper-V / Windows are run with users 
that have enough privileges to do their job. For example, the nova-compute 
service is run with a user that has Hyper-V Admin privileges and is not 
necessarily in the "Administrator" user group. We haven't used rootwrap in our 
usecases, it is disabled by default, plus, oslo.rootwrap imports pwd, which 
doesn't

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

2015-11-25 Thread Cathy Zhang

 I have some questions on option (c) and would like to make sure we are on the 
same page.

Thanks,
Cathy


(c) neutron sub-project repo
- [+] Each sub-project can develop a dashboard fast.
- [-] It is doable, but the directory tree can be complicated.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.
If we work in the same mode as we do DevStack plugins today, that is inside the 
sub-projects repo, the number of repos should be equal to the number of 
sub-projects. Also, this simplifies the packaging and allow each subproject 
owners to take ownership of the code. Guidance from Horizon folks will be 
appreciated to help the interested people get started. Question is: does 
Horizon plugin follow the same model as Neutron plugins like all the code is 
part of Horizon umbrella? If yes, then this might not be the ideal option.

Cathy> Thanks Akihiro for starting this discussion. +1 for the idea of doing 
this within each sub-project repo since its functionality is closely associated 
with the other code patches of the sub-project. Networking-sfc has already 
developed a Horizon dashboard in Horizon tree, but we got suggestion from 
Horizon team to move the code to the separate project repo. We are interested 
in trying this approach in the network-sfc project. Since this is a new way to 
add Horizon plugin, we would like to get guidance from Horizon folks. Is 
Horizon folks OK for this option and will give each Neutron sub-project the 
needed support? I think  Fawad raised a good question here. Does the Horizon 
code in each Neutron sub-project repo a part of Horizon umbrella? Do we need to 
get Horizon team’s approval for the code merge? If so, it comes back to the 
issue of how we can ensure faster iteration?



(d) a separate repo per neutron sub-project
Similar to (c)
- [+] A dedicate repo for dashboard simplifies the directory tree.
- [-] Need to setup a separate repo.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.
 Agree


Note that this mail is not intended to move the current neutron
support in horizon
to outside of horizon tree. I would like to discuss Horizon support of
additional features.

Akihiro

[1] http://docs.openstack.org/developer/horizon/plugins.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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On 25 November 2015 at 09:49, Sean M. Collins  wrote:

> Yeah looks like I read it wrong - the failure occurred during the
> initial resource creation phase, based on comparing the logs that Artur
> posted.
>

I see. I got confused by this:

http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/logs/testr_results.html.gz

Look at the timestamp, it's from 2 days ago.

These must be files that are stale from runs that happened before this node
got reused? That's rude...


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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

2015-11-25 Thread Korzeniewski, Artur

Yes, this file is complete fine. The Grenade is running smoke test before 
resource creation.
The workflow is like this:
1. Install old devstack on main and subnode 
2. Run tempest smoke
3. Create resources
4. Verify resources
5. Shutdown the services
6. Verify if shutdown does not affect the resources
7. Spin new devstack on main node, subnode stays in old version without any 
touch.
8. Upgrade the services - start the new code on main node
9. Run tempest smoke tests on upgraded main node - it in theory should validate 
if we are cross-version compatible (N and N+1)
10. Verify resources
11. Shutdown

The successful steps are in log:
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/logs/grenade.sh.summary.txt.gz

Regards,
Artur

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Wednesday, November 25, 2015 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade

On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> On 25 November 2015 at 09:49, Sean M. Collins  wrote:
> 
> > Yeah looks like I read it wrong - the failure occurred during the 
> > initial resource creation phase, based on comparing the logs that 
> > Artur posted.
> >
> 
> I see. I got confused by this:
> 
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-
> neutron-multinode/bf6bae1/logs/testr_results.html.gz
> 
> Look at the timestamp, it's from 2 days ago.

No, that's correct. It's just taken me 2 days to get around to writing an 
e-mail about all this :)

--
Sean M. Collins

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

__
OpenStack Development Mailing 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][infra][bugs] Grafana Dashboard for Bugs

2015-11-25 Thread Paul Belanger

On Tue, Nov 24, 2015 at 04:20:26PM +0100, Markus Zoeller wrote:
> Background
> ==
> We have "grafana" for data visualization [1] and I'd like to introduce
> a dashboard which shows data from our bug tracker Launchpad. Based on
> ttx's code [2] for the "bugsquashing day stats" [3] I created a PoC 
> (screenshot at [4]). The code which collects the data from Launchpad 
> and pushes it into a statsd deamon is available at [5]*. Thanks to 
> jeblair who showed me all the necessary pieces. I have chosen the
> following namespace hierarchy for the metrics for statsd:
> 
> Metrics
>   |- stats
>|- gauges
> |- launchpad
>  |- bugs
>   |- nova
>|- new-by-tag
>|- not-in-progress-by-importance
>|- open-by-importance
>|- open-by-status
> 
> The two reasons I've chosen it this way are:
> 1) specify "launchpad" in case we will have multiple issue trackers
>at the same time and want to differ between those two
> 2) specify "nova" to seperate between the OpenStack projects
> 
> The code [5] I've written doesn't care about project specifics and can 
> be used for the other projects (Neutron, Cinder, Glance, ...) as well
> without any changes. Only the "config.js" file has to be changed if
> a project wants to opt in.
> 
> Open points
> ===
> * Any feedback if the data [4] I've chosen would be helpfull to you?
>
This is way cool! After we talked the other day, I started thinking more about
this. At first I didn't understand what you wanted to do, but after thinking
about it more and seeing the graph you produced this is very powerful.

> * Which OpenStack project has the right scope for the code [5]?
>
I'm sure -infra is a good home for it.  However, there could be some integration
with stackalytics too, since it is already hitting launchpad and scraping stats.

> * I still have to create a grafyaml [6] file for that. I've build the
>   PoC dashboard with grafana's GUI.
>
Count me in to help :)
> * I haven't yet run the code for the novaclient project, that's why
>   there is a "N/A" in the screenshot.
> * I would need an infra-contact who would help me to have this script
>   executed repeatedly in a (tbd) interval (30mins?).
> 
I don't mind helping with the infra bit, shouldn't be hard to find a node to put
this one.

> References
> ==
> [1] http://grafana.openstack.org/
> [2] 
> http://git.openstack.org/cgit/openstack-infra/bugdaystats/tree/bugdaystats.py
> [3] http://status.openstack.org/bugday/
> [4] Screenshort of the PoC nova bugs dashboard (expires on 2015-12-20):
> http://www.tiikoni.com/tis/view/?id=7f3f191
> [5] https://gist.github.com/anonymous/4368eb69059f11286fe9
> [6] http://docs.openstack.org/infra/grafyaml/
> 
> Footnotes
> =
> * you can set ``target="syso"`` to print the data to the stdout without 
>   the need to have a statsd deamon running
> 
> 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 Development Mailing 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] docker module replacement

2015-11-25 Thread Steven Dake (stdake)

Hey folks,

I understand there is some contention over whether we should make our own 
docker module to deal with the fact that upstream is continually busted.

The short answer is yes, I fully support our own docker module with some 
caveats:

The long answer is:
I would like the module to be compatible from a docker module perspective as it 
relates to Ansible integration.
We are not waiting until Ansible 2.0 to unpin from docker 1.8.2.
I want the code quality to be good, so I would appreciate thoughtful reviews of 
the docker module Sam has started on.
The code may NOT be based upon a fork of the existing code for licensing 
reasons (GPLV3 incompatibility).  It doesn't have to be cleanroom, but it does 
have to be our own body of work.
If upstream Ansible + docker ever get their act together, we will go back to 
using upstream.  If not, not. :)

I am not blaming anyone from Ansible or Docker for these problems.  Software 
integration is the hardest job on the planet as it relates to engineering, 
which is why the world is swiftly moving to full-blown CI to resolve these 
problems.  I know this isn't entirely the upstream way.  We should be fixing 
these things in upstream.  And we do actually do  that!  The problem is Ansible 
1.9.4 is the last release of Ansible 1.9, and Ansible, being a 50 person 
company, can't maintain two individual versions of Ansible.  So we are really 
doing this as a pragmatic factor of the environment in which we operate.

Hope that clears up my position.

Regards,
-steve
__
OpenStack Development Mailing 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] Using docker container to run COE daemons

2015-11-25 Thread Kai Qiang Wu

Hi Jay,

For the Kubernetes  COE container ways, I think @Hua Wang is doing that.

For the swarm COE, the swarm already has master and agent running in
container

For the mesos, it still not have container work until now, Maybe someone
already draft bp on it ?   Not quite sure



Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Jay Lau 
To: OpenStack Development Mailing List

Date:   26/11/2015 07:15 am
Subject:[openstack-dev] [magnum] Using docker container to run COE
daemons



Hi,

It is becoming more and more popular to use docker container run some
applications, so what about leveraging this in Magnum?

What I want to do is that we can put all COE daemons running in docker
containers, because now Kubernetes, Mesos and Swarm support running in
docker container and there are already some existing docker
images/dockerfiles which we can leverage.

So what about update all COE templates to use docker container to run COE
daemons and maintain some dockerfiles for different COEs in Magnum? This
can reduce the maintain effort for COE as if there are new versions and we
want to upgrade, just update the dockerfile is enough. Comments?

--
Thanks,

Jay Lau (Guangya Liu)
__
OpenStack Development Mailing 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] [magnum] Using docker container to run COE daemons

2015-11-25 Thread Jay Lau

Hi,

It is becoming more and more popular to use docker container run some
applications, so what about leveraging this in Magnum?

What I want to do is that we can put all COE daemons running in docker
containers, because now Kubernetes, Mesos and Swarm support running in
docker container and there are already some existing docker
images/dockerfiles which we can leverage.

So what about update all COE templates to use docker container to run COE
daemons and maintain some dockerfiles for different COEs in Magnum? This
can reduce the maintain effort for COE as if there are new versions and we
want to upgrade, just update the dockerfile is enough. Comments?

-- 
Thanks,

Jay Lau (Guangya Liu)
__
OpenStack Development Mailing 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] [Murano] 'NoMatchingFunctionException: No function "#operator_." matches supplied arguments' error when adding an application to an environment

2015-11-25 Thread Stan Lagun

Vahid,

The files you attached doesn't look like a YAML at all

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Wed, Nov 25, 2015 at 10:21 PM, Vahid S Hashemian <
vahidhashem...@us.ibm.com> wrote:

> Kate, Serg,
>
> Thank you very much for your quick responses.
>
> I am attaching the requested yaml file.
>
> For Hot2 plugin, the only difference with hot_package.py is that I changed
> the UI translation version to 2.2 and removed predefined_fields in
> _translate_ui_parameters method.
> The ui.yaml file is attached.
>
>
>
> The CSAR plugin is a work in progress. For example, the workflow method is
> not yet implemented.
> The ui.yaml file is attached.
>
>
> I'd like to make sure the issue is not on my side before I open a bug, as
> Kate suggested.
>
> If necessary, I can also send you the plugin python code.
>
> Thanks.
>
> Regards,
> --Vahid
>
>
>
>
> From:Serg Melikyan 
> To:"OpenStack Development Mailing List (not for usage questions)"
> 
> Date:11/25/2015 03:29 AM
> Subject:Re: [openstack-dev] [Murano]
> 'NoMatchingFunctionException: No function "#operator_." matches supplied
> arguments' error when adding an application to an environment
> --
>
>
>
> Hi Vahid,
>
> you can find generated UI definitions for the package here:
> /tmp/muranodashboard-cache/apps/.../ui/ui.yaml
>
> On Wed, Nov 25, 2015 at 12:54 PM, Ekaterina Chernova
>  wrote:
> >
> > Hi Vahid,
> >
> > Forms are rended after app is added to the environment in accordance
> with the UI definition.
> > UI definition contains yaql expressions and one of your expression is
> incorrect.
> > Please, share UI yaml so we can find out what's the problem.
> > You can also create a bug that it's not obvious which expression is
> failed.
> >
> >
> > Also, make sure that you have valid YAQL version installed (should
> correspond to the version in requirements.txt)
> > And you can ask for help in #murano channel.
> >
> > Regards,
> > Kate.
> >
> >
> > On Wed, Nov 25, 2015 at 4:39 AM, Vahid S Hashemian <
> vahidhashem...@us.ibm.com> wrote:
> >>
> >> Hi,
> >>
> >> I am working on the TOSCA CSAR plugin for murano and so far am able to
> successfully import an application definition archive of my CSAR example to
> murano.
> >> However, when I try to add the imported application to an environment I
> get this error from Murano Dashboard:
> >>
> >> DEBUG:muranodashboard.common.cache:Using cached value from
> /tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
> >> DEBUG:muranodashboard.catalog.views:Clearing forms data for application
> io.murano.apps.generated.CsarHelloWorld.
> >> DEBUG:muranodashboard.catalog.views:Clearing any leftover wizard step
> data.
> >> DEBUG:muranodashboard.common.cache:Using cached value from
> /tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/ui/ui.yaml.
> >> DEBUG:muranodashboard.common.cache:Using cached value from
> /tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
> >> DEBUG:muranodashboard.dynamic_ui.services:Using data {} for app
> io.murano.apps.generated.CsarHelloWorld
> >> DEBUG:muranodashboard.dynamic_ui.services:Using in-memory forms for app
> io.murano.apps.generated.CsarHelloWorld
> >> DEBUG:muranodashboard.common.cache:Using cached value from
> /tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/ui/ui.yaml.
> >> DEBUG:muranodashboard.common.cache:Using cached value from
> /tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
> >> DEBUG:muranodashboard.dynamic_ui.services:Using data {} for app
> io.murano.apps.generated.CsarHelloWorld
> >> DEBUG:muranodashboard.dynamic_ui.services:Using in-memory forms for app
> io.murano.apps.generated.CsarHelloWorld
> >> INFO:muranodashboard.dynamic_ui.forms:Creating form workflowManagement
> >> INFO:muranodashboard.dynamic_ui.forms:Creating form group0
> >> DEBUG:muranodashboard.api:Murano::Client http://localhost:8082/>
> >> DEBUG:muranoclient.common.http:curl -i -X GET -H 'X-Auth-Token:
> 324759651d234c4eaf08f6093dfd7000' -H 'Content-Type: application/json' -H
> 'User-Agent: python-muranoclient'
> http://localhost:8082//v1/catalog/packages/914c2bfd5d504419a94a9affb7af809a
> >> DEBUG:muranoclient.common.http:
> >> HTTP/1.1 200 OK
> >> Date: Wed, 25 Nov 2015 01:31:12 GMT
> >> Connection: keep-alive
> >> Content-Type: application/json
> >> Content-Length: 560
> >> X-Openstack-Request-Id: req-b6759ab2-04b4-4882-ac95-3ac06f970cb5
> >>
> >> {"updated": "2015-11-24T23:28:52", "description": "Template for
> deploying a single server with predefined properties.", "tags":
> ["TOSCA-CSAR-generated"], "class_definitions":
> ["io.murano.apps.generated.CsarHelloWorld"], "is_public": false, "id":
> "914c2bfd5d504419a94a9affb7af809a", "categories": [], "name":
> "csar_hello_world", "created":

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

So I spent a day yesterday trying to get to the point where I could just
run a no-change "tox" successfully on windows.  Unfortunately I gave up
when I realised I still had several days of downloading+building things
ahead of me and clearly I was doing it the hard way :(

Could you point me to the "dev environment how-to" doc for hyper-v work?
I'm thinking of something like
http://docs.openstack.org/developer/nova/development.environment.html#setup
with
simple cut+paste instructions for the totally-windows-clueless like me ;)
 Or perhaps a pre-prepared disk image, if the Microsoft license allows such
a thing.  In particular, the details on
https://wiki.openstack.org/wiki/Hyper-V look out of date (Grizzly, and
several docs.openstack.org links are broken), and the links to things like
https://cloudbase.it/hyper-v-nova-compute-installer-unattended-setup/ look
like deployment rather than development environments (?).

In particular, I think(?) I should be careful *not* to install too much of
a cygwin-style environment, since I think(?) that might no longer be
representative of the environment in which hyper-v is expected to operate.
If I'm wrong, and cygwin/msys is ok, then it looks like there are several
free-software-on-windows "distributions" that would make life a whole lot
simpler (by frankly being less like Windows).  Some guidance from people
who understand the issues here would be appreciated.

 - Gus

On Tue, 24 Nov 2015 at 22:01 Claudiu Belu 
wrote:

> Hello,
>
> Thanks Dims for raising the concern and Angus for reaching out. :)
>
> Most of the time, python development on Windows is not too far off from
> Linux. But the two systems are quite different, which imply different
> modules (fcntl, pwd, grp modules do not exist in Windows) or different
> implementations of some modules (multiprocessing uses Popen instead of
> os.fork, os module is quite different) or some socket options and signals
> are different in Windows.
>
> 1.a. As I've said earlier, some modules do not exist in Windows. All, or
> at least most standard modules document the fact that they are strictly for
> Linux. [1][2][3]
> b. At the very least, running the unit tests in a Windows environment can
> at least detect simple problems (e.g. imports). Secondly, there is a
> Hyper-V / Windows CI running on some of the OpenStack projects (nova,
> neutron, networking_hyperv, cinder) that can be checked before merging.
>
> 2. This is a bit more complicated question. Well, for functions, you could
> have separate modules for Linux specific functions and Windows specific
> functions. This has been done before: [4] As for object-oriented
> implementations, I'd suggest having the system-specific calls be done in
> private methods, which will be overriden by Windows / Linux subclasses with
> their specific implementations. We've done something like this before, but
> solutions were pretty much straight-forward; it might not be as simple for
> oslo_privsep, since it is very Linux-specific.
>
> 3. Typically, the OpenStack services on Hyper-V / Windows are run with
> users that have enough privileges to do their job. For example, the
> nova-compute service is run with a user that has Hyper-V Admin privileges
> and is not necessarily in the "Administrator" user group. We haven't used
> rootwrap in our usecases, it is disabled by default, plus, oslo.rootwrap
> imports pwd, which doesn't exist in Windows.
>
> [1] https://docs.python.org/2/library/fcntl.html
> [2] https://docs.python.org/2/library/pwd.html
> [3] https://docs.python.org/2/library/grp.html
> [4]
> https://github.com/openstack/neutron/blob/master/neutron/agent/common/utils.py
> [5]
> https://github.com/openstack/oslo.rootwrap/blob/master/oslo_rootwrap/wrapper.py#L19
>
> If you have any further questions, feel free to ask. :)
>
> Best regards,
> Claudiu Belu
>
>
> --
> *From:* Angus Lees [g...@inodes.org]
> *Sent:* Tuesday, November 24, 2015 6:18 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> Claudiu Belu
> *Subject:* [hyper-v] oslo.privsep vs Windows
>
> Dims has just raised[1] the excellent concern that oslo.privsep will need
> to at least survive on Windows, because hyper-v.  I have no real experience
> coding on windows (I wrote a windows C program once, but I only ever ran it
> under wine ;) and certainly none within an OpenStack/python context:
>
> 1) How can I test whatever I'm working on to see if I have mistakenly
> introduced something Linux-specific?  Surely this is a challenge common
> across every project in the nova/oslo/hyper-v stack.
>
> 2) What predicate should I use to guard the inevitable Linux-specific or
> Windows-specific code branches?
>
> and I guess:
> 3) What does a typical OpenStack/hyper-v install even look like? Do we run
> rootwrap with some sudo-like-thing, or just run everything as the superuser?
> What _should_ oslo.privsep do for this environment?
>
> [1]

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Alessandro Pilotti

Angus,

"I'm afraid this has to be easy for me or I'm just not going to be able to 
sustain the effort required :-/ )"

What a tragedy, I’m s sorry that life is so terribly bitter and requires 
some effort to support people with views different from yours! :-)

Just kidding, we’re here to help, but we obviously won’t do your work. Given 
that Oslo code needs to be portable, I was just trying to give you some 
alternative that doesn’t require you to do useless manual work during 
development.

1) Unit tests are not the answer, as hopefully they mock out most significant 
underlying OS features. Sure, you will catch the basic issues, like importing a 
module that doesn’t exist on Windows, but you cannot rely on them as a proof of 
portability.
2) Integration testing on the other side provide by definition a proof of 
reliability on the target system (in the limits of the tests coverage at least) 
and CI testing needs eventually to be there on Windows as well for 
oslo.. This is obvious not a way to develop, but a 
“guard”, against issues. In other words, regardless of your opinion on Windows, 
the Windows CI needs to be there, why not adding it now for this project?

Getting to development practices, when designing features, hopefully 
portability gets evaluated _before_ starting coding, so you should not need too 
many manual runs on every platform before being confident enough to send a 
patch to Gerrit and wait for CI results. And for that you don’t need tox or 
anything fancy, just a Python environment and some very basic OS skills.

When in doubt, an option is to drop by on #openstack-hyper-v and ask. But take 
care, you might find open minded people, make sure you're at ease with this. ;-)

Alessandro

From: Angus Lees >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday 26 November 2015 at 03:23
To: "OpenStack Development Mailing List (not for usage questions)" 
>, 
Claudiu Belu >
Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

Thanks for the suggestion, and having a CI bot running on oslo.privsep would be 
a good thing once the basic code works on Windows - I would have expected it to 
be already running on all oslo projects (that the hyper-v hypervisor does/might 
depend on) tbh.

But that's a clumsy way to actually develop something.  I _know_ privsep won't 
work currently on windows (imports pwd/grp for starters), and having to add 
print statements + submit + push-to-gerrit + wait for a CI bot + dig through CI 
bot logs + repeat is a pretty terrible workflow ;-)

(I already have very little empathy for anyone choosing to run Windows just to 
provide yet-another-x86-hypervisor when far easier alternatives are available, 
and I won't donate a disproportionate amount of my time to a well-funded 
company who has historically actively undermined the intellectual commons when 
_I_ have far more rewarding alternatives available.  I'm afraid this has to be 
easy for me or I'm just not going to be able to sustain the effort required :-/ 
)

 - Gus

On Thu, 26 Nov 2015 at 11:56 Alessandro Pilotti 
> wrote:
Hi Angus,

First thanks for your concern on code portability! It still happens that we 
have to ask to revert patches on Oslo projects due to some Linux specific code 
that we discover only when the actual Oslo modules are used by Nova, Neutron, 
Cinder or other projects. Typically a running Windows CI suddenly turns red on 
every patch and that’s how we get to find out. We’re working on adding many 
more projects under Windows CI tests, so at some point all the relevant Oslo 
ones will be covered and we’ll be able to prevent those situations before the 
code gets merged.

What about preparing some basic integration tests for oslo.privsep that we 
could add to our Windows CI infrastructure? This would give you peace of mind 
during development on Linux without needing to test manually all your patches 
on Windows, knowing that the Windows CI will give an error if the patch 
contains non portable code (or code that doesn’t behave as expected).

Alessandro

From: Angus Lees >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday 26 November 2015 at 01:56
To: Claudiu Belu 
>, "OpenStack 
Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

So I spent a day yesterday

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Tony Breeds

On Thu, Nov 26, 2015 at 02:11:01AM +, Alessandro Pilotti wrote:
> Angus,
> 
> "I'm afraid this has to be easy for me or I'm just not going to be able to 
> sustain the effort required :-/ )"
> 
> What a tragedy, I’m s sorry that life is so terribly bitter and requires 
> some effort to support people with views different from yours! :-)

CI has it's place, unit tests have their place, local development has it's 
place.  No on suggested otherwise.

Can you develop in CI, sure is it a great experience? In my opinion no.

Anyway, I think this is heading off track and I'd like to try and steer it back
to the problem at hand.

There are 2 simple questions:
 1. How does one setup an python development environment that is as close as
possible to the environment that hyper-v runs in.
 2. Are the details captured in an easy to locate document for developers?

Yours Tony.

pgpKQIwtFpgui.pgp
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] [hyper-v] oslo.privsep vs Windows

So seriously - how do you set up a dev environment for hyper-v?
It doesn't have to be written up all nice and pretty, just a 30s outline in
an email would be really useful :-/

 - Gus

On Thu, 26 Nov 2015 at 13:13 Alessandro Pilotti <
apilo...@cloudbasesolutions.com> wrote:

> Angus,
>
> "I'm afraid this has to be easy for me or I'm just not going to be able to
> sustain the effort required :-/ )"
>
> What a tragedy, I’m s sorry that life is so terribly bitter and
> requires some effort to support people with views different from yours! :-)
>
> Just kidding, we’re here to help, but we obviously won’t do your work.
> Given that Oslo code needs to be portable, I was just trying to give you
> some alternative that doesn’t require you to do useless manual work during
> development.
>
> 1) Unit tests are not the answer, as hopefully they mock out most
> significant underlying OS features. Sure, you will catch the basic issues,
> like importing a module that doesn’t exist on Windows, but you cannot rely
> on them as a proof of portability.
> 2) Integration testing on the other side provide by definition a proof of
> reliability on the target system (in the limits of the tests coverage at
> least) and CI testing needs eventually to be there on Windows as well for
> oslo.. This is obvious not a way to develop, but a
> “guard”, against issues. In other words, regardless of your opinion on
> Windows, the Windows CI needs to be there, why not adding it now for this
> project?
>
> Getting to development practices, when designing features, hopefully
> portability gets evaluated _before_ starting coding, so you should not need
> too many manual runs on every platform before being confident enough to
> send a patch to Gerrit and wait for CI results. And for that you don’t need
> tox or anything fancy, just a Python environment and some very basic OS
> skills.
>
> When in doubt, an option is to drop by on #openstack-hyper-v and ask. But
> take care, you might find open minded people, make sure you're at ease with
> this. ;-)
>
> Alessandro
>
>
> From: Angus Lees 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday 26 November 2015 at 03:23
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, Claudiu Belu <
> cb...@cloudbasesolutions.com>
>
> Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows
>
> Thanks for the suggestion, and having a CI bot running on oslo.privsep
> would be a good thing once the basic code works on Windows - I would have
> expected it to be already running on all oslo projects (that the hyper-v
> hypervisor does/might depend on) tbh.
>
> But that's a clumsy way to actually develop something.  I _know_ privsep
> won't work currently on windows (imports pwd/grp for starters), and having
> to add print statements + submit + push-to-gerrit + wait for a CI bot + dig
> through CI bot logs + repeat is a pretty terrible workflow ;-)
>
> (I already have very little empathy for anyone choosing to run Windows
> just to provide yet-another-x86-hypervisor when far easier alternatives are
> available, and I won't donate a disproportionate amount of my time to a
> well-funded company who has historically actively undermined the
> intellectual commons when _I_ have far more rewarding alternatives
> available.  I'm afraid this has to be easy for me or I'm just not going to
> be able to sustain the effort required :-/ )
>
>
>  - Gus
>
> On Thu, 26 Nov 2015 at 11:56 Alessandro Pilotti <
> apilo...@cloudbasesolutions.com> wrote:
>
>> Hi Angus,
>>
>> First thanks for your concern on code portability! It still happens that
>> we have to ask to revert patches on Oslo projects due to some Linux
>> specific code that we discover only when the actual Oslo modules are used
>> by Nova, Neutron, Cinder or other projects. Typically a running Windows CI
>> suddenly turns red on every patch and that’s how we get to find out. We’re
>> working on adding many more projects under Windows CI tests, so at some
>> point all the relevant Oslo ones will be covered and we’ll be able to
>> prevent those situations before the code gets merged.
>>
>> What about preparing some basic integration tests for oslo.privsep that
>> we could add to our Windows CI infrastructure? This would give you peace of
>> mind during development on Linux without needing to test manually all your
>> patches on Windows, knowing that the Windows CI will give an error if the
>> patch contains non portable code (or code that doesn’t behave as expected).
>>
>> Alessandro
>>
>>
>>
>> From: Angus Lees 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday 26 November 2015 at 01:56
>> To: Claudiu Belu , "OpenStack Development
>> Mailing List (not for usage questions)" <
>>

Re: [openstack-dev] [kolla] docker module replacement

2015-11-25 Thread Sam Yaple

Point of clarification, Brian Coca (bcoca) confirmed there _will_ be an
ansible 1.9.5 to me the other day. So we will be unblocked at some point
for Docker 1.8.2. Unfortunately the module is broken with v1 registry past
Docker 1.8.2.

That said here are my issues:
* its been 4 weeks since we fixed the bug upstream, we still don't have
a consumable version of ansible with the fix
* waiting on new features to propagate through Docker and docker-py
then we must wait on ansible to implement/merge a PR for the new features
and THEN we must wait for a new ansible tag. At that point our new minimum
requirement is the latest version of ansible. Hopefully it doesn't have any
bugs
* it has been said that because the v1 registry is deprecated so the
ansible  Docker module won't do anything to make that work (and its broken
with the upstream module). The local v2 registry is orders of magnitude
slower than a local v1. This is a big deal for us and its this type of
issue that makes me think we need our own module long term. We can't have
another project dictating such a crucial piece of our project and
development

In the case of liberty, while we can unpin 1.8.2, who is to say 1.9.3 won't
be broken for the same reason? Requiring later versions of ansible for
fixes here won't work long term.

I'm open to solutions that solve my concerns above without requiring a
module in our control.
On Nov 25, 2015 5:55 PM, "Steven Dake (stdake)"  wrote:

> Hey folks,
>
> I understand there is some contention over whether we should make our own
> docker module to deal with the fact that upstream is continually busted.
>
> The short answer is yes, I fully support our own docker module with some
> caveats:
>
> The long answer is:
> I would like the module to be compatible from a docker module perspective
> as it relates to Ansible integration.
> We are not waiting until Ansible 2.0 to unpin from docker 1.8.2.
> I want the code quality to be good, so I would appreciate thoughtful
> reviews of the docker module Sam has started on.
> The code may NOT be based upon a fork of the existing code for licensing
> reasons (GPLV3 incompatibility).  It doesn't have to be cleanroom, but it
> does have to be our own body of work.
> If upstream Ansible + docker ever get their act together, we will go back
> to using upstream.  If not, not. :)
>
> I am not blaming anyone from Ansible or Docker for these problems.
> Software integration is the hardest job on the planet as it relates to
> engineering, which is why the world is swiftly moving to full-blown CI to
> resolve these problems.  I know this isn't entirely the upstream way.  We
> should be fixing these things in upstream.  And we do actually do  that!
> The problem is Ansible 1.9.4 is the last release of Ansible 1.9, and
> Ansible, being a 50 person company, can't maintain two individual versions
> of Ansible.  So we are really doing this as a pragmatic factor of the
> environment in which we operate.
>
> Hope that clears up my position.
>
> Regards,
> -steve
>
> __
> OpenStack Development Mailing 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] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Robert Collins

On 26 November 2015 at 15:54, Alessandro Pilotti
 wrote:
> Basic Python development does not really differ too much on Windows compared
> to Linux.
>
> Let’s start with the Python environment. I’d recommend to install a 2.7
> (x86) one and a 3.4 (x64) one:
>
> https://www.python.org/ftp/python/2.7.10/python-2.7.10.msi
> https://www.python.org/ftp/python/3.4.3/python-3.4.3.amd64.msi
>
> Download also git for Windows: https://git-scm.com/download/win
> Git works in the same way, so nothing particular to add. Just take care of
> the line endings. I usually keep them all in LF, avoiding CRLF, others let
> git do the conversion.
>
> When done, open a PowerShell or command prompt and set your PATH and
> PYTHONPATH e.g.:
>
> $ENV:PATH += ";C:\Python27;C:\Python27\Scripts"
> $ENV:PYTHONPATH = "."
>
> From here is pretty standard Python, e.g.:
>
> pip install “blah>=1.0.0"
> pip install –r requirements.txt
>
> python yourmodule.py
>
> For running tests you can use for example nose since tox / testr don’t
> really work:
>
> pip install mock
> pip install nose
> nosetests .

i haven't seen any bug reports on testrepository vis-a-vis windows;
please do file them, otherwise I'll presume it works.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [hyper-v] oslo.privsep vs Windows

Thanks for the suggestion, and having a CI bot running on oslo.privsep
would be a good thing once the basic code works on Windows - I would have
expected it to be already running on all oslo projects (that the hyper-v
hypervisor does/might depend on) tbh.

But that's a clumsy way to actually develop something.  I _know_ privsep
won't work currently on windows (imports pwd/grp for starters), and having
to add print statements + submit + push-to-gerrit + wait for a CI bot + dig
through CI bot logs + repeat is a pretty terrible workflow ;-)

(I already have very little empathy for anyone choosing to run Windows just
to provide yet-another-x86-hypervisor when far easier alternatives are
available, and I won't donate a disproportionate amount of my time to a
well-funded company who has historically actively undermined the
intellectual commons when _I_ have far more rewarding alternatives
available.  I'm afraid this has to be easy for me or I'm just not going to
be able to sustain the effort required :-/ )

 - Gus

On Thu, 26 Nov 2015 at 11:56 Alessandro Pilotti <
apilo...@cloudbasesolutions.com> wrote:

> Hi Angus,
>
> First thanks for your concern on code portability! It still happens that
> we have to ask to revert patches on Oslo projects due to some Linux
> specific code that we discover only when the actual Oslo modules are used
> by Nova, Neutron, Cinder or other projects. Typically a running Windows CI
> suddenly turns red on every patch and that’s how we get to find out. We’re
> working on adding many more projects under Windows CI tests, so at some
> point all the relevant Oslo ones will be covered and we’ll be able to
> prevent those situations before the code gets merged.
>
> What about preparing some basic integration tests for oslo.privsep that we
> could add to our Windows CI infrastructure? This would give you peace of
> mind during development on Linux without needing to test manually all your
> patches on Windows, knowing that the Windows CI will give an error if the
> patch contains non portable code (or code that doesn’t behave as expected).
>
> Alessandro
>
>
>
> From: Angus Lees 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday 26 November 2015 at 01:56
> To: Claudiu Belu , "OpenStack Development
> Mailing List (not for usage questions)"  >
> Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows
>
> So I spent a day yesterday trying to get to the point where I could just
> run a no-change "tox" successfully on windows.  Unfortunately I gave up
> when I realised I still had several days of downloading+building things
> ahead of me and clearly I was doing it the hard way :(
>
> Could you point me to the "dev environment how-to" doc for hyper-v work?
> I'm thinking of something like
> http://docs.openstack.org/developer/nova/development.environment.html#setup 
> with
> simple cut+paste instructions for the totally-windows-clueless like me ;)
>  Or perhaps a pre-prepared disk image, if the Microsoft license allows such
> a thing.  In particular, the details on
> https://wiki.openstack.org/wiki/Hyper-V look out of date (Grizzly, and
> several docs.openstack.org links are broken), and the links to things
> like https://cloudbase.it/hyper-v-nova-compute-installer-unattended-setup/ 
> look
> like deployment rather than development environments (?).
>
> In particular, I think(?) I should be careful *not* to install too much of
> a cygwin-style environment, since I think(?) that might no longer be
> representative of the environment in which hyper-v is expected to operate.
> If I'm wrong, and cygwin/msys is ok, then it looks like there are several
> free-software-on-windows "distributions" that would make life a whole lot
> simpler (by frankly being less like Windows).  Some guidance from people
> who understand the issues here would be appreciated.
>
>  - Gus
>
> On Tue, 24 Nov 2015 at 22:01 Claudiu Belu 
> wrote:
>
>> Hello,
>>
>> Thanks Dims for raising the concern and Angus for reaching out. :)
>>
>> Most of the time, python development on Windows is not too far off from
>> Linux. But the two systems are quite different, which imply different
>> modules (fcntl, pwd, grp modules do not exist in Windows) or different
>> implementations of some modules (multiprocessing uses Popen instead of
>> os.fork, os module is quite different) or some socket options and signals
>> are different in Windows.
>>
>> 1.a. As I've said earlier, some modules do not exist in Windows. All, or
>> at least most standard modules document the fact that they are strictly for
>> Linux. [1][2][3]
>> b. At the very least, running the unit tests in a Windows environment can
>> at least detect simple problems (e.g. imports). Secondly, there is a
>> Hyper-V / Windows CI running on some of the OpenStack projects (nova,
>> neutron,

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Alessandro Pilotti

Basic Python development does not really differ too much on Windows compared to 
Linux.

Let’s start with the Python environment. I’d recommend to install a 2.7 (x86) 
one and a 3.4 (x64) one:

https://www.python.org/ftp/python/2.7.10/python-2.7.10.msi
https://www.python.org/ftp/python/3.4.3/python-3.4.3.amd64.msi

Download also git for Windows: https://git-scm.com/download/win
Git works in the same way, so nothing particular to add. Just take care of the 
line endings. I usually keep them all in LF, avoiding CRLF, others let git do 
the conversion.

When done, open a PowerShell or command prompt and set your PATH and PYTHONPATH 
e.g.:

$ENV:PATH += ";C:\Python27;C:\Python27\Scripts"
$ENV:PYTHONPATH = "."

From here is pretty standard Python, e.g.:

pip install “blah>=1.0.0"
pip install –r requirements.txt

python yourmodule.py

For running tests you can use for example nose since tox / testr don’t really 
work:

pip install mock
pip install nose
nosetests .

Note: you can also use virtualenvs, exactly like on Linux.

You might incur in occasional native modules that require a C development 
environment. That’s usually more complicated as it requires also dependencies 
and needs C/C++ skills and either Mingw / mingw64 or Visual Studio 2008 (Python 
2.7) or 2010 (Python 3.4).
For those few modules there are typically binary wheels available, either on 
Pypi or provided by 3rd parties. If not, just ask, we compile them from source 
and have wheels in the CI.

What you can optionally do, to get a Python environment pre-loaded with all the 
OpenStack dependencies is to install the OpenStack Hyper-V Compute MSI (see 
http://cloudbase.it) and use the Python env that comes with it.

If you need a basic working OpenStack, just get a standard Devstack running in 
a Linux host or VM plus the above MSI for Hyper-V configured to point to the 
DevStack node. There’s plenty of examples on our blog for similar cases  
(http://cloudbase.it/blog).

It terms of editors it’s a matter of personal taste, but you can find e.g. 
Sublime, Visual Studio Code, Notepad++ or Atom as very good and lightweight 
options.

Let me know if this works for you and if you have any other questions.

Alessandro

From: Angus Lees >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday 26 November 2015 at 04:22
To: "OpenStack Development Mailing List (not for usage questions)" 
>, 
Claudiu Belu >
Subject: Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

So seriously - how do you set up a dev environment for hyper-v?
It doesn't have to be written up all nice and pretty, just a 30s outline in an 
email would be really useful :-/

 - Gus

On Thu, 26 Nov 2015 at 13:13 Alessandro Pilotti 
> wrote:
Angus,

"I'm afraid this has to be easy for me or I'm just not going to be able to 
sustain the effort required :-/ )"

What a tragedy, I’m s sorry that life is so terribly bitter and requires 
some effort to support people with views different from yours! :-)

Just kidding, we’re here to help, but we obviously won’t do your work. Given 
that Oslo code needs to be portable, I was just trying to give you some 
alternative that doesn’t require you to do useless manual work during 
development.

1) Unit tests are not the answer, as hopefully they mock out most significant 
underlying OS features. Sure, you will catch the basic issues, like importing a 
module that doesn’t exist on Windows, but you cannot rely on them as a proof of 
portability.
2) Integration testing on the other side provide by definition a proof of 
reliability on the target system (in the limits of the tests coverage at least) 
and CI testing needs eventually to be there on Windows as well for 
oslo.. This is obvious not a way to develop, but a 
“guard”, against issues. In other words, regardless of your opinion on Windows, 
the Windows CI needs to be there, why not adding it now for this project?

Getting to development practices, when designing features, hopefully 
portability gets evaluated _before_ starting coding, so you should not need too 
many manual runs on every platform before being confident enough to send a 
patch to Gerrit and wait for CI results. And for that you don’t need tox or 
anything fancy, just a Python environment and some very basic OS skills.

When in doubt, an option is to drop by on #openstack-hyper-v and ask. But take 
care, you might find open minded people, make sure you're at ease with this. ;-)

Alessandro

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

[openstack-dev] [oslo] fake driver doesn't work with multi topics

2015-11-25 Thread Masahito MUROI

Hi oslo.message folks,

We are trying to use oslo_message's fake driver [1] for our testing.
However, the driver doesn't seem to work with multi topics. Is this
behavior expected or a bug?

best regard,
Masahito


-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699



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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On Wed, Nov 25, 2015 at 12:29:49PM EST, Korzeniewski, Artur wrote:
> I have run the multimode grenade job twice:
> Failed: [1] 
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/
> Success: [2] 
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/
> 
> The [1] failed because it couldn't ssh to VM. The connectivity issue happened 
> during resource creation phase - even before upgrade.
> 

Ah - now that I've got a log of a successful run, I can see that my
run had the same issue as your failed run - we didn't even get to the
upgrade phase - we failed on the initial resource creation phase, since
my new/ directories were totally empty except for localrc.
-- 
Sean M. Collins

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

Re: [openstack-dev] Encouraging first-time contributors through bug tags/reviews

Excerpts from Shamail Tahir's message of 2015-11-25 09:15:54 -0500:
> Hi everyone,
> 
> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which
> discusses how one open-source project is encouraging contributions by new
> open-source contributors through a combination of a special tag (which is
> associated with work that is needed but can only be completed by someone
> who is a first-time contributor) and helpful comments in the review phase
> to ensure the contribution(s) eventually get merged.
> 
> While reading the article, I immediately thought about our
> low-hanging-fruit bug tag which is used for a very similar purpose in "bug
> fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit
> tag is used to identify items that are generally suitable for first-time or
> beginner contributors but, in reality, anyone can pick them up.
> 
> I wanted to propose a new tag (or even changing the, existing, low-hanging
> fruit tag) that would identify items that we are reserving for first-time
> OpenStack contributors (e.g. a patch-set for the item submitted by someone
> who is not a first time contributor would be rejected)... The same article
> that Andrew shared mentions using an "up-for-grabs" tag which also
> populates the items at up-for-grabs[3] (a site where people looking to
> start working on open-source projects see entry-level items from multiple
> projects).  If we move forward with an exclusive tag for first-timers then
> it would be nice if we could use the up-for-grabs tag so that OpenStack
> also shows up on the list too.  Please let me know if this change should be
> proposed elsewhere, the tags are maintained in launchpad and the wiki I
> found related to bug tags[4] didn't indicate a procedure for submitting a
> change proposal.

I like the idea of making bugs suitable for first-timers more
discoverable. I'm not sure we need to *reserve* any bugs for any class
of contributor. What benefit do you think that provides?

> 
> Tyler Britten also suggested maybe even having a pool of reviewers who
> could monitor items being worked on that fall in this "first-timer"
> category who could further help the new contributors by helpful review
> comments and answering questions if the contributors get stuck on some part
> of the process.  Could this be the same people who helped make the upstream
> training[5] successful?  I look forward to thoughts on this matter.

If we have volunteers willing to do this, that's great. It's not
obvious, but it is actually possible to query gerrit for reviews
from first-time contributors. A bot A watches for new patches leaves
a comment on any for which the submitter has not previously submitted
a patch. Querying for open reviews with comments from that bot is
straightforward once you know its gerrit id. For example, this URL
will show all open patches from first-time contributors submitted
to any repository:

https://review.openstack.org/#/q/reviewer:10068+is:open,n,z

Doug

> 
> [1] https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
> [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
> 
> [3] http://up-for-grabs.net/
> [4] https://wiki.openstack.org/wiki/Bug_Tags
> [5] http://docs.openstack.org/upstream-training/
> 

__
OpenStack Development Mailing 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] Encouraging first-time contributors through bug tags/reviews

2015-11-25 Thread Anthony Chow

Have a tag for first time contributor is a great idea.

On the other hand we should not take out the "low hanging fruit" tag.  I
contribute to OpenStack on my spare time and in my current situation I can
only work on the low hanging fruits.  If the first time tag is replacing
the low hanging fruit then it will be more difficult for me to find bugs
that I can work on.

Thanks and everyone (in the U.S.) have a Happy Thanksgiving,

anthony.

On Wed, Nov 25, 2015 at 9:06 AM, Maish Saidel-Keesing 
wrote:

> This is an awesome idea!!!
>
> On 11/25/15 16:15, Shamail Tahir wrote:
>
> Hi everyone,
>
> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which
> discusses how one open-source project is encouraging contributions by new
> open-source contributors through a combination of a special tag (which is
> associated with work that is needed but can only be completed by someone
> who is a first-time contributor) and helpful comments in the review phase
> to ensure the contribution(s) eventually get merged.
>
> While reading the article, I immediately thought about our
> low-hanging-fruit bug tag which is used for a very similar purpose in "bug
> fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit
> tag is used to identify items that are generally suitable for first-time or
> beginner contributors but, in reality, anyone can pick them up.
>
> I wanted to propose a new tag (or even changing the, existing, low-hanging
> fruit tag) that would identify items that we are reserving for first-time
> OpenStack contributors (e.g. a patch-set for the item submitted by someone
> who is not a first time contributor would be rejected)... The same article
> that Andrew shared mentions using an "up-for-grabs" tag which also
> populates the items at up-for-grabs[3] (a site where people looking to
> start working on open-source projects see entry-level items from multiple
> projects).  If we move forward with an exclusive tag for first-timers then
> it would be nice if we could use the up-for-grabs tag so that OpenStack
> also shows up on the list too.  Please let me know if this change should be
> proposed elsewhere, the tags are maintained in launchpad and the wiki I
> found related to bug tags[4] didn't indicate a procedure for submitting a
> change proposal.
>
> Tyler Britten also suggested maybe even having a pool of reviewers who
> could monitor items being worked on that fall in this "first-timer"
> category who could further help the new contributors by helpful review
> comments and answering questions if the contributors get stuck on some part
> of the process.  Could this be the same people who helped make the upstream
> training[5] successful?  I look forward to thoughts on this matter.
>
> [1]
> https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
> [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
> 
> [3] http://up-for-grabs.net/
> [4] https://wiki.openstack.org/wiki/Bug_Tags
> [5] http://docs.openstack.org/upstream-training/
>
>
> --
> Thanks,
> Shamail Tahir
> t: @ShamailXD
> tz: Eastern Time
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Best Regards,
> Maish Saidel-Keesing
>
> __
> OpenStack Development Mailing 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] [gnocchi][rating] Issues regarding gnocchi support in CloudKitty

2015-11-25 Thread Julien Danjou

On Wed, Nov 25 2015, Stéphane Albert wrote:

Hi Stéphane,

> We can't directly query gnocchi resource indexer for a specific resource
> revision. Let me explain it, if you want to search for every instances
> active for a specific timeframe you'll get a result but the revision
> will be the latest, even if it's after the timeframe you requested. If
> you add resource revision to the request you'll get an empty request if
> it doesn't match the latest version. We can't add history to the request
> as we'll have more than one response when we only need latest revision
> for the timeframe. One workaround is to first do a request to query
> every active instance and then do a query for every instance with
> history filtering on UUID and revision and limiting to one result. It's
> suboptimal as it requires many requests to get the correct information.

You really need to put actual data and request examples in your
explications, as it's really hard to follow you. Best way is to describe
what you have, what you do, what you get and what you would expect.
But I think I see what you mean, and it should be just a few API call
option to add. Best thing would be to open a bug with the details I just
mentioned.

> The other problem we are having is when requesting measures. Let me
> first tell you how CloudKitty is collecting data to set the context.
> We've got a collection period (default 3600 seconds), every period we
> query the backend for a specific timeframe (start = last collection,
> stop = last + period). If we're missing data we restart from where we
> stopped, which can be pretty far in the past.
> We're using gnocchi as ceilometer's storage and by default it's pretty
> hard to exploit data stored. If we request data too far in the past that
> is using a higher granularity than our collection period then we got an
> empty dataset from gnocchi. It's pretty ambiguous as we don't know if
> it's because there is no data, or because our timeframe is too short.
> That means we need to query for the archive policy and find what should
> be the minimum granularity for the period. In some way it's normal to no
> get data because gnocchi is unable to provide accurate data for this
> period, but at least get information that we are requesting too
> precisely. Or send us the data, since we've got the timestamp and
> the granularity, we can easily detect that the result is not accurate
> and decide what we should do.

If you specify only the timeframe and no granularity, it should send to
you all it got for this timeframe. Isn't that good enough for you?

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


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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On 25 November 2015 at 10:15, Korzeniewski, Artur <
artur.korzeniew...@intel.com> wrote:

> Yes, this file is complete fine. The Grenade is running smoke test before
> resource creation.
> The workflow is like this:
> 1. Install old devstack on main and subnode
> 2. Run tempest smoke
> 3. Create resources
> 4. Verify resources
> 5. Shutdown the services
> 6. Verify if shutdown does not affect the resources
> 7. Spin new devstack on main node, subnode stays in old version without
> any touch.
> 8. Upgrade the services - start the new code on main node
> 9. Run tempest smoke tests on upgraded main node - it in theory should
> validate if we are cross-version compatible (N and N+1)
> 10. Verify resources
> 11. Shutdown
>

Thanks Artur, now it's clear...I can see the right versions etc. Having a
good run to compare with helps a lot!

>
> The successful steps are in log:
>
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/logs/grenade.sh.summary.txt.gz
>
>
>
> Regards,
> Artur
>
> -Original Message-
> From: Sean M. Collins [mailto:s...@coreitpro.com]
> Sent: Wednesday, November 25, 2015 7:03 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode
> partial upgrade
>
> On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> > On 25 November 2015 at 09:49, Sean M. Collins 
> wrote:
> >
> > > Yeah looks like I read it wrong - the failure occurred during the
> > > initial resource creation phase, based on comparing the logs that
> > > Artur posted.
> > >
> >
> > I see. I got confused by this:
> >
> > http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-
> > neutron-multinode/bf6bae1/logs/testr_results.html.gz
> >
> > Look at the timestamp, it's from 2 days ago.
>
> No, that's correct. It's just taken me 2 days to get around to writing an
> e-mail about all this :)
>
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing 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] [Murano] 'NoMatchingFunctionException: No function "#operator_." matches supplied arguments' error when adding an application to an environment

2015-11-25 Thread Vahid S Hashemian

Kate, Serg,

Thank you very much for your quick responses.

I am attaching the requested yaml file.

For Hot2 plugin, the only difference with hot_package.py is that I changed 
the UI translation version to 2.2 and removed predefined_fields in 
_translate_ui_parameters method.
The ui.yaml file is attached.



The CSAR plugin is a work in progress. For example, the workflow method is 
not yet implemented.
The ui.yaml file is attached.


I'd like to make sure the issue is not on my side before I open a bug, as 
Kate suggested.

If necessary, I can also send you the plugin python code.

Thanks.

Regards,
--Vahid




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

Date:   11/25/2015 03:29 AM
Subject:Re: [openstack-dev] [Murano] 'NoMatchingFunctionException: 
No function "#operator_." matches supplied arguments' error when adding an 
application to an environment



Hi Vahid,

you can find generated UI definitions for the package here:
/tmp/muranodashboard-cache/apps/.../ui/ui.yaml

On Wed, Nov 25, 2015 at 12:54 PM, Ekaterina Chernova
 wrote:
>
> Hi Vahid,
>
> Forms are rended after app is added to the environment in accordance 
with the UI definition.
> UI definition contains yaql expressions and one of your expression is 
incorrect.
> Please, share UI yaml so we can find out what's the problem.
> You can also create a bug that it's not obvious which expression is 
failed.
>
>
> Also, make sure that you have valid YAQL version installed (should 
correspond to the version in requirements.txt)
> And you can ask for help in #murano channel.
>
> Regards,
> Kate.
>
>
> On Wed, Nov 25, 2015 at 4:39 AM, Vahid S Hashemian 
 wrote:
>>
>> Hi,
>>
>> I am working on the TOSCA CSAR plugin for murano and so far am able to 
successfully import an application definition archive of my CSAR example 
to murano.
>> However, when I try to add the imported application to an environment I 
get this error from Murano Dashboard:
>>
>> DEBUG:muranodashboard.common.cache:Using cached value from 
/tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
>> DEBUG:muranodashboard.catalog.views:Clearing forms data for application 
io.murano.apps.generated.CsarHelloWorld.
>> DEBUG:muranodashboard.catalog.views:Clearing any leftover wizard step 
data.
>> DEBUG:muranodashboard.common.cache:Using cached value from 
/tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/ui/ui.yaml.
>> DEBUG:muranodashboard.common.cache:Using cached value from 
/tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
>> DEBUG:muranodashboard.dynamic_ui.services:Using data {} for app 
io.murano.apps.generated.CsarHelloWorld
>> DEBUG:muranodashboard.dynamic_ui.services:Using in-memory forms for app 
io.murano.apps.generated.CsarHelloWorld
>> DEBUG:muranodashboard.common.cache:Using cached value from 
/tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/ui/ui.yaml.
>> DEBUG:muranodashboard.common.cache:Using cached value from 
/tmp/muranodashboard-cache/apps/91/4c2bfd5d504419a94a9affb7af809a/package_fqn.
>> DEBUG:muranodashboard.dynamic_ui.services:Using data {} for app 
io.murano.apps.generated.CsarHelloWorld
>> DEBUG:muranodashboard.dynamic_ui.services:Using in-memory forms for app 
io.murano.apps.generated.CsarHelloWorld
>> INFO:muranodashboard.dynamic_ui.forms:Creating form workflowManagement
>> INFO:muranodashboard.dynamic_ui.forms:Creating form group0
>> DEBUG:muranodashboard.api:Murano::Client http://localhost:8082/>
>> DEBUG:muranoclient.common.http:curl -i -X GET -H 'X-Auth-Token: 
324759651d234c4eaf08f6093dfd7000' -H 'Content-Type: application/json' -H 
'User-Agent: python-muranoclient' 
http://localhost:8082//v1/catalog/packages/914c2bfd5d504419a94a9affb7af809a

>> DEBUG:muranoclient.common.http:
>> HTTP/1.1 200 OK
>> Date: Wed, 25 Nov 2015 01:31:12 GMT
>> Connection: keep-alive
>> Content-Type: application/json
>> Content-Length: 560
>> X-Openstack-Request-Id: req-b6759ab2-04b4-4882-ac95-3ac06f970cb5
>>
>> {"updated": "2015-11-24T23:28:52", "description": "Template for 
deploying a single server with predefined properties.", "tags": 
["TOSCA-CSAR-generated"], "class_definitions": 
["io.murano.apps.generated.CsarHelloWorld"], "is_public": false, "id": 
"914c2bfd5d504419a94a9affb7af809a", "categories": [], "name": 
"csar_hello_world", "created": "2015-11-24T23:28:52", "author": "OASIS 
TOSCA TC", "enabled": true, "supplier": {}, "fully_qualified_name": 
"io.murano.apps.generated.CsarHelloWorld", "type": "Application", 
"owner_id": "1fee909728c54a698c96f0f7853412ae"}
>>
>> DEBUG:muranoclient.common.http:curl -i -X GET -H 'X-Auth-Token: 
324759651d234c4eaf08f6093dfd7000' -H 'Content-Type: application/json' -H 
'User-Agent: python-muranoclient' 
http://localhost:8082//v1/environments/b8d83a0b6fde465ab9de013f084518d4
>>

[openstack-dev] [gnocchi][rating] Issues regarding gnocchi support in CloudKitty

2015-11-25 Thread Stéphane Albert

Hi,

We've started implementing gnocchi support in CloudKitty. But we're
facing some issues. Some problems where client sided and are now fixed,
but for some others it might doing wrong requests or not using gnocchi's
full potential.

Here are some problems we're actually facing:

We can't directly query gnocchi resource indexer for a specific resource
revision. Let me explain it, if you want to search for every instances
active for a specific timeframe you'll get a result but the revision
will be the latest, even if it's after the timeframe you requested. If
you add resource revision to the request you'll get an empty request if
it doesn't match the latest version. We can't add history to the request
as we'll have more than one response when we only need latest revision
for the timeframe. One workaround is to first do a request to query
every active instance and then do a query for every instance with
history filtering on UUID and revision and limiting to one result. It's
suboptimal as it requires many requests to get the correct information.


The other problem we are having is when requesting measures. Let me
first tell you how CloudKitty is collecting data to set the context.
We've got a collection period (default 3600 seconds), every period we
query the backend for a specific timeframe (start = last collection,
stop = last + period). If we're missing data we restart from where we
stopped, which can be pretty far in the past.
We're using gnocchi as ceilometer's storage and by default it's pretty
hard to exploit data stored. If we request data too far in the past that
is using a higher granularity than our collection period then we got an
empty dataset from gnocchi. It's pretty ambiguous as we don't know if
it's because there is no data, or because our timeframe is too short.
That means we need to query for the archive policy and find what should
be the minimum granularity for the period. In some way it's normal to no
get data because gnocchi is unable to provide accurate data for this
period, but at least get information that we are requesting too
precisely. Or send us the data, since we've got the timestamp and
the granularity, we can easily detect that the result is not accurate
and decide what we should do.

Sorry for the wall of text, and thanks to people that took time to read
it.

BTW, we're available in #cloudkitty channel. You can reach me on most
openstack channels too, I'm in UTC+1 timezone.

Hoping we can find a solution and ship gnocchi support in the next
CloudKitty version, which is pretty much ready.

Cheers

Stéphane Albert   -  05 82 95 65 36
Objectif Libre  www.objectif-libre.com
Infrastructure et Formations Linux

__
OpenStack Development Mailing 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] [searchlight] [release] Searchlight client launchpad project

2015-11-25 Thread Tripp, Travis S

Hello all,

We have started building out the python client and OpenStack client plugin for 
Searchlight. We’ve now encountered the question of whether or not to manage the 
client change tracking through another Launchpad project specific to the client 
[2] or continue to manage it through the current Searchlight launchpad project 
[3]. It seems that with some of the recent changes that Doug has been sending 
out regarding the release notes process [4] that perhaps having another 
launchpad project to manage is not necessary anymore.

The dedicated project gives us somewhere to track releases of the client 
independently, but it also means yet another place to go to try to track 
everything. With the current launchpad project, the client repo, the specs 
repo, the release notes process, it is starting to feel like a lot to manage 
for what is still a small project. My preference would be to try to keep it as 
simple as possible. However, we do want to ensure that we have setup the 
process management toolchain to best support us now and in the future.

So, I’m asking for input on whether or not we should start using the new 
launchpad searchlight client project or just manage bugs and BPs in the main 
searchlight project.

Thank you!
Travis

[1] https://review.openstack.org/#/c/247565/
[2] https://launchpad.net/python-searchlightclient
[3] https://launchpad.net/searchlight
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.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] [nova][neutron][upgrade] Grenade multinode partial upgrade

2015-11-25 Thread Korzeniewski, Artur

From what I understand – the Sean case did not get to upgrade [1]– it has ended 
after creating the VM and trying to ping/ssh it.
So we do not have restart logs of q-agt and no logs in new [2]

The subnode will have only ‘old’ logs because the grenade multimode scenario 
assumes that subnode will not be upgraded – that’s why we will be able to test 
RPC versioning new server talking to old compute/q-agt version.

[1] 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.summary.txt.gz
[2] 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/new/

For sanity I’m attaching my runs of multimode grenade job:

Failed the same way Sean’s one: 
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/

Success:  
http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/

Regards,
Artur

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, November 25, 2015 6:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial 
upgrade



On 25 November 2015 at 08:42, Sean M. Collins 
> wrote:
The first run for the multinode grenade job completed.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/

I'm still getting my bearings in the grenade log output, but if I
understand it correctly, after upgrading Neutron, when spawning a new
instance we do not get successful connectivity. The odd part is we see
the failure twice. Once when upgrading Nova[1], then once when upgrading
Cinder[2]. I would have thought Grenade would have exited after just
failing the first time. It did do a call to worlddump.

The odd part is that the first failure is a little strange - it pings
then sleeps until it successfully gets a packet back. Which it does -
but then it does a call to worlddump. Odd?

Anyway, then it goes on to upgrade cinder, then tries to create an
instance and ssh in, then it fails and grenade exits completely.

I'll continue digging through the logs to see exactly why we don't get
connectivity. I see some interesting warnings in the L3 agent log about
cleaning up a non-existent router[3], which may be the culprit.

[1]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_20_34_06_742

[2]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/grenade.sh.txt.gz#_2015-11-23_21_45_15_133

[3]: 
http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-l3.txt.gz?level=WARNING

Good stuff Sean.

A question:

if the workflow is: upgrade server first, run some connectivity tests to then 
proceed to upgrading the rest to then re-run tempest, where's the log of the 
new server?

All I can see is this one:

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/old/screen-q-svc.txt.gz

And I see no restart in it.

On the subnode (compute), I only see 'old' logs.

http://logs.openstack.org/35/187235/11/experimental/gate-grenade-dsvm-neutron-multinode/011124b/logs/subnode-2/old/

Thoughts?


--
Sean M. Collins


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

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> On 25 November 2015 at 09:49, Sean M. Collins  wrote:
> 
> > Yeah looks like I read it wrong - the failure occurred during the
> > initial resource creation phase, based on comparing the logs that Artur
> > posted.
> >
> 
> I see. I got confused by this:
> 
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/logs/testr_results.html.gz
> 
> Look at the timestamp, it's from 2 days ago.

No, that's correct. It's just taken me 2 days to get around to writing an e-mail
about all this :)

-- 
Sean M. Collins

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

[openstack-dev] [release] better linting of release notes

We noticed today that I left out a setting in the original instructions
I sent to explain how to configure reno.

We want to ensure that the release notes render properly and without
warnings, and to do that we need to turn on the option to Sphinx
to treat warnings as errors by adding "-W" to the sphinx-build line
in tox.ini. I've submitted sample patches to glance[1] and neutron[2].

Note that the neutron patch won't pass the build right now, so some
of the notes will have to be edited first, and you might see similar
effects in your project.

Doug

[1] https://review.openstack.org/249976
[2] https://review.openstack.org/249973

__
OpenStack Development Mailing 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-18, Nov 30 - Dec 4

Focus
-

R-18 is the Mitaka 1 milestone deadline. All projects following the
cycle-with-milestones release model should be preparing for the
milestone tag.

Release Actions
---

All deliverables must have reno configured before adding a Mitaka 1
milestone tag.

We will be using the openstack/releases repository to manage the
Mitaka 1 milestone tags. Prepare the information you will need to
request the tag, including the SHA of the commit to be tagged.

As a one-time change, we are also going to simplify how we specify
the versions for projects by moving to only using tags, and removing
the version entry from setup.cfg.

I will send out a separate email with more detailed instructions
for requesting a milestone tag and removing the version entry.

Stable Release Actions
--

Review stable/liberty branches for patches that have landed since the
last release and determine if your deliverables need new tags.

Important Dates
---

Deadline for requesting a Mitaka 1 milestone tag: Dec 3

Mitaka 2: Jan 19-21

Mitaka release schedule:
https://wiki.openstack.org/wiki/Mitaka_Release_Schedule 


__
OpenStack Development Mailing 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] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-25 Thread Andrew Woodward

IMO, removing the docker containers is a mistake v.s. fixing them and using
them properly. They provide an isolation that is necessary (and that we
mangle) to make services portable and scaleable. We really should sit down
and document how we really want all of the services to interact before we
rip the containers out.

I agree, the way we use containers now still is quite wrong, and brings us
some negative value, but I'm not sold on stripping them out now just
because they no longer bring the same upgrades value as before.

My opinion aside, we are rushing into this far to late in the feature
cycle. Prior to moving forward with this, we need a good QA plan, the spec
is quite light on that and must receive review and approval from QA. This
needs to include an actual testing plan.

>From the implementation side, we are pushing up against the FF deadline. We
need to document what our time objectives are for this and when we will no
longer consider this for 8.0.

Lastly, for those that are +1 on the thread here, please review and comment
on the spec, It's received almost no attention for something with such a
large impact.

On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> The status is as follows:
>
> 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
> w/o docker containers
> 2) I've not built experimental ISO yet (have been testing and debugging
> manually)
> 3) There are still some flaws (need better formatting, etc.)
> 4) Plan for tomorrow is to build experimental ISO and to begin fixing
> system tests and fix the spec.
>
> [1] https://review.openstack.org/#/c/248649
> [2] https://review.openstack.org/#/c/248650
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Colleagues,
>>
>> I've started working on the change. Here are two patches (fuel-main [1]
>> and fuel-library [2]). They are not ready to review (still does not work
>> and under active development). Changes are not going to be huge. Here is a
>> spec [3]. Will keep the status up to date in this ML thread.
>>
>>
>> [1] https://review.openstack.org/#/c/248649
>> [2] https://review.openstack.org/#/c/248650
>> [3] https://review.openstack.org/#/c/248814
>>
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy <
>> amarets...@mirantis.com> wrote:
>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya >> > wrote:
>>>
 On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
 > Hi all,
 >
 > as you know, Rally runs inside docker on Fuel master node, so docker
 > removal (good improvement) is a problem for Rally users.
 >
 > To solve this, I'm planning to make native Rally installation on Fuel
 > master node that is running on CentOS 7,
 > and then make a step-by-step instruction how to make this
 installation.
 >
 > So I hope docker removal will not make issues for Rally users.

 I believe the most backwards compatible scenario is to keep the docker
 installed while removing the fuel-* docker things back to the host OS.
 So nothing would prevent user from pulling and running whichever docker
 containers he wants to put on the Fuel master node. Makes sense?

>>> Sounds good
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

Yeah looks like I read it wrong - the failure occurred during the
initial resource creation phase, based on comparing the logs that Artur
posted.
-- 
Sean M. Collins

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

I'll have to run some rechecks - but perhaps the issue is stable/kilo 
faceplanting on creating the initial resources (which is what, a 30%
success rate? 1 out of 3 runs?) - the only run where we got far enough
to upgrade we were actually successful?

-- 
Sean M. Collins

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On 25 November 2015 at 10:03, Sean M. Collins  wrote:

> On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
> > On 25 November 2015 at 09:49, Sean M. Collins 
> wrote:
> >
> > > Yeah looks like I read it wrong - the failure occurred during the
> > > initial resource creation phase, based on comparing the logs that Artur
> > > posted.
> > >
> >
> > I see. I got confused by this:
> >
> >
> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/logs/testr_results.html.gz
> >
> > Look at the timestamp, it's from 2 days ago.
>
> No, that's correct. It's just taken me 2 days to get around to writing an
> e-mail
> about all this :)
>

Ok, I see now...there's a phase where additional (grenade) resources are
created after having deployed and successfully tested the 'old' cloud,
correct?

So we fail before even attempting an upgrade?

>From here:

http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/logs/grenade.sh.txt.gz#_2015-11-23_18_52_18_102

I can't see any command that hints to upgrading neutron, besides here:

http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/bf6bae1/logs/old/screen-q-svc.txt.gz#_2015-11-23_18_35_00_569

It looks like we're testing 7.0.1.dev114, shouldn't we test from 7.0.0?

I am really confused, I should probably stop asking questions and do some
homework :)

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On 25 November 2015 at 11:33, Armando M.  wrote:

>
>
> On 25 November 2015 at 10:15, Korzeniewski, Artur <
> artur.korzeniew...@intel.com> wrote:
>
>> Yes, this file is complete fine. The Grenade is running smoke test before
>> resource creation.
>> The workflow is like this:
>> 1. Install old devstack on main and subnode
>> 2. Run tempest smoke
>> 3. Create resources
>> 4. Verify resources
>> 5. Shutdown the services
>> 6. Verify if shutdown does not affect the resources
>> 7. Spin new devstack on main node, subnode stays in old version without
>> any touch.
>> 8. Upgrade the services - start the new code on main node
>> 9. Run tempest smoke tests on upgraded main node - it in theory should
>> validate if we are cross-version compatible (N and N+1)
>> 10. Verify resources
>> 11. Shutdown
>>
>
> Thanks Artur, now it's clear...I can see the right versions etc. Having a
> good run to compare with helps a lot!
>

One more thing:

http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/logs/grenade.sh.txt.gz#_2015-11-25_14_31_20_846

I see no tests running, is it normal?


>>
> The successful steps are in log:
>>
>> http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-neutron-multinode/7c05ff0/logs/grenade.sh.summary.txt.gz
>>
>>
>>
>> Regards,
>> Artur
>>
>> -Original Message-
>> From: Sean M. Collins [mailto:s...@coreitpro.com]
>> Sent: Wednesday, November 25, 2015 7:03 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode
>> partial upgrade
>>
>> On Wed, Nov 25, 2015 at 12:53:56PM EST, Armando M. wrote:
>> > On 25 November 2015 at 09:49, Sean M. Collins 
>> wrote:
>> >
>> > > Yeah looks like I read it wrong - the failure occurred during the
>> > > initial resource creation phase, based on comparing the logs that
>> > > Artur posted.
>> > >
>> >
>> > I see. I got confused by this:
>> >
>> > http://logs.openstack.org/69/143169/60/experimental/gate-grenade-dsvm-
>> > neutron-multinode/bf6bae1/logs/testr_results.html.gz
>> >
>> > Look at the timestamp, it's from 2 days ago.
>>
>> No, that's correct. It's just taken me 2 days to get around to writing an
>> e-mail about all this :)
>>
>> --
>> Sean M. Collins
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing 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] [Sahara] Instance customization for Bootstrapping the cluster nodes

2015-11-25 Thread Ashish Billore

Hello Everyone,

I am looking for a way to customize my Cluster nodes at cluster creation
time. This is something like: AWS EMR BootStrap Action:
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-bootstrap.html

While creating an instance through nova boot command / UI, there is an
option to pass user-data through with cloud-init or cloud-config scripts,
that can customize the instance at creation time based on specific
environment or user need. Is there a similar way to pass cloud-init /
cloud-config scripts while creating cluster using Sahara?

Please Note: I do not prefer to bake these customization in the Sahara
image itself, I need to do these at the Cluster creation time, dynamically.

Thanks for the help.

-- 
Thanks,
Ashish
__
OpenStack Development Mailing 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] Encouraging first-time contributors through bug tags/reviews

2015-11-25 Thread Shamail

Hi,

> On Nov 25, 2015, at 10:51 PM, Anthony Chow  wrote:
> 
> Have a tag for first time contributor is a great idea.
> 
> On the other hand we should not take out the "low hanging fruit" tag.  I 
> contribute to OpenStack on my spare time and in my current situation I can 
> only work on the low hanging fruits.  If the first time tag is replacing the 
> low hanging fruit then it will be more difficult for me to find bugs that I 
> can work on.  
Great point. An additional tag probably makes sense in this scenario.
> 
> Thanks and everyone (in the U.S.) have a Happy Thanksgiving,
> 
> anthony.
> 
>> On Wed, Nov 25, 2015 at 9:06 AM, Maish Saidel-Keesing  
>> wrote:
>> This is an awesome idea!!!
>> 
>>> On 11/25/15 16:15, Shamail Tahir wrote:
>>> Hi everyone,
>>> 
>>> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which 
>>> discusses how one open-source project is encouraging contributions by new 
>>> open-source contributors through a combination of a special tag (which is 
>>> associated with work that is needed but can only be completed by someone 
>>> who is a first-time contributor) and helpful comments in the review phase 
>>> to ensure the contribution(s) eventually get merged.
>>> 
>>> While reading the article, I immediately thought about our 
>>> low-hanging-fruit bug tag which is used for a very similar purpose in "bug 
>>> fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit 
>>> tag is used to identify items that are generally suitable for first-time or 
>>> beginner contributors but, in reality, anyone can pick them up.  
>>> 
>>> I wanted to propose a new tag (or even changing the, existing, low-hanging 
>>> fruit tag) that would identify items that we are reserving for first-time 
>>> OpenStack contributors (e.g. a patch-set for the item submitted by someone 
>>> who is not a first time contributor would be rejected)... The same article 
>>> that Andrew shared mentions using an "up-for-grabs" tag which also 
>>> populates the items at up-for-grabs[3] (a site where people looking to 
>>> start working on open-source projects see entry-level items from multiple 
>>> projects).  If we move forward with an exclusive tag for first-timers then 
>>> it would be nice if we could use the up-for-grabs tag so that OpenStack 
>>> also shows up on the list too.  Please let me know if this change should be 
>>> proposed elsewhere, the tags are maintained in launchpad and the wiki I 
>>> found related to bug tags[4] didn't indicate a procedure for submitting a 
>>> change proposal.
>>> 
>>> Tyler Britten also suggested maybe even having a pool of reviewers who 
>>> could monitor items being worked on that fall in this "first-timer" 
>>> category who could further help the new contributors by helpful review 
>>> comments and answering questions if the contributors get stuck on some part 
>>> of the process.  Could this be the same people who helped make the upstream 
>>> training[5] successful?  I look forward to thoughts on this matter.
>>> 
>>> [1] https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
>>> [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
>>> [3] http://up-for-grabs.net/
>>> [4] https://wiki.openstack.org/wiki/Bug_Tags
>>> [5] http://docs.openstack.org/upstream-training/
>>> 
>>> 
>>> -- 
>>> Thanks,
>>> Shamail Tahir
>>> t: @ShamailXD
>>> tz: Eastern Time
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing 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,
>> Maish Saidel-Keesing
>> 
>> __
>> OpenStack Development Mailing 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][security] what is OK to put in DEBUG logs?

2015-11-25 Thread Dan Prince

On Mon, 2015-11-23 at 11:43 -0500, Ruby Loo wrote:
> On 20 November 2015 at 18:32, Ben Nemec 
> wrote:
> > On 11/19/2015 06:00 AM, Lucas Alvares Gomes wrote:
> > > Hi,
> > >
> > >> Also keep in mind that DEBUG logging, while still should have
> > some masking
> > >> of data, since it is explicitly called out (or should be) as not
> > safe for
> > >> production, can contain some " sensitive" data. Credentials
> > should still be
> > >> scrubbed, but I would say the swift temp URL is something that
> > may line up
> > >> with this more flexible level of filtering logs.
> > >>
> > >> Now, if the service (and I don't think ironic suffers from this
> > issue) is
> > >> only really runnable with debug on (because there is no useful
> > information
> > >> otherwise) then I would aim to fix that before putting even
> > potentially
> > >> sensitive data in DEBUG.
> > >>
> > >> The simple choice is if there is even a question, don't log it
> > (or log it in
> > >> a way that obscures the data but still shows unique use).
> > >>
> > >
> > > I agree with Morgan's statement here.
> > >
> > > And just throwing an idea in the wind here, we could make use of
> > the
> > > python logging filters to create a filter for sensitive
> > information.
> > > We probably need one already to avoid having to do things like
> > [1] in
> > > the code.
> > 
> > We actually have a thing to do that:
> > https://github.com/openstack/oslo.utils/blob/master/oslo_utils/stru
> > tils.py#L215
> > 
> > You might need to add a new key to the list of things to mask, but
> > I
> > think it should be able to handle masking the log message for you. 
> > I
> > don't know whether configdrive is a globally sensitive key, but if
> > not
> > then we probably need to revisit the question of whether to allow
> > extending the key list dynamically in the consuming application
> > instead
> > of having only the one hard-coded list.  More context here:
> > https://bugs.launchpad.net/oslo.utils/+bug/1407811
> > 
> > 
> The problem is that the developer WANTS to see the temporary URL, so
> masking it defeats the whole purpose.


Exactly. The sad thing here is that anyone who tries to use Ironic IPA
w/ Temp URLs is could to get their configuration wrong initially... and
they may very well end up adding the same log statement for the temp
URL (I was just trying to be generally helpful to the next person that
tries this). In my case... the actual URL was the only thing that if
logged would be helpful. Next best thing is just read the python code
yourself I guess...

> 
> The only thing I was thinking of (besides the developer modifying
> their code to spit it out) is to have some additional level of
> debugging that doesn't filter anything sensitive and/or add a config
> in ironic to log 'only-in-non-production-environments-shows-
> sensitive-info' with some big warning...

I thought this was what DEBUG was for :). It isn't like the upstream
projects enable by default or anything.

I'm of the belief that you shouldn't have to enable DEBUG in production
and I feel like OpenStack "installers" (my own company included) get it
wrong when they started trending towards defaulting their installations
to enable DEBUG by default.

So yeah. If there is no channel safe for "developer only logs" (DEBUG)
I guess we might should bail on this one.

> 
> My take on this (thanks everyone) is that it is a potential security
> risk to expose the URL in the logging, so we shouldn't allow it
> without some other way (besides expecting/documenting INFO level or
> higher) to prevent it from showing up in production.
> 
> --ruby
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] Call for review focus

2015-11-25 Thread Assaf Muller

On Mon, Nov 23, 2015 at 7:02 AM, Rossella Sblendido  wrote:
>
>
> On 11/20/2015 03:54 AM, Armando M. wrote:
>>
>>
>>
>> On 19 November 2015 at 18:26, Assaf Muller > > wrote:
>>
>> On Wed, Nov 18, 2015 at 9:14 PM, Armando M. > > wrote:
>> > Hi Neutrites,
>> >
>> > We are nearly two weeks away from the end of Mitaka 1.
>> >
>> > I am writing this email to invite you to be mindful to what you
>> review,
>> > especially in the next couple of weeks. Whenever you have the time
>> to review
>> > code, please consider giving priority to the following:
>> >
>> > Patches that target blueprints targeted for Mitaka;
>> > Patches that target bugs that are either critical or high;
>> > Patches that target rfe-approved 'bugs';
>> > Patches that target specs that have followed the most current
>> submission
>> > process;
>>
>> Is it possible to create Gerrit dashboards for patches that answer
>> these
>> criteria, and then persist the links in Neutron's dashboards devref
>> page?
>> http://docs.openstack.org/developer/neutron/dashboards/index.html
>> That'd be super useful.
>>
>>
>> We should look into that, but to be perfectly honest I am not sure how
>> easy it would be, since we'd need to cross-reference content that lives
>> into gerrit as well as launchpad. Would that even be possible?
>
>
> To cross-reference we can use the bug ID or the blueprint name.
>
> I created a script that queries launchpad to get:
> 1) Bug number of the bugs tagged with approved-rfe
> 2) Bug number of the critical/high bugs
> 3) list of blueprints targeted for the current milestone (mitaka-1)
>
> With this info the script builds a .dash file that can be used by
> gerrit-dash-creator [2] to produce a dashboard url .
>
> The script prints also the queries that can be used in gerrit UI directly,
> e.g.:
> Critical/High Bugs
> (topic:bug/1399249 OR topic:bug/1399280 OR topic:bug/1443421 OR
> topic:bug/1453350 OR topic:bug/1462154 OR topic:bug/1478100 OR
> topic:bug/1490051 OR topic:bug/1491131 OR topic:bug/1498790 OR
> topic:bug/1505575 OR topic:bug/1505843 OR topic:bug/1513678 OR
> topic:bug/1513765 OR topic:bug/1514810)
>
>
> This is the dashboard I get right now [3]
>
> I tried in many ways to get Gerrit to filter patches if the commit message
> contains a bug ID. Something like:
>
> (message:"#1399249" OR message:"#1399280" OR message:"#1443421" OR
> message:"#1453350" OR message:"#1462154" OR message:"#1478100" OR
> message:"#1490051" OR message:"#1491131" OR message:"#1498790" OR
> message:"#1505575" OR message:"#1505843" OR message:"#1513678" OR
> message:"#1513765" OR message:"#1514810")
>
> but it doesn't work well, the result of the filter contains patches that
> have nothing to do with the bugs queried.
> That's why I had to filter using the topic.
>
> CAVEAT: To make the dashboard work, bug fixes must use the topic "bug/ID"
> and patches implementing a blueprint the topic "bp/name". If a patch is not
> following this convention it won't be showed in the dashboard, since the
> topic is used as filter. Most of us use this convention already anyway so I
> hope it's not too much of a burden.
>
> Feedback is appreciated :)

Rossella this is exactly what I wanted :) Let's iterate on the patch
and merge it.
We could then consider running the script automatically on a daily
basis and publishing the
resulting URL in a nice bookmarkable place.

>
> [1] https://review.openstack.org/248645
> [2] https://github.com/openstack/gerrit-dash-creator
> [3] https://goo.gl/sglSbp
>
>>
>> Btw, I was looking at the current blueprint assignments [1] for Mitaka:
>> there are some blueprints that still need assignee, approver and
>> drafter; we should close the gap. If there are volunteers, please reach
>> out to me.
>>
>> Thanks,
>> Armando
>>
>> [1] https://blueprints.launchpad.net/neutron/mitaka/+assignments
>>
>>
>> >
>> > Everything else should come later, no matter how easy or interesting
>> it is
>> > to review; remember that as a community we have the collective duty
>> to work
>> > towards a common (set of) target(s), as being planned in
>> collaboration with
>> > the Neutron Drivers team and the larger core team.
>> >
>> > I would invite submitters to ensure that the Launchpad resources
>> > (blueprints, and bug report) capture the most updated view in terms
>> of
>> > patches etc. Work with your approver to help him/her be focussed
>> where it
>> > matters most.
>> >
>> > Finally, we had plenty of discussions at the design summit, and some
>> of
>> > those discussions will have to be followed up with actions (aka code
>> in
>> > OpenStack lingo). Even though, we no longer have deadlines for
>> feature
>> > submission, I strongly advise you not to leave it last minute. We
>> can only
>> >

[openstack-dev] [pbr][oslo] volunteer needed to increase pbr test coverage of sphinx

2015-11-25 Thread Robert Collins

Hi, so pbr has some glue that revolves around running sphinx, and it
got messy and broken with Sphinx 1.3.

Its been broken in a subtle way since then - warnerrors has no effect,
and previous attempts to get it working have broken things in a hard
visible way.

Doug has a patch up - https://review.openstack.org/#/c/229951/1 to fix
things, which may even be right on both sphinx < 1.3 and >=1.3 ... -
but without enough test coverage to know, we're basically guessing,
and since pbr is at the bottom of the ecosystem stack, guessing is a
high-risk activity there.

What we'd like is if someone could backfill the crucial test coverage:
we need to expand the coverage added in
https://review.openstack.org/#/c/189884/2/pbr/tests/test_core.py to
test a 2x2x2 matrix:

One dimension is the sphinx version - < 1.3 and >=1.3

The next dimension is the warnerrors flag - on or off

and the last dimension is whether the project has warnings or not.

pbr's test suite has a virtualenv fixture that makes putting together
arbitrary package combinations pretty straight forward, and I'd be
delighted to mentor someone who picks this up.

The current status quo means we have bitrot happening in docs jobs
across all of openstack, and its accruing project wide tech debt at an
unpleasant rate :(.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Encouraging first-time contributors through bug tags/reviews

2015-11-25 Thread Shamail

> On Nov 26, 2015, at 1:42 AM, Doug Hellmann  wrote:
> 
> OK, reserving bugs for new contributors does reduce the number of
> people contending for them, but it doesn't eliminate the need to
> figure out if someone else is already working on a bug before you
> start. Encouraging folks to assign bugs to themselves when they start
> work is probably the best way to solve that.
+1, I think most do a good job at this.

Where do you think is the appropriate place to formally ask for a new tag 
and/or reservations?  

I'd also appreciate any feedback from the people who have worked on the 
upstream training before each summit... Did you experience any issues finding 
available items for the people to work on?  How do you guide the new 
contributors to help them discover low-hanging-fruit?

Thanks,
Shamail 

__
OpenStack Development Mailing 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] [Security] Cancelling the weekly IRC meeting for thanks giving

2015-11-25 Thread Clark, Robert Graham

Hi all,

As the vast majority of the Security Project members are US based we are 
cancelling the IRC meeting tomorrow.

I’ll send out an ether pad agenda early next week and we can catch up then!

Kind Regards
-Rob
__
OpenStack Development Mailing 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][Neutron] Testing of Ironic/Neutron integration on devstack

2015-11-25 Thread Kevin Benton

This is cool. I didn't know you were working on an OVS driver for testing
in CI as well. :)

Does this work by getting the port wired into OVS so the agent recognizes
it like a regular port so it can be put into VXLAN/VLAN or whatever the
node is configured with? From what I can tell it looks like it's on a
completely different bridge so they wouldn't have connectivity to the rest
of the network.

I have some POC code[1] for 'baremetal' support directly in the OVS agent
so ports get treated just like VM ports. However, it requires upstream
changes so if yours accomplishes the same thing without any upstream
changes, that will be the best way to go.

Perhaps we can merge your approach (config via ssh) with mine (getting the
'baremetal' ports wired up for real connectivity) so we don't need upstream
changes.

1. https://review.openstack.org/#/c/249265/

Cheers,
Kevin Benton

On Wed, Nov 25, 2015 at 7:27 AM, Vasyl Saienko 
wrote:

> Hello Community,
>
> As you know Ironic/Neutron integration is planned in Mitaka. And at the
> moment we don't have any CI that will test it. Unfortunately we can't test
> Ironic/Neutron integration on HW as we don't have it.
> So probably the best way is to develop ML2 driver that will work with OVS.
>
> At the moment we have a PoC [1] of ML2 driver that works with Cisco and
> OVS on linux.
> Also we have some patches to devstack that allows to try Ironic/Neutron
> integration on VM and real HW. And quick guide how to test it locally [0]
>
> https://review.openstack.org/#/c/247513/
> https://review.openstack.org/#/c/248048/
> https://review.openstack.org/#/c/249717/
> https://review.openstack.org/#/c/248074/
>
> I'm interested in Neutron/Ironic integration. It would be great if we have
> it in Mitaka.
> I'm asking Community to check [0] and [1] and share your thoughts.
>
>  Also I would like to request a repo on openstack.org for [1]
>
>
> [0]
> https://github.com/jumpojoy/ironic-neutron/blob/master/devstack/examples/ironic-neutron-vm.md
> [1] https://github.com/jumpojoy/generic_switch
>
> --
> Sincerely
> Vasyl Saienko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-- 
Kevin Benton
__
OpenStack Development Mailing 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] Thoughts on python-future?

2015-11-25 Thread Eric Kao

I think the main benefit of python-future is that the library helps us
write straight Python 3 code instead of special bridged code.

For example, instead of writing six.iteritems(dict0), one could write
simply dict0.items() and expect Python 3 behavior across Python 2 & 3.
This way, whenever Python 2 support is dropped, we can easily drop the
dependence on the library just by dropping the import statements, because
the library mostly had no effect in Python 3 in the first place.

But as others have pointed out, the downside is that the library mucks
with the Python 2 internals, apparently causing much grief =(

On 11/24/15, 7:05 PM, "Robert Collins"  wrote:

>Which bit in particular do you like? Some of the stuff - like
>past.translation - is likely to be deeply fragile, other bits are
>fine, but not really any different to six.
>
>On 25 November 2015 at 15:33, Eric Kao  wrote:
>> Hi all,
>>
>> I¹ve been using the python-future library for Python 3 porting and want
>>to
>> see what people think of it.
>>http://python-future.org/overview.html#features
>>
>> The end result is standard Python3 code made compatible with Python2
>>through
>> library imports. The great thing is that Python 3 execution is mostly
>> independent of the library, so once Python 2 support is dropped, the
>>use of
>> the library can be dropped too.
>>
>> Anyone know why it¹s not used in OpenStack perhaps alongside six?
>>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
>>
>
>
>
>-- 
>Robert Collins 
>Distinguished Technologist
>HP Converged Cloud
>
>__
>OpenStack Development Mailing 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] Thoughts on python-future?

2015-11-25 Thread Eric Kao

Thanks for sharing your thoughts and experiences everyone!

It’s really too bad that the library causes all this headache. The goal is
laudable: enable Python 3 code to run on Python 2 with minimal
modification. It’d be really nice to write clean, standard Python 3 code
[e.g., dict0.items() ] rather than special, bridged code [e.g.,
six.iteritems(dict0) ] for Python 2+3 compatibility.

Such is life I guess. The goal inevitably requires messing with Python 2
internals to conform to Python 3 behavior, which inevitably leads to the
issues people mentioned.

Thanks again!

On 11/25/15, 10:10 AM, "Joshua Harlow"  wrote:

>Julien Danjou wrote:
>> On Tue, Nov 24 2015, Eric Kao wrote:
>>
>>> I¹ve been using the python-future library for Python 3 porting and
>>>want to
>>> see what people think of it.
>>>http://python-future.org/overview.html#features
>>>
>>> The end result is standard Python3 code made compatible with Python2
>>>through
>>> library imports. The great thing is that Python 3 execution is mostly
>>> independent of the library, so once Python 2 support is dropped, the
>>>use of
>>> the library can be dropped too.
>>>
>>> Anyone know why it¹s not used in OpenStack perhaps alongside six?
>>>Thanks!
>>
>> python-future has been a dependency of pytimeparse¹ for a while and it
>> has been a nightmare. IIRC, python-future blends into Python magically
>> so it is somehow automatically imported each time you run Python. This
>> had a tendency to break random other Python packages installed in the
>> environment.
>
>Oh, please no then, magically messing with other python packages by
>monkeying with the internals of python we already have enough of (cough
>cough eventlet, cough cough parts of jsonutils in oslo.serialization
>that injects itself into anyjson)...
>
>Just say no to more please ;)
>
>>
>> In the end we just dropped it from pytimeparse and we're much happier.
>>
>> And we're very happy with six. :)
>>
>> ¹  It's used by Gnocchi.
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing 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] Time to increase our IRC Meetings infrastructure?

2015-11-25 Thread Tony Breeds

On Wed, Nov 25, 2015 at 05:15:48PM +0100, Ihar Hrachyshka wrote:
> Thanks Tony for leading the effort. As you know, neutron-upgrades team
> (well, me) actually confused -alt/-2 thing, and I registered a meeting for
> -2.

I now have tools that will chack that human error in CI.

It's just a matter of creating the Jenkins config now.
 
> I am generally for adding more channels assuming they are used wisely (like:
> organizers check in advance they don’t overlap with related initiatives),
> but if hygiene will do the job and give us some useful slot, that would work
> fine too.

I'll let the dust settle on reviews and then re-generate the graph so we can
see how close we are to capacity at peak times.

Yours Tony.


pgpX2GpEzUaZV.pgp
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] Encouraging first-time contributors through bug tags/reviews

2015-11-25 Thread Shamail

Hi,

> On Nov 25, 2015, at 11:05 PM, Doug Hellmann  wrote:
> 
> Excerpts from Shamail Tahir's message of 2015-11-25 09:15:54 -0500:
>> Hi everyone,
>> 
>> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which
>> discusses how one open-source project is encouraging contributions by new
>> open-source contributors through a combination of a special tag (which is
>> associated with work that is needed but can only be completed by someone
>> who is a first-time contributor) and helpful comments in the review phase
>> to ensure the contribution(s) eventually get merged.
>> 
>> While reading the article, I immediately thought about our
>> low-hanging-fruit bug tag which is used for a very similar purpose in "bug
>> fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit
>> tag is used to identify items that are generally suitable for first-time or
>> beginner contributors but, in reality, anyone can pick them up.
>> 
>> I wanted to propose a new tag (or even changing the, existing, low-hanging
>> fruit tag) that would identify items that we are reserving for first-time
>> OpenStack contributors (e.g. a patch-set for the item submitted by someone
>> who is not a first time contributor would be rejected)... The same article
>> that Andrew shared mentions using an "up-for-grabs" tag which also
>> populates the items at up-for-grabs[3] (a site where people looking to
>> start working on open-source projects see entry-level items from multiple
>> projects).  If we move forward with an exclusive tag for first-timers then
>> it would be nice if we could use the up-for-grabs tag so that OpenStack
>> also shows up on the list too.  Please let me know if this change should be
>> proposed elsewhere, the tags are maintained in launchpad and the wiki I
>> found related to bug tags[4] didn't indicate a procedure for submitting a
>> change proposal.
> 
> I like the idea of making bugs suitable for first-timers more
> discoverable. I'm not sure we need to *reserve* any bugs for any class
> of contributor. What benefit do you think that provides?
I would have to defer to additional feedback here... 

My own perspective from when I was doing my first contribution is that it was 
hard to find active "low-hanging-fruit" items.  Most were already 
work-in-progress or assigned.

The idea was that having a reserved set of bugs would ensure that there was 
always something that could be discovered easily and would be available.   If 
we could make available low-hanging-fruit more discoverable then that would 
possibly mitigate the need for "reserved" bugs.  We have enough items to work 
on where availability shouldn't be an issue, just visibility.

https://bugs.launchpad.net/openstack/+bugs?field.tag=low-hanging-fruit=status=0

> 
>> 
>> Tyler Britten also suggested maybe even having a pool of reviewers who
>> could monitor items being worked on that fall in this "first-timer"
>> category who could further help the new contributors by helpful review
>> comments and answering questions if the contributors get stuck on some part
>> of the process.  Could this be the same people who helped make the upstream
>> training[5] successful?  I look forward to thoughts on this matter.
> 
> If we have volunteers willing to do this, that's great. It's not
> obvious, but it is actually possible to query gerrit for reviews
> from first-time contributors. A bot A watches for new patches leaves
> a comment on any for which the submitter has not previously submitted
> a patch. Querying for open reviews with comments from that bot is
> straightforward once you know its gerrit id. For example, this URL
> will show all open patches from first-time contributors submitted
> to any repository:
> 
> https://review.openstack.org/#/q/reviewer:10068+is:open,n,z
Thanks Doug!  I'll definitely start monitoring the results of this query and 
help when possible.  It will be great if others do it too, the more the 
merrier.  

> 
> Doug
> 
>> 
>> [1] https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
>> [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
>> 
>> [3] http://up-for-grabs.net/
>> [4] https://wiki.openstack.org/wiki/Bug_Tags
>> [5] http://docs.openstack.org/upstream-training/
> 
> __
> OpenStack Development Mailing 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][Neutron] Testing of Ironic/Neutron integration on devstack

2015-11-25 Thread Sukhdev Kapur

Hi Vasyl,

This is great. Kevin and I was working on the similar thing. I just
finished testing his patch and gave a +1.
This is a missing (and needed) functionality for getting the Ironic/Neutron
integration completed.

As Kevin suggests, it will be best if we can combine these approaches and
come up with the best solution.

If you are available, please join us in our next weekly meeting at 8AM
(pacific time) at #openstack-meeting-4.
I am sure team will be excited to know about this solution and this will
give an opportunity to make sure we cover all angles of this testing.

Thanks
-Sukhdev


On Wed, Nov 25, 2015 at 7:27 AM, Vasyl Saienko 
wrote:

> Hello Community,
>
> As you know Ironic/Neutron integration is planned in Mitaka. And at the
> moment we don't have any CI that will test it. Unfortunately we can't test
> Ironic/Neutron integration on HW as we don't have it.
> So probably the best way is to develop ML2 driver that will work with OVS.
>
> At the moment we have a PoC [1] of ML2 driver that works with Cisco and
> OVS on linux.
> Also we have some patches to devstack that allows to try Ironic/Neutron
> integration on VM and real HW. And quick guide how to test it locally [0]
>
> https://review.openstack.org/#/c/247513/
> https://review.openstack.org/#/c/248048/
> https://review.openstack.org/#/c/249717/
> https://review.openstack.org/#/c/248074/
>
> I'm interested in Neutron/Ironic integration. It would be great if we have
> it in Mitaka.
> I'm asking Community to check [0] and [1] and share your thoughts.
>
>  Also I would like to request a repo on openstack.org for [1]
>
>
> [0]
> https://github.com/jumpojoy/ironic-neutron/blob/master/devstack/examples/ironic-neutron-vm.md
> [1] https://github.com/jumpojoy/generic_switch
>
> --
> Sincerely
> Vasyl Saienko
>
> __
> OpenStack Development Mailing 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] Thoughts on python-future?

2015-11-25 Thread Robert Collins

On 26 November 2015 at 10:08, Eric Kao  wrote:
> I think the main benefit of python-future is that the library helps us
> write straight Python 3 code instead of special bridged code.
>
> For example, instead of writing six.iteritems(dict0), one could write
> simply dict0.items() and expect Python 3 behavior across Python 2 & 3.

But - one shouldn't be writing six.iteritems(dict0) *anyway* except in
really specific circumstances. We had a mega thread on that a few
months back - tl;dr at our scale - even at our aspirational scale - it
rarely if ever matters.

Its that that makes me actually skeptical - the overheads of 2+3
single tree compat are really really low already, generally.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

On Wed, Nov 25, 2015 at 02:31:26PM EST, Armando M. wrote:
> So we fail before even attempting an upgrade?

Yeah I think so, I think we were failing at step 3 of Artur's list,
creating the resources.

> It looks like we're testing 7.0.1.dev114, shouldn't we test from 7.0.0?

I think Grenade checks out stable/liberty - so that's probably a version
string generated from the tip of stable/liberty 

> I am really confused, I should probably stop asking questions and do some
> homework :)

No please keep asking - I think we're all learning things here. I'm
certainly no expert.

-- 
Sean M. Collins

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

Re: [openstack-dev] Encouraging first-time contributors through bug tags/reviews

Excerpts from Shamail's message of 2015-11-26 01:22:48 +0500:
> Hi,
> 
> > On Nov 25, 2015, at 11:05 PM, Doug Hellmann  wrote:
> > 
> > Excerpts from Shamail Tahir's message of 2015-11-25 09:15:54 -0500:
> >> Hi everyone,
> >> 
> >> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which
> >> discusses how one open-source project is encouraging contributions by new
> >> open-source contributors through a combination of a special tag (which is
> >> associated with work that is needed but can only be completed by someone
> >> who is a first-time contributor) and helpful comments in the review phase
> >> to ensure the contribution(s) eventually get merged.
> >> 
> >> While reading the article, I immediately thought about our
> >> low-hanging-fruit bug tag which is used for a very similar purpose in "bug
> >> fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit
> >> tag is used to identify items that are generally suitable for first-time or
> >> beginner contributors but, in reality, anyone can pick them up.
> >> 
> >> I wanted to propose a new tag (or even changing the, existing, low-hanging
> >> fruit tag) that would identify items that we are reserving for first-time
> >> OpenStack contributors (e.g. a patch-set for the item submitted by someone
> >> who is not a first time contributor would be rejected)... The same article
> >> that Andrew shared mentions using an "up-for-grabs" tag which also
> >> populates the items at up-for-grabs[3] (a site where people looking to
> >> start working on open-source projects see entry-level items from multiple
> >> projects).  If we move forward with an exclusive tag for first-timers then
> >> it would be nice if we could use the up-for-grabs tag so that OpenStack
> >> also shows up on the list too.  Please let me know if this change should be
> >> proposed elsewhere, the tags are maintained in launchpad and the wiki I
> >> found related to bug tags[4] didn't indicate a procedure for submitting a
> >> change proposal.
> > 
> > I like the idea of making bugs suitable for first-timers more
> > discoverable. I'm not sure we need to *reserve* any bugs for any class
> > of contributor. What benefit do you think that provides?
> I would have to defer to additional feedback here... 
> 
> My own perspective from when I was doing my first contribution is that it was 
> hard to find active "low-hanging-fruit" items.  Most were already 
> work-in-progress or assigned.
> 
> The idea was that having a reserved set of bugs would ensure that there was 
> always something that could be discovered easily and would be available.   If 
> we could make available low-hanging-fruit more discoverable then that would 
> possibly mitigate the need for "reserved" bugs.  We have enough items to work 
> on where availability shouldn't be an issue, just visibility.
> 
> https://bugs.launchpad.net/openstack/+bugs?field.tag=low-hanging-fruit=status=0

OK, reserving bugs for new contributors does reduce the number of
people contending for them, but it doesn't eliminate the need to
figure out if someone else is already working on a bug before you
start. Encouraging folks to assign bugs to themselves when they start
work is probably the best way to solve that.

> 
> > 
> >> 
> >> Tyler Britten also suggested maybe even having a pool of reviewers who
> >> could monitor items being worked on that fall in this "first-timer"
> >> category who could further help the new contributors by helpful review
> >> comments and answering questions if the contributors get stuck on some part
> >> of the process.  Could this be the same people who helped make the upstream
> >> training[5] successful?  I look forward to thoughts on this matter.
> > 
> > If we have volunteers willing to do this, that's great. It's not
> > obvious, but it is actually possible to query gerrit for reviews
> > from first-time contributors. A bot A watches for new patches leaves
> > a comment on any for which the submitter has not previously submitted
> > a patch. Querying for open reviews with comments from that bot is
> > straightforward once you know its gerrit id. For example, this URL
> > will show all open patches from first-time contributors submitted
> > to any repository:
> > 
> > https://review.openstack.org/#/q/reviewer:10068+is:open,n,z
> Thanks Doug!  I'll definitely start monitoring the results of this query and 
> help when possible.  It will be great if others do it too, the more the 
> merrier.  
> 
> > 
> > Doug
> > 
> >> 
> >> [1] 
> >> https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
> >> [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
> >> 
> >> [3] http://up-for-grabs.net/
> >> [4] https://wiki.openstack.org/wiki/Bug_Tags
> >> [5] http://docs.openstack.org/upstream-training/
> > 
> > __
> >

Re: [openstack-dev] [tripleo] Location of TripleO REST API

2015-11-25 Thread Ben Nemec

On 11/23/2015 06:50 AM, Dmitry Tantsur wrote:
> On 11/17/2015 04:31 PM, Tzu-Mainn Chen wrote:
>>
>> 
>>
>>
>>
>> On 10 November 2015 at 15:08, Tzu-Mainn Chen > > wrote:
>>
>> Hi all,
>>
>> At the last IRC meeting it was agreed that the new TripleO REST API
>> should forgo the Tuskar name, and simply be called... the TripleO
>> API.  There's one more point of discussion: where should the API
>> live?  There are two possibilities:
>>
>> a) Put it in tripleo-common, where the business logic lives.  If we
>> do this, it would make sense to rename tripleo-common to simply
>> tripleo.
>>
>>
>> +1 - I think this makes most sense if we are not going to support
>> the tripleo repo as a library.
>>
>>
>> Okay, this seems to be the consensus, which is great.
>>
>> The leftover question is how to package the renamed repo.  'tripleo' is
>> already intuitively in use by tripleo-incubator.
>> In IRC, bnemec and trown suggested splitting the renamed repo into two
>> packages - 'python-tripleo' and 'tripleo-api',
>> which seems sensible to me.
> 
> -1, that would be inconsistent with what other projects are doing. I 
> guess tripleo-incubator will die soon, and I think only tripleo devs 
> have any intuition about it. For me tripleo == instack-undercloud.

This was only referring to rpm packaging, and it is how we currently
package most of the other projects.  The repo itself would stay as one
thing, but would be split into python-tripleo and openstack-tripleo-api
rpms.

I don't massively care about package names, but given that there is no
(for example) openstack-nova package and openstack-tripleo is already in
use by a completely different project, I think it's reasonable to move
ahead with the split packages named this way.

> 
>>
>> What do others think?
>>
>>
>> Mainn
>>
>>
>> b) Put it in its own repo, tripleo-api
>>
>>
>> The first option made a lot of sense to people on IRC, as the
>> proposed
>> API is a very thin layer that's bound closely to the code in
>> tripleo-
>> common.  The major objection is that renaming is not trivial;
>> however
>> it was mentioned that renaming might not be *too* bad... as long as
>> it's done sooner rather than later.
>>
>> What do people think?
>>
>>
>> Thanks,
>> Tzu-Mainn Chen
>>
>> 
>> __
>> OpenStack Development Mailing 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] [keystone] Mid-Cycle Meetup Planning

2015-11-25 Thread Steve Martinelli

23 responses later and it's settled, we'll be having the midcycle in Austin
TX between January 27-29. I've updated the wiki to reflect this update:
https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint

Looking forward to seeing everyone there!

- Steve

Steve Martinelli/Toronto/IBM@IBMCA wrote on 2015/11/24 01:32:28 AM:

> From: Steve Martinelli/Toronto/IBM@IBMCA
> To: "OpenStack Development Mailing List"

> Date: 2015/11/24 01:35 AM
> Subject: [openstack-dev] [keystone] Mid-Cycle Meetup Planning
>
> I'd like to pin down a date and location for our mid-cycle meetup.
> I've created a very short form for folks to fill out: http://goo.gl/
> forms/uNsGSRdRLl
>
> Depending on the number of responses received (normally we see about
> 20-30 folks at the mid-cycle), I may make a final call on the date
> and location so that people can get visas, travel approval, etc as
> soon as possible. So your prompt responses are super important!
>
> Regarding the location, I left an "Other" option, but please only
> use this if you can guarantee a space! Please don't suggest
> unrealistic places such as: The moon or Winterfell :)
>
> As details are available I’ll provide updates. I'll send out a link
> to the wiki with date, location and hotel details as they emerge.
>
> Thanks!
> Steve
>
> p.s. sorry about the duplicate announcement, the first one was sent
> using the tag [Keystyone]!
__
OpenStack Development Mailing 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] Encouraging first-time contributors through bug tags/reviews

Excerpts from Shamail's message of 2015-11-26 02:07:55 +0500:
> 
> > On Nov 26, 2015, at 1:42 AM, Doug Hellmann  wrote:
> > 
> > OK, reserving bugs for new contributors does reduce the number of
> > people contending for them, but it doesn't eliminate the need to
> > figure out if someone else is already working on a bug before you
> > start. Encouraging folks to assign bugs to themselves when they start
> > work is probably the best way to solve that.
> +1, I think most do a good job at this.
> 
> Where do you think is the appropriate place to formally ask for a new tag 
> and/or reservations?  

This list is a good place to ask for a tag like that. It's also a good
topic for the cross-project meetings.

> 
> I'd also appreciate any feedback from the people who have worked on the 
> upstream training before each summit... Did you experience any issues finding 
> available items for the people to work on?  How do you guide the new 
> contributors to help them discover low-hanging-fruit?
> 
> Thanks,
> Shamail 
> 

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

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

2015-11-25 Thread Fox, Kevin M

Getting additional packages through distro channels can be surprisingly 
difficult for new packages. :/

So having one new package for neutron-subprojects-dashboard rather then many 
might be much easier.

Thanks,
Kevin 

From: Akihiro Motoki [amot...@gmail.com]
Sent: Tuesday, November 24, 2015 9:46 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron
subprojects

Hi,

Neutron has now various subprojects and some of them would like to
implement Horizon supports. Most of them are additional features.
I would like to start the discussion where we should have horizon support.

[Background]
Horizon team introduced a plugin mechanism and we can add horizon panels
from external repositories. Horizon team is recommending external repos for
additional services for faster iteration and features.
We have various horizon related repositories now [1].

In Neutron related world, we have neutron-lbaas-dashboard and
horizon-cisco-ui repos.

[Possible options]
There are several possible options for neutron sub-projects.
My current vote is (b), and the next is (a). It looks a good balance to me.
I would like to gather broader opinions,

(a) horizon in-tree repo
- [+] It was a legacy approach and there is no initial effort to setup a repo.
- [+] Easy to share code conventions.
- [-] it does not scale. Horizon team can be a bottleneck.

(b) a single dashboard repo for all neutron sub-projects
- [+] No need to set up a repo by each sub-project
- [+] Easier to share the code convention. Can get horizon reviewers.
- [-] who will be a core reviewer of this repo?

(c) neutron sub-project repo
- [+] Each sub-project can develop a dashboard fast.
- [-] It is doable, but the directory tree can be complicated.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.

(d) a separate repo per neutron sub-project
Similar to (c)
- [+] A dedicate repo for dashboard simplifies the directory tree.
- [-] Need to setup a separate repo.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.


Note that this mail is not intended to move the current neutron
support in horizon
to outside of horizon tree. I would like to discuss Horizon support of
additional features.

Akihiro

[1] http://docs.openstack.org/developer/horizon/plugins.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

Re: [openstack-dev] [all] Thoughts on python-future?

2015-11-25 Thread Joshua Harlow


Julien Danjou wrote:

On Tue, Nov 24 2015, Eric Kao wrote:


I¹ve been using the python-future library for Python 3 porting and want to
see what people think of it. http://python-future.org/overview.html#features

The end result is standard Python3 code made compatible with Python2 through
library imports. The great thing is that Python 3 execution is mostly
independent of the library, so once Python 2 support is dropped, the use of
the library can be dropped too.

Anyone know why it¹s not used in OpenStack perhaps alongside six? Thanks!


python-future has been a dependency of pytimeparse¹ for a while and it
has been a nightmare. IIRC, python-future blends into Python magically
so it is somehow automatically imported each time you run Python. This
had a tendency to break random other Python packages installed in the
environment.


Oh, please no then, magically messing with other python packages by 
monkeying with the internals of python we already have enough of (cough 
cough eventlet, cough cough parts of jsonutils in oslo.serialization 
that injects itself into anyjson)...


Just say no to more please ;)



In the end we just dropped it from pytimeparse and we're much happier.

And we're very happy with six. :)

¹  It's used by Gnocchi.


__
OpenStack Development Mailing 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] [murano] Is it possible to use Murano RESTful API to create and deploy an application

2015-11-25 Thread WANG, Ming Hao (Tony T)

Dear Murano developers and testers,

I want to use Murano RESTful API to create and deploy an application.
Based on my current understanding, I want to use muranoclient cli as following:

1.   "environment-create" to create Murano environment;

2.   "environment-session-create" to create session for the environment;

3.   "environment-apps-create" to create application for the session.

This command hasn't been implemented yet, thus I implement it by studying 
"do_environment_apps_edit" to send POST request to "services" object.

Could you please help to check if my thought is right?

If it is right, I meet the following issue:
When an environment includes several applications, I need to generate an uuid 
for each application, and use the uuid to let one application reference to 
another application.
It is a little strange to let user provide this kind of information, and I 
doubt if I'm using Murano in a wrong way, and Murano isn't designed for this.

Could you please help to check? Is Murano designed to be able to expose RESTful 
to do all the works(including application creation/deployment) that user can do 
from UI?

Please advice,
Thanks,
Tony

__
OpenStack Development Mailing 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] Fwd: [QA] Meeting Thursday November 26th at 9:00 UTC

2015-11-25 Thread Ken'ichi Ohmichi

Hi everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, November 26th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_November_26th_2015_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

To help people figure out what time 9:00 UTC is in other timezones the next
meeting will be at:

03:00 EDT
18:00 JST
18:30 ACST
11:00 CEST
04:00 CDT
02:00 PDT

Thanks

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

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows