[openstack-dev] [keystone][ptl][election] PTL candidacy

[Steve Martinelli]

Hey everyone,

I'd like to continue to serve as the PTL of the keystone project for the
Ocata release. I served as PTL of the keystone project for the Mitaka and
Newton development cycles. I find the role to be extremely rewarding, and
would be honoured to continue to serve in the same capacity, if you'll have
me.

During the Mitaka development cycle we accomplished many blueprints and hit
some important goals, here are a few off the top of my head:

  - Python 3 compatibility (for unit tests)
  - Credential encryption
  - PCI support for passwords
  - Running migration tests on non-sqlite backends
  - API docs are migrated and fully updated
  - Introduced the `keystone doctor` helper

For the Ocata release I'd like to take advantage the short development
cycle to aggressively pay down some of the technical debt we've accumulated
and also improve user and operator experience. I'd like to limit new
features to a minimum (maybe 3-5) my short list is the following:

  - Multi Factor Auth (MFA) support
  - Improving the federated identity mapping engine
  - Tackle the issue with long running operations timing out
  - Handle federated authentication without apache libraries
  - Functional tests with non-standard deployments (ldap, federated
identity)

With the exception of MFA support, all the features listed above match the
theme of paying down technical debt or improving user experience.

>From a non-technical perspective, I'd like to do the following:

  - Improve communication and engagement with our direct downstream
consumers (OSA, tripleo, etc)
  - Continue to work with operators. Create specifications based on real
world use cases that are driven by operators facing issues with
performance, usability, scalability, and upgrades.
  - Appoint a bug czar or perform weekly bug triages and monthly bug
squashes

Lastly, I'd like to thank anyone that contributed to keystone during the
Newton release. I'm very excited for what Ocata will bring and look forward
to working on it in any capacity.

Thanks for reading,
stevemar

Link to the election repo change: https://review.openstack.org/#/c/371899/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Trinath Somanchi]

+1


From: Sridhar Ramaswamy 
Sent: Saturday, September 17, 2016 3:40:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tacker] PTL candidacy

Hi Tackers,

I would like to announce my candidacy to continue as Tacker PTL for the Ocata
dev cycle.

I'm a member of the Tacker community right from its Neutron ServiceVM days.
I actively participated in its transition into NFV Orchestration area and its
graduation into big-tent. Since becoming an official project our developer
community has grown and has more diverse [1].

Newton was a packed cycle for us with many stellar achievements from the
community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
Networking-SFC (we are almost there!) and External Alarm-based Monitoring
using Ceilometer. As usual tons of refactoring work happened to continue
to shed the "Neutronisms" in the project.

Along the way, we have become a better openstack citizen following best
practices like Reno release-notes, better release processes, and better
python3 support. We also expanded our core-team with three new members.

My vision for Tacker Ocata is along the following workstreams identified
in the recent weekly meeting.

* Decomposed VIM drivers:
We need to enable a healthy ecosystem of VIM drivers beyond the current
default openstack VIM driver. Our user community has mixed hypervisor/cloud
technology in their deployments - with some existing pre-openstack systems
(a.la, VMware), some OpenStack based clouds, and, forward looking 
into
Containers and public clouds. All this needs an easy to add VIM driver to
bolt underneath Tacker. Luckily our architecture is designed with this in
mind right from day one. We just need to make it easy (a) for developers to
bring in new VIM drivers and (b) for deployers to quickly add new VIM
capabilities without requiring a fork-lift upgrade of Tacker for every new
VIM type.

As part of this workstream, I'd work towards bringing in a Container VIM
type interfacing with Magnum / Zun.

Lifecycle Features:
* Finish left over Newton features - VNFC and NSD
* Better integration with external EM / FCAPS systems
* Enable support for VNFs leveraging Neutron's latest VLAN aware VM feature

Project maintenance:
 * Doc: API reference guide
 * Pecan API framework
 * OSC support
 * Finish python3x TC goal

Tons of fun things to do! However, Ocata is going to be a short cycle.
So, over next few weeks, I'll help to continue to groom these topics and
zoom in on those that are implementable in one dev cycle and clearly
identify some tracks that would carry over to the next cycle.

In Ocata, given an opportunity to serve as your PTL, I'll continue my role
as the "chief enabler" for this amazing community of developers that I'm so
proud to lead over the last two cycles.

- Sridhar Ramaswamy (irc: sridhar_ram)

[1] http://stackalytics.com/?module=tacker-group=commits

__
OpenStack Development Mailing List (not for 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] focus and Newton release

[Emilien Macchi]

On Fri, Sep 16, 2016 at 1:25 PM, Emilien Macchi  wrote:
> Quick follow-up on releases.
>
> The team should currently focus on:
>
> 1) https://review.openstack.org/#/q/topic:tripleo/rc1 - features what
> we want before tagging rc1.
> 2) https://launchpad.net/tripleo/+milestone/newton-rc1 bugs

rc1 is ready, I'll proceed to the release request this week-end.

> 3) https://launchpad.net/tripleo/+milestone/newton-rc2 bugs
> 4) Upgrade testing (patches will be backported if needed as long as
> they are backward compatible)
> 5) IPv6 testing (patch will be backported if needed)
>
> When 1) is done, I'll tag tripleo rc1 and defer all bugs to newton-rc2.
> Another FYI: Puppet OpenStack will release RC1 next week.

Let's focus on rc2 bugs now:
https://launchpad.net/tripleo/+milestone/newton-rc2
4 Confirmed, 13 Triaged, 24 In Progress

+ ipv6 and upgrade testing.

Have a great week-end everyone.

> Reminder: when rc1 is created, stable/newton branch is also created,
> so please take care of backporting your patch merged in master that
> you think we need in stable branch.
>
> Thanks everyone, we're almost there! Keep going :-)
>
> On Wed, Sep 14, 2016 at 3:16 PM, Emilien Macchi  wrote:
>> Folks,
>>
>> We're currently dealing with multiple CI issues, bug almost all
>> blockers are under control.
>> Until the release, the whole team should focus on what is targeted here:
>> https://launchpad.net/tripleo/+milestone/newton-rc1
>> https://launchpad.net/tripleo/+milestone/newton-rc2
>>
>> 1) Finish to land patches that are in Newton blueprints: Custom roles,
>> Ops tools and Manila/CephFS are the top priorities at this time.
>> 2) Work on newton bugs, critical and high. Note: everything that
>> concerns Upgrades is critical or high, so it's very important to
>> finish this work.
>>
>> Because of remaining work, we won't tag RC1 this week but wait the
>> week of September 26. That week, we'll tag RC1 and stable/newton will
>> be created. Hopefully by this time we solved most of our blockers and
>> merged the last patches related to Newton features.
>> From there, we'll have to backport bugfixes (and upgrade work) from
>> master to stable/newton.
>>
>> See more details about release schedule:
>> https://releases.openstack.org/newton/schedule.html#n-finalrc
>>
>> Any feedback or question is more than welcome,
>> --
>> 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] [puppet] Core nominations

[Iury Gregory]

It will be a pleasure join the Puppet OpenStack core team, I learned a lot
from all of you.

Thank you very for the opportunity!

2016-09-16 17:44 GMT-03:00 Emilien Macchi :

> Cool, sounds like great feedback here!
>
> so I created the new gerrit groups and assign new members into it.
> Congrats folks!
>
> On Thu, Sep 15, 2016 at 12:52 PM, Ivan Berezovskiy
>  wrote:
> > +1, great job, guys! Keep rocking!
> >
> > 2016-09-15 18:03 GMT+03:00 Denis Egorenko :
> >>
> >> +1, good job
> >>
> >> 2016-09-15 17:44 GMT+03:00 Matt Fischer :
> >>>
> >>> +1 to all. Thanks for your work guys!
> >>>
> >>> On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi 
> >>> wrote:
> 
>  While our group keeps moving, it's time to propose again new people
>  part of core team.
> 
>  Dmitry Tantsur / puppet-ironic
>  Dmitry is the guardian of puppet-ironic. He's driving most of the
>  recent features in this module and he now fully deserves being core on
>  it.
> 
>  Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
>  Prad is our Telemetry guru and he never stops to bring attention on
>  these modules! Keep going Prad, we appreciate your help here.
> 
>  Iury Gregory / all modules
>  Iury is our padawan. Still learning, but learning fast, he has been a
>  continuous contributor over the last months. He's always here on IRC
>  and during meetings to help.
>  He always volunteer to help and not for the most fun tasks. (He drove
>  the authtoken work during Newton). I would like to reward his work and
>  show that we trust him to be a good core reviewer.
>  Iury, keep going in your efforts!
> 
> 
>  If your name is not here yet, please keep doing consistent work, help
>  in bug triage, maintain stable CI, doing good reviews, improve our
>  documentation, etc.
> 
>  As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.
> 
>  Thanks,
>  --
>  Emilien Macchi
> 
> 
>  
> __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing 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
> >>
> >
> >
> >
> > --
> > Thanks, Ivan Berezovskiy
> > MOS Puppet Team Lead
> > at Mirantis
> >
> > slack: iberezovskiy
> > skype: bouhforever
> > phone: + 7-960-343-42-46
> >
> >
> > 
> __
> > OpenStack Development Mailing 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
>



-- 

~


*Att[]'sIury 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

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Jamie Lennox]

Cue failing on oslo.context was noticed by the oslo gate jobs a while ago.
These patches [1][2][3] were put up to cue to fix the issue and cleanup the
context usage on 2016/07/22 and have not seen a review.


[1] https://review.openstack.org/#/c/345693
[2] https://review.openstack.org/#/c/345694
[3] https://review.openstack.org/#/c/345695


On 17 September 2016 at 11:09, Ken'ichi Ohmichi 
wrote:

> Hi Graham,
>
> Thanks for your response :-)
> Yeah, you are right.
> That seems the same as a designate bug report:
> https://bugs.launchpad.net/designate/+bug/1603036
> Hope this helps the gate jobs.
>
> Thanks
> Ken Ohmichi
>
> ---
>
>
> 2016-09-15 6:21 GMT-07:00 Hayes, Graham :
> > On 15/09/2016 00:12, Ken'ichi Ohmichi wrote:
> >> Hi Cue-team,
> >>
> >> As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
> >> continues failing 100%.
> >> What is current status of the development?
> >> Hopefully the  job will become stable for smooth development.
> >>
> >> Thanks
> >> Ken Ohmichi
> >
> > I am not sure what the status of development is, but it looks like they
> > hit the same issue some of us did with olso.context 2.6.0 (when the
> > output of to_dict() changed).
> >
> >
> >
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Barcelona Design Summit track layout

[Richard Theis]

Thierry Carrez  wrote on 09/16/2016 09:22:27 AM:

> From: Thierry Carrez 
> To: OpenStack Development Mailing List 

> Date: 09/16/2016 09:25 AM
> Subject: [openstack-dev] [all] Barcelona Design Summit track layout
> 
> Hi everyone,
> 
> I mapped the slot allocation (which I sent on Tuesday) to the available
> rooms in Barcelona, trying to take into account all the constraints you
> submitted and to avoid conflicts with talks on the conference side. Here
> is the result:
> 
> https://docs.google.com/spreadsheets/d/1TQ-
> 
RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true
> 
> This is a pretty brittle (and unfun to build) house of cards, so I'd
> rather minimize the number of changes we push to it at this stage. A few
> things:
> 
> 1. If you have a *hard* conflict that I failed to take into account
> (like the PTL is giving a talk during the one and only fishbowl room the
> team has), let me know and I'll try to find someone you could swap with.
> 
> 2. If you already know that you won't be using a given slot, let me know
> which one(s) ASAP and I'll remove your team from it to make it available
> for others. (NB: Freezer already gave up 2 wr slots)
> 
> 3. If you would like to swap two slots, make sure both PTLs agree and
> let me know. I'll check that it doesn't create other conflicts and make
> it happen.
> 
> 4. If you're an official or prospective team and you notice an empty
> slot that you'd like to use, let me know which one. I'll collect the
> requests and try to satisfy them. Note that the page will be refreshed
> as teams liberate extra slots they don't plan to use -- come back often!
> Priority will be given to teams which don't have representation at all.

I'd like to request a workroom for the networking-ovn project team on
Wednesday from 3:05 to 3:45 and/or 3:55 to 4:35.

- Richard Theis

> 
> 5. We have to make the schedule "official" and push it to the main event
> schedule very soon. Please suggest all changes before end of next week
> (September 25) -- after that the layout will be frozen as we map it to
> real room numbers and publish it.
> 
> Thanks!
> 
> -- 
> Thierry Carrez (ttx)
> 
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cue][qa] Status of OpenStack CI jobs

[Ken'ichi Ohmichi]

Hi Graham,

Thanks for your response :-)
Yeah, you are right.
That seems the same as a designate bug report:
https://bugs.launchpad.net/designate/+bug/1603036
Hope this helps the gate jobs.

Thanks
Ken Ohmichi

---


2016-09-15 6:21 GMT-07:00 Hayes, Graham :
> On 15/09/2016 00:12, Ken'ichi Ohmichi wrote:
>> Hi Cue-team,
>>
>> As http://status.openstack.org/openstack-health/#/ , the cue gate jobs
>> continues failing 100%.
>> What is current status of the development?
>> Hopefully the  job will become stable for smooth development.
>>
>> Thanks
>> Ken Ohmichi
>
> I am not sure what the status of development is, but it looks like they
> hit the same issue some of us did with olso.context 2.6.0 (when the
> output of to_dict() changed).
>
>
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Useful tool for easier viewing of IRC logs online

[Will Zhou]

Hi Bashmakov,

The extension is useful for me. Thanks for the recommendation:)


On Sat, Sep 17, 2016 at 5:28 AM Bashmakov, Alexander <
alexander.bashma...@intel.com> wrote:

> Hello Stackers,
>
>
>
> If you ever find yourself needing to peruse OpenStack IRC logs online (
> http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome
> browser to do it, then the following tool may come in handy:
>
>
>
>
> https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade
>
>
>
> It’s a simple extension to filter messages of the type: “ has quit”
> and “ has joined”, which makes the log much more compact and readable.
>
>
>
> Source code is here: https://github.com/abashmak/chrome-irc-filter
>
>
>
> Comments, suggestions are welcome.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Fourie]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Friday, September 16, 2016 3:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tacker] PTL candidacy

Hi Tackers,

I would like to announce my candidacy to continue as Tacker PTL for the Ocata
dev cycle.

I'm a member of the Tacker community right from its Neutron ServiceVM days.
I actively participated in its transition into NFV Orchestration area and its
graduation into big-tent. Since becoming an official project our developer
community has grown and has more diverse [1].

Newton was a packed cycle for us with many stellar achievements from the
community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
Networking-SFC (we are almost there!) and External Alarm-based Monitoring
using Ceilometer. As usual tons of refactoring work happened to continue
to shed the "Neutronisms" in the project.

Along the way, we have become a better openstack citizen following best
practices like Reno release-notes, better release processes, and better
python3 support. We also expanded our core-team with three new members.

My vision for Tacker Ocata is along the following workstreams identified
in the recent weekly meeting.

* Decomposed VIM drivers:
We need to enable a healthy ecosystem of VIM drivers beyond the current
default openstack VIM driver. Our user community has mixed hypervisor/cloud
technology in their deployments - with some existing pre-openstack systems
(a.la, VMware), some OpenStack based clouds, and, forward looking 
into
Containers and public clouds. All this needs an easy to add VIM driver to
bolt underneath Tacker. Luckily our architecture is designed with this in
mind right from day one. We just need to make it easy (a) for developers to
bring in new VIM drivers and (b) for deployers to quickly add new VIM
capabilities without requiring a fork-lift upgrade of Tacker for every new
VIM type.

As part of this workstream, I'd work towards bringing in a Container VIM
type interfacing with Magnum / Zun.

Lifecycle Features:
* Finish left over Newton features - VNFC and NSD
* Better integration with external EM / FCAPS systems
* Enable support for VNFs leveraging Neutron's latest VLAN aware VM feature

Project maintenance:
 * Doc: API reference guide
 * Pecan API framework
 * OSC support
 * Finish python3x TC goal

Tons of fun things to do! However, Ocata is going to be a short cycle.
So, over next few weeks, I'll help to continue to groom these topics and
zoom in on those that are implementable in one dev cycle and clearly
identify some tracks that would carry over to the next cycle.

In Ocata, given an opportunity to serve as your PTL, I'll continue my role
as the "chief enabler" for this amazing community of developers that I'm so
proud to lead over the last two cycles.

- Sridhar Ramaswamy (irc: sridhar_ram)

[1] http://stackalytics.com/?module=tacker-group=commits

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

[openstack-dev] [Neutron] Newton Postmortem

[Armando M.]

Neutrinos,

Now that Ocata is with us, we can almost regain our ability to pronounce
Neutron without confusing it with Newton (at least I know I can).

Before doing that, there is still the postmortem to finalize [1]. I will
keep on touching it between now and the day of the official release to make
sure we captured accurately what's been accomplished in, erm, Newton.

I need your help to make sure everything is in tip-top shape, please keep
an eye and review [1] regularly.

Thanks,
Armando

[1] https://review.openstack.org/#/c/360207/
__
OpenStack Development Mailing List (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] [QA] PTL candidacy

[Omichi, Kenichi]

Hi everyone,

Thank you for given chance to run as a PTL in current Newton cycle.
This experience is exciting and I am glad to work together in the community.
I'd like to continue running as the PTL in the Ocata cycle.

# Newton Summary

At first, it is nice to summarize the Newton cycle for the next Ocata cycle.
We have worked for multiple items in this Newton cycle, and the progress is
amazing. To be honest, my power is not enough to cover all area and this
achievement has been attained by all contributors in this project.
Thank you very much for your contributions.

## Tempest

Tempest is a biggest project under OpenStack QA, the commit number is 13th
of 754 in whole OpenStack[1]. During the Newton cycle, we have provided
Tempest CLI workflow. Users can use Tempest for different clouds/usecases
with separated workspaces, then the operation becomes easy.

The other thing is the cleanup. Tempest had deep class hierarchy and some
magic for resource creation and cleanup. That made investigations hard when
detecting issues. We have removed such barriers for easy debugging.

Now Tempest provides test frameworks to whole OpenStack projects with stable
interfaces. The interfaces still are increasing by releasing Tempest for helping
the other projects. In the Newton cycle, we released 2 versions(12.1.0, 12.2.0)
and they contain many features as these renos[2]. The other projects switched
using these stable interfaces, this situation is appreciated.

## Devstack

One of big Devstack changes is Neutron becomes the default. Neutron is the
direction as the network service instead of nova-net. The change has long
history like enabling/reverting the default Neutron, and now the activation
is stable. So we will be able to get feedback about Neutron widely from
the ecosystem and that will make the quality better in long-term.

The other try is the Devstack code migration for Heat. Devstack provides
a plugin interface to manage its own Devstack code on each project repo,
that makes each project development smooth. The Devstack code has been
implemented in Heat repo and the Heat gate starts running by using that
in the Newton cycle. In addition, several projects rely on Heat. So these
projects need to enable Heat on the gate, and Magnum team succeeded to
do that by working together with Heat team. That is a good collaboration
across projects.

## OpenStack-Health

OpenStack-Health is a useful tool to know test condition of whole OpenStack
projects from bird's-eye view. By using much data for showing graphs, the
performance became issue and we have improved that in this cycle.

The other thing is links to elastic recheck and bug report.
On last failed tests, we can see related elastic recheck and bug report on
the same line. That helps developers to investigate gate issues.

# For Ocata

Based on the Newton experience, I think there are several items for the Ocata 
cycle.

* Help other projects:
  According to the other projects' PTL candidacies, many future PTLs will work
  for QA in the next cycle. QA team will continue helping these projects by
  communicating to the other projects. And it is nice to provide good document
  which describes how to use new test interfaces of Tempest for the other 
projects.
* Continue bug triage:
  An interesting thing is that bug reports tend to be submitted as Tempest bugs
  even if they are due to the other projects' issues. So the bug triage of 
Tempest
  is important to improve whole OpenStack quality by setting reports to suitable
  projects. We started some prototype[3] to show bug triage progress of Tempest.
  Such kind of graph will be helpful to motivate people for the triage. I hope
  this will be expanded to other projects.

This is my proposal and thanks for giving me a chance to raise my hand again.
Regardless of the election result, I will do my best in this project for the 
next cycle.

Thanks
Ken'ichi Ohmichi

---
[1]: http://stackalytics.com/?metric=commits=newton
[2]: http://docs.openstack.org/releasenotes/tempest/unreleased.html
[3]: https://github.com/oomichi/bug-counter#current-graph


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

[openstack-dev] [tacker] PTL candidacy

[Sridhar Ramaswamy]

Hi Tackers,

I would like to announce my candidacy to continue as Tacker PTL for the
Ocata
dev cycle.

I'm a member of the Tacker community right from its Neutron ServiceVM days.
I actively participated in its transition into NFV Orchestration area and
its
graduation into big-tent. Since becoming an official project our developer
community has grown and has more diverse [1].

Newton was a packed cycle for us with many stellar achievements from the
community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
Networking-SFC (we are almost there!) and External Alarm-based Monitoring
using Ceilometer. As usual tons of refactoring work happened to continue
to shed the "Neutronisms" in the project.

Along the way, we have become a better openstack citizen following best
practices like Reno release-notes, better release processes, and better
python3 support. We also expanded our core-team with three new members.

My vision for Tacker Ocata is along the following workstreams identified
in the recent weekly meeting.

* Decomposed VIM drivers:
We need to enable a healthy ecosystem of VIM drivers beyond the current
default openstack VIM driver. Our user community has mixed hypervisor/cloud
technology in their deployments - with some existing pre-openstack systems
(a.la, VMware), some OpenStack based clouds, and, forward looking into
Containers and public clouds. All this needs an easy to add VIM driver to
bolt underneath Tacker. Luckily our architecture is designed with this in
mind right from day one. We just need to make it easy (a) for developers to
bring in new VIM drivers and (b) for deployers to quickly add new VIM
capabilities without requiring a fork-lift upgrade of Tacker for every new
VIM type.

As part of this workstream, I'd work towards bringing in a Container VIM
type interfacing with Magnum / Zun.

Lifecycle Features:
* Finish left over Newton features - VNFC and NSD
* Better integration with external EM / FCAPS systems
* Enable support for VNFs leveraging Neutron's latest VLAN aware VM feature

Project maintenance:
 * Doc: API reference guide
 * Pecan API framework
 * OSC support
 * Finish python3x TC goal

Tons of fun things to do! However, Ocata is going to be a short cycle.
So, over next few weeks, I'll help to continue to groom these topics and
zoom in on those that are implementable in one dev cycle and clearly
identify some tracks that would carry over to the next cycle.

In Ocata, given an opportunity to serve as your PTL, I'll continue my role
as the "chief enabler" for this amazing community of developers that I'm so
proud to lead over the last two cycles.

- Sridhar Ramaswamy (irc: sridhar_ram)

[1] http://stackalytics.com/?module=tacker-group=commits
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Product] Project Navigator - Maturity Metrics

[Shamail]

Hi Kenny,

The maturity metrics in the project navigator are derived using TC Managed 
Tags[1] (binary) and Operator Tags[2] (non-binary).  The description each tag 
can be found in the provided links.  The values for the tags are refreshed 
periodically (e.g. once a release cycle for operator tags) and these are pulled 
into the project navigator and displayed as the 8 maturity indicators for the 
projects.  The ops-tag team meets once a month when we have new submissions to 
review.  Anyone is welcome to submit a tag/indicator for review.

[1] https://governance.openstack.org/reference/tags/
[2] https://github.com/openstack/ops-tags-team/tree/master/descriptions

Thanks,
Shamail

> On Sep 16, 2016, at 2:04 PM, Kenny Johnston  wrote:
> 
> OpenStackers,
> 
> What is the best way to understand the past discussion, and perhaps start a
> new conversation about the maturity metrics found in the project
> navigator[1]? I don't want to propose anything without knowing more of the
> context of why the current metrics and thresholds were chosen.
> 
> Thanks!
> 
> -- 
> Kenny Johnston | irc:kencjohnston | @kencjohnston
> 
> [1]https://www.openstack.org/software/project-navigator/
> ___
> Product-wg mailing list
> product...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg

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

[openstack-dev] [all] Useful tool for easier viewing of IRC logs online

[Bashmakov, Alexander]

Hello Stackers,

If you ever find yourself needing to peruse OpenStack IRC logs online 
(http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome browser to 
do it, then the following tool may come in handy:

https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade

It's a simple extension to filter messages of the type: " has quit" and 
" has joined", which makes the log much more compact and readable.

Source code is here: https://github.com/abashmak/chrome-irc-filter

Comments, suggestions are welcome.
__
OpenStack Development Mailing List (not for 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] Core nominations

[Emilien Macchi]

Cool, sounds like great feedback here!

so I created the new gerrit groups and assign new members into it.
Congrats folks!

On Thu, Sep 15, 2016 at 12:52 PM, Ivan Berezovskiy
 wrote:
> +1, great job, guys! Keep rocking!
>
> 2016-09-15 18:03 GMT+03:00 Denis Egorenko :
>>
>> +1, good job
>>
>> 2016-09-15 17:44 GMT+03:00 Matt Fischer :
>>>
>>> +1 to all. Thanks for your work guys!
>>>
>>> On Thu, Sep 15, 2016 at 6:59 AM, Emilien Macchi 
>>> wrote:

 While our group keeps moving, it's time to propose again new people
 part of core team.

 Dmitry Tantsur / puppet-ironic
 Dmitry is the guardian of puppet-ironic. He's driving most of the
 recent features in this module and he now fully deserves being core on
 it.

 Pradeep Kilambi / puppet-aodh,ceilometer,gnocchi,panko
 Prad is our Telemetry guru and he never stops to bring attention on
 these modules! Keep going Prad, we appreciate your help here.

 Iury Gregory / all modules
 Iury is our padawan. Still learning, but learning fast, he has been a
 continuous contributor over the last months. He's always here on IRC
 and during meetings to help.
 He always volunteer to help and not for the most fun tasks. (He drove
 the authtoken work during Newton). I would like to reward his work and
 show that we trust him to be a good core reviewer.
 Iury, keep going in your efforts!


 If your name is not here yet, please keep doing consistent work, help
 in bug triage, maintain stable CI, doing good reviews, improve our
 documentation, etc.

 As usual, Puppet OpenStack core team is free to -1 / +1 the proposal.

 Thanks,
 --
 Emilien Macchi


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
> __
> OpenStack Development Mailing 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] [Magnum] PTL Candidacy

[Adrian Otto]

I announce my candidacy for, and respectfully request your support to serve as 
your Magnum PTL for the Ocata release cycle.

Here are are my achievements and OpenStack experience and that make me the 
best choice for this role:

* Founder of the OpenStack Containers Team
* Established vision and specification for Magnum
* Founding PTL for Magnum
* Core reviewer since the first line of code was contributed in Nov 2014
* Added Magnum to OpenStack
* Led numerous mid cycle meetups as PTL
* 3 terms of experience as elected PTL for Solum
* Involved with OpenStack since Austin Design Summit in 2010

What background and skills help me to serve in this role well:

* Over 20 years of experience in technical leadership positions
* Unmatched experience leading multi-organization collaborations
* Diplomacy skills for inclusion of numerous viewpoints
* Ability to drive consensus and shared vision
* Considerable experience in public speaking, including multiple keynotes at 
OpenStack Summits, and numerous appearances at other events.
* Leadership of collaborative OpenStack design summit sessions
* Deep belief in Open Source, Open Development, Open Design, and Open Community
* I love OpenStack and I love using containers

During the newton cycle I pushed for important changes we made as a team:
* Advocated for a more focused mission for Magnum, resulting in project Zun.
* Advocated for renaming our Bay resource to Cluster.

During the Ocata cycle we will work together on enabling the next generation
of applications with a design for complex clusters, and better integrating
our clusters with OpenStack services for networking and storage.

I am only running for PTL for one project, because I want Magnum to be my
primary focus.  I look forward to your vote, and continued success together.

Thanks,

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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Sanjay Upadhyay]

+1 to all.
we got a lot of constructive inputs and help from @beagles and @dsneddon.
/sanjay

On Fri, Sep 16, 2016 at 8:05 PM, Jason Rist  wrote:

> On 09/15/2016 03:20 AM, Steven Hardy wrote:
> > Hi all,
> >
> > As we work to finish the last remaining tasks for Newton, it's a good
> time
> > to look back over the cycle, and recognize the excellent work done by
> > several new contributors.
> >
> > We've seen a different contributor pattern develop recently, where many
> > folks are subsystem experts and mostly focus on a particular project or
> > area of functionality.  I think this is a good thing, and it's hopefully
> > going to allow our community to scale more effectively over time (and it
> > fits pretty nicely with our new composable/modular architecture).
> >
> > We do still need folks who can review with the entire TripleO
> architecture
> > in mind, but I'm very confident folks will start out as subsystem experts
> > and over time broaden their area of experience to encompass more of
> > the TripleO projects (we're already starting to see this IMO).
> >
> > We've had some discussion in the past[1] about strictly defining
> subteams,
> > vs just adding folks to tripleo-core and expecting good judgement to be
> > used (e.g only approve/+2 stuff you're familiar with - and note that it's
> > totally fine for a core reviewer to continue to +1 things if the patch
> > looks OK but is outside their area of experience).
> >
> > So, I'm in favor of continuing that pattern and just welcoming some of
> our
> > subsystem expert friends to tripleo-core, let me know if folks feel
> > strongly otherwise :)
> >
> > The nominations, are based partly on the stats[2] and partly on my own
> > experience looking at reviews, patches and IRC discussion with these
> folks
> > - I've included details of the subsystems I expect these folks to focus
> > their +2A power on (at least initially):
> >
> > 1. Brent Eagles
> >
> > Brent has been doing some excellent work mostly related to Neutron this
> > cycle - his reviews have been increasingly detailed, and show a solid
> > understanding of our composable services architecture.  He's also
> provided
> > a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> > Brent continues this exellent Neutron focussed work, while also expanding
> > his review focus such as the good feedback he's been providing on new
> > Mistral actions in tripleo-common for custom-roles.
> >
> > 2. Pradeep Kilambi
> >
> > Pradeep has done a large amount of pretty complex work around Ceilomenter
> > and Aodh over the last two cycles - he's dealt with some pretty tough
> > challenges around upgrades and has consistently provided good review
> > feedback and solid analysis via discussion on IRC.  I propose Prad
> > continues this excellent Ceilomenter/Aodh focussed work, while also
> > expanding review focus aiming to cover more of t-h-t and other repos over
> > time.
> >
> > 3. Carlos Camacho
> >
> > Carlos has been mostly focussed on composability, and has done a great
> job
> > of working through the initial architecture implementation, including
> > writing some very detailed initial docs[3] to help folks make the
> transition
> > to the new architecture.  I'd suggest that Carlos looks to maintain this
> > focus on composable services, while also building depth of reviews in
> other
> > repos.
> >
> > 4. Ryan Brady
> >
> > Ryan has been one of the main contributors implementing the new Mistral
> > based API in tripleo-common.  His reviews, patches and IRC discussion
> have
> > consistently demonstrated that he's an expert on the mistral
> > actions/workflows and I think it makes sense for him to help with review
> > velocity in this area, and also look to help with those subsystems
> > interacting with the API such as tripleoclient.
> >
> > 5. Dan Sneddon
> >
> > For many cycles, Dan has been driving direction around our network
> > architecture, and he's been consistently doing a relatively small number
> of
> > very high-quality and insightful reviews on both os-net-config and the
> > network templates for tripleo-heat-templates.  I'd suggest Dan continues
> > this focus, and he's indicated he may have more bandwidth to help with
> > reviews around networking in future.
> >
> > Please can I get feedback from exisitng core reviewers - you're free to
> +1
> > these nominations (or abstain), but any -1 will veto the process.  I'll
> > wait one week, and if we have consensus add the above folks to
> > tripleo-core.
> >
> > Finally, there are quite a few folks doing great work that are not on
> this
> > list, but seem to be well on track towards core status.  Some of those
> > folks I've already reached out to, but if you're not nominated now,
> please
> > don't be disheartened, and feel free to chat to me on IRC about it.  Also
> > note the following:
> >
> >  - We need folks to regularly show up, establishing a long-term pattern
> of
> >doing useful reviews, but 

Re: [openstack-dev] [security] Proposing Doug Chivers for Security Core

[Jeremy Stanley]

On 2016-09-16 18:29:21 +0100 (+0100), Rob C wrote:
> I'd like to nominate Doug for a CoreSec position as part of the Security
> Project.
[...]

Doug's input on past discussions has been helpful and enlightening.
I'm eager to see further help from him on embargoed vulnerability
reports, so sounds great to me!
-- 
Jeremy Stanley


signature.asc
Description: 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] Project Navigator - Maturity Metrics

[Kenny Johnston]

OpenStackers,

What is the best way to understand the past discussion, and perhaps start a
new conversation about the maturity metrics found in the project
navigator[1]? I don't want to propose anything without knowing more of the
context of why the current metrics and thresholds were chosen.

Thanks!

-- 
Kenny Johnston | irc:kencjohnston | @kencjohnston

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

[openstack-dev] [puppet] newton release - update

[Emilien Macchi]

Hey,

Just a quick update about our plans to release Newton rc1 and final.
I'm preparing rc1 patches:
https://review.openstack.org/#/q/topic:puppet/9.3.0
Feel free to review.

We'll likely release next week and then we'll have stable/newton
branches. From there, only bugfixes can be backported. So let us know
if there is anything you want merged asap.
We'll release final Newton on October 3 at maximum.

Regarding puppet-ceph, I propose we don't branch stable/jewel, as
jewel is still the ongoing release AFIK. Though I'm proposing a tag to
make a release:
https://review.openstack.org/#/c/371719/
Consider this release stable if you plan to deploy Ceph Jewel.

Any question, feedback, is highly welcome.

Enjoy the week-end!
-- 
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] [Solum] PTL candidacy

[Devdatta Kulkarni]

Hi,

I would like to submit my candidacy to continue as PTL of Solum for Ocata
cycle.

In Newton cycle we made progress in several key areas. Here are the
highlights.

1) We completed work on our Horizon dashboard. It is now possible to perform
   all languagepack and app operations through the dashboard. I would like
to
   acknowledge and thank Swati Dewan and Zhu Rong for spearheading this
work.

2) We continued building and experimenting with different options for doing
app builds
   and deployments. In Mitaka cycle we had worked on a feature that enabled
Solum to
   perform app deployments in tandem with existing CI systems such as
Jenkins that can
   do app builds.
   In Newton, following new ideas were investigated:
   - Building applications as VM images and deploying them (thanks Erik
Schilling)
   - Building applications as Unikernels (thanks shivaSR, mvle)
   - Building applications as Docker containers and deploying to VMs
(CoreOS) (thanks Wei Cao)
   We also completed the feature that enables application build and deploy
upon receiving github
   triggers by Solum.

   You can find screencasts demonstrating these features on Solum wiki
   (https://wiki.openstack.org/wiki/Solum), under "Resources" section.

3) We gained several new contributors, some of whom are on their way to
becoming cores.

For the Ocata cycle, some of the ideas that we can pursue together include:
- Making it easy for operators to configure and use different build and
deployment options
- Adding support to deploy applications to container orchestration systems
- Support for using public Docker images, in addition to Solum
languagepacks, to build
  applications

Along with these, we need to keep working on and improving our
documentation, test coverage,
and installation tooling. (If you are interested in helping out with any of
these, please reach out to our team on IRC (#solum on chat.freenode.net)).


Best regards,
Devdatta Kulkarni
__
OpenStack Development Mailing List (not for 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] Barcelona Design Summit track layout

[Emilien Macchi]

On Fri, Sep 16, 2016 at 10:22 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> I mapped the slot allocation (which I sent on Tuesday) to the available
> rooms in Barcelona, trying to take into account all the constraints you
> submitted and to avoid conflicts with talks on the conference side. Here
> is the result:
>
> https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true
>
> This is a pretty brittle (and unfun to build) house of cards, so I'd
> rather minimize the number of changes we push to it at this stage. A few
> things:
>
> 1. If you have a *hard* conflict that I failed to take into account
> (like the PTL is giving a talk during the one and only fishbowl room the
> team has), let me know and I'll try to find someone you could swap with.

I'll give a talk on Thu 27  9:50am-10:30am but in same time there is a
Puppet design session.
Maybe could we move this Puppet session to another slot (my only
constraint is to attend also all TripleO sessions).
I hope we can arrange something :-)

Thanks a lot,

> 2. If you already know that you won't be using a given slot, let me know
> which one(s) ASAP and I'll remove your team from it to make it available
> for others. (NB: Freezer already gave up 2 wr slots)
>
> 3. If you would like to swap two slots, make sure both PTLs agree and
> let me know. I'll check that it doesn't create other conflicts and make
> it happen.
>
> 4. If you're an official or prospective team and you notice an empty
> slot that you'd like to use, let me know which one. I'll collect the
> requests and try to satisfy them. Note that the page will be refreshed
> as teams liberate extra slots they don't plan to use -- come back often!
> Priority will be given to teams which don't have representation at all.
>
> 5. We have to make the schedule "official" and push it to the main event
> schedule very soon. Please suggest all changes before end of next week
> (September 25) -- after that the layout will be frozen as we map it to
> real room numbers and publish it.
>
> Thanks!
>
> --
> 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



-- 
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] Proposing Doug Chivers for Security Core

[Rob C]

I'd like to nominate Doug for a CoreSec position as part of the Security
Project.

CoreSec team members support the VMT with extended consultation on
externally reported vulnerabilities.

Doug has been an active member of the Security project for several years.
He's done significant recent work on threat analysis and been an avid
contributor to our work in general. Doug has significant OpenStack security
experience, having previously been responsible for security HP's public
OpenStack cloud.

I'd like to also take this time to thank Nathan Kinder for all his hard
work as a member of the Security Project. Nathan is taking a step back from
the security work at the moment to focus on other projects, it is his slot
that Doug will be taking, the CoreSec group will remain 5 people.

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

Re: [openstack-dev] [tripleo] focus and Newton release

[Emilien Macchi]

Quick follow-up on releases.

The team should currently focus on:

1) https://review.openstack.org/#/q/topic:tripleo/rc1 - features what
we want before tagging rc1.
2) https://launchpad.net/tripleo/+milestone/newton-rc1 bugs
3) https://launchpad.net/tripleo/+milestone/newton-rc2 bugs
4) Upgrade testing (patches will be backported if needed as long as
they are backward compatible)
5) IPv6 testing (patch will be backported if needed)

When 1) is done, I'll tag tripleo rc1 and defer all bugs to newton-rc2.
Another FYI: Puppet OpenStack will release RC1 next week.

Reminder: when rc1 is created, stable/newton branch is also created,
so please take care of backporting your patch merged in master that
you think we need in stable branch.

Thanks everyone, we're almost there! Keep going :-)

On Wed, Sep 14, 2016 at 3:16 PM, Emilien Macchi  wrote:
> Folks,
>
> We're currently dealing with multiple CI issues, bug almost all
> blockers are under control.
> Until the release, the whole team should focus on what is targeted here:
> https://launchpad.net/tripleo/+milestone/newton-rc1
> https://launchpad.net/tripleo/+milestone/newton-rc2
>
> 1) Finish to land patches that are in Newton blueprints: Custom roles,
> Ops tools and Manila/CephFS are the top priorities at this time.
> 2) Work on newton bugs, critical and high. Note: everything that
> concerns Upgrades is critical or high, so it's very important to
> finish this work.
>
> Because of remaining work, we won't tag RC1 this week but wait the
> week of September 26. That week, we'll tag RC1 and stable/newton will
> be created. Hopefully by this time we solved most of our blockers and
> merged the last patches related to Newton features.
> From there, we'll have to backport bugfixes (and upgrade work) from
> master to stable/newton.
>
> See more details about release schedule:
> https://releases.openstack.org/newton/schedule.html#n-finalrc
>
> Any feedback or question is more than welcome,
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] Third party CI setup for OVS-DPDK and SRIOV

[Ben Nemec]

On 09/15/2016 09:53 AM, Sanjay Upadhyay wrote:

HI Folks,

I am reaching out to understand how best to setup a third party CI for
OVS-DPDK  and SRIOV
.

Since, we have put forth the patches for both sr-iov and ovs-dpdk, I
think its a requirement to test the functionality. Since, this requires
specific h/w, I guess this comes in the purview of third party CI. So,
how best to approach this.

If there is a vendor to back such an initiative, what kind of
requirements we need to post them. I can understand this is very
specific question, but do let me know from Openstack Infra side what are
the requirements to suffice this.

Any pointers on how to setup a third party CI, would be greatly
appreciated. As a part of my commitment, I can assure to document this
for others :)


The general third-party CI docs can be found here: 
http://docs.openstack.org/infra/openstackci/third_party_ci.html


That basic infrastructure is going to be required to even get started. 
From there we'll have to discuss how to actually run third-party 
TripleO jobs.  The existing third-party CI on TripleO (RDO) basically 
has its own independent CI system largely unrelated to tripleo-ci, and I 
don't think reimplementing from scratch is a pattern we want to repeat. :-)




Many thanks,
/sanjay




__
OpenStack Development Mailing List (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] Spain Visa for Indian contributors

[Kekane, Abhishek]

Business Visa is a recommended category.

Thank you,

Abhishek

From: Hrishikesh Barua [tal...@gmail.com]
Sent: Friday, September 16, 2016 12:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Has anybody applied for a Tourist Visa for this event from India? Or is 
Business Visa the recommended category?

On 16 September 2016 at 11:31, M Ranga Swami Reddy 
> wrote:
That's good...

Thanks
Swami

On Thu, Sep 15, 2016 at 10:59 PM, Kekane, Abhishek 
> wrote:
Hi All,

I have got invitation letter in spanish.
Those who requires this letter in spanish, send mail to 
eventv...@openstack.org mentioning the same.

Thanks to OpenStack foundation.

Cheers,

Abhishek

From: Gorka Eguileor Gimeno [gegui...@redhat.com]
Sent: Thursday, September 15, 2016 9:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,

As a native Spanish speaker I offer my help with the translation if needed.
I assume the OpenStack visa team would be the one required to issue the 
translated invitation letter for it to be valid.

Cheers,
Gorka.

On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy 
>>
 wrote:
Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
==
For business visas:
□ Invitation letter from the Spanish company in Spanish language or both in 
English and Spanish.Letters issued only in English will not be accepted. This 
will be an obligatory requirement.
===

On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy 
>>
 wrote:
That's good. Please share the appropriate link/url to openstack visa team.

On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek 
>>
 wrote:
Hi,

Yes it’s request from embassy than for Indian citizens invitation letter should 
be in Spanish as well English language.
I have sent mail to openstack visa team.

Thank you,

Abhishek Kekane

From: M Ranga Swami Reddy 
[mailto:swamire...@gmail.com>]
Sent: Thursday, September 15, 2016 1:06 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi,
Who asked the invitation letter in Spanish? Is it embassy, please share the 
same info openstack visa team.

JYI - for Tokyo - invitation letter was in Japanese only.

Thanks
Swami

On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek 
>>
 wrote:
Hi Janki,

I will keep you posted about this. Mean time sent mail to 
‘eventv...@openstack.org>’
 to explain your issue and also give reference of this ML.

Thank you,

Abhishek Kekane

From: Janki Chhatbar 
[mailto:jankih...@gmail.com>]
Sent: Thursday, September 15, 2016 11:51 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Spain Visa for Indian contributors

Hi Abhishek
I am Janki. I am applying for visa from India. I haven't applied yet but a 
friend of mine is facing the same issue of needing an invitation letter in 
Spanish.
May be everyone applying from India can request to have the letter in Spanish 
too.
Let me know how you proceed further. It would help me while applying.
Thanks
Janki

On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek 
>>
 wrote:
Hi John,

I have sent mail to 
'eventv...@openstack.org>',
 waiting for positive reply.

One reply I got from Kendall is,

We only send the letter in English. No one else applying for a visa has had a 
problem getting their visa with just the English letter so the letter you 
received should be sufficient.

I will show this reply mail at VFS center and hopefully they will take no 
objection about this.

Thank you for your time,

Abhishek Kekane

-Original Message-
From: John Villalovos 

[openstack-dev] [OSC][PTL] PTL candidacy for OpenStackClient

[Dean Troyer]

I am running for re-election as the OpenStackClient PTL.

We accomplished some major milestones in the last term:
* Release 3.0
* Many new Network commands
* Filled many gaps in Volume support
* Extract osc-lib from the base OSC code
* Re-structure the authentication layer to fully utilize os-client-config
(clouds.yaml support) and KeystoneAuth plugins
* Participated in a UX study in Austin that helped understand how users
approach using OpenStackClient and OpenStack as a whole.

In the coming releases we hope to:
* Revise the plugin interface to allow plugins to hook in to common
commands, such as quota set/show
* Add support for higher-layer value-add commands, such as a project purge
command that can remove all resources owned by a project across all APIs
(this also requires the revised plugin interface)
* Continue to address performance issues, specifically with start-up time.
This includes removing dependencies and duplicated functionality.
* Move more command implementations to utilise the OpenStack SDK once it
reaches a 1.0 release.  (This also reduces dependencies.)
* Expand the implementation of list command options --sort, --marker and
--limit to commands where it is not intrinsically included in the
underlying API by implementing it locally to provide a common user
interface for all list commands.
* Continue to migrate useful common code into osc-lib for use by plugins
and stand-alone CLIs.  This includes basic command support code that is not
API-specific.
* Participate in another UX study in Barcelona specifically geared to
address ambiguous command structures.

The os-client-config library is also included in the OpenStackClient
project.  Our plans for it in the near future are:
* Refactor the primary configuration functionality to allow flexibility to
support different needs in calling applications, such as the order of
operations and plugin loading.
* Collect all of the 'magic' configuration bits used in multiple apps in
one place so we can converge support for common user expectations.

Most of all, I want to see us continue our mission of providing a (wait for
it...) consistent interface to OpenStack via the CLI. Sometimes this means
changing how we think about certain operations in individual projects,
sometimes it means providing direction for new operations, and mostly it
means finding the common ground that makes our users lives simpler.

I thank you and am honored by your support.

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] Spain Visa for Indian contributors

[Hrishikesh Barua]

Has anybody applied for a Tourist Visa for this event from India? Or is
Business Visa the recommended category?

On 16 September 2016 at 11:31, M Ranga Swami Reddy 
wrote:

> That's good...
>
> Thanks
> Swami
>
> On Thu, Sep 15, 2016 at 10:59 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
>
>> Hi All,
>>
>> I have got invitation letter in spanish.
>> Those who requires this letter in spanish, send mail to
>> eventv...@openstack.org mentioning the same.
>>
>> Thanks to OpenStack foundation.
>>
>> Cheers,
>>
>> Abhishek
>> 
>> From: Gorka Eguileor Gimeno [gegui...@redhat.com]
>> Sent: Thursday, September 15, 2016 9:35 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>
>> Hi,
>>
>> As a native Spanish speaker I offer my help with the translation if
>> needed.
>> I assume the OpenStack visa team would be the one required to issue the
>> translated invitation letter for it to be valid.
>>
>> Cheers,
>> Gorka.
>>
>> On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy <
>> swamire...@gmail.com> wrote:
>> Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
>> ==
>> For business visas:
>> □ Invitation letter from the Spanish company in Spanish language or both
>> in English and Spanish.Letters issued only in English will not be accepted.
>> This will be an obligatory requirement.
>> ===
>>
>> On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy <
>> swamire...@gmail.com> wrote:
>> That's good. Please share the appropriate link/url to openstack visa team.
>>
>> On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek <
>> abhishek.kek...@nttdata.com> wrote:
>> Hi,
>>
>> Yes it’s request from embassy than for Indian citizens invitation letter
>> should be in Spanish as well English language.
>> I have sent mail to openstack visa team.
>>
>> Thank you,
>>
>> Abhishek Kekane
>>
>> From: M Ranga Swami Reddy [mailto:swamire...@gmail.com> swamire...@gmail.com>]
>> Sent: Thursday, September 15, 2016 1:06 PM
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>
>> Hi,
>> Who asked the invitation letter in Spanish? Is it embassy, please share
>> the same info openstack visa team.
>>
>> JYI - for Tokyo - invitation letter was in Japanese only.
>>
>> Thanks
>> Swami
>>
>> On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek <
>> abhishek.kek...@nttdata.com> wrote:
>> Hi Janki,
>>
>> I will keep you posted about this. Mean time sent mail to ‘
>> eventv...@openstack.org’ to explain your
>> issue and also give reference of this ML.
>>
>> Thank you,
>>
>> Abhishek Kekane
>>
>> From: Janki Chhatbar [mailto:jankih...@gmail.com> jankih...@gmail.com>]
>> Sent: Thursday, September 15, 2016 11:51 AM
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>
>> Hi Abhishek
>> I am Janki. I am applying for visa from India. I haven't applied yet but
>> a friend of mine is facing the same issue of needing an invitation letter
>> in Spanish.
>> May be everyone applying from India can request to have the letter in
>> Spanish too.
>> Let me know how you proceed further. It would help me while applying.
>> Thanks
>> Janki
>>
>> On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
>> abhishek.kek...@nttdata.com> wrote:
>> Hi John,
>>
>> I have sent mail to 'eventv...@openstack.org> eventv...@openstack.org>', waiting for positive reply.
>>
>> One reply I got from Kendall is,
>>
>> We only send the letter in English. No one else applying for a visa has
>> had a problem getting their visa with just the English letter so the letter
>> you received should be sufficient.
>>
>> I will show this reply mail at VFS center and hopefully they will take no
>> objection about this.
>>
>> Thank you for your time,
>>
>> Abhishek Kekane
>>
>> -Original Message-
>> From: John Villalovos [mailto:openstack@sodarock.com> openstack@sodarock.com>]
>> Sent: Thursday, September 15, 2016 11:17 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>>
>> On that page they seem to list a contact email:
>>
>> eventv...@openstack.org
>>
>> Hopefully they can help with the issue.
>>
>> John
>>
>> On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
>> abhishek.kek...@nttdata.com> wrote:
>> > Hi John,
>> >
>> > I have read the information given at
>> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
>> > and got the invitation letter but it's in English language. 

[openstack-dev] Fwd: [release][Neutron] Neutron Newton RC1 available

[Armando M.]

Neutrinos,

As per announcement below, we are now past RC1. I'll be going over the
changes that were blocked during the past week and lift the -2s. Even
though master development is open, please consider focusing on Newton with
a great deal of attention [1].

Make sure to give review priority to issues as tracked in [2,3,4].

If you have any question, please reach out to a member of the Neutron
release team [5] on IRC.

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/policies/release-checklist.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=deprecation
[4] https://bugs.launchpad.net/neutron/+bugs?field.tag=newton-rc-potential
[5] https://review.openstack.org/#/admin/groups/150,members

-- Forwarded message --
From: Davanum Srinivas 
Date: 16 September 2016 at 09:27
Subject: [openstack-dev] [release][Neutron] Neutron Newton RC1 available
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>


Hello everyone,

The release candidate for Neutron for the end of the Newton cycle
is available!  You can find the RC1 source code tarball(s) at:

https://tarballs.openstack.org/neutron/neutron-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-dynamic-routing/
neutron-dynamic-routing-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-
vpnaas-9.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *newton-rc-potential* to bring it to the Neutron release
crew's attention.

Note that the "master" branch of Neutron is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)


--
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (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][Congress] Congress Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Congress for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/congress/congress-4.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/congress/+filebug

and tag it *newton-rc-potential* to bring it to the Congress release
crew's attention.

Note that the "master" branch of Congress is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [release][Barbican] Barbican Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Barbican for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/barbican/barbican-3.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/barbican/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/barbican/+filebug

and tag it *newton-rc-potential* to bring it to the Barbican release
crew's attention.

Note that the "master" branch of Barbican is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)


-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [release][Neutron] Neutron Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Neutron for the end of the Newton cycle
is available!  You can find the RC1 source code tarball(s) at:

https://tarballs.openstack.org/neutron/neutron-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-dynamic-routing/neutron-dynamic-routing-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-9.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *newton-rc-potential* to bring it to the Neutron release
crew's attention.

Note that the "master" branch of Neutron is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)


-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

[gordon chung]

On 16/09/16 05:46 AM, Julien Danjou wrote:
> On Fri, Sep 16 2016, Sam Morrison wrote:
>
>
>> Currently it is failing one test [1] and that is to do with retention.
>> This is because influxDB does retention based on the current time, e.g. a 1 
>> day retention policy will be from the current time.
>> The tests assume that the retention period is based on the data stored and 
>> so it will keep 1 day of data no matter how old that data is.
>
> lol, yeah the test assume it's a database that does not block you to
> insert things as you want. I feel like that being a bad and funny design
> decision (Whisper has the same defect).
>

i think i know why they did this. i originally thought we should do this 
since it'd make scheduling aggregation/compression tasks easier but i 
like the fact we handled this without limiting us to possible issues of 
what 'current time' is in distributed environment.

i've no idea how to fix this unless you could somehow mock time influx 
uses. you might want to just skip this test too?

cheers,
-- 
gord

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

[openstack-dev] [nova][scheduler] Next Scheduler sub-team meeting

[Ed Leafe]

The next meeting of the Nova Scheduler subteam will be Monday, September 19 at 
1400 UTC in #openstack-meeting-alt

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160919T14

There probably won’t be much to discuss for Newton, but we should probably 
start thinking about Summit topics. If you have some ideas, please add them to 
the agenda at https://wiki.openstack.org/wiki/Meetings/NovaScheduler


-- Ed Leafe






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

[openstack-dev] OpenStack Developer Mailing List Digest September 10-16

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/09/openstack-developer-mailing-list-digest-20160916/

Nominations for OpenStack PTLs Are Now Open
===
* Will remain open until September 18 23:45 UTC
* Submit a text file to the openstack/election repository [1].
  - File name convention: $cycle_name/$project_name/$ircname.txt
* In order to be an elgible candidate (and be allowed to vote) you need to have
  contributed an accepted patch to one of the program projects during the
  Mitaka-Newton timeframe.
* Additional information [2].
* Approved candidates [3]
* Elections will start at September 19, 2016 00:00 UTC until September 25 23:45
  UTC
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103439.html

Ocata Design Summit – Proposed Slot Allocation
==
* Proposed slot allocation for project teams at the Ocata design summit in
  Barcelona [4] based on requests current PTLs have made and adjusted for limit
  space available.
* Kendall Nelson and Thierry will start laying out those sessions over the
  available rooms and time slots.
* Communicated constraints (e.g. Manila not wanting to overlap with Cinder)
  should be communicated to Thierry asap.
* If you don't plan to use all of your slots, let Thierry know so they can be
  given to a team that needs them.
* Start working with your team on content you'd like to cover at the summit and
  warm up those etherpads!
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103560.html

OpenStack Principles

* A set of OpenStack principles is proposed [5] to accurately capture existing
  tribal knowledge as a prerequisite for being able to have an open and
  productive discussions about changing it.
* Last time majority of the Technical Committee were together, it was realized
  that there were a set of unspoken assumptions carried and used to judge
  things.
  - These are being captured to empower everyone to actually be able challenge
and discuss them.
* The principles were started by various TC members who have governance history
  and know these principles. This was in attempt to document this history to
  commonly asked questions. These are not by any means final, and the community
  should participate in discussing them.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#103223

API Working Group News
==
* Recently merged guidelines
  - URIs [6]
  - Links [7]
  - Version string being parsable [8]
* Guidelines Under review
  - Add a warning about JSON expectations. [9]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#102746


[1] - http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] - https://governance.openstack.org/election/
[3] - http://governance.openstack.org/election/#ocata-ptl-candidates
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103560.html
[5] - https://review.openstack.org/#/c/357260/5
[6] - https://review.openstack.org/322194
[7] - https://review.openstack.org/354266
[8] - https://review.openstack.org/346846
[9] - https://review.openstack.org/#/c/364460/

__
OpenStack Development Mailing List (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][documentation] openstack-doc-tools 1.1.0 release

[no-reply]

We are high-spirited to announce the release of:

openstack-doc-tools 1.1.0: Tools for OpenStack Documentation

With source available at:

http://git.openstack.org/cgit/openstack/openstack-doc-tools

Please report issues through launchpad:

http://bugs.launchpad.net/openstack-manuals

For more details, please see below.

1.1.0
^

Other Notes

* For translated manuals, the command "doc-tools-check-languages"
  now places a marker file in the root of each directory. This marker
  file is needed for proper publishing in the OpenStack CI
  environment. For details, see http://specs.openstack.org/openstack-
  infra/infra- specs/specs/doc-publishing.html.

Changes in openstack-doc-tools 1.0.1..1.1.0
---

54aa873 Add root-marker file to translated manuals
0d9c027 [cli-ref] remove deprecated Block Storage API v1
14e757e [cli-ref] unsupport the openstack command
c9b9598 [cli-ref] support Backup, Restore, and DR service
fdd034d [cli-ref] support NFV Orchestration service
307344f Changing 'raise e' to 'raise' to prevent exception masking


Diffstat (except docs and test files)
-

autogenerate_config_docs/autohelp.py  |  2 +-
bin/doc-tools-check-languages | 30 ---
os_doc_tools/commands.py  | 15 ++
os_doc_tools/resources/clients.yaml   | 36 +--
releasenotes/notes/afs-docs-952f940dc7c47408.yaml |  7 +
5 files changed, 63 insertions(+), 27 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] [Congress] Congress horizon plugin - congressclient/congress API auth issue - help

[Aimee Ukasick]

Eric - I added some info to the bug report
https://bugs.launchpad.net/congress/+bug/1602837

My version of DevStack uses keystone v2 for everything. However, I
found this line in the Horizon log:

"The Keystone URL (either in Horizon settings or in service catalog)
points to a v2.0 Keystone endpoint,
but v3 is specified as the API version to use by Horizon. Using v3
endpoint for authentication."


So when I hard-coded the auth_url to be v2.0, the pages loaded data as
expected.
I used your "replace" and will upload a patch asap.

Thanks!

aimee




On Thu, Sep 15, 2016 at 10:05 PM, Eric K  wrote:
> Anusha and Aimee,
>
> Circling back on this issue: it seems that you are seeing different things
> with regards to horizon authentication using keystone v2. I think we can
> make good progress if we can clarify where we stand.
>
> Anusha said setting the auth_url explicitly to v2 works. Aimee said it
> didn¹t.
>
> So just to clarify:
>
> 1. Anusha did you mean set this line
> https://github.com/openstack/congress/blob/master/congress_dashboard/api/co
> ngress.py#L75
> To:
> `auth_url = 'http://:5000/v2.0¹` ?
>
> 2. Aimee, is that what you tried?
>
> 3. Do you still get different results?
>
> From Anusha¹s commit message in this patch
> (https://review.openstack.org/#/c/305063/), the current code should fail
> because `auth_url = getattr(settings, 'OPENSTACK_KEYSTONE_URL¹)`[L75]
> grabs the .../v3 URL (devstack default), yet `auth =
> keystoneclient.auth.identity.v2.Token(`[L77] expects a .../v2.0 URL. So
> could we have a workaround simply by doing something like `auth_url =
> auth_url.replace('v3', 'v2.0¹)`? (*)
>
> Thanks again for all the investigative work!
>
> Eric
>
> (*) Another potential issue is ports:
> https://ask.openstack.org/en/question/67846/difference-between-keystone-por
> t-5000-and-35357/
>
> On 7/22/16, 9:06 AM, "Aimee Ukasick"  wrote:
>
>>All - I made the change to the auth_url that  Anusha suggested.
>>Same problem as before " Cannot authorize API client"
>>2016-07-22 14:13:50.835861 * calling policies_list =
>>client.list_policy()*
>>2016-07-22 14:13:50.836062 Unable to get policies list: Cannot
>>authorize API client.
>>
>>I used the token from the log output to query the Congress API with
>>the keystone v3 token - no issues.
>>curl -X GET -H "X-Auth-Token: 18ec54ac811b49aa8265c3d535ba0095" -H
>>"Cache-Control: no-cache" "http://192.168.56.103:1789/v1/policies;
>>
>>So I really think the problem is that the python-congressclient
>>doesn't support identity v3.
>>I thought it did, but then I came across this:
>>"support keystone v3 api and session based authentication "
>>https://bugs.launchpad.net/python-congressclient/+bug/1564361
>>This is currently assigned to Anusha.
>>I'd like to start work on it since I am becoming familiar with keystone
>>v3.
>>
>>Thoughts?
>>
>>aimee
>>
>>
>>
>>
>>On Fri, Jul 22, 2016 at 8:07 AM, Aimee Ukasick
>> wrote:
>>> Thanks Anusha! I will retest this today. I guess I need to learn more
>>> about Horizon as well - thanks for pointing me in the right direction.
>>>
>>> aimee
>>>
>>>
>>>
>>> On Fri, Jul 22, 2016 at 6:30 AM, Anusha Ramineni
>>> wrote:
 Hi Aimee,

 I think devstack by default configured horizon to use v3 .
 For V2 authentication, from the logs , auth_url doesn't seem to be set
 explicitly to v2 auth_url .

 I have always set explicit v2 auth which worked fine.
 For eg:- auth_url = 'http://:5000/v2.0' , for V2
authentication

 I have raised a patch, to take the auth_url from horizon settings
instead of
 from request.
 https://review.openstack.org/#/c/345828/1

 Please set explict v2 auth_url as mentioned above in
OPENSTACK_KESYTONE_URL
 in /openstack_dashboard/local/local_settings.py and restart
apache2
 server . Then v2 authentication should go through fine.

 For v3 , need to add relevant code for v3 authentication in
contrib/horizon
 as presently it is hardcoded to use only v2. but yes, the code from
plugin
 model patch is still a WIP , so doesn't work for v3 authentication I
guess
 I'll have a look at it and let you know .


 Best Regards,
 Anusha

 On 21 July 2016 at 21:56, Tim Hinrichs  wrote:
>
> So clearly an authentication problem then.
>
> Anusha, do you have any ideas?  (Aimee, I think Anusha has worked with
> Keystone authentication most recently, so she's your best bet.)
>
> Tim
>
> On Thu, Jul 21, 2016 at 8:59 AM Aimee Ukasick
>  wrote:
>>
>> The  Policy/Data Sources web page throws the same errors. I am
>> planning to recheck direct API calls using v3 auth today or tomorrow.
>>
>> aimee
>>
>> On Thu, Jul 21, 2016 at 10:49 AM, Tim Hinrichs  wrote:
>> > 

[openstack-dev] [release][Ceilometer] Ceilometer Newton RC1 available

[Davanum Srinivas]

Hello everyone,

The release candidate for Ceilometer for the end of the Newton cycle
is available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/ceilometer/ceilometer-7.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/ceilometer/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/ceilometer/+filebug

and tag it *newton-rc-potential* to bring it to the Ceilometer release
crew's attention.

Note that the "master" branch of Ceilometer is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of Release Team)

-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Jason Rist]

On 09/15/2016 03:20 AM, Steven Hardy wrote:
> Hi all,
> 
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
> 
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
> 
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
> 
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
> 
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
> 
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
> 
> 1. Brent Eagles
> 
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
> 
> 2. Pradeep Kilambi
> 
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
> 
> 3. Carlos Camacho
> 
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
> 
> 4. Ryan Brady
> 
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
> 
> 5. Dan Sneddon
> 
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
> 
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.
> 
> Finally, there are quite a few folks doing great work that are not on this
> list, but seem to be well on track towards core status.  Some of those
> folks I've already reached out to, but if you're not nominated now, please
> don't be disheartened, and feel free to chat to me on IRC about it.  Also
> note the following:
> 
>  - We need folks to regularly show up, establishing a long-term pattern of
>doing useful reviews, but core status isn't about raw number of reviews,
>it's about consistent downvotes and detailed, well considered and
>insightful feedback that helps increase quality and catch issues early.
> 
>  - Try to spend some time reviewing stuff outside your normal area of
>expertise, to build understanding of the broader TripleO system - as
>discussed 

[openstack-dev] [all] Barcelona Design Summit track layout

[Thierry Carrez]

Hi everyone,

I mapped the slot allocation (which I sent on Tuesday) to the available
rooms in Barcelona, trying to take into account all the constraints you
submitted and to avoid conflicts with talks on the conference side. Here
is the result:

https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfUP7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true

This is a pretty brittle (and unfun to build) house of cards, so I'd
rather minimize the number of changes we push to it at this stage. A few
things:

1. If you have a *hard* conflict that I failed to take into account
(like the PTL is giving a talk during the one and only fishbowl room the
team has), let me know and I'll try to find someone you could swap with.

2. If you already know that you won't be using a given slot, let me know
which one(s) ASAP and I'll remove your team from it to make it available
for others. (NB: Freezer already gave up 2 wr slots)

3. If you would like to swap two slots, make sure both PTLs agree and
let me know. I'll check that it doesn't create other conflicts and make
it happen.

4. If you're an official or prospective team and you notice an empty
slot that you'd like to use, let me know which one. I'll collect the
requests and try to satisfy them. Note that the page will be refreshed
as teams liberate extra slots they don't plan to use -- come back often!
Priority will be given to teams which don't have representation at all.

5. We have to make the schedule "official" and push it to the main event
schedule very soon. Please suggest all changes before end of next week
(September 25) -- after that the layout will be frozen as we map it to
real room numbers and publish it.

Thanks!

-- 
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] [neutron] Skip-only tests

[John Davidge]

John Schwarz wrote:

>Hi all,
>
>The Neutron community has recently started contributing Tempest
>scenario tests in the Neutron tree and I'd like to discuss a general
>issue we're hitting. Mainly, we're talking about required hardware for
>some features and/or VM images that support more features, which makes
>it hard (or impossible) to test certain features at the gate
>end-to-end. Specifically, tests that require SR-IOV or OVS-DPDK, and
>tests relating to VLAN Aware VMs.
>[Š]

Resurrecting this thread with another example where this would be useful:

IPv6 Prefix Delegation

This feature still lacks end-to-end testing because it depends upon having
a compatible DHCPv6 server installed and running with an appropriate
config, and specifically dibbler[1] to act as the DHCPv6 client.

I¹d be interested in assisting with this effort.

John

[1] https://github.com/tomaszmrugalski/dibbler




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[John Trowbridge]

On 09/15/2016 05:20 AM, Steven Hardy wrote:
> Hi all,
> 
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
> 
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
> 
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
> 
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
> 
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
> 
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
> 
> 1. Brent Eagles
> 
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
> 
> 2. Pradeep Kilambi
> 
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
> 
> 3. Carlos Camacho
> 
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
> 
> 4. Ryan Brady
> 
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
> 
> 5. Dan Sneddon
> 
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
> 
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.
> 
> Finally, there are quite a few folks doing great work that are not on this
> list, but seem to be well on track towards core status.  Some of those
> folks I've already reached out to, but if you're not nominated now, please
> don't be disheartened, and feel free to chat to me on IRC about it.  Also
> note the following:
> 
>  - We need folks to regularly show up, establishing a long-term pattern of
>doing useful reviews, but core status isn't about raw number of reviews,
>it's about consistent downvotes and detailed, well considered and
>insightful feedback that helps increase quality and catch issues early.
> 
>  - Try to spend some time reviewing stuff outside your normal area of
>expertise, to build understanding of the broader TripleO system - as
>discussed 

Re: [openstack-dev] [TripleO] TripleO Core nominations

[James Slagle]

On Thu, Sep 15, 2016 at 5:20 AM, Steven Hardy  wrote:
> Hi all,
>
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
>
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
>
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
>
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
>
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
>
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
>
> 1. Brent Eagles
>
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
>
> 2. Pradeep Kilambi
>
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
>
> 3. Carlos Camacho
>
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
>
> 4. Ryan Brady
>
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
>
> 5. Dan Sneddon
>
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
>
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.

+1 to all.

-- 
-- James Slagle
--

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

[openstack-dev] [designate] PTL Candidacy

[Hayes, Graham]

Hi Everyone,

I would like to my intention to continue as PTL of the Designate
project for another cycle.

We have made great steps forward in Designate over the last few cycles,
not just with features, but integrating with the community as a whole.

For Ocata, I have previously proposed, and now am completely behind
making this cycle a non feature cycle. We have built up some large amount
of technical debt, and are in need of some time to just do hardening, bug
fixes, and performance improvements.

With Ocata being such a short cycle, I think we have a prime opportunity
to do that, and with the recent merge of Worker Model, we should not need
any other major refactors.

I think we have made major progress over the previous 3 or 4 years,
and have done amazing work, despite (or maybe because of) being a small
team.

Thanks for reading, and your consideration for PTL.

- Graham

__
OpenStack Development Mailing List (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 Rpm] PTL candidacy

[Haïkel]

Fellow RPM packagers,

I announce my candidacy for PTL of the Packaging Rpm project.
During the Newton cycle, we reached the point where we provide enough
artefacts to build OpenStack clients usable on all supported platforms.

As a PTL, my primary focus would be on:
* 3rd party CI: increase coverage and stability so that we can promote
  existing CI to voting gates.  Next step would be allowing other
  projects to consume our packaging for their own CI (mostly installer
  ones)
* better tooling to generate more native packages, and reduce
  churn. Also adding python3 support.
* allowing people to deploy a minimal OpenStack from our
  packages. Rather than focusing on shoving as much services as
  possible, I'd like us to focus on curating a minimal but high
  quality set of packages to build upon it. After such milestone,
  adding more services will be much easier later.

Why? The goal is to produce a production-ready and curated set of
OpenStack packages for all supported RPM-based platforms (SUSE, RHEL,
etc.). Such deliverables could be used to seed downstream
distributions and encourage collaboration between them around
packaging. It would also help OpenStack installers CI to test against
fresh OpenStack packages.


Off course, I plan to continue supporting these ongoing efforts:
* extending our packages set
* extending our contributors pool (including core)
* last but not least, foster collaboration between downstream vendors.

Best regards,
H.

__
OpenStack Development Mailing List (not for 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][requirements] fixing contraints urls in stable/newton

[Nikhil Komawar]

Hi,


There are many reviews pending on Glance's side for the u-c updates [1,
2, 3] given the u-c file for stable/newton doesn't exist yet [4].


However, I have observed that many reviews for u-c have been merged [5].
The former email in this thread says that merge is expected after the
requirements repo is branched.


What's the process around this and validation in process?


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

[2] https://review.openstack.org/#/c/365731/

[3] https://review.openstack.org/365734

[4]
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/newton

[5] https://review.openstack.org/#/q/topic:create-newton



On 9/2/16 5:19 PM, Doug Hellmann wrote:
> We've discovered that the branching script had an overly restrictive
> regex for detecting the URL to the upper contraints file, so some
> repositories that have been branched and that use constraints did not
> receive the update to use the version of the constraints in the
> requirements stable branch.
>
> You'll need to manually create a patch to append "?h=stable/newton"
> to the end of the URL in your tox.ini files in your stable/newton
> branches.
>
> That said, we have not branched the requirements repository, yet, so the
> new URL won't work. We will announce when we've branched the
> requirements repository, so if you want to set up the patch and have it
> ready you will be able to land it quickly after the branch is ready.
>
> 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
>
>


-- 

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] [openstack-ansible] cinder volume lxc and iscsi

[Fabrice Grelaud]

Le 16/09/2016 12:18, Jesse Pretorius a écrit :
>>I found in google a bug for use of open-iscsi inside lxc-container
>>(https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855), a bug
>>commented by Kevin Carter (openstack-ansible core team) as a "blocking
>>issue" (in may 2015).
>>Is that bug still relevant ?
> Yes, unfortunately it is relevant. We implemented clarification patches in 
> Newton to clarify that:
> https://github.com/openstack/openstack-ansible/commit/a06d93daa9c0228abd46b1af462fb00651942b7e
> https://github.com/openstack/openstack-ansible-os_cinder/commit/d8daff7691de60ffc6bcc4faa851d9a90712d556
>
> So the documentation now makes it more clear in the note at the top of the 
> page:
> http://docs.openstack.org/developer/openstack-ansible-os_cinder/configure-cinder.html
Ok. Maybe will be great to backport to Mitaka documentation
(http://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-cinder.html)
>>Do I need to rather deploy my cinder-volume on compute host (metal) to
>>solve my problem ?
> Yes, that is a known good configuration that is very stable.
Indeed. I redeploy cinder-volume on my compute host and everything is
functionnal.
Thanks again.
>
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Fabrice Grelaud
Secteur Infrastructure et Production
DI - Univ. Bordeaux 1
05 40 00 - 65 92
message...@u-bordeaux1.fr


__
OpenStack Development Mailing List (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] Glance stable/newton cut and ready for Ocata; lift your -2s/-Ws

[Nikhil Komawar]

Hi team,


Glance Newton rc1 is available, if you did not get a chance [1]. This
also means that all further Newton specific fixes need to first merge in
master and then backported to stable/newton branch (only stable maint
team has core rights on that branch [2]). The master branch is open for
Ocata development including new features, doc fixes, string fixes, etc.


So, those who haven't already please make it a point to lift up your
(cores') -2s/-Ws [3] blocks on the reviews you've helped stopped during
the Newton-3, RC1 phase or any Newton phase for that matter. This is the
time we need to start evaluating the potential of those reviews for
Ocata cycle.


Please NOTE: If an important (for those concerned) bug/feature is being
asked to move ahead and if the -2/-W by cores are not lifted up by
*EOD-September-19th*, we may encourage the developers to abandon that
review and propose an alternate one. And for all other reviews with
-2/-W by core(s) & are not abandoned, we will wait until
*EOD-September-30th* after which either they will be either abandoned or
the developer will be asked to propose alternative if -2/-W is not
lifted.  So, if you think that your -2/-W still counts (irrespective of
your earlier comment), please comment elaborately *again* on that review
so that everyone can be aware of your stance and help better resolve the
situation for everyone involved.


Thank you for your cooperation.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103827.html

[2] https://review.openstack.org/#/admin/groups/535,members

[3] In some cases, cores have chosen to -W instead of a -2 to block that
patch until a specific release date. This is to help review the patch
and indicate if it's okay to move forward after the release date i.e. a
core may give a +2 to indicate that the patch is technically okay but -W
it, to wait process wise. The block is interpretation based on cores'
opinions so let's not have more opinions/process on how /you/ think the
block should be.

-- 

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] [murano] [all] Ocata Design Summit - Proposed slot allocation

[Thierry Carrez]

Kirill Zaitsev wrote:
> Your email says, that in Murano we have:
> 1 fb 3wr
> 
> This might be an error on my side, because I believe I’ve requested 1 fb
> 1wr in the questionnaire.

Actually you requested 1fb, 1wr and a contributors meetup (if
available). Since we didn't have room left for a Friday afternoon
contributors meetup, I proposed to give you two contiguous workrooms on
Friday morning instead (for a total of 3 wr).

I'll publish that slot allocation ASAP, and you'll be able to let me
know which slots you don't plan to make use of, so that I can put them
back in the available pool.

Cheers,

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Dougal Matthews]

On 15 September 2016 at 10:20, Steven Hardy  wrote:

> Hi all,
>
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
>
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
>
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
>
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
>
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
>
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
>
> 1. Brent Eagles
>
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
>
> 2. Pradeep Kilambi
>
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
>
> 3. Carlos Camacho
>
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the
> transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
>
> 4. Ryan Brady
>
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
>
> 5. Dan Sneddon
>
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
>
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.
>
> Finally, there are quite a few folks doing great work that are not on this
> list, but seem to be well on track towards core status.  Some of those
> folks I've already reached out to, but if you're not nominated now, please
> don't be disheartened, and feel free to chat to me on IRC about it.  Also
> note the following:
>
>  - We need folks to regularly show up, establishing a long-term pattern of
>doing useful reviews, but core status isn't about raw number of reviews,
>it's about consistent downvotes and detailed, well considered and
>insightful feedback that helps increase quality and catch issues early.
>
>  - Try to spend some time reviewing stuff outside your normal area of
>expertise, to build understanding of the broader TripleO system - as
>

Re: [openstack-dev] [release][mistral] mistral Newton RC1 available

[Dougal Matthews]

On 16 September 2016 at 00:06, Doug Hellmann  wrote:

> Hello everyone,
>
> The release candidate for mistral for the end of the Newton cycle
> is available!  You can find the RC1 source code tarballs at:
>
> https://tarballs.openstack.org/mistral/mistral-3.0.0.0rc1.tar.gz
> https://tarballs.openstack.org/mistral-dashboard/mistral-
> dashboard-3.0.0.0rc1.tar.gz
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this RC1 will be formally released as the final
> Newton release on 6 October. You are therefore strongly
> encouraged to test and validate this tarball!
>

I believe we (TripleO) are hitting a release critical issue here:
https://bugs.launchpad.net/mistral/+bug/1624284

I have tagged the issue.


Alternatively, you can directly test the stable/newton release
> branch at:
>
> http://git.openstack.org/cgit/openstack/mistral/log/?h=stable/newton
>
> If you find an issue that could be considered release-critical,
> please file it at:
>
> https://bugs.launchpad.net/mistral/+filebug
>
> and tag it *newton-rc-potential* to bring it to the mistral release
> crew's attention.
>
> Note that the "master" branch of mistral is now open for Ocata
> development, and feature freeze restrictions no longer apply there!
>
> 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
>
__
OpenStack Development Mailing List (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][senlin] Senlin Newton RC1 available

[Thierry Carrez]

Hello everyone,

The release candidate for Senlin for the end of the Newton cycle is
available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/senlin/senlin-2.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final Newton
release on 6 October. You are therefore strongly encouraged to test and
validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/senlin/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/senlin/+filebug

and tag it *newton-rc-potential* to bring it to the senlin release
crew's attention.

Note that the "master" branch of senlin is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,

-- 
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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Christian Berendt]

> On 16 Sep 2016, at 02:06, Steven Dake (stdake)  wrote:
> 
> Welcome to the core review team!

Thank you for being added to the group of core reviewers of Kolla. Looking 
forward to work with all of you.

Christian.

--
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139



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

[openstack-dev] [Rally] PTL candidacy

[Andrey Kurilin]

Hi stackers,

I'm happy to announce my candidacy for Rally PTL for the Ocata release
cycle.

Quick introduction of myself:
 - My contribution to OpenStack started > 2.5 years ago
 - My first commit to Rally was merged ~ 2,5 years ago
 - I became Rally core ~2.3 years ago

My goals for the Ocata cycle:

 - simplify review process of Rally plugins(more democracy!)
 - do regular 3 weeks releases
 - provide up-to-dated release schedule
 - finish validation refactoring to be more flexible
 - port rally verification component to plugin base to support different
verifiers
 - provide subunit output for Rally Task
 - continue work on Rally as a Service
 - make rally certification even more user-friendly and cover more use-cases
 - update docs to cover all aspects of Rally
 - finish work on new entity - hooks, which allow to execute something on
   specified points of scenario execution
 - port all plugins to support Keystone V3 and make V3 as default version
 - provide a way to deliver rally plugins as python packages
 - split Rally Core and OpenStack related plugins into 2 repos
 - nested atomics
 - trends reports for rally verification


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (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][sahara] last minute features in RC1 breaking gate for sahara-dashboard

[Vitaly Gridnev]

Hello teams,

I'd like to inform you that some feature merged and included in RC1 breaks
gate for sahara-dashboard. I did not investigated that deeply, but seems
like it is related to glance client or around. Any help about that is
highly appreciated. So, now I'm trying to understand how to fix that. See
[0] and [1] for results of jobs.

[0] https://review.openstack.org/#/c/371415
[1] https://review.openstack.org/#/c/371279

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

Re: [openstack-dev] [openstack-ansible] cinder volume lxc and iscsi

[Jesse Pretorius]

>I found in google a bug for use of open-iscsi inside lxc-container
>(https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855), a bug
>commented by Kevin Carter (openstack-ansible core team) as a "blocking
>issue" (in may 2015).
>Is that bug still relevant ?

Yes, unfortunately it is relevant. We implemented clarification patches in 
Newton to clarify that:
https://github.com/openstack/openstack-ansible/commit/a06d93daa9c0228abd46b1af462fb00651942b7e
https://github.com/openstack/openstack-ansible-os_cinder/commit/d8daff7691de60ffc6bcc4faa851d9a90712d556

So the documentation now makes it more clear in the note at the top of the page:
http://docs.openstack.org/developer/openstack-ansible-os_cinder/configure-cinder.html

>Do I need to rather deploy my cinder-volume on compute host (metal) to
>solve my problem ?

Yes, that is a known good configuration that is very stable.




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for 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] PTL non candidacy

[Igor Marnat]

Vladimir, fuelers,
very impressive list of achievements for 1 release cycle. Good work, folks!

Regards,
Igor Marnat

On Tue, Sep 13, 2016 at 1:02 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> Newton cycle is getting to its end and it is time to look at what we've
> managed to achieve by the moment.
>
> * Improved task based deployment engine (memory efficiency, code
>   structure, graph sequences, noop run).
> * Re-implemented OS provisioning as a graph. Now it is one of the graphs in
>   the default deployment graph sequence.
> * Improved graph API and UX. Now it is possible to upload/download
>   custom graphs, run particular graphs, see per-task deployment
>   progress.
> * Aligned the functionality of the new version of fuelclient with the
>   old one. Now all subcommands are available in `fuel2` and we are ready
>   to deprecate old `fuel` command.
> * We are on our way to get rid of ISO. (ISOless BVT is ready, review
>   jobs are in progress).
> * Improved LCM UX including IaC (using git repository as a source for
>   cluster configuration).
> * We begun implementing cluster upgrade procedure as a graph. In the
>   future in-place OpenStack cluster upgrades will be a native part Fuel
>   functionality.
> * We also put some efforts to research container based deployment
>   possibilities (K8s and Docker). We introduced a bunch of
>   experimental repositories (fuel-ccp-*) where the team is now working
>   on CI/CD like UX for containerized OpenStack deployment.
>
> There are also many things that we were planning but didn't manage
> to do. I'm not going to nominate myself as a PTL for Ocata cycle, but I'll
> continue to contribute to Fuel to make it a perfect deployment
> tool and I'm looking forward for other Fuel team members to run for PTL
> role.
>
> Thanks.
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (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] [horizon] Question on a singular/plural string use in openstack_dashboard

[Ian Y. Choi]

Hello,

Recently, thanks to the help from Andreas, I am investigating on a 
broken job

for the translation import of Horizon project [1].
The actual error message is
: openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format 
specification for argument 'req' doesn't exist in 'msgstr[0]'


And then I have found that this error was from a string in horizon - 
openstack_dashboard [2]


error_message = ungettext_lazy(
'The requested instance cannot be launched as you only '
'have %(avail)i of your quota available. ',
'The requested %(req)i instances cannot be launched as 
you '

'only have %(avail)i of your quota available.',
count)
params = {'req': count,
  'avail': available_count}

In i18n translation infrastructure, only one of two (for singular and 
plural) strings should be
selected, translated, saved, and finally imported back to Horizon 
project as [1].

However, the first string only used "%(avail)i" string variable,
and the second string used both "%(req)i" and "%(avail)i" string variables.

Since one Korean translator selected the first string, there will be no 
"%(req)i" in Korean po file, which generates such an error.
So my suggestion is to use the same string variables for both two 
strings when we use ungettext_lazy function.


Is it a bug from Horizon? Would it be other issues when we change like
: from 'The requested instance cannot be launched as you only ' to 'The 
requested %(req)i instance cannot be launched as you only '?



[1] 
http://logs.openstack.org/periodic/horizon-propose-translation-update/c038aab/console.html#_2016-09-16_07_37_22_312092
[2] 
http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#n214



With many thanks,

/Ian

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

Re: [openstack-dev] [TripleO] TripleO Core nominations

[Giulio Fidente]

On 09/15/2016 11:20 AM, Steven Hardy wrote:

Hi all,

As we work to finish the last remaining tasks for Newton, it's a good time
to look back over the cycle, and recognize the excellent work done by
several new contributors.

We've seen a different contributor pattern develop recently, where many
folks are subsystem experts and mostly focus on a particular project or
area of functionality.  I think this is a good thing, and it's hopefully
going to allow our community to scale more effectively over time (and it
fits pretty nicely with our new composable/modular architecture).

We do still need folks who can review with the entire TripleO architecture
in mind, but I'm very confident folks will start out as subsystem experts
and over time broaden their area of experience to encompass more of
the TripleO projects (we're already starting to see this IMO).

We've had some discussion in the past[1] about strictly defining subteams,
vs just adding folks to tripleo-core and expecting good judgement to be
used (e.g only approve/+2 stuff you're familiar with - and note that it's
totally fine for a core reviewer to continue to +1 things if the patch
looks OK but is outside their area of experience).

So, I'm in favor of continuing that pattern and just welcoming some of our
subsystem expert friends to tripleo-core, let me know if folks feel
strongly otherwise :)

The nominations, are based partly on the stats[2] and partly on my own
experience looking at reviews, patches and IRC discussion with these folks
- I've included details of the subsystems I expect these folks to focus
their +2A power on (at least initially):

1. Brent Eagles

Brent has been doing some excellent work mostly related to Neutron this
cycle - his reviews have been increasingly detailed, and show a solid
understanding of our composable services architecture.  He's also provided
a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
Brent continues this exellent Neutron focussed work, while also expanding
his review focus such as the good feedback he's been providing on new
Mistral actions in tripleo-common for custom-roles.

2. Pradeep Kilambi

Pradeep has done a large amount of pretty complex work around Ceilomenter
and Aodh over the last two cycles - he's dealt with some pretty tough
challenges around upgrades and has consistently provided good review
feedback and solid analysis via discussion on IRC.  I propose Prad
continues this excellent Ceilomenter/Aodh focussed work, while also
expanding review focus aiming to cover more of t-h-t and other repos over
time.

3. Carlos Camacho

Carlos has been mostly focussed on composability, and has done a great job
of working through the initial architecture implementation, including
writing some very detailed initial docs[3] to help folks make the transition
to the new architecture.  I'd suggest that Carlos looks to maintain this
focus on composable services, while also building depth of reviews in other
repos.

4. Ryan Brady

Ryan has been one of the main contributors implementing the new Mistral
based API in tripleo-common.  His reviews, patches and IRC discussion have
consistently demonstrated that he's an expert on the mistral
actions/workflows and I think it makes sense for him to help with review
velocity in this area, and also look to help with those subsystems
interacting with the API such as tripleoclient.

5. Dan Sneddon

For many cycles, Dan has been driving direction around our network
architecture, and he's been consistently doing a relatively small number of
very high-quality and insightful reviews on both os-net-config and the
network templates for tripleo-heat-templates.  I'd suggest Dan continues
this focus, and he's indicated he may have more bandwidth to help with
reviews around networking in future.

Please can I get feedback from exisitng core reviewers - you're free to +1
these nominations (or abstain), but any -1 will veto the process.  I'll
wait one week, and if we have consensus add the above folks to
tripleo-core.


+1

espcially in this project, diversification is a strategy!


 - We need folks to regularly show up, establishing a long-term pattern of
   doing useful reviews, but core status isn't about raw number of reviews,
   it's about consistent downvotes and detailed, well considered and
   insightful feedback that helps increase quality and catch issues early.

 - Try to spend some time reviewing stuff outside your normal area of
   expertise, to build understanding of the broader TripleO system - as
   discussed above subsystem experts are a good thing, but we also need
   to see some appreciation of the broader Tripleo archticture &
   interfaces (all the folks above have demonstrated solid knowledge of one
   or more of our primary interfaces, e.g the Heat or the Mistral layer)


thanks for sharing these ^^
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente

__
OpenStack 

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

[Julien Danjou]

On Fri, Sep 16 2016, Sam Morrison wrote:

Hi Sam,

> Been working a bit on this and have a patch based on master that is
> working at:
>
> https://github.com/NeCTAR-RC/gnocchi/tree/influxdb-driver

Great!

> I could push it up to gerrit but I think something will need to change
> for it to run the influxdb tests?

You can use pifpaf like we do for the indexer, InfluxDB is supported.
That should make it possible to run the unit tests in the gate right
away.

As for the functional tests, you can set up support via devstack and
we wouldhad a job in infra.

> It should act more like the carbonara drivers now as opposed to the
> old influx driver. It will do downsampling and retention based on the
> archive policies.

That's great, and I imagine it'd be faster than doing it on the fly like
previously.

> Currently it is failing one test [1] and that is to do with retention. 
> This is because influxDB does retention based on the current time, e.g. a 1 
> day retention policy will be from the current time. 
> The tests assume that the retention period is based on the data stored and so 
> it will keep 1 day of data no matter how old that data is.

lol, yeah the test assume it's a database that does not block you to
insert things as you want. I feel like that being a bad and funny design
decision (Whisper has the same defect).

> I also had to disable retention policies in influx while running the tests as
> when I backfill data influx is too smart and won’t backfill data that wouldn’t
> meet the retention policy.

I imagine that's because some of our tests are using date in year e.g.
2014? :)

> One way to fix all this would be to change all the test times to be
> relative from now but then there could be other race conditions etc. I
> think.

Completely, imagine if the test takes 1 month to run, it would fail
anyway. ;-) It's completely hypothetical and unrealaistic of course, but
in principle I think it's better if we can keep things the way they are.

> I’m still not 100% happy with the code, particularly around how the
> continuous queries are created based on the archive policies.
>
> We are using this code in preprod and so far all is going well. 

Great. Do you have performance numbers, scalability, or things that are
different/better/worse than using Carbonara based drivers?

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


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

[openstack-dev] [neutron][LBaaS v2]Quota Update for LBaaS v2 Members

[reedip banerjee]

Hi All,

Currently OpenstackClient and NeutronClient supports updating the quota for
LBaaS v2 members.
However, the quota API does not seem to support it.[1]

I would just like to get this information cleared whether we actually allow
updating the quotas for LBaaSv2 Members??

[1]: https://bugs.launchpad.net/python-openstackclient/+bug/1624097

-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing List (not for 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] CI is currently down: 2 blockers

[Dougal Matthews]

For those interested we now have a minimal way to reproduce the
MessagingTimeout in Mistral.

https://bugs.launchpad.net/mistral/+bug/1624284

It seems to be related to this change in Mistral:


https://github.com/openstack/mistral/commit/1b0f0cddd620a3785017bb28d432cb0030b627d7

And even more specifically, this line:


https://github.com/openstack/mistral/commit/1b0f0cddd620a3785017bb28d432cb0030b627d7#diff-fa1c08d9053a1e6736fb8ac64e51d1ab

Thomas Herve managed to work around it by changing the executor.


On 16 September 2016 at 01:19, Emilien Macchi  wrote:

> So here's an update about current situation:
>
> Master / Newton
> gate-tripleo-ci-centos-7-ovb-nonha
> gate-tripleo-ci-centos-7-ovb-ha
> The 2 jobs are supposed to pass, but some jobs are timing out in RH1 cloud.
> In order to reduce the timeouts, Ben ran:
> heat-manage purge_deleted 3
> nova-manage db archive_deleted_rows --verbose --max_rows 100
> sudo mysqlcheck -o -A
>
> gate-tripleo-ci-centos-7-nonha-multinode
> We merged the revert: https://review.openstack.org/#/c/370250/
> At the time I'm writing this email, the job is still non-voting:
> https://review.openstack.org/#/c/371133/
> But hopefully Infra will merge this patch soon to bring it back in the
> gate.
>
>
> stable/mitaka and stable/liberty
> gate-tripleo-ci-centos-7-ovb-nonha works fine.
> gate-tripleo-ci-centos-7-ovb-ha is broken because Galera was updated
> in EPEL (and TripleO Mitaka still deploys EPEL).
> I have 2 patches in order to fix the situation:
> 1) Fix Galera configuration to work with recent EPEL (kudos to Damien
> for his help): https://review.openstack.org/#/c/371029/
> 2) (not required but good to have) Disable EPEL in tripleoclient
> https://review.openstack.org/#/c/369559/ - I would understand if
> people -1 this patch and I have no strong opinion about it.
>
> I hope 1) will pass CI so we can just move forward.
>
> It's end of day for me but if someone can monitor
> http://tripleo.org/cistatus.html during Friday morning and make sure
> everything it still running fine, we would appreciate it. Also please
> report any bug related to CI and set the ci & alert tags.
>
> Thanks, and let's keep focusing on Newton release!
>
> On Thu, Sep 15, 2016 at 11:26 AM, Emilien Macchi 
> wrote:
> > On Wed, Sep 14, 2016 at 10:13 PM, Emilien Macchi 
> wrote:
> >> Hi,
> >>
> >> Just a heads-up before end of day:
> >>
> >> 1) multinode job is failing 80% of time. James and myself did some
> >> attempts to revert or fix things but we have been unfortunate until
> >> now.
> >> Everything is documented here: https://bugs.launchpad.net/
> tripleo/+bug/1623606
> >
> > We found out that https://review.openstack.org/#/c/368760/ is breaking
> > us, so we will revert it and work on it again later.
> >
> >> 2) ovb jobs are timeing out during NetworkDeployment because
> >> 99-refresh-completed is not signaling to Heat due to instance-id being
> >> detected as null by os-apply-config.
> >> James proposed a revert: https://review.openstack.org/#/c/370250/
> >> But the patch can't be merged because of 1).
> >
> > We are going to merge James's revert, we think it will bring back OVB
> jobs.
> >
> > To merge the reverts, we need to disable voting on multinode jobs:
> > https://review.openstack.org/#/c/370922/
> >
> > Please do not merge anything today (except the 2 reverts) until our
> > situation becomes more stable. Probably tonight or tomorrow.
> > Once situation is better, I or someone else in the team will give an
> > update here.
> >
> > Thanks for your understanding,
> >
> >> I'll continue to work on it tomorrow but if you're able to jump in and
> >> make progress on it, this downtime is very critical at this stage of
> >> the cycle.
> >>
> >> Any help is highly welcome.
> >>
> >> Thanks,
> >> --
> >> 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 Development Mailing List (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][horizon] Horizon Newton RC1 available

[Thierry Carrez]

Hello everyone,

The release candidate for Horizon for the end of the Newton cycle is
available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/horizon/horizon-10.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final Newton
release on 6 October. You are therefore strongly encouraged to test and
validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/horizon/+filebug

and tag it *newton-rc-potential* to bring it to the horizon release
crew's attention.

Note that the "master" branch of horizon is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [charms] bug squash day - Thursday 22nd September

[James Page]

Hi Team

We running up towards feature freeze on the 29th of September for our charm
release mid October.

So that we have an accurate view of bugs across the OpenStack Charms in
advance of that date, I'm proposing we have a bug day next Thursday (22nd
September).

Anyone is welcome to participate - we'll co-ordinate via the
#openstack-charms IRC channel - objective for the day is a) triage new
untouched bugs b) re-touch on any outstanding bugs and c) squash as many as
possible on the day!

This view is probably the best way to find bug work:

  https://bugs.launchpad.net/~openstack-charmers/+packagebugs

Looking forward to squashing as many bugs as possible!

Cheers

James
__
OpenStack Development Mailing List (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][nova] Nova Newton RC1 available

[Thierry Carrez]

Hello everyone,

The release candidate for Nova for the end of the Newton cycle is
available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/nova/nova-14.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final Newton
release on 6 October. You are therefore strongly encouraged to test and
validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/nova/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/nova/+filebug

and tag it *newton-rc-potential* to bring it to the nova release
crew's attention.

Note that the "master" branch of nova is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [release][glance] Glance Newton RC1 available

[Thierry Carrez]

Hello everyone,

The release candidate for Glance for the end of the Newton cycle is
available!  You can find the RC1 source code tarball at:

https://tarballs.openstack.org/glance/glance-13.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final Newton
release on 6 October. You are therefore strongly encouraged to test and
validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/glance/log/?h=stable/newton

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/glance/+filebug

and tag it *newton-rc-potential* to bring it to the glance release
crew's attention.

Note that the "master" branch of glance is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [release][zaqar] Zaqar Newton RC1 available

[Thierry Carrez]

Hello everyone,

The release candidate for Zaqar (and zaqar-ui) for the end of the Newton
cycle is available!  You can find the RC1 source code tarballs at:

https://tarballs.openstack.org/zaqar/zaqar-3.0.0.0rc1.tar.gz
https://tarballs.openstack.org/zaqar-ui/zaqar-ui-1.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, these RC1s will be formally released as the final
Newton release on 6 October. You are therefore strongly encouraged to
test and validate these tarballs!

Alternatively, you can directly test the stable/newton release branches at:

http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/newton
http://git.openstack.org/cgit/openstack/zaqar-ui/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/zaqar/+filebug

and tag it *newton-rc-potential* to bring it to the zaqar release
crew's attention.

Note that the "master" branches of zaqar and zaqar-ui are now open for
Ocata development, and feature freeze restrictions no longer apply there!

Thanks,

-- 
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] [TripleO] TripleO Core nominations

[Marios Andreou]

On 15/09/16 12:20, Steven Hardy wrote:
> Hi all,
> 
> As we work to finish the last remaining tasks for Newton, it's a good time
> to look back over the cycle, and recognize the excellent work done by
> several new contributors.
> 
> We've seen a different contributor pattern develop recently, where many
> folks are subsystem experts and mostly focus on a particular project or
> area of functionality.  I think this is a good thing, and it's hopefully
> going to allow our community to scale more effectively over time (and it
> fits pretty nicely with our new composable/modular architecture).
> 
> We do still need folks who can review with the entire TripleO architecture
> in mind, but I'm very confident folks will start out as subsystem experts
> and over time broaden their area of experience to encompass more of
> the TripleO projects (we're already starting to see this IMO).
> 
> We've had some discussion in the past[1] about strictly defining subteams,
> vs just adding folks to tripleo-core and expecting good judgement to be
> used (e.g only approve/+2 stuff you're familiar with - and note that it's
> totally fine for a core reviewer to continue to +1 things if the patch
> looks OK but is outside their area of experience).
> 
> So, I'm in favor of continuing that pattern and just welcoming some of our
> subsystem expert friends to tripleo-core, let me know if folks feel
> strongly otherwise :)
> 
> The nominations, are based partly on the stats[2] and partly on my own
> experience looking at reviews, patches and IRC discussion with these folks
> - I've included details of the subsystems I expect these folks to focus
> their +2A power on (at least initially):
> 
> 1. Brent Eagles
> 
> Brent has been doing some excellent work mostly related to Neutron this
> cycle - his reviews have been increasingly detailed, and show a solid
> understanding of our composable services architecture.  He's also provided
> a lot of valuable feedback on specs such as dpdk and sr-iov.  I propose
> Brent continues this exellent Neutron focussed work, while also expanding
> his review focus such as the good feedback he's been providing on new
> Mistral actions in tripleo-common for custom-roles.
> 
> 2. Pradeep Kilambi
> 
> Pradeep has done a large amount of pretty complex work around Ceilomenter
> and Aodh over the last two cycles - he's dealt with some pretty tough
> challenges around upgrades and has consistently provided good review
> feedback and solid analysis via discussion on IRC.  I propose Prad
> continues this excellent Ceilomenter/Aodh focussed work, while also
> expanding review focus aiming to cover more of t-h-t and other repos over
> time.
> 
> 3. Carlos Camacho
> 
> Carlos has been mostly focussed on composability, and has done a great job
> of working through the initial architecture implementation, including
> writing some very detailed initial docs[3] to help folks make the transition
> to the new architecture.  I'd suggest that Carlos looks to maintain this
> focus on composable services, while also building depth of reviews in other
> repos.
> 
> 4. Ryan Brady
> 
> Ryan has been one of the main contributors implementing the new Mistral
> based API in tripleo-common.  His reviews, patches and IRC discussion have
> consistently demonstrated that he's an expert on the mistral
> actions/workflows and I think it makes sense for him to help with review
> velocity in this area, and also look to help with those subsystems
> interacting with the API such as tripleoclient.
> 
> 5. Dan Sneddon
> 
> For many cycles, Dan has been driving direction around our network
> architecture, and he's been consistently doing a relatively small number of
> very high-quality and insightful reviews on both os-net-config and the
> network templates for tripleo-heat-templates.  I'd suggest Dan continues
> this focus, and he's indicated he may have more bandwidth to help with
> reviews around networking in future.
> 
> Please can I get feedback from exisitng core reviewers - you're free to +1
> these nominations (or abstain), but any -1 will veto the process.  I'll
> wait one week, and if we have consensus add the above folks to
> tripleo-core.

+1 from me - haven't worked directly with everyone on the list but I
have been witness to excellent contributions both in code and review
comments from all*

thanks, marios



* fwiw - @beagles I first noticed with the excellent reviews and
comments when folks started moving the neutron to composable,
@pradk from the ceilo/aodh work, @camacho - too many things to mention
;), @rbrady from the mistral/tripleocommon/client work, and @dsneddon
has been a long time contributor and as shardy said wrote the initial
network reference architecture and did a lot of the implementation for
'network isolation' in tripleo.



> 
> Finally, there are quite a few folks doing great work that are not on this
> list, but seem to be well on track towards core status.  Some of those
> folks I've already reached out 

Re: [openstack-dev] Spain Visa for Indian contributors

[M Ranga Swami Reddy]

That's good...

Thanks
Swami

On Thu, Sep 15, 2016 at 10:59 PM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi All,
>
> I have got invitation letter in spanish.
> Those who requires this letter in spanish, send mail to
> eventv...@openstack.org mentioning the same.
>
> Thanks to OpenStack foundation.
>
> Cheers,
>
> Abhishek
> 
> From: Gorka Eguileor Gimeno [gegui...@redhat.com]
> Sent: Thursday, September 15, 2016 9:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> Hi,
>
> As a native Spanish speaker I offer my help with the translation if needed.
> I assume the OpenStack visa team would be the one required to issue the
> translated invitation letter for it to be valid.
>
> Cheers,
> Gorka.
>
> On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy  > wrote:
> Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
> ==
> For business visas:
> □ Invitation letter from the Spanish company in Spanish language or both
> in English and Spanish.Letters issued only in English will not be accepted.
> This will be an obligatory requirement.
> ===
>
> On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy  > wrote:
> That's good. Please share the appropriate link/url to openstack visa team.
>
> On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> Hi,
>
> Yes it’s request from embassy than for Indian citizens invitation letter
> should be in Spanish as well English language.
> I have sent mail to openstack visa team.
>
> Thank you,
>
> Abhishek Kekane
>
> From: M Ranga Swami Reddy [mailto:swamire...@gmail.com swamire...@gmail.com>]
> Sent: Thursday, September 15, 2016 1:06 PM
>
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> Hi,
> Who asked the invitation letter in Spanish? Is it embassy, please share
> the same info openstack visa team.
>
> JYI - for Tokyo - invitation letter was in Japanese only.
>
> Thanks
> Swami
>
> On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> Hi Janki,
>
> I will keep you posted about this. Mean time sent mail to ‘
> eventv...@openstack.org’ to explain your
> issue and also give reference of this ML.
>
> Thank you,
>
> Abhishek Kekane
>
> From: Janki Chhatbar [mailto:jankih...@gmail.com jankih...@gmail.com>]
> Sent: Thursday, September 15, 2016 11:51 AM
>
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> Hi Abhishek
> I am Janki. I am applying for visa from India. I haven't applied yet but a
> friend of mine is facing the same issue of needing an invitation letter in
> Spanish.
> May be everyone applying from India can request to have the letter in
> Spanish too.
> Let me know how you proceed further. It would help me while applying.
> Thanks
> Janki
>
> On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> Hi John,
>
> I have sent mail to 'eventv...@openstack.org eventv...@openstack.org>', waiting for positive reply.
>
> One reply I got from Kendall is,
>
> We only send the letter in English. No one else applying for a visa has
> had a problem getting their visa with just the English letter so the letter
> you received should be sufficient.
>
> I will show this reply mail at VFS center and hopefully they will take no
> objection about this.
>
> Thank you for your time,
>
> Abhishek Kekane
>
> -Original Message-
> From: John Villalovos [mailto:openstack@sodarock.com o...@sodarock.com>]
> Sent: Thursday, September 15, 2016 11:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Spain Visa for Indian contributors
>
> On that page they seem to list a contact email:
>
> eventv...@openstack.org
>
> Hopefully they can help with the issue.
>
> John
>
> On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
> abhishek.kek...@nttdata.com> wrote:
> > Hi John,
> >
> > I have read the information given at
> > https://www.openstack.org/summit/barcelona-2016/travel/#visa
> > and got the invitation letter but it's in English language. Problem is
> that Visa centers in India are demanding this invitation letter in English
> as well as Spanish language.
> >
> > Thank you,
> >
> > Abhishek Kekane
> >
> > -Original Message-
> > From: John Villalovos [mailto:openstack@sodarock.com openstack@sodarock.com>]
> > Sent: Thursday, September 15, 2016 9:45 AM
> > To: 

Re: [openstack-dev] Spain Visa for Indian contributors

[M Ranga Swami Reddy]

Thank you. Will contact you if required any help here.

Thanks
Swami

On Thu, Sep 15, 2016 at 7:05 PM, Gorka Eguileor Gimeno 
wrote:

> Hi,
>
> As a native Spanish speaker I offer my help with the translation if needed.
> I assume the OpenStack visa team would be the one required to issue the
> translated invitation letter for it to be valid.
>
> Cheers,
> Gorka.
>
> On Thu, Sep 15, 2016 at 2:14 PM, M Ranga Swami Reddy  > wrote:
>
>> Page#2:  http://www.vfsglobal.com/spain/india/pdf/Spain-Checklist.pdf
>> ==
>> For business visas:
>> □ Invitation letter from the Spanish company in Spanish language or both
>> in English and Spanish.Letters issued only in English will not be
>> accepted. This will be an obligatory requirement.
>> ===
>>
>> On Thu, Sep 15, 2016 at 3:35 PM, M Ranga Swami Reddy <
>> swamire...@gmail.com> wrote:
>>
>>> That's good. Please share the appropriate link/url to openstack visa
>>> team.
>>>
>>> On Thu, Sep 15, 2016 at 1:14 PM, Kekane, Abhishek <
>>> abhishek.kek...@nttdata.com> wrote:
>>>
 Hi,



 Yes it’s request from embassy than for Indian citizens invitation
 letter should be in Spanish as well English language.

 I have sent mail to openstack visa team.



 Thank you,



 Abhishek Kekane



 *From:* M Ranga Swami Reddy [mailto:swamire...@gmail.com]
 *Sent:* Thursday, September 15, 2016 1:06 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Spain Visa for Indian contributors



 Hi,

 Who asked the invitation letter in Spanish? Is it embassy, please share
 the same info openstack visa team.



 JYI - for Tokyo - invitation letter was in Japanese only.



 Thanks

 Swami



 On Thu, Sep 15, 2016 at 11:58 AM, Kekane, Abhishek <
 abhishek.kek...@nttdata.com> wrote:

 Hi Janki,



 I will keep you posted about this. Mean time sent mail to ‘
 eventv...@openstack.org’ to explain your issue and also give reference
 of this ML.



 Thank you,



 Abhishek Kekane



 *From:* Janki Chhatbar [mailto:jankih...@gmail.com]
 *Sent:* Thursday, September 15, 2016 11:51 AM


 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Spain Visa for Indian contributors



 Hi Abhishek

 I am Janki. I am applying for visa from India. I haven't applied yet
 but a friend of mine is facing the same issue of needing an invitation
 letter in Spanish.

 May be everyone applying from India can request to have the letter in
 Spanish too.

 Let me know how you proceed further. It would help me while applying.

 Thanks

 Janki



 On Thu, Sep 15, 2016 at 11:30 AM, Kekane, Abhishek <
 abhishek.kek...@nttdata.com> wrote:

 Hi John,

 I have sent mail to 'eventv...@openstack.org', waiting for positive
 reply.

 One reply I got from Kendall is,

 We only send the letter in English. No one else applying for a visa has
 had a problem getting their visa with just the English letter so the letter
 you received should be sufficient.

 I will show this reply mail at VFS center and hopefully they will take
 no objection about this.

 Thank you for your time,

 Abhishek Kekane

 -Original Message-
 From: John Villalovos [mailto:openstack@sodarock.com]

 Sent: Thursday, September 15, 2016 11:17 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Spain Visa for Indian contributors

 On that page they seem to list a contact email:

 eventv...@openstack.org

 Hopefully they can help with the issue.

 John

 On Wed, Sep 14, 2016 at 9:24 PM, Kekane, Abhishek <
 abhishek.kek...@nttdata.com> wrote:
 > Hi John,
 >
 > I have read the information given at
 > https://www.openstack.org/summit/barcelona-2016/travel/#visa
 > and got the invitation letter but it's in English language. Problem
 is that Visa centers in India are demanding this invitation letter in
 English as well as Spanish language.
 >
 > Thank you,
 >
 > Abhishek Kekane
 >
 > -Original Message-
 > From: John Villalovos [mailto:openstack@sodarock.com]
 > Sent: Thursday, September 15, 2016 9:45 AM
 > To: OpenStack Development Mailing List (not for usage questions)
 > Subject: Re: [openstack-dev] Spain Visa for Indian contributors
 >
 > There is information on the Visa process at:
 > https://www.openstack.org/summit/barcelona-2016/travel/#visa
 >
 > Not sure if you have