Re: [openstack-dev] [Kuryr][Dragonflow] - PTL Non Candacy

[Li Ma]

It was a good pleasure to work with you, Gal.You did an awesome job
for Dragonflow.

Thanks for all your help and guide in this project. Hopefully we can
get-together
some time or cooperate in other projects in the future.

On Mon, Sep 12, 2016 at 4:31 PM, Gal Sagie  wrote:
> Hello all,
>
> I would like to announce that i will not be running for projects Kuryr or
> Dragonflow
> PTL.
>
> I believe that both projects shows great value and progress compared to the
> time they exists
> mostly thanks to the great communities actively working on both of them.
>
> I also strongly believe that the PTL position is one that should be
> alternating given there is
> a good candidate and i believe there are some great candidates for both
> projects.
>
> I will of course still stay involved in both projects and excited to see
> what the next
> release is going to bring.
>
> Thanks for everyone that closely helped and contributed and lets keep up on
> making
> OpenStack great together.
>
> Gal.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

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] [Kuryr][Dragonflow] - PTL Non Candacy

[Antoni Segura Puimedon]

On Mon, Sep 12, 2016 at 10:31 AM, Gal Sagie  wrote:
> Hello all,
>
> I would like to announce that i will not be running for projects Kuryr or
> Dragonflow
> PTL.
>
> I believe that both projects shows great value and progress compared to the
> time they exists
> mostly thanks to the great communities actively working on both of them.
>
> I also strongly believe that the PTL position is one that should be
> alternating given there is
> a good candidate and i believe there are some great candidates for both
> projects.
>
> I will of course still stay involved in both projects and excited to see
> what the next
> release is going to bring.
>
> Thanks for everyone that closely helped and contributed and lets keep up on
> making
> OpenStack great together.

Thanks to you for all the hard work and dedication to making Kuryr a welcoming
community!

>
> Gal.
>
>
> __
> OpenStack Development Mailing 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] [telemetry] PTL candidacy

[Julien Danjou]

Hi!

The Telemetry project continued improving this last cycle, and I'm really glad
of what the team achieve. We continued to reduce our technical debt a lot, and
improved various parts of our stack. We're still leading some parts of the
OpenStack development platform, and I think it's a great achievement for a
small team like us.

I want us to continue on this trajectory and continue to set the bar higher for
the projects in general. That's why I'm running again this time to serve the
team as team lead. I'll continue to manage the project in a transparent way and
do everything I can to grow our community and make people feel welcome.

The goals I set for Newton have mostly been met: Panko is real, we reduced
hard-coupling and technical debt, and added some fancy new features here and
there.

Looking forward to Ocata, I hope we'll be able to continue improving in that
direction. We still have a lot of things to do, such as improving our
documentation, API ref, etc and making our stack more solid.

And I know we'll do this!

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

Submitted at https://review.openstack.org/#/c/368666/


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

[openstack-dev] [Kuryr][Dragonflow] - PTL Non Candacy

[Gal Sagie]

Hello all,

I would like to announce that i will not be running for projects Kuryr or
Dragonflow
PTL.

I believe that both projects shows great value and progress compared to the
time they exists
mostly thanks to the great communities actively working on both of them.

I also strongly believe that the PTL position is one that should be
alternating given there is
a good candidate and i believe there are some great candidates for both
projects.

I will of course still stay involved in both projects and excited to see
what the next
release is going to bring.

Thanks for everyone that closely helped and contributed and lets keep up on
making
OpenStack great together.

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

[openstack-dev] [fuel][9.0][Deployment][Error]

[Samer Machara]

Hi, 

I'm trying to deploy a basic three nodes architecture to test Fuel 9: 1 
controller, 1storage and 1 compute nodes. After some minutes, I got this error 
message: 
Deployment has failed. All nodes are finished. Failed tasks: Task[sync_time/1], 
Task[sync_time/3], Task[sync_time/2] Stopping the deployment process! 
So I tried to redeploy it but without success. 

It works well with Fuel 6.0, but I would like to work with version 9. 
More details at https://bugs.launchpad.net/fuel/+bug/1622518 


The diagnostic Snapshot is to big to be sent or attached to the Bug. 




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] [Cinder] FFE request for RBD replication

[Michał Dulko]

+1, thanks for taking care of that!

On 09/12/2016 03:35 AM, Huang Zhiteng wrote:
> +1 for this long-waited feature to land in Newton.
>
> On Sun, Sep 11, 2016 at 1:09 AM, Jay S. Bryant
> >
> wrote:
>
> +1 from me.  It is making good progress and is low risk.
>
> -Jay
>
>
>
> On 09/09/2016 02:32 PM, Gorka Eguileor wrote:
>
> Hi,
>
> As some of you may know, Jon Bernard (jbernard on IRC) has
> been working
> on the RBD v2.1 replication implementation [1] for a while,
> and we would
> like to request a Feature Freeze Exception for that work, as
> we believe
> it is a good candidate being a low risk change for the
> integrity of
> the existing functionality in the driver:
>
> - It's non intrusive if it's not enabled (enabled using
>replication_device configuration option).
> - It doesn't affect existing deployments (disabled by default).
> - Changes are localized to the driver itself (rbd.py) and the
> driver
>unit tests file (test_rbd.py).
>
> Jon would have liked to make this request himself, but due to the
> untimely arrival of his newborn baby this is not possible.
>
> For obvious reasons Jon will not be available for a little
> while, but
> this will not be a problem, as I am well acquainted with the
> code -and
> I'll be able to reach Jon if necessary- and will be taking
> care of the
> final steps of the review process of his patch: replying to
> comments in
> a timely fashion, making changes to the code as required, and
> answering
> pings on IRC regarding the patch.
>
> Since some people may be interested in testing this
> functionality during
> the reviewing process -or just for fun- I'll be publishing a
> post with
> detailed explanation on how to deploy and test this feature as
> well as
> an automated way to deploy 2 Ceph clusters -linked to be
> mirroring one
> another-, and one devstack node with everything ready to test the
> functionality (configuration and keys for the Ceph clusters,
> cinder
> configuration, the latest upstream patch, and a volume type
> with the
> right configuration).
>
> Please, do not hesitate to ask if there are any questions to
> or concerns
> related to this request.
>
> Thank you for taking the time to evaluate this request.
>
> Cheers,
> Gorka.
>
> [1]: https://review.openstack.org/333565
> 
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Regards
> Huang Zhiteng
>
>
> __
> OpenStack Development Mailing 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] [charms] PTL candidacy

[James Page]

Hi

I would like to announce my candidacy for PTL of the OpenStack Charms
project (see [0]).

I'm the incumbent and first PTL of this project, which joined the OpenStack
project this year;  Right now we have around 30 charms for deploying
various parts of OpenStack, with an active core team 100% populated by
Canonical.

We're slowly incubating contribution from outside of this team - this cycle
I want to focus on changing that; specifically I think we have shortcomings
in engaging new developers, as getting into OpenStack charm development can
be high cost - the route to testing your charm change prior to submission
currently presents various options, and I want to focus on ensuring that
anyone with a reasonably specified machine can get started deploying
OpenStack and hacking on the OpenStack charms, enabling both end-users and
developers to have a better start in using and understanding the OpenStack
Charms.

I will continue to drive cross charm initiatives; specifically I think
Python 3 support is a key objective during the Ocata cycle, and we should
aim
to have that in place as early in cycle as possible.

I also look forward to working collaboratively with other deployment
projects
within the OpenStack project.

I look forward to helping steer the project during the Ocata cycle, and
helping to incubate the developer and user community around the OpenStack
Charms!

Cheers

James

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

[openstack-dev] [kolla][elections][ptl] Kolla PTL Candidacy for Jeffrey Zhang

[Jeffrey Zhang]

Hi Everyone,

I'm excited to announce my candidacy for PTL for Kolla team during the Ocata
cycle.

Kolla is a fantastic project. It brings fresh new blood to OpenStack Deployment
Management. Simplifying the lives of Operators when managing OpenStack is
essential to OpenStack’s success and I personally believe Kolla as of Liberty
1.1.0 delivers on that promise. I also deployed several Kolla production
environment for customers without any problem. I've been a core contributor to
Kolla since Mitaka. I am full time on Kolla project and have been heavily
involved with all of my waking hours[0][1].

Over the Newton development cycle, we have implemented numerous new features
and improved stability and usability. The top features are:

* Introduced the Bifrost and kolla-host to manage the bare metal provision and
  initialize the node before deploying OpenStack.
* The introduction of far more services including Aodh, Bifrost, Ceilometer,
  Cloudkitty, Multipath, Rally, Sahara, Tempest, Watcher.
* Implemented Dockerfile customization.
* Launched the kolla-kubernetes project.
* More robust CI jobs

As a team, the Kolla Community tested 123 nodes for Kolla using osic[2]. The
results validate Kolla works and scales to a majority of use cases today. The
major code paths that enable this scalability have been in place since Liberty
which gives a good indicator of Liberty and Mitaka scalability. As a Kolla
core reviewer and PTL self-nominee, I find this result to be highly satisfying.
One of Kolla’s many goals has been executed: Deploying OpenStack at 100+ node
count fast and easily.

The kolla community is diversely affiliated, a fantastic crew of contributors,
and excellent leadership within the core reviewer team.

For Ocata, I'd like the project focused on these objectives:

* Focus on the needs of the Kolla team.
* Optimize the speed of reconfiguration and upgrade.
* Implement and integrate with more driver plugins for neutron and cinder.
* Deliver 1.0.0 of kolla-kubernetes.
* Implement different CI jobs to test diverse scenarios.I’d like to start out
  with some really hard CI problems such as testing real upgrades and
  validating ceph in the CI jobs per commit.
* Support the implementation of a monitoring stack.

Finally, I know it is important that PTL time is spent on the non-technical
problem-solving such as mentoring potential core reviewers, scheduling the
project progress, interacting with other OpenStack projects and many other
activities a PTL undertakes.  I’d like to work this cycle on scaling those
activities across the core reviewer team.  I will use my personal strengths and
rely on the core reviewer team’s personal strengths to make Kolla Ocata the
best release yet.

Thank you for the considering me to serve as your Kolla PTL.

Regards,
Jeffrey Zhang

[0] http://stackalytics.com/?release=all=kolla=commits
[1] http://stackalytics.com/?release=all=kolla=marks
[2] https://review.openstack.org/352101

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

[openstack-dev] [Heat] Nomination for Heat PTL

[Rabi Mishra]

Hi
All,


I would like to nominate myself to take the role of Heat PTL for
the
Ocata
cycle.


I have been involved with the project since the last few years, first as
a
contributor and then a core reviewer and have had the opportunity to
work
with a great team and community. I strongly believe that with
ever
increasing adoption of Heat, we are well placed to live up to
the
expectations of the end users and OpenStack ecosystem at large,
by
continuously evolving, encouraging participation and consensus
building.


We achieved some significant milestones in the newton cycle by
making
convergence the default architecture and improving on some of the
key
non functional areas like stability and performance. I believe we
have
more work to do in these areas, when projects like TriplO start
using
Heat with convergence
enabled.


We have the fortune of having a number of experienced and previous
PTLs
in the team that makes the job of a  new PTL easier and I don't
see
the PTL anything more than a communication bridge and a team
catalyst.


I believe our focus in the Ocata cycle would
include:


- Continuously improve the stability and
performance
- Upgrades with zero
downtime
- Increase/improve the the test coverage without increasing
the
  CI
time
- Convergence
Phase-II
- Validation
improvements


And not to mention the run-of-the-mill
activities:


- Ensuring that CI jobs are healthy (and we don't break other
projects)
- On time releases with efficient coordination and
collaboration

I'm sure we would be able to achieve the goals we set for ourselves
and
would be happy to work as the team
catalyst.


Thank
you.

Rabi Mishra
__
OpenStack Development Mailing List (not for 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] governance proposal worth a visit: Write down OpenStack principles

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Jay Pipes's message of 2016-09-09 14:30:29 -0400:
>>  > To me, this statement
>>> about One OpenStack is about emphasizing those commonalities and
>>> working together to increase them, with the combined goals of
>>> improving the user and operator experience of using OpenStack and
>>> improving our own experience of making it.
>>
>> +1000 to the above, and I don't believe anything about my stance that 
>> OpenStack should be a cloud toolkit goes against that.
>>
>> The wording/philosophy that I disagree with is the "one product" thing :)
> 
> Tomato, tomato.
> 
> We're all, I think, looking at this "One OpenStack" principle from
> different perspectives.  You say "a toolkit". I say "a project".
> Thierry said "a product". The important word in all of those phrases
> is "a" -- as in singular.

FWIW I agree with Jay that the wording "a product" is definitely
outdated and does not represent the current reality. "Product"
presupposes a level of integration that we never achieved, and which is,
in my opinion, not desirable at this stage. I think that saying "a
framework" would be more accurate today. Something like "OpenStack is
one community with one common mission, producing one framework of
collaborating components" would capture my thinking.

-- 
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] [opentack-dev][tacker]Manual install Tacker fails

[Janki Chhatbar]

Hi

I tried installing manually following the guide you shared. I didnot face
any problem and the server started fine. Could you please share your
tacker.conf file and tacker.log file?

Thanks
Janki


On Mon, Sep 12, 2016 at 9:09 AM, zhi  wrote:

> hi,
>
> I downloaded the code from the master branch and installed Tacker manual
> by the document[1]. I met an error when I started the tacker-server by
> "python /usr/bin/tacker-server --config-file /etc/tacker/tacker.conf
>   --log-file /var/log/tacker/tacker.log".
>
> The error message is "
> 2016-09-12 11:20:48.427 ERROR stevedore.extension
> [req-4799662d-a606-4337-802f-d94c44b35a50 None None] Could not load
> 'noop': Can't instantiate abstract class DeviceNoop with abstract methods
> get_resource_info
> 2016-09-12 11:20:48.428 ERROR stevedore.extension
> [req-4799662d-a606-4337-802f-d94c44b35a50 None None] Could not load
> 'nova': Can't instantiate abstract class DeviceNova with abstract methods
> get_resource_info
> "
>
> Did anyone meet the same error as me?
>
> Hope for your reply.
>
>
> Thanks
>
>
> [1]. http://docs.openstack.org/developer/tacker/install/
> manual_installation.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
>
>


-- 
Thanking you

Janki Chhatbar
OpenStack | Docker | SDN
simplyexplainedblog.wordpress.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] [glance] [elections] Glance PTL non-candidacy

[Nikhil Komawar]

Hi team,


Just wanted to share my decision for not running for PTL for Glance.
It's been great serving the community in this role however, there are
some personal and family matters that I need to attend to over the next
couple of months or so.


I think the Glance team has done great and we've quite a bunch of bright
developers who are helping push the project forward in the appropriate
direction. With Glare becoming separate project and Ocata being short
cycle, I anticipate the priorities being rather obvious to those who
have stayed in touch. I will be available to do the rightful handoff to
the incoming PTL (for Ocata) and update with Newton happenings once
we're done with a few important bugs that are being targeted for RC1.


I intend to stick around in Glance and related projects like
Searchlight, Glare, etc. However, I am planning to take a more hands on
role and see a few features through in Ocata.  Given more and more
glance-cores time sharing with other projects, I think we need some
throttle in our review system. So, I'd like to help any new developers
get their reviews up, that in turn will help the Glance community.


Last but not the least, I have thoroughly enjoyed working in this role
with all my fellow stackers, particularly glancers! So, a BIG thank you
for having worked with me in making Glance better over the last couple
of years.


-- 

Cheers,
Nikhil


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

Re: [openstack-dev] [nova] Seeking info on PCI Passthrough scheduling

[Kostiantyn.Volenbovskyi]

Hi,
Probably going through [1] (and link to Admin guide made by Stephen in one of 
activity - [2]) and maybe [3] will be helpful

BR,
Konstantin
[1] https://bugs.launchpad.net/nova/+bug/1614882
[2] 
http://docs.openstack.org/admin-guide/compute-cpu-topologies.html#customizing-instance-numa-placement-policies
[3] https://bugs.launchpad.net/nova/+bug/1441169

From: Carlton, Paul (Cloud Services) [mailto:paul.carlt...@hpe.com]
Sent: Friday, September 09, 2016 7:16 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Seeking info on PCI Passthrough scheduling


Hi



I'm investigating a issue raised by our QA team and trying to locate the 
documentation or specifications that describe how

instances that use PCI-PT devices get scheduled.  I'm trying to understand what 
the expected behavior is when scheduling

an instance that used a port associated with a pci device and a flavor that 
defines numa and cpu requirements etc.



Thanks








Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard Enterprise
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Office: +44 (0) 1173 162189
Mobile:+44 (0)7768 994283
Email:paul.carl...@hpe.com
Hewlett-Packard Enterprise Limited registered Office: Cain Road, Bracknell, 
Berks RG12 1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error, you should 
delete it from your system immediately and advise the sender. To any recipient 
of this message within HP, unless otherwise stated you should consider this 
message and attachments as "HP CONFIDENTIAL".
__
OpenStack Development Mailing List (not for 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] Broken CI, overcloud.yaml not found

[Emilien Macchi]

On Mon, Sep 12, 2016 at 7:59 AM, Emilien Macchi  wrote:
> On Sun, Sep 11, 2016 at 1:22 PM, Emilien Macchi  wrote:
>> Hopefully Heïkel was also online :-)
>>
>> Here's the short term workaround: https://review.rdoproject.org/r/#/c/2186/
>> For long term, we need to backport what we want from master to
>> tripleoclient, specially all the recent mistral changes.
>>
>> So please, if you have a patch in tripleoclient that has been merged
>> since August 30th, please backport it to stable/newton.
>
> To synchronize this work, I created an etherpad:
> https://etherpad.openstack.org/p/tripleoclient-newton-backports
>
> Please use it to decide if whether of not we backport patches. Also we
> can use it to know who is doing it.

So we have this Gerrit topic:
https://review.openstack.org/#/q/topic:tripleoclient/backports/newton
with almost all backports, please still have a look at the remaining
patches in the etherpad to whether or not backport them.

Thanks,

>> Thanks,
>>
>> On Sun, Sep 11, 2016 at 12:54 PM, Emilien Macchi  wrote:
>>> So I found the reason, python-tripleoclient looks like downgraded in
>>> RDO since yesterday. See the bug report for more context.
>>>
>>> I investigated all recent changes in packaging and projects, I can't
>>> find yet the root cause of this downgrade, any hint is welcome!
>>>
>>> On Sun, Sep 11, 2016 at 12:27 PM, Emilien Macchi  wrote:
 I'm not sure how yet but it looks like
 https://review.openstack.org/#/c/315679/ broke CI (even if it passed
 jobs).
 I'm seeing a high number of failures all related to this error:

 6:19:49.979948 | Deploying templates in the directory
 /usr/share/openstack-tripleo-heat-templates
 2016-09-11 16:19:53.927301 | The following errors occurred:
 2016-09-11 16:19:53.927537 | [Errno 2] No such file or directory:
 '/usr/share/openstack-tripleo-heat-templates/overcloud-without-mergepy.yaml'
 2016-09-11 16:19:53.927609 | [Errno 2] No such file or directory:
 '/usr/share/openstack-tripleo-heat-templates/overcloud.yaml'

 See 
 http://logs.openstack.org/18/347918/5/check/gate-tripleo-ci-centos-7-nonha-multinode/e7c4b3b/console.html#_2016-09-11_16_19_53_927537

 I reported the bug here: https://bugs.launchpad.net/tripleo/+bug/1622353

 I'll investigate a bit today, but continue tomorrow. Please use this
 bug report if you have any thoughts.

 Thanks,
 --
 Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

[openstack-dev] [kuryr] September 12th meeting agenda

[Antoni Segura Puimedon]

Hi Kuryrs!

Sorry I didn't get to post it earlier, here goes today's meeting
agenda. As always, feel free to add items or bring them up during the
open discussion, I'll be checking the agenda for updates just before
the meeting starts at 14utc.

See you in the meeting,

Toni

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

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Antoni Segura Puimedon]

On Mon, Sep 12, 2016 at 1:29 PM, Coughlan, Ivan  wrote:
>
>
> Overview
>
> Kuryr proposes to address the issues of double encapsulation and exposure of
> containers as neutron entities when containers are running within VMs.
>
> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
> propose to:
>
> -  Use allowed-address-pairs configuration for the VM neutron port
>
> -  Use IPVLAN for wiring the Containers within VM
>
>
>
> In this way:
>
> -  Achieve efficient data path to container within VM
>
> -  Better leverage OpenStack EPA(Enhanced Platform Awareness)
> features to accelerate the data path (more details below)
>
> -  Mitigate the risk of vlan-aware-vms not making neutron in time
>
> -  Provide a solution that works on existing and previous openstack
> releases
>
>
>
> This work should be done in a way permitting the user to optionally select
> this feature.
>
>
>
>
>
> Required Changes
>
> The four main changes we have identified in the current kuryr codebase are
> as follows:
>
> · Introduce an option of enabling “IPVLAN in VM” use case. This can
> be achieved by using a config file option or possibly passing a command line
> argument. The IPVLAN master interface must also be identified.
>
> · If using “IPVLAN in VM” use case, Kuryr should no longer create a
> new port in Neutron or the associated VEth pairs. Instead, Kuryr will create
> a new IPVLAN slave interface on top of the VM’s master interface and pass
> this slave interface to the Container netns.
>
> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be
> identified so we can associate the additional IPVLAN addresses with the
> port. This can be achieved by querying Neutron’s show-port function and
> passing the VMs IP address.
>
> · If using “IPVLAN in VM” use case, Kuryr should associate the
> additional IPVLAN addresses with the VMs port. This can be achieved using
> Neutron’s allowed-address-pairs flag in the port-update function. We intend
> to make use of Kuryr’s existing IPAM functionality to request these IPs from
> Neutron.
>
>
>
> Asks
>
> We wish to discuss the pros and cons.
>
> For example, containers exposure as proper neutron entities and the utility
> of neutron’s allowed-address-pairs is not yet well understood.
>
>
>
> We also wish to understand if this approach is acceptable for kuryr?

Thanks Ivan, adding discussion about this to the weekly IRC meeting. Maybe it's
a bit tight for all the participants to get comfortable enough with
the specifics
to take a decision today, but let's bring the topic to the table and give an
answer during this week.

>
>
>
>
>
> EPA
>
> The Enhanced Platform Awareness initiative is a continuous program to enable
> fine-tuning of the platform for virtualized network functions.
>
> This is done by exposing the processor and platform capabilities through the
> management and orchestration layers.
>
> When a virtual network function is instantiated by an Enhanced Platform
> Awareness enabled orchestrator, the application requirements can be more
> efficiently matched with the platform capabilities.
>
> http://itpeernetwork.intel.com/openstack-kilo-release-is-shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>
> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>
> https://www.brighttalk.com/webcast/12229/181563/epa-features-in-openstack-kilo
>
>
>
>
>
> Regards,
>
> Ivan….
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> OpenStack Development Mailing 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] Is this a bug in metadata proxy...

[ZZelle]

>
> I was wondering if the user/group should be (only) set in a common config,
> like neutron.conf, if it should be duplicated in dhcp and metadata config
> files, or if the metadata ini should be added to the list of ini files,
> when starting up the DHCP agent.
>

Previously, metadata_proxy_user/group were documented in neutron.conf (when
a neutron.conf sample was in github repo) in order to deduce
metadata_proxy_socket_mode correctly.
You can also define them in both l3/dhcp.ini and metadata-agent.ini config
files or set explicitly metadata_proxy_socket_mode in metadata-agent.ini.

But it's unrelated as your trouble seems to be linked to a
metadata_proxy_watch_log misconfiguration and
metadata_proxy_user/group/watch_log are all used by dhcp/l3-agents.

With the wrong config, I hit the access denied issue and had no info
> indicating that is what has happened. Was wondering if there was any
> protection against that misconfiguration case, or way to get an indication
> of it.
>


Before dropping privileges, we cannot detect such access deny to log file
(because of features like GRsec,PaX, RBAC).
After dropping privileges, we can only log to syslog or stdout if we catch
an access deny to log file.

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

[openstack-dev] [Kuryr] IPVLAN data path proposal

[Coughlan, Ivan]

Overview
Kuryr proposes to address the issues of double encapsulation and exposure of 
containers as neutron entities when containers are running within VMs.
As an alternative to the vlan-aware-vms and use of ovs within the VM, we 
propose to:

-  Use allowed-address-pairs configuration for the VM neutron port

-  Use IPVLAN for wiring the Containers within VM

In this way:

-  Achieve efficient data path to container within VM

-  Better leverage OpenStack EPA(Enhanced Platform Awareness) features 
to accelerate the data path (more details below)

-  Mitigate the risk of vlan-aware-vms not making neutron in time

-  Provide a solution that works on existing and previous openstack 
releases

This work should be done in a way permitting the user to optionally select this 
feature.


Required Changes
The four main changes we have identified in the current kuryr codebase are as 
follows:

* Introduce an option of enabling "IPVLAN in VM" use case. This can be 
achieved by using a config file option or possibly passing a command line 
argument. The IPVLAN master interface must also be identified.

* If using "IPVLAN in VM" use case, Kuryr should no longer create a new 
port in Neutron or the associated VEth pairs. Instead, Kuryr will create a new 
IPVLAN slave interface on top of the VM's master interface and pass this slave 
interface to the Container netns.

* If using "IPVLAN in VM" use case, the VM's port ID needs to be 
identified so we can associate the additional IPVLAN addresses with the port. 
This can be achieved by querying Neutron's show-port function and passing the 
VMs IP address.

* If using "IPVLAN in VM" use case, Kuryr should associate the 
additional IPVLAN addresses with the VMs port. This can be achieved using 
Neutron's allowed-address-pairs flag in the port-update function. We intend to 
make use of Kuryr's existing IPAM functionality to request these IPs from 
Neutron.

Asks
We wish to discuss the pros and cons.
For example, containers exposure as proper neutron entities and the utility of 
neutron's allowed-address-pairs is not yet well understood.

We also wish to understand if this approach is acceptable for kuryr?


EPA
The Enhanced Platform Awareness initiative is a continuous program to enable 
fine-tuning of the platform for virtualized network functions.
This is done by exposing the processor and platform capabilities through the 
management and orchestration layers.
When a virtual network function is instantiated by an Enhanced Platform 
Awareness enabled orchestrator, the application requirements can be more 
efficiently matched with the platform capabilities.
http://itpeernetwork.intel.com/openstack-kilo-release-is-shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
https://www.brighttalk.com/webcast/12229/181563/epa-features-in-openstack-kilo


Regards,
Ivan
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kuryr] Spec and devref placement

[Antoni Segura Puimedon]

Hi Kuryrs!

On September 5th's weekly IRC meeting Irena Berezovsky suggested that
we should take a decision regarding the location of specs and devrefs.

Currently we default to putting all the specs and devrefs for:
- Kuryr
- Kuryr-libnetwork
- Kuryr-kubernetes

to openstack/kuryr. Fuxi is still being integrated and keeps its own doc.

The three proposals that came up where:
a) All specs and devrefs to openstack/kuryr
b) Specs in openstack/kuryr but devrefs in each specific project,
i.e., the one that will end up with the implementation code.
c) Both specs and devrefs in each separate Kuryr project.

I would like to advocate for option (b). It makes things easy for when
specs involve multiple kuryr pieces and, at the same time, it keeps
development information in the place where you'd expect, close to the
code.

Please, weigh on this issue here in the ML or in the weekly IRC
meeting today. The idea is to reach a decision by next week's weekly
IRC meeting and then write it in each subproject's "how to contribute"

See you later in the weekly IRC,

Toni

__
OpenStack Development Mailing List (not for 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] Broken CI, overcloud.yaml not found

[Emilien Macchi]

On Sun, Sep 11, 2016 at 1:22 PM, Emilien Macchi  wrote:
> Hopefully Heïkel was also online :-)
>
> Here's the short term workaround: https://review.rdoproject.org/r/#/c/2186/
> For long term, we need to backport what we want from master to
> tripleoclient, specially all the recent mistral changes.
>
> So please, if you have a patch in tripleoclient that has been merged
> since August 30th, please backport it to stable/newton.

To synchronize this work, I created an etherpad:
https://etherpad.openstack.org/p/tripleoclient-newton-backports

Please use it to decide if whether of not we backport patches. Also we
can use it to know who is doing it.

> Thanks,
>
> On Sun, Sep 11, 2016 at 12:54 PM, Emilien Macchi  wrote:
>> So I found the reason, python-tripleoclient looks like downgraded in
>> RDO since yesterday. See the bug report for more context.
>>
>> I investigated all recent changes in packaging and projects, I can't
>> find yet the root cause of this downgrade, any hint is welcome!
>>
>> On Sun, Sep 11, 2016 at 12:27 PM, Emilien Macchi  wrote:
>>> I'm not sure how yet but it looks like
>>> https://review.openstack.org/#/c/315679/ broke CI (even if it passed
>>> jobs).
>>> I'm seeing a high number of failures all related to this error:
>>>
>>> 6:19:49.979948 | Deploying templates in the directory
>>> /usr/share/openstack-tripleo-heat-templates
>>> 2016-09-11 16:19:53.927301 | The following errors occurred:
>>> 2016-09-11 16:19:53.927537 | [Errno 2] No such file or directory:
>>> '/usr/share/openstack-tripleo-heat-templates/overcloud-without-mergepy.yaml'
>>> 2016-09-11 16:19:53.927609 | [Errno 2] No such file or directory:
>>> '/usr/share/openstack-tripleo-heat-templates/overcloud.yaml'
>>>
>>> See 
>>> http://logs.openstack.org/18/347918/5/check/gate-tripleo-ci-centos-7-nonha-multinode/e7c4b3b/console.html#_2016-09-11_16_19_53_927537
>>>
>>> I reported the bug here: https://bugs.launchpad.net/tripleo/+bug/1622353
>>>
>>> I'll investigate a bit today, but continue tomorrow. Please use this
>>> bug report if you have any thoughts.
>>>
>>> Thanks,
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [stable] [all] Regarding string freeze and back ports involving translatable strings

[Luigi Toscano]

On Friday, 9 September 2016 14:12:51 CEST Matt Riedemann wrote:
> On 9/9/2016 1:58 PM, Ben Swartzlander wrote:
> > On 09/08/2016 08:37 PM, Matt Riedemann wrote:
> >> On 9/8/2016 7:05 PM, Ravi, Goutham wrote:
> >>> Hi,
> >>> 
> >>> 
> >>> 
> >>> I was looking for some clarity around backports of bug fixes that
> >>> qualify the stable branch policy [1].
> >>>  >>> priate-fixes>
> >>> 
> >>> 
> >>> What is the policy if the fix introduces a new translatable string or
> >>> modifies an existing one?
> >>> 
> >>> The guidelines in Release management [2]
> >>> 
> >>> regarding string freeze do not specifically call this scenario out. I
> >>> see that while translatable strings are mostly avoided, some projects
> >>> have been merging changes to stable branches with introduction of new
> >>> translatable strings.
> >>> 
> >>> 
> >>> 
> >>> The question is reminiscent of one posed in the ML a few releases ago
> >>> [3];
> >>>  >>> 2.html>
> >>> 
> >>> 
> >>> but applies to stable branches. Should we allow changes to translatable
> >>> strings for bug fixes that matter, or is it better to always deny them
> >>> for the sake of translation accuracy?
> >> 
> >> The former IMO, a high severity bug fix trumps a translation. Note that
> >> some projects are translated on the stable branches too, I know this is
> >> the case for Nova.
> >> 
> >> If it's a user-facing change, like an error message in the API, then it
> >> might require a bit more careful consideration, but if it's just a log
> >> message marked for translation that an end user of the API wouldn't see
> >> anyway, then I think it's fine to backport it.
> > 
> > So this stance makes sense to me, but I can't reconcile it with the
> > "hard string freeze" rules. Is the theory that after we release, the
> > string freeze ends for the stable branch, and that the hard string
> > freeze only exists for that 3 week period between RC1 and final release,
> > or is the theory that hard string freeze is always subject to exceptions
> > for "critical" bug fixes?
> > 
> I treat it as the former.

Interesting: I'm not a translator in the OpenStack project, but I contribute 
as translator to other Free Software communities and I would thought as the 
latter as more appropriate. Stable is stable and string changes should be 
approved on a case-by-case, otherwise translator's life can be more 
complicated especially when the next release is translated.

But as I said I'm not a translator here.

-- 
Luigi

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

[openstack-dev] [heat] resigning from heat-cores

[Pavlo Shchelokovskyy]

Hi Heaters,

with great regret I announce my resignation from the heat-core team.

About a year ago I was reassigned to another project, and despite my best
efforts I came to conclusion that unfortunately I can not keep up with
duties expected from Heat core team member in appropriate capacity.

I do still work on OpenStack, so I'm not leaving the community altogether,
and will be available in e.g. IRC. I also have some ideas left to implement
in Heat, but, given the great community we've built around the project, I
could surely make it as an ordinary contributor.

It was an honor to be a member of this team, I’ve learned a lot during this
time. Hope to see some of you in Barcelona :)

Best regards,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.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] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

[Anastasia Urlapova]

+1

On Mon, Sep 12, 2016 at 3:00 AM, Matthew Mosesohn 
wrote:

> +1
>
> On Sun, Sep 11, 2016 at 10:20 PM, Alexey Shtokolov
>  wrote:
> > +1
> >
> > Stanislaw made a great contribution!
> > I would like to mention SSL-support, YAQL expressions for data-driven
> > orchestration
> > and his awesome live YAQL evaluator for Fuel Master node [0]
> >
> > [0] https://github.com/sorrowless/fuyaql
> >
> > ---
> > WBR, Alexey Shtokolov
> > Fuel Development Lead
> >
> > On Thu, Sep 8, 2016 at 1:17 PM, Denis Egorenko 
> > wrote:
> >>
> >> +1
> >>
> >> 2016-09-08 13:06 GMT+03:00 Aleksandr Didenko :
> >>>
> >>> +1
> >>>
> >>> On Thu, Sep 8, 2016 at 11:06 AM, Sergey Vasilenko
> >>>  wrote:
> 
>  +1
> 
> 
> 
> 
>  
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>>
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Egorenko Denis,
> >> Senior Deployment Engineer
> >> Mirantis
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] should we provide 'ironic node-list --chassis' and 'ironic port-list --node' commands?

[Loo, Ruby]

Hi,

Vlad was the only one that was luke-warm in favour of 'ironic node-list 
--chassis'. Since I haven't received any positive, enthusiastic comment about 
wanting it, I don't think it is worth spending any more time pursuing it.

'openstack baremetal node list --chassis' does exist though (in 1.7.0 [1]).

--ruby

[1] http://docs.openstack.org/releasenotes/python-ironicclient/newton.html


On 2016-08-30, 11:57 AM, "Vladyslav Drok" 
> wrote:

The ironic node-list --chassis seems to be easier to understand for me. I've 
commented on one of the patches that maybe we should deprecate the 
chassis-node-list if we add this, but then, the deprecation is slow, we have 
some functional tests already... Having two commands kind of reflects the 
duplication in our API, where we can do /chassis//nodes and 
/nodes?chassis_uuid=, so maybe having both of them is fine.

Vlad

On Mon, Aug 29, 2016 at 7:22 PM, Loo, Ruby 
> wrote:
Hi,

While working on the openstackclient plugin commands for ironic, I was thinking 
about the equivalents for 'ironic chassis-node-list' (nodes that are part of 
specified chassis) and 'ironic-node-port-list' (ports that are part of 
specified node). It didn't make sense to me to have an 'openstack baremetal 
chassis node list', since a 'chassis' and a 'node' are two different objects in 
osc lingo and we already have 'openstack baremetal chassis xx' and 'openstack 
baremetal node yy' commands. Furthermore, our REST API supports 'GET 
/v1/nodes?chassis=c1' and 'GET /v1/ports?node=n1'.

So I proposed 'openstack baremetal node list --chassis' and 'openstack 
baremetal port list --node' [1]. To implement this, I need to enhance our 
corresponding python APIs. The question I have is whether we want to only 
enhance the python API, or also provide 'ironic node-list --chassis' and 
'ironic port-list --node' commands. The latter is being proposed [2] and coded 
at [3]. Doing this would mean two different ironic CLIs to do the same thing, 
but also provide a more obvious 1:1 correspondence between ironic & osc 
commands, and between ironic CLI and python API.

Thoughts?

It'd be great if we could decide in the next day or so, in order to get the 
osc-related commands into the client this week for the Newton release.

--ruby

[1] 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/ironicclient-osc-plugin.html#openstack-baremetal-node
[2] https://launchpad.net/bugs/1616242
[3] https://review.openstack.org/#/c/359520/

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

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

Re: [openstack-dev] [Cinder] FFE request for RBD replication

[Sean McGinnis]

On Mon, Sep 12, 2016 at 10:24:23AM +0200, Michał Dulko wrote:
> +1, thanks for taking care of that!
> 
> On 09/12/2016 03:35 AM, Huang Zhiteng wrote:
> > +1 for this long-waited feature to land in Newton.
> >
> > On Sun, Sep 11, 2016 at 1:09 AM, Jay S. Bryant
> > >
> > wrote:
> >
> > +1 from me.  It is making good progress and is low risk.
> >
> > -Jay
> >
> >
> >
> > On 09/09/2016 02:32 PM, Gorka Eguileor wrote:
> >
> > Hi,
> >
> > As some of you may know, Jon Bernard (jbernard on IRC) has
> > been working
> > on the RBD v2.1 replication implementation [1] for a while,
> > and we would
> > like to request a Feature Freeze Exception for that work, as
> > we believe
> > it is a good candidate being a low risk change for the
> > integrity of
> > the existing functionality in the driver:
> >
> > - It's non intrusive if it's not enabled (enabled using
> >replication_device configuration option).
> > - It doesn't affect existing deployments (disabled by default).
> > - Changes are localized to the driver itself (rbd.py) and the
> > driver
> >unit tests file (test_rbd.py).

This looks fine to me. My only concern is the risk accepting it would
introduce, but as you point out that risk is low and should be well
contained. I think it should be fine to still get this in.


> >
> > Jon would have liked to make this request himself, but due to the
> > untimely arrival of his newborn baby this is not possible.
> >
> > For obvious reasons Jon will not be available for a little
> > while, but
> > this will not be a problem, as I am well acquainted with the
> > code -and
> > I'll be able to reach Jon if necessary- and will be taking
> > care of the
> > final steps of the review process of his patch: replying to
> > comments in
> > a timely fashion, making changes to the code as required, and
> > answering
> > pings on IRC regarding the patch.
> >
> > Since some people may be interested in testing this
> > functionality during
> > the reviewing process -or just for fun- I'll be publishing a
> > post with
> > detailed explanation on how to deploy and test this feature as
> > well as
> > an automated way to deploy 2 Ceph clusters -linked to be
> > mirroring one
> > another-, and one devstack node with everything ready to test the
> > functionality (configuration and keys for the Ceph clusters,
> > cinder
> > configuration, the latest upstream patch, and a volume type
> > with the
> > right configuration).
> >
> > Please, do not hesitate to ask if there are any questions to
> > or concerns
> > related to this request.
> >
> > Thank you for taking the time to evaluate this request.
> >
> > Cheers,
> > Gorka.
> >
> > [1]: https://review.openstack.org/333565
> > 
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> >
> >
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> >
> >
> >
> > -- 
> > Regards
> > Huang Zhiteng
> >
> >
> > __
> > OpenStack Development Mailing 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 

Re: [openstack-dev] [heat] resigning from heat-cores

[Sergey Kraynev]

Hi Pavlo,

It's really bad to hear such news. However as you said we all stay in
community and I believe, we will meet again! :)
See you in Barcelona, I hope ;)

On 12 September 2016 at 15:35, Pavlo Shchelokovskyy
 wrote:
> Hi Heaters,
>
> with great regret I announce my resignation from the heat-core team.
>
> About a year ago I was reassigned to another project, and despite my best
> efforts I came to conclusion that unfortunately I can not keep up with
> duties expected from Heat core team member in appropriate capacity.
>
> I do still work on OpenStack, so I'm not leaving the community altogether,
> and will be available in e.g. IRC. I also have some ideas left to implement
> in Heat, but, given the great community we've built around the project, I
> could surely make it as an ordinary contributor.
>
> It was an honor to be a member of this team, I’ve learned a lot during this
> time. Hope to see some of you in Barcelona :)
>
> Best regards,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.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
>



-- 
Regards,
Sergey.

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

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Mark Voelker]

> 
> On Sep 8, 2016, at 3:11 PM, Sean Dague  wrote:
> 
> On 09/08/2016 09:04 AM, Andrew Laski wrote:
>> 
>> 
>> On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote:
>>> On 09/07/2016 07:34 PM, Andrew Laski wrote:
 
 
 On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
> 3) core functionality should IMO require as few API calls as possible,
> to as few components as possible, while keeping REST data models etc.
> intact, [1][2]
 
 I agree that it should require as few API calls as possible but maybe we
 disagree about what core functionality is. Or to put it another way,
 what is core functionality depends on your perspective.
 
 I subscribe to the plumbing and porcelain approach
 (https://urldefense.proofpoint.com/v2/url?u=https-3A__git-2Dscm.com_book_en_v2_Git-2DInternals-2DPlumbing-2Dand-2DPorcelain=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=NWKhA-J2KIQGEiKTb4wFudlx1am5gBxyHPlNT1SsaLk=gPL9-f0Ias_WpPgP27BaMtNJszadrz57swhz6bBDoQY=
  )
 and believe that Nova should be part of the plumbing. So while I fully
 agree with a small number of API calls to do simple tasks I don't
 believe that orchestrating network setups is core functionality in Nova
 but is core to OpenStack.
>>> 
>>> Personally, I think that the role of Nova is to give you a functional
>>> compute unit. If you can't talk to that over the network, that doesn't
>>> seem very functional to me. For complicated setups it's fine that you
>>> need to do complicated things, but "I would like a working server with
>>> network" doesn't feel like it's a complicated ask from the user.
>> 
>> I'd really like to agree here, however it seems that it is actually a
>> somewhat complicated ask from the user due to the diverse network setups
>> used in practice.
>> 
>> But I was responding to the idea of booting an instance with a
>> floating-ip which to me goes beyond setting up a simple default network
>> for an instance. And I think therein lies the problem, there seems to be
>> some disagreement as to what a simple default network setup should be.
> 
> I agree that floating-ip auto allocation may be over that line, as
> floating ips are specifically constructs that are designed to not be
> tied to servers for the lifecycle of the server. Their value comes in
> having the floating ip last longer than the server.
> 
> But, there is also something here about wanting to make sure you have
> publicly accessable servers (which don't require floating ips specifically).
> 

/me chimes in late because still unearthing from a lot of work travel

Just to piggyback on a lot of what’s been said here, I completely agree that 
getting external connectivity to an instance is tricky today due to the variety 
of networking models in use.  That that’s both a strength (in that we have a 
rich enough platform to accommodate lots of different models to suit lots of 
different use cases) and a weakness (in that we end up having conversations 
like this and don’t have an interoperable way for users of multiple clouds to 
get external connectivity).  As a matter of fact, this very issue was recently 
mentioned to the Board as one of the top interoperability issues that the 
DefCore Committee sees in the wild today:

https://github.com/openstack/defcore/blob/master/doc/source/periodic_reports/fall_2016.rst#issue-3-external-network-connectivity

For what it’s worth, the DefCore Committee debated adding floating IP’s to the 
interoperability Guidelines that products have to follow in order to use the 
OpenStack name/trademark last fall, and ended up rejecting the idea—mostly for 
the reasons listed in this thread (e.g. there are a lot of other models and a 
lot of clouds don’t actually use floating IP’s so they actually aren’t 
interoperable, etc).

Also worth pointing out: the idea of having an administrative setting to 
auto-boot instances with a publicly accessible IP (whether that’s on a provider 
network or whether instances are auto-allocated a floating IP or whatever) is 
possibly less than ideal from an interoperability point of view, because end 
users tend to not have good ways of discovering administratively-set config 
settings.  At a minimum we'd want users to able to programmatically discover 
which position that knob was set to.

> There seems to be a space about sane default networking for users.
> Get-me-a-network worked through part of it. There might be a good follow
> on for some more standard models of "I really want internet accessible
> system". Neutron is not limited to granting this via floating ips like
> Nova Net was.

+1.  Get-me-a-network made it easier to get an instance booted up and attached 
to “a" network while alleviating part of the complexity (e.g. various 
underlying network models) of doing so.  What DefCore is seeing from an 
interoperability 

[openstack-dev] [kuryr] PTL Candidacy

[Antoni Segura Puimedon]

Hi Kuryrs!

First of all, I want to thank Gal for the hard work done in the past
two cycles as PTL for the project and to all of you who have
contributed in any and many ways, be it either in documentation, code,
bugs, design, discussion and usage.

I announce my candidacy to the Kuryr PTL position [1] with the goal of
bringing Kuryr to fulfill its mission of bringing OpenStack networking
and storage to the container world. The way in which I believe we
should do it is mainly by continuing to increase the community
participation in the day to day of the project evolution.

In order to take Kuryr to the next stage, the goals that I'd like us
to focus on are:

- Make it easier for people to develop Kuryr with kuryr-kubernetes devstack.
- Increased testing for kuryr-libnetwork and start to have end to end
testing for kuryr-kubernetes.
- Now that we implemented a core contribution specialization in four groups:
+ fuxi,
+ kuryr,
+ kuryr-libnetwokr,
+ kuryr-kubernetes.
We should get more people familiar enough with each project to be able
to promote them to core contributors.
- Increase the attention on bug tracking and release management.
- Reach Container-in-VM support.
- Participate more in upstream container orchestration engine communities.

I look forward to work with all of you to make Kuryr into the things
all of us want and need from it.

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

Antoni Segura Puimedon

__
OpenStack Development Mailing List (not for 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] [elections] Glance PTL non-candidacy

[Brian Rosmaita]

Nikhil,

Thank you for all your hard work as Glance PTL (3 times!).  Glad to hear
that you will be continuing to work in OpenStack, and especially that you
plan to continue working with Glance.

cheers,
brian

On 9/12/16, 2:08 AM, "Nikhil Komawar"  wrote:

>Hi team,
>
>
>Just wanted to share my decision for not running for PTL for Glance.
>It's been great serving the community in this role however, there are
>some personal and family matters that I need to attend to over the next
>couple of months or so.
>
>
>I think the Glance team has done great and we've quite a bunch of bright
>developers who are helping push the project forward in the appropriate
>direction. With Glare becoming separate project and Ocata being short
>cycle, I anticipate the priorities being rather obvious to those who
>have stayed in touch. I will be available to do the rightful handoff to
>the incoming PTL (for Ocata) and update with Newton happenings once
>we're done with a few important bugs that are being targeted for RC1.
>
>
>I intend to stick around in Glance and related projects like
>Searchlight, Glare, etc. However, I am planning to take a more hands on
>role and see a few features through in Ocata.  Given more and more
>glance-cores time sharing with other projects, I think we need some
>throttle in our review system. So, I'd like to help any new developers
>get their reviews up, that in turn will help the Glance community.
>
>
>Last but not the least, I have thoroughly enjoyed working in this role
>with all my fellow stackers, particularly glancers! So, a BIG thank you
>for having worked with me in making Glance better over the last couple
>of years.
>
>
>-- 
>
>Cheers,
>Nikhil
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [kuryr] Spec and devref placement

[Jaume Devesa]

+1 on b) too.

On 12 September 2016 at 13:38, Antoni Segura Puimedon 
wrote:

> Hi Kuryrs!
>
> On September 5th's weekly IRC meeting Irena Berezovsky suggested that
> we should take a decision regarding the location of specs and devrefs.
>
> Currently we default to putting all the specs and devrefs for:
> - Kuryr
> - Kuryr-libnetwork
> - Kuryr-kubernetes
>
> to openstack/kuryr. Fuxi is still being integrated and keeps its own doc.
>
> The three proposals that came up where:
> a) All specs and devrefs to openstack/kuryr
> b) Specs in openstack/kuryr but devrefs in each specific project,
> i.e., the one that will end up with the implementation code.
> c) Both specs and devrefs in each separate Kuryr project.
>
> I would like to advocate for option (b). It makes things easy for when
> specs involve multiple kuryr pieces and, at the same time, it keeps
> development information in the place where you'd expect, close to the
> code.
>
> Please, weigh on this issue here in the ML or in the weekly IRC
> meeting today. The idea is to reach a decision by next week's weekly
> IRC meeting and then write it in each subproject's "how to contribute"
>
> See you later in the weekly IRC,
>
> Toni
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Jaume Devesa
Software Engineer at Midokura
__
OpenStack Development Mailing 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

[Sean McGinnis]

Hello everyone, 

I would like to announce my candidacy to continue as Cinder PTL for the Ocata   
release.

The Cinder project has made great strides over the last several releases
adding functionality and improving stability. I think we have a very active 
team and love being part of such a strong community.

The Ocata cycle will be a much shorter one than in the past. One thing I would  
like to encourage for this release, as much as makes sense, is to focus on  
being mostly a bug fix and stabilization cycle. One side effect of all of the   
great new work going in recently is there has been a lot of new code introduced 
and changes made. There have been fundamental changes in how some things
operate with the the change from rootwrap to privsep. I would like to take  
advantage of this shorter concentrated cycle to delay some things in order to   
make sure we have a solid foundation to build on.   

Not to say there are any major issues with the project, or that there isn't 
new work that we do want to get in to Cinder. We have an incredible team that   
has been able to introduce some pretty significant code with little to no   
impact on the rest of the system. Folks have done a great job manually testing  
as well as adding unit and other automated testing to ensure high quality. But  
even with code that has been in there untouched for years we still find certain 
conditions that bring out issues. It would be great to find some of these now   
before we build too much more on top.   

Between the Summit and holidays for most over this cycle, Ocata will really be  
a short one. But I look forward to seeing how much this team can do, even in
this quick cycle. This could be a lot of fun!   

Thank you for your consideration!   

Sean

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

Re: [openstack-dev] [kuryr] Spec and devref placement

[Irena Berezovsky]

I am fine with option (b) as well.
We can add option (d):
Specs in openstack/*kuryr-specs* but devrefs in each specific project,
i.e., the one that will end up with the implementation code.


On Mon, Sep 12, 2016 at 2:38 PM, Antoni Segura Puimedon 
wrote:

> Hi Kuryrs!
>
> On September 5th's weekly IRC meeting Irena Berezovsky suggested that
> we should take a decision regarding the location of specs and devrefs.
>
> Currently we default to putting all the specs and devrefs for:
> - Kuryr
> - Kuryr-libnetwork
> - Kuryr-kubernetes
>
> to openstack/kuryr. Fuxi is still being integrated and keeps its own doc.
>
> The three proposals that came up where:
> a) All specs and devrefs to openstack/kuryr
> b) Specs in openstack/kuryr but devrefs in each specific project,
> i.e., the one that will end up with the implementation code.
> c) Both specs and devrefs in each separate Kuryr project.
>
> I would like to advocate for option (b). It makes things easy for when
> specs involve multiple kuryr pieces and, at the same time, it keeps
> development information in the place where you'd expect, close to the
> code.
>
> Please, weigh on this issue here in the ML or in the weekly IRC
> meeting today. The idea is to reach a decision by next week's weekly
> IRC meeting and then write it in each subproject's "how to contribute"
>
> See you later in the weekly IRC,
>
> Toni
>
> __
> OpenStack Development Mailing 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] [Congress] PTL non-candidacy

[Tim Hinrichs]

Hi all,

I've decided it's time to step down as PTL of Congress.  Partly because I
have so many outside responsibilities, and partly because we have such a
strong team, the time is right for someone else to lead the project.  We've
made so much progress over the past couple of years, and there's so much
left to do.  I'm truly excited to see someone's ideas for setting direction
and interacting with the community.  Should be a ton of fun!

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

[openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Steven Dake (stdake)]

To the OpenStack Community,

Consider this email my self non-nomination for PTL of Kolla for
the coming Ocata release.  I let the team know in our IRC team meeting
several months ago I was passing the on baton at the conclusion of Newton,
but I thought the broader OpenStack community would appreciate the information.

I am super proud of what our tiny struggling community produced starting
3 years ago with only 3 people to the strongly emergent system that is Kolla
with over 467 total contributors [1] since inception and closing in on 5,000
commits today.

In my opinion, the Kolla community is well on its way to conquering the last
great challenge OpenStack faces: Making operational deployment management (ODM)
of OpenStack cloud platforms straight-forward, easy, and most importantly
cost effective for the long term management of OpenStack.

The original objective the Kolla community set out to accomplish, deploying
OpenStack in containers at 100 node scale has been achieved as proven by this
review [2].  In these 12 scenarios, we were able to deploy with 3
controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
storage and run rally as well as tempest against the deployment.

Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.

I have developed a strong leadership pipeline and expect several candidates
to self-nominate.  I wish all of them the best in the future PTL elections.

Finally, I would like to thank all of the folks that have supported Kolla’s
objectives.  If I listed the folks individually this email would be far too
long, but you know who you are ☺ Thank you for placing trust in my judgement.

It has been a pleasure to serve as your leader.

Regards
-steak

[1] http://stackalytics.com/report/contribution/kolla-group/2000
[2] https://review.openstack.org/#/c/352101/

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

[Samuel de Medeiros Queiroz]

Hello, everyone!

First of all, I would like to thanks all the previous Keystone PTLs,
core reviewers and contributors who have made OpenStack and Keystone
what they are today. It is been a pleasure for me to work in this team
and learn with you all. I would be honored to be your PTL during the
next development cycle.

That said, I would like to put my name forward as a candidate for PTL
during the Ocata release [1].

I have been involved in OpenStack since the Icehouse release and I have
been a core reviewer on Keystone since the Mitaka release. During the
Newton cycle, I also served as the Keystone cross-project liaison and
participated as a mentor for the Outreachy program.

My main focuses have been helping new developers to contribute to the
project and improving documentation. I have been doing my best to review
elected priorities, helping the team to deliver what was scoped to the
release cycle.

Given that the Ocata development window is shorter, my main goal for
Ocata is to focus on the stability and usability of the project. My
primary subgoals include a) tackling the issue with long-running
operations and token expiry, b) keeping up the good work on improving
api-ref docs and creating the api-guide docs, and c) ensuring Keystone
is a friendly place for new contributors to get started. Other subgoals
that are nice to have but still important are d) broadening our tests
environments to include functional tests for LDAP backends, auditing,
and federated identity workflows, and e) making the default RBAC
authorization more granular.

Thank you,
Samuel de Medeiros Queiroz

[1] https://review.openstack.org/#/c/369002/
__
OpenStack Development Mailing 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

[Brian Rosmaita]

I've just put up https://review.openstack.org/#/c/368995/, declaring my
candidacy for Glance PTL.

Here's the content of that patch for your convenience:


Hello everyone,

I would like to announce my candidacy for the role of PTL of Glance for
the Ocata cycle.

Current State of Glance
---

This is a good time to be PTL of Glance.  The project has recently
served as the incubator for a successful project (Searchlight) and a
hopefully soon-to-be successful project (Glare), and at this point we
can focus on being Glance [0].  In Newton, the Images v1 API is being
deprecated [1] and Nova will be using the v2 API by default [2], which
allows us to focus even further.

Glance has some important efforts in progress that need to be seen
through to completion, so given the short upcoming cycle, I anticipate
quick agreement in determining our Ocata priorities.  In short, I see
myself as a "continuity" candidate, building on the good work done by
Flavio and Nikhil in the previous cycles.

Glance Priorities
-

This is how I see things shaping up for Ocata.

1. Image Import

The Glance image import refactoring proposal [3] has been discussed
thoroughly through two cycles by all OpenStack groups and individuals
interested in a discoverable, interoperable means of getting end-user
created images into OpenStack clouds of various types (public/private,
large/small).  There are some patches up, and Nikhil has indicated
that image import is a priority for post RC-1 time; I want us to
continue that work and deliver image import in Ocata.

2. Community Images

Implementation of the Community Images spec [4], approved for Newton,
has been delayed, in large part due to reviewer bandwidth issues (which
I'll address below).  It's a much-requested feature, has several
patches up, and is a priority to deliver early in Ocata.

3. Rolling Upgrades

The OpenStack Innovation Center has been promoting various operator
friendly enhancements to OpenStack, one of which is zero-downtime
control plane upgrades.  Several Glance developers associated with OSIC
have been working out a strategy (and some alternatives) to make this
happen in Glance [5,6].  I expect we'll be able to converge on a
strategy during (or shortly after) the Barcelona Summit with the goal
of having a zero-downtime Newton-to-Ocata upgrade available in Ocata.

(These three items are high-impact for operators and end users, so are
appropriately our top three Ocata priorities.  I have serious concerns
about Glance being able to deliver more than this in Ocata, so please
notice the caveats attached to the following items.)

4. Community Priorities

The TC recently adopted "community goals" for each cycle [7], and as a
good community citizen, the Glance project will want to adopt these as
priorities for Ocata.  The goal "remove copies of incubated Oslo code"
[8] primarily affects the python-glanceclient.  The goal "support
python 3.5" [9] is still under discussion in the wider community, with
some projects reporting that it will be a stretch to implement in
Ocata.  It will also be a stretch for Glance given our resource
constraints.  (I think the major impact for Glance will be in getting
the functional tests to pass under Python 3.5, but I haven't done a
complete analysis of this.)

5. Other

As noted earlier, this is a short cycle. The above is quite a list,
though that's mitigated a bit by some of the items already being in
progress.  There are some other candidates for Glance priorities that
we can discuss carefully at the Summit [10], in particular, the Glance
Store Refactor and Hierarchical Image Access.  Personally, I would like
to see us at least (a) come to a consensus on, and (b) articulate
clearly the envisioned usage of the glance_store library during the
Summit as that will be helpful in guiding the refactoring of its API
and guide its future development (whether or not that development
happens in Ocata).  Hierarchical Image Access would complete the Glance
image sharing use cases, and shouldn't be too bad to implement given
the changes made for the Community Images implementation, but we need
to make a realistic assessment of this at the Summit.

Finally, the glance-specs repo contains some approved but not
implemented specs and lite-specs.  These are useful items (or they
wouldn't have been approved in the first place!).  They will also have
to be the subject of a realistic assessment during the Summit.

Glance Community


I said earlier that this is a good time to be Glance PTL; it's also a
good time to join the Glance community, particularly for ambitious
developers who would like to achieve core status on one of the major
OpenStack projects.  We need more reviewers as, right now, most of the
core reviewers for Glance have additional commitments.

Although we need more reviewers, I don't want to "clean house" because
our core reviewers represent a cross-section of the community and bring
a lot of expertise 

Re: [openstack-dev] [glance] Bug days next week

[Nikhil Komawar]

Just a gentle reminder, the bug days start Tuesday September 13th.

https://etherpad.openstack.org/p/newton-glance-sept-bug-days


P.S. In some parts of the world, this day has already started.


On 9/7/16 3:54 PM, Nikhil Komawar wrote:
> Hi all,
>
>
> I would like to propose bug days for Glance next week Tuesday 13th
> September and Wednesday 14th September (during your work hours / in your
> time zone).
>
>
> We've a plenty of bugs to address [1, 2, 3] and looks like the the right
> time in the cycle when we would get a good benefit of these bug days. I
> would encourage people to focus on Glance server bugs rather than client
> and store bugs during these days. Nevertheless, you are free to choose
> what best suits your needs.
>
>
> RC1 is supposed to be targeted on Thursday Sept 15th and it would be a
> good time to triage some critical bugs for the same.
>
>
> Additionally, this is an excellent opportunity to all those who are
> looking to get involved, become a glance-core or just make some more
> contributions to Glance.
>
>
> If you happen to fix an important bug and think that we need to include
> it as a part of a Glance RC release, please drop me a note on IRC and
> wait for my update. Either I will propose a topic change to
> "newton-rc-potential" indicating that it has been considered strongly to
> be a part of the release or I may leave a comment indicating why we
> haven't considered so. Please do NOT make the topic to
> "newton-rc-potential" yourself as it will be used while coordinating the
> release work and unexpected reviews under that topic will delay or
> disrupt the release process.
>
>
> If you do not have time to propose a review and have found a bug that
> could be a good candidate for Newton RC, then please "tag" that bug in
> launchpad to have the tag named "newton-rc-potential" (this tag has been
> added to official tags list). The bug team or the Glance core team will
> then consider proposing fixes for these bugs.
>
>
> We will use etherpad to collaboratively add notes and updates for this
> event here [4]. Please see my official entry for this event at [5].
>
>
> As always, feel free to reach out for questions and comments.
>
>
> [1] https://bugs.launchpad.net/glance/
>
> [2] https://bugs.launchpad.net/glance-store
>
> [3] https://bugs.launchpad.net/python-glanceclient/
>
> [4] https://etherpad.openstack.org/p/newton-glance-sept-bug-days
>
> [5] https://review.openstack.org/366923
>
>

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [packaging-deb][PTL] candidacy

[Jeremy Stanley]

On 2016-09-12 21:10:04 +0200 (+0200), Thomas Goirand wrote:
[...]
> P.S: It maybe will be a bit hard to find out who can vote, because only
> the debian/newton branch should count, and currently Stackalytics is
> counting the master which contains upstream commits. Hopefully, we can
> solve the issue before the elections.

We don't rely on Stackalytics for generating electoral rolls. We
query Gerrit for owners of changes merged during the validity period
to any repos for covered deliverables listed in governance,
irrespective of the branches to which those changes merge (sole
exception being election for Stable Branch Maintenance PTL, where we
count changes merged to stable/.* branches of all official projects).
-- 
Jeremy Stanley

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

[openstack-dev] [packaging-deb][PTL] candidacy

[Thomas Goirand]

I am writing to submit my candidacy for re-election as the PTL for the
packaging-deb project.

The idea sparked in Vancouver (spring 2015). The project joined the
big-tent about a year ago (in August 2015, it was approved by the TC)
But it then took about a year to have it bootstraped. This was long and
painful bootstrap, but today, I can proudly announce that it was finally
well launched. Right now, all of Oslo and python-*client are built, and
it is a mater of days until all services of Newton is completely built
in OpenStack infra (Keystone is already there in Newton b2 version).

I'll do my best to continue to drive the project, and hope to gather
more contribution every day. Every contributor counts.

Cheers,

Thomas Goirand (zigo)

P.S: It maybe will be a bit hard to find out who can vote, because only
the debian/newton branch should count, and currently Stackalytics is
counting the master which contains upstream commits. Hopefully, we can
solve the issue before the elections.

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

Re: [openstack-dev] [ironic] openstack/python-ironicclient

[Dean Troyer]

On Mon, Sep 12, 2016 at 10:51 AM, Ruby Loo  wrote:

> My preference is:
>
> * openstack baremetal driver show --raid-logical-disk-properties
>

Agreed here.

The process we encourage is always to first identify the resource you are
operating on.  I would add that a 'property' is not a resource, it
describes a resource, there may be many of them per resource, etc.  Here,
the resource is 'baremetal driver'.

because we already have 'openstack baremetal driver show' as a command, and
> other than wanting to see a description of the logical disk properties, the
> only other command related to the disk properties is 'openstack baremetal
> node set --target-raid-config'.
>

Possible confusion on my part... the properties you want to display as part
of 'baremetal driver show' are set with 'baremetal node set'?  That
assymetry may be part of the reason this was ambiguous to start with.


> The problem, though, is that this only shows the disk properties, nothing
> else about the driver. The information is different, so that trying to use
> this command to show the driver information AND the disk property
> descriptions, doesn't make sense either.
>
>
> If we thought that we might have some 'openstack baremetal driver raid
> ' command in the future, then 'openstack baremetal driver
> raid logical disk properties show' might make more sense. (Now I'm leaning
> towards this one.)
>

To generalize a bit more, if the 'baremetal driver' has different kinds of
properties, or groups of properties that you want to distinguish, I would
suggest doing that with a common option name like you have above:
'--raid-logical-disk-property' and defining more of those as you need
them.  But use the same approach where you set the properties too, etc.

dt

-- 

Dean Troyer
dtro...@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] [all] governance proposal worth a visit: Write down OpenStack principles

[Doug Hellmann]

> On Sep 12, 2016, at 2:17 PM, Doug Hellmann  wrote:
> 
> Excerpts from Thierry Carrez's message of 2016-09-12 08:53:58 +0200:
>> Doug Hellmann wrote:
>>> Excerpts from Jay Pipes's message of 2016-09-09 14:30:29 -0400:
> To me, this statement
> about One OpenStack is about emphasizing those commonalities and
> working together to increase them, with the combined goals of
> improving the user and operator experience of using OpenStack and
> improving our own experience of making it.
 
 +1000 to the above, and I don't believe anything about my stance that 
 OpenStack should be a cloud toolkit goes against that.
 
 The wording/philosophy that I disagree with is the "one product" thing :)
>>> 
>>> Tomato, tomato.
>>> 
>>> We're all, I think, looking at this "One OpenStack" principle from
>>> different perspectives.  You say "a toolkit". I say "a project".
>>> Thierry said "a product". The important word in all of those phrases
>>> is "a" -- as in singular.
>> 
>> FWIW I agree with Jay that the wording "a product" is definitely
>> outdated and does not represent the current reality. "Product"
>> presupposes a level of integration that we never achieved, and which is,
>> in my opinion, not desirable at this stage. I think that saying "a
>> framework" would be more accurate today. Something like "OpenStack is
>> one community with one common mission, producing one framework of
>> collaborating components" would capture my thinking.
>> 
> 
> From the perspective of what we are delivering, I can go along with
> either "toolkit" or "framework." Do those terms capture the spirit
> of the original meaning, though, when considered from a governance
> perspective? Aren't we trying to say that we're a single community,
> too?

And of course re-reading I see you said “community” right there at the start.
I should probably not be doing code reviews today, either. ;-)

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] [glance] Periodically checking Glance image files

[Nikhil Komawar]

Hi Sergio,

Thanks for reaching out. And this is an excellent question.

Firstly, I'd like to mention that Glance is built-in (and if deployed
correctly) is self-resilient in ensuring that you do NOT need an audit
of such files. In fact, if any operator (particularly large scale
operator) needs such a system we have a serious issue where potentially
important /user/ data is likely to be lost resulting in legal issues (so
please beware).

Having said that, I'd like to start investigating more into your
particular issue and see where we may be missing out in ensuring data
integrity in Glance. Let me ask you a first few set of questions that
will help us get an initial understanding:-

1) Are you a public cloud vendor; in particular, have you deployed
glance to potentially non-trusted users? or is the case otherwise?
2) Are you deploying Glance v1 or Glance v2?
3) Have you exposed the "location" feature set (CRUD) to regular users?
(if using API v2, have you enabled ``show_multiple_locations``
configuration)
4) What backends have you configured Glance with and who has access to
them? What is the resiliency or rotation (of disks) (for say capacity
management) of your backend store system?
5) Sanity check on your issue:-
5.1) What are the image statues for which the image data files are missing?
5.2) What is the rate of error approximately (if you don't have
specifics, info like rare, medium, often will help)


We may have to dig a bit further into the issue but this set of info
should help us narrow down the issue and determine if there are any gaps
in Glance.

P.S. Please use the tag "[glance]" in the subject line to help us get to
your email faster.

On 9/12/16 12:48 PM, Sergio A. de Carvalho Jr. wrote:
> Hi all,
>
> Is there (or was there ever) any plans to implement in Glance a
> service that would periodically check that the image files are still
> available on the file system (or in whatever storage system being
> used) and have the correct checksum?
>
> We had a few issues where an image file was removed from the
> filesystem and that can go undetected for a long time until someone
> tries to access that image, so we were wondering if it would be
> possible (and if it would make sense) to implement some sort of
> background service to periodically check if all images found in the
> database can be retrieved successfully.
>
> Thoughts?
>
> Sergio
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Thanks,
Nikhil



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

[openstack-dev] Periodically checking Glance image files

[Sergio A. de Carvalho Jr.]

Hi all,

Is there (or was there ever) any plans to implement in Glance a service
that would periodically check that the image files are still available on
the file system (or in whatever storage system being used) and have the
correct checksum?

We had a few issues where an image file was removed from the filesystem and
that can go undetected for a long time until someone tries to access that
image, so we were wondering if it would be possible (and if it would make
sense) to implement some sort of background service to periodically check
if all images found in the database can be retrieved successfully.

Thoughts?

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

[openstack-dev] [new][horizon] XStatic-Bootstrap-SCSS 3.3.7.1 release

[no-reply]

We are chuffed to announce the release of:

XStatic-Bootstrap-SCSS 3.3.7.1: Bootstrap-SCSS 3.3.7 (XStatic
packaging standard)

With package available at:

https://pypi.python.org/pypi/XStatic-Bootstrap-SCSS

For more details, please see below.

Changes in XStatic-Bootstrap-SCSS 3.3.7.0..3.3.7.1
--

4ca4a05 Update with corrected xstatic-release


Diffstat (except docs and test files)
-

setup.cfg  |  2 +-
setup.py   | 24 
xstatic/pkg/bootstrap_scss/__init__.py |  2 +-
3 files changed, 18 insertions(+), 10 deletions(-)




__
OpenStack Development Mailing List (not for 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] weekly meeting #91

[Emilien Macchi]

Hi,

Tomorrow we'll have our weekly meeting:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160913
Feel free to add topics as usual,

Thanks!

On Thu, Sep 8, 2016 at 9:57 AM, Iury Gregory  wrote:
> No topic/discussion in our agenda, we cancelled the meeting, see you next
> week!
>
> 2016-09-05 15:39 GMT-03:00 Iury Gregory :
>>
>> Hi Puppeteers,
>>
>> If you have any topic to add for this week, please use the etherpad:
>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160906
>>
>> See you tomorrow =)
>>
>> 2016-08-30 12:02 GMT-03:00 Emilien Macchi :
>>>
>>> No topic this week, meeting cancelled!
>>>
>>> See you next week :)
>>>
>>> On Mon, Aug 29, 2016 at 1:45 PM, Emilien Macchi 
>>> wrote:
>>> > Hi,
>>> >
>>> > If you have any topic to add for this week, please use the etherpad:
>>> >
>>> > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160830
>>> >
>>> > See you tomorrow,
>>> >
>>> > On Tue, Aug 23, 2016 at 1:08 PM, Iury Gregory 
>>> > wrote:
>>> >> No topic/discussion in our agenda, we cancelled the meeting, see you
>>> >> next
>>> >> week!
>>> >>
>>> >>
>>> >>
>>> >> 2016-08-22 16:19 GMT-03:00 Iury Gregory :
>>> >>>
>>> >>> Hi Puppeteers!
>>> >>>
>>> >>> We'll have our weekly meeting tomorrow at 3pm UTC on
>>> >>> #openstack-meeting-4
>>> >>>
>>> >>> Here's a first agenda:
>>> >>>
>>> >>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160823
>>> >>>
>>> >>> Feel free to add topics, and any outstanding bug and patch.
>>> >>>
>>> >>> See you tomorrow!
>>> >>> Thanks,
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> ~
>>> >> Att[]'s
>>> >> Iury Gregory Melo Ferreira
>>> >> Master student in Computer Science at UFCG
>>> >> E-mail:  iurygreg...@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
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Emilien Macchi
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> ~
>> Att[]'s
>> Iury Gregory Melo Ferreira
>> Master student in Computer Science at UFCG
>> E-mail:  iurygreg...@gmail.com
>> ~
>
>
>
>
> --
>
> ~
> Att[]'s
> Iury Gregory Melo Ferreira
> Master student in Computer Science at UFCG
> E-mail:  iurygreg...@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
>



-- 
Emilien Macchi

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

[openstack-dev] Announcing RSC (Rack Scale Controller)

[Bhandaru, Malini K]

Hello Everyone!
Think disaggregated hardware assembled to meet workload needs, 
dynamically growing and shrinking your cloud, and more. 
https://wiki.openstack.org/wiki/Rsc
Do come and join us for our very first IRC meeting on Sept 13, UTC 3:00 hrs.
Please forward to others you think may be interested.
Regards,
Malini

__
OpenStack Development Mailing List (not for 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] governance proposal worth a visit: Write down OpenStack principles

[Ed Leafe]

On Sep 12, 2016, at 1:53 AM, Thierry Carrez  wrote:

> FWIW I agree with Jay that the wording "a product" is definitely
> outdated and does not represent the current reality. "Product"
> presupposes a level of integration that we never achieved, and which is,
> in my opinion, not desirable at this stage.

Though the two terms looks and sound somewhat similar, “project” and “product” 
could not be more dissimilar.

https://www.linux.com/blog/why-your-open-source-project-not-product


-- Ed Leafe






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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

[Clay Gerrard]

On Sun, Sep 11, 2016 at 11:53 PM, Thierry Carrez 
wrote:
>
> FWIW I agree with Jay that the wording "a product" is definitely
> outdated and does not represent the current reality. "Product"
> presupposes a level of integration that we never achieved, and which is,
> in my opinion, not desirable at this stage. I think that saying "a
> framework" would be more accurate today. Something like "OpenStack is
> one community with one common mission, producing one framework of
> collaborating components" would capture my thinking.
>


This is why I always have and presumably always will support Thierry on the
TC.  His initial thinking *frequently* seems out of alignment with me, but
after observing others healthy debate and discussion [1] - I always find we
tend we both come around a little and seem to be pointing in basically the
same direction in the end.  Thierry is *reasonable*.  Throwing out old
assumptions when new information is raised is an absolute imperative - and
here we see Thierry plainly and openly offering concession to a reasonable
counterpoint.

It's unfortunate just how often we have to see Thierry do this on behalf of
some other members on the TC!  In fact, sometimes I'm scared to imagine
just how much worse off OpenStack governance might be if it wasn't for the
small handful of reasonable individuals willing to subject themselves to
the pain of the political grind.

PTL announcements are coming out and TC announcements are coming up soon!

http://governance.openstack.org/

Let's make sure we get some more *reasonable* people in there to help out
Thierry!  Thank you Thierry for your service!

-Clay

1. Like many other OpenStack contributors - I try not to personally get
involved in these non-technical debates.  It's a huge distraction from the
mission; and for me personally I recognize I'm too passionate and
ineloquent to make any meaningful direct contribution anyway.  But I care
about the OpenStack mission; and I feel compelled as of late to do my part
to ensure reasonable people are focusing on the right things in OpenStack
governance.  OpenStack for Operators!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Bug smash day: Wed, Sep 14

[Dmitry Tantsur]

Hi all!

On Wednesday, Sep 14, 2016 we will try to clean up our bug list, triage, 
separate RFEs from real bugs, etc. Then we'll find out which bugs must 
be fixed for Newton, and, well, fix them :)


We are starting as soon as the first person joins and stop as soon as 
the last person drops. We will coordinate our efforts on the 
#openstack-ironic channel on Freenode. Please feel free to join at your 
convenience.


See you there!

__
OpenStack Development Mailing List (not for 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] governance proposal worth a visit: Write down OpenStack principles

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-09-12 08:53:58 +0200:
> Doug Hellmann wrote:
> > Excerpts from Jay Pipes's message of 2016-09-09 14:30:29 -0400:
> >>  > To me, this statement
> >>> about One OpenStack is about emphasizing those commonalities and
> >>> working together to increase them, with the combined goals of
> >>> improving the user and operator experience of using OpenStack and
> >>> improving our own experience of making it.
> >>
> >> +1000 to the above, and I don't believe anything about my stance that 
> >> OpenStack should be a cloud toolkit goes against that.
> >>
> >> The wording/philosophy that I disagree with is the "one product" thing :)
> > 
> > Tomato, tomato.
> > 
> > We're all, I think, looking at this "One OpenStack" principle from
> > different perspectives.  You say "a toolkit". I say "a project".
> > Thierry said "a product". The important word in all of those phrases
> > is "a" -- as in singular.
> 
> FWIW I agree with Jay that the wording "a product" is definitely
> outdated and does not represent the current reality. "Product"
> presupposes a level of integration that we never achieved, and which is,
> in my opinion, not desirable at this stage. I think that saying "a
> framework" would be more accurate today. Something like "OpenStack is
> one community with one common mission, producing one framework of
> collaborating components" would capture my thinking.
> 

>From the perspective of what we are delivering, I can go along with
either "toolkit" or "framework." Do those terms capture the spirit
of the original meaning, though, when considered from a governance
perspective? Aren't we trying to say that we're a single community,
too?

Doug

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

[openstack-dev] [ironic] weekly subteam report

[Loo, Ruby]

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 29 Aug 2016 and 12 Sep 2016)
- Ironic: 255 bugs (+21) + 213 wishlist items (-1). 41 new (+8), 181 in 
progress (+11), 0 critical, 35 high (+1) and 16 incomplete (-1)
- Inspector: 11 bugs (+1) + 20 wishlist items. 1 new, 12 in progress (+3), 0 
critical, 2 high (+1) and 1 incomplete (-1)
- Nova bugs with Ironic tag: 9 (-1). 0 new, 0 critical, 0 high

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- Infra has asked us to fix the list of jobs we're generating. dtantsur is 
handling it
- Infra also wants us to move to Xenial from Newton on

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- will get back to it in Ocata (which is soon!)

OpenStackClient plugin for ironic (dtantsur, rloo)
==
* trello: https://trello.com/c/ckqtq3kG/16-openstackclient-plugin-for-ironic
- "done". The OSC commands are 98 (+-1.999%) complete and in 
python-ironicclient 1.7.0
- update to spec to reflect reality: https://review.openstack.org/#/c/363921/
- bugs/rfes have been opened for remaining commands (that rloo is aware of)
- will remove this subteam item after today's meeting

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- we should try to merge them this week IMO

Keystone policy support (JayF, devananda)
=
* trello: https://trello.com/c/P5q3Es2z/15-keystone-policy-support
- the only remaining bit is the preventative unit test that would prevent 
future API changes from landing without a policy check

Active node creation (TheJulia)
===
* trello: https://trello.com/c/BwA91osf/22-active-node-creation
- New revision of the tempest tests should be expected later today.

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- Nova patch: in review(unfortunately, removing -2 by Matt was mistake??)
- Ironic patches: merged

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- It's been postponed to Ocata, but the base patches for ironic-lib is already 
merged
- A -2 patch waiting for Ocata to open is already proposed: 
https://review.openstack.org/#/c/366742/

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- our grenade job has been down due to a failure in network_basic_ops test
- we had to hack on our test runner to disable this test until we find a 
sane way to fix it
- otherwise we're ready for the release

Install guide migration (JayF and mat128)
=
- Plan and progress: 
https://etherpad.openstack.org/p/ironic-install-guide-migration-plan
- Initial docs published: 
http://docs.openstack.org/project-install-guide/baremetal/draft/ yay!
- 2 reviews in-flight for importing existing content
- https://review.openstack.org/#/q/topic:bug/1612278

Cross-project:
==
- Infra insists on switching new jobs to Xenial

Drivers:

OneView (gabriel-bezerra/thiagop/xavierr)
-
- Inband inspection
- RFE: https://bugs.launchpad.net/ironic/+bug/1621530
- Code: https://review.openstack.org/367065
- CI server is down -- we're working on fixing it (2016-09-09)

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard


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

[openstack-dev] [nova] Community generated roadmap responses (newton)

[Matt Riedemann]

I wanted to share my responses to a set of questions from the Product 
Working Group who is working with the OpenStack Foundation to collect 
updated information on the Newton release for each project (along with 
directional guidance on future release plans).


This is a follow up at the end of the release based on an interview I 
gave toward the beginning (shortly after the Austin summit):


https://www.youtube.com/watch?v=EHCj1DZNNWw

The first one is hard to answer based on our list of priorities:

https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html

The immediate user POV features from that list in Newton that we 
completed were API policy defaults in code, glance v2 integration and 
Get Me a Network. However, more work went into cells v2 and scheduler 
(placement API) changes, but the cells v2 and placement API features are 
still optional in Newton, and are really operational features. So it's a 
hard one to answer but I just left what was in the initial interview 
responses.


For the Themes section I gave a lot of info, maybe more than they wanted 
for marketing slides, but the Nova team got quite a bit done in Newton 
and I'm not including everything, but it'd be remiss of me to not 
include a lot of these.


As for Ocata and Pike, we don't determine the priorities for those until 
the summit, so they are just educated guesses at this point.


Note: these are already submitted. I'm posting here for informational 
purposes to let people know that sausage is being made.


Questions:

1. What are the top 3 or 4 features that your team is delivering as part 
of the Newton release?

- Limited cells v2 support
- Placement API (tracking quantitative resources)
- API policy defaults in code
- api-ref docs cleanup

2. Areas of focus/ themes you will target (please give an example of how 
your team will execute on these themes in the Newton release)


Theme 1: Scalability [Changes that will impact the scale at which the 
service can operate]

- Cells v2
- Placement API

Theme 2: Resiliency [Changes that will improve the availability of or 
ability to recover from failures for the service]

- Ironic multiple compute host support for HA

Theme 3: Manageability [Changes that promote operational ease-of-use or 
benefits operators in general]

- API policy defaults in code
- Added support for libvirt live migration post-copy mode
- New vendor data API: 
http://docs.openstack.org/develope//nova/vendordata.html#deployer-provided-data

- Mutable debug logging configuration.
- nova-manage command to synchronize quota usage
- Improved configuration option documentation
- A subset of notifications are now versioned

Theme 4: Modularity [Changes that help the service architecture divide 
into more manageable/smaller services/code-base]
- os-vif library integration for LinuxBridge and OVS on libvirt 
computes

- Castellan library integration for key management

Theme 5: Interoperability [Changes that help enable the service to 
operate across multiple OpenStack clouds [federation] or promote a 
common experience when the service is deployed in separate 
OpenStack-Powered clouds [interop]]
- Proxy resource APIs are deprecated in the v2.36 microversion: 
http://docs.openstack.org/developer/nova/api_microversion_history.html#id33

- Glance v2 integration
- Removed support for API extensions

Theme 6: User Experience [Changes that benefit end-users of your service 
-- not the operators but the people consuming the service]

- api-ref docs cleanup: http://developer.openstack.org/api-ref/compute/
- Server tag support - v2.26 microversion: 
http://docs.openstack.org/developer/nova/api_microversion_history.html#id23
- Virtual device tagging - v2.32 microversion: 
http://docs.openstack.org/developer/nova/api_microversion_history.html#id29
- Get Me a Network (auto-allocated networking topology) - v2.37 
microversion: 
http://docs.openstack.org/developer/nova/api_microversion_history.html#id34


Theme 7: Security [Changes that improve security ]
- oslo.privsep integration for os-vif and os-brick libraries
- Multi-tenant networking support for Ironic computes

3. What are the top 3 new features planned for development in the [Ocata 
release]?


New features/ enhancements
- Multi-v2 cell deployment support
- Placement API used for scheduling decisions
- libvirt storage pools
- API discoverability - What can this cloud do? What am I allowed 
to do on this cloud?


Areas of focus/ themes you will target
- Scalability, manageability, interoperability and security

4. What do you project will be areas of focus in [Pike release]?  What 
does your crystal ball show you?


New features/ enhancements
- Model resource provider capabilities and use them for scheduling
- Improved API workflows between Nova/Cinder and Nova/Neutron

Areas of focus/ themes you will target
- 

[openstack-dev] [chef] Chef PTL candidacy

[Samuel Cassiba]

Hello everyone,

I would like to announce my candidacy to continue as OpenStack Chef
PTL for the Ocata release.[0]

= State of the Kitchen =

Over the Newton cycle, we said good bye to some contributors, and
hello to others. It slowed our overall output, but Stackalytics shows
that we still get through about 2 reviews per day. Not impressive
numbers, I know, but like LA traffic, as long as it doesn't come to a
stop, it's a good thing. Though we're down to just two cores, we're
still iterating, and have even gained some new contributors in the
process.

In Newton, we had some pretty big deliverables:

- Ubuntu 16.04
- python-openstackclient
- Identity v3
- newer ChefDKs (0.17.17 at the time of this writing)
- client cookbook based on fog-openstack
- refactor the telemetry cookbook to introduce Gnocchi
- as always, better integration

As of today, several of those things are still in implementation and
review. We're slowly gaining momentum again with the close of the
Newton cycle upon us. With the Ocata cycle being shorter, we have even
less time to get things in shape, but we'll get there.

= The Future =

My goals for the Ocata cycle are to:
- continue getting integration to an unbroken state so that it can be
relied upon for upstream and downstream build health
- furthering the documentation efforts that took place during Mitaka
- get more people familiar with the project to the point where we can
promote some of them to core

As far as process goes, I don't anticipate any big sweeping process
changes for the project over the next cycle. The processes that we
have agreed to seem to be working thus far.

With the Ocata cycle, I want to focus more on engaging new developers
and understanding their obstacles, to ensure that people can get
started deploying OpenStack and hacking on cookbooks.

I look forward to continuing to steer the OpenStack Chef cookbooks as
well as collaborating with other projects within the greater OpenStack
project.

Yours,

Samuel Cassiba

[0] https://review.openstack.org/369027

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

Re: [openstack-dev] [Keystone] Why not OAuth 2.0 provider?

[Steve Martinelli]

>
> Would you please shed some light on how to configure Keystone for OAuth1?
> Thank you very much.
>

There is some documentation in the API but nothing formally written out:
http://developer.openstack.org/api-ref/identity/v3-ext/index.html


>
> I am trying to develop OAuth 2 client for Keystone. We will contribute our
> OAuth 2 client source code to the community if we can use Google/Facebook
> to log in to OpenStack through OAuth 2 client.
>
>
Currently you can setup keystone to work with Google / Facebook and other
social logins. If you've setup keystone to use Shibboleth (which you did, I
snipped that part of the message), then you can set it up to use these
social logins as well. See documentation here:
http://docs.openstack.org/developer/keystone/federation/federated_identity.html#id4


> Thanks.
>
> Best regards,
>
> Winston Hong
> Ottawa, Ontario
> Canada
>
>
> Steve Martinelli  Jun 27, 2016, 10:57 PM
>
> > So, the os-oauth routes you mention in the documentation do not make
> > keystone a proper oauth provider. We simply perform delegation (one user
> > handing some level of permission on a project to another entity) with
> the
> > standard flow established in the oauth1.0b specification.
> >
> > Historically we chose oauth1.0 because one of the implementers was very
> > much against a flow based on oauth2.0 (though the names are similar,
> these
> > can be treated as two very different beasts, you can read about it here
> > [1]). Even amongst popular service providers the choice is split down
> the
> > middle, some providing support for both [2]
> >
> > We haven't bothered to implement support for oauth2.0 since there has
> been
> > no feedback or desire from operators to do so. Mostly, we don't want
> > yet-another-delegation mechanism in keystone, we have trusts and
> oauth1.0;
> > should an enticing use case arise to include another, then we can
> revisit
> > the discussion.
> >
> > [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
> > [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
>
> __
> OpenStack Development Mailing 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] Periodically checking Glance image files

[Sergio A. de Carvalho Jr.]

Hi Nikhil,

Thanks so much for you response.

1) No, this is a private cloud.
2) Glance v1 (this problem has manifested itself in one of our oldest
deployments, which is running Icehouse).
3) No, location is not exposed.
4) Glance is setup with the filesystem backend drive, using a Gluster
volume mounted on the host..
5.1) Images were in active state, even though the image file had zero bytes.
5.2) very low, it may have happened only twice in the last year.

Even if the location is not exposed, there are a number of things that can
happen to the actual images files after they've been uploaded to Glance,
without Glance noticing, depending how reliable your storage backend is.
That's why I thought, in some circumstances, it would be useful to have
some sort of background service checking that image files haven't been
corrupted or gone missing altogether.

Sergio


On Mon, Sep 12, 2016 at 7:27 PM, Nikhil Komawar 
wrote:

>
> Hi Sergio,
>
> Thanks for reaching out. And this is an excellent question.
>
> Firstly, I'd like to mention that Glance is built-in (and if deployed
> correctly) is self-resilient in ensuring that you do NOT need an audit
> of such files. In fact, if any operator (particularly large scale
> operator) needs such a system we have a serious issue where potentially
> important /user/ data is likely to be lost resulting in legal issues (so
> please beware).
>
> Having said that, I'd like to start investigating more into your
> particular issue and see where we may be missing out in ensuring data
> integrity in Glance. Let me ask you a first few set of questions that
> will help us get an initial understanding:-
>
> 1) Are you a public cloud vendor; in particular, have you deployed
> glance to potentially non-trusted users? or is the case otherwise?
> 2) Are you deploying Glance v1 or Glance v2?
> 3) Have you exposed the "location" feature set (CRUD) to regular users?
> (if using API v2, have you enabled ``show_multiple_locations``
> configuration)
> 4) What backends have you configured Glance with and who has access to
> them? What is the resiliency or rotation (of disks) (for say capacity
> management) of your backend store system?
> 5) Sanity check on your issue:-
> 5.1) What are the image statues for which the image data files are missing?
> 5.2) What is the rate of error approximately (if you don't have
> specifics, info like rare, medium, often will help)
>
>
> We may have to dig a bit further into the issue but this set of info
> should help us narrow down the issue and determine if there are any gaps
> in Glance.
>
> P.S. Please use the tag "[glance]" in the subject line to help us get to
> your email faster.
>
> On 9/12/16 12:48 PM, Sergio A. de Carvalho Jr. wrote:
> > Hi all,
> >
> > Is there (or was there ever) any plans to implement in Glance a
> > service that would periodically check that the image files are still
> > available on the file system (or in whatever storage system being
> > used) and have the correct checksum?
> >
> > We had a few issues where an image file was removed from the
> > filesystem and that can go undetected for a long time until someone
> > tries to access that image, so we were wondering if it would be
> > possible (and if it would make sense) to implement some sort of
> > background service to periodically check if all images found in the
> > database can be retrieved successfully.
> >
> > Thoughts?
> >
> > Sergio
> >
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
>
> Thanks,
> Nikhil
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] FFE request for RBD replication

[Gorka Eguileor Gimeno]

Thanks everyone for the quick and positive responses.

I'm on PTO this week with limited internet access, so my replies may have
some delays. Next week it will go back to normal.  :-)

Cheers,
Gorka.

On Mon, Sep 12, 2016 at 3:04 PM, Sean McGinnis 
wrote:

> On Mon, Sep 12, 2016 at 10:24:23AM +0200, Michał Dulko wrote:
> > +1, thanks for taking care of that!
> >
> > On 09/12/2016 03:35 AM, Huang Zhiteng wrote:
> > > +1 for this long-waited feature to land in Newton.
> > >
> > > On Sun, Sep 11, 2016 at 1:09 AM, Jay S. Bryant
> > > >
> > > wrote:
> > >
> > > +1 from me.  It is making good progress and is low risk.
> > >
> > > -Jay
> > >
> > >
> > >
> > > On 09/09/2016 02:32 PM, Gorka Eguileor wrote:
> > >
> > > Hi,
> > >
> > > As some of you may know, Jon Bernard (jbernard on IRC) has
> > > been working
> > > on the RBD v2.1 replication implementation [1] for a while,
> > > and we would
> > > like to request a Feature Freeze Exception for that work, as
> > > we believe
> > > it is a good candidate being a low risk change for the
> > > integrity of
> > > the existing functionality in the driver:
> > >
> > > - It's non intrusive if it's not enabled (enabled using
> > >replication_device configuration option).
> > > - It doesn't affect existing deployments (disabled by default).
> > > - Changes are localized to the driver itself (rbd.py) and the
> > > driver
> > >unit tests file (test_rbd.py).
>
> This looks fine to me. My only concern is the risk accepting it would
> introduce, but as you point out that risk is low and should be well
> contained. I think it should be fine to still get this in.
>
>
> > >
> > > Jon would have liked to make this request himself, but due to
> the
> > > untimely arrival of his newborn baby this is not possible.
> > >
> > > For obvious reasons Jon will not be available for a little
> > > while, but
> > > this will not be a problem, as I am well acquainted with the
> > > code -and
> > > I'll be able to reach Jon if necessary- and will be taking
> > > care of the
> > > final steps of the review process of his patch: replying to
> > > comments in
> > > a timely fashion, making changes to the code as required, and
> > > answering
> > > pings on IRC regarding the patch.
> > >
> > > Since some people may be interested in testing this
> > > functionality during
> > > the reviewing process -or just for fun- I'll be publishing a
> > > post with
> > > detailed explanation on how to deploy and test this feature as
> > > well as
> > > an automated way to deploy 2 Ceph clusters -linked to be
> > > mirroring one
> > > another-, and one devstack node with everything ready to test
> the
> > > functionality (configuration and keys for the Ceph clusters,
> > > cinder
> > > configuration, the latest upstream patch, and a volume type
> > > with the
> > > right configuration).
> > >
> > > Please, do not hesitate to ask if there are any questions to
> > > or concerns
> > > related to this request.
> > >
> > > Thank you for taking the time to evaluate this request.
> > >
> > > Cheers,
> > > Gorka.
> > >
> > > [1]: https://review.openstack.org/333565
> > > 
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >  unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> > >  openstack-dev>
> > >
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >  unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >  >
> > >
> > >
> > >
> > >
> > > --
> > > Regards
> > > Huang Zhiteng
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: 

Re: [openstack-dev] [Keystone] Why not OAuth 2.0 provider?

[Yang Hong]

Hello Steve.

Thank you very much for your great work on OAuth 1 authentication for
Keystone.

(1) I have configured Keystone for Federation by following the instructions
below.

Then I can log in to OpenStack through Shibboleth identity provider.


Configuring Keystone for Federation
http://docs.openstack.org/developer/keystone/mitaka/configure_federation.html

-

(2) I can NOT find the instructions on Configuring Keystone for OAuth1.

I also can NOT find the instructions on Configuring Keystone for OAuth2.

http://docs.openstack.org/developer/keystone/mitaka/

Instead I only find the developers' documentation on OAuth2 for OpenStack
(OpenStack/Keystone?)

http://docs.openstack.org/infra/openstackid/oauth2.html

OAuth2 IdP?

https://github.com/openstack-infra/openstackid

Comparing the source code keystone-8.0.0.0b1.tar.gz with the GitHub
repository, I discover that there has been fundemental update on oAuth 1
module.

(2a) For keystone-8.0.0.0b1.tar.gz

https://github.com/openstack/keystone/releases?after=9.0.0.0b1

keystone/contrib/oauth1

backends/ controllers.py core.py routers.py validator.py

(2b) For the GitHub repository,

https://github.com/openstack/keystone/tree/master/keystone

keystone/contrib/oauth1

backends/ routers.py

keystone/oauth1

controllers.py core.py routers.py schema.py validator.py

-

Would you please shed some light on how to configure Keystone for OAuth1?
Thank you very much.

I am trying to develop OAuth 2 client for Keystone. We will contribute our
OAuth 2 client source code to the community if we can use Google/Facebook
to log in to OpenStack through OAuth 2 client.

Thanks.

Best regards,

Winston Hong
Ottawa, Ontario
Canada


Steve Martinelli  Jun 27, 2016, 10:57 PM

> So, the os-oauth routes you mention in the documentation do not make
> keystone a proper oauth provider. We simply perform delegation (one user
> handing some level of permission on a project to another entity) with the
> standard flow established in the oauth1.0b specification.
>
> Historically we chose oauth1.0 because one of the implementers was very
> much against a flow based on oauth2.0 (though the names are similar,
these
> can be treated as two very different beasts, you can read about it here
> [1]). Even amongst popular service providers the choice is split down the
> middle, some providing support for both [2]
>
> We haven't bothered to implement support for oauth2.0 since there has
been
> no feedback or desire from operators to do so. Mostly, we don't want
> yet-another-delegation mechanism in keystone, we have trusts and
oauth1.0;
> should an enticing use case arise to include another, then we can revisit
> the discussion.
>
> [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
> [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon] PTL candidacy

[Richard Jones]

I am announcing my candidacy for Horizon PTL.

I've been contributing to Horizon since the Juno cycle and have
been a core reviewer for the last two cycles. We’ve got a great
culture in the Horizon team that I’d like to help continue and
thrive.

I feel we have made good progress in several areas of Horizon that
improve responsiveness and stability, and believe our focus should
be on continuing that work.

My goals for Ocata are:

- Ensure that modernisation of the interface continues with good
  framework components emerging that are accessible to existing and
  new developers of Horizon and Horizon plugins. This means
  continuing to ensure the code is written to good, consistent
  patterns, but also making sure there is good documentation to
  accompany it.

- Continue to encourage finding better ways to handle scaling
  in OpenStack, both in our own filtering and use of data but also
  liaising with other projects to see how they can help us address
  scaling bottlenecks. Getting the profiling panel integrated into
  Horizon’s developer interface is a high priority for Ocata.

- Improve our rate of addressing bugs; I will look at running more
  of the successful bug days that we had previously. One aspect
  of this is putting more effort into keeping our dependency
  compatibilities up to date, both Python and Django, but also
  the xstatic packages we rely on.

- Improve communication both within the Horizon team and outside
  so folks can more easily get up to speed or keep up to date with
  what’s happening in Horizon.


Thank you,

Richard Jones
__
OpenStack Development Mailing List (not for 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] Overriding internal_api network name

[Steven Hardy]

On Mon, Sep 12, 2016 at 04:21:43PM +0200, Dmitry Tantsur wrote:
> Hi folks!
> 
> I'm looking into support for multiple overclouds with shared control plane.
> I'm porting a downstream guide: https://review.openstack.org/368840.
> 
> However, this no longer works, probably because "internal_api" network name
> is hardcoded in ServiceNetMapDefaults: 
> https://github.com/openstack/tripleo-heat-templates/blob/dfe74b211267cde7a1da4e1fe9430127eda234c6/network/service_net_map.yaml#L14.
> So deployment fails with
> 
> CREATE_FAILED resources.RedisVirtualIP: Property error:
> resources.VipPort.properties.network: Error validating value 'internal_api':
> Unable to find network with name or id 'internal_api'
> 
> Is it a bug? Or is there another way to change the network name? I need it
> to avoid overlap between networks from two overclouds. I'd prefer to avoid
> overriding everything from ServiceNetMapDefaults in my network environment
> file.

IMO this isn't a bug, but an RFE perhaps.

The reason is that until a couple of weeks ago, you always had to fully
define all services in ServiceNetMap, so this is basically just a case
where the optimization introduced here (which allows you to partially
specify ServiceNetMap which is then merged with ServiceNetMapDefaults)
doesn't work:

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

I'd say overriding everything is an OK workaround, but we can definitely
discuss ways to do it more cleanly - I'll give it some thought (probably
we'll need another mapping that defines the network names that can be
easily overidden).

Steve

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

Re: [openstack-dev] [Release] [FFE] two xstatic packages to be bumped in upper-constraints, please

[Tony Breeds]

On Tue, Sep 13, 2016 at 10:39:24AM +1000, Richard Jones wrote:
> Hi folks,
> 
> We have two patches to upper-constraints up that we'd like to see merged
> for Newton. The package updates in question only changed meta-data, but
> they did so in a way that fixes issues for downstream, and it makes sense
> to keep upper-constraints in line with what they'll be packaging.
> 
> The reviews are:
> 
> update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
> https://review.openstack.org/#/c/368970/
> 
> update constraint for XStatic-smart-table to new release 1.4.13.2
> https://review.openstack.org/#/c/366194/

The users of these packages are:
Package  : xstatic-bootstrap-scss [xstatic-bootstrap-scss>=3] (used by 3 
projects)
openstack/karbor-dashboard[type:library]
openstack/horizon [type:service]
openstack/magnum-ui   
[release:cycle-with-intermediary,type:horizon-plugin]
Package  : xstatic-smart-table [xstatic-smart-table!=1.4.13.0,>=1.4.5.3] 
(used by 3 projects)
openstack/karbor-dashboard[type:library]
openstack/horizon [type:service]
openstack/magnum-ui   
[release:cycle-with-intermediary,type:horizon-plugin]

Looks good to me, these changes have 0 code impact and make packagers lives
easier.  As an added bonus as they're just constraint bumps they're easy to
revert if needed.


Yours Tony.


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

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Tony Breeds]

On Tue, Sep 13, 2016 at 09:03:52AM +0800, Jamie Lennox wrote:

> So the major difference between positional 1.0 and 1.1 is that we swapped
> from using a @functools.wrap decorator to a @wrapt decorator. The reason
> for this is that @functools.wraps basically screws up any inspection of the
> function signature.

Yeah I heard abotu wrapt at PyCon-AU[1] this year.  Good stuff

> Barbican failing this difference means it's inspecting
> oslo.context.RequestContext [1] and it looks like it's doing this so it can
> tell the difference between before and after oslo.context 2.2. Given we're
> at 2.9 in minimum requirements we can just remove this and all should be ok.
> 
> Patch: https://review.openstack.org/#/c/369092/

Thanks so much Jamie!   That's a much better solution than bumping g-r and
re-releasing the keystone libraries

Yours Tony.

[1] https://youtu.be/u7oj-ghfhUk


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

[openstack-dev] [trove] PTL candidacy

[Amrith Kumar]

I am writing to submit my candidacy for re-election as the PTL for the
Trove project (Ocata cycle). I have been an active technical
contributor to the Trove project since just before the Icehouse
release when Trove was integrated into OpenStack. I have also
contributed code[1] and reviews[2] to some other OpenStack projects,
and have been an active participant in the Stewardship Working Group
[3] (SWG) and a not-so active participant in the Delimiter project.

Ocata is a short cycle, and based on some discussions within the
community, and feedback from users, I believe that we should continue
to build on the progress and improvements that we were able to acheive
in the Newton cycle, and focus on:

- paying down our technical debt, including specifically some long
  standing items that were listed by the TC at the time when Trove was
  integrated, and improving our testing, addressing some long standing
  issues with dependencies between the server and the client, and

- making it easier to use Trove by delivering tools to simplify guest
  image creation, and improving the commands and API for registering
  datastores and images, and

- improving the Trove API documentation, and

- strengthen the community and foster new members and companies who
  wish to contribute to Trove, and work closely with new participants
  to improve their experiences using Trove, and

- adding support for clustering in some databases (potentially
  Couchbase), refactoring the guestagent for PostgreSQL, supporting
  cluster upgrades, anding add support for additional database
  versions (like MySQL 5.7).

I would also like to take this opportunity to thank all members of the
development community who helped the Trove project during the Newton
cycle; those who contributed code and reviews to the project as well
as members of the infra, release, stable, oslo, docs, dib, and other
project teams who helped us on innumerable occasions.

Thank you, and I appreciate your support in the election. I have
Submitted this candidacy as review [4].

-amrith

--
Amrith Kumar
Email: amr...@tesora.com
IRC: amrith
GPG: 0x5e48849a9d21a29b

[1] http://stackalytics.com/?user_id=amrith=all=commits
[2] http://stackalytics.com/?user_id=amrith=all=marks
[3] https://review.openstack.org/#/c/337895/
[4] https://review.openstack.org/#/c/368960/


__
OpenStack Development Mailing List (not for 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] moving driver to open source

[Ben Swartzlander]

On 09/09/2016 11:12 AM, Duncan Thomas wrote:

On 9 September 2016 at 17:22, Ben Swartzlander > wrote:

On 09/08/2016 04:41 PM, Duncan Thomas wrote:



Despite the fact I've appeared to be slightly disagreeing with
John in
the IRC discussion on this subject, you've summarised my concern
very
well. I'm not convinced that these support tools need to be open
source,
but they absolutely need to be licensed in such a way that
distributions
can repackage them and freely distribute them. I'm not aware of any
tools currently required by cinder where this is not the case,
but a few
of us are in the process of auditing this to make sure we
understand the
situation before we clarify our rules.


I don't agree with this stance. I think the Cinder (and OpenStack)
communities should be able to dictate what form driver take,
including the code and the license, but when we start to try to
control what drivers are allowed to talk to (over and API or CLI)
then we are starting to artificially limit what kinds of storage
systems can integrate with OpenStack.

Storage systems take a wide variety of forms, including specialized
hardware systems, clusters of systems, pure software-based systems,
open source, closed source, and even other SDS abstraction layers. I
don't see the point is creating rules that specify what form a
storage system has to take if we are going to allow a driver for it.
As long as the driver itself and all of it's python dependencies are
Apache licensed, we can do our job of reviewing the code and fixing
cinder-level bugs. Any other kind of restrictions just limit
customer choice and stifle competition.

Even if you don't agree with my stance, I see serious practical
problems with trying to define what it and is not permitted in terms
of "support tools". Is a proprietary binary that communicates with a
physical controller using a proprietary API a "support tool"? What
if someone creates a software-defined-storage system which is purely
a proprietary binary and nothing else?

API proxies are also very hard to nail down. Is an API proxy with a
proprietary license not allowed? What if that proxy runs on the box
itself? What if it's a separate software package you have to
install? I don't think we can write a set of rules that won't
accidentally exclude things we don't want to exclude.


So my issue is not with any of those things, it is that I believe
anybody should be able to put together a distribution of openstack, that
just works, which any supported backend, without needed to negotiate
licensing deals with vendors, and without having to have nasty hacks in
their installers that pull things down off the web on to cinder nodes to
get around licensing rules. That is one of the main 'opens' to me in
openstack.

I don't care so much whether your CLI or API proxy in open or closed
source, but I really do care if I can create a distribution, even a
novel one, with that software in it, without hitting licensing issues.
That is, as I see it, a bare minimum - anything less than that and it
does not belong in the cinder source tree.


I don't understand how you can have this stance while tolerating the 
existence of such things as the VMware driver. That software (ESXi) 
absolutely requires a license to use or distribute.


-Ben


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




__
OpenStack Development Mailing List (not for 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] [elections] Glance PTL non-candidacy

[Nikhil Komawar]

Thanks Brian. I'm glad to be associated with OpenStack and Glance.


On 9/12/16 8:46 AM, Brian Rosmaita wrote:
> Nikhil,
>
> Thank you for all your hard work as Glance PTL (3 times!).  Glad to hear
> that you will be continuing to work in OpenStack, and especially that you
> plan to continue working with Glance.
>
> cheers,
> brian
>
> On 9/12/16, 2:08 AM, "Nikhil Komawar"  wrote:
>
>> Hi team,
>>
>>
>> Just wanted to share my decision for not running for PTL for Glance.
>> It's been great serving the community in this role however, there are
>> some personal and family matters that I need to attend to over the next
>> couple of months or so.
>>
>>
>> I think the Glance team has done great and we've quite a bunch of bright
>> developers who are helping push the project forward in the appropriate
>> direction. With Glare becoming separate project and Ocata being short
>> cycle, I anticipate the priorities being rather obvious to those who
>> have stayed in touch. I will be available to do the rightful handoff to
>> the incoming PTL (for Ocata) and update with Newton happenings once
>> we're done with a few important bugs that are being targeted for RC1.
>>
>>
>> I intend to stick around in Glance and related projects like
>> Searchlight, Glare, etc. However, I am planning to take a more hands on
>> role and see a few features through in Ocata.  Given more and more
>> glance-cores time sharing with other projects, I think we need some
>> throttle in our review system. So, I'd like to help any new developers
>> get their reviews up, that in turn will help the Glance community.
>>
>>
>> Last but not the least, I have thoroughly enjoyed working in this role
>> with all my fellow stackers, particularly glancers! So, a BIG thank you
>> for having worked with me in making Glance better over the last couple
>> of years.
>>
>>
>> -- 
>>
>> Cheers,
>> Nikhil
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [glance] Periodically checking Glance image files

[Nikhil Komawar]

Hey Sergio,


Glad to know that you're not having any feature related issues (to me
this is a good sign). Based on your answers, it makes sense to require a
reliability solution for backend data (or some sort of health monitoring
for the user data).


So, I wonder what your thoughts are for such an audit system. At a first
glance, this looks rather not scalable, at least if you plan to do the
audit on all of the active images. Consider a deployment trying to run
this for around 100-500K active image records. This will need to be run
in batches, thus completing the list of records and saying that you've
done a full audit of the active image -- is a NP-complete problem (new
images can be introduced, some images can be updated in the meantime, etc.)

The failure rate is low, so a random (sparse check) on the image data
won't help either. Would a cron job setup to do the audit for smaller
deployments work? May be we can look into some known cron solutions to
do the trick?


On 9/12/16 4:18 PM, Sergio A. de Carvalho Jr. wrote:
> Hi Nikhil,
>
> Thanks so much for you response.
>
> 1) No, this is a private cloud.
> 2) Glance v1 (this problem has manifested itself in one of our oldest
> deployments, which is running Icehouse).
> 3) No, location is not exposed.
> 4) Glance is setup with the filesystem backend drive, using a Gluster
> volume mounted on the host..
> 5.1) Images were in active state, even though the image file had zero
> bytes.
> 5.2) very low, it may have happened only twice in the last year.
>
> Even if the location is not exposed, there are a number of things that
> can happen to the actual images files after they've been uploaded to
> Glance, without Glance noticing, depending how reliable your storage
> backend is. That's why I thought, in some circumstances, it would be
> useful to have some sort of background service checking that image
> files haven't been corrupted or gone missing altogether.
>
> Sergio
>
>
> On Mon, Sep 12, 2016 at 7:27 PM, Nikhil Komawar  > wrote:
>
>
> Hi Sergio,
>
> Thanks for reaching out. And this is an excellent question.
>
> Firstly, I'd like to mention that Glance is built-in (and if deployed
> correctly) is self-resilient in ensuring that you do NOT need an audit
> of such files. In fact, if any operator (particularly large scale
> operator) needs such a system we have a serious issue where
> potentially
> important /user/ data is likely to be lost resulting in legal
> issues (so
> please beware).
>
> Having said that, I'd like to start investigating more into your
> particular issue and see where we may be missing out in ensuring data
> integrity in Glance. Let me ask you a first few set of questions that
> will help us get an initial understanding:-
>
> 1) Are you a public cloud vendor; in particular, have you deployed
> glance to potentially non-trusted users? or is the case otherwise?
> 2) Are you deploying Glance v1 or Glance v2?
> 3) Have you exposed the "location" feature set (CRUD) to regular
> users?
> (if using API v2, have you enabled ``show_multiple_locations``
> configuration)
> 4) What backends have you configured Glance with and who has access to
> them? What is the resiliency or rotation (of disks) (for say capacity
> management) of your backend store system?
> 5) Sanity check on your issue:-
> 5.1) What are the image statues for which the image data files are
> missing?
> 5.2) What is the rate of error approximately (if you don't have
> specifics, info like rare, medium, often will help)
>
>
> We may have to dig a bit further into the issue but this set of info
> should help us narrow down the issue and determine if there are
> any gaps
> in Glance.
>
> P.S. Please use the tag "[glance]" in the subject line to help us
> get to
> your email faster.
>
> On 9/12/16 12:48 PM, Sergio A. de Carvalho Jr. wrote:
> > Hi all,
> >
> > Is there (or was there ever) any plans to implement in Glance a
> > service that would periodically check that the image files are still
> > available on the file system (or in whatever storage system being
> > used) and have the correct checksum?
> >
> > We had a few issues where an image file was removed from the
> > filesystem and that can go undetected for a long time until someone
> > tries to access that image, so we were wondering if it would be
> > possible (and if it would make sense) to implement some sort of
> > background service to periodically check if all images found in the
> > database can be retrieved successfully.
> >
> > Thoughts?
> >
> > Sergio
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > 

Re: [openstack-dev] [glance] [elections] Glance PTL non-candidacy

[Kekane, Abhishek]

Hi Nikhil,

Thank you for your support, guidance and hard work as Glance PTL.
I have enjoyed working with you and glad to know that you will be there to help 
:)

Thank you,

Abhishek

-Original Message-
From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
Sent: Monday, September 12, 2016 11:39 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [glance] [elections] Glance PTL non-candidacy

Hi team,


Just wanted to share my decision for not running for PTL for Glance.
It's been great serving the community in this role however, there are some 
personal and family matters that I need to attend to over the next couple of 
months or so.


I think the Glance team has done great and we've quite a bunch of bright 
developers who are helping push the project forward in the appropriate 
direction. With Glare becoming separate project and Ocata being short cycle, I 
anticipate the priorities being rather obvious to those who have stayed in 
touch. I will be available to do the rightful handoff to the incoming PTL (for 
Ocata) and update with Newton happenings once we're done with a few important 
bugs that are being targeted for RC1.


I intend to stick around in Glance and related projects like Searchlight, 
Glare, etc. However, I am planning to take a more hands on role and see a few 
features through in Ocata.  Given more and more glance-cores time sharing with 
other projects, I think we need some throttle in our review system. So, I'd 
like to help any new developers get their reviews up, that in turn will help 
the Glance community.


Last but not the least, I have thoroughly enjoyed working in this role with all 
my fellow stackers, particularly glancers! So, a BIG thank you for having 
worked with me in making Glance better over the last couple of years.


-- 

Cheers,
Nikhil


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

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

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

Re: [openstack-dev] [Release] [FFE] two xstatic packages to be bumped in upper-constraints, please

[Matthew Thode]

On 09/12/2016 07:39 PM, Richard Jones wrote:
> Hi folks,
> 
> We have two patches to upper-constraints up that we'd like to see merged
> for Newton. The package updates in question only changed meta-data, but
> they did so in a way that fixes issues for downstream, and it makes
> sense to keep upper-constraints in line with what they'll be packaging.
> 
> The reviews are:
> 
> update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
> https://review.openstack.org/#/c/368970/
> 
> update constraint for XStatic-smart-table to new release 1.4.13.2 
> https://review.openstack.org/#/c/366194/
> 
> 
> Thanks,
> 
> Richard
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Both of these are bumps to upper-constraints, which is good.  Also, I
don't see a problem with downstream projects (as found via codesearch).

-- 
-- Matthew Thode (prometheanfire)



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

[openstack-dev] [kolla] potential Ansible template issue you may meet

[Jeffrey Zhang]

When using ansible template module, you may see the trailing newline
is stripped by blocks, like

# template.j2
a = {% if true %}1{% endfor %}
b = 2

the render will be like

a=1b=2

The newline character after `a=1` is stripped.

The root cause comes from jinja2's trim_blocks feature. Ansible
enabled this feature. If you want to disable it, just add `#jinja2:
trim_blocks: False` to the j2 template file. This is a feature in
Ansible, and I do not think they will fix/change this. But we need
take care of this when using the template module.

More info please check[0][1]

[0] https://github.com/ansible/ansible/issues/16344
[1] http://jinja.pocoo.org/docs/dev/api/#jinja2.Environment

-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me

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

Re: [openstack-dev] [opentack-dev][tacker]Manual install Tacker fails

[Sridhar Ramaswamy]

Hi Zhi,

Thanks for reporting this issue. This is caused due to a recent code
change, that shows up only during manual install. Please open a bug. Fix is
fairly straightforward.

- Sridhar

On Sun, Sep 11, 2016 at 8:39 PM, zhi  wrote:

> hi,
>
> I downloaded the code from the master branch and installed Tacker manual
> by the document[1]. I met an error when I started the tacker-server by
> "python /usr/bin/tacker-server --config-file /etc/tacker/tacker.conf
>   --log-file /var/log/tacker/tacker.log".
>
> The error message is "
> 2016-09-12 11:20:48.427 ERROR stevedore.extension
> [req-4799662d-a606-4337-802f-d94c44b35a50 None None] Could not load
> 'noop': Can't instantiate abstract class DeviceNoop with abstract methods
> get_resource_info
> 2016-09-12 11:20:48.428 ERROR stevedore.extension
> [req-4799662d-a606-4337-802f-d94c44b35a50 None None] Could not load
> 'nova': Can't instantiate abstract class DeviceNova with abstract methods
> get_resource_info
> "
>
> Did anyone meet the same error as me?
>
> Hope for your reply.
>
>
> Thanks
>
>
> [1]. http://docs.openstack.org/developer/tacker/install/
> manual_installation.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-dev] [Release] [FFE] two xstatic packages to be bumped in upper-constraints, please

[Richard Jones]

Hi folks,

We have two patches to upper-constraints up that we'd like to see merged
for Newton. The package updates in question only changed meta-data, but
they did so in a way that fixes issues for downstream, and it makes sense
to keep upper-constraints in line with what they'll be packaging.

The reviews are:

update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
https://review.openstack.org/#/c/368970/

update constraint for XStatic-smart-table to new release 1.4.13.2
https://review.openstack.org/#/c/366194/


Thanks,

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

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Jamie Lennox]

On 8 September 2016 at 11:29, Tony Breeds  wrote:

> On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote:
> > https://review.openstack.org/366631
> >
> > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> > current minimum requirement) results in various unit test failures in
> > barbican, related to parsing of request headers in generated contexts
> > for unit testing.  Updating to 1.1.1 resolves this issue.
>
> I'd really like to get to the bottom of exactly what these failures are
> and how
> they can be fixed.  I'd ask why we didn't catch them sooner but that boils
> down
> to us not actually testing our lower-bounds.
>
> https://bugs.launchpad.net/oslo.context/+bug/1620963 indicates that
> they're
> unit test failures but elsewhere I saw functional tests mentioned.  Have we
> uncovered a real issue or a testing defect?
>
> > This is specifically affecting barbican and RDO testing (from discussion
> > and the review).
> >
> > The reason I think an FFE is needed is because downstream packagers,
> > while encouraged to package based on upper-constraints sometimes don't.
> > Meaning they'd miss something like this.
>
> Yeah it's complex.  We've stated several  times that this is the contract
> we
> make with downstream that we test with u-c and that's our reccomendation
> for
> packaging.  While I agree that we shoudl test our minimums that's not a
> thing
> we can do right now[1]
>
> I agree that it's wrong to state our minimum is 1.0.1 when we *know* that
> it's
> 1.1.1, I'm not convinced the know that yet.
>
> > Arguments against are that this will have knock on effects down the line
> > (will require re-releases and re-re-releases because of updating things
> > like keystone (this is deep in the depgraph)), so is bad from a release
> > team work point of view.  Also, I think this just effects testing, so
> > the impact of this is more minor than something more serious (not JUST
> > breaking testing).
>
> Here's my summary of the changes needed to bump the minimum[2]
>
> Package  : positional [positional>=1.0.1] (used by 4 projects)
> Re-Release   : 4 projects
> openstack/keystoneauth[type:library]
> openstack/keystonemiddleware  [type:library]
> openstack/oslo.context[type:library]
> openstack/python-keystoneclient   [type:library]
>
> Each of those 4 libraries have stable/newton branches that only contain
> updates to .gitreview
> origin/master : keystoneauth1===2.12.1
> origin/master : keystonemiddleware===4.9.0
> origin/master : oslo.context===2.9.0
> origin/master : python-keystoneclient===3.5.0
>
> So if we take the g-r change we'd need to release
>
> keystoneauth1===2.13.0
> keystonemiddleware===4.10.0
> oslo.context===2.10.0
> python-keystoneclient===3.6.0
>
> All of which would be accepted by global-requirements
>
> I know during the requirements meeting I sdaid I was worried about
> secondary
> release effects but if I follow correctly they'll be minimal.
>
> I guess that's a long way of saying we need someone that knows about
> oslo.context and hopefully barbican to look at this
>
> Yours Tony.
>
> [1] I just had an idea for a crazy hack that might kinda work to generate
> lower-constraints.txt something to look at Ocata :)
> [2] If we don't do this befoer we branch stable/newton then we *can't* do
> it.
>

So the major difference between positional 1.0 and 1.1 is that we swapped
from using a @functools.wrap decorator to a @wrapt decorator. The reason
for this is that @functools.wraps basically screws up any inspection of the
function signature.

Barbican failing this difference means it's inspecting
oslo.context.RequestContext [1] and it looks like it's doing this so it can
tell the difference between before and after oslo.context 2.2. Given we're
at 2.9 in minimum requirements we can just remove this and all should be ok.

Patch: https://review.openstack.org/#/c/369092/


[1]
http://git.openstack.org/cgit/openstack/barbican/tree/barbican/context.py?h=3.0.0.0b3#n43


>
> __
> OpenStack Development Mailing 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] [Congress] Default devstack deployment config

[Eric K]

Hi all,

I want to get people¹s thoughts regarding what we should set as default
devstack deployment config for Ocata.
At the moment, it is set to deploy three processes: API, policy, and
datasource-drivers.

I see some potential arguments against that:
1. For most users installing via devstack, running Congress in three
processes bring little benefit, but rather a more complex and less stable
user experience. (Even if our code is perfect, rabbitMQ will timeout every
now and then)
2. It¹s not clear that we want to officially support separating the API from
the policy engine at this point. The supported deployment options for HAHT
do not need it.
The main argument I see for deploying three processes by default is that we
may get more bug reports regarding the multi-process deployment that way.

Our main options for devstack default are:
1. Single-process Congress (with in-mem transport).
2. Two-process Congress API+Policy, datasource-drivers. (other breakdowns
between two processes are also possible)
3. Three-process Congress.

In the end, I think it¹s a trade-off: potentially getting more bug reports
from users, at the expense of a more complex and less polished user
experience that could make a poor first impression. What does everyone
think?

Personally, I slightly favor defaulting to single process Congress because
from a typical devstack user¹s perspective, there is little reason to run
separate processes. In addition, because it is the first time we¹re
releasing our complete architecture overhaul to the wild, and it may be a
good to default to the least complex deployment for the first cycle of the
new architecture.


__
OpenStack Development Mailing List (not for 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] Default devstack deployment config

[Tim Hinrichs]

I'd agree with a single process version of Congress for devstack.  I'd say
we should even do that for Newton.

Tim

On Mon, Sep 12, 2016 at 6:34 PM Eric K  wrote:

> Hi all,
>
> I want to get people’s thoughts regarding what we should set as default
> devstack deployment config for Ocata.
> At the moment, it is set to deploy three processes: API, policy, and
> datasource-drivers.
>
> I see some potential arguments against that:
>
>1. For most users installing via devstack, running Congress in three
>processes bring little benefit, but rather a more complex and less stable
>user experience. (Even if our code is perfect, rabbitMQ will timeout every
>now and then)
>2. It’s not clear that we want to officially support separating the
>API from the policy engine at this point. The supported deployment options
>for HAHT do not need it.
>
> The main argument I see for deploying three processes by default is that
> we may get more bug reports regarding the multi-process deployment that way.
>
> Our main options for devstack default are:
> 1. Single-process Congress (with in-mem transport).
> 2. Two-process Congress API+Policy, datasource-drivers. (other breakdowns
> between two processes are also possible)
> 3. Three-process Congress.
>
> In the end, I think it’s a trade-off: potentially getting more bug reports
> from users, at the expense of a more complex and less polished user
> experience that could make a poor first impression. What does everyone
> think?
>
> Personally, I slightly favor defaulting to single process Congress because
> from a typical devstack user’s perspective, there is little reason to run
> separate processes. In addition, because it is the first time we’re
> releasing our complete architecture overhaul to the wild, and it may be a
> good to default to the least complex deployment for the first cycle of the
> new architecture.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][ptl] Self non-nomination for Kolla PTL for Ocata cycle

[Barrett, Carol L]

Steve - You did a great job leading the effort & appreciate your work on 
building a leadership pipeline for the project.
Best wishes
Carol

Sent from my iPhone

On Sep 12, 2016, at 12:09 PM, Steven Dake (stdake) 
> wrote:

To the OpenStack Community,

Consider this email my self non-nomination for PTL of Kolla for
the coming Ocata release.  I let the team know in our IRC team meeting
several months ago I was passing the on baton at the conclusion of Newton,
but I thought the broader OpenStack community would appreciate the information.

I am super proud of what our tiny struggling community produced starting
3 years ago with only 3 people to the strongly emergent system that is Kolla
with over 467 total contributors [1] since inception and closing in on 5,000
commits today.

In my opinion, the Kolla community is well on its way to conquering the last
great challenge OpenStack faces: Making operational deployment management (ODM)
of OpenStack cloud platforms straight-forward, easy, and most importantly
cost effective for the long term management of OpenStack.

The original objective the Kolla community set out to accomplish, deploying
OpenStack in containers at 100 node scale has been achieved as proven by this
review [2].  In these 12 scenarios, we were able to deploy with 3
controllers, 100 compute nodes, and 20 storage nodes using Ceph for all
storage and run rally as well as tempest against the deployment.

Kolla is _No_Longer_a_Toy_ and _has_not_been_ since Liberty 1.1.0.

I have developed a strong leadership pipeline and expect several candidates
to self-nominate.  I wish all of them the best in the future PTL elections.

Finally, I would like to thank all of the folks that have supported Kolla’s
objectives.  If I listed the folks individually this email would be far too
long, but you know who you are :) Thank you for placing trust in my judgement.

It has been a pleasure to serve as your leader.

Regards
-steak

[1] http://stackalytics.com/report/contribution/kolla-group/2000
[2] https://review.openstack.org/#/c/352101/

__
OpenStack Development Mailing 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] [Congress] PTL non-candidacy

[Eric K]

Thank you so much, Tim, for spearheading and guiding the project all this
time!  I'm especially grateful for your emphasis on supporting the
development and the goals of the contributors. I hope we'll continue to
benefit from your vision and your thought-leadership in the future!

Eric

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

Date:  Monday, September 12, 2016 at 8:20 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  [openstack-dev] [Congress] PTL non-candidacy

> Hi all,
> 
> I've decided it's time to step down as PTL of Congress.  Partly because I have
> so many outside responsibilities, and partly because we have such a strong
> team, the time is right for someone else to lead the project.  We've made so
> much progress over the past couple of years, and there's so much left to do.
> I'm truly excited to see someone's ideas for setting direction and interacting
> with the community.  Should be a ton of fun!
> 
> 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


__
OpenStack Development Mailing List (not for 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] VMware NSX CI - status?

[Giridhar Jayavelu]

Matt,
There was some cleanup done around 2.30pm (PST) and that's why the logs are 
missing.
And the previous failures were due to lower value set for FIXED_NETWORK_SIZE in 
devstack
configuration file. It has been increased to 126 now.

Thanks,
Giri

> On Sep 12, 2016, at 4:29 PM, Matt Riedemann  
> wrote:
> 
> I'd like to know the latest status on the VMware NSX CI. It's not 
> automatically reporting on nova changes, I had to manually check it several 
> times on this change:
> 
> https://review.openstack.org/#/c/281134/
> 
> And then when it does report it fails every time, and the logs are not 
> available.
> 
> Is someone from the VMware team investigating this?
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Congress] PTL candidacy

[Eric K]

Hi all!

I¹m writing to announce my candidacy for Congress PTL (Ocata).

First, I¹d like to thank Tim for his outstanding leadership since the very
beginning of the project.  Under his leadership, Congress has grown from an
interesting idea to a capable service.  I would also like to thank everyone
for
their tremendous support in bringing me along as a Congress contributor,
from
first learning the codebase to leading the high-availability design and
implementation efforts.  I¹m truly grateful to be a part of such a
welcoming,
collaborative and supportive community.

For the Ocata cycle, my main focus for Congress is usability and
ease-of-adoption.  For example, by shipping Congress with pre-built policies
and templates, Congress would provide useful policy-based monitoring fresh
out-of-the-box, its time-to-value improving from weeks to under a day.  I
also
aim to continue prioritizing user engagement, cross-project collaboration,
and
code robustness.  Last but not least, I look forward to supporting our
project
members in their goals and visions for Congress.

Thank you all once again!

-- Eric J. Kao


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

[openstack-dev] [nova] VMware NSX CI - status?

[Matt Riedemann]

I'd like to know the latest status on the VMware NSX CI. It's not 
automatically reporting on nova changes, I had to manually check it 
several times on this change:


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

And then when it does report it fails every time, and the logs are not 
available.


Is someone from the VMware team investigating this?

--

Thanks,

Matt Riedemann


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

[openstack-dev] [Infra] Meeting Tuesday September 13th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday September 13th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project infrastructure and process surrounding automated testing
and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-06-19.03.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-06-19.03.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-06-19.03.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
OpenStack Development Mailing List (not for 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] [elections] Glance PTL non-candidacy

[Nikhil Komawar]

Thanks Abhishek! I'm glad to have been of assistance and happy to help
further.


On 9/13/16 12:27 AM, Kekane, Abhishek wrote:
> Hi Nikhil,
>
> Thank you for your support, guidance and hard work as Glance PTL.
> I have enjoyed working with you and glad to know that you will be there to 
> help :)
>
> Thank you,
>
> Abhishek
>
> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
> Sent: Monday, September 12, 2016 11:39 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [glance] [elections] Glance PTL non-candidacy
>
> Hi team,
>
>
> Just wanted to share my decision for not running for PTL for Glance.
> It's been great serving the community in this role however, there are some 
> personal and family matters that I need to attend to over the next couple of 
> months or so.
>
>
> I think the Glance team has done great and we've quite a bunch of bright 
> developers who are helping push the project forward in the appropriate 
> direction. With Glare becoming separate project and Ocata being short cycle, 
> I anticipate the priorities being rather obvious to those who have stayed in 
> touch. I will be available to do the rightful handoff to the incoming PTL 
> (for Ocata) and update with Newton happenings once we're done with a few 
> important bugs that are being targeted for RC1.
>
>
> I intend to stick around in Glance and related projects like Searchlight, 
> Glare, etc. However, I am planning to take a more hands on role and see a few 
> features through in Ocata.  Given more and more glance-cores time sharing 
> with other projects, I think we need some throttle in our review system. So, 
> I'd like to help any new developers get their reviews up, that in turn will 
> help the Glance community.
>
>
> Last but not the least, I have thoroughly enjoyed working in this role with 
> all my fellow stackers, particularly glancers! So, a BIG thank you for having 
> worked with me in making Glance better over the last couple of years.
>
>

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [glance] [elections] Glance PTL non-candidacy

[Fei Long Wang]

Hi Nikhil,

Thanks for your hard work as Glance PTL, you did a great job. And happy 
to know you will still work in OpenStack, see you around ;)


On 12/09/16 18:08, Nikhil Komawar wrote:

Hi team,


Just wanted to share my decision for not running for PTL for Glance.
It's been great serving the community in this role however, there are
some personal and family matters that I need to attend to over the next
couple of months or so.


I think the Glance team has done great and we've quite a bunch of bright
developers who are helping push the project forward in the appropriate
direction. With Glare becoming separate project and Ocata being short
cycle, I anticipate the priorities being rather obvious to those who
have stayed in touch. I will be available to do the rightful handoff to
the incoming PTL (for Ocata) and update with Newton happenings once
we're done with a few important bugs that are being targeted for RC1.


I intend to stick around in Glance and related projects like
Searchlight, Glare, etc. However, I am planning to take a more hands on
role and see a few features through in Ocata.  Given more and more
glance-cores time sharing with other projects, I think we need some
throttle in our review system. So, I'd like to help any new developers
get their reviews up, that in turn will help the Glance community.


Last but not the least, I have thoroughly enjoyed working in this role
with all my fellow stackers, particularly glancers! So, a BIG thank you
for having worked with me in making Glance better over the last couple
of years.




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


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

[openstack-dev] [Searchlight] PTL Non-candidacy

[Tripp, Travis S]

Hi everybody,

After an amazing ride that I believe has created a solid platform for a rich 
and interactive search experience in OpenStack, I wanted to let everybody know 
that I will not be nominating myself to be the Searchlight PTL for the Ocata 
cycle. I will continue as a core reviewer and will support whoever is the next 
PTL. 

After 4 release cycles of solid and rapid development (Kilo, Liberty, Mitaka, & 
Newton) we will be applying the 1.0 release tag in a few weeks. This marks a 
significant achievement for this project, because we took a very conservative 
approach to release numbering and waited to move past the 0.x release tag until 
we felt like the project was ready for deployers to start using it. We’ve 
achieved that milestone with the Newton release.

With 1.0, Searchlight now provides:

* Unified search and aggregation queries across:
   * Nova instances, flavors, hypervisors, & server groups
   * Glance images, snapshots, metadefs
   * Cinder volumes, snapshots
   * Neutron networks, ports, subnets, routers, security groups, & floating IPs
   * Designate (DNS) Zones, recordsets
   * Swift container and object search (Experimental)
* A horizon search panel (plugin)
* A CLI via an OpenStack client plugin
* Strong deployment management support via documentation and the CLI
   * Including zero downtime re-indexing and migration support

This is all incredibly powerful and really changes the way you interact with 
the cloud when you really start to use it, such as through the Searchlight UI 
plugin for Horizon. Even so, I believe that we’ve barely started to scratch the 
surface of what we can do with the search and aggregation [0] [1] capabilities 
provided by Searchlight.

I’m really excited to see where it goes from here!

-Travis


[0] 
http://docs.openstack.org/developer/searchlight/searchlightapi.html#aggregations
[1] For example, in a couple of hours I was able to use Searchlight to include 
the number of instances that an image is use by in the Horizon images table: 
http://imgur.com/a/l7S00


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

Re: [openstack-dev] [Searchlight] PTL Non-candidacy

[Nikhil Komawar]

Hi Travis,


Firstly, I would like to congratulate you for such an amazing piece of
work that you've lead to create.


Even though not very hands on over the last few months, I've kept myself
updated with the new developments in the projects and seen the team
grow. So, I am glad to say that you've done a brilliant job at creating
this credible team and a vibrant community.


Thank you for all the hard work & great input as the PTL, and for your
decision to stay core in the project! Hope to keep interacting with you
in a different capacity :)

On 9/13/16 1:00 AM, Tripp, Travis S wrote:
> Hi everybody,
>
> After an amazing ride that I believe has created a solid platform for a rich 
> and interactive search experience in OpenStack, I wanted to let everybody 
> know that I will not be nominating myself to be the Searchlight PTL for the 
> Ocata cycle. I will continue as a core reviewer and will support whoever is 
> the next PTL. 
>
> After 4 release cycles of solid and rapid development (Kilo, Liberty, Mitaka, 
> & Newton) we will be applying the 1.0 release tag in a few weeks. This marks 
> a significant achievement for this project, because we took a very 
> conservative approach to release numbering and waited to move past the 0.x 
> release tag until we felt like the project was ready for deployers to start 
> using it. We’ve achieved that milestone with the Newton release.
>
> With 1.0, Searchlight now provides:
>
> * Unified search and aggregation queries across:
>* Nova instances, flavors, hypervisors, & server groups
>* Glance images, snapshots, metadefs
>* Cinder volumes, snapshots
>* Neutron networks, ports, subnets, routers, security groups, & floating 
> IPs
>* Designate (DNS) Zones, recordsets
>* Swift container and object search (Experimental)
> * A horizon search panel (plugin)
> * A CLI via an OpenStack client plugin
> * Strong deployment management support via documentation and the CLI
>* Including zero downtime re-indexing and migration support
>
> This is all incredibly powerful and really changes the way you interact with 
> the cloud when you really start to use it, such as through the Searchlight UI 
> plugin for Horizon. Even so, I believe that we’ve barely started to scratch 
> the surface of what we can do with the search and aggregation [0] [1] 
> capabilities provided by Searchlight.
>
> I’m really excited to see where it goes from here!
>
> -Travis
>
>
> [0] 
> http://docs.openstack.org/developer/searchlight/searchlightapi.html#aggregations
> [1] For example, in a couple of hours I was able to use Searchlight to 
> include the number of instances that an image is use by in the Horizon images 
> table: http://imgur.com/a/l7S00
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Thanks,
Nikhil



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

Re: [openstack-dev] [release] proposing adding Tony Breeds to "Release Managers" team

[Swapnil Kulkarni]

On Tue, Sep 6, 2016 at 9:06 PM, Doug Hellmann  wrote:
> Team,
>
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
>
> Please respond below with +1 or -1.
>
> Thanks,
> 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



+1

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

Re: [openstack-dev] [glance] [elections] Glance PTL non-candidacy

[Nikhil Komawar]

Thank you Fei Long. It's always a pleasure working with you!


On 9/13/16 12:59 AM, Fei Long Wang wrote:
> Hi Nikhil,
>
> Thanks for your hard work as Glance PTL, you did a great job. And
> happy to know you will still work in OpenStack, see you around ;)
>
> On 12/09/16 18:08, Nikhil Komawar wrote:
>> Hi team,
>>
>>
>> Just wanted to share my decision for not running for PTL for Glance.
>> It's been great serving the community in this role however, there are
>> some personal and family matters that I need to attend to over the next
>> couple of months or so.
>>
>>
>> I think the Glance team has done great and we've quite a bunch of bright
>> developers who are helping push the project forward in the appropriate
>> direction. With Glare becoming separate project and Ocata being short
>> cycle, I anticipate the priorities being rather obvious to those who
>> have stayed in touch. I will be available to do the rightful handoff to
>> the incoming PTL (for Ocata) and update with Newton happenings once
>> we're done with a few important bugs that are being targeted for RC1.
>>
>>
>> I intend to stick around in Glance and related projects like
>> Searchlight, Glare, etc. However, I am planning to take a more hands on
>> role and see a few features through in Ocata.  Given more and more
>> glance-cores time sharing with other projects, I think we need some
>> throttle in our review system. So, I'd like to help any new developers
>> get their reviews up, that in turn will help the Glance community.
>>
>>
>> Last but not the least, I have thoroughly enjoyed working in this role
>> with all my fellow stackers, particularly glancers! So, a BIG thank you
>> for having worked with me in making Glance better over the last couple
>> of years.
>>
>>
>

-- 

Thanks,
Nikhil


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

[openstack-dev] [tripleo] Overriding internal_api network name

[Dmitry Tantsur]

Hi folks!

I'm looking into support for multiple overclouds with shared control 
plane. I'm porting a downstream guide: https://review.openstack.org/368840.


However, this no longer works, probably because "internal_api" network 
name is hardcoded in ServiceNetMapDefaults: 
https://github.com/openstack/tripleo-heat-templates/blob/dfe74b211267cde7a1da4e1fe9430127eda234c6/network/service_net_map.yaml#L14. 
So deployment fails with


CREATE_FAILED resources.RedisVirtualIP: Property error: 
resources.VipPort.properties.network: Error validating value 
'internal_api': Unable to find network with name or id 'internal_api'


Is it a bug? Or is there another way to change the network name? I need 
it to avoid overlap between networks from two overclouds. I'd prefer to 
avoid overriding everything from ServiceNetMapDefaults in my network 
environment file.


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

[openstack-dev] [kolla][elections] PTL candidacy

[Michał Jastrzębski]

Hello,

You all hopefully know me as inc0 on IRC. I would like to submit my candidacy
for the PTL position in the following cycle.

I think we, as a team, did a tremendous job in last cycles, ensuring that Kolla
is and will be the great project to work on and to use. Opensource
project is only
as good as its community, and Kolla has proven many times over that it excels in
this front. PTL is just a the first among equals, facilitator for group,
but it's the group that is important. I would be happy to help our community
as PTL to grow while keeping its openness, friendliness, equality and diversity.

I have been a developer in operations teams for 5 years now. In my
opinion Kolla is
an operators' tool which means operators' priorities should be also Kolla's top
priorities. That means stability, careful maintenance of stable branches,
good documentation, troubleshooting and maintenance procedures.

You might know me by my work, which includes:

* Upgrade playbooks
* OSIC cluster testing kickoff
* Customization mechanism for Dockerfiles
* Parts of HA infrastructure
* Early logging infrastructure

My hope for our project, first and foremost, is to provide operators way to
deploy and run OpenStack in a way that will not cost them their nerves. It's my
aspiration for our community that we make sure that OpenStack can be easily and
quickly deployed, upgraded, maintained and scalable. I joined Kolla because I
thought this project holds potential to help achieve these goals (which are
still the biggest issues in OpenStack, according to user survey), and
I believe I
was right to do so.

As PTL my technical goals for Ocata cycle would be:

* Make Kolla easy to extend - there are lots of snowflakes
* Ensure that all the tools are present for large scale deployments - 300+ node
* Provide easier config management and overrides for non-ini configs
* Work on multi-node CI jobs - to ensure HA
* Work on upgrade CI jobs
* Split up kolla-ansible, but keep it as reference implementation for this cycle
* Deliver kolla-kubernetes 1.0
* Ensure high security of Kolla-deployed OpenStack
* Adhere to feedback from our early adopters and evaluators

My goals for our community will include:

* Keep Kolla community diverse. We are one of most diverse project, and we want
  to keep it. This is sign of healthy community.
* Extend Kolla's reach to operators and help operators to have their voice and
  commits included in Kolla project
* Keep Kolla growing and ensure that as it grows, it won't close up for
  newcomers, that resonates nicely with diversity
* Make a "Woot for Kolla" tradition in our weekly meetings:)

I am very grateful for a vote of confidence from You and I promise to do my
very best to ensure that Kolla remains a great project, friendly community and
dependable toolset for production OpenStacks.

Regards,
Michal

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

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Antoni Segura Puimedon]

On Mon, Sep 12, 2016 at 1:42 PM, Antoni Segura Puimedon
 wrote:
> On Mon, Sep 12, 2016 at 1:29 PM, Coughlan, Ivan  
> wrote:
>>
>>
>> Overview
>>
>> Kuryr proposes to address the issues of double encapsulation and exposure of
>> containers as neutron entities when containers are running within VMs.
>>
>> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
>> propose to:
>>
>> -  Use allowed-address-pairs configuration for the VM neutron port
>>
>> -  Use IPVLAN for wiring the Containers within VM
>>
>>
>>
>> In this way:
>>
>> -  Achieve efficient data path to container within VM
>>
>> -  Better leverage OpenStack EPA(Enhanced Platform Awareness)
>> features to accelerate the data path (more details below)
>>
>> -  Mitigate the risk of vlan-aware-vms not making neutron in time
>>
>> -  Provide a solution that works on existing and previous openstack
>> releases
>>
>>
>>
>> This work should be done in a way permitting the user to optionally select
>> this feature.
>>
>>
>>
>>
>>
>> Required Changes
>>
>> The four main changes we have identified in the current kuryr codebase are
>> as follows:
>>
>> · Introduce an option of enabling “IPVLAN in VM” use case. This can
>> be achieved by using a config file option or possibly passing a command line
>> argument. The IPVLAN master interface must also be identified.
>>
>> · If using “IPVLAN in VM” use case, Kuryr should no longer create a
>> new port in Neutron or the associated VEth pairs. Instead, Kuryr will create
>> a new IPVLAN slave interface on top of the VM’s master interface and pass
>> this slave interface to the Container netns.
>>
>> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be
>> identified so we can associate the additional IPVLAN addresses with the
>> port. This can be achieved by querying Neutron’s show-port function and
>> passing the VMs IP address.
>>
>> · If using “IPVLAN in VM” use case, Kuryr should associate the
>> additional IPVLAN addresses with the VMs port. This can be achieved using
>> Neutron’s allowed-address-pairs flag in the port-update function. We intend
>> to make use of Kuryr’s existing IPAM functionality to request these IPs from
>> Neutron.
>>
>>
>>
>> Asks
>>
>> We wish to discuss the pros and cons.
>>
>> For example, containers exposure as proper neutron entities and the utility
>> of neutron’s allowed-address-pairs is not yet well understood.
>>
>>
>>
>> We also wish to understand if this approach is acceptable for kuryr?

My vote is that it is acceptable to work on introducing such mode to
kuryr-libnetwork
(and later to kuryr-kubernetes).

Could we get a link to the current PoC and set a meeting for an
upstreaming plan?


>
> Thanks Ivan, adding discussion about this to the weekly IRC meeting. Maybe 
> it's
> a bit tight for all the participants to get comfortable enough with
> the specifics
> to take a decision today, but let's bring the topic to the table and give an
> answer during this week.
>
>>
>>
>>
>>
>>
>> EPA
>>
>> The Enhanced Platform Awareness initiative is a continuous program to enable
>> fine-tuning of the platform for virtualized network functions.
>>
>> This is done by exposing the processor and platform capabilities through the
>> management and orchestration layers.
>>
>> When a virtual network function is instantiated by an Enhanced Platform
>> Awareness enabled orchestrator, the application requirements can be more
>> efficiently matched with the platform capabilities.
>>
>> http://itpeernetwork.intel.com/openstack-kilo-release-is-shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>>
>> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>>
>> https://www.brighttalk.com/webcast/12229/181563/epa-features-in-openstack-kilo
>>
>>
>>
>>
>>
>> Regards,
>>
>> Ivan….
>>
>> --
>> Intel Research and Development Ireland Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>> Registered Number: 308263
>>
>> This e-mail and any attachments may contain confidential material for the
>> sole use of the intended recipient(s). Any review or distribution by others
>> is strictly prohibited. If you are not the intended recipient, please
>> contact the sender and delete all copies.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

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

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Irena Berezovsky]

Hi Ivan,
The approach looks very interesting and seems to be reasonable effort to
make it work with kuryr as alternative to the 'VLAN aware VM' approach.
Having container presented as neutron entity has its value, especially for
visibility/monitoring (i.e mirroring) and security  (i.e applying security
groups).
But I do think that for short term, this approach is a good way to provide
Container in VM  support.
I  think it's worth to submit devref to kuryr to move forward.
BR,
Irena

On Mon, Sep 12, 2016 at 2:29 PM, Coughlan, Ivan 
wrote:

>
>
> *Overview*
>
> Kuryr proposes to address the issues of double encapsulation and exposure
> of containers as neutron entities when containers are running within VMs.
>
> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
> propose to:
>
> -  Use allowed-address-pairs configuration for the VM neutron port
>
> -  Use IPVLAN for wiring the Containers within VM
>
>
>
> In this way:
>
> -  Achieve efficient data path to container within VM
>
> -  Better leverage OpenStack EPA(Enhanced Platform Awareness)
> features to accelerate the data path (more details below)
>
> -  Mitigate the risk of vlan-aware-vms not making neutron in time
>
> -  Provide a solution that works on existing and previous
> openstack releases
>
>
>
> This work should be done in a way permitting the user to optionally select
> this feature.
>
>
>
>
> *Required Changes*
>
> The four main changes we have identified in the current kuryr codebase are
> as follows:
>
> · Introduce an option of enabling “IPVLAN in VM” use case. This
> can be achieved by using a config file option or possibly passing a command
> line argument. The IPVLAN master interface must also be identified.
>
> · If using “IPVLAN in VM” use case, Kuryr should no longer create
> a new port in Neutron or the associated VEth pairs. Instead, Kuryr will
> create a new IPVLAN slave interface on top of the VM’s master interface and
> pass this slave interface to the Container netns.
>
> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be
> identified so we can associate the additional IPVLAN addresses with the
> port. This can be achieved by querying Neutron’s show-port function and
> passing the VMs IP address.
>
> · If using “IPVLAN in VM” use case, Kuryr should associate the
> additional IPVLAN addresses with the VMs port. This can be achieved using
> Neutron’s allowed-address-pairs flag in the port-update function. We
> intend to make use of Kuryr’s existing IPAM functionality to request these
> IPs from Neutron.
>
>
>
> *Asks*
>
> We wish to discuss the pros and cons.
>
> For example, containers exposure as proper neutron entities and the
> utility of neutron’s allowed-address-pairs is not yet well understood.
>
>
>
> We also wish to understand if this approach is acceptable for kuryr?
>
>
>
>
>
> *EPA*
>
> The Enhanced Platform Awareness initiative is a continuous program to
> enable fine-tuning of the platform for virtualized network functions.
>
> This is done by exposing the processor and platform capabilities through
> the management and orchestration layers.
>
> When a virtual network function is instantiated by an Enhanced Platform
> Awareness enabled orchestrator, the application requirements can be more
> efficiently matched with the platform capabilities.
>
> http://itpeernetwork.intel.com/openstack-kilo-release-is-
> shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>
> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>
> https://www.brighttalk.com/webcast/12229/181563/epa-
> features-in-openstack-kilo
>
>
>
>
>
> Regards,
>
> Ivan….
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> OpenStack Development Mailing 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] [fuel-library] Nominate Stanislaw Bogatkin to fuel-library core

[Alex Schultz]

+1

On Wed, Sep 7, 2016 at 5:07 PM, Maksim Malchuk  wrote:
> Hello,
>
> I would like to nominate Stanislaw Bogatkin to fuel-library core due to his
> significant contribution to the project [1] and [2]. He is one of the top
> reviewers and contributors in the project.
>
> [1]
> http://stackalytics.com/?user_id=sbogatkin_type=all=all=marks=fuel-library
> [2] http://stackalytics.com/report/contribution/fuel-library/90
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Cinder] PTL candidacy

[Sheel Rana Insaan]

+1.

Sean's services as Cinder PTL is really appreciable!!

Regards,
Sheel Rana

On Sep 12, 2016 7:11 PM, "Sean McGinnis"  wrote:

Hello everyone,

I would like to announce my candidacy to continue as Cinder PTL for the
Ocata
release.

The Cinder project has made great strides over the last several releases
adding functionality and improving stability. I think we have a very active
team and love being part of such a strong community.

The Ocata cycle will be a much shorter one than in the past. One thing I
would
like to encourage for this release, as much as makes sense, is to focus on
being mostly a bug fix and stabilization cycle. One side effect of all of
the
great new work going in recently is there has been a lot of new code
introduced
and changes made. There have been fundamental changes in how some things
operate with the the change from rootwrap to privsep. I would like to take
advantage of this shorter concentrated cycle to delay some things in order
to
make sure we have a solid foundation to build on.

Not to say there are any major issues with the project, or that there isn't
new work that we do want to get in to Cinder. We have an incredible team
that
has been able to introduce some pretty significant code with little to no
impact on the rest of the system. Folks have done a great job manually
testing
as well as adding unit and other automated testing to ensure high quality.
But
even with code that has been in there untouched for years we still find
certain
conditions that bring out issues. It would be great to find some of these
now
before we build too much more on top.

Between the Summit and holidays for most over this cycle, Ocata will really
be
a short one. But I look forward to seeing how much this team can do, even in
this quick cycle. This could be a lot of fun!

Thank you for your consideration!

Sean

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

Re: [openstack-dev] [heat] resigning from heat-cores

[Thomas Herve]

On Mon, Sep 12, 2016 at 2:35 PM, Pavlo Shchelokovskyy
 wrote:
> Hi Heaters,
>
> with great regret I announce my resignation from the heat-core team.
>
> About a year ago I was reassigned to another project, and despite my best
> efforts I came to conclusion that unfortunately I can not keep up with
> duties expected from Heat core team member in appropriate capacity.
>
> I do still work on OpenStack, so I'm not leaving the community altogether,
> and will be available in e.g. IRC. I also have some ideas left to implement
> in Heat, but, given the great community we've built around the project, I
> could surely make it as an ordinary contributor.
>
> It was an honor to be a member of this team, I’ve learned a lot during this
> time. Hope to see some of you in Barcelona :)

Thanks a ton Pavlo, it's great working with you, and we'll hope to see
you around again.

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

[openstack-dev] [Ceilometer]:Ceilometer kafka publisher is not consistent !

[Raghunath D]

 Hi ,

I have below entries in my pipeline.yaml file:

sources:
  - name: meter_source
  interval: 600
  meters:
  - "*"
 sinks:
    - name: meter_sink
  transformers:
  publishers:
  - notifier://
  - kafka://localhost:9092?topic=ceilometer

The behaviour of kafka is not consistent.I have to restart 
ceilometer-agent-notification to work it properly.
After restart it works for some time and will start throwing errors.

http://paste.openstack.org/show/572186/
Should I raise a bug for this issue ?

It would be a great help to how to debug and fix this issue.

With Best Regards
 Raghunath Dudyala
 Tata Consultancy Services Limited
 Mailto: raghunat...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

[openstack-dev] [release] PTL candidacy

[Doug Hellmann]

I am announcing my candidacy for PTL for the Release Management team
for the Ocata release cycle [1].

During Newton we successfully split out the Requirements Management
team, which now has enough active members to maintain a healthy review
rate for requirements changes.  The team also made significant
progress in our automation goals during Newton, and I would like to
serve again to see that work through the next phase.

My goals for Ocata include automating stable branch creation through
reviews, as we did with tags; smoothing out a few rough edges in what
we've already implemented for automating tags and releases; and
continuing our documentation work to make the end-of-cycle process
more repeatable and reliable. I would also like for us to finish the
work in reno and pbr to support embedding the release notes build
information in our source distributions.

-- Doug Hellmann

[1] https://review.openstack.org/368924

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

Re: [openstack-dev] [ironic] openstack/python-ironicclient

[Ruby Loo]

On Tue, Sep 6, 2016 at 8:11 AM, Galyna Zholtkevych <
gzholtkev...@mirantis.com> wrote:

> Dear all,
>
> Ironic community needs a help to decide on the specification
>
> of the openstack client command that provide the same functionality as
>
> 'ironic driver-raid-logical-disk-properties' .
>
> Some propositions violate openstack client conventions for a user.
>
> For now the available propositions are:
>
> * openstack baremetal driver raid-logical-disk-properties show
>
> * openstack baremetal driver show --raid-logical-disk-properties
>
> * openstack baremetal driver raid logical disk properties show
>
> * openstack baremetal driver show raid-logical-disk-properties
>
> * openstack baremetal driver show raid logical-disk-properties
>
>
> Reference to the appropriate discussion: https://bugs.launchpad.net/
> python-ironicclient/+bug/1619052
>
>
>
Hi Galyna,

Thanks for asking. These two won't work because 'openstack baremetal driver
show' exists as a command, and the code won't be able to interpret these as
different commands:

   * openstack baremetal driver show raid-logical-disk-properties

   * openstack baremetal driver show raid logical-disk-properties


I think the OSC way is to use English so of these two, probably the second
one is the right way:

* openstack baremetal driver raid-logical-disk-properties show

* openstack baremetal driver raid logical disk properties show


My preference is:

* openstack baremetal driver show --raid-logical-disk-properties


because we already have 'openstack baremetal driver show' as a command, and
other than wanting to see a description of the logical disk properties, the
only other command related to the disk properties is 'openstack baremetal
node set --target-raid-config'.


The problem, though, is that this only shows the disk properties, nothing
else about the driver. The information is different, so that trying to use
this command to show the driver information AND the disk property
descriptions, doesn't make sense either.


If we thought that we might have some 'openstack baremetal driver raid
' command in the future, then 'openstack baremetal driver
raid logical disk properties show' might make more sense. (Now I'm leaning
towards this one.)


Do we really want a way for the user to get this information? Another
choice is not to provide any command for this. (Just kidding.)


--ruby
__
OpenStack Development Mailing 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] Skipping team meeting today?

[Renat Akhmerov]

Team,

I’m travelling now and would like to skip the meeting. If you still would like 
to have it then please take charge.

Renat Akhmerov
@Nokia

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

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Hongbin Lu]

Ivan,

Thanks for the proposal. From Magnum's point of view, this proposal doesn't
seem to require to store neutron/rabbitmq credentials in tenant VMs which
is more desirable. I am looking forward to the PoC.

Best regards,
Hongbin

On Mon, Sep 12, 2016 at 7:29 AM, Coughlan, Ivan 
wrote:

>
>
> *Overview*
>
> Kuryr proposes to address the issues of double encapsulation and exposure
> of containers as neutron entities when containers are running within VMs.
>
> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
> propose to:
>
> -  Use allowed-address-pairs configuration for the VM neutron port
>
> -  Use IPVLAN for wiring the Containers within VM
>
>
>
> In this way:
>
> -  Achieve efficient data path to container within VM
>
> -  Better leverage OpenStack EPA(Enhanced Platform Awareness)
> features to accelerate the data path (more details below)
>
> -  Mitigate the risk of vlan-aware-vms not making neutron in time
>
> -  Provide a solution that works on existing and previous
> openstack releases
>
>
>
> This work should be done in a way permitting the user to optionally select
> this feature.
>
>
>
>
> *Required Changes*
>
> The four main changes we have identified in the current kuryr codebase are
> as follows:
>
> · Introduce an option of enabling “IPVLAN in VM” use case. This
> can be achieved by using a config file option or possibly passing a command
> line argument. The IPVLAN master interface must also be identified.
>
> · If using “IPVLAN in VM” use case, Kuryr should no longer create
> a new port in Neutron or the associated VEth pairs. Instead, Kuryr will
> create a new IPVLAN slave interface on top of the VM’s master interface and
> pass this slave interface to the Container netns.
>
> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be
> identified so we can associate the additional IPVLAN addresses with the
> port. This can be achieved by querying Neutron’s show-port function and
> passing the VMs IP address.
>
> · If using “IPVLAN in VM” use case, Kuryr should associate the
> additional IPVLAN addresses with the VMs port. This can be achieved using
> Neutron’s allowed-address-pairs flag in the port-update function. We
> intend to make use of Kuryr’s existing IPAM functionality to request these
> IPs from Neutron.
>
>
>
> *Asks*
>
> We wish to discuss the pros and cons.
>
> For example, containers exposure as proper neutron entities and the
> utility of neutron’s allowed-address-pairs is not yet well understood.
>
>
>
> We also wish to understand if this approach is acceptable for kuryr?
>
>
>
>
>
> *EPA*
>
> The Enhanced Platform Awareness initiative is a continuous program to
> enable fine-tuning of the platform for virtualized network functions.
>
> This is done by exposing the processor and platform capabilities through
> the management and orchestration layers.
>
> When a virtual network function is instantiated by an Enhanced Platform
> Awareness enabled orchestrator, the application requirements can be more
> efficiently matched with the platform capabilities.
>
> http://itpeernetwork.intel.com/openstack-kilo-release-is-
> shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>
> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>
> https://www.brighttalk.com/webcast/12229/181563/epa-
> features-in-openstack-kilo
>
>
>
>
>
> Regards,
>
> Ivan….
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> OpenStack Development Mailing 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] [Openstack] OpenStack Newton B3 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Martinx - ジェームズ]

On 8 September 2016 at 14:40, Corey Bryant 
wrote:

> Hi All,
>
> The Ubuntu OpenStack team is pleased to announce the general availability
> of OpenStack Newton B3 milestone in Ubuntu 16.10 and for Ubuntu 16.04 LTS
> via the Ubuntu Cloud Archive.
>
> Ubuntu 16.04 LTS
> 
> You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
> Ubuntu 16.04 installations by running the following commands:
>
> sudo add-apt-repository cloud-archive:newton
> sudo apt update
>
> The Ubuntu Cloud Archive for Newton includes updates for Aodh, Barbican,
> Ceilometer, Cinder, Designate, Glance, Heat, Horizon, Ironic (6.1.0),
> Keystone, Manila, Networking-OVN, Neutron, Neutron-FWaaS, Neutron-LBaaS,
> Neutron-VPNaaS, Nova, and Trove.
>
> You can see the full list of packages and versions at [0].
>
> Ubuntu 16.10
> --
> No extra steps required; just start installing OpenStack!
>
> Branch Package Builds
> ---
> If you want to try out the latest master branch updates, or updates to
> stable branches, we are delivering continuously integrated packages on each
> upstream commit in the following PPA’s:
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
>sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
>sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
>
> bear in mind these are built per-commitish (30 min checks for new commits
> at the moment) so ymmv from time-to-time.
>
> Reporting bugs
> 
> Any issues please report bugs using the 'ubuntu-bug' tool:
>
>   sudo ubuntu-bug nova-conductor
>
> this will ensure that bugs get logged in the right place in Launchpad.
>
> Thanks and have fun!
>
> Regards,
>
> Corey
> (on behalf of the Ubuntu OpenStack team)
>
> [0] http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-arc
> hive/newton_versions.html
>
>
That's awesome!

I think that we also need new OpenvSwitch (2.6) and new DPDK-16.07 inside
of UCA (Xenial) too...

I can't find those packages neither here:

https://launchpad.net/~openstack-ubuntu-testing/+
archive/ubuntu/newton?field.series_filter=xenial

Nor here:

https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/newton-staging

I just sent an e-mail to Christian Ehrhardt about this...

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