date:20180131

On 2018-02-01 05:49, Takashi Yamamoto wrote:
> [...]
>> * Don't create your own versions of these changes.  My script will
>>   eventually upload changes to all affected project-branches.  It's
>>   intentionally a slow process, and attempting to speed it up won't
>>   help.  But if there's something wrong with the change I propose, feel
>>   free to push an update to correct it.
> 1. is it ok to create my version of the change when making other
> changes to the file?  eg. https://review.openstack.org/#/c/538200/


If you add a *new* zuul.yaml file, do not add the project name stanza.
His scripts will not catch new additions.

If you change an existing file, wait for Jim's change.

> 2. as a reviewer, what should i do to the similar changes which is not yours?
> https://review.openstack.org/#/q/topic:zuulv3-projects+NOT+owner:%22James+E.+Blair+%253Ccorvus%2540inaugust.com%253E%22

I would block any new ones with a reference to the message. There's
really no sense in doing those changes and cause extra work,

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


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

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

On 2018-01-31 22:58, Akihiro Motoki wrote:
> I don't think we need to drop translation support NOW (at least for
> neutron-lbaas-dashboard).
> There might be fixes which affects translation and/or there might be
> translation improvements.
> I don't think a deprecation means no translation fix any more. It
> sounds too aggressive.
> Is there any problem to keep translations for them?

Reading the whole FAQ - since bug fixes are planned, translations can
merge back. So, indeed we can keep translation infrastructure set up.

I recommend to translators to remove neutron-lbaas-dashboard from the
priority list,

Andreas

> Akihiro
> 
> 2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
>> In that case, I suggest to remove translation jobs for these repositories,
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


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

[openstack-dev] [Karbor] [ptl] PTL candidacy for Rocky

2018-01-31 Thread Chen Ying

Hi all,

I would like to nominate myself to be the Karbor PTL for the Rocky cycle.

I began to contribute to Karbor project since 2016.01, as a core reviewer
from Newton cycle, and as Karbor PTL for the Queens cycle. It is my pleasure
to work with the great team to make this project better and better.

In Queens we have done a lot of great works about OpenStack resources
protection
in karbor: API support the checkpoint verification. Support quotas. Support
checkpoint cross AZ copy API. Cross-site backup and restore. Support freezer
protection plugin. Support K8S pods protection integration. Implement
policies
in code.
Other achievements are: Support operation log api. Support API json schema
validation. Support service management API and so on.

For the next cycle I'd like to focus on the tasks as follows:

- Grow the Karbor team of contributors
- Cross projects integration and improvement
- Make project goals. Also following community goals and project goals to
make
  sure it will complete.
- Usability: documentation, karbor client and Karbor Horizon. Ensure Karbor
  Horizon and client continue to be a robust and easy-to-use tool for
Karbor.

If you have any ideas on these points we're always happy to discuss and
correct our plans.

We're always happy to get new contributors on the project and always ready
to help people interested in Karbor development get up to speed. I'm excited
to continue contributing to Karbor.

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

[openstack-dev] [requirements][ptl] Announcing my candidacy for PTL of the requirements project

2018-01-31 Thread Matthew Thode

I would like to announce my candidacy for PTL of the Requirements project for
the Rocky cycle.

The following will be my goals for the cycle, in order of importance:

1. The primary goal is to keep a tight rein on global-requirements and
upper-constraints updates.

2. Speaking of global-requirements updates, the primary goal this cycle will
continue to work on project specific requirements.  All projects would continue
to use upper-constraints.txt to ensure co-installability, but would be able to
manage their requirements.txt file, largely on their own.

https://bugs.launchpad.net/openstack-requirements/+bug/1719009 is the bug
tracking per-project requirements.

3. Un-cap requirements where possible (stuff like eventlet).

4. Publish constraints and requirements to streamline the freeze process.

https://bugs.launchpad.net/openstack-requirements/+bug/1719006 is the bug
tracking the publish job.

5. Audit global-requirements and upper-constraints for redundancies.  One of
the rules we have for new entrants to global-requirements and/or
upper-constraints is that they be non-redundant.  Keeping that rule in mind,
audit the list of requirements for possible redundancies and if possible,
reduce the number of requirements we manage.

6.  Audit global-requirements minimums.  While technically not supported from a
co-installability or stability standpoint (as it's not tested), we should
endeavor to have the global-requirements minimums work in Openstack.  Ensuring
any bugs, features or changes that have happened since the global-requirements
minimum was released til the upper-constraints was defined are not NEEDED by
Openstack.  This will rely on the cross gating work tonyb did.

I look forward to continue working with you in this cycle, as your PTL or not.

Thanks for your time,
Matthew Thode

IRC: prometheanfire

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [all][infra] Automatically generated Zuul changes (topic: zuulv3-projects)

2018-01-31 Thread Takashi Yamamoto

On Thu, Feb 1, 2018 at 2:59 AM, James E. Blair  wrote:
> Hi,
>
> Occasionally we will make changes to the Zuul configuration language.
> Usually these changes will be backwards compatible, but whether they are
> or not, we still want to move things forward.
>
> Because Zuul's configuration is now spread across many repositories, it
> may take many changes to do this.  I'm in the process of making one such
> change now.
>
> Zuul no longer requires the project name in the "project:" stanza for
> in-repo configuration.  Removing it makes it easier to fork or rename a
> project.
>
> I am using a script to create and upload these changes.  Because changes
> to Zuul's configuration use more resources, I, and the rest of the infra
> team, are carefully monitoring this and pacing changes so as not to
> overwhelm the system.  This is a limitation we'd like to address in the
> future, but we have to live with now.
>
> So if you see such a change to your project (the topic will be
> "zuulv3-projects"), please observe the following:
>
> * Go ahead and approve it as soon as possible.
>
> * Don't be strict about backported change ids.  These changes are only
>   to Zuul config files, the stable backport policy was not intended to
>   apply to things like this.
>
> * Don't create your own versions of these changes.  My script will
>   eventually upload changes to all affected project-branches.  It's
>   intentionally a slow process, and attempting to speed it up won't
>   help.  But if there's something wrong with the change I propose, feel
>   free to push an update to correct it.

1. is it ok to create my version of the change when making other
changes to the file?  eg. https://review.openstack.org/#/c/538200/

2. as a reviewer, what should i do to the similar changes which is not yours?
https://review.openstack.org/#/q/topic:zuulv3-projects+NOT+owner:%22James+E.+Blair+%253Ccorvus%2540inaugust.com%253E%22

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

__
OpenStack Development Mailing List (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] [cyborg][ptl]PTL Candidacy for Rocky

2018-01-31 Thread Zhipeng Huang

Hi Team,

I would like to express my interest in continuing to serve as PTL of Cyborg
project for Rocky release.

I know we have been in a fanatic state for our first release preparation,
but when I looked back to the early days when nomad (cyborg's prelife)
project kicks off, I feel I'm blessed to be able to work with such a great
community and a great dev team, to get where we are now.

We took it in our pride that cyborg is one of the few project that is grown
entirely in the OpenStack community from the very beginning: no vendor code
dump, design discussion from scratch, write every bit of code from zero.
Heck we even changed the project name based upon team voting/consensus.

I have to admit I also had doubt on how a project like cyborg will really
survive, given that we rely so heavily on community effort rather than
single vendor human resource investment which is often guaranteed. And also
the problem that we are such a young team that none of us  is veteran
OpenStacker. I'm then hugely encouraged and fascinated by how far we are
able to get.

For Pike, the three core members from three different companies came up
with the basic framework. And for Queens, with more devs joining we will
pulled of *our own first implementation of the nested resource provider*, *a
basic interaction framework between cyborg-conductor and nova-placement*, *a
generic driver that will be a reference implementation for vendor drivers*,*
Intel FPGA driver* (our first vendor driver !), *SPDK driver *(the first
software accelerator driver !), *cyborg-agent resource tracker*, and so on
and so forth. I can't really ask more from this amazing team.

Moreover for the First Contact SIG initiative, we also established a
vibrant Cyborg China Dev community via Wechat group and  held many ad-hoc
meetings. This effort has helped tremendously on our Queens delivery in the
making. We also joined with Nova team to kickoff the Resource Management
SIG which will help align the resource data modeling across OpenStack and
other related open source communities.

With Queens release work still lingering around, the plan for Rocky was
actually bounced over several times during team discussion, and here are
the items that in my mind are important target:
(1) Adopt MS based development cadence. Queens was a chaotic process and I
think we learnt a hard lesson from it
(2) Finishing up the implementation for Nova-Cyborg interaction spec.
(3) Quota and multi-tenancy support
(4) FPGA Programmability support.
(5) NVIDIA GPU/ARM SoC driver support
(6) Meta data standardization. We might take a lesson from Device Tree.
(7) Containerization support for Kubernetes DPI plugin.

Thanks for your patience on reading through this long email. Again I want
to express my will to continue serving cyborg project in Rocky and look
forward to your support or any questions you might have.

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (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] PTL candidacy

2018-01-31 Thread melanie witt

Hello Stackers,

I would like to announce my candidacy for Nova PTL in the Rocky cycle.

I have been a core reviewer on Nova since May 2015 and have been working with 
OpenStack since mid 2012 (ancient times!) and you may know me on IRC as 
melwitt. I have been both a user and a developer on OpenStack, so I think I see 
things from a bit more of an all-around perspective. I’ve worked in a company 
where we ran private OpenStack clouds, so I’ve done deployments, I’ve debugged 
production issues, I’ve worked on custom internal-only patches -- you name it. 
Having experienced all of these situations has given me a special interest in 
solving problems for users, operators, and developers. It has been my mission 
to work with all of you to help make Nova better.

Like Matt, I see the Nova PTL role as a service position to the community. The 
PTL is there to help the team get things done in Nova. That means keeping track 
of the schedule, keeping tabs on ongoing work and helping people make progress 
if they’re stuck, facilitating cross-project communication when we’re working 
on things that integrate with other projects, and easing contribution to the 
project.

On the last point, I have some ideas around easing contribution, mostly having 
to do with situations where someone may have researched a bug, found a root 
cause, and can propose a patch, but don’t have the time or knowhow to provide a 
patch complete with test coverage. In cases I have seen, I reached out to the 
person and asked if they would mind if I wrote tests for their patch and added 
myself as co-author. Not only did they not mind, they were happy I offered. So, 
as an experiment, I would like to keep a list of patches (in the Priorities 
etherpad) where authors add links to patches they’d like help with in exchange 
for co-authorship. If a more experienced contributor finds a patch in the list 
that they’re interested in, they can jump in and fill in the gaps so we end up 
with a complete patch ready-for-review. In this way, I would like to try to 
give less experienced authors the opportunity to pair with more experienced 
authors on patches.

Speaking of the Priorities etherpad [1], I’d like to bring it back to active 
use. It’s a good way IMHO to track ready-for-review patches on the various 
sub-teams, virt drivers, and blueprints that we have. I think we have been good 
at reviewing high priority project patch sets but I think we could use more 
focus on reviewing lower priority blueprint work. I’d like to add a section for 
approved blueprints to increase visibility on those patches, so that 
ready-for-review patches don’t get lost in the shuffle. Regretfully, there have 
been a number of blueprint patches that were ready for review early on in the 
cycle and did not receive review for lack of visibility. I’d like to do 
something to keep track of those patches and get the ball rolling on review 
earlier in the cycle, before the higher priority work ramps up too much. I 
think keeping a section in the Priorities etherpad for these could help, along 
with a brief report/reminder of that section’s status in Nova meetings.

Bug triage has fallen a bit behind in more recent cycles and I’ve been thinking 
about how we could improve that. In the past, we had a model where we tag bugs 
with an area (like ‘api’, ‘compute’, ‘volumes’) and tag owners [2] were 
responsible for triaging bugs with their tag. The idea is that bug tagging 
(categorizing) is a quick and simple task that doesn’t require much time. Then, 
the more time-consuming task of triaging the validity and severity of bugs is 
load-balanced among tag owners. I’d like to refresh the bug tag owner list and 
see if we can get back into a pattern where we can spread out bug triage among 
the team and make more progress there.

Another area that could be improved is our communication of “low hanging fruit” 
work suitable for newer contributors. To be honest, I don’t find much in Nova 
to be “low hanging fruit” but do want to make an effort to collect and maintain 
a list of bugs and tasks that are better starting points for people who want to 
work on Nova. Long ago, we had the low-hanging-fruit etherpad [3] and I’d like 
to resurrect it to keep track of things that newer contributors could pick up.

I think Matt has done great work to increase communication across projects we 
integrate with and with the operator community. I would like to continue that 
work to maintain those relationships and continue to keep the operator 
community apprised of changes in Nova that will affect them. I know we are not 
perfect here but we endeavor to keep the communication lines open and I, for 
one, welcome feedback on areas we fall short so that we can improve.

We got a lot done in Queens, completing 36 out of 42 approved blueprints. I 
would like to keep that momentum going into the Rocky cycle. I have liked the 
model of using the PTG to discuss and prioritize work for the cycle and

Re: [openstack-dev] [kolla] PTL non candidacy

2018-01-31 Thread Steven Dake (stdake)

Cheers Michal.  Thank you for your service.

Regards
-steve

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

Date: Wednesday, January 31, 2018 at 1:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] PTL non candidacy

Thanks for being a great PTL for kolla Michał ☺

You’re not announcing your non-candidacy for drinking with your
OpenStack friends and this does not mean we can’t drink together ;)

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 10, 2018 13, 2017 at 10:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

Hello,

A bit earlier than usually, but I'd like to say that I won't be
running for PTL reelection for Rocky cycle. I had privilege of being
PTL of Kolla for last 3 cycles and I would like to thank Kolla
community for this opportunity and trust. I'm very proud of what we've
accomplished over last 3 releases and I'm sure we will accomplish even
greater things in the future!

It's good for project to change leadership every now and then. I would
encourage everyone in community to consider running, I can promise
that this job is ... very interesting;) and extremely rewarding!

Thank you all for support and please, support new PTL as much as you
supported me.

Regards,
Michal

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

__
OpenStack Development Mailing List (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-ansible][ptl] PTL candidacy for Rocky

2018-01-31 Thread Jean-Philippe Evrard

Hello everyone,

I would like to announce my candidacy for PTL of the
OpenStack-Ansible project for the Rocky cycle.

I will focus on a single theme this cycle, simplification.

After all the features introduced in Queens cycle, it's time
to simplify our work:

* Reduce the amount of variables in each role, and/or rename them to
  a more guessable name.
* Make possible to use a source of truth to reduce the amount of
  glue variables we need. A candidate for source of truth could
  be etcd, due to its presence in the OpenStack reference architecture.
* Simplifying further our "repo build".
* Simplifying our tasks, by using convention over configuration
  (Reducing the group configurability for example).
* Reducing the need of our dynamic inventory: everyone
  should be able to use openstack-ansible with a simple static inventory.
* Clarify each role maturity/contributions status. This would
  make easier for deployers to understand the status of each role, and
  take the appropriate decisions to whether or not deploy project x
  or y. If we make it simple to contribute to new
  roles and playbooks, it would also open us to more contributions
  and contributors.

On top of those simplification topics, I'd like to add the following
features in the next cycle, depending on their release timing:
* Upgrade to Ansible 2.5
* Support Ubuntu 18.04

I look forward to keep working with you all, and it would be my
honor to serve as PTL for the next cycle.

Thanks for taking the time to read this and I hope to see you in Dublin,
Jean-Philippe Evrard (evrardjp)

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

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

I don't think we need to drop translation support NOW (at least for
neutron-lbaas-dashboard).
There might be fixes which affects translation and/or there might be
translation improvements.
I don't think a deprecation means no translation fix any more. It
sounds too aggressive.
Is there any problem to keep translations for them?

Akihiro

2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
> In that case, I suggest to remove translation jobs for these repositories,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

Good to hear that! Thanks for your leadership.

Thanks,
Akihiro Motoki

2018-02-01 2:50 GMT+09:00 Michael Johnson :
> Today we are announcing the start of the deprecation cycle for
> neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
> stadium evolution [1], neutron-lbaas was identified as a project that
> should spin out of neutron and become its own project. The
> specification detailing this process was approved [2] during the
> newton OpenStack release cycle.
>
> OpenStack load balancing no longer requires deep access into the
> neutron code base and database. All of the required networking
> capabilities are now available via stable APIs. This change de-couples
> the load balancing release versioning from the rest of the OpenStack
> deployment. Since Octavia uses stable APIs when interacting with other
> OpenStack services, you can run a different version of Octavia in
> relation to your OpenStack cloud deployment.
>
> Per OpenStack deprecation policy, both projects will continue to
> receive support and bug fixes during the deprecation cycle, but no new
> features will be added to either project. All future feature
> enhancements will now occur on the Octavia project(s) [3].
>
> We are not announcing the end of the deprecation cycle at this time,
> but it will follow OpenStack policy of at least two release cycles
> prior to retirement. This means that the first release that these
> projects could be retired would be the “T” OpenStack release cycle.
>
> We have created a Frequently Asked Questions (FAQ) wiki page to help
> answer additional questions you may have about this process:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> For more information or if you have additional questions, please see
> the following resources:
>
> The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> The Octavia documentation: https://docs.openstack.org/octavia/latest/
>
> Reach out to us via IRC on the Freenode IRC network, channel #openstack-lbaas
>
> Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
> Freenode IRC network.
>
> Sending email to the OpenStack developer mailing list: openstack-dev
> [at] lists [dot] openstack [dot] org. Please prefix the subject with
> '[openstack-dev][Octavia]'
>
> Thank you for your support and patience during this transition,
>
> Michael Johnson
> Octavia PTL
>
> [1] 
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
> [2] 
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
> [3] https://governance.openstack.org/tc/reference/projects/octavia.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [keystone] milestone-3 retrospective

Hey all,

Now that we're past the 3rd milestone, we can step a time to hold a
retrospective. Let's shoot for next week during the weekly keystone
meeting. We'll get the board cleaned up before then [0].

Thanks,

Lance

[0] https://trello.com/b/jrpmDKtf/keystone-retrospective




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

[openstack-dev] [telemetry][heat][mistral][sdk][searchlight][senlin][tacker][tricircle][tripleo] Missing Queens releases

While reviewing Queens release deliverables and preparing missing stable/queens
branches, we have identified several libraries that have not had any Queens
releases.

In the past, we have stated we would force a release for any missing
deliverables in order to have a clear branching point. We considered tagging
the base of the stable/pike branch again and starting a new stable/queens
branch from there, but that doesn't work for several technical reasons the most
important of which is that the queens release would not include any changes
that had been backported to stable/pike, and we have quite a few of those. So,
we are left with 2 choices: do not release these libraries at all for queens,
or release from HEAD on master. Skipping the releases entirely will make it
difficult to provide bug fixes in these libraries over the life of the queens
release so, although it is potentially disruptive, we plan to release from HEAD
on master. We will rely on the constraints update mechanism to protect the gate
if the new releases introduce bugs and teams will be able to fix those problems
on the new stable/queens branch and then release a new version.

See https://review.openstack.org/#/c/539657/ and the notes below for details of
what will be tagged.

ceilometermiddleware


Mostly doc and CI related changes, but the "Retrieve project id to ignore from
keystone" commit (e2bf485) looks like it may be important.

Heat


heat-translator
There are quite a few bug fixes and feature changes merged that have not been
released. It is currently marked with a type of "library", but we will change
this to "other" and require a release by the end of the cycle (see
https://review.openstack.org/#/c/539655/ for that change). Based on the README
description, this appears to be a command line and therefore should maybe have
a type of "client-library", but "other" would work as far as release process
goes. Since this is kind of a special command line, perhaps "other" would be
the correct type going forward, but we will need input from the Heat team on
that.

python-heatclient
Only reno updates, so a new release on master should not be very disruptive.

tosca-parser
Several unreleased bug fixes and feature changes. Consumed by heat-translator
and tacker, so there is some risk in releasing it this late.


Mistral
---

mistral-lib
Mostly packaging and build changes, with a couple of fixes. It is used by
mistral and tripleo-common.

SDK
---

requestsexceptions
No changes this cycle. We will branch stable/queens from the same point as
stable/pike.

Searchlight
---

python-searchlightclient
Only doc and g-r changes. Since the risk here is low, we are going to release
from master and branch from there.

Senlin
--

python-senlinclient
Just one bug fix. This is a dependency for heat, mistral, openstackclient,
python-openstackclient, rally, and senlin-dashboard. The one bug fix looks
fairly safe though, so we are going to release from master and branch from
there.

Tacker
--

python-tackerclient
Many feature changes and bug fixes. This impacts mistral and tacker.

Tricircle
-

python-tricircleclient
One feature and several g-r changes.


Please respond here, comment on the patch, or hit us up in #openstack-release
if you have any questions or concerns.

Thanks,
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for 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-operators] LTS pragmatic example


On 1/31/2018 2:51 AM, Saverio Proto wrote:

Hello all,

I am again proposing a change due to operations experience. I am
proposing a clean and simple cherry-pick to Ocata.

"it depends" works pretty bad as policy for accepting patches.

Now I really dont understand what is the issue with the Stable Policy
and this patch:

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

This is a UX problem. Horizon is giving the wrong information to the user.

I got this answer:
Ocata is the second phase of stable branches [1]. Only critical bugfixes
and security patches are acceptable. I don't think it belongs to the
category.

But merging a patch that changes a log file in Nova back to Newton was
OKAY few weeks ago.

I will not be able to be in person at the PTG, but please talk about
this. People just give up upstreaming stuff like this.

thank you

Saverio


Regarding the stable policy docs, there is a note right after the 
support phases table saying, essentially, 'it depends':


https://docs.openstack.org/project-team-guide/stable-branches.html#support-phases

"It’s nevertheless allowed to backport fixes for other bugs if their 
safety can be easily proved. For example, documentation fixes, debug log 
message typo corrections, test only changes, patches that enhance test 
coverage, configuration file content fixes can apply to all supported 
branches. For those types of backports, stable maintainers will decide 
on case by case basis."


Furthermore there is the "Appropriate fixes" section:

https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes

That also goes into detail about risk vs reward here.

Maybe there should be an asterisk in the support phases table so that 
people read the notes, or we should move the support phases table below 
the note so it's considered.


Also, please keep in mind that the people doing stable branch 
maintenance upstream aren't trying to make your life hard. There is no 
one rule that fits all patches. The stable policy is a guideline, and if 
there is doubt about whether or not a patch should be accepted in 
stable, I consider the policy as the guideline for what the maintainers 
should do.


--

Thanks,

Matt

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

Re: [openstack-dev] [kolla] PTL non candidacy

2018-01-31 Thread Vikram Hosakote (vhosakot)

Thanks for being a great PTL for kolla Michał ☺

You’re not announcing your non-candidacy for drinking with your
OpenStack friends and this does not mean we can’t drink together ;)

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 10, 2018 13, 2017 at 10:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

Hello,

A bit earlier than usually, but I'd like to say that I won't be
running for PTL reelection for Rocky cycle. I had privilege of being
PTL of Kolla for last 3 cycles and I would like to thank Kolla
community for this opportunity and trust. I'm very proud of what we've
accomplished over last 3 releases and I'm sure we will accomplish even
greater things in the future!

It's good for project to change leadership every now and then. I would
encourage everyone in community to consider running, I can promise
that this job is ... very interesting;) and extremely rewarding!

Thank you all for support and please, support new PTL as much as you
supported me.

Regards,
Michal

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

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

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage


On 1/30/2018 11:14 PM, Hanxi Liu wrote:
Can I understand it as a trend that versioned notifications will replace 
unversioned notifications even though versioned notifications may have 
the only consumer for long time?


The long-term goal in nova is to eventually have parity between the 
versioned and unversioned legacy notifications. New notifications are 
all versioned. Nova can be configured to send versioned, unversioned or 
both formats via the "[notifications]notification_format" config option. 
That defaults to sending both formats. Eventually once the other 
openstack services that consume nova's notifications are switched over 
to using the versioned notifications, I think we can deprecate the 
legacy unversioned notifications and drop those from the code (probably 
several years from now at this rate).


--

Thanks,

Matt

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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

2018-01-31 Thread Jim Rollenhagen

On Wed, Jan 31, 2018 at 12:22 PM, Dmitry Tantsur 
wrote:

> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>
>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
>>
>>> At the last PTG we had some time on Monday and Tuesday for
>>> cross-project discussions related to baremetal and VM management. We
>>> don't currently have that on the schedule for this PTG. There is still
>>> some free time available that we can ask for[1]. Should we try to
>>> schedule some time for this?
>>>
>>>  From a keystone perspective, some things we'd like to talk about with
>>> the BM/VM teams are:
>>>
>>> - Unified limits[2]: we now have a basic REST API for registering
>>> limits in keystone. Next steps are building out libraries that can
>>> consume this API and calculate quota usage and limit allocation, and
>>> developing models for quotas in project hierarchies. Input from other
>>> projects is essential here.
>>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>>> problem, and we'd like to guide other projects through the migration.
>>> - Application credentials[4]: this main part of this work is largely
>>> done, next steps are implementing better access control for it, which
>>> is largely just a keystone team problem but we could also use this
>>> time for feedback on the implementation so far
>>>
>>> There's likely some non-keystone-related things that might be at home
>>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>>> two for these projects? Or perhaps not dedicated days, but
>>> planned-in-advance meeting time? Or should we wait and schedule it
>>> ad-hoc if we feel like we need it?
>>>
>>> Colleen
>>>
>>> [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rI
>>> zlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25Kji
>>> uRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
>>> [2] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/limits-api.html
>>> [3] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/system-scope.html
>>> [4] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/application-credentials.html
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> These all seem like good topics for big cross-project issues.
>>
>> I've never liked the "BM/VM" platform naming thing, it seems to imply
>> that the only things one needs to care about for these discussions is if
>> they work on or use nova and ironic, and that's generally not the case.
>>
>
> ++ can we please rename it? I think people (myself included) will expect
> specifically something related to bare metal instances co-existing with
> virtual ones (e.g. scheduling or networking concerns). Which is also a
> great topic, but it does not seem to be present on the list.


Fair point. When the "VM/baremetal workgroup" was originally formed,
the goal was more about building clouds with both types of resources,
making them behave similarly from a user perspective, etc. Somehow
we got into talking applications and these other topics came up, which
seemed more interesting/pressing to fix. :)

Maybe "cross-project identity integration" or something is a better name?

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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal



On 01/31/2018 11:50 AM, Pavlo Shchelokovskyy wrote:
> Lance,
>
> that's a single patch renaming the sample policy file from .json to
> .yaml, so I do not think it is a real blocker.
> Besides we have another patch on review that deletes those files
> altogether (and which I like more and there was an ML thread resulting
> in a decision to indeed remove them).
>
> I'll ask the patch owner to abandon it.
Thanks for following up. I just wanted to make sure we we're missing
something. Once that patch is abandoned, the list should automatically
update and ironic will be removed from that list.
>
> Cheers,
>
> On Wed, Jan 31, 2018 at 7:23 PM, Lance Bragstad  > wrote:
>
>
>
> On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:
> > Hi!
> >
> > On 01/31/2018 06:16 PM, Lance Bragstad wrote:
> >> Hey folks,
> >>
> >> The tracking tool for the policy-and-docs-in-code goal for
> Queens [0]
> >> lists a couple projects remaining for the goal [1].  I wanted
> to start a
> >> discussion with said projects to see how we want to go about
> the work in
> >> the future, we have a couple of options.
> >
> > I was under assumption that ironic has finished this goal. I'll wait
> > for pas-ha to weigh in, but I was not planning any activities
> for it.
> It looks like there is still an unmerged patch tagged with the
> policy-and-docs-in-code topic [0].
>
> [0]
> 
> https://review.openstack.org/#/q/is:open+topic:policy-and-docs-in-code+project:openstack/ironic
> 
> 
> >
> >>
> >> I can update the document the goal document saying the work is
> still
> >> underway for those projects. We can also set aside time at the
> PTG to
> >> finish up that work if people would like more help. This might be
> >> something we can leverage the baremetal/vm room for if we get
> enough
> >> interest [2].
> >
> > Mmm, the scope of the bm/vm room is already unclear to me, this may
> > add to the confusion. Maybe just a "Goals workroom"?
> >
> >>
> >> I want to get the discussion rolling if there is something we
> need to
> >> coordinate for the PTG. Thoughts?
> >>
> >> Thanks,
> >>
> >> Lance
> >>
> >>
> >> [0]
> https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> 
> >> [1] https://www.lbragstad.com/policy-burndown/
> 
> >> [2]
> >>
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html
> 
> 
> >>
> >>
> >>
> >>
> >>
> >>
> __
> >>
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>
> >
> >
> >
> __
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for

Re: [openstack-dev] [docs] how to update published pike docs

2018-01-31 Thread Brian Rosmaita

On Wed, Jan 31, 2018 at 1:47 PM, Andreas Jaeger  wrote:
> On 2018-01-31 18:22, Jeremy Stanley wrote:
>> On 2018-01-31 12:07:30 -0500 (-0500), Brian Rosmaita wrote:
>> [...]
>
> That fixed it - thanks,
>

Yes! Thanks for the quick work.  All fixed now!

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

Re: [openstack-dev] [docs] how to update published pike docs

On 2018-01-31 18:22, Jeremy Stanley wrote:
> On 2018-01-31 12:07:30 -0500 (-0500), Brian Rosmaita wrote:
> [...]
>> What do we need to do to get the docs.o.o to show the fixed docs?  Is
>> it something we need to do on the glance side, or does it have to be
>> fixed somewhere else?
> 
> Looks like that commit merged toward the end of September, so
> identifying why the build failed (or never ran) will be tough. I've
> reenqueued the tip of your stable/pike branch into the post
> pipeline, but because that pipeline runs at a low priority it may
> still be a few hours before that completes (commit 06af2eb in the
> status display). Once it does, we should hopefully at least have
> logs detailing the problem though if all goes well you'll have
> properly updated documentation there instead.


That fixed it - thanks,

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


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

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

In that case, I suggest to remove translation jobs for these repositories,

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


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

Re: [openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

2018-01-31 Thread Armando M.

On 31 January 2018 at 09:50, Michael Johnson  wrote:

> Today we are announcing the start of the deprecation cycle for
> neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
> stadium evolution [1], neutron-lbaas was identified as a project that
> should spin out of neutron and become its own project. The
> specification detailing this process was approved [2] during the
> newton OpenStack release cycle.
>
> OpenStack load balancing no longer requires deep access into the
> neutron code base and database. All of the required networking
> capabilities are now available via stable APIs. This change de-couples
> the load balancing release versioning from the rest of the OpenStack
> deployment. Since Octavia uses stable APIs when interacting with other
> OpenStack services, you can run a different version of Octavia in
> relation to your OpenStack cloud deployment.
>
> Per OpenStack deprecation policy, both projects will continue to
> receive support and bug fixes during the deprecation cycle, but no new
> features will be added to either project. All future feature
> enhancements will now occur on the Octavia project(s) [3].
>
> We are not announcing the end of the deprecation cycle at this time,
> but it will follow OpenStack policy of at least two release cycles
> prior to retirement. This means that the first release that these
> projects could be retired would be the “T” OpenStack release cycle.
>
> We have created a Frequently Asked Questions (FAQ) wiki page to help
> answer additional questions you may have about this process:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> For more information or if you have additional questions, please see
> the following resources:
>
> The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation
>
> The Octavia documentation: https://docs.openstack.org/octavia/latest/
>
> Reach out to us via IRC on the Freenode IRC network, channel
> #openstack-lbaas
>
> Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
> Freenode IRC network.
>
> Sending email to the OpenStack developer mailing list: openstack-dev
> [at] lists [dot] openstack [dot] org. Please prefix the subject with
> '[openstack-dev][Octavia]'
>
> Thank you for your support and patience during this transition,
>
> Michael Johnson
> Octavia PTL
>

What a milestone! Thanks for your leadership throughout this journey!

Cheers,
Armando


>
> [1] http://specs.openstack.org/openstack/neutron-specs/specs/
> newton/neutron-stadium.html
> [2] http://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
> [3] https://governance.openstack.org/tc/reference/projects/octavia.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

2018-01-31 Thread Goutham Pratapa

Hi Jay,

Thanks for the questions.. :)

What precisely do you mean by "resources" above ??

Resources as-in resources required to boot-up a vm (Keypair, Image, Flavors
)

Also, by "syncing", do you mean "replicating"? The reason I ask is because
in the case of, say, VM "resources", you can't "sync" a VM across regions.
You can replicate its bootable image, but you can't "sync" a VM's state
across multiple OpenStack deployments.

>
Yes as you said syncing as-in replicating only.

and yes we cannot sync vm's across regions but our idea is to
sync/replicate all the parameters required to boot a vm

(viz. *image, keypair, flavor*) which are originally there in the source
region to the target regions in a single-go.

I'm curious what you mean by "resource management". Could you elaborate a
bit on this?

Resource management as-in managing the resources i.e say a user has a
glance image(*qcow2 or ami format*) or
say flavor(*works only if admin*) with some properties or keypair present
in one source region and he wants the same image or
same flavor with same properties or the same keypair in another set of
regions user may have to recreate them in all target regions.

But with the help of kingbird you can do all the operations in a single go.

--> If user wants to sync a resource of type keypair he can replicate the
keypair into multiple target regions in single go (similarly glance images
and flavors )
--> If user wants different type of resource( keypair,image and flavor) in
a single go then user can  give a yaml file as input and kingbird
replicates all resources in all target regions


Thanks
Goutham.

On Wed, Jan 31, 2018 at 9:25 PM, Jay Pipes  wrote:

> On 01/31/2018 01:49 AM, Goutham Pratapa wrote:
>
>> *Kingbird (The Multi Region orchestrator):*
>>
>> We are proud to announce kingbird is not only a centralized quota and
>> resource-manager but also a  Multi-region Orchestrator.
>>
>> *Use-cases covered:
>>
>> *- Admin can synchronize and periodically balance quotas across regions
>> and can have a global view of quotas of all the tenants across regions.
>> - A user can sync a resource or a group of resources from one region to
>> other in a single go
>>
>
> What precisely do you mean by "resources" above?
>
> Also, by "syncing", do you mean "replicating"? The reason I ask is because
> in the case of, say, VM "resources", you can't "sync" a VM across regions.
> You can replicate its bootable image, but you can't "sync" a VM's state
> across multiple OpenStack deployments.
>
>   A user can sync multiple key-pairs, images, and flavors from one region
>> to other, ( Flavor can be synced only by admin)
>>
>> - A user must have complete tempest test-coverage for all the
>> scenarios/services rendered by kingbird.
>>
>> - Horizon plugin so that user can access/view global limits.
>>
>> * Our Road-map:*
>>
>> -- Automation scripts for kingbird in
>>  -ansible,
>>  -salt
>>  -puppet.
>> -- Add SSL support to kingbird
>> -- Resource management in Kingbird-dashboard.
>>
>
> I'm curious what you mean by "resource management". Could you elaborate a
> bit on this?
>
> Thanks,
> -jay
>
> -- Kingbird in a docker
>> -- Add Kingbird into Kolla.
>>
>> We are looking out for*_contributors and ideas_* which can enhance
>> Kingbird and make kingbird a one-stop solution for all multi-region problems
>>
>>
>>
>> *_Stable Branches :_
>> *
>> *
>> Kingbird-server: https://github.com/openstack/kingbird/tree/stable/queens
>> 
>> *
>> *Python-Kingbird-client (0.2.1): https://github.com/openstack/p
>> ython-kingbirdclient/tree/0.2.1 > python-kingbirdclient/tree/0.2.1>
>> *
>>
>> I would like to Thank all the people who have helped us in achieving this
>> milestone and guided us all throughout this Journey :)
>>
>> Thanks
>> Goutham Pratapa
>> PTL
>> OpenStack-Kingbird.
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>


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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

2018-01-31 Thread Colleen Murphy

On Wed, Jan 31, 2018 at 6:46 PM, Graham Hayes  wrote:
> On 31/01/18 17:22, Dmitry Tantsur wrote:
>> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
[snip]
>>>
>>> These all seem like good topics for big cross-project issues.
>>>
>>> I've never liked the "BM/VM" platform naming thing, it seems to imply
>>> that the only things one needs to care about for these discussions is
>>> if they work on or use nova and ironic, and that's generally not the
>>> case.
>>
>> ++ can we please rename it? I think people (myself included) will expect
>> specifically something related to bare metal instances co-existing with
>> virtual ones (e.g. scheduling or networking concerns). Which is also a
>> great topic, but it does not seem to be present on the list.
>>
>
> Yeah - both of these topic apply to all projects. If we could do
> scheduled time for both of these, and then separate time for Ironic /
> Nova issues it would be good.
>
>>>
>>> So if you do have a session about this really cross-project
>>> platform-specific stuff, can we at least not call it "BM/VM"? Plus,
>>> "BM" always makes me think of something I'd rather not see in a room
>>> with other people.
>>>

++

Sorry, I didn't mean to be exclusive. These topics do apply to most
projects, and it did feel awkward writing that email with keystone
goals in mind when keystone is in neither category.

Colleen

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

Re: [openstack-dev] [security] Security PTG Planning, x-project request for topics.

2018-01-31 Thread Luke Hinds

On Mon, Jan 29, 2018 at 2:29 PM, Adam Young  wrote:

> Bug 968696 and System Roles.   Needs to be addressed across the Service
> catalog.
>

Thanks Adam, will add it to the list. I see it's been open since 2012!


>
> On Mon, Jan 29, 2018 at 7:38 AM, Luke Hinds  wrote:
>
>> Just a reminder as we have not had many uptakes yet..
>>
>> Are there any projects (new and old) that would like to make use of the
>> security SIG for either gaining another perspective on security challenges
>> / blueprints etc or for help gaining some cross project collaboration?
>>
>> On Thu, Jan 11, 2018 at 3:33 PM, Luke Hinds  wrote:
>>
>>> Hello All,
>>>
>>> I am seeking topics for the PTG from all projects, as this will be where
>>> we try out are new form of being a SIG.
>>>
>>> For this PTG, we hope to facilitate more cross project collaboration
>>> topics now that we are a SIG, so if your project has a security need /
>>> problem / proposal than please do use the security SIG room where a larger
>>> audience may be present to help solve problems and gain x-project consensus.
>>>
>>> Please see our PTG planning pad [0] where I encourage you to add to the
>>> topics.
>>>
>>> [0] https://etherpad.openstack.org/p/security-ptg-rocky
>>>
>>> --
>>> Luke Hinds
>>> Security Project PTL
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
e: lhi...@redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][infra] Automatically generated Zuul changes (topic: zuulv3-projects)

2018-01-31 Thread James E. Blair

Hi,

Occasionally we will make changes to the Zuul configuration language.
Usually these changes will be backwards compatible, but whether they are
or not, we still want to move things forward.

Because Zuul's configuration is now spread across many repositories, it
may take many changes to do this.  I'm in the process of making one such
change now.

Zuul no longer requires the project name in the "project:" stanza for
in-repo configuration.  Removing it makes it easier to fork or rename a
project.

I am using a script to create and upload these changes.  Because changes
to Zuul's configuration use more resources, I, and the rest of the infra
team, are carefully monitoring this and pacing changes so as not to
overwhelm the system.  This is a limitation we'd like to address in the
future, but we have to live with now.

So if you see such a change to your project (the topic will be
"zuulv3-projects"), please observe the following:

* Go ahead and approve it as soon as possible.

* Don't be strict about backported change ids.  These changes are only
  to Zuul config files, the stable backport policy was not intended to
  apply to things like this.

* Don't create your own versions of these changes.  My script will
  eventually upload changes to all affected project-branches.  It's
  intentionally a slow process, and attempting to speed it up won't
  help.  But if there's something wrong with the change I propose, feel
  free to push an update to correct it.

Thanks,

Jim

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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal

2018-01-31 Thread Mathieu Gagné

On Wed, Jan 31, 2018 at 12:16 PM, Lance Bragstad  wrote:
> Hey folks,
>
> The tracking tool for the policy-and-docs-in-code goal for Queens [0]
> lists a couple projects remaining for the goal [1].  I wanted to start a
> discussion with said projects to see how we want to go about the work in
> the future, we have a couple of options.
>
> I can update the document the goal document saying the work is still
> underway for those projects. We can also set aside time at the PTG to
> finish up that work if people would like more help. This might be
> something we can leverage the baremetal/vm room for if we get enough
> interest [2].
>
> I want to get the discussion rolling if there is something we need to
> coordinate for the PTG. Thoughts?
>
> Thanks,
>
> Lance
>

As an operator, I can't wait for Glance and Neutron to complete this goal.
The policy is code is *very* useful when you do heavy work in policy.
Thanks to all working toward that goal.

--
Mathieu

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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal

2018-01-31 Thread Pavlo Shchelokovskyy

Lance,

that's a single patch renaming the sample policy file from .json to .yaml,
so I do not think it is a real blocker.
Besides we have another patch on review that deletes those files altogether
(and which I like more and there was an ML thread resulting in a decision
to indeed remove them).

I'll ask the patch owner to abandon it.

Cheers,

On Wed, Jan 31, 2018 at 7:23 PM, Lance Bragstad  wrote:

>
>
> On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:
> > Hi!
> >
> > On 01/31/2018 06:16 PM, Lance Bragstad wrote:
> >> Hey folks,
> >>
> >> The tracking tool for the policy-and-docs-in-code goal for Queens [0]
> >> lists a couple projects remaining for the goal [1].  I wanted to start a
> >> discussion with said projects to see how we want to go about the work in
> >> the future, we have a couple of options.
> >
> > I was under assumption that ironic has finished this goal. I'll wait
> > for pas-ha to weigh in, but I was not planning any activities for it.
> It looks like there is still an unmerged patch tagged with the
> policy-and-docs-in-code topic [0].
>
> [0]
> https://review.openstack.org/#/q/is:open+topic:policy-and-
> docs-in-code+project:openstack/ironic
> >
> >>
> >> I can update the document the goal document saying the work is still
> >> underway for those projects. We can also set aside time at the PTG to
> >> finish up that work if people would like more help. This might be
> >> something we can leverage the baremetal/vm room for if we get enough
> >> interest [2].
> >
> > Mmm, the scope of the bm/vm room is already unclear to me, this may
> > add to the confusion. Maybe just a "Goals workroom"?
> >
> >>
> >> I want to get the discussion rolling if there is something we need to
> >> coordinate for the PTG. Thoughts?
> >>
> >> Thanks,
> >>
> >> Lance
> >>
> >>
> >> [0] https://governance.openstack.org/tc/goals/queens/policy-in-
> code.html
> >> [1] https://www.lbragstad.com/policy-burndown/
> >> [2]
> >> http://lists.openstack.org/pipermail/openstack-dev/2018-
> January/126743.html
> >>
> >>
> >>
> >>
> >>
> >> 
> __
> >>
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

2018-01-31 Thread Michael Johnson

Today we are announcing the start of the deprecation cycle for
neutron-lbaas and neutron-lbaas-dashboard. As part of the neutron
stadium evolution [1], neutron-lbaas was identified as a project that
should spin out of neutron and become its own project. The
specification detailing this process was approved [2] during the
newton OpenStack release cycle.

OpenStack load balancing no longer requires deep access into the
neutron code base and database. All of the required networking
capabilities are now available via stable APIs. This change de-couples
the load balancing release versioning from the rest of the OpenStack
deployment. Since Octavia uses stable APIs when interacting with other
OpenStack services, you can run a different version of Octavia in
relation to your OpenStack cloud deployment.

Per OpenStack deprecation policy, both projects will continue to
receive support and bug fixes during the deprecation cycle, but no new
features will be added to either project. All future feature
enhancements will now occur on the Octavia project(s) [3].

We are not announcing the end of the deprecation cycle at this time,
but it will follow OpenStack policy of at least two release cycles
prior to retirement. This means that the first release that these
projects could be retired would be the “T” OpenStack release cycle.

We have created a Frequently Asked Questions (FAQ) wiki page to help
answer additional questions you may have about this process:
https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

For more information or if you have additional questions, please see
the following resources:

The FAQ: https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

The Octavia documentation: https://docs.openstack.org/octavia/latest/

Reach out to us via IRC on the Freenode IRC network, channel #openstack-lbaas

Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the
Freenode IRC network.

Sending email to the OpenStack developer mailing list: openstack-dev
[at] lists [dot] openstack [dot] org. Please prefix the subject with
'[openstack-dev][Octavia]'

Thank you for your support and patience during this transition,

Michael Johnson
Octavia PTL

[1] 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[2] 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
[3] https://governance.openstack.org/tc/reference/projects/octavia.html

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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal


On 01/31/2018 06:23 PM, Lance Bragstad wrote:



On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:

Hi!

On 01/31/2018 06:16 PM, Lance Bragstad wrote:

Hey folks,

The tracking tool for the policy-and-docs-in-code goal for Queens [0]
lists a couple projects remaining for the goal [1].  I wanted to start a
discussion with said projects to see how we want to go about the work in
the future, we have a couple of options.


I was under assumption that ironic has finished this goal. I'll wait
for pas-ha to weigh in, but I was not planning any activities for it.

It looks like there is still an unmerged patch tagged with the
policy-and-docs-in-code topic [0].

[0]
https://review.openstack.org/#/q/is:open+topic:policy-and-docs-in-code+project:openstack/ironic


But is it required? We've marked the goal as done already, and pas-ha is no 
longer working on it AFAIK.






I can update the document the goal document saying the work is still
underway for those projects. We can also set aside time at the PTG to
finish up that work if people would like more help. This might be
something we can leverage the baremetal/vm room for if we get enough
interest [2].


Mmm, the scope of the bm/vm room is already unclear to me, this may
add to the confusion. Maybe just a "Goals workroom"?



I want to get the discussion rolling if there is something we need to
coordinate for the PTG. Thoughts?

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html





__

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




__

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





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




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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

2018-01-31 Thread Graham Hayes

On 31/01/18 17:22, Dmitry Tantsur wrote:
> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
>>> At the last PTG we had some time on Monday and Tuesday for
>>> cross-project discussions related to baremetal and VM management. We
>>> don't currently have that on the schedule for this PTG. There is still
>>> some free time available that we can ask for[1]. Should we try to
>>> schedule some time for this?
>>>
>>>  From a keystone perspective, some things we'd like to talk about with
>>> the BM/VM teams are:
>>>
>>> - Unified limits[2]: we now have a basic REST API for registering
>>> limits in keystone. Next steps are building out libraries that can
>>> consume this API and calculate quota usage and limit allocation, and
>>> developing models for quotas in project hierarchies. Input from other
>>> projects is essential here.
>>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>>> problem, and we'd like to guide other projects through the migration.
>>> - Application credentials[4]: this main part of this work is largely
>>> done, next steps are implementing better access control for it, which
>>> is largely just a keystone team problem but we could also use this
>>> time for feedback on the implementation so far
>>>
>>> There's likely some non-keystone-related things that might be at home
>>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>>> two for these projects? Or perhaps not dedicated days, but
>>> planned-in-advance meeting time? Or should we wait and schedule it
>>> ad-hoc if we feel like we need it?
>>>
>>> Colleen
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
>>>
>>> [2]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
>>>
>>> [3]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
>>>
>>> [4]
>>> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html
>>>
>>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> These all seem like good topics for big cross-project issues.
>>
>> I've never liked the "BM/VM" platform naming thing, it seems to imply
>> that the only things one needs to care about for these discussions is
>> if they work on or use nova and ironic, and that's generally not the
>> case.
> 
> ++ can we please rename it? I think people (myself included) will expect
> specifically something related to bare metal instances co-existing with
> virtual ones (e.g. scheduling or networking concerns). Which is also a
> great topic, but it does not seem to be present on the list.
> 

Yeah - both of these topic apply to all projects. If we could do
scheduled time for both of these, and then separate time for Ironic /
Nova issues it would be good.

>>
>> So if you do have a session about this really cross-project
>> platform-specific stuff, can we at least not call it "BM/VM"? Plus,
>> "BM" always makes me think of something I'd rather not see in a room
>> with other people.
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [docs] [infra] how to update published pike docs

On 2018-01-31 18:07, Brian Rosmaita wrote:
> Hello Docs people,
> 
> The glance install docs currently published on docs.o.o don't include
> a correction we merged a while back, and I get a few bug reports filed
> on this particular problem every week.  (It's great that people are
> willing to file corrections, but the duplicates are really piling up!)
>  Anyway, here's what's happening:
> 
> published docs:
> https://docs.openstack.org/glance/pike/install/install-debian.html
> (can't see the create db stuff -- you may need to look at the next
> link first to see what I mean)
> 
> docs in github:
> https://github.com/openstack/glance/blob/stable/pike/doc/source/install/install-debian.rst
> (can see the create db stuff)
> 
> glance stable/pike in the repo:
> http://git.openstack.org/cgit/openstack/glance?h=stable%2Fpike
> You can see stable/pike head is at the fix.
> 
> What do we need to do to get the docs.o.o to show the fixed docs?  Is
> it something we need to do on the glance side, or does it have to be
> fixed somewhere else?

please check the post job for this, I assume it never run or failed.

If it did not run, just push a new change out.

If it failed, let's fix it first.

Btw. to get logs, see
https://docs.openstack.org/infra/manual/developers.html#post-processing

And docs team has nothing to do here, this is pure infra - so updated tags.

If you have further questions, let's discuss on #openstack-infra,


Andreas

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


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


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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal



On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:
> Hi!
>
> On 01/31/2018 06:16 PM, Lance Bragstad wrote:
>> Hey folks,
>>
>> The tracking tool for the policy-and-docs-in-code goal for Queens [0]
>> lists a couple projects remaining for the goal [1].  I wanted to start a
>> discussion with said projects to see how we want to go about the work in
>> the future, we have a couple of options.
>
> I was under assumption that ironic has finished this goal. I'll wait
> for pas-ha to weigh in, but I was not planning any activities for it.
It looks like there is still an unmerged patch tagged with the
policy-and-docs-in-code topic [0].

[0]
https://review.openstack.org/#/q/is:open+topic:policy-and-docs-in-code+project:openstack/ironic
>
>>
>> I can update the document the goal document saying the work is still
>> underway for those projects. We can also set aside time at the PTG to
>> finish up that work if people would like more help. This might be
>> something we can leverage the baremetal/vm room for if we get enough
>> interest [2].
>
> Mmm, the scope of the bm/vm room is already unclear to me, this may
> add to the confusion. Maybe just a "Goals workroom"?
>
>>
>> I want to get the discussion rolling if there is something we need to
>> coordinate for the PTG. Thoughts?
>>
>> Thanks,
>>
>> Lance
>>
>>
>> [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
>> [1] https://www.lbragstad.com/policy-burndown/
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html
>>
>>
>>
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 01/31/2018 06:15 PM, Matt Riedemann wrote:

On 1/30/2018 9:33 AM, Colleen Murphy wrote:

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?

From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1]
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true

[2]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html

[3]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html

[4]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html

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

These all seem like good topics for big cross-project issues.

I've never liked the "BM/VM" platform naming thing, it seems to imply that the
only things one needs to care about for these discussions is if they work on or
use nova and ironic, and that's generally not the case.

++ can we please rename it? I think people (myself included) will expect
specifically something related to bare metal instances co-existing with virtual
ones (e.g. scheduling or networking concerns). Which is also a great topic, but
it does not seem to be present on the list.

So if you do have a session about this really cross-project platform-specific
stuff, can we at least not call it "BM/VM"? Plus, "BM" always makes me think of
something I'd rather not see in a room with other people.

Re: [openstack-dev] [docs] how to update published pike docs

2018-01-31 Thread Jeremy Stanley

On 2018-01-31 12:07:30 -0500 (-0500), Brian Rosmaita wrote:
[...]
> What do we need to do to get the docs.o.o to show the fixed docs?  Is
> it something we need to do on the glance side, or does it have to be
> fixed somewhere else?

Looks like that commit merged toward the end of September, so
identifying why the build failed (or never ran) will be tough. I've
reenqueued the tip of your stable/pike branch into the post
pipeline, but because that pipeline runs at a low priority it may
still be a few hours before that completes (commit 06af2eb in the
status display). Once it does, we should hopefully at least have
logs detailing the problem though if all goes well you'll have
properly updated documentation there instead.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal


Hi!

On 01/31/2018 06:16 PM, Lance Bragstad wrote:

Hey folks,

The tracking tool for the policy-and-docs-in-code goal for Queens [0]
lists a couple projects remaining for the goal [1].  I wanted to start a
discussion with said projects to see how we want to go about the work in
the future, we have a couple of options.


I was under assumption that ironic has finished this goal. I'll wait for pas-ha 
to weigh in, but I was not planning any activities for it.




I can update the document the goal document saying the work is still
underway for those projects. We can also set aside time at the PTG to
finish up that work if people would like more help. This might be
something we can leverage the baremetal/vm room for if we get enough
interest [2].


Mmm, the scope of the bm/vm room is already unclear to me, this may add to the 
confusion. Maybe just a "Goals workroom"?




I want to get the discussion rolling if there is something we need to
coordinate for the PTG. Thoughts?

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html




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




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

Re: [openstack-dev] [nova][ironic] Tagging newton EOL


On 1/30/2018 10:17 PM, Tony Breeds wrote:

Hi All,
 When we tagged newton EOL in October there were in-flight reviews
for nova and ironic that needed to land before we could EOL them.  That
work completed but I dropped the ball.  So can we tag those last 2
repos?

As in October a member of the infra team needs to do this *or* I can
be added to Project Bootstrappers[1] for long enough to do this.

# EOL repos belonging to ironic
eol_branch.sh -- stable/newton newton-eol openstack/ironic
# EOL repos belonging to nova
eol_branch.sh -- stable/newton newton-eol openstack/nova

Yours Tony.

[1] https://review.openstack.org/#/admin/groups/26,members



Yes please for the love of God do this.

I also fully realize that we've had to wait this long because I kept 
breaking things, then fixing and backporting them, and then realize 
those fixes had broken something else and required more backports, yay!


--

Thanks,

Matt

__
OpenStack Development Mailing List (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] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal

Hey folks,

The tracking tool for the policy-and-docs-in-code goal for Queens [0]
lists a couple projects remaining for the goal [1].  I wanted to start a
discussion with said projects to see how we want to go about the work in
the future, we have a couple of options.

I can update the document the goal document saying the work is still
underway for those projects. We can also set aside time at the PTG to
finish up that work if people would like more help. This might be
something we can leverage the baremetal/vm room for if we get enough
interest [2].

I want to get the discussion rolling if there is something we need to
coordinate for the PTG. Thoughts?

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html




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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?


On 1/30/2018 9:33 AM, Colleen Murphy wrote:

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?

 From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1] 
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[4] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html

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



These all seem like good topics for big cross-project issues.

I've never liked the "BM/VM" platform naming thing, it seems to imply 
that the only things one needs to care about for these discussions is if 
they work on or use nova and ironic, and that's generally not the case.


So if you do have a session about this really cross-project 
platform-specific stuff, can we at least not call it "BM/VM"? Plus, "BM" 
always makes me think of something I'd rather not see in a room with 
other people.


--

Thanks,

Matt

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

Re: [openstack-dev] [requirement][cyborg]FFE - pyspdk requirement dependency

2018-01-31 Thread Jeremy Stanley

On 2018-01-31 10:44:12 -0600 (-0600), Matthew Thode wrote:
[...]
> Thanks for the link, and yes should probably just be discussed in a
> review.  Missing a setup.py/cfg and license and testing all make it seem
> like a no-go though.

The 0.0.2 sdist on PyPI does contain those, leading me to suspect
that either the GH repo is non-canonical or its Python packaging
files are maintained independent of revision control.
-- 
Jeremy Stanley


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] [kolla][ptl] PTL Candidacy for Rocky

2018-01-31 Thread Jeffrey Zhang

Hi everyone,

I am excited to announce my candidacy for the Rocky cycle as Kolla PTL.

Kolla is a fantastic project, which simplifies the lives of operators when
managing OpenStack. Now, Kolla can containerize and deliver almost all
OpenStack Big Tent projects. And more and more OpenStack environment are
deployed by Kolla in the real world. And lots of developers and operators
joined Kolla, too.

I have been involved in OpenStack since Folsom cycle and I have been a core
reviewer on Kolla since Liberty cycle. I have contributed lots of features
and
solved lots of critical issue in Kolla projects since then[0][1]. During the
Ocata, Pike and Queens cycle I also served as the Kolla release liaison. I
also have helped new developers to contribute to the project and operators
to solve issues.

For the Rocky cycle, I would like to focus on following objectives:

* Focus on the needs of Kolla team.
* Continue to encourage diversity in our Community.
* Support check and diff mode in kolla-ansible.
* Implement zero downtime for OpenStack services.
* Continue to speed up the kolla-ansible deploy and reconfigure.
* Make CI easier to understand and debug.
* Push tag image to hub.docker.com site which is more stable than branch
tag.
* Deliver 1.0.0 of kolla-kubernetes.

Finally, I know it is important that PTL time is spent on the non-technical
problem-solving such as mentoring potential core reviewers, scheduling the
project progress, interacting with other OpenStack projects and many other
activities a PTL undertakes. I’d like to work this cycle on scaling those
activities across the core reviewer team.

Thank you for reading this and for considering this candidacy. As a
community
I am certain we can make Kolla better and better.

Sincerely,
Jeffrey4l

[0] http://stackalytics.com/?release=all=kolla=commits
[1] http://stackalytics.com/?release=all=kolla=marks

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

[openstack-dev] [docs] how to update published pike docs

2018-01-31 Thread Brian Rosmaita

Hello Docs people,

The glance install docs currently published on docs.o.o don't include
a correction we merged a while back, and I get a few bug reports filed
on this particular problem every week.  (It's great that people are
willing to file corrections, but the duplicates are really piling up!)
 Anyway, here's what's happening:

published docs:
https://docs.openstack.org/glance/pike/install/install-debian.html
(can't see the create db stuff -- you may need to look at the next
link first to see what I mean)

docs in github:
https://github.com/openstack/glance/blob/stable/pike/doc/source/install/install-debian.rst
(can see the create db stuff)

glance stable/pike in the repo:
http://git.openstack.org/cgit/openstack/glance?h=stable%2Fpike
You can see stable/pike head is at the fix.

What do we need to do to get the docs.o.o to show the fixed docs?  Is
it something we need to do on the glance side, or does it have to be
fixed somewhere else?

thanks,
brian

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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?



On 01/30/2018 09:33 AM, Colleen Murphy wrote:
> At the last PTG we had some time on Monday and Tuesday for
> cross-project discussions related to baremetal and VM management. We
> don't currently have that on the schedule for this PTG. There is still
> some free time available that we can ask for[1]. Should we try to
> schedule some time for this?
>
> From a keystone perspective, some things we'd like to talk about with
> the BM/VM teams are:
>
> - Unified limits[2]: we now have a basic REST API for registering
> limits in keystone. Next steps are building out libraries that can
> consume this API and calculate quota usage and limit allocation, and
> developing models for quotas in project hierarchies. Input from other
> projects is essential here.
> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
> problem, and we'd like to guide other projects through the migration.
> - Application credentials[4]: this main part of this work is largely
> done, next steps are implementing better access control for it, which
> is largely just a keystone team problem but we could also use this
> time for feedback on the implementation so far
So, I'm probably biased, but a huge +1 for me. I think the last
baremetal/vm session in Denver was really productive and led to most of
what we accomplished this release. Who else do we need to get involved
in order to get this scheduled? Do we need some more projects to show up
(e.g. cinder, nova, neutron)?

Tacking on the RBAC stuff, it would be cool to sit down with others and
talk about basic roles [0], since we have everything to make that
possible. I suppose we could start collecting topics in an etherpad and
elaborating on them there.

[0] https://review.openstack.org/#/c/523973/
> There's likely some non-keystone-related things that might be at home
> in a dedicated BM/VM room too. Do we want to have a dedicated day or
> two for these projects? Or perhaps not dedicated days, but
> planned-in-advance meeting time? Or should we wait and schedule it
> ad-hoc if we feel like we need it?
>
> Colleen
>
> [1] 
> https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
> [2] 
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
> [3] 
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
> [4] 
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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] [requirement][cyborg]FFE - pyspdk requirement dependency

2018-01-31 Thread Matthew Thode

On 18-01-31 10:15:12, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > Excerpts from We We's message of 2018-01-31 01:54:04 +0800:
> >>> Hi,
> >>
> >>> I have modified and resubmitted  pyspdk to the pypi. Please check it.
> >>
> >>> Thx,
> >>
> >>> Helloway
> > 
> > Is there a public source repository for the library somewhere?
> 
> Looks like it lives at:
> https://github.com/hellowaywewe/py-spdk
> 
> Since the primary objections are not really due to the FFE state but
> more due to the nature of the library, this should probably first be
> proposed as a change to openstack/requirements and discussed there...
> 
> When it's ready but blocked by FF we can return to a ML thread to
> discuss it...
> 

Thanks for the link, and yes should probably just be discussed in a
review.  Missing a setup.py/cfg and license and testing all make it seem
like a no-go though.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [nova] Requesting eyes on fix for bug 1686703


On 1/31/2018 7:30 AM, Matthew Booth wrote:
Could I please have some eyes on this bugfix: 
https://review.openstack.org/#/c/462521/ . I addressed an issue raised 
in August 2017, and it's had no negative feedback since. It would be 
good to get this one finished.


First, I'd like to avoid setting a precedent of asking for reviews in 
the ML. So please don't do this.


Second, this is a latent issue, and we're less than two weeks to RC1, so 
I'd prefer that we hold this off until Rocky opens up in case it 
introduces any regressions so we at least have time to deal with those 
when we're not in stop-ship mode.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for 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-operators] LTS pragmatic example

2018-01-31 17:51 GMT+09:00 Saverio Proto :
> Hello all,
>
> I am again proposing a change due to operations experience. I am
> proposing a clean and simple cherry-pick to Ocata.
>
> "it depends" works pretty bad as policy for accepting patches.
>
> Now I really dont understand what is the issue with the Stable Policy
> and this patch:
>
> https://review.openstack.org/#/c/539439/
>
> This is a UX problem. Horizon is giving the wrong information to the user.
>
> I got this answer:
> Ocata is the second phase of stable branches [1]. Only critical bugfixes
> and security patches are acceptable. I don't think it belongs to the
> category.
>

It is really understandable.

I am the person who put -1 on the horizon backport raised here. In
this specific case, the proposed backport does not import a new
confusion and it will provide a correct error message for a specific
case, so when I put -1 I struggled whether I put +2 or -1. It is
half-and-half. I am okay to remove my -1.

On the other hand, it is important to share some common criteria among
the stable reviewers.
different reviewers can apply different criteria. it is not productive
to define a project specific policy which is a bit different from the
common stable branch policy.
I would like to see some updated stable policy in near future as
output of LTS discussions.

Akihiro

> But merging a patch that changes a log file in Nova back to Newton was
> OKAY few weeks ago.
>
> I will not be able to be in person at the PTG, but please talk about
> this. People just give up upstreaming stuff like this.
>
> thank you
>
> Saverio
>
>
> On 15.11.17 03:37, Matt Riedemann wrote:
>> On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
>>> Let's focus our energy on the etherpad please
>>>
>>> https://etherpad.openstack.org/p/LTS-proposal
>>>
>>> On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas 
>>> wrote:
 Saverio,

 Please see this :
 https://docs.openstack.org/project-team-guide/stable-branches.html for
 current policies.

 On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto
  wrote:
>> Which stable policy does that patch violate?  It's clearly a bug
>> because the wrong information is being logged.  I suppose it goes
>> against the string freeze rule? Except that we've stopped translating
>> log messages so maybe we don't need to worry about that in this case,
>> since it isn't an exception.
>
> Well, I also would like to understand more about stable policy
> violations.
> When I proposed such patches in the past for the release N-2 I have
> always got the answer: it is not a security issue so it will not be
> merged.
>
> This is a good example of how things have been working so far:
>
> https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa
>
>
> This cinder patch was merged in master. It was then merged in Mitaka.
> But it was not merged in Liberty just because "only security fixes"
> were
> allowed at that point.
>
> You can read that in the comments:
> https://review.openstack.org/#/c/306610/
>
> Is this kind of things going to change after the discussion in Sydney ?
> The discussion is not enough ? what we need to get done then ?
>
> thank you
>
> Saverio
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Davanum Srinivas :: https://twitter.com/dims
>>>
>>>
>>>
>>
>> Heh, I'm reading this thread after approving all of those patches.
>>
>> The answer as to whether it's appropriate or not, is "it depends".
>> Depends on the patch, depends on the age of the branch, etc.
>>
>> In this case, newton is in phase 3 so normally it's only security or
>> critical fixes allowed, but in this case it's so trivial and so
>> obviously wrong that I was OK with approving it just to get it in before
>> we end of life the branch.
>>
>> So, it depends. And because it depends, that's also why we don't
>> automate the backport of every fix made on master. Because guess what,
>> we also backport "fixes" that introduce regressions, and when you do
>> that to n-1 (Pike at this point) then you still have a lot of time to
>> detect that and fix it upstream, but regressing things on the oldest
>> branch leaves very little time to (1) have it detected and (2) get it
>> fixed before end of life.
>>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
>

[openstack-dev] [relmgt][ptl] Release Management PTL candidacy for Rocky

Greetings!

I would like to submit my name to continue as the release management PTL for
the Rocky release.

Since starting with Queens I have learned a lot about our release process and
all the great automation tooling we have to support that. I've also had to
learn a fair bit about zuul and ansible along the way.

It has been an interesting and active release cycle, and I am excited to
continue learning and applying those lessons to keep things moving and looking
for any ways I can add to the already great body of work we have in our release
automation.

Thank you for your consideration.

Sean McGinnis (smcginnis)

__
OpenStack Development Mailing List (not for 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][Kingbird]Multi-Region Orchestrator

2018-01-31 Thread Jay Pipes


On 01/31/2018 01:49 AM, Goutham Pratapa wrote:

*Kingbird (The Multi Region orchestrator):*

We are proud to announce kingbird is not only a centralized quota and 
resource-manager but also a  Multi-region Orchestrator.


*Use-cases covered:

*- Admin can synchronize and periodically balance quotas across regions 
and can have a global view of quotas of all the tenants across regions.
- A user can sync a resource or a group of resources from one region to 
other in a single go


What precisely do you mean by "resources" above?

Also, by "syncing", do you mean "replicating"? The reason I ask is 
because in the case of, say, VM "resources", you can't "sync" a VM 
across regions. You can replicate its bootable image, but you can't 
"sync" a VM's state across multiple OpenStack deployments.


  A user can sync multiple key-pairs, images, and flavors from one 
region to other, ( Flavor can be synced only by admin)


- A user must have complete tempest test-coverage for all the 
scenarios/services rendered by kingbird.


- Horizon plugin so that user can access/view global limits.

* Our Road-map:*

-- Automation scripts for kingbird in
     -ansible,
     -salt
     -puppet.
-- Add SSL support to kingbird
-- Resource management in Kingbird-dashboard.


I'm curious what you mean by "resource management". Could you elaborate 
a bit on this?


Thanks,
-jay


-- Kingbird in a docker
-- Add Kingbird into Kolla.

We are looking out for*_contributors and ideas_* which can enhance 
Kingbird and make kingbird a one-stop solution for all multi-region problems




*_Stable Branches :_
*
*
Kingbird-server: 
https://github.com/openstack/kingbird/tree/stable/queens 


*
*Python-Kingbird-client (0.2.1): 
https://github.com/openstack/python-kingbirdclient/tree/0.2.1 


*

I would like to Thank all the people who have helped us in achieving 
this milestone and guided us all throughout this Journey :)


Thanks
Goutham Pratapa
PTL
OpenStack-Kingbird.



__
OpenStack Development Mailing List (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] [sdk][ptl] PTL Candidacy for Rocky

2018-01-31 Thread Monty Taylor


Hi everybody!

I'd like to run for PTL of OpenStackSDK again

This last cycle was pretty exciting. We merged the shade and 
openstacksdk projects into a single team. We shifted os-client-config to 
that team as well. We merged the code from shade and os-client-config 
into openstacksdk, and then renamed the team.


It wasn't just about merging projects though. We got some rework done to 
base the Proxy classes on keystoneauth Adapters providing direct 
passthrough REST availability for services. We finished the 
Resource2/Proxy2 transition. We updated pagination to work for all of 
the OpenStack services - and in the process uncovered a potential 
cross-project goal. And we tied services in openstacksdk to services 
listed in the Service Types Authority.


Moving forward, there's tons to do.

First and foremost we need to finish integrating the shade code into the 
sdk codebase. The sdk layer and the shade layer are currently friendly 
but separate, and that doesn't make sense long term. To do this, we need 
to figure out a plan for rationalizing the return types - shade returns 
munch.Munch objects which are dicts that support object attribute 
access. The sdk returns Resource objects.


There are also multiple places where the logic in the shade layer can 
and should move into the sdk's Proxy layer. Good examples of this are 
swift object uploads and downloads and glance image uploads.


I'd like to move masakari and tricircle's out-of-tree SDK classes in tree.

shade's caching and rate-limiting layer needs to be shifted to be able 
to apply to both levels, and the special caching for servers, ports and
floating-ips needs to be replaced with the general system. For us to do 
that though, the general system needs to be improved to handle 
nodepool's batched rate-limited use case as well.


We need to remove the guts of both shade and os-client-config in their 
repos and turn them into backwards compatibility shims.


We need to work with the python-openstackclient team to finish getting 
the current sdk usage updated to the non-Profile-based flow, and to make 
sure we're providing what they need to start replacing uses of 
python-*client with uses of sdk.


I know the folks with the shade team background are going to LOVE this 
one, but we need to migrate existing sdk tests that mock sdk objects to 
requests-mock. (We also missed a few shade tests that still mock out 
methods on OpenStackCloud that need to get transitioned)


Finally - we need to get a 1.0 out this cycle. We're very close - the 
main sticking point now is the shade/os-client-config layer, and 
specifically cleaning up a few pieces of shade's API that weren't great 
but which we couldn't change due to API contracts.


I'm sure there will be more things to do too. There always are.

In any case, I'd love to keep helping to pushing these rocks uphill.

Thanks!
Monty

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

Re: [openstack-dev] [release][masakari] Need help on masakari deliverables

2018-01-31 Thread Sam P

Hi Sean,

 Thanks. That make sense.
 I will proceed masakari release as independent for Queens.
 And will push those patches to Rocky.

--- Regards,
Sampath


On Thu, Feb 1, 2018 at 12:30 AM, Sean McGinnis 
wrote:

> On Thu, Feb 01, 2018 at 12:19:16AM +0900, Sam P wrote:
> > Hi release team,
> >
> >  I did not realize at the time however, I noticed that masakari does not
> > have any
> >  of it deliverables are set for Queens in [1]. Which is my fault and
> really
> > sorry for that.
> >
> > We currently have 3 deliverables,
> > masakari:
> > repos:
> > - openstack/masakari
> > masakari-monitors:
> >   repos:
> > - openstack/masakari-monitors
> > python-masakariclient:
> >   repos:
> > - openstack/python-masakariclient
> >
> >  I would like to propose those patches to openstack/releases.
> >  "Now" is a bad timing for that?
> >  Your advice is greatly appreciated.
> >
> > [1]
> > http://git.openstack.org/cgit/openstack/releases/tree/
> deliverables/queens
> >
> > --- Regards,
> > Sampath
>
>
> Hi Sampath,
>
> Since these have missed all milestones for this cycle, we do not want to
> add it
> now. Especially as we are past all freeze dates.
>
> I think at this point the best option is to release this as independent
> (under
> the deliverables/_independent directory in the openstack/releases repo)
> and we
> can get it on the normal cycle-with-milestones or cycle-with-intermediary
> sequence in Rocky.
>
> Make sense?
>
> Any questions, feel free to drop in #openstack-release. Or we can continue
> here
> of course.
>
> Thanks,
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][masakari] Need help on masakari deliverables

On Thu, Feb 01, 2018 at 12:19:16AM +0900, Sam P wrote:
> Hi release team,
> 
>  I did not realize at the time however, I noticed that masakari does not
> have any
>  of it deliverables are set for Queens in [1]. Which is my fault and really
> sorry for that.
> 
> We currently have 3 deliverables,
> masakari:
> repos:
> - openstack/masakari
> masakari-monitors:
>   repos:
> - openstack/masakari-monitors
> python-masakariclient:
>   repos:
> - openstack/python-masakariclient
> 
>  I would like to propose those patches to openstack/releases.
>  "Now" is a bad timing for that?
>  Your advice is greatly appreciated.
> 
> [1]
> http://git.openstack.org/cgit/openstack/releases/tree/deliverables/queens
> 
> --- Regards,
> Sampath

Hi Sampath,

Since these have missed all milestones for this cycle, we do not want to add it
now. Especially as we are past all freeze dates.

I think at this point the best option is to release this as independent (under
the deliverables/_independent directory in the openstack/releases repo) and we
can get it on the normal cycle-with-milestones or cycle-with-intermediary
sequence in Rocky.

Make sense?

Any questions, feel free to drop in #openstack-release. Or we can continue here
of course.

Thanks,
Sean

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

[openstack-dev] [release][masakari] Need help on masakari deliverables

2018-01-31 Thread Sam P

Hi release team,

 I did not realize at the time however, I noticed that masakari does not
have any
 of it deliverables are set for Queens in [1]. Which is my fault and really
sorry for that.

We currently have 3 deliverables,
masakari:
repos:
- openstack/masakari
masakari-monitors:
  repos:
- openstack/masakari-monitors
python-masakariclient:
  repos:
- openstack/python-masakariclient

 I would like to propose those patches to openstack/releases.
 "Now" is a bad timing for that?
 Your advice is greatly appreciated.

[1]
http://git.openstack.org/cgit/openstack/releases/tree/deliverables/queens

--- Regards,
Sampath
__
OpenStack Development Mailing List (not for 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] opendaylight OpenDaylightConnectionProtocol deprecation issue

2018-01-31 Thread Ben Nemec




On 01/29/2018 04:27 AM, Moshe Levi wrote:

Hi all,

It seem that this commit [1] deprecated the 
OpenDaylightConnectionProtocol, but it also remove it.


This is causing the following issue when we deploy opendaylight non 
containerized. See [2]


One solution is to add back the OpenDaylightConnectionProtocol [3] the 
other solution is to remove the OpenDaylightConnectionProtocol from the 
deprecated parameter_groups [4].


Looks like the deprecation was done incorrectly.  The parameter should 
have been left in place and referenced in the deprecated group.  So I 
think the fix would just be to put the parameter definition back.




[1] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab 



[2] - http://paste.openstack.org/show/656702/

[3] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab#diff-21674daa44a327c016a80173efeb10e7L20 



[4] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab#diff-21674daa44a327c016a80173efeb10e7R112 





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



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

[openstack-dev] [keystone] [ptl] PTL candidacy for Rocky

Hey folks,

I'm writing to express my interest in continuing to serve as keystone's
PTL for the Rocky release.

Even though we're a few weeks away from an official Queens release, I
felt we had an extremely productive cycle. The outcome of the Queens PTG
in Denver was nothing short of ambitious. We finished up things that
missed the boat for Pike, while shouldering some hefty new initiatives.
To summarize:

* We helped projects move their default policies into code and document
them, which makes maintenance for operators and deployers much more
manageable
* We implemented full support for tagging project resources, which has
been a long-time ask from operators
* We landed an implementation for application credentials, making it
easier to run apps that integrate with OpenStack - especially for
deployments backing to LDAP
* We implemented an experimental API for unified limits, which opens the
doors for us to start integrating consistent quota enforcement across
services
* We introduced a new assignment target and token scope to help set
administrative APIs apart from end user APIs
* Lastly, our team did a good job stepping up to mentor new contributors

The following are a few of my top priorities for Rocky:

* Help projects leverage system scope to improve the usability and
security of their APIs
* Build on the in-code policy work to provide discoverable capability APIs
* Put together a plan to make unified limits a stable API and help
incorporate its usage into other projects
* Continue fostering an environment where newcomers feel welcome and can
make meaningful contributions

In my nomination for the Pike cycle, I mentioned that I wanted to do
what I could to solve the hard problems our community is faced with.
It's extremely encouraging to see the needle move on several
long-standing issues, especially with a systematic, team-oriented
approach. It's been great to be a part of those efforts.

Thanks for taking the time to read this and I hope to see you in Dublin,

Lance




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] [Glance][PTL] Nomination for Glance PTL for Rocky cycle

2018-01-31 Thread Abhishek Kekane

All the best Erno, Long may you reign ;)

Abhishek

On 31-Jan-2018 18:38, "Erno Kuvaja"  wrote:

> Hi all,
>
> After lengthy discussions and careful thinking I have thrown my name
> into the hat for Glance PTL. You can find my thoughts from the
> candidacy patch https://review.openstack.org/#/c/539196/
>
> I'd like to take the opportunity to thank most recently Brian but also
> our other former PTLs from Mark to Flavio and everyone in between that
> I've had pleasure to work with for running the show and showing the
> way. You guys have been integral part of me growing to the point where
> I dare to do this.
>
> Nominations are still open and having an election is healthy so if any
> of you are still thinking of nominating yourselves, there's time until
> Fri. Don't miss the deadline or you will get me by default ;)
>
> Best,
> Erno jokke Kuvaja
>
> __
> OpenStack Development Mailing List (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] [User-committee] [publiccloud-wg] Reminder for todays meeting

2018-01-31 Thread Zhipeng Huang

shall we cancel the meeting for today then ?

On Wed, Jan 31, 2018 at 9:55 PM, Tobias Rydberg 
wrote:

> Hi,
>
> It's maybe time for a new doodle about bi-weekly meeting ... potentially
> also about going to weekly meeting?
>
> Personally I'm fine with morning times as well, if that is better for more
> people.
>
> Tobias
>
> On 2018-01-31 14:46, Jean-Daniel Bonnetot wrote:
>
> Hi,
>
> For me it's not the best time frame. A have a weekly meeting on that time.
> Is it possible to move our weekly meeting 30min later ?
> If it's not possible for this meeting, maybe it's doable for the next ones?
>
> Jean-Daniel Bonnetot
> ovh.com | @pilgrimstack
>
>
>
>
>
> On 31 Jan 2018, at 12:37, Tobias Rydberg  wrote:
>
> Hi all,
>
> Time again for a meeting for the Public Cloud WG - today at 1400 UTC in
> #openstack-meeting-3
>
> Agenda and etherpad at: https://etherpad.openstack.org/p/publiccloud-wg
>
> See you later!
>
> Tobias Rydberg
>
> --
> Tobias Rydberg
> Senior Developer
> Mobile: +46 733 312780
>
> www.citynetwork.eu | www.citycloud.com
>
> INNOVATION THROUGH OPEN IT INFRASTRUCTURE
> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (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] FFE request for --check feature

2018-01-31 Thread Shewale, Bhagyashri

Hi Glance Folks,

I'm requesting an Feature Freeze Exception for the lite-spec 
http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/lite-spec-db-sync-check.html
  
which is implemented by https://review.openstack.org/#/c/455837/8/ 

Regards,
Bhagyashri Shewale

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [User-committee] [publiccloud-wg] Reminder for todays meeting

2018-01-31 Thread Tobias Rydberg


Hi,

It's maybe time for a new doodle about bi-weekly meeting ... potentially 
also about going to weekly meeting?


Personally I'm fine with morning times as well, if that is better for 
more people.


Tobias


On 2018-01-31 14:46, Jean-Daniel Bonnetot wrote:

Hi,

For me it's not the best time frame. A have a weekly meeting on that time.
Is it possible to move our weekly meeting 30min later ?
If it's not possible for this meeting, maybe it's doable for the next 
ones?


Jean-Daniel Bonnetot
ovh.com  | @pilgrimstack





On 31 Jan 2018, at 12:37, Tobias Rydberg > wrote:


Hi all,

Time again for a meeting for the Public Cloud WG - today at 1400 UTC 
in #openstack-meeting-3


Agenda and etherpad at: 
https://etherpad.openstack.org/p/publiccloud-wg 



See you later!

Tobias Rydberg

--
Tobias Rydberg
Senior Developer
Mobile: +46 733 312780

www.citynetwork.eu  | www.citycloud.com 



INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


___
User-committee mailing list
user-commit...@lists.openstack.org 


http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee






smime.p7s
Description: S/MIME Cryptographic 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] [masakari] [Release-job-failures] Tag of openstack/masakari failed

2018-01-31 Thread Sam P

Hi Sean,

 Thanks for the advice. Above fix has merged.

--- Regards,
Sampath


On Wed, Jan 31, 2018 at 9:39 PM, Sean McGinnis 
wrote:

> Masakari had a release job fail for publishing the release notes. It
> appears to
> be due to the release notes not being updated to follow the latest
> requirements
> with the changes that were done in the zuul job.
>
> There is an outstanding patch in openstack/masakari that should fix this:
>
> https://review.openstack.org/#/c/520887/
>
> Thanks,
> Sean
>
> - Forwarded message from z...@openstack.org -
>
> Date: Wed, 31 Jan 2018 09:56:58 +
> From: z...@openstack.org
> To: release-job-failu...@lists.openstack.org
> Subject: [Release-job-failures] Tag of openstack/masakari failed
> Reply-To: openstack-dev@lists.openstack.org
>
> Build failed.
>
> - publish-openstack-releasenotes http://logs.openstack.org/6b/
> 6b10645d92e7560efc088f7f09991d332af7096f/tag/publish-
> openstack-releasenotes/de4278d/ : FAILURE in 3m 46s
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> - End forwarded message -
>
> __
> OpenStack Development Mailing List (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] [User-committee] [publiccloud-wg] Reminder for todays meeting

2018-01-31 Thread Jean-Daniel Bonnetot

Hi,

For me it's not the best time frame. A have a weekly meeting on that time.
Is it possible to move our weekly meeting 30min later ?
If it's not possible for this meeting, maybe it's doable for the next ones?

Jean-Daniel Bonnetot
ovh.com | @pilgrimstack





On 31 Jan 2018, at 12:37, Tobias Rydberg 
> wrote:

Hi all,

Time again for a meeting for the Public Cloud WG - today at 1400 UTC in 
#openstack-meeting-3

Agenda and etherpad at: https://etherpad.openstack.org/p/publiccloud-wg

See you later!

Tobias Rydberg

--
Tobias Rydberg
Senior Developer
Mobile: +46 733 312780

www.citynetwork.eu | 
www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


___
User-committee mailing list
user-commit...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

__
OpenStack Development Mailing List (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][all] QA Office Hours on 01st Feb, 2018

2018-01-31 Thread Chandan kumar

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

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

Re: [openstack-dev] [ironic] ansible deploy, playbooks and containers?

2018-01-31 Thread Mark Goddard

I like the swift/HTTP proposal.

In kayobe we've considered how to customise the deployment process, with
hook points [1] looking like the right approach.

Another possibility when deploy steps [2] land could be to break up the
ansible deployment into multiple steps, and allow each step to be
overridden.

[1] https://github.com/stackhpc/kayobe/issues/52
[2] https://review.openstack.org/#/c/412523/

On 31 January 2018 at 13:16, Dmitry Tantsur  wrote:

> Hi all,
>
> I'd like to discuss one idea that came to me while trying to use the
> ansible deploy in TripleO.
>
> The ansible deploy interface is all about customization. Meaning, we
> expect people to modify the playbooks. I have two concerns with it:
>
> 1. Nearly any additions requires a full copy of the playbooks. Which will
> make the operators miss any future updates to the shipped version (e.g.
> from packages).
>
> 2. We require operators to modify playbooks on the hard drive in a
> location, available to ironic-conductor. This is inconvenient when there
> are many conductors and quite hairy with containers.
>
> So, what came to my mind is:
>
> 1. Let us maybe define some hook points in our playbooks and allow
> operators to overwrite only them? I'm not sure how it's going to look, so
> suggestions are welcome.
>
> 2. Let us maybe allow a swift or http(s) URL for the playbooks_path
> configuration? That will be a link to a tarball that will be unpacked by
> ironic to a temporary location before executing.
>
> What do you think?
>
> __
> OpenStack Development Mailing List (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] [nova] Requesting eyes on fix for bug 1686703

2018-01-31 Thread Matthew Booth

Could I please have some eyes on this bugfix:
https://review.openstack.org/#/c/462521/ . I addressed an issue raised in
August 2017, and it's had no negative feedback since. It would be good to
get this one finished.

Thanks,

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

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

[openstack-dev] [ironic] ansible deploy, playbooks and containers?


Hi all,

I'd like to discuss one idea that came to me while trying to use the ansible 
deploy in TripleO.


The ansible deploy interface is all about customization. Meaning, we expect 
people to modify the playbooks. I have two concerns with it:


1. Nearly any additions requires a full copy of the playbooks. Which will make 
the operators miss any future updates to the shipped version (e.g. from packages).


2. We require operators to modify playbooks on the hard drive in a location, 
available to ironic-conductor. This is inconvenient when there are many 
conductors and quite hairy with containers.


So, what came to my mind is:

1. Let us maybe define some hook points in our playbooks and allow operators to 
overwrite only them? I'm not sure how it's going to look, so suggestions are 
welcome.


2. Let us maybe allow a swift or http(s) URL for the playbooks_path 
configuration? That will be a link to a tarball that will be unpacked by ironic 
to a temporary location before executing.


What do you think?

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

Re: [openstack-dev] [glance] Q-3 milestone released

2018-01-31 Thread Brian Rosmaita

On Tue, Jan 30, 2018 at 11:39 PM, Brian Rosmaita
 wrote:
[snip]
> Glance cores, please do not merge any patches until after
> https://review.openstack.org/#/c/536630/ has merged.

The patch merged at 08:15UTC today.  Merge away (subject to common
sense and the fact that we're in RC time).

cheers,
brian

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

[openstack-dev] [Glance][PTL] Nomination for Glance PTL for Rocky cycle

2018-01-31 Thread Erno Kuvaja

Hi all,

After lengthy discussions and careful thinking I have thrown my name
into the hat for Glance PTL. You can find my thoughts from the
candidacy patch https://review.openstack.org/#/c/539196/

I'd like to take the opportunity to thank most recently Brian but also
our other former PTLs from Mark to Flavio and everyone in between that
I've had pleasure to work with for running the show and showing the
way. You guys have been integral part of me growing to the point where
I dare to do this.

Nominations are still open and having an election is healthy so if any
of you are still thinking of nominating yourselves, there's time until
Fri. Don't miss the deadline or you will get me by default ;)

Best,
Erno jokke Kuvaja

__
OpenStack Development Mailing List (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] [masakari] [Release-job-failures] Tag of openstack/masakari failed

Masakari had a release job fail for publishing the release notes. It appears to
be due to the release notes not being updated to follow the latest requirements
with the changes that were done in the zuul job.

There is an outstanding patch in openstack/masakari that should fix this:

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

Thanks,
Sean

- Forwarded message from z...@openstack.org -

Date: Wed, 31 Jan 2018 09:56:58 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Tag of openstack/masakari failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- publish-openstack-releasenotes 
http://logs.openstack.org/6b/6b10645d92e7560efc088f7f09991d332af7096f/tag/publish-openstack-releasenotes/de4278d/
 : FAILURE in 3m 46s

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

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

Re: [openstack-dev] [horizon] FFE Request for Queens

2018-01-31 Thread Lajos Katona


Thanks Akihiro
I will bring it up on today's meeting.

Regards
Lajos

On 2018-01-31 10:39, Akihiro Motoki wrote:

+1 for FFE. I can support it.

We need a final ack from our PTL.

Akihiro

2018-01-30 5:13 GMT+09:00 Lajos Katona :

Hi,

I would like to ask for FFE on the neutron-trunk-ui blueprint to let the
admin panel for trunks be accepted for Queens.

Based on discussion on IRC
(http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2018-01-29.log.html#t2018-01-29T14:36:58
) the remaining part of the blueprint neutron-trunk-ui
(https://blueprints.launchpad.net/horizon/+spec/neutron-trunk-ui) should be
handled separately:

The admin panel (https://review.openstack.org/516657) should be part of the
Queens release, as now that is not dependent on the ngDetails patches. With
this the blueprint should be set to implemented.
The links (https://review.openstack.org/524619) for the ports details (trunk
parent and subports) from the trunk panel should be handled in a bug report:

https://bugs.launchpad.net/horizon/+bug/1746082

Regards
Lajos Katona

__
OpenStack Development Mailing List (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] [Openstack-operators] LTS pragmatic example

2018-01-31 Thread Saverio Proto

> You seem to be interested in a policy shift toward more of a "bugfix"
> branch where any fix should be allowed to land, and where branch age
> should not be a factor. It would be interesting to assess if that is a
> general view. I know that distros in general are happy with more of a
> "stable" approach.

Hello Thierry,

you are right. A bugfix branch is very important for us. I cannot keep a
UX bug in production, when I have a user that opens a support ticket
about this. I have to avoid the second user opening the second ticket
for the very same problem.
If merging to a common bugfix branch is not possible, I will have to
carry local patches.
Please be aware that most Openstack Ubuntu packages do carry local
patches in the debian/patches/ folder.
I am pretty sure that this patch could land without problems in the
Ubuntu packages for Newton/Horizon.

> 
>> But merging a patch that changes a log file in Nova back to Newton was
>> OKAY few weeks ago.
> Could you provide a link to that one ?

sure, here it is:
https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea

Thank you

Saverio



-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing List (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] [publiccloud-wg] Reminder for todays meeting

2018-01-31 Thread Tobias Rydberg


Hi all,

Time again for a meeting for the Public Cloud WG - today at 1400 UTC in 
#openstack-meeting-3


Agenda and etherpad at: https://etherpad.openstack.org/p/publiccloud-wg

See you later!

Tobias Rydberg

--
Tobias Rydberg
Senior Developer
Mobile: +46 733 312780

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED




smime.p7s
Description: S/MIME Cryptographic 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] [oslo][oslo.log]Re: Error will be occurred if watch_log_file option is true

2018-01-31 Thread Rikimaru Honjo


Hello,

Sorry for the very late reply...

On 2018/01/10 1:11, Doug Hellmann wrote:

Excerpts from Rikimaru Honjo's message of 2018-01-09 18:11:09 +0900:

Hello,

On 2018/01/04 23:12, Doug Hellmann wrote:

Excerpts from Rikimaru Honjo's message of 2018-01-04 18:22:26 +0900:

Hello,

The below bug was reported in Masakari's Launchpad.
I think that this bug was caused by oslo.log.
(And, the root cause is a bug of pyinotify using by oslo.log. The detail is
written in the bug report.)

* masakari-api failed to launch due to setting of watch_log_file and log_file
 https://bugs.launchpad.net/masakari/+bug/1740111

There is a possibility that this bug will affects all openstack components 
using oslo.log.
(But, the processes working with uwsgi[1] wasn't affected when I tried to 
reproduce.
I haven't solved the reason of this yet...)

Could you help us?
And, what should we do...?

[1]
e.g. nova-api, cinder-api, keystone...

Best regards,


The bug is in pyinotify. According to the git repo [1] that project
was last updated in June of 2015.  I recommend we move off of
pyinotify entirely, since it appears to be unmaintained.

If there is another library to do the same thing we should switch
to it (there seem to be lots of options [2]). If there is no viable
replacement or fork, we should deprecate that log watching feature
(and anything else for which we use pyinotify) and remove it ASAP.

We'll need a volunteer to do the evaluation and update oslo.log.

Doug

[1] https://github.com/seb-m/pyinotify
[2] https://pypi.python.org/pypi?%3Aaction=search=inotify=search

Thank you for replying.

I haven't deeply researched, but inotify looks good.
Because "weight" of inotify is the largest, and following text is described.

https://pypi.python.org/pypi/inotify/0.2.9

This project is unrelated to the *PyInotify* project that existed prior to this 
one (this project began in 2015). That project is defunct and no longer 
available.

PyInotify is defunct and no longer available...



The inotify package seems like a good candidate to replace pyinotify.

Have you looked at how hard it would be to change oslo.log? If so, does
using the newer library eliminate the bug you had?

I am researching it now. (But, I think it is not easy.)
I'll create a patch if inotify can eliminate the bug.



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




--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp




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

Re: [openstack-dev] [nova][ironic] Tagging newton EOL


Hi!

Ironic is ready for newton EOL.

On 01/31/2018 05:17 AM, Tony Breeds wrote:

Hi All,
 When we tagged newton EOL in October there were in-flight reviews
for nova and ironic that needed to land before we could EOL them.  That
work completed but I dropped the ball.  So can we tag those last 2
repos?

As in October a member of the infra team needs to do this *or* I can
be added to Project Bootstrappers[1] for long enough to do this.

# EOL repos belonging to ironic
eol_branch.sh -- stable/newton newton-eol openstack/ironic
# EOL repos belonging to nova
eol_branch.sh -- stable/newton newton-eol openstack/nova

Yours Tony.

[1] https://review.openstack.org/#/admin/groups/26,members




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

Re: [openstack-dev] [horizon] FFE Request for Queens

+1 for FFE. I can support it.

We need a final ack from our PTL.

Akihiro

2018-01-30 5:13 GMT+09:00 Lajos Katona :
> Hi,
>
> I would like to ask for FFE on the neutron-trunk-ui blueprint to let the
> admin panel for trunks be accepted for Queens.
>
> Based on discussion on IRC
> (http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2018-01-29.log.html#t2018-01-29T14:36:58
> ) the remaining part of the blueprint neutron-trunk-ui
> (https://blueprints.launchpad.net/horizon/+spec/neutron-trunk-ui) should be
> handled separately:
>
> The admin panel (https://review.openstack.org/516657) should be part of the
> Queens release, as now that is not dependent on the ngDetails patches. With
> this the blueprint should be set to implemented.
> The links (https://review.openstack.org/524619) for the ports details (trunk
> parent and subports) from the trunk panel should be handled in a bug report:
>
> https://bugs.launchpad.net/horizon/+bug/1746082
>
> Regards
> Lajos Katona
>
> __
> OpenStack Development Mailing List (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] [blazar] [Release-job-failures] Release of openstack/blazar-nova failed

Masahito MUROI wrote:
> Thanks. I push the patch to fix the issue.  Do I need an additional
> patch that tags blazar-nova 1.0.1 as I did to blazarclient?

I'd say yes. The simplest way for us to properly publish it would be a
new version tag once everything is in place.

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] [Openstack-operators] LTS pragmatic example

Saverio Proto wrote:
> Hello all,
> 
> I am again proposing a change due to operations experience. I am
> proposing a clean and simple cherry-pick to Ocata.
> 
> "it depends" works pretty bad as policy for accepting patches.
> 
> Now I really dont understand what is the issue with the Stable Policy
> and this patch:
> 
> https://review.openstack.org/#/c/539439/
> 
> This is a UX problem. Horizon is giving the wrong information to the user.
> 
> I got this answer:
> Ocata is the second phase of stable branches [1]. Only critical bugfixes
> and security patches are acceptable. I don't think it belongs to the
> category.

Every deployer has different expectations for "stable", which is why we
have a stable branch policy. Our current policy is a trade-off between
being a source of important fixes ("bugfix" branch), and changing less
and less as time moves on ("stable" branch). The idea behind it being,
if people lived with a minor issue for so long, the behavior change
creates more "instability" than keeping the minor bug in.

The rules have been followed in this case -- it's a UI bug, but changing
the behavior now would create unwanted churn on a "stable" branch for
little gain.

You seem to be interested in a policy shift toward more of a "bugfix"
branch where any fix should be allowed to land, and where branch age
should not be a factor. It would be interesting to assess if that is a
general view. I know that distros in general are happy with more of a
"stable" approach.

> But merging a patch that changes a log file in Nova back to Newton was
> OKAY few weeks ago.
Could you provide a link to that one ?

-- 
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] [blazar] [Release-job-failures] Release of openstack/blazar-nova failed

2018-01-31 Thread Masahito MUROI


Hi Sean,

Thanks. I push the patch to fix the issue.  Do I need an additional 
patch that tags blazar-nova 1.0.1 as I did to blazarclient?


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

best regards,
Masahito

On 2018/01/31 7:40, Sean McGinnis wrote:

There was a failure with releasing blazar-nova. It would appear this has a
dependency on nova, but nova is not in the required-projects. This will need to
be corrected before we can complete the blazar-nova release.

http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/job-output.txt.gz#_2018-01-30_22_06_50_103665

- Forwarded message from z...@openstack.org -

Date: Tue, 30 Jan 2018 22:11:42 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/blazar-nova failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- release-openstack-python 
http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/
 : FAILURE in 3m 45s
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

__
OpenStack Development Mailing List (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][Kingbird]Multi-Region Orchestrator

2018-01-31 Thread Goutham Pratapa

OK, sorry that was a mistake :)

Thank you, Thierry  :)


On Wed, Jan 31, 2018 at 2:51 PM, Thierry Carrez 
wrote:

> Goutham Pratapa wrote:
> > *Kingbird (The Multi Region orchestrator):*
> >
> > We are proud to announce kingbird is not only a centralized quota and
> > resource-manager but also a  Multi-region Orchestrator.
> > [...]
> > Thanks
> > Goutham Pratapa
> > PTL
> > OpenStack-Kingbird.
>
> Quick clarification: Kingbird is not (yet) an official OpenStack
> component, so it should probably not call itself OpenStack Kingbird.
>
> Regards,
>
> --
> 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
>



-- 
Cheers !!!
Goutham Pratapa
__
OpenStack Development Mailing List (not for 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][Kingbird]Multi-Region Orchestrator

Goutham Pratapa wrote:
> *Kingbird (The Multi Region orchestrator):*
> 
> We are proud to announce kingbird is not only a centralized quota and
> resource-manager but also a  Multi-region Orchestrator.
> [...]
> Thanks
> Goutham Pratapa
> PTL
> OpenStack-Kingbird.

Quick clarification: Kingbird is not (yet) an official OpenStack
component, so it should probably not call itself OpenStack Kingbird.

Regards,

-- 
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] [requirement][cyborg]FFE - pyspdk requirement dependency