[openstack-dev] [murano] murano 5.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for murano for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/murano/

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

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

http://git.openstack.org/cgit/openstack/murano/log/?h=stable/queens

Release notes for murano can be found at:

http://docs.openstack.org/releasenotes/murano/




__
OpenStack Development Mailing List (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] nova 17.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for nova for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/

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

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

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

Release notes for nova can be found at:

http://docs.openstack.org/releasenotes/nova/




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

[openstack-dev] [horizon] horizon 13.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for horizon for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/horizon/

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

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

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

Release notes for horizon can be found at:

http://docs.openstack.org/releasenotes/horizon/




__
OpenStack Development Mailing 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] [Senlin] [PTL] PTL nomination for Senlin

[Lee Yi]

+1
---
Lee Yi / Fiberhome Corp.
liyi8...@gmail.com



> On 3 Feb 2018, at 12:38, YUAN RUIJIE  wrote:
> 
> +1
> Thanks for taking up responsibility to lead the team!!!
> 
> 2018-01-31 15:58 GMT+08:00  >:
> 
> 
> Hi all
> 
> I'd like to announce my candidacy for the PTL role of Senlin Project for
> 
> Rocky cycle.
> 
> 
> 
> I began to contribute to Senlin project since Mitaka and joined the team as
> 
> a core reviewer in 2016.10. It is my pleasure to work with the great team
> 
> to make this project better and better, and we will keep moving and look
> 
> forward to push Senlin to the next level.
> 
> 
> 
> As a clustering service, we already can handle some resource types like nova
> 
> server, heat stack, NFV VDU etc. in past cycles. We also have done a lot of
> 
> great works in Queue cycle, for example we finished k8s on Senlin feature's
> 
> demo[1][2][3][4]. And there are still many works need to do in future.
> 
> 
> 
> As a PTL in Rocky cycle, I'd like to focus on the tasks as follows:
> 
> 
> 
> * Promote k8s on Senlin feature implementation and make it use in NFV
> 
>   For example:
> 
>   - Add ability to do actions on cluster creation/deletion.
> 
>   - Add more network interfaces in drivers.
> 
>   - Add kubernetes master profile, use kubeadm to setup one master node.
> 
>   - Add kubernetes node profile, auto retrieve kubernetes data from master
> 
> cluster.
> 
> * Improve health policy to support more useful auto-healing scenario
> 
> * Improve LoadBalance policy when use Octavia service driver
> 
> * Improve runtime data processing inside Senlin server
> 
> * A better support for EDGE-Computing unattended operation use cases[5]
> 
> * A stronger team to take the Senlin project to its next level.
> 
> 
> 
> Again, it is my pleasure to work with such a great team.
> 
> 
> 
> Thanks
> 
> XueFeng Liu
> 
> 
> 
> [1]https://review.openstack.org/#/c/515321/ 
> 
> [2]https://v.qq.com/x/page/i05125sfonh.html 
> 
> [3]https://v.qq.com/x/page/t0512vo6tw1.html 
> 
> [4]https://v.qq.com/x/page/y0512ehqiiq.html 
> 
> [5]https://www.openstack.org/videos/boston-2017/integration-of-enterprise-monitoring-product-senlin-and-mistral-for-auto-healing
>  
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (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] [Release-job-failures] release-post job for openstack/releases failed

[Ian Wienand]

On 02/09/2018 02:35 PM, Tony Breeds wrote:
>> - tag-releases 
>> http://logs.openstack.org/bd/bd802368fe546a891b89f78fec89d3ea9964c155/release-post/tag-releases/ffc68e7/
>>  : TIMED_OUT in 32m 19s
>> - publish-static publish-static : SKIPPED
> 
> Can we please re-run these jobs.

Done with [1]

-i

[1] 
http://logs.openstack.org/bd/bd802368fe546a891b89f78fec89d3ea9964c155/release-post/tag-releases/2cdfded/

__
OpenStack Development Mailing 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] Nominating Hironori Shiina for ironic-core

[Shivanand Tendulker]

+1

On Wed, Feb 7, 2018 at 11:53 AM, John Villalovos  wrote:

> +1
>
> On Mon, Feb 5, 2018 at 10:12 AM, Julia Kreger  > wrote:
>
>> I would like to nominate Hironori Shiina to ironic-core. He has been
>> working in the ironic community for some time, and has been helping
>> over the past several cycles with more complex features. He has
>> demonstrated an understanding of Ironic's code base, mechanics, and
>> overall community style. His review statistics are also extremely
>> solid. I personally have a great deal of trust in his reviews.
>>
>> I believe he would make a great addition to our team.
>>
>> Thanks,
>>
>> -Julia
>>
>> 
>> __
>> 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
>
>
__
OpenStack Development Mailing 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-job-failures] release-post job for openstack/releases failed

[Tony Breeds]

On Fri, Feb 09, 2018 at 03:28:23AM +, z...@openstack.org wrote:
> Build failed.
> 
> - tag-releases 
> http://logs.openstack.org/bd/bd802368fe546a891b89f78fec89d3ea9964c155/release-post/tag-releases/ffc68e7/
>  : TIMED_OUT in 32m 19s
> - publish-static publish-static : SKIPPED

Can we please re-run these jobs.  The tag is on git.o.o but none of the
publish/email steps happened.  Looks like a network timeout?

http://logs.openstack.org/bd/bd802368fe546a891b89f78fec89d3ea9964c155/release-post/tag-releases/ffc68e7/job-output.txt.gz#_2018-02-09_03_27_47_445990

Yours Tony.


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

[openstack-dev] [glance] priorities for the coming week (9 Feb - 15 Feb)

[Brian Rosmaita]

Congratulations to Erno for his election as the Rocky PTL!  Erno is
taking over PTG planning, so don't forget to add ideas to the planning
etherpad:
https://etherpad.openstack.org/p/glance-rocky-ptg-planning

The first Release Candidate for the Queens edition of Glance was
released today and the stable/queens branch was cut.

Our focus is still on Queens this week.  It would be a good idea to
give RC-1 a workout, paying particular attention to interoperable
image import and the glance-manage and glance-scrubber tools, which
underwent some refactoring and enhancements this cycle.

We'll continue to track the development toward RC-2 on this etherpad:
https://etherpad.openstack.org/p/glance-queens-rc1-patches

Add any bugs you find that are release critical to that etherpad so
that the core team can verify that they need to be backported to
stable/queens.

There will definitely be an RC-2, which will contain whatever we come
up with to address https://bugs.launchpad.net/glance/+bug/1747869

But don't let that stop you from testing out RC-1!

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

Re: [openstack-dev] [reno][tripleo] an alternative approach to known issues

[Gabriele Cerami]

On 08 Feb, Ben Nemec wrote:
> So TripleO has a tech debt policy: 
> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tech-debt-tracking.html
> (and I'm tagging tripleo on this thread for visibility).

I didn't know about this policy. I've been circling around tech debts
for more than a month now, and nobody pointed me to it either.

Anyway, I find it insufficient. Not specifically the tracking method,
but more the guidelines and the example, to understand how to use it
correctly.

Doing some basic research, I see that in tripleo 31 bugs were marked
with tech-debt tag. 15 Were closed, but they were also marked as
CRITICAL. This does not match my definition of tech-debt.
Of the remaining 16 sometimes it's hard to understand which part is the
technical debt, some are really new features requests matching more the
feeling "we may have needed to think about this months ago during the
design", for some it's just "we don't have a clear idea of what to do"
and the rest is "here's a bandaid, we'll think about it later"

The policy lacks a definition of what is a technical debt. I understand
the issue as it's really difficult to find a unique definition that fits
all we want to include.
Whatever the definition we want it to be, there are at least three things
that I want to see in tech debt bug (or report), and they all try to
focus on the "debt" part of the whole "tech debt" concept.

- What's the cost of the repayment
- What's the cost of the interests
- What's the frequency of the interests

For me a technical debt is an imperfect implementation that has
consequences. Describable and maybe measurable consequences.
"I'm using list in this case for simplicity but if we add more items, we
may need a more efficient structure, because it will become too slow"
The cost of the repayment is the time spent to replace the structure and
its methods with something more complex
The cost of the interests is the speed lost when the list increases
The frequency of the interests is "this list will become very big every
three hours"

Without these three elements it becomes hard to understand if we want to
really repay the debt, and how we prioritize the repayments.

Since a tech debt is something that I find really related to the code
(Which piece or line of code is the one that has these measurale
consequences) I'd really like for the report to be as close as possible
to the code.
Also sometimes it may just become a design choice based on assumptions.
"I know the list is not efficient, but we'll rarely get it big often,
and we are sure to clear it out almost immediately"

We can maybe discuss further the advantages of the existing bug tracking
for the handling of these reports.

> I'm not sure I agree.  Bugs stay open until they are fixed/won't fixed. Tech
> debt stays open until it is fixed/won't fixed.  We've had bugs open for
> years for things that are tricky to fix.  Arguably those are tech debt too,
> but in any case I'm not aware of any problems with using the bug tracker to
> manage them.

Remember the "debt" in "technical debt". You're not reporting it
correctly if you don't measure the consequences. I don't think the
report should really be about the problem or the solution, because then
you're really only talking about the full repayment.
Of course without any description on the consequences, the tech debt may
be equated to a bug, you really have a problem and you want to discuss
only its solution.

Another difference is that the importance of a bug rarely changes over
time, once correctly triaged.

With the technical debt instead
- A won't fix doesn't mean that the interests are gone. You closed the
  bug/tech debt and you are not counting the interests anymore.
  Convenient and deceiving. There is no status currently that could put
  the bug on hold. Removing it from all the short term consideration,
  but make it still count for its interests, make it possible to
  consider and reevaluate at any time.
- A tech debt really can get more and more costly to repay. If someone
  else implement something over you "imperfect" code, the cost of the
  repayment just doubled, because you have to fix a stack of code now.
  Marking the code with a # TD may warn someone "be aware that someone
  is trying to build over a problem"
- The frequency of interests may increase also over time, and the
  importance may raise as we are paying too much interests, and may be
  better to start considering full repayment.
- One of the solution to a technical debt is "conversion": you just
  render the imperfect solution just less imperfect, that is you don't
  fully repay it, you repay just a little to lower the interests cost or
  frequency. It's not a workaround, it's not a fix, you're just reducing
  its impact. How do you report that in a bug tracking system ?

> I'm kind of split on the idea of templates for Reno.  On the one hand I
> could see it being useful for complex things, but on the other I wonder if
> something 

[openstack-dev] [searchlight] searchlight-ui 4.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for searchlight-ui for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight-ui/

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

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

http://git.openstack.org/cgit/openstack/searchlight-ui/log/?h=stable/queens

Release notes for searchlight-ui can be found at:

http://docs.openstack.org/releasenotes/searchlight-ui/

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

https://bugs.launchpad.net/searchlight

and tag it *queens-rc-potential* to bring it to the searchlight-ui
release crew's attention.


__
OpenStack Development Mailing List (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] [manila] manila 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for manila for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/manila/

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

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

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/queens

Release notes for manila can be found at:

http://docs.openstack.org/releasenotes/manila/




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

Re: [openstack-dev] [magnum][release] release-post job for openstack/releases failed

[Jeremy Stanley]

On 2018-02-08 18:29:18 -0500 (-0500), Doug Hellmann wrote:
[...]
> Another alternative is to change the job configuration for magnum to use
> release-openstack-server instead of publish-to-pypi, at least for the
> near term. That would give the magnum team more time to make the changes
> need to modify the sdist name for the package.

And yet another (longer-term) alternative is:

https://www.python.org/dev/peps/pep-0541/#removal-of-an-abandoned-project

We're presently trying the same to gain use of the keystone name on
PyPI, and magnum's the only other service we have in that same boat
as far as I'm aware. In both cases the projects have basically been
dead for half a decade (and in the magnum case they never even seem
to have uploaded an initial package at all).
-- 
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] [requirements][kolla][openstack-ansible][puppet][tripleo] requirements unfreeze and you, how you should handle it

[Alex Schultz]

On Thu, Feb 8, 2018 at 2:29 PM, Matthew Thode  wrote:
> As the title states, cycle trailing projects will need to change their
> requirements update behavior until they create stable/queens branches.
>
> When requirements unfreezes we will be doing rocky work, meaning that
> requirements updates to your projects (our master to your master) will
> be for rocky.
>
> I requests that all the projects tagged in the email's subject get a +1
> from a requirements core before merging until they branch stable/queens.
>

For clarity: before merging requirements updates.  So for TripleO
folks please do not merge any requirements updates unless the
requirements cores have +1'd or we've branched Queens.

> Once they branch stable/queens the projects are free to proceed as
> normal.
>
> If the projects tagged in the subject can ack me (email or irc) I'd
> appreciate it, would give us some peace of mind to unfreeze tomorrow.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [magnum][release] release-post job for openstack/releases failed

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2018-02-08 13:00:52 -0600:
> The release job for magnum failed, but luckily it was after tagging and
> branching the release. It was not able to get to the point of uploading a
> tarball to http://tarballs.openstack.org/magnum/ though.
> 
> The problem the job encountered is that magnum is now configured to publish to
> Pypi. The tricky part ends up being that the "magnum" package on Pypi is not
> this magnum project. It appears to be an older abandoned project by someone,
> not related to OpenStack.
> 
> There is an openstack-magnum registered. But since the setup.cfg file in
> openstack/magnum has "name = magnum", it attempts to publish to the one that 
> is
> not ours.
> 
> I have put up a patch to openstack/magnum to change the name to
> openstack-magnum here:
> 
> https://review.openstack.org/#/c/542371/
> 
> That, or something like it, will need to merge and be backported to
> stable/queens before we can get this project published.
> 
> If there are any questions, please feel free to drop in to the
> #openstack-release channel.
> 
> Thanks,
> Sean

Another alternative is to change the job configuration for magnum to use
release-openstack-server instead of publish-to-pypi, at least for the
near term. That would give the magnum team more time to make the changes
need to modify the sdist name for the package.

Doug

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

Re: [openstack-dev] [tripleo] Unbranched repositories and testing

[Alex Schultz]

On Tue, Oct 10, 2017 at 2:24 PM, Emilien Macchi  wrote:
> On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský  wrote:
>> On 5.10.2017 22:40, Alex Schultz wrote:
>>>
>>> Hey folks,
>>>
>>> So I wandered across the policy spec[0] for how we should be handling
>>> unbranched repository reviews and I would like to start a broader
>>> discussion around this topic.  We've seen it several times over the
>>> recent history where a change in oooqe or tripleo-ci ends up affecting
>>> either a stable branch or an additional set of jobs that were not run
>>> on the change.  I think it's unrealistic to run every possible job
>>> combination on every submission and it's also a giant waste of CI
>>> resources.  I also don't necessarily agree that we should be using
>>> depends-on to prove things are fine for a given patch for the same
>>> reasons. That being said, we do need to minimize our risk for patches
>>> to these repositories.
>>>
>>> At the PTG retrospective I mentioned component design structure[1] as
>>> something we need to be more aware of. I think this particular topic
>>> is one of those types of things where we could benefit from evaluating
>>> the structure and policy around these unbranched repositories to see
>>> if we can improve it.  Is there a particular reason why we continue to
>>> try and support deployment of (at least) 3 or 4 different versions
>>> within a single repository?  Are we adding new features that really
>>> shouldn't be consumed by these older versions such that perhaps it
>>> makes sense to actually create stable branches?  Perhaps there are
>>> some other ideas that might work?
>>
>>
>> Other folks probably have a better view of the full context here, but i'll
>> chime in with my 2 cents anyway..
>>
>> I think using stable branches for tripleo-quickstart-extras could be worth
>> it. The content there is quite tightly coupled with the expected TripleO
>> end-user workflows, which tend to evolve considerably between releases.
>> Branching extras might be a good way to "match the reality" in that sense,
>> and stop worrying about breaking older workflows. (Just recently it came up
>> that the upgrade workflow in O is slightly updated to make it work in P, and
>> will change quite a bit for Q. Minor updates also changed between O and P.)
>>
>> I'd say that tripleo-quickstart is a different story though. It seems fairly
>> release-agnostic in its focus. We may want to keep it unbranched (?). That
>> probably applies even more for tripleo-ci, where ability to make changes
>> which affect how TripleO does CIing in general, across releases, is IMO a
>> significant feature.
>>
>> Maybe branching quickstart-extras might require some code reshuffling
>> between what belongs there and what belongs into quickstart itself.
>
> I agree a lot with Jirka and I think branching oooq-extras would be a
> good first start to see how it goes.
> If we find it helpful and working correctly, we could go the next
> steps and see if there is any other repo that could be branched
> (tripleo-ci or oooq) but I guess for now the best candidate is
> oooq-extras.
>

I'm resurrecting this thread as we seemed to have done it again[0]
with a change oooq-extras master breaking stable/pike.  So I would
propose that we start investigating branching oooq-extras.  Does
anyone see any blocking issues with starting to branch this
repository?

Thanks,
-Alex

[0] https://bugs.launchpad.net/tripleo/+bug/1748315


>> (Just my 2 cents, i'm likely not among the most important stakeholders in
>> this...)
>>
>> Jirka
>>
>>
>>>
>>> Thanks,
>>> -Alex
>>>
>>> [0] https://review.openstack.org/#/c/478488/
>>> [1] http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jpg
>>>
>>> __
>>> OpenStack Development Mailing List (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
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [reno][tripleo] an alternative approach to known issues

[Ben Nemec]

So TripleO has a tech debt policy: 
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tech-debt-tracking.html 
(and I'm tagging tripleo on this thread for visibility).


It essentially comes down to: open a bug, tag it "tech-debt", and 
reference it in the code near the tech debt.  I kind of like that 
approach because it makes use of the existing integration between Gerrit 
and Launchpad, and we don't have to invent a new system for triaging 
tech debt.  It just gets treated as the appropriate level bug.


I guess my question then would be whether there is sufficient advantage 
to inventing a new system in Reno when we already have systems in place 
that seem suited to this.  I have a few specific thoughts below too.


On 02/08/2018 04:43 PM, Gabriele Cerami wrote:

Hi,

sometimes it happens, while reviewing a patch, to find an issue that
is not quite a bug, because it doesn't limit functionality, but
may represent a problem in some corner case, or with some possible
future modification in some component involved in the patch; it may
best be described as a weakness in the code, which may happen only under
certain circumstances.
The author, for some time or complexity constraint is creating a
technical debt, or making a micro design choice.

How to keep track of the issue ? How, after 6 month when there's time
and bandwidth to look at the problem again, can this note be found and
issue dealt in the way it deserves ?
How to help prioritize then the list of issues left behind during the
duration of a release ?
Nobody is going to read all the comments on all the merged patches in
the past months, to find all the objections.
Also technical debts cannot be treated like bugs, because they have a
different life span. A bug is opened and closed for good after a while.


I'm not sure I agree.  Bugs stay open until they are fixed/won't fixed. 
Tech debt stays open until it is fixed/won't fixed.  We've had bugs open 
for years for things that are tricky to fix.  Arguably those are tech 
debt too, but in any case I'm not aware of any problems with using the 
bug tracker to manage them.



A technical debt may be carried for long time, and it would be perfectly
natural to mark it as something to just live with, and pay the interest
for, because the time required to solve it it's not worth it. And
despite that, it's important to keep track of them because an eventual
reevaluation of the interests cost or a change in the surroundings (a
new requirement that breaks an assumption) may lead to a different
decision after some time.

The way technical debts are treated right now officially is by adding a
TODO note inside the code, or maybe adding a "issue" field in release
notes.
I would like to expand this TODO note, and the known issue field,
make it become something more structured.
I thought about reno, to create a technical debt register/micro design
document.
A developer would generate a UUID, put on the code a comment

# TD: 

and then add the description in reno. A simple yaml associative array
with three or four keys: UUID, description, consequences, options, which
may describe either the problem or the micro design choice and
assumption without which the code may show these weaknesses.
The description would stay with the code, submitted with the same
patch with which it was introduced. Then when it's time, a report on all
these description could be created to evaluate, prioritize and
eventually close the gap that was created, or just mark that as "prefer
to just deal with the consequences"

One may later incur in a problem a number of times, find the piece of
code responsible, and see that the problem is know, and immediately
raise its impact to request a reevaluation.
Or we may realize that the code that creates a certain amount of
weaknesses is going to be deleted, and we can close all the items
related to it.

The creation and handling of such items could add too much of a burden
to the developer, for these reasons, I would prefer to automate some
part of the creation, for example the UUID generation, date expansion,
status change on the item.

I used this, to try out how this automation could work

https://review.openstack.org/538233

which could add basic logic to the templates, to automate some of the
tasks.

This idea certainly requires refinement (for example what happens when
the weakness is discovered at a later time), but I would like to
understand if it's possible to use reno for this approach. Any feedback
would be highly appreciated.


I'm kind of split on the idea of templates for Reno.  On the one hand I 
could see it being useful for complex things, but on the other I wonder 
if something complex enough to require a template actually belongs in 
release notes or if it should go in formal documentation.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [reno] an alternative approach to known issues

[Gabriele Cerami]

Hi,

sometimes it happens, while reviewing a patch, to find an issue that
is not quite a bug, because it doesn't limit functionality, but
may represent a problem in some corner case, or with some possible
future modification in some component involved in the patch; it may
best be described as a weakness in the code, which may happen only under
certain circumstances.
The author, for some time or complexity constraint is creating a
technical debt, or making a micro design choice.

How to keep track of the issue ? How, after 6 month when there's time
and bandwidth to look at the problem again, can this note be found and
issue dealt in the way it deserves ?
How to help prioritize then the list of issues left behind during the
duration of a release ?
Nobody is going to read all the comments on all the merged patches in
the past months, to find all the objections.
Also technical debts cannot be treated like bugs, because they have a
different life span. A bug is opened and closed for good after a while.
A technical debt may be carried for long time, and it would be perfectly
natural to mark it as something to just live with, and pay the interest
for, because the time required to solve it it's not worth it. And
despite that, it's important to keep track of them because an eventual
reevaluation of the interests cost or a change in the surroundings (a
new requirement that breaks an assumption) may lead to a different
decision after some time.

The way technical debts are treated right now officially is by adding a
TODO note inside the code, or maybe adding a "issue" field in release
notes.
I would like to expand this TODO note, and the known issue field,
make it become something more structured.
I thought about reno, to create a technical debt register/micro design
document.
A developer would generate a UUID, put on the code a comment

# TD: 

and then add the description in reno. A simple yaml associative array
with three or four keys: UUID, description, consequences, options, which
may describe either the problem or the micro design choice and
assumption without which the code may show these weaknesses.
The description would stay with the code, submitted with the same
patch with which it was introduced. Then when it's time, a report on all
these description could be created to evaluate, prioritize and
eventually close the gap that was created, or just mark that as "prefer
to just deal with the consequences"

One may later incur in a problem a number of times, find the piece of
code responsible, and see that the problem is know, and immediately
raise its impact to request a reevaluation.
Or we may realize that the code that creates a certain amount of
weaknesses is going to be deleted, and we can close all the items
related to it.

The creation and handling of such items could add too much of a burden
to the developer, for these reasons, I would prefer to automate some
part of the creation, for example the UUID generation, date expansion,
status change on the item.

I used this, to try out how this automation could work

https://review.openstack.org/538233

which could add basic logic to the templates, to automate some of the
tasks.

This idea certainly requires refinement (for example what happens when
the weakness is discovered at a later time), but I would like to
understand if it's possible to use reno for this approach. Any feedback
would be highly appreciated.

Thanks

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

[openstack-dev] [freezer] freezer-dr 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for freezer-dr for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-dr/

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

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

http://git.openstack.org/cgit/openstack/freezer-dr/log/?h=stable/queens

Release notes for freezer-dr can be found at:

http://docs.openstack.org/releasenotes/freezer-dr/




__
OpenStack Development Mailing List (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] [freezer] freezer-api 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for freezer-api for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-api/

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

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

http://git.openstack.org/cgit/openstack/freezer-api/log/?h=stable/queens

Release notes for freezer-api can be found at:

http://docs.openstack.org/releasenotes/freezer-api/




__
OpenStack Development Mailing List (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] [freezer] freezer-web-ui 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for freezer-web-ui for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-web-ui/

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

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

http://git.openstack.org/cgit/openstack/freezer-web-ui/log/?h=stable/queens

Release notes for freezer-web-ui can be found at:

http://docs.openstack.org/releasenotes/freezer-web-ui/




__
OpenStack Development Mailing List (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] [freezer] freezer 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for freezer for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer/

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

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

http://git.openstack.org/cgit/openstack/freezer/log/?h=stable/queens

Release notes for freezer can be found at:

http://docs.openstack.org/releasenotes/freezer/




__
OpenStack Development Mailing List (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][kolla][openstack-ansible][puppet][tripleo] requirements unfreeze and you, how you should handle it

[Matthew Thode]

As the title states, cycle trailing projects will need to change their
requirements update behavior until they create stable/queens branches.

When requirements unfreezes we will be doing rocky work, meaning that
requirements updates to your projects (our master to your master) will
be for rocky.

I requests that all the projects tagged in the email's subject get a +1
from a requirements core before merging until they branch stable/queens.

Once they branch stable/queens the projects are free to proceed as
normal.

If the projects tagged in the subject can ack me (email or irc) I'd
appreciate it, would give us some peace of mind to unfreeze tomorrow.

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

[openstack-dev] [glance] glance 16.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for glance for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/glance/

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

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

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

Release notes for glance can be found at:

http://docs.openstack.org/releasenotes/glance/




__
OpenStack Development Mailing 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] [requirements][tricircle][heat] more help needed

[Matthew Thode]

On 18-02-08 15:20:54, Matthew Thode wrote:
> The following do not have a stable/queens branch and could cause
> requirements to remain frozen until they do.  If I get no response by
> tomorrow afternoon my time (about 24 horus from the time this email was
> SENT) I may still move to unfreeze requirements.
> 
> [tricircle]
> tricircle
> 
> [heat]
> heat-agents
> 
> There are other projects needing a stable/queens branch as well, but
> those are the main two.  Below you'll find all the non-cycle-trailing
> projects that do requirements syncs without stable/queens branches.
> 
> 
> Projects without team or release model could not be found in 
> openstack/releases for queens
> openstack/almanach
> openstack/compute-hyperv
> openstack/ekko
> openstack/gce-api
> openstack/glare
> openstack/ironic-staging-drivers
> openstack/kosmos
> openstack/mixmatch
> openstack/mogan
> openstack/nemesis
> openstack/networking-dpm
> openstack/networking-hpe
> openstack/networking-l2gw
> openstack/nova-dpm
> openstack/nova-lxd
> openstack/os-xenapi
> openstack/python-glareclient
> openstack/python-kingbirdclient
> openstack/python-moganclient
> openstack/python-oneviewclient
> openstack/python-valenceclient
> openstack/swauth
> openstack/tap-as-a-service
> openstack/trio2o
> openstack/valence
> openstack/vmware-nsx
> openstack/vmware-nsxlib
> openstackclientOpenStackClient
> os-service-types   OpenStackSDK
> anchor Security
> ec2-apiec2-api
> magnum-ui  magnum
> manila-image-elements  manila
> masakari   masakari
> masakari-monitors  masakari
> python-masakariclient  masakari
> tacker tacker
> tacker-horizon tacker
> 
> Repos with type: horizon-plugin
> blazar-dashboard   blazar
> heat-dashboard heat
> manila-ui  manila
> senlin-dashboard   senlin
> solum-dashboardsolum
> 
> Repos with type: other
> heat-agentsheat
> networking-hyperv  winstackers
> 
> Repos with type: service
> tricircle  tricircle
> 

adding tags...

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

[openstack-dev] [requirements] more help needed

[Matthew Thode]

The following do not have a stable/queens branch and could cause
requirements to remain frozen until they do.  If I get no response by
tomorrow afternoon my time (about 24 horus from the time this email was
SENT) I may still move to unfreeze requirements.

[tricircle]
tricircle

[heat]
heat-agents

There are other projects needing a stable/queens branch as well, but
those are the main two.  Below you'll find all the non-cycle-trailing
projects that do requirements syncs without stable/queens branches.


Projects without team or release model could not be found in openstack/releases 
for queens
openstack/almanach
openstack/compute-hyperv
openstack/ekko
openstack/gce-api
openstack/glare
openstack/ironic-staging-drivers
openstack/kosmos
openstack/mixmatch
openstack/mogan
openstack/nemesis
openstack/networking-dpm
openstack/networking-hpe
openstack/networking-l2gw
openstack/nova-dpm
openstack/nova-lxd
openstack/os-xenapi
openstack/python-glareclient
openstack/python-kingbirdclient
openstack/python-moganclient
openstack/python-oneviewclient
openstack/python-valenceclient
openstack/swauth
openstack/tap-as-a-service
openstack/trio2o
openstack/valence
openstack/vmware-nsx
openstack/vmware-nsxlib
openstackclientOpenStackClient
os-service-types   OpenStackSDK
anchor Security
ec2-apiec2-api
magnum-ui  magnum
manila-image-elements  manila
masakari   masakari
masakari-monitors  masakari
python-masakariclient  masakari
tacker tacker
tacker-horizon tacker

Repos with type: horizon-plugin
blazar-dashboard   blazar
heat-dashboard heat
manila-ui  manila
senlin-dashboard   senlin
solum-dashboardsolum

Repos with type: other
heat-agentsheat
networking-hyperv  winstackers

Repos with type: service
tricircle  tricircle

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

[openstack-dev] [congress] congress-dashboard 2.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for congress-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress-dashboard/

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

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


http://git.openstack.org/cgit/openstack/congress-dashboard/log/?h=stable/queens

Release notes for congress-dashboard can be found at:

http://docs.openstack.org/releasenotes/congress-dashboard/

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

https://bugs.launchpad.net/congress

and tag it *queens-rc-potential* to bring it to the congress-dashboard
release crew's attention.


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

[openstack-dev] [searchlight] searchlight 4.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for searchlight for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight/

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

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

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/queens

Release notes for searchlight can be found at:

http://docs.openstack.org/releasenotes/searchlight/




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

[openstack-dev] [searchlight] searchlight 4.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for searchlight for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/searchlight/

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

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

http://git.openstack.org/cgit/openstack/searchlight/log/?h=stable/queens

Release notes for searchlight can be found at:

http://docs.openstack.org/releasenotes/searchlight/




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

[openstack-dev] [congress] congress 7.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for congress for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress/

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

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

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

Release notes for congress can be found at:

http://docs.openstack.org/releasenotes/congress/




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

[openstack-dev] [trove] trove 9.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for trove for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/trove/

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

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

http://git.openstack.org/cgit/openstack/trove/log/?h=stable/queens

Release notes for trove can be found at:

http://docs.openstack.org/releasenotes/trove/




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

[openstack-dev] [designate] designate-dashboard 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for designate-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/designate-dashboard/

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

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


http://git.openstack.org/cgit/openstack/designate-dashboard/log/?h=stable/queens

Release notes for designate-dashboard can be found at:

http://docs.openstack.org/releasenotes/designate-dashboard/




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

[openstack-dev] [trove] trove-dashboard 10.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for trove-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/trove-dashboard/

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

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

http://git.openstack.org/cgit/openstack/trove-dashboard/log/?h=stable/queens

Release notes for trove-dashboard can be found at:

http://docs.openstack.org/releasenotes/trove-dashboard/




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

[openstack-dev] [designate] designate 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for designate for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/designate/

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

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

http://git.openstack.org/cgit/openstack/designate/log/?h=stable/queens

Release notes for designate can be found at:

http://docs.openstack.org/releasenotes/designate/

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

https://bugs.launchpad.net/designate

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


__
OpenStack Development Mailing 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] [charms] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[James Page]

+1 from me

On Thu, 8 Feb 2018 at 18:23 Billy Olsen  wrote:

> Dmitrii easily gets a +1 from me!
>
> On 02/08/2018 09:42 AM, Alex Kavanagh wrote:
> > Hi
> >
> > I'd like to propose Dmitrii Shcherbakov to join the launchpad
> > "OpenStack Charmers" team.  He's done some tremendous work on existing
> > the charms, has developed some new ones, and has really developed his
> > understanding of configuring and implementing OpenStack.  I think he'd
> > make a great addition to the team.
> >
> > Thanks
> > Alex.
> >
> >
> > --
> > Alex Kavanagh - Software Engineer
> > Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Zane Bitter]

On 07/02/18 12:24, Goutham Pratapa wrote:

 >Yes as you said it can be interpreted as a tool that can
orchestrate multiple-regions. 


Actually from your additional information I'm now getting the impression 
that you are, in fact, positioning this as a partial competitor to Heat.



Just to be sure does openstack already has project which can
replicate the resources and orchestrate???


OpenStack has an orchestration service - Heat - and it allows you to do 
orchestration across multiple regions by creating a nested Stack in an 
arbitrary region as a resource in a Heat Stack.[1]


Heat includes the ability to create Nova keypairs[2] and even, for those 
users with sufficient privileges, flavors[3] and quotas[4][5][6]. (It 
used to be able to create Glance images as well, but this was deprecated 
because it is not feasible using the Glance v2 API.)


[1] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::Stack
[2] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::KeyPair
[3] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Flavor
[4] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Quota
[5] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Cinder::Quota
[6] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Neutron::Quota



why because In coming
cycle our idea is that a user just gives a VM-ID or Vm-name and we
sync all the resources with which the vm is actually created
ofcourse we cant have the same network in target-region so we may
need the network-id or port-id from the target region from user so
that kingbird will boot up the requested vm in the target region(s).


So it sounds like you are starting from the premise that users will 
create stuff in an ad-hoc way, then later discover that they need to 
replicate their ad-hoc deployments to multiple regions, and you're 
building a tool to do that. Heat, on the other hand, starts from the 
premise that users will invest a little up-front effort to create a 
declarative definition of their deployment, which they can then deploy 
repeatably in multiple (or the same!) regions. Our experience is that 
people have shown themselves to be quite willing to do this, because 
repeatable deployments have lots of benefits.


Looking at the things you want to synchronise:

* Quotas

Operators can already use Heat templates to manage these if they so desire.

* Flavors

Some clouds allow users to create flavors, and those users can use Heat 
templates to manage them already.


Operators can *not* use Heat templates to manage flavors in the same way 
that that can with quotas, because the OS::Nova::Flavor resource was 
designed with the above use-case in mind instead. (Specifically, it 
doesn't allow you to set the name.) Support has been requested for it in 
the past, however, and given the other kinds of admin-only resources we 
have in Heat (Quotas, Keystone resources) it would be consistent to 
modify OS::Nova::Flavor to allow this additional use case.


It's possible that operators could benefit from better/other tooling for 
Flavors and Quotas. In fact, the reason I've pushed back against some of 
the admin-facing stuff in Heat is that it often seems to me that Heat is 
an awkward tool for managing global-singleton or tenant-local-singleton 
administrator resources. It's definitely fine for multiple tools to 
co-exist, although a separate OpenStack service with an API seems like 
it could be overkill to me.


* Keypairs

This is a non-issue IMHO.

* Images

I agree with what I think Jay is suggesting here - not that there should 
be a single global Glance handling multiple regions (locality is 
important for images), but definitely some sort of multi-region support 
in Glance (e.g. a built-in way to automatically replicate an image to 
other regions) would be a better solution than an external service doing 
it. Glance is always looking for new contributors :)


Though I really think the problem here is that there aren't good ways to 
automate image upload in general with the Glance v2 API; the multiregion 
part is just a for-loop. Allowing Glance to download an image from a URL 
(or even if it were limited to Swift objects) instead of having to 
upload one to it would allow us to resurrect OS::Glance::Image in Heat.


* Other user resources

These are already handled, in a much more general way, by Heat.


Honestly, it seems like a lot of wheels are being reinvented here. I 
think it would be more productive to start with a list of use cases and 
see whether the gaps can be covered by changes to existing services that 
they would consider in-scope.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] [OpenStack Foundation] CFP Deadline Today - OpenStack Summit Vancouver

[Jimmy McArthur]

Hi everyone,

The Vancouver Summit 
 CFP closes *TODAY at 
11:59pm Pacific Time (February 9 at 6:59am UTC).*


Get your talks in for:
• Container infrastructure
• Edge computing
• CI/CD
• HPC/GPU/AI
• Open source community
• OpenStack private, public and hybrid cloud

View topic ideas for each track HERE 
 and 
submit your proposals 
 before 
the deadline!


Please note, the sessions that are included in your sponsorship package 
or purchased as an add-on do not go through the CFP process.


If you have any questions, please email sum...@openstack.org 
.


Cheers,
Jimmy



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

[openstack-dev] [magnum] Release of openstack/magnum failed

[Sean McGinnis]

Apologies, I forwarded the wrong one just a bit ago. See below for the actual
links to the magnum release job failures if you wish to take a look.

Sean

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

Date: Thu, 08 Feb 2018 18:06:54 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/magnum failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- release-openstack-python 
http://logs.openstack.org/df/dff1ac0f8248a75c39c5b9449de0b6c83906aff5/release/release-openstack-python/e923153/
 : POST_FAILURE in 7m 23s
- 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-dev] [magnum][release] release-post job for openstack/releases failed

[Sean McGinnis]

The release job for magnum failed, but luckily it was after tagging and
branching the release. It was not able to get to the point of uploading a
tarball to http://tarballs.openstack.org/magnum/ though.

The problem the job encountered is that magnum is now configured to publish to
Pypi. The tricky part ends up being that the "magnum" package on Pypi is not
this magnum project. It appears to be an older abandoned project by someone,
not related to OpenStack.

There is an openstack-magnum registered. But since the setup.cfg file in
openstack/magnum has "name = magnum", it attempts to publish to the one that is
not ours.

I have put up a patch to openstack/magnum to change the name to
openstack-magnum here:

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

That, or something like it, will need to merge and be backported to
stable/queens before we can get this project published.

If there are any questions, please feel free to drop in to the
#openstack-release channel.

Thanks,
Sean

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

Date: Thu, 08 Feb 2018 17:09:44 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] release-post job for openstack/releases failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- tag-releases 
http://logs.openstack.org/11/1160e02315eaef3a8380af3d6dd9f707eccc214e/release-post/tag-releases/ff8305f/
 : TIMED_OUT in 32m 28s
- publish-static publish-static : 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

Re: [openstack-dev] [Openstack-sigs] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

On Thu, Feb 8, 2018 at 6:21 PM Kendall Nelson  wrote:

> This link might work better for everyone:
>
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>

+1 thanks this is editable

>
> -Kendall (diablo_rojo)
>
>
> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
> wrote:
>
>> Hello PTLs and SIG Chairs!
>>
>> So here's the deal, we have 50 spots that are first come, first
>> served. We have slots available before and after lunch both Tuesday and
>> Thursday.
>>
>> The google sheet here[1] should be set up so you have access to edit, but
>> if you can't for some reason just reply directly to me and I can add your
>> team to the list (I need team/sig name and contact email).
>>
>> I will be locking the google sheet on *Monday February 26th so I need to
>> know if your team is interested by then. *
>>
>> See you soon!
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>>
>>
>>
>> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Done!

On Thu, Feb 8, 2018 at 10:13 AM Matthew Thode 
wrote:

> On 18-02-08 10:00:58, Michael Johnson wrote:
> > Hi Kendall,
> >
> > Can you put Octavia down for 2:10 on Thursday after neutron?
> > Thanks,
> > Michael
> >
> >
> > On Wed, Feb 7, 2018 at 9:15 PM, Kendall Nelson 
> wrote:
> > > Hello PTLs and SIG Chairs!
> > >
> > > So here's the deal, we have 50 spots that are first come, first
> served. We
> > > have slots available before and after lunch both Tuesday and Thursday.
> > >
> > > The google sheet here[1] should be set up so you have access to edit,
> but if
> > > you can't for some reason just reply directly to me and I can add your
> team
> > > to the list (I need team/sig name and contact email).
> > >
> > > I will be locking the google sheet on Monday February 26th so I need
> to know
> > > if your team is interested by then.
> > >
> > > See you soon!
> > >
> > > - Kendall Nelson (diablo_rojo)
> > >
> > > [1]
> > >
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
> > >
>
> And Requirements after that (at 2:20 Thursday)
>
> --
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing List (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] [charms] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[Billy Olsen]

Dmitrii easily gets a +1 from me!

On 02/08/2018 09:42 AM, Alex Kavanagh wrote:
> Hi
>
> I'd like to propose Dmitrii Shcherbakov to join the launchpad
> "OpenStack Charmers" team.  He's done some tremendous work on existing
> the charms, has developed some new ones, and has really developed his
> understanding of configuring and implementing OpenStack.  I think he'd
> make a great addition to the team.
>
> Thanks
> Alex.
>
>
> -- 
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
>
> __
> OpenStack Development Mailing List (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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Done!

On Thu, Feb 8, 2018 at 9:39 AM Andrea Frittoli 
wrote:

> Hello Kendall,
>
> QA Team Tue at 11:00 please :)
>
> Andrea
>
> On Thu, Feb 8, 2018 at 5:37 PM Kendall Nelson 
> wrote:
>
>> Done!
>>
>> On Thu, 8 Feb 2018, 8:56 am Miguel Lavalle,  wrote:
>>
>>> Hi Kendall,
>>>
>>> Can you add Neutron on Thursday at 2pm. If that is not available, then
>>> anytime Wednesday or Thursday. I am the contact: mig...@mlavalle.com
>>>
>>> Thanks
>>>
>>> On Wed, Feb 7, 2018 at 11:15 PM, Kendall Nelson 
>>> wrote:
>>>
 Hello PTLs and SIG Chairs!

 So here's the deal, we have 50 spots that are first come, first
 served. We have slots available before and after lunch both Tuesday and
 Thursday.

 The google sheet here[1] should be set up so you have access to edit,
 but if you can't for some reason just reply directly to me and I can add
 your team to the list (I need team/sig name and contact email).

 I will be locking the google sheet on *Monday February 26th so I need
 to know if your team is interested by then. *

 See you soon!

 - Kendall Nelson (diablo_rojo)

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






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


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

Re: [openstack-dev] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

This link might work better for everyone:
https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing

-Kendall (diablo_rojo)

On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson  wrote:

> Hello PTLs and SIG Chairs!
>
> So here's the deal, we have 50 spots that are first come, first served. We
> have slots available before and after lunch both Tuesday and Thursday.
>
> The google sheet here[1] should be set up so you have access to edit, but
> if you can't for some reason just reply directly to me and I can add your
> team to the list (I need team/sig name and contact email).
>
> I will be locking the google sheet on *Monday February 26th so I need to
> know if your team is interested by then. *
>
> See you soon!
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>
>
>
>
>
__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Matthew Thode]

On 18-02-08 10:00:58, Michael Johnson wrote:
> Hi Kendall,
> 
> Can you put Octavia down for 2:10 on Thursday after neutron?
> Thanks,
> Michael
> 
> 
> On Wed, Feb 7, 2018 at 9:15 PM, Kendall Nelson  wrote:
> > Hello PTLs and SIG Chairs!
> >
> > So here's the deal, we have 50 spots that are first come, first served. We
> > have slots available before and after lunch both Tuesday and Thursday.
> >
> > The google sheet here[1] should be set up so you have access to edit, but if
> > you can't for some reason just reply directly to me and I can add your team
> > to the list (I need team/sig name and contact email).
> >
> > I will be locking the google sheet on Monday February 26th so I need to know
> > if your team is interested by then.
> >
> > See you soon!
> >
> > - Kendall Nelson (diablo_rojo)
> >
> > [1]
> > https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
> >

And Requirements after that (at 2:20 Thursday)

-- 
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][Kingbird]Multi-Region Orchestrator

[Zane Bitter]

On 07/02/18 11:20, Chris Friesen wrote:

One use-case I've seen for this sort of thing is someone that has multiple 
geographically-separate clouds, and maybe they want to run the same heat stack 
in all of them.

Something like "create a keypair in each of the clouds with the same 
public key and same name" could be done by the end user with some 
coding, but it's convenient to have a tool to do it for you.


You can do this inside the Heat stack:

https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::KeyPair

- ZB

__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Michael Johnson]

Hi Kendall,

Can you put Octavia down for 2:10 on Thursday after neutron?
Thanks,
Michael


On Wed, Feb 7, 2018 at 9:15 PM, Kendall Nelson  wrote:
> Hello PTLs and SIG Chairs!
>
> So here's the deal, we have 50 spots that are first come, first served. We
> have slots available before and after lunch both Tuesday and Thursday.
>
> The google sheet here[1] should be set up so you have access to edit, but if
> you can't for some reason just reply directly to me and I can add your team
> to the list (I need team/sig name and contact email).
>
> I will be locking the google sheet on Monday February 26th so I need to know
> if your team is interested by then.
>
> See you soon!
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>
>
>
>
> __
> OpenStack Development Mailing List (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] [cinder] cinder 12.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

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

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

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/queens

Release notes for cinder can be found at:

http://docs.openstack.org/releasenotes/cinder/




__
OpenStack Development Mailing List (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][api] POST /api-sig/news

[Ed Leafe]

Greetings OpenStack community,

Today's meeting was chock-full of interesting discussion. Let me recap it for 
you.

We began with a follow-up conversation about the use of "action" URLs (as 
opposed to resource-based URLs). The origin of this discussion came from an 
email posted to the dev list by Tommy Hu [7], describing how several types of 
actions are currently being handled through the cinder and nova REST 
interfaces. After last week's API-SIG discussion, edleafe replied [8], which 
was followed by some more email discussion. It seems that there is still a lot 
of impetus to simply "get things working" instead of "let's do it in a 
consistent manner across OpenStack". If you have an opinion on this issue, 
please reply on the mailing list!

On the topic of the PTG, the SIG has created an etherpad [9] where agenda items 
are starting to be proposed. If you have any topic that you would like to 
discuss, or see discussed, please add it to that etherpad. We also decided that 
we are not cute enough to merit taking a group photo at the PTG.

We discussed the spec by Gilles Dubreuil [10] for creating a guideline for 
API-Schema to make APIs more machine-discoverable. We felt that this was more 
of a one-off need rather than something we'd like to see rolled out across all 
OpenStack APIs. Furthermore, API-Schema will be problematic for services that 
use microversions. If you have some insight or opinions on this, please add 
your comments to that review.

cdent then won the award for the Quote of the Day [11].

Finally, we discussed a bug [12] that is the result of the Nova API not 
properly including caching information in the headers of its replies. There is 
some pushback from the Nova team as to whether this is a bug or a request for a 
new feature. We unanimously agreed that it is indeed a bug, and should be 
remedied as soon as possible. Again, please add your perspective to that bug 
report.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week.

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126334.html
[8] http://lists.openstack.org/pipermail/openstack-dev/2018-February/126891.html
[9] https://etherpad.openstack.org/p/api-sig-ptg-rocky
[10] https://review.openstack.org/#/c/524467/
[11] 
http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-08-16.00.log.html#l-131
[12] https://bugs.launchpad.net/nova/+bug/1747935

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






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

Re: [openstack-dev] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

Hello Kendall,

QA Team Tue at 11:00 please :)

Andrea

On Thu, Feb 8, 2018 at 5:37 PM Kendall Nelson  wrote:

> Done!
>
> On Thu, 8 Feb 2018, 8:56 am Miguel Lavalle,  wrote:
>
>> Hi Kendall,
>>
>> Can you add Neutron on Thursday at 2pm. If that is not available, then
>> anytime Wednesday or Thursday. I am the contact: mig...@mlavalle.com
>>
>> Thanks
>>
>> On Wed, Feb 7, 2018 at 11:15 PM, Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Done!

On Thu, 8 Feb 2018, 8:56 am Miguel Lavalle,  wrote:

> Hi Kendall,
>
> Can you add Neutron on Thursday at 2pm. If that is not available, then
> anytime Wednesday or Thursday. I am the contact: mig...@mlavalle.com
>
> Thanks
>
> On Wed, Feb 7, 2018 at 11:15 PM, Kendall Nelson 
> wrote:
>
>> Hello PTLs and SIG Chairs!
>>
>> So here's the deal, we have 50 spots that are first come, first
>> served. We have slots available before and after lunch both Tuesday and
>> Thursday.
>>
>> The google sheet here[1] should be set up so you have access to edit, but
>> if you can't for some reason just reply directly to me and I can add your
>> team to the list (I need team/sig name and contact email).
>>
>> I will be locking the google sheet on *Monday February 26th so I need to
>> know if your team is interested by then. *
>>
>> See you soon!
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][neutron] bare metal on vxlan network

[Mitchell Jameson]

Hi Moshe,

I'm not aware of any mechanism drivers that actually create the VTEP (that
will be a manual step,) but there are drivers that support Hierarchical
Port Binding [1]. The networking-arista mechanism driver [2] is one such
driver, but there are others. Such drivers will configure a VLAN to VNI
mapping on switches based on the segmentation IDs of the neutron network
segments bound at each port binding level.

In such a deployment, you'd create a VXLAN network in neutron. You could
then launch a baremetal instance on that network. The mechanism driver will
then be responsible for dynamically allocating a VLAN for the
baremetal<->TOR switch segment and mapping that VLAN to the VXLAN network's
VNI on the TOR switch such that the baremetal instance is connected to the
VXLAN fabric segment.

[1] https://specs.openstack.org/openstack/neutron-specs/
specs/kilo/ml2-hierarchical-port-binding.html
[2] https://github.com/openstack/networking-arista

On Wed, Feb 7, 2018 at 10:06 PM, Moshe Levi  wrote:

> Hi all,
>
>
>
> Ironic supports  mutli tenancy for quite few releases and according to the
> spec [1] it can work with vlan/vxlan networks.
>
> I see lot of mechanism driver that support vlan network such as [2] and
> [3] , but I didn't find any mechanism driver that work on vxlan network.
>
> Is there a mechanism driver that can configure vtep on a switch exist for
> the bare metal?
>
>
>
> Help would be appreciated
>
>
>
>
>
> [1] https://specs.openstack.org/openstack/ironic-specs/specs/
> not-implemented/ironic-ml2-integration.html
>
> [2] https://github.com/openstack/networking-arista
>
> [3] https://github.com/openstack/networking-generic-switch
>
> __
> OpenStack Development Mailing List (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] [blazar] blazar 1.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for blazar for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/blazar/

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

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

http://git.openstack.org/cgit/openstack/blazar/log/?h=stable/queens

Release notes for blazar can be found at:

http://docs.openstack.org/releasenotes/blazar/

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

https://launchpad.net/blazar

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


__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Miguel Lavalle]

Hi Kendall,

Can you add Neutron on Thursday at 2pm. If that is not available, then
anytime Wednesday or Thursday. I am the contact: mig...@mlavalle.com

Thanks

On Wed, Feb 7, 2018 at 11:15 PM, Kendall Nelson 
wrote:

> Hello PTLs and SIG Chairs!
>
> So here's the deal, we have 50 spots that are first come, first served. We
> have slots available before and after lunch both Tuesday and Thursday.
>
> The google sheet here[1] should be set up so you have access to edit, but
> if you can't for some reason just reply directly to me and I can add your
> team to the list (I need team/sig name and contact email).
>
> I will be locking the google sheet on *Monday February 26th so I need to
> know if your team is interested by then. *
>
> See you soon!
>
> - Kendall Nelson (diablo_rojo)
>
> [1] https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoT
> ypX66eNURsopQY/edit?usp=sharing
>
>
>
>
> __
> OpenStack Development Mailing List (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] [neutron] [networking-ovn] Rocky PTG

[Miguel Angel Ajo Pelayo]

I have created an etherpad for networking-ovn, if
https://etherpad.openstack.org/p/networking-ovn-ptg-rocky with some topics
I thought are relevant.

But please feel free to add anything you believe it could be interesting
and fill attendance so it's easier to sync & meet. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] Propose Dmitrii Shcherbakov for OpenStack Charmers team.

[Alex Kavanagh]

Hi

I'd like to propose Dmitrii Shcherbakov to join the launchpad "OpenStack
Charmers" team.  He's done some tremendous work on existing the charms, has
developed some new ones, and has really developed his understanding of
configuring and implementing OpenStack.  I think he'd make a great addition
to the team.

Thanks
Alex.


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
__
OpenStack Development Mailing List (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] networking-powervm 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for networking-powervm for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-powervm/

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

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


http://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/queens

Release notes for networking-powervm can be found at:

http://docs.openstack.org/releasenotes/networking-powervm/




__
OpenStack Development Mailing List (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_powervm 6.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for nova_powervm for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova-powervm/

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

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

http://git.openstack.org/cgit/openstack/nova_powervm/log/?h=stable/queens

Release notes for nova_powervm can be found at:

http://docs.openstack.org/releasenotes/nova_powervm/




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

[openstack-dev] [horizon] PTG Planning Etherpad

[Ivan Kolodyazhny]

Hi team,

In case if you missed it, it's a friendly reminder that we've got etherpad
[1] with Rocky PTG topics proposals.

If you're going to attend it or want to get some topic discussed, please
add your name and topic to the list [1].

Hope to see you all in Dublin.

[1] https://etherpad.openstack.org/p/horizon-ptg-rocky

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
__
OpenStack Development Mailing List (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] [PTG] Last Chance for PTG Dublin Tickets

[Kendall Waters]

Hi everyone,

Yesterday we sold out the upcoming Dublin PTG, and have since received many 
requests for more tickets. We have been working with the venue to accommodate 
extra capacity, but every additional attendee incrementally increases our costs 
$600. We understand the importance of this event and the need to have key team 
members present, so we have negotiated an additional 100 tickets which we will 
partially subsidize to be sold at a $400 ticket price. We recognize this is 
significantly more than we have had to charge in the past, but we still hope 
you can join us in Dublin. 

Please let me know if you have any questions. 

Cheers,
Kendall


Kendall Waters
OpenStack Marketing
kend...@openstack.org



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

Re: [openstack-dev] [release][requirements][monasca] FFE request for monasca-common

[Matthew Thode]

On 18-02-08 14:41:21, Dirk Müller wrote:
> 2018-02-08 11:05 GMT+01:00 Bedyk, Witold :
> 
> > I would like to request FFE for monasca-common to be bumped in upper 
> > constraints. The version has been bumped together with the rest of Monasca 
> > components [1]. Monasca-common is used only in Monasca projects [2].
> 
> The changes between 2.7.0 and 2.8.0 are:
> 
> +2.8.0
> +-
> +
> +* Enable tempest tests as voting
> +* Add messages for testing unicode
> +* Zuul: Remove project name
> +* Remove not used mox library
> +* Updated from global requirements
> +* Updated from global requirements
> 
> 
> The requirements changes are removal of mox, and fix for oslotest to
> sync the queens level requirements. so this looks good to me. +1
> 

Yep, LGTM as well (just approved)

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

[openstack-dev] [vitrage] Tagged Vitrage release candidates and created stable/queens branches

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I tagged the following release candidates for Vitrage:

vitrage 2.1.0
vitrage-dashboard 1.4.1
python-vitrageclient 2.0.0 (already tagged)

All these repositories now have stable/queens branches, so the master can be 
used for Rocky development.

Thanks,
Ifat.


__
OpenStack Development Mailing List (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] [octavia] octavia 2.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for octavia for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia/

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

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

http://git.openstack.org/cgit/openstack/octavia/log/?h=stable/queens

Release notes for octavia can be found at:

http://docs.openstack.org/releasenotes/octavia/




__
OpenStack Development Mailing List (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] [octavia] octavia-dashboard 1.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for octavia-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia-dashboard/

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

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


http://git.openstack.org/cgit/openstack/octavia-dashboard/log/?h=stable/queens

Release notes for octavia-dashboard can be found at:

http://docs.openstack.org/releasenotes/octavia-dashboard/

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

https://storyboard.openstack.org/#!/project/909

and tag it *queens-rc-potential* to bring it to the octavia-dashboard
release crew's attention.


__
OpenStack Development Mailing List (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] [octavia] neutron-lbaas 12.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for neutron-lbaas for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas/

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

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

http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/queens

Release notes for neutron-lbaas can be found at:

http://docs.openstack.org/releasenotes/neutron-lbaas/




__
OpenStack Development Mailing List (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] [octavia] neutron-lbaas-dashboard 4.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for neutron-lbaas-dashboard for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas-dashboard/

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

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


http://git.openstack.org/cgit/openstack/neutron-lbaas-dashboard/log/?h=stable/queens

Release notes for neutron-lbaas-dashboard can be found at:

http://docs.openstack.org/releasenotes/neutron-lbaas-dashboard/

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

https://storyboard.openstack.org/#!/project/907

and tag it *queens-rc-potential* to bring it to the neutron-lbaas-dashboard
release crew's attention.


__
OpenStack Development Mailing 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] cycle highlights for sub-projects

[Armando M.]

On 2 February 2018 at 13:33, Armando M.  wrote:

> Hi neutrinos,
>
> RC1 is fast approaching and this time we can add highlights to the release
> files [1]. If I can ask you anyone interested in contributing to the
> highlights: please review [2].
>
> Miguel and I will make sure they are compiled correctly. We have time
> until Feb 9 to get this done.
>

> Many thanks,
> Armando
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/
> 2017-December/125613.html
> [2] https://review.openstack.org/#/c/540476/
>


Reminder before we cut RC1 by EOB today.

Cheers,
Armando
__
OpenStack Development Mailing 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] [requirements][release] FFE for constraints update for python-tackerclient bug-fix release

[Thierry Carrez]

Matthew Thode wrote:
> It should have time to get in for the freeze, the question I have is
> 'What in openstack is broken if we update upper-contraints after the
> freeze instead of before?'

> A follow up question is 'does this need a global-requirements.txt bump?'

In other words, will the new tacker just work with the old client
release (just not exposing the new feature), or will it fail ? If it
fails, the global-requirements needs to be bumped to require >=0.12.0...

-- 
Thierry Carrez (ttx)



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

[openstack-dev] [release] Release countdown for week R-2, February 10 - 16

[Sean McGinnis]

The end is near!

Before I continue with the countdown info for next week, just a reminder that
today, 8th February, is the RC1 milestone. Please make sure your project
submits a release patch for an RC (cycle-with-milestones) or final
(cycle-with-intermediary) release with a request to create a stable/queens
branch today if you have not already done so.

Development Focus
-

Teams should be working on release critical bugs in preparation of the final
release.

General Information
---

Any cycle-with-milestones projects that missed the RC1 deadline should prepare
an RC1 release as soon as possible.

After all of the cycle-with-milestone projects have branched we will branch
devstack, grenade, and the requirements repos. This will effectively open them
back up for Rocky development, though the focus should still be on finishing up
Queens until the final release.

Actions
-

Watch for any translation patches coming through and merge them quickly.

If your project has a stable/queens branch created, please make sure those
patches are also merged there. Keep in mind there will need to be a final
release candidate cut to capture any merged translations and critical bug fixes
from this branch.

Please also check for completeness in release notes and add any relevant
"prelude" content. These notes are targetted for the downstream consumers of
your project, so it would be great to include any useful information for those
that are going to pick up and use or deploy the Queens version of your project.

We also have the cycle-highlights information in the project deliverable files.
This one is targeted at marketing and other consumers that typically been
pinging PTLs every release asking for "what's new" in this release. If you have
not done so already, please add a few highlights for your team that would be
useful for this kind of consumer.

This would be a good time for any release:independent projects to add the
history for any releases not yet listed in their deliverable file. These files
are under the deliverable/_independent directory in the openstack/releases
repo.

We are still missing cycle-with-intermediary releases for heat-translator,
patrole, and tacker-horizon. If we do not receive release requests for these
repos soon we will be forced to create a release from the latest commit to
create a stable/queens branch. The release team would rather not be the ones
initiating this release, so please submit a release patch for these as soon as
possible.


Upcoming Deadlines & Dates
--

Rocky PTL election close: February 14
Final Queens Release Candidates: February 22
Rocky PTG in Dublin: Week of February 26
Queens cycle-trailing RC deadline: March 1

-- 
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] [release][requirements][monasca] FFE request for monasca-common

[Dirk Müller]

2018-02-08 11:05 GMT+01:00 Bedyk, Witold :

> I would like to request FFE for monasca-common to be bumped in upper 
> constraints. The version has been bumped together with the rest of Monasca 
> components [1]. Monasca-common is used only in Monasca projects [2].

The changes between 2.7.0 and 2.8.0 are:

+2.8.0
+-
+
+* Enable tempest tests as voting
+* Add messages for testing unicode
+* Zuul: Remove project name
+* Remove not used mox library
+* Updated from global requirements
+* Updated from global requirements


The requirements changes are removal of mox, and fix for oslotest to
sync the queens level requirements. so this looks good to me. +1

Greetings,
Dirk

__
OpenStack Development Mailing 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][cinder]Question about cinder as glance store

[Gorka Eguileor]

On 07/02, Erlon Cruz wrote:
> That will depend on the Cinder/OS-brick iscsiadm versions right? Can you
> tell what are the versions from where the problem was fixed?
>
> Erlon
>

Hi,

Like you said it depends on your Cinder and OS-Brick versions, and the
open-iscsi package will be different depending on your distro, for RHOS
7.4 this is iscsi-initiator-utils version 6.2.0.874-2 or later.

Things working fine may also depend on your multipath and Cinder/Nova
configuration as well as LVM filters (if your deployment can have images
that have LVM).

I think that's all that need to be properly setup.

Cheers,
Gorka.

> 2018-02-07 8:27 GMT-02:00 Gorka Eguileor :
>
> > On 07/02, Rikimaru Honjo wrote:
> > > Hello,
> > >
> > > I'm planning to use cinder as glance store.
> > > And, I'll setup cinder to connect storage by iSCSI multipath.
> > >
> > > In this case, can I run glance-api and cinder-volume on the same node?
> > >
> > > In my understanding, glance-api will attach a volume to own node and
> > > write a uploaded image to the volume if glance backend is cinder.
> > > I afraid that the race condition of cinder-volume's iSCSI operations
> > > and glance-api's iSCSI operations.
> > > Is there possibility of occurring it?
> > > --
> > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> > > 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
> >
> > Hi,
> >
> > When properly set with the right configuration and the right system and
> > OpenStack packages, Cinder, OS-Brick, and Nova no longer have race
> > conditions with iSCSI operations anymore (single or multipathed), not
> > even with drivers that do "shared target".
> >
> > So I would assume that Glance won't have any issues either as long as
> > it's properly making the Cinder and OS-Brick calls.
> >
> > Cheers,
> > Gorka.
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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


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

[openstack-dev] [senlin] senlin 5.0.0.0rc1 (queens)

[no-reply]

Hello everyone,

A new release candidate for senlin for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/senlin/

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

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

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

Release notes for senlin can be found at:

http://docs.openstack.org/releasenotes/senlin/

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

https://bugs.launchpad.net/senlin-tempest-plugin

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


__
OpenStack Development Mailing 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Dmitry Tantsur]

On 02/07/2018 10:31 PM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote:


Okay  It's safe to ignore then ;P  We should probably remove it from
projects.txt if it really is empty  I'll propose that.


Oh my bad, ironic-python-agent-builder was included as it's included as
an ironic project[1] NOT because it;s listed in projects.txt.  Given
that it's clearly not for me to remove anything.

Having said that if the project hasn't had any updates at all since it's
creation in July 2017 perhaps it's no longer needed and could be
removed?


We do plan to use it, we just never had time to populate it :(



Yours Tony.

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n1539



__
OpenStack Development Mailing List (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] [monasca] Feature freeze lifted

[Bedyk, Witold]

Hello,

Yesterday I have created stable/queens branches for our repos. It will be used 
to create the final Queens release.
We can continue the work on new features on master.

Cheers
Witek

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

Re: [openstack-dev] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Andrey Kurilin]

Hi Rico

2018-02-08 11:38 GMT+02:00 Rico Lin :

> Thx Andrey, looking forward to new rally job
>
> At meanwhile,  seems current job is broken [1]
>

Based on the error, the fix requires +2;-2 change to
https://github.com/openstack/heat/blob/master/rally-scenarios/plugins/stack_output.py
.
I can propose a patch with a fix and we can leave legacy-rally job at
experimental queue.
Or we can return to this after sometime. I'm ok about both cases.


> and we're expecting for a new job to replace.
> We will remove the old legacy one (see patch [2]) for now if that won't
> break rally (in any way).
> I'm changing only config for heat (under zuul.d/projects.yaml), won't
> touch `legacy-rally-dsvm-fakevirt-heat` itself (I guess that is up to
> rally team to remove it later)
>
> [1] http://logs.openstack.org/29/531929/3/experimental/
> legacy-rally-dsvm-fakevirt-heat/cd797f4/job-output.txt.
> gz#_2018-02-08_05_02_37_258609
> [2] https://review.openstack.org/542111
>
> 2018-02-08 3:39 GMT+08:00 Andrey Kurilin :
>
>> Hi Rico and stackers,
>>
>> Thanks for raising this topic.
>>
>> Short answer: please leave it as is for now. Rally team will work on
>> ZuulV3 jobs soon.
>>
>> Detailed: We are planning to make some big changes in our architecture
>> which includes splitting the main repo into a separate repository for a
>> framework and a separate repository for all OpenStack plugins.
>> To minimize work across all projects which have Rally job, we decided to
>> pause working on ZuulV3 until the split will be finished.
>> As for estimates, I'm planning to make the final release before splitting
>> today or tomorrow. As soon as new release will be ready, we will start
>> working on splitting and CI as well.
>>
>> Thanks for the patient and for using Rally!
>>
>> 2018-02-07 10:13 GMT+02:00 Rico Lin :
>>
>>> Hi heat and rally team
>>>
>>> Right now, in heat's zuul jobs. We still got one legacy job to change
>>> `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out
>>> here [2], but after discussion with infra team, it seems best if we can
>>> define this in rally, and reference it in heat.
>>> So my question to rally team for all these will be, do we still need
>>> this job? and how you guys think about if we put that into rally?
>>>
>>> [1] https://github.com/openstack-infra/project-config/blob/m
>>> aster/zuul.d/projects.yaml#L6979
>>> [2] https://review.openstack.org/#/c/509141
>>> --
>>> May The Force of OpenStack Be With You,
>>>
>>> *Rico Lin*irc: ricolin
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [release][requirements][monasca] FFE request for monasca-common

[Bedyk, Witold]

Hello,

I would like to request FFE for monasca-common to be bumped in upper 
constraints. The version has been bumped together with the rest of Monasca 
components [1]. Monasca-common is used only in Monasca projects [2].

Best greetings
Witek


[1] https://review.openstack.org/541767
[2] 
http://codesearch.openstack.org/?q=monasca-common=nope=.*requirements.*=

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

Re: [openstack-dev] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Rico Lin]

Thx Andrey, looking forward to new rally job

At meanwhile,  seems current job is broken [1] and we're expecting for a
new job to replace.
We will remove the old legacy one (see patch [2]) for now if that won't
break rally (in any way).
I'm changing only config for heat (under zuul.d/projects.yaml), won't touch
`legacy-rally-dsvm-fakevirt-heat` itself (I guess that is up to rally team
to remove it later)

[1]
http://logs.openstack.org/29/531929/3/experimental/legacy-rally-dsvm-fakevirt-heat/cd797f4/job-output.txt.gz#_2018-02-08_05_02_37_258609
[2] https://review.openstack.org/542111

2018-02-08 3:39 GMT+08:00 Andrey Kurilin :

> Hi Rico and stackers,
>
> Thanks for raising this topic.
>
> Short answer: please leave it as is for now. Rally team will work on
> ZuulV3 jobs soon.
>
> Detailed: We are planning to make some big changes in our architecture
> which includes splitting the main repo into a separate repository for a
> framework and a separate repository for all OpenStack plugins.
> To minimize work across all projects which have Rally job, we decided to
> pause working on ZuulV3 until the split will be finished.
> As for estimates, I'm planning to make the final release before splitting
> today or tomorrow. As soon as new release will be ready, we will start
> working on splitting and CI as well.
>
> Thanks for the patient and for using Rally!
>
> 2018-02-07 10:13 GMT+02:00 Rico Lin :
>
>> Hi heat and rally team
>>
>> Right now, in heat's zuul jobs. We still got one legacy job to change
>> `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out
>> here [2], but after discussion with infra team, it seems best if we can
>> define this in rally, and reference it in heat.
>> So my question to rally team for all these will be, do we still need this
>> job? and how you guys think about if we put that into rally?
>>
>> [1] https://github.com/openstack-infra/project-config/blob/
>> master/zuul.d/projects.yaml#L6979
>> [2] https://review.openstack.org/#/c/509141
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [ptg] Lightning talks

[Thierry Carrez]

Mike Perez wrote:
> [...]
> Appropriate 5 minute talk examples:
> * Neat features in libraries like oslo that we should consider adopting in our
>   community wide goals.
> * Features and tricks in your favorite editor that makes doing work easier.
> * Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
>   in five minutes anyone?

Note that we'll have an infra talk about Zuulv3 (and other things you
should know about OpenStack project infrastructure in 2018) on the
Tuesday, so that is likely to be covered already :)

> * Some potential API specification from the API SIG that we should adopt as
>   a community wide goal.

I'd say it's also fine to talk about something of interest to the PTG
crowd that you're passionate about and is not directly tied to OpenStack!

Cheers,

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] [glance][cinder]Question about cinder as glance store

[Rikimaru Honjo]

Hello Gorka,

Thank you for replying!
I'll try to run glance-api and cinder-volume on the same node
according to your information.

On 2018/02/07 19:27, Gorka Eguileor wrote:

On 07/02, Rikimaru Honjo wrote:

Hello,

I'm planning to use cinder as glance store.
And, I'll setup cinder to connect storage by iSCSI multipath.

In this case, can I run glance-api and cinder-volume on the same node?

In my understanding, glance-api will attach a volume to own node and
write a uploaded image to the volume if glance backend is cinder.
I afraid that the race condition of cinder-volume's iSCSI operations
and glance-api's iSCSI operations.
Is there possibility of occurring it?
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
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


Hi,

When properly set with the right configuration and the right system and
OpenStack packages, Cinder, OS-Brick, and Nova no longer have race
conditions with iSCSI operations anymore (single or multipathed), not
even with drivers that do "shared target".

So I would assume that Glance won't have any issues either as long as
it's properly making the Cinder and OS-Brick calls.

Cheers,
Gorka.

__
OpenStack Development Mailing 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] [ptg] Track around release cycle, consumption models and stable branches

[Thierry Carrez]

Borne Mace wrote:
> I would be interested in taking part in this discussion as well,

OK I think we have enough people to warrant a spot on the pre-scheduled
tracks (Tuesday afternoon). I'll make it happen.

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tripleo] FFE - Feuture Freeze Exception request for Routed Spine and Leaf Deployment

[Harald Jensas]

Hi,

Thanks for all the reviews. Just one more + CI change and docs left now.


**HEADs UP**:
I think we might have broken ovb jobs until 537830
 is landed once packages are promoted.
This is due to a change in Ironic[1] that I realized yesterday is not yet
in the packages used by tripleo CI. We should make sure the Prep-CI patch
below lands before we have packages promoted.


* Prep-CI for routed-networks changes
  https://review.openstack.org/#/c/541678/


* Install and enable neutron baremetal mech plugin
  https://review.openstack.org/537830

This needs a rebase, I will do it today.
It also needs packages that is not available in repos used by CI.


tripleo-docs


* Documentation - TripleO routed-spine-and-leaf
  https://review.openstack.org/#/c/539939/

I will go over this again today, but so far reviews are good.


//
Harald


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

On Mon, Feb 5, 2018 at 3:42 AM, Emilien Macchi  wrote:

>
>
> On Fri, Feb 2, 2018 at 3:28 AM, Harald Jensås  wrote:
>
>> Requesting:
>>   Feuture Freeze Exception request for Routed Spine and Leaf Deployment
>>
>> Blueprints:
>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
>> ironic-inspector
>> 
>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-
>> deployment
>>
>> All external dependencies for Routed Spine and Leaf Deployement have
>> finally landed. (Except puppet module changes.)
>>
>>
>> Pros
>> 
>>
>> This delivers a feature that has been requested since the Kilo release.
>> It makes TripleO more viable in large deployments as well as in edge
>> use cases where openstack services are not deployed in one datacenter.
>>
>> The core piece in this is the neutron segments service_plugin. This has
>> been around since newton. Most of the instack-undercloud patches were
>> first proposed during ocata.
>>
>> The major change is in the undercloud. In tripleo-heat-templates we
>> need just a small change to ensure we get ip addresses allocated from
>> neutron when segments service plug-in is enabled in neutron. The
>> overcloud configuration stays the same, we already do have users
>> deploying routed networks in the isolated networks using composable
>> networks so we know it works.
>>
>>
>> Risks
>> =
>>
>> I see little risk introducing a regression to current functionality
>> with these changes. The major part of the undercloud patches has been
>> around for a long time and passing CI.
>>
>> The format of undercloud.conf is changed, options are deprecated and
>> new options are added to enable multiple control plane subnets/l2-
>> segments to be defined. All options are properly deprectated, so
>> using a configuration file from pike will still work.
>>
>>
>>
>> =
>> The list of patches that need to land
>> =
>>
>> instack-undercloud
>> --
>>
>> * Tripleo routed networks ironic inspector, and Undercloud
>>   https://review.openstack.org/#/c/437544/
>> * Move ctlplane network/subnet setup to python
>>   https://review.openstack.org/533364
>> * Update config to use per network groups
>>   https://review.openstack.org/533365
>> * Update validations to validate all subnets
>>   https://review.openstack.org/533366
>> * Add support for multiple inspection subnets
>>   https://review.openstack.org/533367
>> * Create static routes for remote subnets
>>   https://review.openstack.org/533368
>> * Add per subnet network cidr nat rules
>>   https://review.openstack.org/533369
>> * Add per subnet masquerading
>>   https://review.openstack.org/533370
>> * Install and enable neutron baremetal mech plugin
>>   https://review.openstack.org/537830
>>
>> tripleo-heat-templates
>> --
>>
>> * Add subnet property to ctlplane network for server resources
>>   https://review.openstack.org/473817
>>
>> tripleo-docs
>> 
>>
>> * Documentation - TripleO routed-spine-and-leaf
>>   https://review.openstack.org/#/c/539939/
>>
>> puppet-neutron
>> --
>>
>> * Add networking-baremetal ml2 plug-in
>>   https://review.openstack.org/537826
>> * Add networking-baremetal - ironic-neutron-agent
>>   https://review.openstack.org/539405
>>
>>
> I'm a bit concerned by the delay of this request. Feature freeze request
> deadline was 10 days ago:
> https://releases.openstack.org/queens/schedule.html#q-ff
>
> We're now in the process on producing a release candidate. The amount of
> code that needs to land to have the feature completed isn't small but it
> looks like well tested and you seems pretty confident.
> I'm not sure what to vote on this one tbh because yeah the use-case is
> super important, and we know how Queens release is important to us. But at
> the same time there is a risk to introduce problems, and