Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

[Samuel Bercovici]

And then they were 6 =D>


-Sam.

-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com] 
Sent: Thursday, September 17, 2015 1:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for 
neutron-lbaas core team

Hi all,

As the Lieutenant of the advanced services, I nominate Michael Johnson to be a 
member of the neutron-lbaas core reviewer team.

Review stats are in line with other cores[2], and Michael has been instrumental 
in both neutron-lbaas and octavia.

Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, 
Phil, Al, and Kyle.)

Thanks,
doug

1. 
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-lbaas/90


__
OpenStack Development Mailing 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] API response on k8s failure

[Ton Ngo]

Hi Ryan,
 There is a bug opened with a similar failure symptom, although I am
not sure if the cause is the same:
https://bugs.launchpad.net/magnum/+bug/1481889

Trying to use kubectl to deploy the V1 manifest, I get this error message:
Error: unable to recognize "redis-master.yaml": no object named "Pod" is
registered

Clearly the error handling from the k8s handler needs to be improved.  If
the bug above is different from what you found, I think opening a new bug
would be best.

Ton Ngo,




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

Date:   09/14/2015 05:34 PM
Subject:Re: [openstack-dev] [Magnum] API response on k8s failure



Ryan,

Thanks for sharing this. Sorry you got out to a bumpy start. I suggest you
do file a bug for this against magnum and we can decide how best to handle
it. I can not tell from your email what the kubectl would do with the same
input. We might have an opportunity to make both better.

If you need guidance for how to file a bug, feel free to email me directly
and I can point you in the right direction.

Thanks,

Adrian

> On Sep 14, 2015, at 3:05 PM, Ryan Rossiter 
wrote:
>
> I was giving a devstacked version of Magnum a try last week, and from a
new user standpoint, I hit a big roadblock that caused me a lot of
confusion. Here's my story:
>
> I was attempting to create a pod in a k8s bay, and I provided it with an
sample manifest from the Kubernetes repo. The Magnum API then returned the
following error to me:
>
> ERROR: 'NoneType' object has no attribute 'host' (HTTP 500)
>
> I hunted down the error to be occurring here [1]. The k8s_api call was
going bad, but conductor was continuing on anyways thinking the k8s API
call went fine. I dug through the API calls to find the true cause of the
error:
>
> {u'status': u'Failure', u'kind': u'Status', u'code': 400, u'apiVersion':
u'v1beta3', u'reason': u'BadRequest', u'message': u'Pod in version v1
cannot be handled as a Pod: no kind "Pod" is registered for version "v1"',
u'metadata': {}}
>
> It turned out the error was because the manifest I was using had
apiVersion v1, not v1beta3. That was very unclear by Magnum originally
sending the 500.
>
> This all does occur within a try, but the k8s API isn't throwing any sort
of exception that can be caught by [2]. Was this caused by a regression in
the k8s client? It looks like the original intention of this was to catch
something going wrong in k8s, and then forward on the message & error code
on to let the magnum API return that.
>
> My question here is: does this classify as a bug? This happens in more
places than just the pod create. It's changing around API returns (quite a
few of them), and I don't know how that is handled in the Magnum project.
If we want to have this done as a blueprint, I can open that up and target
it for Mitaka, and get to work. If it should be opened up as a bug, I can
also do that and start work on it ASAP.
>
> [1]
https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L88-L108

> [2]
https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L94

>
> --
> Thanks,
>
> Ryan Rossiter (rlrossit)
>
>
>
__
> OpenStack Development Mailing 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] [Glance] PTL candidacy

[Nikhil Komawar]

Hello everyone,

I would like to herewith propose my candidacy for the role of Glance PTL
for the Mitaka release cycle.

I. Personal Commitment

I am a full time upstream OpenStacker at IBM and have recently
transitioned into this role with the condition that I will be given 100%
time to focus on community issues, development and help solve upstream
challenges. I am also committed to giving my full attention to Glance.
Not too long ago, I have had a few conversations with the PTLs of other
projects for either help them better use Glance or for dissolving the
issues they were facing in their projectsw. However, in this cycle I
would like to work with some of you in the capacity of inter-project
liaisons to help better understand the usage and stability of Glance in
respective areas and yet be involved with you in addressing those
issues. I know this is added work that must not go unrewarded so, I
would like to work out a plan with you that will enable distribution of
power (if with more power comes more responsibility, visa versa must
true, making it true claim). It has been enabled in Glance to some
extent & I have learnt other bigger projects implementing this. I would
like to make it a complete reality in Glance. I am also committed to
documenting and improving the current specs process and criterion that
will enable quicker turnaround time.

At IBM, I have the pleasure of being part of team that has some of the
most outstanding OpenStackers and I hope to collaborate more with them
in Mitaka for solving (hard) problems.

II. Liberty

a) Stability

Over 100 bugs were fixed in Liberty (including python-glanceclient,
glance_store and Glance servers) with a relatively small review team.
Glance is gradually improving momentum to help the different code
proposals get time-justice for code reviews. Some features in Kilo
introduced a number security bugs beyond expectations so, the further
development of those features has been slowed down and focus has been
shifted to fix the functionality, making it more stable and secure.
Experimental features showed a smooth progress and close to no issues of
such sort. A close eye on the reviews was kept to ensure so. Any spec
proposals that showed potential security risks, shake stability or
performance or refactor major parts of the code base were given a wait
signal.

b) Performance

I consider them as systematic optimizations and sometimes systematic
improvisations. Major disagreements on the path forward for optimizing
streaming workflows for images data have been sorted out. Many new
proposals were made however, due to lack of early time commitment from
developers they were unable to be seen through. Continued feedback
should be expected for similar proposals for glance_store in early Mitaka.

c) Cross project communications & Process Evolution

I have made an attempt to continually evolve our process to make it more
engaging and community friendly. Now there are three meetings weekly
that are a good place for collaboration on different aspects of Glance.
Either me or a member of the Glance community is at the weekly CPL
meeting to gather feedback from horizontal teams, cross project
decision/efforts etc. as well as input has been provided using Glance’s
perspective. I have had regular chats with Nova PTL on the outstanding
issues of the Images APIs and adoption of v2 Images API by Nova.
Feedback was provided at the DefCore mid-cycle as well as a welcoming
hand was presented for attending Glance mid-cycle (even virtually) for
those who could not make it.  In Mitaka, I hope to continue
collaborating with the interested members there as well as in the other
projects. I would like to pay close personal attention to the pressing
matters that need short team resolution like the adoption of v2 API by
Nova and Images API suitable for DefCore. Unfortunately, any of the
existing (half) attempts at fixing this issue have been wasted as they
were breaking some of the fundamental aspects of project. This matter
would need wider input for a fine resolution and a change that would not
break the world; of-course compromise is very likely for some but
doesn’t need to be fundamentally disjoint with the newly established
DefCore standard. It was realized early that a half baked attempt of
making such a critical change would break core of Glance so, I have been
contemplating on the future of the project. More clarity of thought has
been accomplished during the conversations with the TC members, PTLs,
Product WG liaisons etc. and I will continue to gather more feedback in
Mitaka. It has been a pleasure to be part of (collaborating with) teams
that help build very large cloud deployments and I find that experience
valuable for solving this complicated matter. Not only upstream but at
IBM too, I plan to closely interact with the technical and product
leaders of the Public and Private cloud deployment to help solve such
issues. My team at IBM enables me to have such interactions with

[openstack-dev] [dragonflow] Low OVS version for Ubuntu

[Li Ma]

Hi all,

I tried to run devstack to deploy dragonflow, but I failed with lower
OVS version.

I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
which is much lower than the required version 2.3.1+?

So, can anyone provide a Ubuntu repository that contains the correct
OVS packages?

Thanks,
-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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

[openstack-dev] [neutron] Please help review this RFE

[Li Ma]

Hi Neutron folks,

I'd like to introduce a pure python-driven network configuration
library to Neutron. A discussion just started in the RFE ticket [1].
I'd like to get feedback on this proposal.

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

Take a look and let me know your thoughts.
-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

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

Re: [openstack-dev] [puppet] service default value functions

[Yanis Guenane]

On 09/16/2015 09:39 PM, Emilien Macchi wrote:
>
> On 09/16/2015 12:53 PM, Alex Schultz wrote:
>> Hey puppet folks,
>>
>> Based on the meeting yesterday[0], I had proposed creating a parser
>> function called is_service_default[1] to validate if a variable matched
>> our agreed upon value of ''.  This got me thinking
>> about how can we maybe not use the arbitrary string throughout the
>> puppet that can not easily be validated.  So I tested creating another
>> puppet function named service_default[2] to replace the use of '> DEFAULT>' throughout all the puppet modules.  My tests seemed to
>> indicate that you can use a parser function as parameter default for
>> classes. 
>>
>> I wanted to send a note to gather comments around the second function. 
>> When we originally discussed what to use to designate for a service's
>> default configuration, I really didn't like using an arbitrary string
>> since it's hard to parse and validate. I think leveraging a function
>> might be better since it is something that can be validated via tests
>> and a syntax checker.  Thoughts?
> Let me add your attempt to make it work in puppet-cinder:
> https://review.openstack.org/#/c/224277
>
> I like the proposal, +1.
Alex, thank you for this proposal.

I like your approach :

 * as it will make writing manifest more idiomatic.

$foo = service_default() with if is_service_default($foo) { } reads
better than
$foo = '' with if $foo == ''.

 * if for any reason, hopefully this shouldn't happen but we need to
change the value,
it will happen only on few places. (less commit to review)

 * the end result is the exact same one as the one we have today.

For me it's a go, let's see what the other have to say about it

Thank you,

>
>> Thanks,
>> -Alex
>>
>> [0] 
>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
>> [1] https://review.openstack.org/#/c/223672
>> [2] https://review.openstack.org/#/c/224187
>>
>>
>> __
>> OpenStack Development Mailing 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] [dragonflow] Low OVS version for Ubuntu

[Gal Sagie]

Hello Li Ma,

Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need
OVS 2.3.1.
As suggested you can build it from source.
For Fedora 21 OVS2.3.1 is part of the default yum repository.

You can ping me on IRC (gsagie at freenode) if you need any additional help
how
to compile OVS.

Thanks
Gal.

On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <
sbisw...@linux.vnet.ibm.com> wrote:

>
>
> On Thursday 17 September 2015 12:22 PM, Li Ma wrote:
>
>> Hi all,
>>
>> I tried to run devstack to deploy dragonflow, but I failed with lower
>> OVS version.
>>
>> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
>> which is much lower than the required version 2.3.1+?
>>
>> So, can anyone provide a Ubuntu repository that contains the correct
>> OVS packages?
>>
>
> Why don't you just build the OVS you want from here:
> http://openvswitch.org/download/
>
> Thanks,
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

The G.
__
OpenStack Development Mailing List (not for 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] RFE process question

[Li Ma]

A reasonable user story. Other than tag, a common description field
for Neutron resources is also usable.

I submitted a RFE bug for review:
https://bugs.launchpad.net/neutron/+bug/1496705

__
OpenStack Development Mailing 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] [oslo][oslo.config] Reloading configuration of service

[mhorban]

Hi Doug,

> Rather than building hooks into oslo.config, why don't we build them
> into the thing that is catching the signal. That way the app can do lots
> of things in response to a signal, and one of them might be reloading
> the configuration.

Hm... Yes... It is really stupid idea to put reloading hook into 
oslo.config.
I'll move that hook mechanism into oslo.service. oslo.service is 
responsible for catching/handling signals.


Is it enough to have one callback function? Or should I must add ability 
to register many different callback functions?


What is your point of view?

Marian

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

Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu

[Sudipto Biswas]

On Thursday 17 September 2015 12:22 PM, Li Ma wrote:

Hi all,

I tried to run devstack to deploy dragonflow, but I failed with lower
OVS version.

I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
which is much lower than the required version 2.3.1+?

So, can anyone provide a Ubuntu repository that contains the correct
OVS packages?


Why don't you just build the OVS you want from here: 
http://openvswitch.org/download/


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] [Fuel] Bugs which we should accept in 7.0 after Hard Code Freeze

[Adam Heczko]

Hi, I'd like to ask for fixing these security related bugs in stable/7.0
branch:

https://bugs.launchpad.net/fuel/+bug/1496407
https://bugs.launchpad.net/fuel/+bug/1488732

Both are fuel-library related tasks, it is Apache2 and NTPD configuration
lifting.

Thanks,

Adam

On Tue, Sep 15, 2015 at 12:19 AM, Mike Scherbakov 
wrote:

> Thanks Andrew.
> Team, if there are any disagreements - let's discuss it. Otherwise, I
> think we should be just strict and follow defined process. We can deliver
> high priority bugfixes in updates channel later if needed.
>
> I hope that reasoning is clear for everything. Every bugfix has a
> potential to break something. It's basically a risk.
>
> On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov 
> wrote:
>
>> Hi Everyone!
>>
>> I would like to reiterate the bugfix process after Hard Code Freeze.
>> According to our HCF definition [1] we should only merge fixes for
>> *Critical* bugs to *stable/7.0* branch, High and lower priority bugs
>> should NOT be accepted to *stable/7.0* branch anymore.
>> Also we should accept patches for critical bugs to *stable/7.0* branch
>> only after the corresponding patchset with same ChangeID was accepted into
>> master.
>>
>> [1] - https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze
>>
>> Regards,
>> Andrey Maximov
>> Fuel Project Manager
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [all][gate] grende jobs failing.

[Tony Breeds]

On Thu, Sep 17, 2015 at 03:34:30PM +1000, Tony Breeds wrote:
> On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:
> > Hi all,
> > The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in kilo.  
> > The
> > juno global-requirements for Babel are not compatible with kilo so nothing 
> > can
> > get through grenade :(
> > 
> > We're working it
> > https://bugs.launchpad.net/oslo.utils/+bug/1496678
> 
> Here's my best effort for right now.
> https://review.openstack.org/#/c/224429/ 

For those playing along at home the new plan is to:
 1. Release a version of oslo.utils with the kilo requirements
This needs to be done as a revert because 1.4.2 must follow 1.4.1
 - https://review.openstack.org/#/c/224472/
 2 Tag that as 1.4.2

Then the gate should be okay again, while the stable team (and me) work out how
to fix juno without breaking kilo.

Yours Tony.


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

[openstack-dev] [oslo][oslo.config] Reloading configuration of service

[mhorban]

Hi Josh,

> Sounds like a useful idea if projects can plug-in themselves into the
> reloading process. I definitely think there needs to be a way for
> services to plug-in to this, although I'm not quite sure it will be
> sufficient at the current time though.
>
> An example of why:
>
> -
> 
https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24 


> (unless this module is purged from python and reloaded it will likely
> not reload correctly).
>
> Likely these can all be easily fixed (I just don't know how many of
> those exist in the various projects); but I guess we have to start
> somewhere so getting the underlying code able to be reloaded is a first
> step of likely many.

Each of openstack component should contain code responsible for 
reloading such objects.
What objects  will be reloaded? It depends of inspire and desire of 
developers/users.

Writing such code is a second step.

Marian

__
OpenStack Development Mailing 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] questions about nova compute monitors extensions

[Hou Gang HG Liu]

Hi Jay,

I notice nova compute monitor now only tries to load monitors with 
namespace "nova.compute.monitors.cpu", and only one monitor in one 
namespace can be enabled(
https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py
).

Is there a plan to make MonitorHandler.NAMESPACES configurable or just 
hard code constraint as it is now? And how to make compute monitor support 
user defined as it was?

Thanks!
B.R

Hougang Liu （刘侯刚）
Developer - IBM Platform Resource Scheduler   
Systems and Technology Group

Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023 陕西
省西安市高新六路42号中清大厦3层
E-mail: liuh...@cn.ibm.com  Xian, Shaanxi 
Province 710075, China 
 


__
OpenStack Development Mailing 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][ptl] Magnum PTL Candidacy

[Hongbin Lu]

Hi all,

I would like to announce my candidacy for the PTL position of Magnum.

I involved in Magnum project starting from December 2014. At that time, 
Magnum's code base is much smaller than right now. Since then, I worked with a 
diverse set of team members to land features, discuss the roadmap, fix the 
gate, do pre-release test, fix the documentation, etc.. Thanks to our team 
efforts, in the past a few months, I saw important features were landed one 
after another, which I really proud of.

To address the question why I am a good candidate for Magnum, here are the key 
reasons:
* I contributed a lot to Magnum's code base and feature set.
* I am familiar with every aspects of the project, and understand both the big 
picture and technical details.
* I will have time and resources to take the PTL responsibility, mostly because 
I am a full time allocated to this project.
* I love container.
* I care the project.
Here is more details of my involvement in the project:
http://stackalytics.com/?module=magnum-group
https://github.com/openstack/magnum/graphs/contributors

In my opinion, Magnum needs to focus on the following in the next cycle:
* Production ready: Work on everything that are possible to make it happen.
* Baremetal: Complete and optimize our Ironic integration to enable running 
containers on baremetal.
* Container network: deliver a network solution that is high performance and 
customizable.
* UI: Integrate with Horizon to give users a friendly interface to use Magnum.
* Pluggable COE: A pluggable design is a key feature for users to customize 
Magnum, which is always the case.
* Grow community: Attract more contributors to contribute to Magnum.

If elected, I will strictly follow the principal of being a OpenStack project, 
especially the four opens. The direction of the project will be 
community-driven as always.

I hope you will give me an opportunity to serve as Magnum's PTL in the next 
cycle.

Best regards,
Hongbin

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

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

[Doug Hellmann]

Excerpts from mhorban's message of 2015-09-17 10:26:28 +0300:
> Hi Doug,
> 
>  > Rather than building hooks into oslo.config, why don't we build them
>  > into the thing that is catching the signal. That way the app can do lots
>  > of things in response to a signal, and one of them might be reloading
>  > the configuration.
> 
> Hm... Yes... It is really stupid idea to put reloading hook into 
> oslo.config.
> I'll move that hook mechanism into oslo.service. oslo.service is 
> responsible for catching/handling signals.
> 
> Is it enough to have one callback function? Or should I must add ability 
> to register many different callback functions?
> 
> What is your point of view?
> 
> Marian
> 

We probably want the ability to have multiple callbacks. There are
already a lot of libraries available on PyPI for handling "events" like
this, so maybe we can pick one of those that is well maintained and
integrate it with oslo.service?

Doug

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

Re: [openstack-dev] [defcore] Scoring for DefCore 2016.01 Guideline

[Flavio Percoco]

On 16/09/15 22:26 -0700, Chris Hoge wrote:

The DefCore Committee is working on scoring capabilities for the upcoming
2016.01 Guideline, a solid draft of which will be available at the Mitaka
summit for community review and will go to the Board of Directors for
approaval in Janaury [1]. The current 2015.07 Guideline [2] covers Nova,
Swift, and Keystone. Scoring for the upcoming Guideline may includes new
capabilities for Neutron, Glance, Cinder, and Heat, as well as
updated capabilities for Keystone and Nova.

As part of our process, we want to encourage the development and user
communities to give feedback on the proposed capability categorizations
and how they are currently graded against the Defcore criteria [3].

Capabilities we're currently considering for possible inclusion are:
   Neutron:  https://review.openstack.org/#/c/210080/
   Glance:   https://review.openstack.org/#/c/213353/
   Cinder:   https://review.openstack.org/#/c/221631/
   Heat: https://review.openstack.org/#/c/216983/
   Keystone: https://review.openstack.org/#/c/213330/
   Nova: https://review.openstack.org/#/c/223915/

We would especially like to thank the PTL's and technical community members
who helped draft the proposed capabilities lists and provided
feedback--your input has been very helpful.

[1] 
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n13
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json
[3] 
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst



Thanks for sending this out, it's useful and informative.

Flavio

--
@flaper87
Flavio Percoco


pgpdv0KXx1igP.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] [neutron] PTL Non-Candidacy

[Livnat Peer]

Kyle,
Thank you for the awesome work you did in the past 3 cycles as PTL.
You made hard decisions and drove changes that resulted in a more
welcoming, easier to work with community, not to mention a more
healthy project.
I'm very happy I had the chance to work with you,

Livnat

On Sat, Sep 12, 2015 at 12:12 AM, Kyle Mestery  wrote:
> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered the
> concept of rotating PTL duties with each cycle, I'd like to highly encourage
> Neutron and other projects to do the same. Having a deep bench of leaders
> supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.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] [glance] proposed priorities for Mitaka

[John Garbutt]

On 15 September 2015 at 18:22, Monty Taylor  wrote:
> On 09/15/2015 07:09 PM, stuart.mcla...@hp.com wrote:

 I've been looking into the existing task-based-upload that Doug
 mentions:
 can anyone clarify the following?

 On a default devstack install you can do this 'task' call:

 http://paste.openstack.org/show/462919
>>>
>>>
>>> Yup. That's the one.
>>>
 as an alternative to the traditional image upload (the bytes are
 streamed
 from the URL).

 It's not clear to me if this is just an interesting example of the kind
 of operator specific thing you can configure tasks to do, or a real
 attempt to define an alternative way to upload images.

 The change which added it [1] calls it a 'sample'.

 Is it just an example, or is it a second 'official' upload path?
>>>
>>>
>>> It's how you have to upload images on Rackspace.
>>
>>
>> Ok, so Rackspace have a task called image_import. But it seems to take
>> different json input than the devstack version. (A Swift container/object
>> rather than a URL.)
>>
>> That seems to suggest that tasks really are operator specific, that there
>> is no standard task based upload ... and it should be ok to try
>> again with a clean slate.
>
>
> Yes - as long as we don't use the payload as a defacto undefined API to
> avoid having specific things implemented in the API I think we're fine.
>
> Like, if it was:
>
> glance import-image
>
> and that presented an interface that had a status field ... I mean, that's a
> known OpenStack pattern - it's how nova boot works.
>
> Amongst the badness with this is:
>
> a) It's only implemented in one cloud and at that cloud with special code
> b) The interface is "send some JSON to this endpoint, and we'll infer a
> special sub-API from the JSON, which is not a published nor versioned API"

+1 for moving forward with a "works everywhere" upload API.

My memory of the issue here, is the want to validate images, before
allowing users to create instances from that image. If we can get that
working with the regular HTTP upload method, I think we will have
sorted the main issue.

Its more about failing as early as possible and defence in depth,
rather than a specific threat thats not already protected against,
AFAIK.

Forcing copy from swift is handy in terms of reducing glance API load,
but that shouldn't be done at the cost of interoperability.

Thanks,
johnthetubaguy

>>> If you want to see the
>>> full fun:
>>>
>>>
>>> https://github.com/openstack-infra/shade/blob/master/shade/__init__.py#L1335-L1510
>>>
>>>
>>> Which is "I want to upload an image to an OpenStack Cloud"
>>>
>>> I've listed it on this slide in CLI format too:
>>>
>>> http://inaugust.com/talks/product-management/index.html#/27
>>>
>>> It should be noted that once you create the task, you need to poll the
>>> task with task-show, and then the image id will be in the completed
>>> task-show output.
>>>
>>> Monty
>>
>>
>> __
>> OpenStack Development Mailing 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] [keystone] PTL Candidacy

[David Stanek]

Hello everyone,

I'd like to announce my candidacy for the Keystone PTL for the Mitaka cycle.
The project has had great leadership the entire time I have been involved
and
I want to keep up the tradition.

I've been working on Keystone for the past 2 years and I'd like to step up
and take more of a leadership role. I have a long track record of technical
leadership that can be directly applied to Keystone. This includes
everything
from project management to application architecture and many things in
between.

My thoughts on the direction of the project really boil down to landing the
features we have already committed to, taking our experimental features and
making them stable, improving general project stability and expanding our
community.

Goals for this cycle:

* Land the features

  Several features that are very beneficial to the community are currently
  in development. We need to get them stable and shipped for Mitaka. This
  includes, but is not limited to federation, reseller, and centralized
  policy. There is also additional work that needs to be done with
  federation to take it from experimental to stable, like helping other
  projects adapt to the new requirements and making it a first class
OpenStack
  feature.

* Fix the bugs

  We have 293 bugs (at the time of this writing) that need some attention.
  Many have patches that need some work or just need reviews. Others need
  to be investigated and fixed. I'd like to cut this number in half. To do
  that I'd like to get people to focus more on them through activities such
  as bug reviews and bug days (more on that below).

* Expand out testing

  Over the last two cycles we have made some significant advances in our
  testing practices. We need to expand on this cultural shift and even
expand
  the focus on testing.

  The full test runtime needs to be cut by at least 50% to improve developer
  workflow. Near immediate test feedback is important for not breaking flow
  when writing code. This can be accomplished by refactoring test code to
  reduce unnecessary setup and focus on the code being tested.

* Expand our community

  Being PTL isn't about me making all of the decisions or calling all of the
  shots. It's about facilitating the design and development of Keystone by
  working with the community. Through mentoring we can get more developers
  ready to be core to speed up our review pace. We need to work together to
  find ways to give more people the ability to contribute upstream. I do
  believe it's possible to make our thriving community even better.

Thank you for voting for me as your PTL for the Mitaka release cycle.


-- David Stanek
__
OpenStack Development Mailing List (not for 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][gate] grende jobs failing.

[Davanum Srinivas]

Tony,
Looks like the ban is holding up:
https://review.openstack.org/#/c/224429/

-- Dims


On Thu, Sep 17, 2015 at 4:03 AM, Tony Breeds 
wrote:

> On Thu, Sep 17, 2015 at 03:34:30PM +1000, Tony Breeds wrote:
> > On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:
> > > Hi all,
> > > The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
> kilo.  The
> > > juno global-requirements for Babel are not compatible with kilo so
> nothing can
> > > get through grenade :(
> > >
> > > We're working it
> > > https://bugs.launchpad.net/oslo.utils/+bug/1496678
> >
> > Here's my best effort for right now.
> > https://review.openstack.org/#/c/224429/
>
> For those playing along at home the new plan is to:
>  1. Release a version of oslo.utils with the kilo requirements
> This needs to be done as a revert because 1.4.2 must follow 1.4.1
>  - https://review.openstack.org/#/c/224472/
>  2 Tag that as 1.4.2
>
> Then the gate should be okay again, while the stable team (and me) work
> out how
> to fix juno without breaking kilo.
>
> Yours 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
>
>


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

[openstack-dev] [Cinder] PTL Candidacy

[Ivan Kolodyazhny]

Hello everyone,

I'm announcing my candidacy for Cinder PTL for the Mitaka release.

First of all, I would like to thank John and Mike for their great and hard
work making Cinder such a great project with good and a big community.

As a Cinder community we made a great progress not only with new features,
but with improving Cinder quality too. Our community grows quickly and
we are glad to see new contributors again and again.

I've started work with OpenStack since Diablo release. I’ve been an active
contributor to Cinder since Juno cycle [1].

As a Cinder PTL I would like to focus on the following areas of improvements
for the next release cycle:

* Finally move all projects to Cinder API v2 and prepare to remove v1 API.

* Better Cinder integration with other OpenStack projects like Nova and
  Ironic, support Keystone API v3.

* Continue to work on Cinder backups improvements like: scaling,
performance,
  etc.

* Work with driver vendors to stabilize third party CI. I believe,
  every PTL candidate will have this item on the list.

* Improve Cinder test coverage and quality: we need to get functional tests,
  better Tempest and Rally coverage, make our unit tests better

We need to continue to be open for developers community and operators
needs. Improving quality and growing the community are the tasks which
should
be done indefinitely. But we need to keep balance between new features
development and support of existing ones by all drivers and stability of
Cinder project.

[1] http://stackalytics.com/report/contribution/cinder/180

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

Re: [openstack-dev] [glance] proposed priorities for Mitaka

[John Garbutt]

On 14 September 2015 at 16:27, Thierry Carrez  wrote:
> Doug Hellmann wrote:
>> [...]
>> 1. Resolve the situation preventing the DefCore committee from
>>including image upload capabilities in the tests used for trademark
>>and interoperability validation.
>>
>> 2. Follow through on the original commitment of the project to
>>provide an image API by completing the integration work with
>>nova and cinder to ensure V2 API adoption.
>> [...]
>
> Thanks Doug for taking the time to dive into Glance and to write this
> email. I agree with your top two priorities as being a good summary of
> what the "rest of the community" expects the Glance leadership to focus
> on in the very short term.

Sorry for going back in time, but...

+1

This is a great summary of things, and I agree with the large strokes
of what is being suggested here.

Thank for helping ignite a very worthwhile debate here.

Thanks,
johnthetubaguy

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

Re: [openstack-dev] [cinder] LVM snapshot performance issue -- why isn't thin provisioning the default?

[Duncan Thomas]

On 16 September 2015 at 23:43, Eric Harney  wrote:

> Currently, at least some options set in [DEFAULT] don't apply to
> per-driver sections, and require you to set them in the driver section
> as well.
>

This is extremely confusing behaviour. Do you have any examples? I'm not
sure if we can fix it without breaking people's existing configs but I
think it is worth trying. I'll add it to the list of things to talk about
briefly in Tokyo.

-- 
Duncan Thomas
__
OpenStack Development Mailing List (not for 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][gate] grende jobs failing.

[Tony Breeds]

On Thu, Sep 17, 2015 at 06:22:47AM -0400, Davanum Srinivas wrote:
> Tony,
> Looks like the ban is holding up:
> https://review.openstack.org/#/c/224429/

Sorry yes.  Robert Collins pointed out that my new quicker plan wasn't going to
work so we went back to the original ban 1.4.1 solution.

It looks like the gate is mostly green again.

If people have grenade jobs that failed, a recheck shoudl fix that.

Thanks to all those that pushed on this to get things going again.

Yours Tony.


pgpXVil6P3oMn.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] [Barbican] Providing service user read access to all tenant's certificates

[Dave McCowan (dmccowan)]

The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
OpenStack Development Mailing List (not for 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] Is magnum db going to be removed for k8s resources?

[Jay Lau]

Anyone who have some comments/suggestions on this? Thanks!

On Mon, Sep 14, 2015 at 3:57 PM, Jay Lau  wrote:

> Hi Vikas,
>
> Thanks for starting this thread. Here just show some of my comments here.
>
> The reason that Magnum want to get k8s resource via k8s API including two
> reasons:
> 1) Native clients support
> 2) With current implantation, we cannot get pod for a replication
> controller. The reason is that Magnum DB only persist replication
> controller info in Magnum DB.
>
> With the bp of objects-from-bay, the magnum will always call k8s API to
> get all objects for pod/service/rc. Can you please show some of your
> concerns for why do we need to persist those objects in Magnum DB? We may
> need to sync up Magnum DB and k8s periodically if we persist two copies of
> objects.
>
> Thanks!
>
> 
>
> 2015-09-14 14:39 GMT+08:00 Vikas Choudhary :
>
>> Hi Team,
>>
>> As per object-from-bay blueprint implementation [1], all calls to magnum db
>> are being skipped for example pod.create() etc.
>>
>> Are not we going to use magnum db at all for pods/services/rc ?
>>
>>
>> Thanks
>> Vikas Choudhary
>>
>>
>> [1] https://review.openstack.org/#/c/213368/
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>



-- 
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-dev] [Neutron] Effective Neutron

[Armando M.]

Hi fellow developers and reviewers,

Some of you may have noticed that I put together patch [1] up for review.

The intention of this initiative is to capture/share 'pills of wisdom' when
it comes to Neutron development and reviewing. In fact, there are a number
of common patterns (or anti-patterns) that we keep stumbling on, and I came
to the realization that if we all stopped for a second and captured those
in writing for any newcomer (or veteran) to see, we would all benefit
during code reviews and development, because we'd all know what to watch
out for. The wishful thinking is that once this document reaches critical
mass, we will all have learned how to avoid common mistakes and get our
patches merged swiftly.

It is particularly aimed at the Neutron contributor and it is not meant to
replace the wealth of information that is available on doc.openstack.org,
the wiki or the Internet. This is also not meant to be a cross-project
effort, because let's face it...every project is different, and pills of
wisdom in Neutron may as well be everyone's knowledge in Heat, etc.

I aim to add more material over the next couple of days, also with the help
of some of you, so bear with me while the patch is in WIP.

Feedback welcome.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/224419/
__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Anne Gentle]

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor  wrote:

> On 09/17/2015 04:50 PM, Anita Kuno wrote:
>
>> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>>
>>>
>>>
>>> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>>>
 PTL Nomination is now over. The official candidate list is available on
 the wiki[0].

 There are 5 projects without candidates, so according to this
 resolution[1], the TC we'll have to appoint a new PTL for Barbican,
 MagnetoDB, Magnum, Murano and Security

>>>
>>> This is devil's advocate, but why does a project technically need a PTL?
>>>   Just so that there can be a contact point for cross-project things,
>>> i.e. a lightning rod?  There are projects that do a lot of group
>>> leadership/delegation/etc, so it doesn't seem that a PTL is technically
>>> required in all cases.
>>>
>>
>> I think that is a great question for the TC to consider when they
>> evaluate options for action with these projects.
>>
>> The election officials are fulfilling their obligation according to the
>> resolution:
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
>>
>> If you read the verb there the verb is "can" not "must", I choose the
>> verb "can" on purpose for the resolution when I wrote it. The TC has the
>> option to select an appointee. The TC can do other things as well,
>> should the TC choose.
>>
>
> I agree- and this is a great example of places where human judgement is
> better than rules.
>
> For instance - one of the projects had a nominee but it missed the
> deadline, so that's probably an easy on.
>

Honestly I did the "Thursday" alignment math in my head and thought of it
in my non-futuristic timezone. Plus I have a Thursday release mentality
thanks to Theirry's years of excellent release management. :)

Plus, I further confused a couple of candidates when encouraging candidacy
posts, so I apologize for that! I am trying to get ahead of what we'll have
to do on the TC anyway.

I'd like to apply some common sense here and if this many candidates on
both sides of the globe got confused, we can still take that into
consideration when taking next steps.


>
> For one of the projects it had been looking dead for a while, so this is
> the final nail in the coffin from my POV
>

I'm not sure we've defined a coffin really, more of an attic/shelving
system. :)

I'll definitely take some time to follow up with individuals in this
deadline confusion system when we take next steps on the TC.

Anne


>
> For the other three - I know they're still active projects with people
> interested in them, so sorting them out will be fun!
>
>
>
>>
>>>
 There are 7 projects that will have an election: Cinder, Glance, Ironic,
 Keystone, Mistral, Neutron and Oslo. The details for those will be
 posted tomorrow after Tony and I setup the CIVS system.

 Thank you,
 Tristan


 [0]:

 https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

 [1]:

 http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html






 __

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


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



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Thierry Carrez]

Monty Taylor wrote:
> I agree- and this is a great example of places where human judgement is
> better than rules.
> 
> For instance - one of the projects had a nominee but it missed the
> deadline, so that's probably an easy on.
> 
> For one of the projects it had been looking dead for a while, so this is
> the final nail in the coffin from my POV
> 
> For the other three - I know they're still active projects with people
> interested in them, so sorting them out will be fun!

Looks like in 4 cases (Magnum, Barbican, Murano, Security) there is
actually a candidate, they just missed the deadline. So that should be
an easy discussion at the next TC meeting.

For the last one, it is not an accident. I think it is indeed the final
nail on the coffin.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

[Martin André]

On Thu, Sep 17, 2015 at 3:22 AM,  wrote:

> There is an apparent need for having official RHOS being supported from
> our end, and we just so happen to have the possibility of filling that
> need. Should the need arise to support whatever fancy proprietary backend
> system or even have Kolla integrate with Oracle Solaris or something, that
> need would most probably be backed by a company plus developer effort. I
> believe the burden for our current (great) team would more or less stay the
> same (eg. lets assume we don't know anything about Solaris), so this
> company should ship in devvers to aid their 'wish'. The team effort with
> these additional devvers would indeed grow, bigtime. Keeping our eyes on
> the matters feels like a fair solution, allowing for these additions while
> guarding the effort they take. Should Kolla start supporting LXC besides
> Docker, that would be awesome (uhm...) - but I honestly don't see a need to
> be thinking about that right now, if someone comes up with a spec about it
> and wants to invest time+effort we can atleast review it. We shouldn't
> prepare our Dockerfiles for such a possibility though, whereas the
> difference between RHOS and CentOS is very little. Hence, support is rather
> easy to implement.
>
> The question was if Kolla wants/should support integrating with 3rd party
> tools, and I think we should support it. There should be rules, yes. We
> probably shouldn't be worrying about proprietary stuff that other projects
> hardly take seriously (even though drivers have been accepted)...
>
> Vote: +1
>
> - harmw
>
> Sam Yaple schreef op 2015-09-14 13:44:
>
>> On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke 
>> wrote:
>>
>> On 13/09/15 18:34, Steven Dake (stdake) wrote:
>>>
>>> Response inline.

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Sunday, September 13, 2015 at 1:35 AM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake)
 > wrote:
 Response inline.

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Saturday, September 12, 2015 at 11:34 PM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 Sam Yaple

 On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake)
 > wrote:

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Saturday, September 12, 2015 at 11:01 PM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake)
 > wrote:
 Hey folks,

 Sam had asked a reasonable set of questions regarding a patchset:
 https://review.openstack.org/#/c/222893/ [1]


 The purpose of the patchset is to enable both RDO and RHOS as
 binary choices on RHEL platforms.  I suspect over time,
 from-source deployments have the potential to become the norm, but
 the business logistics of such a change are going to take some
 significant time to sort out.

 Red Hat has two distros of OpenStack neither of which are from
 source.  One is free called RDO and the other is paid called
 RHOS.  In order to obtain support for RHEL VMs running in an
 OpenStack cloud, you must be running on RHOS RPM binaries.  You
 must also be running on RHEL.  It remains to be seen whether Red
 Hat will actively support Kolla deployments with a RHEL+RHOS set
 of packaging in containers, but my hunch says they will.  It is
 in Kolla’s best interest to implement this model and not make it
 hard on Operators since many of them do indeed want Red Hat’s
 support structure for their OpenStack deployments.

 Now to Sam’s questions:

Re: [openstack-dev] [all][gate] grende jobs failing.

[Davanum Srinivas]

+1 for range checking and stable team +2's in openstack/releases repo

-- dims

On Thu, Sep 17, 2015 at 10:05 AM, Matt Riedemann  wrote:

>
>
> On 9/17/2015 7:23 AM, Tony Breeds wrote:
>
>> On Thu, Sep 17, 2015 at 06:22:47AM -0400, Davanum Srinivas wrote:
>>
>>> Tony,
>>> Looks like the ban is holding up:
>>> https://review.openstack.org/#/c/224429/
>>>
>>
>> Sorry yes.  Robert Collins pointed out that my new quicker plan wasn't
>> going to
>> work so we went back to the original ban 1.4.1 solution.
>>
>> It looks like the gate is mostly green again.
>>
>> If people have grenade jobs that failed, a recheck shoudl fix that.
>>
>> Thanks to all those that pushed on this to get things going again.
>>
>> Yours 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
>>
>>
> As noted in the stable/kilo block on 1.4.1, we're good until we do a 1.4.2
> release at which point we either break juno or we break kilo since they
> overlap in supported version ranges.
>
> I've asked Tony to push a requirements change on stable/juno and
> stable/kilo to add a note next to oslo.utils reminding us of this so we
> think twice before breaking it again (we should really make this part of
> the openstack/releases review process - to check that the proposed version
> change isn't going to show up in a branch that we don't intend it do).
> Because if the proposed release has a g-r sync for branch n and the version
> will show up in branch n-1 or n+1, things will likely break.
>
> Hopefully we just don't need an oslo.utils release on juno or kilo before
> juno-eol happens.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Matt Riedemann]

On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


This is devil's advocate, but why does a project technically need a PTL? 
 Just so that there can be a contact point for cross-project things, 
i.e. a lightning rod?  There are projects that do a lot of group 
leadership/delegation/etc, so it doesn't seem that a PTL is technically 
required in all cases.




There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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



--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Morgan Fainberg]

Time.is is showing utc in "PM" not a 24 hour clock. It is past 1500 UTC at the 
moment. 

Sent via mobile

> On Sep 17, 2015, at 08:05, Douglas Mendizábal 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I think someone jumped the gun on this thread.  According to the wiki
> [1] the cutoff time is not until 5:59 UTC, which
> doesn't happen for another few hours. [2]
> 
> Am I missing something?
> 
> [1] https://wiki.openstack.org/wiki/PTL_Elections_September_2015
> [2] http://time.is/UTC
> 
> Douglas Mendizábal
> 
>> On 9/17/15 9:50 AM, Anita Kuno wrote:
>>> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>>> 
>>> 
 On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
 PTL Nomination is now over. The official candidate list is 
 available on the wiki[0].
 
 There are 5 projects without candidates, so according to this 
 resolution[1], the TC we'll have to appoint a new PTL for 
 Barbican, MagnetoDB, Magnum, Murano and Security
>>> 
>>> This is devil's advocate, but why does a project technically
>>> need a PTL? Just so that there can be a contact point for 
>>> cross-project things, i.e. a lightning rod?  There are projects 
>>> that do a lot of group leadership/delegation/etc, so it doesn't 
>>> seem that a PTL is technically required in all cases.
>> 
>> I think that is a great question for the TC to consider when they 
>> evaluate options for action with these projects.
>> 
>> The election officials are fulfilling their obligation according
>> to the resolution: 
>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20
> 141128-elections-process-for-leaderless-programs.rst
> If you read the verb there the verb is "can" not "must", I choose
>> the verb "can" on purpose for the resolution when I wrote it. The 
>> TC has the option to select an appointee. The TC can do other 
>> things as well, should the TC choose.
>> 
>> Thanks, Anita.
>> 
>>> 
 
 There are 7 projects that will have an election: Cinder, 
 Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The 
 details for those will be posted tomorrow after Tony and I 
 setup the CIVS system.
 
 Thank you, Tristan
 
 
 [0]: 
 https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirm
> ed_Candidates
> [1]:
 http://governance.openstack.org/resolutions/20141128-elections-proce
> ss-for-leaderless-programs.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
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
> 
> iQIcBAEBCgAGBQJV+tawAAoJEB7Z2EQgmLX7WKIP/RUdGYOkA5dHuNnWKdX8QhaD
> VzZSyTOjIebNZshiMIz8FhKGrFUn8wqEScbtUIFHIJj8tKVjZQ19m2Gg6zh42X6V
> kpogxGDBwE5a/vuBA1z9eiTocA4KYEypxY+SIh18ho84dj5hDooI9N7ZsCJaaF3+
> yKTLvUw7YxMM2iPxjZgQTH1vE1pMUh2fcylv3T3NhpHzIRgeB9dfnfr938rnwUTj
> NUTK3DmWJAraAgHcKnwIN+JwOYF1SexXFK1eO2TX0yNYSEzFI3Xina0Hq3bHAON9
> KbWlgr4pN19PsqqQnQrPjJbBmBs8TCkXNhTAojHtlA1oIbUiK8c3h32PHEt2AyCx
> 5g3btXOAqsCqvKtmFH1sj5EACeMUCW4J98u8e212iQPizgG9SD4LZ8FPPHOqWMwV
> 4haWpWLczZyXf7w7/deP4gndoW7njU/uiwCUNBrgdjI5AeaP5vckHQZ9iQmETsRa
> bwwu5Yq7K92rAupVRFx4bofTyG4I8bw+Lg2muYMnwuqvgf++xqsMVs0x97jFYja5
> M2qGMgihYDytDoYvdL71WykuN39SzZmPHzxKXKmiOcTXWhAXp10pBwFUFzFJmt+V
> /tNjHfzvqt6qvnDEtt65vuwGBEQyiQFqmKmyPFCONCibn8nwoqjwP9hWmG4y1vVa
> geegYxrikuEQ3KnPFQWr
> =jON5
> -END 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

__
OpenStack Development Mailing List (not for 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] Effective Neutron

[Gary Kotton]

Thanks for marking as WPI

From: "Armando M." >
Reply-To: OpenStack List 
>
Date: Thursday, September 17, 2015 at 6:20 PM
To: OpenStack List 
>
Subject: [openstack-dev] [Neutron] Effective Neutron

Hi fellow developers and reviewers,

Some of you may have noticed that I put together patch [1] up for review.

The intention of this initiative is to capture/share 'pills of wisdom' when it 
comes to Neutron development and reviewing. In fact, there are a number of 
common patterns (or anti-patterns) that we keep stumbling on, and I came to the 
realization that if we all stopped for a second and captured those in writing 
for any newcomer (or veteran) to see, we would all benefit during code reviews 
and development, because we'd all know what to watch out for. The wishful 
thinking is that once this document reaches critical mass, we will all have 
learned how to avoid common mistakes and get our patches merged swiftly.

It is particularly aimed at the Neutron contributor and it is not meant to 
replace the wealth of information that is available on 
doc.openstack.org, the wiki or the Internet. This is 
also not meant to be a cross-project effort, because let's face it...every 
project is different, and pills of wisdom in Neutron may as well be everyone's 
knowledge in Heat, etc.

I aim to add more material over the next couple of days, also with the help of 
some of you, so bear with me while the patch is in WIP.

Feedback welcome.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/224419/
__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Monty Taylor]

On 09/17/2015 04:50 PM, Anita Kuno wrote:

On 09/17/2015 08:22 AM, Matt Riedemann wrote:



On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


This is devil's advocate, but why does a project technically need a PTL?
  Just so that there can be a contact point for cross-project things,
i.e. a lightning rod?  There are projects that do a lot of group
leadership/delegation/etc, so it doesn't seem that a PTL is technically
required in all cases.


I think that is a great question for the TC to consider when they
evaluate options for action with these projects.

The election officials are fulfilling their obligation according to the
resolution:
http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

If you read the verb there the verb is "can" not "must", I choose the
verb "can" on purpose for the resolution when I wrote it. The TC has the
option to select an appointee. The TC can do other things as well,
should the TC choose.


I agree- and this is a great example of places where human judgement is 
better than rules.


For instance - one of the projects had a nominee but it missed the 
deadline, so that's probably an easy on.


For one of the projects it had been looking dead for a while, so this is 
the final nail in the coffin from my POV


For the other three - I know they're still active projects with people 
interested in them, so sorting them out will be fun!








There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html





__

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






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




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

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Kevin Benton]

Yes, the L2 semantics apply to the external network as well (at least with
ML2).

One example of the special casing is the external_network_bridge option in
the L3 agent. That would cause the agent to plug directly into a bridge so
none of the normal L2 agent wiring would occur. With the L2 bridge_mappings
option there is no reason for this to exist anymore because it ignoring
network attributes makes debugging a nightmare.

>Yes, that makes sense.  Clearly the core semantic there is IP.  I can
imagine reasonable variation on less core details, e.g. L2 broadcast vs.
NBMA.  Perhaps it would be acceptable, if use cases need it, for such
details to be described by flags on the external network object.

An external network object is just a regular network object with a
router:external flag set to true. Any changes to it would have to make
sense in the context of all networks. That's why I want to make sure that
whatever we come up with makes sense in all contexts and isn't just a bolt
on corner case.
On Sep 17, 2015 8:21 AM, "Neil Jerram"  wrote:

> Thanks, Kevin.  Some further queries, then:
>
> On 17/09/15 15:49, Kevin Benton wrote:
> >
> > It's not true for all plugins, but an external network should provide
> > the same semantics of a normal network.
> >
> Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> I'm also wondering about what you wrote in the recent thread with Carl
> about representing a network connected by routers.  I think you were
> arguing that a L3-only network should not be represented by a kind of
> Neutron network object, because a Neutron network has so many L2
> properties/semantics that it just doesn't make sense, and better to have
> a different kind of object for L3-only.  Do those L2
> properties/semantics apply to an external network too?
>
> > The only difference is that it allows router gateway interfaces to be
> > attached to it.
> >
> Right.  From a networking-calico perspective, I think that means that
> the implementation should (eventually) support that, and hence allow
> interconnection between the external network and private Neutron networks.
>
> > We want to get rid of as much special casing as possible for the
> > external network.
> >
> I don't understand here.  What 'special casing' do you mean?
>
> Regards,
> Neil
>
> > On Sep 17, 2015 7:02 AM, "Neil Jerram"  > > wrote:
> >
> > Thanks to the interesting 'default network model' thread, I now know
> > that Neutron allows booting a VM on an external network. :-)  I
> didn't
> > realize that before!
> >
> > So, I'm now wondering what connectivity semantics are expected (or
> > even
> > specified!) for such VMs, and whether they're the same as - or very
> > similar to - the 'routed' networking semantics I've described at [1].
> >
> > [1]
> >
> https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
> >
> > Specifically I wonder if VM's attached to an external network
> > expect any
> > particular L2 characteristics, such as being able to L2 broadcast to
> > each other?
> >
> > By way of context - i.e. why am I asking this?...   The
> > networking-calico project [2] provides an implementation of the
> > 'routed'
> > semantics at [1], but only if one suspends belief in some of the
> > Neutron
> > semantics associated with non-external networks, such as needing a
> > virtual router to provide connectivity to the outside world.
> (Because
> > networking-calico provides that external connectivity without any
> > virtual router.)  Therefore we believe that we need to propose some
> > enhancement of the Neutron API and data model, so that Neutron can
> > describe 'routed' semantics as well as all the traditional ones.
> But,
> > if what we are doing is semantically equivalent to 'attaching to an
> > external network', perhaps no such enhancement is needed...
> >
> > [2] https://git.openstack.org/cgit/openstack/networking-calico
> > 
> >
> > Many thanks for any input!
> >
> > Neil
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List 

Re: [openstack-dev] [Neutron] Effective Neutron

[Sean M. Collins]

On Thu, Sep 17, 2015 at 11:37:35AM EDT, Edgar Magana wrote:
> Actually, I am wondering if replacing the Wiki with this great information 
> will be better???
> For sure, docs are well structured and they have a great team behind them but 
> the wikis are not the same, gerrit review provide a better way to distribute 
> and update this knowledge…

+1 - I've fallen out of love with Wikis for this exact reason. 

-- 
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] [all][elections] PTL nomination period is now over

[Clark, Robert Graham]

Likewise, I'm not sure I missed the candidacy window, I think our late 
mid-cycle threw things out of whack slightly.

When I saw the Magnum nomination I made a mental note to apply today. This is a 
poor-show on my part and I apologise to the TC, the community and the Security 
team for this apparent lack of awareness. 

Five projects without candidates seems like a lot, especially as several of 
them are very active. I think perhaps this is a busy time of year and like me a 
number of people were not paying close enough attention to the election window.

I understand that the official window for nominations has now closed, I'd like 
to understand more about how the process detailed in [1] below will operate, 
many of these projects have established PTLs (like me) who are obviously not 
great at tracking dates (like me) but still very much want to continue to lead 
in their communities (like me). I'd like to better understand what happens next.

-Rob



> -Original Message-
> From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com]
> Sent: 17 September 2015 14:56
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][elections] PTL nomination period is now 
> over
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> This is quite unfortunate, as I was intending to submit my candidacy
> for the Barbican project today, but I did not realize the cutoff time
> would be in the morning in CDT.
> 
> I'd like to apologize to the OpenStack community and the Barbican team
> in particular for missing this deadline.
> 
> Thanks,
> 
> Douglas Mendizábal
> 
> On 9/17/15 8:49 AM, Flavio Percoco wrote:
> > On 17/09/15 13:44 +, Tristan Cacqueray wrote:
> >> On 09/17/2015 01:32 PM, Flavio Percoco wrote:
> >>> On 17/09/15 13:25 +, Tristan Cacqueray wrote:
>  PTL Nomination is now over. The official candidate list is
>  available on the wiki[0].
> 
>  There are 5 projects without candidates, so according to
>  this resolution[1], the TC we'll have to appoint a new PTL
>  for Barbican, MagnetoDB, Magnum, Murano and Security
> >>>
> >>> Magnum had a candidacy on the mailing list. I'd assume this is
> >>> because it wasn't proposed to openstack/election. Right?
> >>
> >> That is correct, but the candidacy was submitted after the
> >> deadlines so we can't validate this candidate.
> >
> > Awesome, thanks for the confirmation. Flavio
> >
> >>
> >>>
> >>> Thanks for the hard work here, Flavio
> >>>
> 
>  There are 7 projects that will have an election: Cinder,
>  Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The
>  details for those will be posted tomorrow after Tony and I
>  setup the CIVS system.
> 
>  Thank you, Tristan
> 
> 
>  [0]:
>  https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confir
> med_Candidates
> 
> 
> 
> 
> [1]:
>  http://governance.openstack.org/resolutions/20141128-elections-proc
> ess-for-leaderless-programs.html
> 
> 
> 
> 
> >>>
> >>>
> >>>
> 
> 
> 
> __
> 
> 
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>>
> >>> 
> __
> >>>
> >>>
> >>>
> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >
> >>>
> >
> >
> >
> >
> > __
> 
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - https://gpgtools.org
> 
> iQIcBAEBCgAGBQJV+saCAAoJEB7Z2EQgmLX7XG0P/AqOTGDDbVJrJSTPnCGwtqYd
> 275uDQgWqvbsGMKOrfKO7GBgI/5n/j8hCyiipq6niCfW5eWWH7rYgU1pLKLjiZmR
> 12Ui4PwkqvoJEa0J5NIiM8GOrt2TEDTu7vOQAWMzGEn+8fbs7Z9MRPIAg7bEXuk0
> eQNs5LK6j/INXvuuKm4ZV2MjAxJRbtsSZYVn59U4IxM0GSJIC4MLu8dGaRzf+G8B
> 881hflBskg1Sa5UjEcj/yMUDrtBLOyNkM67dv8M9ojNB0bX3o+US8zmJnsbk6whD
> ox3GrgoxT8he6iMNd/YYycFtBlBZ4fqNN8Uv5Vr/+k8s2umJf7Y3IbM2oQuhM1oJ
> mWuwFbyc440ep9WkBeXeZTm0S0FYwR3MS40nW2D04eHEcTbCHchKIoLp/tO0AKYP
> op116JlzTyWZatywL8rIOner4UJQX6yUqmGRdonACNQ6OAzTLTTaARtwqHacxL81
> UqzOLEQ8nW9p5xCTPWhbPbR7t1T7ngwf5bJAuDKVx9JDUsM+mYjZ7smWdg+PV1yS
> SwW94TzImOV4ujiT7AwzUBz6SZ0jHFt5yXVWscggpj5k7l8lPqFhd4xQVvidqLcZ
> VsHfKwfdfWX22z+97n4/GjEd6B0seZqcxoP4qVsXXgpuFJETVLEifDM9DTOLccxy
> xQR6UpOxTZxl5EdiOpxX
> =nraX
> -END PGP SIGNATURE-
> 
> 

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

[Joshua Harlow]

Agreed, +1 :)

Gotta start somewhere to get to somewhere else ;)

mhorban wrote:

Hi Josh,

 > Sounds like a useful idea if projects can plug-in themselves into the
 > reloading process. I definitely think there needs to be a way for
 > services to plug-in to this, although I'm not quite sure it will be
 > sufficient at the current time though.
 >
 > An example of why:
 >
 > -
 >
https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24

 > (unless this module is purged from python and reloaded it will likely
 > not reload correctly).
 >
 > Likely these can all be easily fixed (I just don't know how many of
 > those exist in the various projects); but I guess we have to start
 > somewhere so getting the underlying code able to be reloaded is a first
 > step of likely many.

Each of openstack component should contain code responsible for
reloading such objects.
What objects will be reloaded? It depends of inspire and desire of
developers/users.
Writing such code is a second step.

Marian

__
OpenStack Development Mailing 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][elections] PTL nomination period is now over

[Kyle Mestery]

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor  wrote:

> On 09/17/2015 04:50 PM, Anita Kuno wrote:
>
>> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>>
>>>
>>>
>>> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>>>
 PTL Nomination is now over. The official candidate list is available on
 the wiki[0].

 There are 5 projects without candidates, so according to this
 resolution[1], the TC we'll have to appoint a new PTL for Barbican,
 MagnetoDB, Magnum, Murano and Security

>>>
>>> This is devil's advocate, but why does a project technically need a PTL?
>>>   Just so that there can be a contact point for cross-project things,
>>> i.e. a lightning rod?  There are projects that do a lot of group
>>> leadership/delegation/etc, so it doesn't seem that a PTL is technically
>>> required in all cases.
>>>
>>
>> I think that is a great question for the TC to consider when they
>> evaluate options for action with these projects.
>>
>> The election officials are fulfilling their obligation according to the
>> resolution:
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
>>
>> If you read the verb there the verb is "can" not "must", I choose the
>> verb "can" on purpose for the resolution when I wrote it. The TC has the
>> option to select an appointee. The TC can do other things as well,
>> should the TC choose.
>>
>
> I agree- and this is a great example of places where human judgement is
> better than rules.
>
> For instance - one of the projects had a nominee but it missed the
> deadline, so that's probably an easy on.
>
> For one of the projects it had been looking dead for a while, so this is
> the final nail in the coffin from my POV
>
> For the other three - I know they're still active projects with people
> interested in them, so sorting them out will be fun!
>
>
This is the right approach. Human judgement #ftw! :)


>
>
>>
>>>
 There are 7 projects that will have an election: Cinder, Glance, Ironic,
 Keystone, Mistral, Neutron and Oslo. The details for those will be
 posted tomorrow after Tony and I setup the CIVS system.

 Thank you,
 Tristan


 [0]:

 https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

 [1]:

 http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html






 __

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


>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Tristan Cacqueray]

On 09/17/2015 03:05 PM, Douglas Mendizábal wrote:
> I think someone jumped the gun on this thread.  According to the wiki
> [1] the cutoff time is not until 5:59 UTC, which
> doesn't happen for another few hours. [2]
> 
> Am I missing something?
> 
> [1] https://wiki.openstack.org/wiki/PTL_Elections_September_2015
> [2] http://time.is/UTC
> 
> Douglas Mendizábal
> 


Hi Douglas,

UTC time is now:  "Thu Sep 17 15:16:46 UTC 2015".
The deadline was: "Thu Sep 17 05:59:00 UTC 2015"

You can check UTC time using this command line "TZ=UTC date".

Regards,
Tristan



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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Tony Breeds]

On Thu, Sep 17, 2015 at 10:05:20AM -0500, Douglas Mendizábal wrote:
 
> I think someone jumped the gun on this thread.  According to the wiki
> [1] the cutoff time is not until 5:59 UTC, which
> doesn't happen for another few hours. [2]
> 
> Am I missing something?

From the wiki[0]:
---
Timeline
September 11 - September 17, 05:59 UTC: Open candidacy for PTL positions
September 18 - September 24: PTL elections
---

The time in UTC is: http://www.timeanddate.com/worldclock/timezone/utc
which, at the time of this writing, is: Sept 17th 15:20ish

So the nomination period closed nearly 10 hours ago.

The time-frame to be eligible to vote in the election closes at 5:59am on Sept
18th (UTC)

I hope that clarifies.

Yours Tony.
[0] https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Timeline


pgpkUsTVzUGSU.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] [Neutron] Effective Neutron

[Edgar Magana]

Actually, I am wondering if replacing the Wiki with this great information will 
be better???
For sure, docs are well structured and they have a great team behind them but 
the wikis are not the same, gerrit review provide a better way to distribute 
and update this knowledge…

Great initiative Armax!

BTW. Gary is WPI = Work Provided Intentionally  or What the Problem Is?? ;-)

Edgar

From: Gary Kotton
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, September 17, 2015 at 8:27 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [Neutron] Effective Neutron

Thanks for marking as WPI

From: "Armando M." >
Reply-To: OpenStack List 
>
Date: Thursday, September 17, 2015 at 6:20 PM
To: OpenStack List 
>
Subject: [openstack-dev] [Neutron] Effective Neutron

Hi fellow developers and reviewers,

Some of you may have noticed that I put together patch [1] up for review.

The intention of this initiative is to capture/share 'pills of wisdom' when it 
comes to Neutron development and reviewing. In fact, there are a number of 
common patterns (or anti-patterns) that we keep stumbling on, and I came to the 
realization that if we all stopped for a second and captured those in writing 
for any newcomer (or veteran) to see, we would all benefit during code reviews 
and development, because we'd all know what to watch out for. The wishful 
thinking is that once this document reaches critical mass, we will all have 
learned how to avoid common mistakes and get our patches merged swiftly.

It is particularly aimed at the Neutron contributor and it is not meant to 
replace the wealth of information that is available on 
doc.openstack.org, the wiki or the Internet. This is 
also not meant to be a cross-project effort, because let's face it...every 
project is different, and pills of wisdom in Neutron may as well be everyone's 
knowledge in Heat, etc.

I aim to add more material over the next couple of days, also with the help of 
some of you, so bear with me while the patch is in WIP.

Feedback welcome.

Many thanks,
Armando

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

Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu

[Assaf Muller]

Another issue is that the gate is running with Ubuntu 14.04, which is
running OVS 2.0. This means we can't test
certain features in Neutron (For example, the OVS ARP responder).

On Thu, Sep 17, 2015 at 4:17 AM, Gal Sagie  wrote:

> Hello Li Ma,
>
> Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need
> OVS 2.3.1.
> As suggested you can build it from source.
> For Fedora 21 OVS2.3.1 is part of the default yum repository.
>
> You can ping me on IRC (gsagie at freenode) if you need any additional
> help how
> to compile OVS.
>
> Thanks
> Gal.
>
> On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <
> sbisw...@linux.vnet.ibm.com> wrote:
>
>>
>>
>> On Thursday 17 September 2015 12:22 PM, Li Ma wrote:
>>
>>> Hi all,
>>>
>>> I tried to run devstack to deploy dragonflow, but I failed with lower
>>> OVS version.
>>>
>>> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
>>> which is much lower than the required version 2.3.1+?
>>>
>>> So, can anyone provide a Ubuntu repository that contains the correct
>>> OVS packages?
>>>
>>
>> Why don't you just build the OVS you want from here:
>> http://openvswitch.org/download/
>>
>> Thanks,
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing 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][elections] PTL nomination period is now over

[Edgar Magana]

Folks,

Last year I found myself in the same position when I missed a deadline because 
my wrong planning and time zones nightmare!
However, the rules were very clear and I assumed my mistake. So, we should 
assume that we do not have candidates and follow the already described process. 
However, this should be very easy to figure out for the TC, it is just a matter 
to find our who is interested in the PTL role and consulting with the core team 
of that specific project.

Just my two cents…

Edgar

From: Kyle Mestery
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, September 17, 2015 at 8:48 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [all][elections] PTL nomination period is now over

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor 
> wrote:
On 09/17/2015 04:50 PM, Anita Kuno wrote:
On 09/17/2015 08:22 AM, Matt Riedemann wrote:


On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security

This is devil's advocate, but why does a project technically need a PTL?
  Just so that there can be a contact point for cross-project things,
i.e. a lightning rod?  There are projects that do a lot of group
leadership/delegation/etc, so it doesn't seem that a PTL is technically
required in all cases.

I think that is a great question for the TC to consider when they
evaluate options for action with these projects.

The election officials are fulfilling their obligation according to the
resolution:
http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

If you read the verb there the verb is "can" not "must", I choose the
verb "can" on purpose for the resolution when I wrote it. The TC has the
option to select an appointee. The TC can do other things as well,
should the TC choose.

I agree- and this is a great example of places where human judgement is better 
than rules.

For instance - one of the projects had a nominee but it missed the deadline, so 
that's probably an easy on.

For one of the projects it had been looking dead for a while, so this is the 
final nail in the coffin from my POV

For the other three - I know they're still active projects with people 
interested in them, so sorting them out will be fun!


This is the right approach. Human judgement #ftw! :)





There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html





__

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




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



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

__
OpenStack Development Mailing List (not for 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] Effective Neutron

[Kyle Mestery]

On Thu, Sep 17, 2015 at 10:20 AM, Armando M.  wrote:

> Hi fellow developers and reviewers,
>
> Some of you may have noticed that I put together patch [1] up for review.
>
> The intention of this initiative is to capture/share 'pills of wisdom'
> when it comes to Neutron development and reviewing. In fact, there are a
> number of common patterns (or anti-patterns) that we keep stumbling on, and
> I came to the realization that if we all stopped for a second and captured
> those in writing for any newcomer (or veteran) to see, we would all benefit
> during code reviews and development, because we'd all know what to watch
> out for. The wishful thinking is that once this document reaches critical
> mass, we will all have learned how to avoid common mistakes and get our
> patches merged swiftly.
>
> It is particularly aimed at the Neutron contributor and it is not meant to
> replace the wealth of information that is available on doc.openstack.org,
> the wiki or the Internet. This is also not meant to be a cross-project
> effort, because let's face it...every project is different, and pills of
> wisdom in Neutron may as well be everyone's knowledge in Heat, etc.
>
> I aim to add more material over the next couple of days, also with the
> help of some of you, so bear with me while the patch is in WIP.
>
> Feedback welcome.
>
>
Thanks for sending this out and working on this patch Armando. This is
going to greatly assist everyone working on Neutron. Nice job!

Kyle


> Many thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/224419/
>
> __
> OpenStack Development Mailing 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] [Security] Leadership / Participation in PTL elections.

[Clark, Robert Graham]

Security Folks,

Some how I missed the window to nominate myself as a PTL candidate for
Security. I have literally no idea how I missed it. I’ve been working on
Security project things all week (Anchor and OSSNs mainly) so it’s not like I
wasn’t thinking about the Security team!

Anyway, I missed the voting window (as did a few others it would seem) and this
makes me very sad, the PTL position will now be decided by the OpenStack
technical committee in line with:

http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

Although it will get –2 because it is late, I have submitted my candidacy
anyway because I wanted to express how much I’d like to continue working to
drive Security standard up in OpenStack by helping to keep our many security
projects moving along. My candidacy request can be seen here:

https://review.openstack.org/224798

My most sincere apologies,
-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] [oslo][oslo.config] Reloading configuration of service

[Joshua Harlow]

So a few 'event' like constructs/libraries that I know about:

http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier 



I'd be happy to extract that and move to somewhere else if needed, it 
provides basic event/pub/sub kind of activities for taskflow (in-memory, 
not over rpc...)


A second one that I almost used in taskflow (but didn't because it has 
more of a global registry, which didn't suit taskflow's non-global 
usage) that might fit this usage just fine...


https://pythonhosted.org/blinker/

Both could probably do the job...

-Josh

Doug Hellmann wrote:

Excerpts from mhorban's message of 2015-09-17 10:26:28 +0300:

Hi Doug,

  >  Rather than building hooks into oslo.config, why don't we build them
  >  into the thing that is catching the signal. That way the app can do lots
  >  of things in response to a signal, and one of them might be reloading
  >  the configuration.

Hm... Yes... It is really stupid idea to put reloading hook into
oslo.config.
I'll move that hook mechanism into oslo.service. oslo.service is
responsible for catching/handling signals.

Is it enough to have one callback function? Or should I must add ability
to register many different callback functions?

What is your point of view?

Marian



We probably want the ability to have multiple callbacks. There are
already a lot of libraries available on PyPI for handling "events" like
this, so maybe we can pick one of those that is well maintained and
integrate it with oslo.service?

Doug

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


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

Re: [openstack-dev] [all][elections] PTL nomination period is nowover

[Steve Martinelli]

>> I'd like to apply some common sense here and if this many candidates on
both sides of the globe got confused, we can still take that into
consideration when taking next steps.

++ to this, it was clearly a slip up from some folk. let's use our human
judgement and common sense here :)

Thanks,

Steve Martinelli
OpenStack Keystone Core



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

Date:   2015/09/17 11:56 AM
Subject:Re: [openstack-dev] [all][elections] PTL nomination period is
now over





On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor 
wrote:
  On 09/17/2015 04:50 PM, Anita Kuno wrote:
   On 09/17/2015 08:22 AM, Matt Riedemann wrote:


 On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
  PTL Nomination is now over. The official candidate list is available
  on
  the wiki[0].

  There are 5 projects without candidates, so according to this
  resolution[1], the TC we'll have to appoint a new PTL for Barbican,
  MagnetoDB, Magnum, Murano and Security

 This is devil's advocate, but why does a project technically need a
 PTL?
   Just so that there can be a contact point for cross-project things,
 i.e. a lightning rod?  There are projects that do a lot of group
 leadership/delegation/etc, so it doesn't seem that a PTL is
 technically
 required in all cases.

   I think that is a great question for the TC to consider when they
   evaluate options for action with these projects.

   The election officials are fulfilling their obligation according to the
   resolution:
   
http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst


   If you read the verb there the verb is "can" not "must", I choose the
   verb "can" on purpose for the resolution when I wrote it. The TC has the
   option to select an appointee. The TC can do other things as well,
   should the TC choose.

  I agree- and this is a great example of places where human judgement is
  better than rules.

  For instance - one of the projects had a nominee but it missed the
  deadline, so that's probably an easy on.

Honestly I did the "Thursday" alignment math in my head and thought of it
in my non-futuristic timezone. Plus I have a Thursday release mentality
thanks to Theirry's years of excellent release management. :)

Plus, I further confused a couple of candidates when encouraging candidacy
posts, so I apologize for that! I am trying to get ahead of what we'll have
to do on the TC anyway.

I'd like to apply some common sense here and if this many candidates on
both sides of the globe got confused, we can still take that into
consideration when taking next steps.


  For one of the projects it had been looking dead for a while, so this is
  the final nail in the coffin from my POV

I'm not sure we've defined a coffin really, more of an attic/shelving
system. :)

I'll definitely take some time to follow up with individuals in this
deadline confusion system when we take next steps on the TC.

Anne


  For the other three - I know they're still active projects with people
  interested in them, so sorting them out will be fun!





  There are 7 projects that will have an election: Cinder, Glance,
  Ironic,
  Keystone, Mistral, Neutron and Oslo. The details for those will be
  posted tomorrow after Tony and I setup the CIVS system.

  Thank you,
  Tristan


  [0]:
  
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates


  [1]:
  
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html






  __


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




   __

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



  __

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



--
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [all][elections] PTL nomination period is now over

[Tristan Cacqueray]

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security

There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html




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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Flavio Percoco]

On 17/09/15 13:25 +, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


Magnum had a candidacy on the mailing list. I'd assume this is because
it wasn't proposed to openstack/election. Right?

Thanks for the hard work here,
Flavio



There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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



--
@flaper87
Flavio Percoco


pgpmqV9hsomjp.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] [all][gate] grende jobs failing.

[Matt Riedemann]

On 9/17/2015 7:23 AM, Tony Breeds wrote:

On Thu, Sep 17, 2015 at 06:22:47AM -0400, Davanum Srinivas wrote:

Tony,
Looks like the ban is holding up:
https://review.openstack.org/#/c/224429/


Sorry yes.  Robert Collins pointed out that my new quicker plan wasn't going to
work so we went back to the original ban 1.4.1 solution.

It looks like the gate is mostly green again.

If people have grenade jobs that failed, a recheck shoudl fix that.

Thanks to all those that pushed on this to get things going again.

Yours 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



As noted in the stable/kilo block on 1.4.1, we're good until we do a 
1.4.2 release at which point we either break juno or we break kilo since 
they overlap in supported version ranges.


I've asked Tony to push a requirements change on stable/juno and 
stable/kilo to add a note next to oslo.utils reminding us of this so we 
think twice before breaking it again (we should really make this part of 
the openstack/releases review process - to check that the proposed 
version change isn't going to show up in a branch that we don't intend 
it do).  Because if the proposed release has a g-r sync for branch n and 
the version will show up in branch n-1 or n+1, things will likely break.


Hopefully we just don't need an oslo.utils release on juno or kilo 
before juno-eol happens.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [magnum] Is magnum db going to be removed for k8s resources?

[Ryan Rossiter]

Here's what I see if I look at this from a matter-of-fact standpoint.

When Nova works with libvirt, libvirt might have something that Nova 
doesn't know about, but Nova doesn't care. Nova's database is the only 
world that Nova cares about. This allows Nova to have one source of data.


With Magnum, if we take data from both our database and the k8s API, we 
will have a split view of the world. This has both positives and negatives.


It does allow an end-user to do whatever they want with their cluster, 
and they don't necessarily have to use Magnum to do things, but Magnum 
will still have the correct status of stuff. It allows the end-user to 
choose what they want to use. Another positive is that because each 
clustering service is architected slightly different, it allows each 
service to know what it knows, without Magnum trying to guess some 
commonality between them.


A problem I see arising is the complexity added when gathering data from 
separate clusters. If I have one of every cluster, what happens when I 
need to get my list of containers? I would rather do just one call to 
the DB and get them, otherwise I'll have to call k8s, then call swarm, 
then mesos, and then aggregate all of them to return. I don't know if 
the only thing we will be retrieving from k8s are k8s-unique objects, 
but this is a situation that comes to my mind. Another negative is the 
possibility that the API does not perform as well as the DB. If the nova 
instance running the k8s API is super overloaded, the k8s API return 
will take longer than a call to the DB.


Let me know if I'm way off-base in any of these points. I'm not going to 
give an opinion at this point, this is just how I see things.


On 9/17/2015 7:53 AM, Jay Lau wrote:

Anyone who have some comments/suggestions on this? Thanks!

On Mon, Sep 14, 2015 at 3:57 PM, Jay Lau  wrote:


Hi Vikas,

Thanks for starting this thread. Here just show some of my comments here.

The reason that Magnum want to get k8s resource via k8s API including two
reasons:
1) Native clients support
2) With current implantation, we cannot get pod for a replication
controller. The reason is that Magnum DB only persist replication
controller info in Magnum DB.

With the bp of objects-from-bay, the magnum will always call k8s API to
get all objects for pod/service/rc. Can you please show some of your
concerns for why do we need to persist those objects in Magnum DB? We may
need to sync up Magnum DB and k8s periodically if we persist two copies of
objects.

Thanks!



2015-09-14 14:39 GMT+08:00 Vikas Choudhary :


Hi Team,

As per object-from-bay blueprint implementation [1], all calls to magnum db
are being skipped for example pod.create() etc.

Are not we going to use magnum db at all for pods/services/rc ?


Thanks
Vikas Choudhary


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


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




--
Thanks,

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


--
Thanks,

Ryan Rossiter (rlrossit)


__
OpenStack Development Mailing List (not for 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] Upgrade plans for RDO Manager - Brainstorming

[Jan Provaznik]

On 09/09/2015 05:34 PM, Zane Bitter wrote:

On 24/08/15 15:12, Emilien Macchi wrote:

Hi,

So I've been working on OpenStack deployments for 4 years now and so far
RDO Manager is the second installer -after SpinalStack [1]- I'm
working on.

SpinalStack already had interested features [2] that allowed us to
upgrade our customer platforms almost every months, with full testing
and automation.

Now, we have RDO Manager, I would be happy to share my little experience
on the topic and help to make it possible in the next cycle.

For that, I created an etherpad [3], which is not too long and focused
on basic topics for now. This is technical and focused on Infrastructure
upgrade automation.

Feel free to continue discussion on this thread or directly in the
etherpad.

[1] http://spinalstack.enovance.com
[2] http://spinalstack.enovance.com/en/latest/dev/upgrade.html
[3] https://etherpad.openstack.org/p/rdo-manager-upgrades


I added some notes on the etherpad, but I think this discussion poses a
larger question: what is TripleO? Why are we using Heat? Because to me
the major benefit of Heat is that it maintains a record of the current
state of the system that can be used to manage upgrades. And if we're
not going to make use of that - if we're going to determine the state of
the system by introspecting nodes and update it by using Ansible scripts
without Heat's knowledge, then we probably shouldn't be using Heat at all.

I'm not saying that to close off the option - I think if Heat is not the
best tool for the job then we should definitely consider other options.
And right now it really is not the best tool for the job. Adopting
Puppet (which was a necessary choice IMO) has meant that the
responsibility for what I call "software orchestration"[1] is split
awkwardly between Puppet and Heat. For example, the Puppet manifests are
baked in to images on the servers, so Heat doesn't know when they've
changed and can't retrigger Puppet to update the configuration when they
do. We're left trying to reverse-engineer what is supposed to be a
declarative model from the workflow that we want for things like
updates/upgrades.

That said, I think there's still some cause for optimism: in a world
where every service is deployed in a container and every container has
its own Heat SoftwareDeployment, the boundary between Heat's
responsibilities and Puppet's would be much clearer. The deployment
could conceivably fit a declarative model much better, and even offer a
lot of flexibility in which services run on which nodes. We won't really
know until we try, but it seems distinctly possible to aspire toward
Heat actually making things easier rather than just not making them too
much harder. And there is stuff on the long-term roadmap that could be
really great if only we had time to devote to it - for example, as I
mentioned in the etherpad, I'd love to get Heat's user hooks integrated
with Mistral so that we could have fully-automated, highly-available (in
a hypothetical future HA undercloud) live migration of workloads off
compute nodes during updates.



TBH I don't expect that using containers will significantly simplify (or 
make clearer) the upgrade process. It would work nicely if upgrade would 
mean just replacing one container with another (where a container is 
represented by a heat resource). But I'm convinced that a container 
replacement will actually involve a complex workflow of actions which 
have to be done before and after.



In the meantime, however, I do think that we have all the tools in Heat
that we need to cobble together what we need to do. In Liberty, Heat
supports batched rolling updates of ResourceGroups, so we won't need to
use user hooks to cobble together poor-man's batched update support any
more. We can use the user hooks for their intended purpose of notifying
the client when to live-migrate compute workloads off a server that is


Unfortunately rolling_updates supports only "pause time" between update 
batches, so if any workflow would be needed between batches (e.g. pause 
before next batch until user validates that previous batch update was 
successful), we still have to use user hooks. But I guess adding hooks 
support to rolling_updates wouldn't be too difficult.



about to upgraded. The Heat templates should already tell us exactly
which services are running on which nodes. We can trigger particular
software deployments on a stack update with a parameter value change (as
we already do with the yum update deployment). For operations that
happen in isolation on a single server, we can model them as
SoftwareDeployment resources within the individual server templates. For
operations that are synchronised across a group of servers (e.g.
disabling services on the controller nodes in preparation for a DB
migration) we can model them as a SoftwareDeploymentGroup resource in
the parent template. And for chaining multiple sequential operations
(e.g. disable services, migrate database, enable 

Re: [openstack-dev] [TripleO] Core reviewers for python-tripleoclient and tripleo-common

[James Slagle]

Hi, It's been a week, and I've heard no objections this proposal:

>> Specifically, the folks I'm proposing are:
>> Brad P. Crochet 
>> Dougal Matthews 

>> - keep just 1 tripleo acl, and add additional folks there, with a good
>> faith agreement not to +/-2,+A code that is not from the 2 client
>> repos.

I've added them to the core team. Thanks!



-- 
-- James Slagle
--

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think someone jumped the gun on this thread.  According to the wiki
[1] the cutoff time is not until 5:59 UTC, which
doesn't happen for another few hours. [2]

Am I missing something?

[1] https://wiki.openstack.org/wiki/PTL_Elections_September_2015
[2] http://time.is/UTC

Douglas Mendizábal

On 9/17/15 9:50 AM, Anita Kuno wrote:
> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>> 
>> 
>> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>>> PTL Nomination is now over. The official candidate list is 
>>> available on the wiki[0].
>>> 
>>> There are 5 projects without candidates, so according to this 
>>> resolution[1], the TC we'll have to appoint a new PTL for 
>>> Barbican, MagnetoDB, Magnum, Murano and Security
>> 
>> This is devil's advocate, but why does a project technically
>> need a PTL? Just so that there can be a contact point for 
>> cross-project things, i.e. a lightning rod?  There are projects 
>> that do a lot of group leadership/delegation/etc, so it doesn't 
>> seem that a PTL is technically required in all cases.
> 
> I think that is a great question for the TC to consider when they 
> evaluate options for action with these projects.
> 
> The election officials are fulfilling their obligation according
> to the resolution: 
> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20
141128-elections-process-for-leaderless-programs.rst
>
>
> 
If you read the verb there the verb is "can" not "must", I choose
> the verb "can" on purpose for the resolution when I wrote it. The 
> TC has the option to select an appointee. The TC can do other 
> things as well, should the TC choose.
> 
> Thanks, Anita.
> 
>> 
>>> 
>>> There are 7 projects that will have an election: Cinder, 
>>> Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The 
>>> details for those will be posted tomorrow after Tony and I 
>>> setup the CIVS system.
>>> 
>>> Thank you, Tristan
>>> 
>>> 
>>> [0]: 
>>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirm
ed_Candidates
>>>
>>>
>>>
>>> 
[1]:
>>> http://governance.openstack.org/resolutions/20141128-elections-proce
ss-for-leaderless-programs.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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+tawAAoJEB7Z2EQgmLX7WKIP/RUdGYOkA5dHuNnWKdX8QhaD
VzZSyTOjIebNZshiMIz8FhKGrFUn8wqEScbtUIFHIJj8tKVjZQ19m2Gg6zh42X6V
kpogxGDBwE5a/vuBA1z9eiTocA4KYEypxY+SIh18ho84dj5hDooI9N7ZsCJaaF3+
yKTLvUw7YxMM2iPxjZgQTH1vE1pMUh2fcylv3T3NhpHzIRgeB9dfnfr938rnwUTj
NUTK3DmWJAraAgHcKnwIN+JwOYF1SexXFK1eO2TX0yNYSEzFI3Xina0Hq3bHAON9
KbWlgr4pN19PsqqQnQrPjJbBmBs8TCkXNhTAojHtlA1oIbUiK8c3h32PHEt2AyCx
5g3btXOAqsCqvKtmFH1sj5EACeMUCW4J98u8e212iQPizgG9SD4LZ8FPPHOqWMwV
4haWpWLczZyXf7w7/deP4gndoW7njU/uiwCUNBrgdjI5AeaP5vckHQZ9iQmETsRa
bwwu5Yq7K92rAupVRFx4bofTyG4I8bw+Lg2muYMnwuqvgf++xqsMVs0x97jFYja5
M2qGMgihYDytDoYvdL71WykuN39SzZmPHzxKXKmiOcTXWhAXp10pBwFUFzFJmt+V
/tNjHfzvqt6qvnDEtt65vuwGBEQyiQFqmKmyPFCONCibn8nwoqjwP9hWmG4y1vVa
geegYxrikuEQ3KnPFQWr
=jON5
-END 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] [neutron] What semantics are expected when booting a VM on an external network?

[Neil Jerram]

Thanks, Kevin.  Some further queries, then:

On 17/09/15 15:49, Kevin Benton wrote:
>
> It's not true for all plugins, but an external network should provide
> the same semantics of a normal network.
>
Yes, that makes sense.  Clearly the core semantic there is IP.  I can
imagine reasonable variation on less core details, e.g. L2 broadcast vs.
NBMA.  Perhaps it would be acceptable, if use cases need it, for such
details to be described by flags on the external network object.

I'm also wondering about what you wrote in the recent thread with Carl
about representing a network connected by routers.  I think you were
arguing that a L3-only network should not be represented by a kind of
Neutron network object, because a Neutron network has so many L2
properties/semantics that it just doesn't make sense, and better to have
a different kind of object for L3-only.  Do those L2
properties/semantics apply to an external network too?

> The only difference is that it allows router gateway interfaces to be
> attached to it.
>
Right.  From a networking-calico perspective, I think that means that
the implementation should (eventually) support that, and hence allow
interconnection between the external network and private Neutron networks.

> We want to get rid of as much special casing as possible for the
> external network.
>
I don't understand here.  What 'special casing' do you mean?

Regards,
Neil

> On Sep 17, 2015 7:02 AM, "Neil Jerram"  > wrote:
>
> Thanks to the interesting 'default network model' thread, I now know
> that Neutron allows booting a VM on an external network. :-)  I didn't
> realize that before!
>
> So, I'm now wondering what connectivity semantics are expected (or
> even
> specified!) for such VMs, and whether they're the same as - or very
> similar to - the 'routed' networking semantics I've described at [1].
>
> [1]
> 
> https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
>
> Specifically I wonder if VM's attached to an external network
> expect any
> particular L2 characteristics, such as being able to L2 broadcast to
> each other?
>
> By way of context - i.e. why am I asking this?...   The
> networking-calico project [2] provides an implementation of the
> 'routed'
> semantics at [1], but only if one suspends belief in some of the
> Neutron
> semantics associated with non-external networks, such as needing a
> virtual router to provide connectivity to the outside world.  (Because
> networking-calico provides that external connectivity without any
> virtual router.)  Therefore we believe that we need to propose some
> enhancement of the Neutron API and data model, so that Neutron can
> describe 'routed' semantics as well as all the traditional ones.  But,
> if what we are doing is semantically equivalent to 'attaching to an
> external network', perhaps no such enhancement is needed...
>
> [2] https://git.openstack.org/cgit/openstack/networking-calico
> 
>
> Many thanks for any input!
>
> Neil
>
>
> __
> OpenStack Development Mailing 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][elections] PTL nomination period is now over

[Jeremy Stanley]

On 2015-09-17 10:05:20 -0500 (-0500), Douglas Mendizábal wrote:
> I think someone jumped the gun on this thread.  According to the wiki
> [1] the cutoff time is not until 5:59 UTC, which
> doesn't happen for another few hours. [2]

Per that page the deadline for nominations is September 17, 05:59
UTC which was over 9 hours ago now. The deadline for contributions
to count toward being part of the electorate is September 18, 2015
05:59 UTC (a little less than 15 hours from now).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Sean M. Collins]

On Thu, Sep 17, 2015 at 09:58:29AM EDT, Neil Jerram wrote:
> Specifically I wonder if VM's attached to an external network expect any
> particular L2 characteristics, such as being able to L2 broadcast to
> each other?

I am fairly certain that our definition of a Neutron Network, as a L2
broadcast segment, implies that yes this should be possible.
-- 
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] [Magnum]bay/baymodel sharing for multi-tenants

[Jay Lau]

Hi Magnum,

Currently, there are about two blueprints related to bay/baymode sharing
for different tenants.
1) https://blueprints.launchpad.net/magnum/+spec/tenant-shared-model
2) https://blueprints.launchpad.net/magnum/+spec/public-baymodels

What we want to do is we can make the bay/baymodel to be shared by
multi-tenants, the reason is that sometimes, creating a bay maybe time
consuming, and enabling the bay shared by multi-tenant can save some time
for some users.

Any comments on this?

-- 
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] [neutron] PTL Non-Candidacy

[John Belamaric]

Thanks for all your hard work Kyle. Enjoy your more relaxed schedule :)


On Sep 11, 2015, at 5:12 PM, Kyle Mestery 
> wrote:

I'm writing to let everyone know that I do not plan to run for Neutron PTL for 
a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan 
recently put it in his non-candidacy email [1]. But it goes further than that 
for me. As Flavio put it in his post about "Being a PTL" [2], it's a full time 
job. In the case of Neutron, it's more than a full time job, it's literally an 
always on job.

I've tried really hard over my three cycles as PTL to build a stronger web of 
trust so the project can grow, and I feel that's been accomplished. We have a 
strong bench of future PTLs and leaders ready to go, I'm excited to watch them 
lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered the 
concept of rotating PTL duties with each cycle, I'd like to highly encourage 
Neutron and other projects to do the same. Having a deep bench of leaders 
supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.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][elections] PTL nomination period is now over

[Flavio Percoco]

On 17/09/15 13:44 +, Tristan Cacqueray wrote:

On 09/17/2015 01:32 PM, Flavio Percoco wrote:

On 17/09/15 13:25 +, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


Magnum had a candidacy on the mailing list. I'd assume this is because
it wasn't proposed to openstack/election. Right?


That is correct, but the candidacy was submitted after the deadlines so
we can't validate this candidate.


Awesome, thanks for the confirmation.
Flavio





Thanks for the hard work here,
Flavio



There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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








--
@flaper87
Flavio Percoco


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

[openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Neil Jerram]

Thanks to the interesting 'default network model' thread, I now know
that Neutron allows booting a VM on an external network. :-)  I didn't
realize that before!

So, I'm now wondering what connectivity semantics are expected (or even
specified!) for such VMs, and whether they're the same as - or very
similar to - the 'routed' networking semantics I've described at [1].

[1]
https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst

Specifically I wonder if VM's attached to an external network expect any
particular L2 characteristics, such as being able to L2 broadcast to
each other?

By way of context - i.e. why am I asking this?...   The
networking-calico project [2] provides an implementation of the 'routed'
semantics at [1], but only if one suspends belief in some of the Neutron
semantics associated with non-external networks, such as needing a
virtual router to provide connectivity to the outside world.  (Because
networking-calico provides that external connectivity without any
virtual router.)  Therefore we believe that we need to propose some
enhancement of the Neutron API and data model, so that Neutron can
describe 'routed' semantics as well as all the traditional ones.  But,
if what we are doing is semantically equivalent to 'attaching to an
external network', perhaps no such enhancement is needed...

[2] https://git.openstack.org/cgit/openstack/networking-calico

Many thanks for any input!

Neil


__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is quite unfortunate, as I was intending to submit my candidacy
for the Barbican project today, but I did not realize the cutoff time
would be in the morning in CDT.

I'd like to apologize to the OpenStack community and the Barbican team
in particular for missing this deadline.

Thanks,

Douglas Mendizábal

On 9/17/15 8:49 AM, Flavio Percoco wrote:
> On 17/09/15 13:44 +, Tristan Cacqueray wrote:
>> On 09/17/2015 01:32 PM, Flavio Percoco wrote:
>>> On 17/09/15 13:25 +, Tristan Cacqueray wrote:
 PTL Nomination is now over. The official candidate list is
 available on the wiki[0].
 
 There are 5 projects without candidates, so according to
 this resolution[1], the TC we'll have to appoint a new PTL
 for Barbican, MagnetoDB, Magnum, Murano and Security
>>> 
>>> Magnum had a candidacy on the mailing list. I'd assume this is
>>> because it wasn't proposed to openstack/election. Right?
>> 
>> That is correct, but the candidacy was submitted after the
>> deadlines so we can't validate this candidate.
> 
> Awesome, thanks for the confirmation. Flavio
> 
>> 
>>> 
>>> Thanks for the hard work here, Flavio
>>> 
 
 There are 7 projects that will have an election: Cinder,
 Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The
 details for those will be posted tomorrow after Tony and I
 setup the CIVS system.
 
 Thank you, Tristan
 
 
 [0]: 
 https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confir
med_Candidates



 
[1]:
 http://governance.openstack.org/resolutions/20141128-elections-proc
ess-for-leaderless-programs.html




>>>
>>>
>>>

 

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

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+saCAAoJEB7Z2EQgmLX7XG0P/AqOTGDDbVJrJSTPnCGwtqYd
275uDQgWqvbsGMKOrfKO7GBgI/5n/j8hCyiipq6niCfW5eWWH7rYgU1pLKLjiZmR
12Ui4PwkqvoJEa0J5NIiM8GOrt2TEDTu7vOQAWMzGEn+8fbs7Z9MRPIAg7bEXuk0
eQNs5LK6j/INXvuuKm4ZV2MjAxJRbtsSZYVn59U4IxM0GSJIC4MLu8dGaRzf+G8B
881hflBskg1Sa5UjEcj/yMUDrtBLOyNkM67dv8M9ojNB0bX3o+US8zmJnsbk6whD
ox3GrgoxT8he6iMNd/YYycFtBlBZ4fqNN8Uv5Vr/+k8s2umJf7Y3IbM2oQuhM1oJ
mWuwFbyc440ep9WkBeXeZTm0S0FYwR3MS40nW2D04eHEcTbCHchKIoLp/tO0AKYP
op116JlzTyWZatywL8rIOner4UJQX6yUqmGRdonACNQ6OAzTLTTaARtwqHacxL81
UqzOLEQ8nW9p5xCTPWhbPbR7t1T7ngwf5bJAuDKVx9JDUsM+mYjZ7smWdg+PV1yS
SwW94TzImOV4ujiT7AwzUBz6SZ0jHFt5yXVWscggpj5k7l8lPqFhd4xQVvidqLcZ
VsHfKwfdfWX22z+97n4/GjEd6B0seZqcxoP4qVsXXgpuFJETVLEifDM9DTOLccxy
xQR6UpOxTZxl5EdiOpxX
=nraX
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Anita Kuno]

On 09/17/2015 08:22 AM, Matt Riedemann wrote:
> 
> 
> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>> PTL Nomination is now over. The official candidate list is available on
>> the wiki[0].
>>
>> There are 5 projects without candidates, so according to this
>> resolution[1], the TC we'll have to appoint a new PTL for Barbican,
>> MagnetoDB, Magnum, Murano and Security
> 
> This is devil's advocate, but why does a project technically need a PTL?
>  Just so that there can be a contact point for cross-project things,
> i.e. a lightning rod?  There are projects that do a lot of group
> leadership/delegation/etc, so it doesn't seem that a PTL is technically
> required in all cases.

I think that is a great question for the TC to consider when they
evaluate options for action with these projects.

The election officials are fulfilling their obligation according to the
resolution:
http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

If you read the verb there the verb is "can" not "must", I choose the
verb "can" on purpose for the resolution when I wrote it. The TC has the
option to select an appointee. The TC can do other things as well,
should the TC choose.

Thanks,
Anita.

> 
>>
>> There are 7 projects that will have an election: Cinder, Glance, Ironic,
>> Keystone, Mistral, Neutron and Oslo. The details for those will be
>> posted tomorrow after Tony and I setup the CIVS system.
>>
>> Thank you,
>> Tristan
>>
>>
>> [0]:
>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
>>
>> [1]:
>> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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][elections] PTL nomination period is now over

[Tristan Cacqueray]

On 09/17/2015 01:32 PM, Flavio Percoco wrote:
> On 17/09/15 13:25 +, Tristan Cacqueray wrote:
>> PTL Nomination is now over. The official candidate list is available on
>> the wiki[0].
>>
>> There are 5 projects without candidates, so according to this
>> resolution[1], the TC we'll have to appoint a new PTL for Barbican,
>> MagnetoDB, Magnum, Murano and Security
> 
> Magnum had a candidacy on the mailing list. I'd assume this is because
> it wasn't proposed to openstack/election. Right?

That is correct, but the candidacy was submitted after the deadlines so
we can't validate this candidate.

> 
> Thanks for the hard work here,
> Flavio
> 
>>
>> There are 7 projects that will have an election: Cinder, Glance, Ironic,
>> Keystone, Mistral, Neutron and Oslo. The details for those will be
>> posted tomorrow after Tony and I setup the CIVS system.
>>
>> Thank you,
>> Tristan
>>
>>
>> [0]:
>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
>>
>> [1]:
>> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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
> 




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

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Kevin Benton]

It's not true for all plugins, but an external network should provide the
same semantics of a normal network. The only difference is that it allows
router gateway interfaces to be attached to it. We want to get rid of as
much special casing as possible for the external network.
On Sep 17, 2015 7:02 AM, "Neil Jerram"  wrote:

> Thanks to the interesting 'default network model' thread, I now know
> that Neutron allows booting a VM on an external network. :-)  I didn't
> realize that before!
>
> So, I'm now wondering what connectivity semantics are expected (or even
> specified!) for such VMs, and whether they're the same as - or very
> similar to - the 'routed' networking semantics I've described at [1].
>
> [1]
>
> https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
>
> Specifically I wonder if VM's attached to an external network expect any
> particular L2 characteristics, such as being able to L2 broadcast to
> each other?
>
> By way of context - i.e. why am I asking this?...   The
> networking-calico project [2] provides an implementation of the 'routed'
> semantics at [1], but only if one suspends belief in some of the Neutron
> semantics associated with non-external networks, such as needing a
> virtual router to provide connectivity to the outside world.  (Because
> networking-calico provides that external connectivity without any
> virtual router.)  Therefore we believe that we need to propose some
> enhancement of the Neutron API and data model, so that Neutron can
> describe 'routed' semantics as well as all the traditional ones.  But,
> if what we are doing is semantically equivalent to 'attaching to an
> external network', perhaps no such enhancement is needed...
>
> [2] https://git.openstack.org/cgit/openstack/networking-calico
>
> Many thanks for any input!
>
> Neil
>
>
> __
> OpenStack Development Mailing 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] Design Summit Topics for Nova

[Tony Breeds]

On Wed, Sep 16, 2015 at 11:40:28AM -0700, melanie witt wrote:
 
> Today I was informed that google forms are blocked in China [1], so I wanted
> to mention it here so we can consider an alternate way to collect submissions
> from those who might not be able to access the form.

I'll act as an email to google forms proxy if needed. People that willbe at the
summit can fill in the temp;ate below.
(stolen from the google forms)

---
Topic Title:
Topic Description:
Submitter IRC handle:
Session leader IRC handle
 Please note the session leader must be there on the day at the summit. Please
 just leave this blank if you feel unable to find someone to lead the session.
 
Link to nova-spec review:
 Features you want to discuss need to have at least a WIP spec before being
 considered for the design summit track. Ideally we will merge the spec before
 the design summit, so a session would not be required.
 
Link to pre-reading:
 Before the submission is on the final list, we need to have some background
 reading for more complex topics, or topics that have had lots of previous
 discussion, so its easier for everyone to get involved. This could be a wiki
 page, an etherpad, an ML post, or devref.
---

Yours Tony.


pgppG5IcwvLYg.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] Pycharm License for OpenStack developers

[Andrew Melton]

Hey Devs,


I'm the guy who's maintained our JetBrains licenses for the past couple of 
years. License philosophy aside, the IDE you choose to use is entirely up to 
you. I'm currently waiting to hear back from JetBrains on the actual license. 
From the sound of it, the opensource license hasn't changed much since last 
year. Originally we had an unlimited license, which made user management 
easier. This year it sounds like we will still have a bulk license, they just 
want an estimation for an initial user count limit, which I've given them. 
They've assured me that we will be able to increase the user limit on the 
license if we hit it.


Once I have the new license, I'll send out an email to the list letting 
everyone know. Please hold off on license requests until then. Unless JetBrains 
demands more strict control, I'll handle everything like I always have. I'll 
just need your launchpad-id to confirm you're actually a contributor, then I'll 
send the license your way.


--Andrew


From: John Griffith 
Sent: Wednesday, September 16, 2015 3:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Pycharm License for OpenStack developers



On Wed, Sep 16, 2015 at 12:35 PM, Morgan Fainberg 
> wrote:


On Wed, Sep 16, 2015 at 11:12 AM, Joshua Harlow 
> wrote:
Anyone know about the impact of:

- https://mmilinkov.wordpress.com/2015/09/04/jetbrains-lockin-we-told-you-so/

- http://blog.jetbrains.com/blog/2015/09/03/introducing-jetbrains-toolbox/

I'm pretty sure a lot of openstack-devs are using pycharms, and wonder what 
this change will mean for those devs?

I have historically purchased my own license (because I believed in supporting 
the companies that produce the tools, even though there was a oss-project 
license that I didn't need to pay for).
?Total tangent, but props on purchasing a license to support something you use 
on a regular basis!
?

I am evaluating if I wish to continue with jetbrains based on this change or 
not. They have said they are evaluating the feedback - I'm willing to see what 
the end result will be.

There are other IDE options out there for python and I may consider those. I 
haven't run out my license, I am not sure this is enough to change my POV that 
pycharm is the best option at the moment for my workflow. It was for other 
software I historically purchased (business suites/photo editing) but those 
filled a different space.

How much impact will this make to those pure upstream developers? Very little 
unless jetbrains ceases the opensource project license.

Just my $0.02.

--Morgan


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


__
OpenStack Development Mailing List (not for 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] What semantics are expected when booting a VM on an external network?

[Neil Jerram]

Thanks so much for your continuing answers; they are really helping me.

I see your points now about the special casing, and about the semantic
expectations and internal wiring of a Neutron network being just the
same for an external network as for non-external.  Hence, the model for
an L3-only external network should be the same as it would be for an
L3-only tenant network, except for the router:external flag (and might
be along the lines that you've suggested, of a subnet with a null network).

It still seems that 'router:external true' might be a good match for
some of the other 'routed' semantics in [1], though, so I'd like to
drill down more on exactly what 'router:external true' means.

A summary of the semantics at [1] is:
(a) L3-only connectivity between instances attached to the network.
(b) Data can be routed between between this network and the outside, and
between multiple networks of this type, without needing Neutron routers
(c) Floating IPs are not supported for instances on this network. 
Instead, wherever an instance needs to be routable from, attach it to a
network with a subnet of IP addresses that are routable from that place.

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

According to [2], router:external "Indicates whether this network is
externally accessible."  Which I think is an exact match for (b) - would
you agree?  (Note: it can't mean that every instance on that network
actually _is_ contactable from outside, because that depends on IP
addressing, and router:external is a network property, not subnet.  But
it can mean that every instance is _potentially_ contactable, without
the mediation of a Neutron router.)

[2] http://developer.openstack.org/api-ref-networking-v2-ext.html

Also I believe that (c) is already true for Neutron external networks -
i.e. it doesn't make sense to assign a floating IP to an instance that
is directly on an external network.  Is that correct?

In summary, for the semantics that I'm wanting to model, it sounds like
router:external true already gives me 2 of the 3 main pieces.  There's
still serious work needed for (a), but that's really nice news, if I'm
seeing things correctly (since discovering that instances can be
attached to an external network).

Regards,
Neil




On 17/09/15 17:29, Kevin Benton wrote:
>
> Yes, the L2 semantics apply to the external network as well (at least
> with ML2).
>
> One example of the special casing is the external_network_bridge
> option in the L3 agent. That would cause the agent to plug directly
> into a bridge so none of the normal L2 agent wiring would occur. With
> the L2 bridge_mappings option there is no reason for this to exist
> anymore because it ignoring network attributes makes debugging a
> nightmare.
>
> >Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> An external network object is just a regular network object with a
> router:external flag set to true. Any changes to it would have to make
> sense in the context of all networks. That's why I want to make sure
> that whatever we come up with makes sense in all contexts and isn't
> just a bolt on corner case.
>
> On Sep 17, 2015 8:21 AM, "Neil Jerram"  > wrote:
>
> Thanks, Kevin.  Some further queries, then:
>
> On 17/09/15 15:49, Kevin Benton wrote:
> >
> > It's not true for all plugins, but an external network should
> provide
> > the same semantics of a normal network.
> >
> Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2
> broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> I'm also wondering about what you wrote in the recent thread with Carl
> about representing a network connected by routers.  I think you were
> arguing that a L3-only network should not be represented by a kind of
> Neutron network object, because a Neutron network has so many L2
> properties/semantics that it just doesn't make sense, and better
> to have
> a different kind of object for L3-only.  Do those L2
> properties/semantics apply to an external network too?
>
> > The only difference is that it allows router gateway interfaces
> to be
> > attached to it.
> >
> Right.  From a networking-calico perspective, I think that means that
> the implementation should (eventually) support that, and hence allow
> interconnection between the external network and private Neutron
> networks.
>
> > We want to get rid of as much special casing as possible for the
> > external network.
>   

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Kevin Benton]

Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
paper submissions use for academic conferences. That way there is never a
need to convert TZs, you just get it in by the end of the day in your own
time zone.
On Sep 17, 2015 9:18 AM, "Edgar Magana"  wrote:

> Folks,
>
> Last year I found myself in the same position when I missed a deadline
> because my wrong planning and time zones nightmare!
> However, the rules were very clear and I assumed my mistake. So, we should
> assume that we do not have candidates and follow the already described
> process. However, this should be very easy to figure out for the TC, it is
> just a matter to find our who is interested in the PTL role and consulting
> with the core team of that specific project.
>
> Just my two cents…
>
> Edgar
>
> From: Kyle Mestery
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Thursday, September 17, 2015 at 8:48 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [all][elections] PTL nomination period is
> now over
>
> On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor 
> wrote:
>
>> On 09/17/2015 04:50 PM, Anita Kuno wrote:
>>
>>> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>>>


 On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:

> PTL Nomination is now over. The official candidate list is available on
> the wiki[0].
>
> There are 5 projects without candidates, so according to this
> resolution[1], the TC we'll have to appoint a new PTL for Barbican,
> MagnetoDB, Magnum, Murano and Security
>

 This is devil's advocate, but why does a project technically need a PTL?
   Just so that there can be a contact point for cross-project things,
 i.e. a lightning rod?  There are projects that do a lot of group
 leadership/delegation/etc, so it doesn't seem that a PTL is technically
 required in all cases.

>>>
>>> I think that is a great question for the TC to consider when they
>>> evaluate options for action with these projects.
>>>
>>> The election officials are fulfilling their obligation according to the
>>> resolution:
>>>
>>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
>>>
>>> If you read the verb there the verb is "can" not "must", I choose the
>>> verb "can" on purpose for the resolution when I wrote it. The TC has the
>>> option to select an appointee. The TC can do other things as well,
>>> should the TC choose.
>>>
>>
>> I agree- and this is a great example of places where human judgement is
>> better than rules.
>>
>> For instance - one of the projects had a nominee but it missed the
>> deadline, so that's probably an easy on.
>>
>> For one of the projects it had been looking dead for a while, so this is
>> the final nail in the coffin from my POV
>>
>> For the other three - I know they're still active projects with people
>> interested in them, so sorting them out will be fun!
>>
>>
> This is the right approach. Human judgement #ftw! :)
>
>
>>
>>
>>>

> There are 7 projects that will have an election: Cinder, Glance,
> Ironic,
> Keystone, Mistral, Neutron and Oslo. The details for those will be
> posted tomorrow after Tony and I setup the CIVS system.
>
> Thank you,
> Tristan
>
>
> [0]:
>
> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
>
> [1]:
>
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
>
>
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Neil Jerram]

But on the Internet, no one knows that I'm really a crocodile, and
writing from Midway...

Neil


On 17/09/15 18:29, Kevin Benton wrote:
>
> Maybe it would be a good idea to switch to 23:59 AOE deadlines like
> many paper submissions use for academic conferences. That way there is
> never a need to convert TZs, you just get it in by the end of the day
> in your own time zone.
>
> On Sep 17, 2015 9:18 AM, "Edgar Magana"  > wrote:
>
> Folks,
>
> Last year I found myself in the same position when I missed a
> deadline because my wrong planning and time zones nightmare!
> However, the rules were very clear and I assumed my mistake. So,
> we should assume that we do not have candidates and follow the
> already described process. However, this should be very easy to
> figure out for the TC, it is just a matter to find our who is
> interested in the PTL role and consulting with the core team of
> that specific project.
>
> Just my two cents… 
>
> Edgar
>
> From: Kyle Mestery
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> Date: Thursday, September 17, 2015 at 8:48 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [all][elections] PTL nomination
> period is now over
>
> On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor
> > wrote:
>
> On 09/17/2015 04:50 PM, Anita Kuno wrote:
>
> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>
>
>
> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>
> PTL Nomination is now over. The official candidate
> list is available on
> the wiki[0].
>
> There are 5 projects without candidates, so
> according to this
> resolution[1], the TC we'll have to appoint a new
> PTL for Barbican,
> MagnetoDB, Magnum, Murano and Security
>
>
> This is devil's advocate, but why does a project
> technically need a PTL?
>   Just so that there can be a contact point for
> cross-project things,
> i.e. a lightning rod?  There are projects that do a
> lot of group
> leadership/delegation/etc, so it doesn't seem that a
> PTL is technically
> required in all cases.
>
>
> I think that is a great question for the TC to consider
> when they
> evaluate options for action with these projects.
>
> The election officials are fulfilling their obligation
> according to the
> resolution:
> 
> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
>
> If you read the verb there the verb is "can" not "must", I
> choose the
> verb "can" on purpose for the resolution when I wrote it.
> The TC has the
> option to select an appointee. The TC can do other things
> as well,
> should the TC choose.
>
>
> I agree- and this is a great example of places where human
> judgement is better than rules.
>
> For instance - one of the projects had a nominee but it missed
> the deadline, so that's probably an easy on.
>
> For one of the projects it had been looking dead for a while,
> so this is the final nail in the coffin from my POV
>
> For the other three - I know they're still active projects
> with people interested in them, so sorting them out will be fun!
>
>
> This is the right approach. Human judgement #ftw! :)
>  
>
>
>
>
>
> There are 7 projects that will have an election:
> Cinder, Glance, Ironic,
> Keystone, Mistral, Neutron and Oslo. The details
> for those will be
> posted tomorrow after Tony and I setup the CIVS
> system.
>
> Thank you,
> Tristan
>
>
> [0]:
> 
> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
>
> [1]:
> 
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
>
>
>
>
>
> 
> __
>
> OpenStack Development Mailing List (not for usage
> questions)
> Unsubscribe:
> 
> 

Re: [openstack-dev] [Sahara] FFE request for improved secret storage

[michael mccune]

i am retracting this request, i think this feature would benefit from 
more time to test and review.


thanks for the consideration,
mike

On 09/09/2015 12:09 PM, michael mccune wrote:

hi all,

i am requesting an FFE for the improved secret storage feature.

this change will allow operators to utilize the key manager service for
offloading the passwords stored by sahara. this change does not
implement mandatory usage of barbican, and defaults to a backward
compatible behavior that requires no change to a stack.

there is currently 1 review up which addresses the main thrust of this
change, there will be 1 additional review which will include more
passwords being migrated to use the mechanisms for offloading.

i expect this work to be complete by sept. 25.

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

blueprint
https://blueprints.launchpad.net/sahara/+spec/improved-secret-storage

spec
http://specs.openstack.org/openstack/sahara-specs/specs/liberty/improved-secret-storage.html


thanks,
mike

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



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

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Kevin Benton]

router:external only affects the behavior of Neutron routers. It allows
them to attach to it with an external gateway interface which implies NAT
and floating IPs.

>From an instance's perspective, an external network would be no different
than any other provider network scenario that uses a non-Neutron router.
Nothing different happens with the routing of traffic.

>Also I believe that (c) is already true for Neutron external networks - i.e.
it doesn't make sense to assign a floating IP to an instance that is
directly on an external network.  Is that correct?

Well not floating IPs from the same external network, but you could
conceivably have layers where one external network has an internal Neutron
router interface that leads to another external network via a Neutron
router.


On Thu, Sep 17, 2015 at 10:17 AM, Neil Jerram 
wrote:

> Thanks so much for your continuing answers; they are really helping me.
>
> I see your points now about the special casing, and about the semantic
> expectations and internal wiring of a Neutron network being just the
> same for an external network as for non-external.  Hence, the model for
> an L3-only external network should be the same as it would be for an
> L3-only tenant network, except for the router:external flag (and might
> be along the lines that you've suggested, of a subnet with a null network).
>
> It still seems that 'router:external true' might be a good match for
> some of the other 'routed' semantics in [1], though, so I'd like to
> drill down more on exactly what 'router:external true' means.
>
> A summary of the semantics at [1] is:
> (a) L3-only connectivity between instances attached to the network.
> (b) Data can be routed between between this network and the outside, and
> between multiple networks of this type, without needing Neutron routers
> (c) Floating IPs are not supported for instances on this network.
> Instead, wherever an instance needs to be routable from, attach it to a
> network with a subnet of IP addresses that are routable from that place.
>
> [1] https://review.openstack.org/#/c/198439/
>
> According to [2], router:external "Indicates whether this network is
> externally accessible."  Which I think is an exact match for (b) - would
> you agree?  (Note: it can't mean that every instance on that network
> actually _is_ contactable from outside, because that depends on IP
> addressing, and router:external is a network property, not subnet.  But
> it can mean that every instance is _potentially_ contactable, without
> the mediation of a Neutron router.)
>
> [2] http://developer.openstack.org/api-ref-networking-v2-ext.html
>
> Also I believe that (c) is already true for Neutron external networks -
> i.e. it doesn't make sense to assign a floating IP to an instance that
> is directly on an external network.  Is that correct?
>
> In summary, for the semantics that I'm wanting to model, it sounds like
> router:external true already gives me 2 of the 3 main pieces.  There's
> still serious work needed for (a), but that's really nice news, if I'm
> seeing things correctly (since discovering that instances can be
> attached to an external network).
>
> Regards,
> Neil
>
>
>
>
> On 17/09/15 17:29, Kevin Benton wrote:
> >
> > Yes, the L2 semantics apply to the external network as well (at least
> > with ML2).
> >
> > One example of the special casing is the external_network_bridge
> > option in the L3 agent. That would cause the agent to plug directly
> > into a bridge so none of the normal L2 agent wiring would occur. With
> > the L2 bridge_mappings option there is no reason for this to exist
> > anymore because it ignoring network attributes makes debugging a
> > nightmare.
> >
> > >Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> > imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> > NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> > details to be described by flags on the external network object.
> >
> > An external network object is just a regular network object with a
> > router:external flag set to true. Any changes to it would have to make
> > sense in the context of all networks. That's why I want to make sure
> > that whatever we come up with makes sense in all contexts and isn't
> > just a bolt on corner case.
> >
> > On Sep 17, 2015 8:21 AM, "Neil Jerram"  > > wrote:
> >
> > Thanks, Kevin.  Some further queries, then:
> >
> > On 17/09/15 15:49, Kevin Benton wrote:
> > >
> > > It's not true for all plugins, but an external network should
> > provide
> > > the same semantics of a normal network.
> > >
> > Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> > imagine reasonable variation on less core details, e.g. L2
> > broadcast vs.
> > NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> > 

[openstack-dev] [OSSN 0052] Python-swiftclient exposes raw token values in debug logs

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Python-swiftclient exposes raw token values in debug logs
- ---

### Summary ###
The password and authentication token configuration options for the
python-swiftclient are not marked as secret. The values of these options
will be logged to the standard logging output when the controller is run
in debug mode.

### Affected Services / Software ###
Python-swiftclient, Swift, Glance, Juno, Kilo

### Discussion ###
When using the python-swiftclient to connect to Glance, and the
:glance-api.conf: has set the value of the debug option to True, the
requests sent through the API, including user and token details, will be
captured in the local log mechanism.

### Recommended Actions ###
It is recommended to use the debug level in configurations only when
necessary to troubleshoot an issue. When the debug flag is set, the
resulting logs should be treated as having sensitive information and as
such should have strict permissions around the file and containing
directory set in the operating system. Additionally, the logs should
not be transported off the system in plaintext such as through syslog.

The debug level can be turned off by setting the following option in
the `glance-api.conf` file:

[DEFAULT]
debug = false

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0052
Original LaunchPad Bug :
https://bugs.launchpad.net/python-swiftclient/+bug/1470740
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+wY0AAoJEJa+6E7Ri+EVIDEH/jtjxXOMTiiGMVrlBCwRIbVj
qxqbe8ExtWxz21cMFHOvxxdZgeOerNegTxUqgil1MVQMC9DZuVmkyPt7NLwWhN9l
Xqul/Rrk4UNBlesGuCVlXPCmcaH6HXzZG1Jaty2QDok/0ev1QUynb1i4cktISUJm
Xo0TCt/R7CijyD/AHrLOxjHwh7NUyT+8v9dyD8wdalAA814wmyz31aFW/FCfunaP
v6yx89H0FjPbxksXcB9O+E1ZyGVGJBkU7GuzAGcr6Wa+9/dg14AzQmUb4/AbEyEt
udQ275vGkicGImGOrVANwEIHK7ooliede2sxgG1omhqAd3Ak/QsMcMpbw3gk1BE=
=w1KU
-END 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] [Congress] CLI equivalent

[Shiv Haris]

Thanks Alex.

From: Alex Yip [mailto:a...@vmware.com]
Sent: Wednesday, September 16, 2015 12:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Congress] CLI equivalent


Try this:

openstack congress policy row list classification error​






From: Shiv Haris >
Sent: Wednesday, September 16, 2015 12:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] CLI equivalent

Do we have a CLI way for  doing the equivalent of:

$ curl -X GET localhost:1789/v1/policies/classification/tables/error/rows
As described in the tutorial:

https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations

-Shiv

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Thursday, September 10, 2015 8:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] Ending feature freeze

Hi all,

We're now finished with feature freeze.  We have our first release candidate 
and the stable/liberty branch.  So master is once again open for new features.  
Couple of things to note:

1. Documentation.  We should also look through the docs and update them.  
Documentation is really important.  There's one doc patch not yet merged, so be 
sure to pull that down before editing.  That patch officially deprecates a 
number of API calls that don't make sense for the new distributed architecture. 
 If you find places where we don't mention the deprecation, please fix that.

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

2. Bugs.  We should still all be manually testing, looking for bugs, and fixing 
them.  This will be true especially as other projects change their clients, 
which as we've seen can break our datasource drivers.

All bug fixes first go into master, and then we cherry-pick to stable/liberty.  
Once you've patched a bug on master and it's been merged, you'll create another 
change for your bug-fix and push it to review.  Then one of the cores will 
+2/+1 it (usually without needing another formal round of reviews).  Here's the 
procedure.

// pull down the latest changes for master
$ git checkout master
$ git pull

// create a local branch for stable/liberty and switch to it
$ git checkout origin/stable/liberty -b stable/liberty

// cherry-pick your change from master onto the local stable/liberty
// The -x records the original  in the commit msg
$ git cherry-pick -x 

// Push to review and specify the stable/liberty branch.
// Notice in gerrit that the branch is stable/liberty, not master
$ git review stable/liberty

// Once your change to stable/liberty gets merged, fetch all the new
// changes.

// switch to local version of stable/liberty
$ git checkout stable/liberty

// fetch all the new changes to all the branches
$ git fetch origin

// update your local branch
$ git rebase origin/stable/liberty

Tim





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

Re: [openstack-dev] [Devstack][Sahara][Cinder] BlockDeviceDriver support in Devstack

[Sean M. Collins]

You need to remove your Workflow-1.

-- 
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] [all][elections] PTL nomination period is now over

[Brian Curtin]

Because it's still day_n AOE in early hours of day_n+1 local-time in a
lot of places. I think I have until 6 AM the day after an AOE deadline
where it's still considered the deadline date anywhere on earth, as
there are still places on earth where the date hasn't flipped.

Your EOD is not the deadline, as it's really only a reference to how
many more hours you have until it's no longer that date anywhere on
earth. People screw themselves out of things by using their EOD as the
definition.

(we've been using this with the PyCon CFP since forever)

On Thu, Sep 17, 2015 at 1:17 PM, Kevin Benton  wrote:
> How is it not what I described? Time zones become irrelevant if you get it
> in by the end of the day in your local time zone.
>
> https://en.wikipedia.org/wiki/Anywhere_on_Earth
>
> On Thu, Sep 17, 2015 at 10:30 AM, Brian Curtin  wrote:
>>
>> On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton  wrote:
>> > Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
>> > paper submissions use for academic conferences. That way there is never
>> > a
>> > need to convert TZs, you just get it in by the end of the day in your
>> > own
>> > time zone.
>>
>> This is somehow going to cause even more confusion because you'll have
>> to explain AOE (which is not what you described).
>>
>> __
>> OpenStack Development Mailing 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
>

__
OpenStack Development Mailing 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] [app-catalog] App Catalog IRC meeting minutes - 9/17/2015

[Christopher Aedo]

We had a nice meeting today and caught up on some of our
plans/intentions for the web site backend.  Long ago we knew that a
basically static site with assets listed in a YAML would not last for
long.  It's already causing issues with respect to versions and
updates, and makes determining when things were added really
cumbersome.

Over the next few weeks we will be transitioning to using flask for
the backend.  Initially we'll just replicate exactly what we have now,
then can slowly start adding the additional features we are planning.
We will also be using many of the same design elements (static files
and javascript) between the Horizon plugin and the website itself.

There's lots more happening here in the months to come at any rate :)
If you ever think about ways to make OpenStack clouds more useful for
the end-users (or are just curious about what we are up to), please
join us on IRC (#openstack-app-catalog).  Thanks!

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:30 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-17-17.00.log.html

Meeting summary
---
* rollcall  (docaedo, 17:00:50)
* Status updates (docaedo)  (docaedo, 17:02:07)
  * ACTION: docaedo to get SSL cert for app catalog website  (docaedo,
17:05:52)
* Discuss "new site plans" etherpad (docaedo)  (docaedo, 17:07:48)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
(docaedo, 17:07:55)
  * ACTION: docaedo to request a new repo for common elements shared
between app-catalog and ui  (docaedo, 17:15:38)
* Open discussion  (docaedo, 17:23:19)
Meeting ended at 17:28:31 UTC.

Action items, by person
---
* docaedo
  * docaedo to get SSL cert for app catalog website
  * docaedo to request a new repo for common elements shared between
app-catalog and ui

People present (lines said)
---
* docaedo (40)
* kfox (29)
* kzaitsev_mb (7)
* pkoros (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

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

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Shamail Tahir]

On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle  wrote:

>
>
> On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez 
> wrote:
>
>> Anne Gentle wrote:
>> > [...]
>> > What are some of the problems with each layer?
>> >
>> > 1. weekly meeting: time zones, global reach, size of cross-project
>> > concerns due to multiple projects being affected, another meeting for
>> > PTLs to attend and pay attention to
>>
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting
>
>
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>>
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
>>
> I wanted to add a +1 to the idea of using a tag other than [all] to
highlight cross-project communications.

>
>> > 2. specs: don't seem to get much attention unless they're brought up at
>> > weekly meeting, finding owners for the work needing to be done in a spec
>> > is difficult since each project team has its own priorities
>>
>> Right, it's difficult to get them reviewed, and getting consensus and TC
>> rubberstamp on them is also a bit of a thankless job. Basically you're
>> trying to make sure everyone is OK with what you propose and most people
>> ignore you (and then would be unhappy when they are impacted by the
>> implementation a month later). I don't think that system works well and
>> I'd prefer we change it.
>>
>> > 3. direct communications: decisions from these comms are difficult to
>> > then communicate more widely, it's difficult to get time with busy PTLs
>> > 4. Summits: only happens twice a year, decisions made then need to be
>> > widely communicated
>> >
>> > I'm sure there are more details and problems I'm missing -- feel free to
>> > fill in as needed.
>> >
>> > Lastly, what suggestions do you have for solving problems with any of
>> > these layers?
>>
>> I'm starting to think we need to overhaul the whole concept of
>> cross-project initiatives. The current system where an individual drives
>> a specific spec and goes through all the hoops to expose it to the rest
>> of the community is not really working. The current model doesn't
>> support big overall development cycle goals either, since there is no
>> team to implement those.
>>
>
> Completely agree, this is my observation as well from the service catalog
> improvement work. While the keystone team is crucial, so many other teams
> are affected. And I don't have all the key skills to implement the vision,
> nor do I want to be a spec writer who can't implement, ya know? It's a
> tough one.
>

Hi, would it make sense for the product WG to help write and/or track the
specs?  Apologies, in advance, if our workflow does not fit the needs being
discussed.

We have a defined workflow for how we will be working on user stories
through our process[1] and I wonder if a similar workflow could be built
for cross-project specs.  We are already trying to focus on
multi-release/cross-project user stories[2] but we are doing it from a
market perspective as opposed to tracking items that are cross-project
needs based on the current state.  The process could definitely be expanded
to help coordinate these needs as well.   This will allow an individual to
still be associated with a spec but if the person is unable to finish the
work or needs more help, the team could ask for more resources or let
stakeholders know that there might be a delay.

[1]
https://docs.google.com/presentation/d/1dZBm4cfpSyVlvPLpHSReaQiZ7e8SfgS7VLSbSqoWokw/edit?usp=sharing
[2] https://wiki.openstack.org/wiki/ProductTeam#Objectives

>
>
>>
>> Just brainstorming out loud, maybe we need to have a base team of people
>> committed to drive such initiatives to completion, a team that
>> individuals could leverage when they have a cross-project idea, a team
>> that could define a few cycle goals and actively push them during the
>> cycle.
>>
>
This is very similar to how the Product WG structure is setup as well.  We
have cross-project liaisons (CPLs) that participate in the project team
meetings and also user-story owners who cover the overall goal of
completing the user story.  The user story owner leverages the cross
project liaisons to help with tracking component/project specific
dependencies for implementing the user story but the user story owner is
looking at the overall state of the bigger picture.   Our CPLs work 

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Kevin Benton]

Midway is still on earth. :)

On Thu, Sep 17, 2015 at 10:35 AM, Neil Jerram 
wrote:

> But on the Internet, no one knows that I'm really a crocodile, and
> writing from Midway...
>
> Neil
>
>
> On 17/09/15 18:29, Kevin Benton wrote:
> >
> > Maybe it would be a good idea to switch to 23:59 AOE deadlines like
> > many paper submissions use for academic conferences. That way there is
> > never a need to convert TZs, you just get it in by the end of the day
> > in your own time zone.
> >
> > On Sep 17, 2015 9:18 AM, "Edgar Magana"  > > wrote:
> >
> > Folks,
> >
> > Last year I found myself in the same position when I missed a
> > deadline because my wrong planning and time zones nightmare!
> > However, the rules were very clear and I assumed my mistake. So,
> > we should assume that we do not have candidates and follow the
> > already described process. However, this should be very easy to
> > figure out for the TC, it is just a matter to find our who is
> > interested in the PTL role and consulting with the core team of
> > that specific project.
> >
> > Just my two cents…
> >
> > Edgar
> >
> > From: Kyle Mestery
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)"
> > Date: Thursday, September 17, 2015 at 8:48 AM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > Subject: Re: [openstack-dev] [all][elections] PTL nomination
> > period is now over
> >
> > On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor
> > > wrote:
> >
> > On 09/17/2015 04:50 PM, Anita Kuno wrote:
> >
> > On 09/17/2015 08:22 AM, Matt Riedemann wrote:
> >
> >
> >
> > On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
> >
> > PTL Nomination is now over. The official candidate
> > list is available on
> > the wiki[0].
> >
> > There are 5 projects without candidates, so
> > according to this
> > resolution[1], the TC we'll have to appoint a new
> > PTL for Barbican,
> > MagnetoDB, Magnum, Murano and Security
> >
> >
> > This is devil's advocate, but why does a project
> > technically need a PTL?
> >   Just so that there can be a contact point for
> > cross-project things,
> > i.e. a lightning rod?  There are projects that do a
> > lot of group
> > leadership/delegation/etc, so it doesn't seem that a
> > PTL is technically
> > required in all cases.
> >
> >
> > I think that is a great question for the TC to consider
> > when they
> > evaluate options for action with these projects.
> >
> > The election officials are fulfilling their obligation
> > according to the
> > resolution:
> >
> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst
> >
> > If you read the verb there the verb is "can" not "must", I
> > choose the
> > verb "can" on purpose for the resolution when I wrote it.
> > The TC has the
> > option to select an appointee. The TC can do other things
> > as well,
> > should the TC choose.
> >
> >
> > I agree- and this is a great example of places where human
> > judgement is better than rules.
> >
> > For instance - one of the projects had a nominee but it missed
> > the deadline, so that's probably an easy on.
> >
> > For one of the projects it had been looking dead for a while,
> > so this is the final nail in the coffin from my POV
> >
> > For the other three - I know they're still active projects
> > with people interested in them, so sorting them out will be fun!
> >
> >
> > This is the right approach. Human judgement #ftw! :)
> >
> >
> >
> >
> >
> >
> > There are 7 projects that will have an election:
> > Cinder, Glance, Ironic,
> > Keystone, Mistral, Neutron and Oslo. The details
> > for those will be
> > posted tomorrow after Tony and I setup the CIVS
> > system.
> >
> > Thank you,
> > Tristan
> >
> >
> > [0]:
> >
> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
> >
> > [1]:
> >
> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
> >
> >
> >
> >
> >
> >
>  

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

[Steven Dake (stdake)]

It appears the core team is mostly in agreement about the idea of having 
support for commercial distributions of OpenStack in Kolla.  The vote was 
nearly unanimous.  That said, there was some feedback that came out of the 
various comments.

As a community:
We should set standards by which distros of OpenStack should operate in order 
to stay inside the Kolla tree
We should be willing to remove in-tree distros if their engineering backing 
disappears or their contributors lose interest in maintaining the distros
We should judge each new distro with an eye towards minimizing maintenance 
burden
We should be inclusive and make an effort to facilitate participation in Kolla 
from commercial distributions of OpenStack
Down the road we should sort out our CI requirements, once we actually have 
effective CI for our free distros of OpenStack

Thanks everyone for your valued time in responding on this vote.

Regards
-steve


From: Martin André >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, September 17, 2015 at 7:07 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla] Followup to review in gerrit relating to 
RHOS + RDO types



On Thu, Sep 17, 2015 at 3:22 AM, > 
wrote:
There is an apparent need for having official RHOS being supported from our 
end, and we just so happen to have the possibility of filling that need. Should 
the need arise to support whatever fancy proprietary backend system or even 
have Kolla integrate with Oracle Solaris or something, that need would most 
probably be backed by a company plus developer effort. I believe the burden for 
our current (great) team would more or less stay the same (eg. lets assume we 
don't know anything about Solaris), so this company should ship in devvers to 
aid their 'wish'. The team effort with these additional devvers would indeed 
grow, bigtime. Keeping our eyes on the matters feels like a fair solution, 
allowing for these additions while guarding the effort they take. Should Kolla 
start supporting LXC besides Docker, that would be awesome (uhm...) - but I 
honestly don't see a need to be thinking about that right now, if someone comes 
up with a spec about it and wants to invest time+effort we can atleast review 
it. We shouldn't prepare our Dockerfiles for such a possibility though, whereas 
the difference between RHOS and CentOS is very little. Hence, support is rather 
easy to implement.

The question was if Kolla wants/should support integrating with 3rd party 
tools, and I think we should support it. There should be rules, yes. We 
probably shouldn't be worrying about proprietary stuff that other projects 
hardly take seriously (even though drivers have been accepted)...

Vote: +1

- harmw

Sam Yaple schreef op 2015-09-14 13:44:
On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke 
>
wrote:

On 13/09/15 18:34, Steven Dake (stdake) wrote:

Response inline.

From: Sam Yaple 
>>
Reply-To: 
"s...@yaple.net>"
>>
Date: Sunday, September 13, 2015 at 1:35 AM
To: Steven Dake 
>>
Cc: "OpenStack Development Mailing List (not for usage
questions)"


  
tack-...@lists.openstack.org>>
Subject: Re: [kolla] Followup to review in gerrit relating to
RHOS + RDO types

On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake)
>>
 wrote:
Response inline.

From: Sam Yaple 
>>
Reply-To: 
"s...@yaple.net>"
>>
Date: Saturday, September 12, 2015 at 11:34 PM
To: Steven Dake 
>>
Cc: "OpenStack Development Mailing List (not for usage
questions)"


  
tack-...@lists.openstack.org>>
Subject: Re: [kolla] Followup to review in gerrit relating to
RHOS + RDO types

Sam Yaple

On Sun, Sep 13, 2015 at 1:15 AM, 

Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

[Edgar Magana]

Not a core but I would like to share my +1 about Michael.

Cheers,

Edgar




On 9/16/15, 3:33 PM, "Doug Wiegley"  wrote:

>Hi all,
>
>As the Lieutenant of the advanced services, I nominate Michael Johnson to be a 
>member of the neutron-lbaas core reviewer team.
>
>Review stats are in line with other cores[2], and Michael has been 
>instrumental in both neutron-lbaas and octavia.
>
>Existing cores, please vote +1/-1 for his addition to the team (that’s 
>Brandon, Phil, Al, and Kyle.)
>
>Thanks,
>doug
>
>1. 
>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] service default value functions

[Matt Fischer]

Clint,

We're solving a different issue. Before anytime someone added an option we
had this logic:

if $setting {
  project_config/setting: value => $setting
}
else {
  project_config/setting: ensure => absent;
}

This was annoying to have to write for every single setting but without it,
nobody could remove settings that they didn't want and fall back to the
project defaults.

This discussion is about a way in the libraries to do the ensure absent but
to drop all the else {} clauses in all our modules.



On Thu, Sep 17, 2015 at 11:39 AM, Clint Byrum  wrote:

> Excerpts from Alex Schultz's message of 2015-09-16 09:53:10 -0700:
> > Hey puppet folks,
> >
> > Based on the meeting yesterday[0], I had proposed creating a parser
> > function called is_service_default[1] to validate if a variable matched
> our
> > agreed upon value of ''.  This got me thinking about how
> > can we maybe not use the arbitrary string throughout the puppet that can
> > not easily be validated.  So I tested creating another puppet function
> > named service_default[2] to replace the use of ''
> > throughout all the puppet modules.  My tests seemed to indicate that you
> > can use a parser function as parameter default for classes.
> >
> > I wanted to send a note to gather comments around the second function.
> > When we originally discussed what to use to designate for a service's
> > default configuration, I really didn't like using an arbitrary string
> since
> > it's hard to parse and validate. I think leveraging a function might be
> > better since it is something that can be validated via tests and a syntax
> > checker.  Thoughts?
>
> I'm confused.
>
> Why aren't you omitting the configuration option from the file if you
> want to use the default? Isn't that what undef is for?
>
> __
> OpenStack Development Mailing 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][elections] PTL nomination period is now over

[Kevin Benton]

How is it not what I described? Time zones become irrelevant if you get it
in by the end of the day in your local time zone.

https://en.wikipedia.org/wiki/Anywhere_on_Earth

On Thu, Sep 17, 2015 at 10:30 AM, Brian Curtin  wrote:

> On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton  wrote:
> > Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
> > paper submissions use for academic conferences. That way there is never a
> > need to convert TZs, you just get it in by the end of the day in your own
> > time zone.
>
> This is somehow going to cause even more confusion because you'll have
> to explain AOE (which is not what you described).
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [mistral][requirements] lockfile not in global requirements

[Andreas Jaeger]

The syncing of requirements fails from the requirements repository to 
mistral-extra with

'lockfile' is not in global-requirements.txt

Mistral team, could you either propose to add lockfile to the global 
requirements file - or remove it from your project, please?


for details see:
https://jenkins.openstack.org/job/propose-requirements-updates/363/consoleFull

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


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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Brian Curtin]

On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton  wrote:
> Maybe it would be a good idea to switch to 23:59 AOE deadlines like many
> paper submissions use for academic conferences. That way there is never a
> need to convert TZs, you just get it in by the end of the day in your own
> time zone.

This is somehow going to cause even more confusion because you'll have
to explain AOE (which is not what you described).

__
OpenStack Development Mailing List (not for 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] LVM snapshot performance issue -- why isn't thin provisioning the default?

[Eric Harney]

On 09/17/2015 05:00 AM, Duncan Thomas wrote:
> On 16 September 2015 at 23:43, Eric Harney  wrote:
> 
>> Currently, at least some options set in [DEFAULT] don't apply to
>> per-driver sections, and require you to set them in the driver section
>> as well.
>>
> 
> This is extremely confusing behaviour. Do you have any examples? I'm not
> sure if we can fix it without breaking people's existing configs but I
> think it is worth trying. I'll add it to the list of things to talk about
> briefly in Tokyo.
> 

The most recent place this bit me was with iscsi_helper.

If cinder.conf has:

[DEFAULT]
iscsi_helper = lioadm
enabled_backends = lvm1

[lvm1]
volume_driver = ...LVMISCSIDriver
# no iscsi_helper setting


You end up with c-vol showing "iscsi_helper = lioadm", and
"lvm1.iscsi_helper = tgtadm", which is the default in the code, and not
the default in the configuration file.

I agree that this is confusing, I think it's also blatantly wrong.  I'm
not sure how to fix it, but I think it's some combination of your
suggestions above and possibly having to introduce new option names.

__
OpenStack Development Mailing List (not for 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][lbaas] Proposing Michael Johnson for neutron-lbaas core team

[Brandon Logan]

I'm off today so my +1 is more like a +2

On Sep 17, 2015 12:59 PM, Edgar Magana  wrote:
Not a core but I would like to share my +1 about Michael.

Cheers,

Edgar




On 9/16/15, 3:33 PM, "Doug Wiegley"  wrote:

>Hi all,
>
>As the Lieutenant of the advanced services, I nominate Michael Johnson to be a 
>member of the neutron-lbaas core reviewer team.
>
>Review stats are in line with other cores[2], and Michael has been 
>instrumental in both neutron-lbaas and octavia.
>
>Existing cores, please vote +1/-1 for his addition to the team (that’s 
>Brandon, Phil, Al, and Kyle.)
>
>Thanks,
>doug
>
>1. 
>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Sylvain Bauza]

Le 17/09/2015 19:26, Kevin Benton a écrit :


Maybe it would be a good idea to switch to 23:59 AOE deadlines like 
many paper submissions use for academic conferences. That way there is 
never a need to convert TZs, you just get it in by the end of the day 
in your own time zone.





IMHO, the current process leaves enough time for proposing a candidacy, 
given that it's first advertised by beginning of the cycle on the main 
Release schedule wiki page (eg. for Liberty [1]) and then officially 
announced 8 days before the deadline. We also know that PTL elections 
come around 6 weeks before the Summit every cycle. One last official 
annoucement is made 1 day before the deadline.


Trying to target the very last moment for providing a candidacy just 
seems risky to me in that condition and we should really propose to the 
candidates to not wait for the last minute and propose far eariler.


-Sylvain


[1] 
https://wiki.openstack.org/w/index.php?title=Liberty_Release_Schedule=78501


On Sep 17, 2015 9:18 AM, "Edgar Magana" > wrote:


Folks,

Last year I found myself in the same position when I missed a
deadline because my wrong planning and time zones nightmare!
However, the rules were very clear and I assumed my mistake. So,
we should assume that we do not have candidates and follow the
already described process. However, this should be very easy to
figure out for the TC, it is just a matter to find our who is
interested in the PTL role and consulting with the core team of
that specific project.

Just my two cents…

Edgar

From: Kyle Mestery
Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
Date: Thursday, September 17, 2015 at 8:48 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [all][elections] PTL nomination
period is now over

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor
> wrote:

On 09/17/2015 04:50 PM, Anita Kuno wrote:

On 09/17/2015 08:22 AM, Matt Riedemann wrote:



On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate
list is available on
the wiki[0].

There are 5 projects without candidates, so
according to this
resolution[1], the TC we'll have to appoint a new
PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


This is devil's advocate, but why does a project
technically need a PTL?
  Just so that there can be a contact point for
cross-project things,
i.e. a lightning rod?  There are projects that do a
lot of group
leadership/delegation/etc, so it doesn't seem that a
PTL is technically
required in all cases.


I think that is a great question for the TC to consider
when they
evaluate options for action with these projects.

The election officials are fulfilling their obligation
according to the
resolution:

http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

If you read the verb there the verb is "can" not "must", I
choose the
verb "can" on purpose for the resolution when I wrote it.
The TC has the
option to select an appointee. The TC can do other things
as well,
should the TC choose.


I agree- and this is a great example of places where human
judgement is better than rules.

For instance - one of the projects had a nominee but it missed
the deadline, so that's probably an easy on.

For one of the projects it had been looking dead for a while,
so this is the final nail in the coffin from my POV

For the other three - I know they're still active projects
with people interested in them, so sorting them out will be fun!


This is the right approach. Human judgement #ftw! :)





There are 7 projects that will have an election:
Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details
for those will be
posted tomorrow after Tony and I setup the CIVS
system.

Thank you,
Tristan


[0]:

https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates

[1]:

[openstack-dev] [OSSN 0055] Service accounts may have cloud admin privileges

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Service accounts may have cloud admin privileges
- ---

### Summary ###
OpenStack services (for example Nova and Glance) typically use a
service account in Keystone to perform actions.  In some cases this
service account has full admin privileges, may therefore perform any
action on your cloud, and should be protected appropriately.

### Affected Services / Software ###
Most OpenStack services / all versions

### Discussion ###
In many cases, OpenStack services require an OpenStack account to
perform API actions such as validating Keystone tokens.  Some
deployment tools grant administrative level access to these service
accounts, making these accounts very powerful.

A service account with administrator access could be used to:

  - destroy/modify/access data
  - create or destroy admin accounts
  - potentially escalate to undercloud access
  - log in to Horizon

### Recommended Actions ###
Service accounts can use the "service" role rather than admin.  You
can check what role the service account has by performing the following
steps:

1. List roles:

 openstack role list

2. Check the role assignment for the service user in question:

 openstack role assignment list --user 

3. Compare the ID listed in the "role" column from step 2 with the role
IDs listed in step 1.  If the role is listed as "admin", the service
account has full admin privileges on the cloud.

It is possible to change the role to "service" for some accounts but
this may have unexpected consequences for services such as Nova and
Neutron, and is therefore not recommended for inexperienced admins.

If a service account does have admin, it's advisable to closely
monitor login events for that user to ensure that it is not used
unexpectedly.  In particular, pay attention to unusual IPs using the
service account.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0055
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1464750
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+wq9AAoJEJa+6E7Ri+EVxgUH/2EEDXgPQn0TZpds9kK10mVC
jsi8Y/OEAJD2xnUS+ZkT0GbpopOJa3XRWKUmPCufYDz5Ay3ATyTfMuSdH519ZDK6
0sfZmSZK/AKXALFoUUBB1J2QckmrbH9tvMlr3NQ6f1a4MT0UIgkQvGZnduGSF9Gm
aglGWcuhL7TvzuuawwHoivDtWdNWEYOgrvG1779U6uSz9Dj23GvQQwn79y6JE7qt
N2D9dcxqXBlOV+hfcidJVzZ9FvEz7YY2yHZ9EK1apCinDhRin8CH+0W5Ukbur2K+
I1JtvIqMHddoKu6REqQCe3vyme7IHUuYYpiwJgT3yNBDlk+3nbjwRLcUpW4XNPk=
=cGtS
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Kevin Benton]

It guarantees that if you hit the date deadline local time, that you won't
miss the deadline. It doesn't matter if there are extra hours afterwards.
The idea is that it gets rid of the need to do time zone conversions.

If we are trying to do some weird optimization where everyone wants to
submit in the last 60 seconds, then sure AOE isn't great for that because
you still have to convert. It doesn't seem to me like that's what we are
trying to do though.
On Sep 17, 2015 11:36 AM, "Brian Curtin"  wrote:

> Because it's still day_n AOE in early hours of day_n+1 local-time in a
> lot of places. I think I have until 6 AM the day after an AOE deadline
> where it's still considered the deadline date anywhere on earth, as
> there are still places on earth where the date hasn't flipped.
>
> Your EOD is not the deadline, as it's really only a reference to how
> many more hours you have until it's no longer that date anywhere on
> earth. People screw themselves out of things by using their EOD as the
> definition.
>
> (we've been using this with the PyCon CFP since forever)
>
> On Thu, Sep 17, 2015 at 1:17 PM, Kevin Benton  wrote:
> > How is it not what I described? Time zones become irrelevant if you get
> it
> > in by the end of the day in your local time zone.
> >
> > https://en.wikipedia.org/wiki/Anywhere_on_Earth
> >
> > On Thu, Sep 17, 2015 at 10:30 AM, Brian Curtin  wrote:
> >>
> >> On Thu, Sep 17, 2015 at 12:26 PM, Kevin Benton 
> wrote:
> >> > Maybe it would be a good idea to switch to 23:59 AOE deadlines like
> many
> >> > paper submissions use for academic conferences. That way there is
> never
> >> > a
> >> > need to convert TZs, you just get it in by the end of the day in your
> >> > own
> >> > time zone.
> >>
> >> This is somehow going to cause even more confusion because you'll have
> >> to explain AOE (which is not what you described).
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> >
>
> __
> OpenStack Development Mailing 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][elections] PTL nomination period is now over

[Matt Riedemann]

On 9/17/2015 1:43 PM, Sylvain Bauza wrote:



Le 17/09/2015 19:26, Kevin Benton a écrit :


Maybe it would be a good idea to switch to 23:59 AOE deadlines like
many paper submissions use for academic conferences. That way there is
never a need to convert TZs, you just get it in by the end of the day
in your own time zone.




IMHO, the current process leaves enough time for proposing a candidacy,
given that it's first advertised by beginning of the cycle on the main
Release schedule wiki page (eg. for Liberty [1]) and then officially
announced 8 days before the deadline. We also know that PTL elections
come around 6 weeks before the Summit every cycle. One last official
annoucement is made 1 day before the deadline.

Trying to target the very last moment for providing a candidacy just
seems risky to me in that condition and we should really propose to the
candidates to not wait for the last minute and propose far eariler.


Heh, yeah, +1. If running for PTL is something you had in mind to begin 
with, you should probably be looking forward to when the elections start 
and get your ducks in a row.  Part of being PTL, a large part I'd think, 
is the ability to organize and manage things. If you're waiting until 
the 11th hour to do this, I wouldn't have much sympathy.




-Sylvain


[1]
https://wiki.openstack.org/w/index.php?title=Liberty_Release_Schedule=78501


On Sep 17, 2015 9:18 AM, "Edgar Magana" > wrote:

Folks,

Last year I found myself in the same position when I missed a
deadline because my wrong planning and time zones nightmare!
However, the rules were very clear and I assumed my mistake. So,
we should assume that we do not have candidates and follow the
already described process. However, this should be very easy to
figure out for the TC, it is just a matter to find our who is
interested in the PTL role and consulting with the core team of
that specific project.

Just my two cents…

Edgar

From: Kyle Mestery
Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
Date: Thursday, September 17, 2015 at 8:48 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [all][elections] PTL nomination
period is now over

On Thu, Sep 17, 2015 at 10:26 AM, Monty Taylor
> wrote:

On 09/17/2015 04:50 PM, Anita Kuno wrote:

On 09/17/2015 08:22 AM, Matt Riedemann wrote:



On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:

PTL Nomination is now over. The official candidate
list is available on
the wiki[0].

There are 5 projects without candidates, so
according to this
resolution[1], the TC we'll have to appoint a new
PTL for Barbican,
MagnetoDB, Magnum, Murano and Security


This is devil's advocate, but why does a project
technically need a PTL?
  Just so that there can be a contact point for
cross-project things,
i.e. a lightning rod?  There are projects that do a
lot of group
leadership/delegation/etc, so it doesn't seem that a
PTL is technically
required in all cases.


I think that is a great question for the TC to consider
when they
evaluate options for action with these projects.

The election officials are fulfilling their obligation
according to the
resolution:

http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20141128-elections-process-for-leaderless-programs.rst

If you read the verb there the verb is "can" not "must", I
choose the
verb "can" on purpose for the resolution when I wrote it.
The TC has the
option to select an appointee. The TC can do other things
as well,
should the TC choose.


I agree- and this is a great example of places where human
judgement is better than rules.

For instance - one of the projects had a nominee but it missed
the deadline, so that's probably an easy on.

For one of the projects it had been looking dead for a while,
so this is the final nail in the coffin from my POV

For the other three - I know they're still active projects
with people interested in them, so sorting them out will be fun!


This is the right approach. Human judgement #ftw! :)





There are 7 projects that will have an election:
Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details
  

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

[Carl Baldwin]

On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton  wrote:
> Yes, the L2 semantics apply to the external network as well (at least with
> ML2).

This is true and should remain so.  I think we've come to the
agreement that a neutron Network, external, shared, or not, should be
an L2 broadcast domain and have these semantics uniformly.

> One example of the special casing is the external_network_bridge option in
> the L3 agent. That would cause the agent to plug directly into a bridge so
> none of the normal L2 agent wiring would occur. With the L2 bridge_mappings
> option there is no reason for this to exist anymore because it ignoring
> network attributes makes debugging a nightmare.

+1

>>Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> An external network object is just a regular network object with a
> router:external flag set to true. Any changes to it would have to make sense
> in the context of all networks. That's why I want to make sure that whatever
> we come up with makes sense in all contexts and isn't just a bolt on corner
> case.

I have been working on a proposal around adding better L3 modeling to
Neutron.  I will have something up by the end of this week.  As a
preview, my current thinking is that we should add a new object to
represent an L3 domain.  I will propose that floating ips move to
reference this object instead of a network.  I'm also thinking that a
router's external gateway will reference an instance of this new
object instead of a Network object.  To cover current use cases, a
Network would own one of these new instances to define the subnets
that live on the network.  I think we'll also have the flexibility to
create an L3 only domain or one that spans a group of L2 networks like
what is being requested by operators [1].

We can also discuss in the context of this proposal how a Port may be
able to associate with L3-only.  As you know, ports need to provide
certain L2 services to VMs in order for them to operate.  But, does
this mean they need to associate to a neutron Network directly?  I
don't know yet but I tend to think that the model could support this
as long as VM ports have a driver like Calico behind them to support
the VMs' dependence on DHCP and ARP.

This is all going to take a fair amount of work.  I'm hoping a good
chunk of it will fit in the Mitaka cycle.

Carl

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

__
OpenStack Development Mailing List (not for 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] Discovery

[Egor Guz]

+1 for stop using public discovery endpoint, most private cloud vms doesn’t 
have access to internet and operator must to run etcd instance somewhere just 
for discovery.

—
Egor

From: Andrew Melton 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, September 17, 2015 at 12:06
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] Discovery


Hey Daneyon,


I'm fairly partial towards #2 as well. Though, I'm wondering if it's possible 
to take it a step further. Could we run etcd in each Bay without using the 
public discovery endpoint? And then, configure Swarm to simply use the internal 
ectd as it's discovery mechanism? This could cut one of our external service 
dependencies and make it easier to run Magnum is an environment with locked 
down public internet access.​


Anyways, I think #2 could be a good start that we could iterate on later if 
need be.


--Andrew



From: Daneyon Hansen (danehans) >
Sent: Wednesday, September 16, 2015 11:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Discovery

All,

While implementing the flannel --network-driver for swarm, I have come across 
an issue that requires feedback from the community. Here is the breakdown of 
the issue:

  1.  Flannel [1] requires etcd to store network configuration. Meeting this 
requirement is simple for the kubernetes bay types since kubernetes requires 
etcd.
  2.  A discovery process is needed for bootstrapping etcd. Magnum implements 
the public discovery option [2].
  3.  A discovery process is also required to bootstrap a swarm bay type. 
Again, Magnum implements a publicly hosted (Docker Hub) option [3].
  4.  Magnum API exposes the discovery_url attribute that is leveraged by swarm 
and etcd discovery.
  5.  Etcd can not be implemented in swarm because discovery_url is associated 
to swarm’s discovery process and not etcd.

Here are a few options on how to overcome this obstacle:

  1.  Make the discovery_url more specific, for example etcd_discovery_url and 
swarm_discovery_url. However, this option would needlessly expose both 
discovery url’s to all bay types.
  2.  Swarm supports etcd as a discovery backend. This would mean discovery is 
similar for both bay types. With both bay types using the same mechanism for 
discovery, it will be easier to provide a private discovery option in the 
future.
  3.  Do not support flannel as a network-driver for k8s bay types. This would 
require adding support for a different driver that supports multi-host 
networking such as libnetwork. Note: libnetwork is only implemented in the 
Docker experimental release: 
https://github.com/docker/docker/tree/master/experimental.

I lean towards #2 but their may be other options, so feel free to share your 
thoughts. I would like to obtain feedback from the community before proceeding 
in a particular direction.

[1] https://github.com/coreos/flannel
[2] 
https://github.com/coreos/etcd/blob/master/Documentation/discovery_protocol.md
[3] https://docs.docker.com/swarm/discovery/

Regards,
Daneyon Hansen
__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[John Griffith]

On Thu, Sep 17, 2015 at 2:23 PM, Kyle Mestery  wrote:

> On Thu, Sep 17, 2015 at 3:19 PM, Anne Gentle <
> annegen...@justwriteclick.com> wrote:
>
>>
>>
>> On Thu, Sep 17, 2015 at 3:15 PM, John Griffith 
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 17, 2015 at 2:00 PM, Doug Hellmann 
>>> wrote:
>>>
 Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:

 > I think this is all superfluous however and we should simply encourage
 > people to not wait until the last minute. Waiting to see who is
 > running/what the field looks like isn't as important as standing up
 and
 > saying you're interested in running.

 +1

 Doug


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

>>>
>>> ​My dog ate my homework...
>>> My car wouldn't start...
>>> I couldn't figure out what UTC time was...
>>>
>>> The guidelines seemed pretty clear:
>>> Any member of an election electorate can propose their candidacy for the
>>> same election until September 17, 05:59 UTC​
>>>
>>> That being said, a big analysis on date/time selection etc doesn't
>>> really seem warranted here or harping on the fact that something 'went
>>> wrong'.  I as a TC member have no problem saying "things happen" and those
>>> that have submitted candidacy albeit late and are unopposed are in.. no
>>> muss no fuss.  I *think* we're all reasonable adults and don't know that
>>> anybody had in mind that the TC would arbitrarily assign somebody that
>>> wasn't even listed as a PTL for one of the mentioned projects.
>>>
>>>
>> It's not so simple for Magnum, with 2 late candidacies. We'll figure it
>> out but yes, we have work to do.
>>
>>
> It could be simple: Let magnum have an election with both candidates. As
> Monty said:
>
​+1

Also, not the second submitter stated they only submitted because they
noticed nobody else was running.  Regardless seems easy enough to deal
with. ​


>
> "... this is a great example of places where human judgement is better
> than rules."
>
> Thanks,
> Kyle
>
>
>> Anne
>>
>>
>> Moving on,
>>> John
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>
>> --
>> Anne Gentle
>> Rackspace
>> Principal Engineer
>> www.justwriteclick.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Associating patches with bugs/bps (Please don't hurt me)

[Ryan Rossiter]

I'm going to start out by making this clear: I am not looking to incite 
a flame war.


I've been working in Magnum for a couple of weeks now, and I'm starting 
to get down the processes for contribution. I'm here to talk about the 
process of always needing to have a patch associated with a bug or 
blueprint.


I have a good example of this being too strict. I knew the rules, so I 
opened [1] to say there are some improperly named variables and classes. 
I think it took longer for me to open the bug than it did to actually 
fix it. I think we need to start taking a look at how strict we need to 
be in requiring bugs to be opened and linked to patches. I understand 
it's a fine line between "it's broken" to "it would be nice to make this 
better".


I remember the debate when I was originally putting up [2] for review. 
The worry was that if these new tests would cut into developer 
productivity because it is more strict. The same argument can be applied 
to opening these bugs. If we have to open something up for everything we 
want to upload a patch for, that's just another step in the process to 
take up time.


Now, with my opinion out there, if we still want to take the direction 
of opening up bugs for everything, I will comply (I'm not the guy making 
decisions around here). I would like to see clear and present 
documentation explaining this to new contributors, though ([3] would 
probably be a good place to explain this).


Once again, not looking to start an argument. If everyone feels the way 
it works now is the best, I'm more than happy to join in :)


[1] https://bugs.launchpad.net/magnum/+bug/1496568
[2] https://review.openstack.org/#/c/217342/
[3] http://docs.openstack.org/developer/magnum/contributing.html

--
Thanks,

Ryan Rossiter (rlrossit)


__
OpenStack Development Mailing 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] [app-catalog] versions for murano assets in the catalog

[Christopher Aedo]

One big thing missing from the App Catalog right now is the ability to
version assets.  This is especially obvious with the Murano assets
which have some version/release dependencies.  Ideally an app-catalog
user would be able to pick an older version (ie "works with kilo
rather than liberty"), but we don't have that functionality yet.

We are working on resolving handling versions elegantly from the App
Catalog side but in the short term we believe Murano is going to need
a workaround.  In order to support multiple entries with the same name
(i.e. Apache Tomcat package for both Kilo and Liberty) we are
proposing the Liberty release of Murano have a new default URL, like:

MURANO_REPO_URL="http://apps.openstack.org/api/v1/murano_repo/liberty/;

We have a patch ready [1] which would redirect traffic hitting that
URL to http://storage.apps.openstack.org.  If we take this approach,
we will then retain the ability to manage where Murano fetches things
from without requiring clients of the Liberty-Murano release to do
anything.  For instance, if there is a need for Liberty versions of
Murano packages to be different from Kilo, we could set up a
Liberty-specific directory and put those versions there, and then
adjust the redirect appropriately.

What do you think?  We definitely need feedback here, otherwise we are
likely to break things Murano relies on.  kzaitsev is active on IRC
and was the one who highlighted this issue, but if there are other
compatibility or version concerns as Murano continues to grow and
improve, we could use one or two more people from Murano to stay in
touch with us wherever you intersect with the App Catalog so we don't
break something for you :)

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

-Christopher

__
OpenStack Development Mailing List (not for 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][elections] PTL nomination period is now over

[Doug Hellmann]

Excerpts from Morgan Fainberg's message of 2015-09-17 12:51:33 -0700:

> I think this is all superfluous however and we should simply encourage
> people to not wait until the last minute. Waiting to see who is
> running/what the field looks like isn't as important as standing up and
> saying you're interested in running.

+1

Doug

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