[openstack-dev] [heat] heat 10.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/heat/

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/heat/log/?h=stable/queens

Release notes for heat can be found at:

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




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


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

2018-02-09 Thread Pino de Candia
Hi Folks,

here are the slides for the Tatu presentation:
https://docs.google.com/presentation/d/1HI5RR3SNUu1If-A5Zi4EMvjl-3TKsBW20xEUyYHapfM

I meant to record the demo video as well but I haven't gotten around to
editing all the bits. Please stay tuned.

thanks,
Pino


On Tue, Feb 6, 2018 at 10:52 AM, Giuseppe de Candia <
giuseppe.decan...@gmail.com> wrote:

> Hi Luke,
>
> Fantastic! An hour would be great if the schedule allows - there are lots
> of different aspects we can dive into and potential future directions the
> project can take.
>
> thanks!
> Pino
>
>
>
> On Tue, Feb 6, 2018 at 10:36 AM, Luke Hinds  wrote:
>
>>
>>
>> On Tue, Feb 6, 2018 at 4:21 PM, Giuseppe de Candia <
>> giuseppe.decan...@gmail.com> wrote:
>>
>>> Hi Folks,
>>>
>>> I know the request is very late, but I wasn't aware of this SIG until
>>> recently. Would it be possible to present a new project to the Security SIG
>>> at the PTG? I need about 30 minutes. I'm hoping to drum up interest in the
>>> project, sign on users and contributors and get feedback.
>>>
>>> For the past few months I have been working on a new project - Tatu [1]-
>>> to automate the management of SSH certificates (for both users and hosts)
>>> in OpenStack. Tatu allows users to generate SSH certificates with
>>> principals based on their Project role assignments, and VMs automatically
>>> set up their SSH host certificate (and related config) via Nova vendor
>>> data. The project also manages bastions and DNS entries so that users don't
>>> have to assign Floating IPs for SSH nor remember IP addresses.
>>>
>>> I have a working demo (including Horizon panels [2] and OpenStack CLI
>>> [3]), but am still working on the devstack script and patches [4] to get
>>> Tatu's repositories into OpenStack's GitHub and Gerrit. I'll try to post a
>>> demo video in the next few days.
>>>
>>> best regards,
>>> Pino
>>>
>>>
>>> References:
>>>
>>>1. https://github.com/pinodeca/tatu (Please note this is still very
>>>much a work in progress, lots of TODOs in the code, very little testing 
>>> and
>>>documentation doesn't reflect the latest design).
>>>2. https://github.com/pinodeca/tatu-dashboard
>>>3. https://github.com/pinodeca/python-tatuclient
>>>4. https://review.openstack.org/#/q/tatu
>>>
>>>
>>>
>>>
>> Hi Giuseppe, of course you can! I will add you to the agenda. We could
>> get your an hour if it allows more time for presenting and post discussion?
>>
>> We will be meeting in an allocated room on Monday (details to follow).
>>
>> https://etherpad.openstack.org/p/security-ptg-rocky
>>
>> Luke
>>
>>
>>
>>
>>>
>>>
>>> On Wed, Jan 31, 2018 at 12:03 PM, Luke Hinds  wrote:
>>>

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

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

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


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


 --
 Luke Hinds | NFV Partner Engineering | CTO 

[Openstack-operators] Developer Mailing List Digest February 3-9th

2018-02-09 Thread Mike Perez
Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: https://www.openstack.org/blog/?p=8287

Success Bot Says
* stephenfin on #openstack-nova [0]: After 3 years and 7 (?) releases,
  encryption between nova's consoleproxy service and compute nodes is finally
* possible ✌️
* AJaeger on #openstack-infra [1]: zuul and nodepool feature/zuulv3 branches
  have merged into master
* ildikov on #openstack-nova [2]: OpenStack now supports to attach a Cinder
  volume to multiple VM instances managed by Nova.
* mriedem on #openstack-nova [3]: osc-placement 1.0.0 released; you can now do
  things with resource providers/classes via OSC CLI now.
* AJaeger on #openstack-infra [4]: All tox jobs have been converted to Zuul v3
  native syntax, run-tox.sh is gone.
* ttx on #openstack-dev [5]: All teams have at least one candidate for PTL for
  the Rocky cycle! Might be the first time.
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-15.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-18.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-23.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-24.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-07.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-08.log.html


Community Summaries
===
* Release countdown [0]
* Nova placement resource provider update [1]
* TC Report [2]
* POST /api-sig/news [3]
* Technical Committee Status Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127120.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127203.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127012.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127140.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127192.html


Dublin PTG Schedule is Up
=
PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to
discuss additional topics that take half a day and can be requested [1]. For
small things (90 min discussions) we can book them dyncamically during the
event with the new PTG bot features. Follow the thread for updates to the
schedule [2].

[0] - https://www.openstack.org/ptg#tab_schedule
[1] - https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892


Last Chance for PTG Dublin Tickets
==
PTG tickets for Dublin were sold out this week, and the Foundation received
many requests for more tickets. Working with the venue to accommodate the extra
capacity, every additional attendee incrementally increases costs to $600. It's
understood the importance of this event and the need to have key team members
present, so the OpenStack Foundation has negotiated an additional 100 tickets
and will partially subsidize to be at sold at $400 [0].

[0] - 
https://www.eventbrite.com/e/project-teams-gathering-dublin-2018-tickets-39055825024

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127129.html


New Zuul Depends-On Syntax

Recently introduced url-based syntax for Depends-On: footer in your commit 
message:

Depends-On: https://review.openstack.org/535851

Old syntax will continue to work for a while, but please begin using the new
syntax. Zuul has grown the ability to talk to multiple backend systems (Gerrit,
Git and plain Git so far).

From a change in gerrit you could have:
Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or from a Github pull request:
Depends-On: https://review.openstack.org/536159

Tips and certain cases contained further in the full message.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html


Call For Mentors and Funding

The Outreachy program [0] helps people of underrepresented groups get involved
in free and open source software by matching interns with established mentors
in the upstream community.

OpenStack will be 

[openstack-dev] Developer Mailing List Digest February 3-9th

2018-02-09 Thread Mike Perez
Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: https://www.openstack.org/blog/?p=8287

Success Bot Says
* stephenfin on #openstack-nova [0]: After 3 years and 7 (?) releases,
  encryption between nova's consoleproxy service and compute nodes is finally
* possible ✌️
* AJaeger on #openstack-infra [1]: zuul and nodepool feature/zuulv3 branches
  have merged into master
* ildikov on #openstack-nova [2]: OpenStack now supports to attach a Cinder
  volume to multiple VM instances managed by Nova.
* mriedem on #openstack-nova [3]: osc-placement 1.0.0 released; you can now do
  things with resource providers/classes via OSC CLI now.
* AJaeger on #openstack-infra [4]: All tox jobs have been converted to Zuul v3
  native syntax, run-tox.sh is gone.
* ttx on #openstack-dev [5]: All teams have at least one candidate for PTL for
  the Rocky cycle! Might be the first time.
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-15.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-18.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-23.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-24.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-07.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-08.log.html


Community Summaries
===
* Release countdown [0]
* Nova placement resource provider update [1]
* TC Report [2]
* POST /api-sig/news [3]
* Technical Committee Status Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127120.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127203.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127012.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127140.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127192.html


Dublin PTG Schedule is Up
=
PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to
discuss additional topics that take half a day and can be requested [1]. For
small things (90 min discussions) we can book them dyncamically during the
event with the new PTG bot features. Follow the thread for updates to the
schedule [2].

[0] - https://www.openstack.org/ptg#tab_schedule
[1] - https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892


Last Chance for PTG Dublin Tickets
==
PTG tickets for Dublin were sold out this week, and the Foundation received
many requests for more tickets. Working with the venue to accommodate the extra
capacity, every additional attendee incrementally increases costs to $600. It's
understood the importance of this event and the need to have key team members
present, so the OpenStack Foundation has negotiated an additional 100 tickets
and will partially subsidize to be at sold at $400 [0].

[0] - 
https://www.eventbrite.com/e/project-teams-gathering-dublin-2018-tickets-39055825024

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127129.html


New Zuul Depends-On Syntax

Recently introduced url-based syntax for Depends-On: footer in your commit 
message:

Depends-On: https://review.openstack.org/535851

Old syntax will continue to work for a while, but please begin using the new
syntax. Zuul has grown the ability to talk to multiple backend systems (Gerrit,
Git and plain Git so far).

From a change in gerrit you could have:
Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or from a Github pull request:
Depends-On: https://review.openstack.org/536159

Tips and certain cases contained further in the full message.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html


Call For Mentors and Funding

The Outreachy program [0] helps people of underrepresented groups get involved
in free and open source software by matching interns with established mentors
in the upstream community.

OpenStack will be 

[openstack-dev] [keystone] Keystone Team Update - Weeks of 29 January and 5 February 2018

2018-02-09 Thread Colleen Murphy
# Keystone Team Update - Weeks of 29 January and 5 February 2018

It's been a busy couple of weeks and I missed the last update, here's
an update for the last two weeks.

## News

### RC1

RC1 was cut today[1]. We expect to release an RC2 after branching
since we have a translations patch and a couple of bugfixes that we
hope to get in.

### PTG Planning

We're finalizing topics to cover during the cross-project days of the PTG[2].

[1] https://review.openstack.org/#/c/542385/
[2] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg

## Open Specs

Search query: https://goo.gl/pc8cCf

We don't have any new specs proposed currently but Adrian has hinted
that an interesting one is on its way[3].

[3] 
http://lists.openstack.org/pipermail/openstack-operators/2018-February/014852.html

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 33 changes this last week, 76 since the last update
newsletter. These included the last of our api-ref reorganization
changes, cleanup of v2 cruft and documentation, and some major
bugfixes.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 25 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Please focus reviews
on release-critical bugs.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

We've released our RC1 and we are in hard string freeze. We have two
more weeks to make another RC release.

## Shout-outs

Thanks to our Outreachy intern Suramya for completing our api-ref
reorganization! This was a big step in making our API reference more
useable. Of course we have many more things for you to help us with ;)

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
OpenStack Development Mailing 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] Updates on containerized undercloud

2018-02-09 Thread Emilien Macchi
On Fri, Feb 9, 2018 at 2:30 PM, James Slagle  wrote:
[...]

You may want to add an item for the routed ctlplane work that landed
> at the end of Queens. Afaik, that will need to be supported with the
> containerized undercloud.
>

Done: https://trello.com/c/kFtIkto1/17-routed-ctlplane-networking

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


Re: [openstack-dev] [tripleo] Updates on containerized undercloud

2018-02-09 Thread James Slagle
On Fri, Feb 9, 2018 at 5:02 PM, Emilien Macchi  wrote:
> Quite a lot of progress has been made over the last months (and days), so I
> found useful to share an update on where we are with the efforts on
> containerized undercloud.
>
> ## CI efforts
>
> - tripleo-ci-centos-7-undercloud-containers job has been reworked to use the
> "undercloud install" interface. Job is green and will probably start voting
> during the next days. See https://review.openstack.org/#/c/517445/ and
> https://review.openstack.org/#/c/517444/.
> - we're looking at switching some other CI jobs (maybe one to start) to
> deploy a containerized undercloud, and then deploy an overcloud (probably
> featureset010). We have a few blockers but we're working on it. It's mostly
> the overcloud_prep that fails:
> http://logs.openstack.org/06/542906/1/check/tripleo-ci-centos-7-containers-multinode/0b18c49/logs/undercloud/home/zuul/overcloud_prep_containers.log.txt.gz#_2018-02-09_17_07_27
> - because of that effort, we're also taking an opportunity to refactor
> tripleo-quickstart-extras roles to be more "standard" for both undercloud
> and overcloud (example, renaming overcloud-prep-containers to
> prep-containers, etc). We'll need help from TripleO CI squad probably.
> - Chandan will help us to run validate-tempest in
> tripleo-ci-centos-7-undercloud-containers so we can have some actual testing
> for this job, since no overcloud is deployed.
>
> ## Feature parity
>
> - TLS work is ongoing.
> - TripleO UI containerization is ongoing.
> - Nova join support is targeted for Rocky
> - Upgrade workflow is under investigation. We'll work on re-using the
> upgrade_tasks in THT to upgrade a non-containerized undercloud (Queens) to a
> containerized undercloud (Rocky) like we did between Ocata and Pike with the
> upgrade_tasks. We'll actually re-use the same code but will have to change
> the undercloud upgrade workflow in tripleoclient.

You may want to add an item for the routed ctlplane work that landed
at the end of Queens. Afaik, that will need to be supported with the
containerized undercloud.

-- 
-- James Slagle
--

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


Re: [openstack-dev] [tripleo] Updates on containerized undercloud

2018-02-09 Thread Emilien Macchi
On Fri, Feb 9, 2018 at 2:02 PM, Emilien Macchi  wrote:

> Quite a lot of progress has been made over the last months (and days), so
> I found useful to share an update on where we are with the efforts on
> containerized undercloud.
>
> ## CI efforts
>
> - tripleo-ci-centos-7-undercloud-containers job has been reworked to use
> the "undercloud install" interface. Job is green and will probably start
> voting during the next days. See https://review.openstack.org/#/c/517445/
> and https://review.openstack.org/#/c/517444/.
> - we're looking at switching some other CI jobs (maybe one to start) to
> deploy a containerized undercloud, and then deploy an overcloud (probably
> featureset010). We have a few blockers but we're working on it. It's mostly
> the overcloud_prep that fails:
> http://logs.openstack.org/06/542906/1/check/tripleo-ci-
> centos-7-containers-multinode/0b18c49/logs/undercloud/home/
> zuul/overcloud_prep_containers.log.txt.gz#_2018-02-09_17_07_27
> - because of that effort, we're also taking an opportunity to refactor
> tripleo-quickstart-extras roles to be more "standard" for both undercloud
> and overcloud (example, renaming overcloud-prep-containers to
> prep-containers, etc). We'll need help from TripleO CI squad probably.
> - Chandan will help us to run validate-tempest in 
> tripleo-ci-centos-7-undercloud-containers
> so we can have some actual testing for this job, since no overcloud is
> deployed.
>
> ## Feature parity
>
> - TLS work is ongoing.
> - TripleO UI containerization is ongoing.
> - Nova join support is targeted for Rocky
> - Upgrade workflow is under investigation. We'll work on re-using the
> upgrade_tasks in THT to upgrade a non-containerized undercloud (Queens) to
> a containerized undercloud (Rocky) like we did between Ocata and Pike with
> the upgrade_tasks. We'll actually re-use the same code but will have to
> change the undercloud upgrade workflow in tripleoclient.
>
> That highlights the current efforts, if you have any question, need more
> specific or just any feedback, please go ahead.
> At the PTG, we'll discuss about some technical details and hope to move
> forward with this nice feature during Rocky cycle.
>
> Thanks,
> --
> Emilien Macchi
>

I forgot to mention, but people working on this topic have been using
Trello to collaborate:
https://trello.com/b/nmGSNPoQ/containerized-undercloud

To keep things in the open, here's the link and anyone is free to
participate.

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


[openstack-dev] [tripleo] Updates on containerized undercloud

2018-02-09 Thread Emilien Macchi
Quite a lot of progress has been made over the last months (and days), so I
found useful to share an update on where we are with the efforts on
containerized undercloud.

## CI efforts

- tripleo-ci-centos-7-undercloud-containers job has been reworked to use
the "undercloud install" interface. Job is green and will probably start
voting during the next days. See https://review.openstack.org/#/c/517445/
and https://review.openstack.org/#/c/517444/.
- we're looking at switching some other CI jobs (maybe one to start) to
deploy a containerized undercloud, and then deploy an overcloud (probably
featureset010). We have a few blockers but we're working on it. It's mostly
the overcloud_prep that fails:
http://logs.openstack.org/06/542906/1/check/tripleo-ci-centos-7-containers-multinode/0b18c49/logs/undercloud/home/zuul/overcloud_prep_containers.log.txt.gz#_2018-02-09_17_07_27
- because of that effort, we're also taking an opportunity to refactor
tripleo-quickstart-extras roles to be more "standard" for both undercloud
and overcloud (example, renaming overcloud-prep-containers to
prep-containers, etc). We'll need help from TripleO CI squad probably.
- Chandan will help us to run validate-tempest in
tripleo-ci-centos-7-undercloud-containers so we can have some actual
testing for this job, since no overcloud is deployed.

## Feature parity

- TLS work is ongoing.
- TripleO UI containerization is ongoing.
- Nova join support is targeted for Rocky
- Upgrade workflow is under investigation. We'll work on re-using the
upgrade_tasks in THT to upgrade a non-containerized undercloud (Queens) to
a containerized undercloud (Rocky) like we did between Ocata and Pike with
the upgrade_tasks. We'll actually re-use the same code but will have to
change the undercloud upgrade workflow in tripleoclient.

That highlights the current efforts, if you have any question, need more
specific or just any feedback, please go ahead.
At the PTG, we'll discuss about some technical details and hope to move
forward with this nice feature during Rocky cycle.

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


[openstack-dev] [tripleo] Updating default Docker registry and namespace

2018-02-09 Thread David Moreau Simard
Hi,

I've submitted a series of patches:
https://review.openstack.org/#/q/topic:default-registry

In these patches, I am merely doing the following:

#1 s/trunk.registry.rdoproject.org/docker.io/
trunk.registry.rdoproject.org is not meant for production or stable
use, it should only be used as a staging ground so we don't spam
docker.io with hundreds of images needlessly.
We're pushing and tagging tested and promoted images to docker.io --
trunk.registry.rdoproject.org should not be advertised.

#2 s/latest/current-tripleo/
We don't use the "latest" tag, we push tags based on their trunk
repository hash (DLRN) or names such as "current-tripleo",
"current-tripleo-rdo", etc.

#3 s/tripleoupstream/tripleomaster/
The docker.io/tripleoupstream namespace is unmaintained. Images are
now pushed and tagged in the tripleomaster namespace.
Patches for these should be backported to Pike while replacing
"tripleomaster" for "tripleopike" once they have landed.

Please validate the patches properly as I can't pretend to have tested
these before sending them.

Thanks,

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] [infra] Please add me to Tatu's Gerrit groups

2018-02-09 Thread Jeremy Stanley
On 2018-02-09 10:00:25 -0600 (-0600), Pino de Candia wrote:
> I'd like to be added to the recently created tatu-core and
> tatu-release Gerrit groups.

Since your Gerrit account is the one which proposed the change to
add the project whose ACLs use those groups, I have added you as the
initial member in both of them.
-- 
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] [reno][tripleo] an alternative approach to known issues

2018-02-09 Thread Ben Nemec



On 02/08/2018 07:42 PM, Gabriele Cerami wrote:

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.


I would tend to agree.  Tech debt is something you can live with for a 
period of time, and critical bugs are not.  The critical tech debt bug 
open in tripleo at the time I'm writing this is clearly not critical 
since it's been open for months and nothing has happened with it, nor 
has it been blocking anyone from deploying or developing TripleO.



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.


Absolutely.  Policies are not set in stone for all time.  They're living 
documents that can be updated as we find limitations or areas for 
improvement.  Please feel free to propose any updates you think would be 
helpful to the existing policy.  We can hash out the details in Gerrit.





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.


I don't think any bug should be closed as long as we have some interest 
in fixing it.  If it's not high priority then it should be triaged as 
such, but I wouldn't advocate closing a bug just because we won't have 
time to get to it this cycle/year/decade. :-)


The milestone field might be a good way to indicate that a 

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

2018-02-09 Thread Wesley Hayutin
On Thu, Feb 8, 2018 at 6:23 PM, Alex Schultz  wrote:

> 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


 Thanks Alex,
TripleO-CI please be prepared to discuss this thread in the next scrum
meeting.



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

Re: [openstack-dev] [sahara] FFE - Adding Ambari 2.4.2.0 to image gen

2018-02-09 Thread Telles Nobrega
Taking that the risk to the project is none the FFE exception is granted.

On Fri, Feb 9, 2018 at 3:15 PM Luigi Toscano  wrote:

> Hi,
> I'd like to request a feature exception for
> https://review.openstack.org/#/c/529442/
>
> I finally managed to test it, and the generated image with Ambari 2.4.2.0
> can
> spawn clusters with both HDP 2.4 and HDP 2.3. There are some issues when
> Hive
> is involved, but I think that they are not regressions.
>
> The feature (which it's pretty trivial in itself, but required a fair
> amount
> of testing) is pretty much isolated and it won't cause regressions on other
> components anyway.
>
> Ciao
> --
> Luigi
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing List (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] [sahara] FFE - Adding Ambari 2.4.2.0 to image gen

2018-02-09 Thread Luigi Toscano
Hi,
I'd like to request a feature exception for
https://review.openstack.org/#/c/529442/

I finally managed to test it, and the generated image with Ambari 2.4.2.0 can 
spawn clusters with both HDP 2.4 and HDP 2.3. There are some issues when Hive 
is involved, but I think that they are not regressions.

The feature (which it's pretty trivial in itself, but required a fair amount 
of testing) is pretty much isolated and it won't cause regressions on other 
components anyway.

Ciao
-- 
Luigi



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


[Openstack] Routing in connected VMs

2018-02-09 Thread Navdeep Uniyal
Dear all,


I am trying to create a network chain manually of VMs in openstack by entering 
the routing table entries in the machines. However, it doesn't seems to work.
The network between the VMs is VLAN network on top of provider network.

Scenario is like : A-->B-->C

I have enabled the IP forwarding on the node B but I am not able to ping from A 
to C. ICMP echo requests are not reaching C.
I am able to ping from B to A and B to C. Please if someone could help in this 
regard.


Best Regards,
Navdeep
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


[openstack-dev] [neutron] neutron 12.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

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

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/log/?h=stable/queens

Release notes for neutron can be found at:

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




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

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-ovn/log/?h=stable/queens

Release notes for networking-ovn can be found at:

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

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

https://bugs.launchpad.net/networking-ovn

and tag it *queens-rc-potential* to bring it to the networking-ovn
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] [neutron] neutron-fwaas 12.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-fwaas/log/?h=stable/queens

Release notes for neutron-fwaas can be found at:

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




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

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-midonet/log/?h=stable/queens

Release notes for networking-midonet can be found at:

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




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

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-sfc/log/?h=stable/queens

Release notes for networking-sfc can be found at:

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

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

http://bugs.launchpad.net/networking-sfc

and tag it *queens-rc-potential* to bring it to the networking-sfc
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] [neutron] neutron-dynamic-routing 12.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/neutron-dynamic-routing/

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-dynamic-routing/log/?h=stable/queens

Release notes for neutron-dynamic-routing can be found at:

http://docs.openstack.org/releasenotes/neutron-dynamic-routing/




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

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-odl/log/?h=stable/queens

Release notes for networking-odl can be found at:

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




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

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-bgpvpn/log/?h=stable/queens

Release notes for networking-bgpvpn can be found at:

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

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

http://bugs.launchpad.net/bgpvpn

and tag it *queens-rc-potential* to bring it to the networking-bgpvpn
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] [neutron] networking-bagpipe 8.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

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

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-bagpipe/log/?h=stable/queens

Release notes for networking-bagpipe can be found at:

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

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

http://bugs.launchpad.net/networking-bagpipe

and tag it *queens-rc-potential* to bring it to the networking-bagpipe
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] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-09 Thread Balázs Gibizer



On Fri, Feb 9, 2018 at 4:01 PM, Matt Riedemann  
wrote:

I'd like to add Takashi to the python-novaclient core team.

python-novaclient doesn't get a ton of activity or review, but 
Takashi has been a solid reviewer and contributor to that project for 
quite awhile now:


http://stackalytics.com/report/contribution/python-novaclient/180

He's always fast to get new changes up for microversion support and 
help review others that are there to keep moving changes forward.


So unless there are objections, I'll plan on adding Takashi to the 
python-novaclient-core group next week.


+1

Cheers,
gibi



--

Thanks,

Matt

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

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



__
OpenStack Development Mailing 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] [openstack][openstackweb] can not registe new user at openstack.org

2018-02-09 Thread Jimmy McArthur

Hi -

I'm sorry for the troubles you're having in registering as a Foundation 
Member. If you could email me directly (ji...@openstack.org), I'd be 
happy to help you with the issue and get your membership set up.


Thank you,
Jimmy


Begin forwarded message:

*From: *>
*Subject: **[Openstack] [openstack][openstackweb] can not registe new 
user at openstack.org *

*Date: *February 9, 2018 at 9:34:09 AM CST
*To: *"openstack" >


it always tips "Please confirm that you are not a robots". But there is 
no way to confirm.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org 


Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-09 Thread Ken'ichi Ohmichi
+1


2018年2月9日(金) 8:09 Stephen Finucane :

> On Fri, 2018-02-09 at 09:01 -0600, Matt Riedemann wrote:
> > I'd like to add Takashi to the python-novaclient core team.
> >
> > python-novaclient doesn't get a ton of activity or review, but Takashi
> > has been a solid reviewer and contributor to that project for quite
> > awhile now:
> >
> > http://stackalytics.com/report/contribution/python-novaclient/180
> >
> > He's always fast to get new changes up for microversion support and help
> > review others that are there to keep moving changes forward.
> >
> > So unless there are objections, I'll plan on adding Takashi to the
> > python-novaclient-core group next week.
>
> Easy +1 from me. Would be good to have him on the team.
>
> Stephen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat][tacker][murano][RelMgmt] heat-translator deliverable type?

2018-02-09 Thread HADDLETON, Robert W (Bob)

On 2/9/2018 10:18 AM, Matthew Thode wrote:

On 18-02-09 10:10:10, Sean McGinnis wrote:

Hello Heat team,

The release team just recently noticed the heat-translator deliverable is
marked as a type of "other" and is following the release-model of
"cycle-with-intermediary".

It appears this is actually a library though. It's hard to tell, but it is
either a client lib or non-client lib. In either case, we need to mark it as
such and treat its release according to that type.

In order to stabilize requirements changes, we have two separate deadlines,
first for non-client libs, then a week later for client libs. Since
heat-translator appears to be a dependency used by other projects, it will need
to be subject to those release deadlines.

Can the team clarify what type of library this is, and change the type going
forward to accurately reflect that?

Please let the release team know if there are any questions.


I think tacker and murano may be using it in a non-intended way (those
are the only projects I could find that's using it).

https://github.com/openstack/tacker/search?utf8=%E2%9C%93=translator=
https://github.com/openstack/murano/search?utf8=%E2%9C%93=translator=
Tacker worked with us on their usage so it's a known scenario.  I wasn't 
aware that Murano was using h-t, but if the implementation is similar to 
Tacker's it should be fine.


spzala knows more of the history than I do, but heat-translator, like 
tosca-parser, was originally a stand-alone client that has evolved into 
a library that can be used by other projects.  Both projects are now 
used as libraries by Tacker, and possibly others, in addition to having 
users of the command-line clients.


When we moved into the release model it was suggested that we use type 
"other", but I'm happy to change to whatever the appropriate release 
type is.  Both projects are fairly low volume at the moment, so we don't 
need a lot of releases.


Thanks

Bob Haddleton

<>__
OpenStack Development Mailing 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] an alternative approach to known issues

2018-02-09 Thread Thierry Carrez
Doug Hellmann wrote:
> What makes reno a good fit for this task? It seems like updating a
> regular documentation page in the source tree would work just as well,
> since presumably these technical debt descriptions don't need to be
> backported to stable branches.

Yeah it feels like reno would add complexity for little benefit in that
process... Better track debt in a TODO document, or a proper task tracker ?

-- 
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] [heat][tacker][murano][RelMgmt] heat-translator deliverable type?

2018-02-09 Thread Matthew Thode
On 18-02-09 10:10:10, Sean McGinnis wrote:
> Hello Heat team,
> 
> The release team just recently noticed the heat-translator deliverable is
> marked as a type of "other" and is following the release-model of
> "cycle-with-intermediary".
> 
> It appears this is actually a library though. It's hard to tell, but it is
> either a client lib or non-client lib. In either case, we need to mark it as
> such and treat its release according to that type.
> 
> In order to stabilize requirements changes, we have two separate deadlines,
> first for non-client libs, then a week later for client libs. Since
> heat-translator appears to be a dependency used by other projects, it will 
> need
> to be subject to those release deadlines.
> 
> Can the team clarify what type of library this is, and change the type going
> forward to accurately reflect that?
> 
> Please let the release team know if there are any questions.
> 

I think tacker and murano may be using it in a non-intended way (those
are the only projects I could find that's using it).

https://github.com/openstack/tacker/search?utf8=%E2%9C%93=translator=
https://github.com/openstack/murano/search?utf8=%E2%9C%93=translator=

-- 
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] [heat][RelMgmt] heat-translator deliverable type?

2018-02-09 Thread Sean McGinnis
Hello Heat team,

The release team just recently noticed the heat-translator deliverable is
marked as a type of "other" and is following the release-model of
"cycle-with-intermediary".

It appears this is actually a library though. It's hard to tell, but it is
either a client lib or non-client lib. In either case, we need to mark it as
such and treat its release according to that type.

In order to stabilize requirements changes, we have two separate deadlines,
first for non-client libs, then a week later for client libs. Since
heat-translator appears to be a dependency used by other projects, it will need
to be subject to those release deadlines.

Can the team clarify what type of library this is, and change the type going
forward to accurately reflect that?

Please let the release team know if there are any questions.

Thanks!

Sean (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] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-09 Thread Stephen Finucane
On Fri, 2018-02-09 at 09:01 -0600, Matt Riedemann wrote:
> I'd like to add Takashi to the python-novaclient core team.
> 
> python-novaclient doesn't get a ton of activity or review, but Takashi 
> has been a solid reviewer and contributor to that project for quite 
> awhile now:
> 
> http://stackalytics.com/report/contribution/python-novaclient/180
> 
> He's always fast to get new changes up for microversion support and help 
> review others that are there to keep moving changes forward.
> 
> So unless there are objections, I'll plan on adding Takashi to the 
> python-novaclient-core group next week.

Easy +1 from me. Would be good to have him on the team.

Stephen

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


[openstack-dev] [barbican][heat] Missing RCs

2018-02-09 Thread Sean McGinnis
Hello teams,

Yesterday was the RC1 deadline, and we have not seen a release request for
either Barbican or Heat.

If there is some blocking reason for waiting on these, please let us know as
soon as possible. Otherwise, please submit a release request with branching for
stable/queens to the openstack/releases repo.

RC's are needed to help test and package, so we need to get something out there
relatively soon. If we do not see a release request from these teams, the
release team will need to force a release and branch creation by this coming
Tuesday, the 13th. We would prefer to not be the ones doing that though.

Thanks for your attention. Please let us know if there are any questions or
issues.

Sean (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] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-09 Thread Sylvain Bauza
+1, no objections so far.

On Fri, Feb 9, 2018 at 4:01 PM, Matt Riedemann  wrote:

> I'd like to add Takashi to the python-novaclient core team.
>
> python-novaclient doesn't get a ton of activity or review, but Takashi has
> been a solid reviewer and contributor to that project for quite awhile now:
>
> http://stackalytics.com/report/contribution/python-novaclient/180
>
> He's always fast to get new changes up for microversion support and help
> review others that are there to keep moving changes forward.
>
> So unless there are objections, I'll plan on adding Takashi to the
> python-novaclient-core group next week.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Ocata Created Ports Strange Issue

2018-02-09 Thread Eugen Block

Hi,

my input on this is very limited, but I believe we had a similar issue  
in our Ocata cloud. My workaround was like yours, detach the assigned  
port, recreate it and attach it again. The only strange thing was,  
that when I wanted to delete the port, the CLI reported that the port  
didn't exist, it literally disappeared!
I didn't spend very much time to debug it because it has not happened  
since then. And if I remember correctly, it occured around our large  
migration, where we upgraded our Ceph backend to the latest version,  
upgraded the OS of all nodes and also the cloud from Mitaka to Ocata  
(via Newton), it could have been a side effect of that, at least that  
was my hope.


So as I said, this is not of big help, but I can confirm your  
observation, unfortunately without any pointers to the cause. If this  
happens again, I will definitely spend more time on debugging! ;-)


Regards,
Eugen


Zitat von Georgios Dimitrakakis :


Dear all,

I have a small Ocata installation (1x controller + 2x compute nodes)  
on which I have manually created 5 network ports and afterwards each  
one of these ports is assigned to a specific instance (4Linux VMs  
and 1Windows). All these instances are located on one physical  
hypervisor (compute node) while the controller is also the  
networking node.


The other day we had to do system maintenance and all hosts (compute  
and network/controller) were powered off but before that we  
gracefully shutoff all running VMs.


As soon as maintenance finished we powered on everything and I met  
the following strange issue... Instances with an attached port were  
trying for very long time to get an IP from the DHCP server but they  
all manage to get one eventually with the exception of the Windows  
VM on which I had to assign it statically. Restarting networking  
services on controller/network and/or compute node didn't make any  
difference. On the other hand all newly spawned instances didn't  
have any problem no matter on which compute node they were spawned  
and their only difference was that they were automatically getting  
ports assigned. All the above happened on Friday and today (Monday)  
people were complaining that the Linux VMs didn't have network  
connectivity (Windows was working...), so I don't know the exact  
time the issue occured. I have tried to access all VMs using the  
"self-service" network by spawning a new instance unfortunately  
without success. The instance was successfully spawned, it had  
network connectivity but couldn't reach any of the afforementioned  
VMs.


What I did finally and solved the problem was to detach interfaces,  
deleted ports, re-created new ports with same IP address etc. and  
re-attached them to the VMs. As soon as I did that networking  
connectivity was back to normal without even having to restart the  
VMs.


Unfortunately I couldn't find any helpful information regarding this  
in the logs and I am wondering has anyone seen or experienced  
something similar?


Best regards,

G.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


[openstack-dev] [infra] Please add me to Tatu's Gerrit groups

2018-02-09 Thread Pino de Candia
Hi Infra Team,

I'd like to be added to the recently created tatu-core and tatu-release
Gerrit groups.

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


[openstack-dev] [mistral] mistral-extra 6.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/mistral-extra/

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/mistral-extra/log/?h=stable/queens

Release notes for mistral-extra can be found at:

http://docs.openstack.org/releasenotes/mistral-extra/




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


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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/mistral-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/mistral-dashboard/log/?h=stable/queens

Release notes for mistral-dashboard can be found at:

http://docs.openstack.org/releasenotes/mistral-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] [mistral] mistral 6.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/mistral/

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/mistral/log/?h=stable/queens

Release notes for mistral can be found at:

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




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


[Openstack] [openstack][openstackweb] can not registe new user at openstack.org

2018-02-09 Thread guoyongxhzhf
it always tips "Please confirm that you are not a robots". But there is no way 
to confirm.___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/keystone/

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/keystone/log/?h=stable/queens

Release notes for keystone can be found at:

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




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


[openstack-dev] [telemetry] ceilometer-powervm 6.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/ceilometer-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/ceilometer-powervm/log/?h=stable/queens

Release notes for ceilometer-powervm can be found at:

http://docs.openstack.org/releasenotes/ceilometer-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


Re: [openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

2018-02-09 Thread Julia Kreger
Since all of our ironic cores have replied and nobody has stated any
objections, I guess it is time to welcome Hironori to the team! I will
make the changes in gerrit after coffee.

Thanks everyone!

-Julia

On Fri, Feb 9, 2018 at 7:13 AM, Sam Betts (sambetts)  wrote:
> +1
>
>

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


Re: [openstack-dev] [ironic] Nominating Hironori Shiina for ironic-core

2018-02-09 Thread Sam Betts (sambetts)
+1

On 09/02/2018, 04:36, "Shivanand Tendulker" 
> wrote:

+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: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] [nova] [placement] resource providers update 18-06

2018-02-09 Thread Chris Dent


Resource provider 18-06 is here.

# Most Important

RC1 was cut last night, so we shouldn't be merging any new features now,
just bug fixes. Which, of course, means finding and fixing bugs is the
thing to do.

In the gaps where that's not happening, planning for Rocky is a useful
thing to be doing.

The PTG is coming up at the end of this month. If you have topics for
discussion that are not already on the etherpad, add them:

 https://etherpad.openstack.org/p/nova-ptg-rocky

A variety of specs, and discussions related to such things, are in
progress and listed below. If I've forgotten something, let me know, as
usual.

I wrote a thing describing some of my efforts to break placement:

https://anticdent.org/placement-scale-fun.html

Placement itself was fine, but I was able to break other stuff. If you
have an environment where you are able to do that kind of concrete
experimentation, it will help to make the release better.

# What's Changed

RC1 happened. Some more "sending global request id" changes merged. A
release note was created to describe the behavior change in
AggregateCoreFilter (and friends):

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

# Help Wanted

Testing, Testing, Testing.

There are a fair few unstarted bugs related to placement that could do
with some attention. Here's a handy URL: https://goo.gl/TgiPXb

# Specs

* Support traits in Glance
  https://review.openstack.org/#/c/541507/4

* Add generation support in aggregate assocation
  https://review.openstack.org/#/c/540447/

* Update ProviderTree
  https://review.openstack.org/#/c/540111/

* Support aggregate affinity filter/weighers
  https://review.openstack.org/#/c/529135/
  (Note that this is not placement aggregates and is not a
  placement-oriented solution but is something many of the same people
  are into.)

* Granular Resource Request Syntax (Rocky)
  https://review.openstack.org/#/c/540179/

* Report CPU features to placement
  https://review.openstack.org/#/c/497733/

# Main Themes

We've not yet identified the new themes, other than to know that
Nested remains a big deal. Presumably at the PTG we will define and
then narrow the themes.

## Nested Resource Providers

Work continues at


https://review.openstack.org/#/q/status:open+topic:bp/nested-resource-providers

By which I mean that there's lots of active work and discussion on the
patches on this topic. It's the locus of activity.

# Other

Many of these things are bug fixes or doc tuneups, and thus
potentially relevant for Queens.

* Update references to OSC in old rp specs
  https://review.openstack.org/#/c/539038/

* [Placement] Invalid query parameter could lead to HTTP 500
   https://review.openstack.org/#/c/539408/

* [placement] use simple FaultWrapper
   https://review.openstack.org/#/c/533752/

* Ensure resource classes correctly
   https://review.openstack.org/#/c/539738/

* Avoid inventory DELETE API (no conflict detection)
   https://review.openstack.org/#/c/539712/

* Fix nits in allocation canidate limit handling
  https://review.openstack.org/#/c/536784/

* WIP: Move resource provider objects
  https://review.openstack.org/#/c/540049/

* Do not normalize allocation ratios
   https://review.openstack.org/#/c/532924/

* Sending global request ids from nova to placement
 https://review.openstack.org/#/q/topic:bug/1734625

* Update resources once in update available resources
 https://review.openstack.org/#/c/520024/
 (This ought, when it works, to help address some redunancy
 concerns with nova making too many requests to placement)

* Support aggregate affinity filters/weighers
 https://review.openstack.org/#/q/topic:bp/aggregate-affinity
 A rocky targeted improvement to affinity handling

* Move placement body samples in docs to own dir
 https://review.openstack.org/#/c/529998/

* Improved functional test coverage for placement
 https://review.openstack.org/#/q/topic:bp/placement-test-enhancement

* Functional tests for traits api
 https://review.openstack.org/#/c/524094/

* annotate loadapp() (for placement wsgi app) as public
 https://review.openstack.org/#/c/526691/

* Remove microversion fallback code from report client
 https://review.openstack.org/#/c/528794/

* WIP: SchedulerReportClient.set_aggregates_for_provider
 https://review.openstack.org/#/c/532995/
 This is for rocky as it depends on changing the api for
 aggregates handling on the placement side to accept and provide
 a generation

* Add functional test for two-cell scheduler behaviors
 https://review.openstack.org/#/c/452006/
 (This is old and maybe out of date, but something we might like to
 resurrect)

* Make API history doc consistent
 https://review.openstack.org/#/c/477478/

* WIP: General policy sample file for placement
 https://review.openstack.org/#/c/524425/

* Support relay RP for allocation candidates
https://review.openstack.org/#/c/533437/
Bug fix for sharing with 

[openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

2018-02-09 Thread Matt Riedemann

I'd like to add Takashi to the python-novaclient core team.

python-novaclient doesn't get a ton of activity or review, but Takashi 
has been a solid reviewer and contributor to that project for quite 
awhile now:


http://stackalytics.com/report/contribution/python-novaclient/180

He's always fast to get new changes up for microversion support and help 
review others that are there to keep moving changes forward.


So unless there are objections, I'll plan on adding Takashi to the 
python-novaclient-core group next week.


--

Thanks,

Matt

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


[openstack-dev] [TripleO][ui] Network Configuration wizard

2018-02-09 Thread Jiri Tomasek
Hi, all

Full support for network configuration is one of the main goals for TripleO
UI for Rocky cycle as it is missing part which still requires user to
manually prepare templates and provide them to deployment plan.

*Step 1. Network Isolation*

In Queens cycle we've started working on adding roles and networks
management Mistral workflows  [1], [2] which allows GUI to provide
composable roles and networks features. Roles management workflows are
landed, networks management work has most of the patches up for a review.

Both roles and networks management is based on a similar concept of having
roles/networks directory in deployment plan which consists of
roles/networks definitions available to be used for deployment. The list of
selected roles/networks which are actually used for deployment as well as
it's configuration is stored in roles_data.yaml and network_data.yaml which
are then used for populating jinja templates/environments. TripleO-common
then provides Mistral workflows for listing available roles/networks,
listing currently selected roles/networks, updating roles/networks and
selecting roles/networks.

This functionality allows us to:
Select roles for deployment and configure them
Select networks used for deployment and configure them
Assign networks to roles

Result of this is network-isolation.yaml environment file with correct
templates configured in resource_registry and parameters set according to
information in networks_data.yaml and roles_data.yaml

Work needed to finish:
[tripleo-heat-templates]
Add networks directory https://review.openstack.org/#/c/520634/

[tripleo-common]
Update Networks
https://blueprints.launchpad.net/tripleo/+spec/update-networks-action
Get Available Networks
https://blueprints.launchpad.net/tripleo/+spec/get-networks-action
Select Networks  (will be pretty much the
same as
https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow
)

[tripleo-ui] , Wireframes [6]
Create Network configuration step in deployment plan page
Create network configuration wizard view
Create dialog to select networks used for deployment
Create dialog to configure networks
Create dialog to assign networks to roles
https://blueprints.launchpad.net/tripleo/+spec/networks-roles-assignment-ui

Up to here the direction is pretty well defined.

*Step 2. network-environment -> NIC configs*

Second step of network configuration is NIC config. For this
network-environment.yaml is used which references NIC config templates
which define network_config in their resources section. User is currently
required to configure these templates manually. We would like to provide
interactive view which would allow user to setup these templates using
TripleO UI. A good example is a standalone tool created by Ben Nemec [3].

There is currently work aimed for Pike to introduce jinja templating for
network environments and templates [4] (single-nic-with-vlans,
bond-with-vlans) to support composable networks and roles (integrate data
from roles_data.yaml and network_data.yaml) It would be great if we could
move this one step further by using these samples as a starting point and
let user specify full NIC configuration.

Available information at this point:
- list of roles and networks as well as which networks need to be
configured at which role's NIC Config template
- os-net-config schema which defines NIC configuration elements and
relationships [5]
- jinja templated sample NIC templates

Requirements:
- provide feedback to the user about networks assigned to role and have not
been configured in NIC config yet
- let user construct network_config section of NIC config templates for
each role (brigdes/bonds/vlans/interfaces...)
- provide means to assign network to vlans/interfaces and automatically
construct network_config section parameter references
- populate parameter definitions in NIC config templates based on
role/networks assignment
- populate parameter definitions in NIC config templates based on specific
elements which use them e.g. BondInterfaceOvsOptions in case when ovs_bond
is used
- store NIC config templates in deployment plan and reference them from
network-environment.yaml

Problems to solve:
As a biggest problem to solve I see defining logic which would
automatically handle assigning parameters to elements in network_config
based on Network which user assigns to the element. For example: Using GUI,
user is creating network_config for compute role based on
network/config/multiple-nics/compute.yaml, user adds an interface and
assigns the interface to Tenant network. Resulting template should then
automatically populate addresses/ip_netmask: get_param: TenantIpSubnet.
Question is whether all this logic should live in GUI or should GUI pass
simplified format to Mistral workflow which will convert it to proper
network_config format and populates the template with it.

I'd really like to hear some ideas or feedback on this so we can figure out
how to define a mechanism for 

Re: [openstack-dev] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

2018-02-09 Thread Matthew Thode
On 18-02-09 17:21:26, Sam P wrote:
> Hi Matthew,
> 
>  Thanks for the info.
>  For Masakari, after discussing with release team, all following 3 project
> will do independent
>  release for Queens.
> masakari   masakari
> ​​
> masakari-monitorsmasakari
> python-masakariclient   masakari
> 
> Still need 3-4 days to create stable/queens for masakari and
> masakari-monitors
> and python-masakariclinet can be done late today.
> I will create stable/queens as soon as we merged the required patches.
> Requirement update will unfreeze soon, and we will hold the requirement
> updates till we create stable/queens.
> 
> 
> --- Regards,
> Sampath
> 
> 
> On Thu, Feb 8, 2018 at 7:33 PM, Dmitry Tantsur  wrote:
> 
> > 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/refe
> >> rence/projects.yaml#n1539
> >>

Sounds good, thanks for the update.

-- 
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] [reno] an alternative approach to known issues

2018-02-09 Thread Doug Hellmann
Excerpts from Gabriele Cerami's message of 2018-02-08 22:43:56 +:
> 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
> 

What makes reno a good fit for this task? It seems like updating a
regular documentation page in the source tree would work just as well,
since presumably these technical debt descriptions don't need to be
backported to stable branches.

Doug

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


[openstack-dev] [sahara] sahara 8.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/sahara/

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/sahara/log/?h=stable/queens

Release notes for sahara can be found at:

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




__
OpenStack Development Mailing List (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] [sahara] sahara-image-elements 8.0.0.0rc1 (queens)

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/sahara-image-elements/

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/sahara-image-elements/log/?h=stable/queens

Release notes for sahara-image-elements can be found at:

http://docs.openstack.org/releasenotes/sahara-image-elements/




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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/sahara-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/sahara-dashboard/log/?h=stable/queens

Release notes for sahara-dashboard can be found at:

http://docs.openstack.org/releasenotes/sahara-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


Re: [Openstack] diskimage-builder: prepare ubuntu 17.x images

2018-02-09 Thread Volodymyr Litovka

Hi Tony,

this patch works for me:

--- 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball.orig 
2018-02-09 12:20:02.117793234 +
+++ 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball 
2018-02-09 13:25:48.654868263 +

@@ -14,7 +14,9 @@

 DIB_CLOUD_IMAGES=${DIB_CLOUD_IMAGES:-http://cloud-images.ubuntu.com}
 DIB_RELEASE=${DIB_RELEASE:-trusty}
-BASE_IMAGE_FILE=${BASE_IMAGE_FILE:-$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz}
+SUFFIX="-root"
+[[ $DIB_RELEASE =~ (artful|bionic) ]] && SUFFIX=""
+BASE_IMAGE_FILE=${BASE_IMAGE_FILE:-$DIB_RELEASE-server-cloudimg-${ARCH}${SUFFIX}.tar.gz}
 
SHA256SUMS=${SHA256SUMS:-https://${DIB_CLOUD_IMAGES##http?(s)://}/$DIB_RELEASE/current/SHA256SUMS}
 CACHED_FILE=$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE
 CACHED_FILE_LOCK=$DIB_LOCKFILES/$BASE_IMAGE_FILE.lock
@@ -45,9 +47,25 @@
 fi
 popd
 fi
-    # Extract the base image (use --numeric-owner to avoid UID/GID 
mismatch between
-    # image tarball and host OS e.g. when building Ubuntu image on an 
openSUSE host)
-    sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE

+    if [ -n "$SUFFIX" ]; then
+  # Extract the base image (use --numeric-owner to avoid UID/GID 
mismatch between
+  # image tarball and host OS e.g. when building Ubuntu image on an 
openSUSE host)
+  sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE

+    else
+  # Unpack image to IDIR, mount it on MDIR, copy it to TARGET_ROOT
+  IDIR="/tmp/`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13 ; 
echo ''`"
+  MDIR="/tmp/`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13 ; 
echo ''`"

+  sudo mkdir $IDIR $MDIR
+  sudo tar -C $IDIR --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE
+  sudo mount -o loop -t auto 
$IDIR/$DIB_RELEASE-server-cloudimg-${ARCH}.img $MDIR

+  pushd $PWD 2>/dev/null
+  cd $MDIR
+  sudo tar c . | sudo tar x -C $TARGET_ROOT -k --numeric-owner 
2>/dev/null

+  popd
+  # Clean up
+  sudo umount $MDIR
+  sudo rm -rf $IDIR $MDIR
+    fi
 }

 (


On 2/9/18 1:03 PM, Volodymyr Litovka wrote:

Hi Tony,

On 2/9/18 6:01 AM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 10:53:14PM +0200, Volodymyr Litovka wrote:

Hi colleagues,

does anybody here know how to prepare Ubuntu Artful (17.10) image using
diskimage-builder?

diskimage-builder use the following naming style for download -
$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz

and while "-root" names are there for trusty/amd64 and xenial/amd64 distros,
these archives for artful (and bionic) are absent on
cloud-images.ubuntu.com. There are just different kinds of images, not
source tree as in -root archives.

I will appreciate any ideas or knowledge how to customize 17.10-based image
using diskimage-builder or in diskimage-builder-like fashion.

You might like to investigate the ubuntu-minimal DIB element which will
build your ubuntu image from apt rather than starting with the pre-built
image.

good idea, but with

export DIST="ubuntu-minimal"
export DIB_RELEASE=artful

diskimage-builder fails with the following debug:

2018-02-09 10:33:22.426 | dib-run-parts Sourcing environment file 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 | + source 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 |  dirname 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.428 | +++ 
PATH='$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/tmp/in_target.d/pre-install.d/../environment.d/..'

2018-02-09 10:33:22.428 | +++ dib-init-system
2018-02-09 10:33:22.429 | + set -eu
2018-02-09 10:33:22.429 | + set -o pipefail
2018-02-09 10:33:22.429 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.429 | + [[ -f /sbin/initctl ]]
2018-02-09 10:33:22.429 | + [[ -f /etc/gentoo-release ]]
2018-02-09 10:33:22.429 | + [[ -f /sbin/init ]]
2018-02-09 10:33:22.429 | + echo 'Unknown init system'
2018-02-09 10:36:54.852 | + exit 1
2018-02-09 10:36:54.853 | ++ DIB_INIT_SYSTEM='Unknown init system

while earlier it find systemd

2018-02-09 10:33:22.221 | dib-run-parts Sourcing environment file 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 | + source 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 |  dirname 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.224 | +++ 
PATH=/home/doka/DIB/dib/bin:/home/doka/DIB/dib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/..

2018-02-09 10:33:22.224 | +++ dib-init-system
2018-02-09 10:33:22.225 | + set -eu
2018-02-09 10:33:22.225 | + set -o pipefail

Re: [Openstack-operators] [Openstack] diskimage-builder: prepare ubuntu 17.x images

2018-02-09 Thread Volodymyr Litovka

Hi Tony,

this patch works for me:

--- 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball.orig 
2018-02-09 12:20:02.117793234 +
+++ 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball 
2018-02-09 13:25:48.654868263 +

@@ -14,7 +14,9 @@

 DIB_CLOUD_IMAGES=${DIB_CLOUD_IMAGES:-http://cloud-images.ubuntu.com}
 DIB_RELEASE=${DIB_RELEASE:-trusty}
-BASE_IMAGE_FILE=${BASE_IMAGE_FILE:-$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz}
+SUFFIX="-root"
+[[ $DIB_RELEASE =~ (artful|bionic) ]] && SUFFIX=""
+BASE_IMAGE_FILE=${BASE_IMAGE_FILE:-$DIB_RELEASE-server-cloudimg-${ARCH}${SUFFIX}.tar.gz}
 
SHA256SUMS=${SHA256SUMS:-https://${DIB_CLOUD_IMAGES##http?(s)://}/$DIB_RELEASE/current/SHA256SUMS}
 CACHED_FILE=$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE
 CACHED_FILE_LOCK=$DIB_LOCKFILES/$BASE_IMAGE_FILE.lock
@@ -45,9 +47,25 @@
 fi
 popd
 fi
-    # Extract the base image (use --numeric-owner to avoid UID/GID 
mismatch between
-    # image tarball and host OS e.g. when building Ubuntu image on an 
openSUSE host)
-    sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE

+    if [ -n "$SUFFIX" ]; then
+  # Extract the base image (use --numeric-owner to avoid UID/GID 
mismatch between
+  # image tarball and host OS e.g. when building Ubuntu image on an 
openSUSE host)
+  sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE

+    else
+  # Unpack image to IDIR, mount it on MDIR, copy it to TARGET_ROOT
+  IDIR="/tmp/`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13 ; 
echo ''`"
+  MDIR="/tmp/`head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13 ; 
echo ''`"

+  sudo mkdir $IDIR $MDIR
+  sudo tar -C $IDIR --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE
+  sudo mount -o loop -t auto 
$IDIR/$DIB_RELEASE-server-cloudimg-${ARCH}.img $MDIR

+  pushd $PWD 2>/dev/null
+  cd $MDIR
+  sudo tar c . | sudo tar x -C $TARGET_ROOT -k --numeric-owner 
2>/dev/null

+  popd
+  # Clean up
+  sudo umount $MDIR
+  sudo rm -rf $IDIR $MDIR
+    fi
 }

 (


On 2/9/18 1:03 PM, Volodymyr Litovka wrote:

Hi Tony,

On 2/9/18 6:01 AM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 10:53:14PM +0200, Volodymyr Litovka wrote:

Hi colleagues,

does anybody here know how to prepare Ubuntu Artful (17.10) image using
diskimage-builder?

diskimage-builder use the following naming style for download -
$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz

and while "-root" names are there for trusty/amd64 and xenial/amd64 distros,
these archives for artful (and bionic) are absent on
cloud-images.ubuntu.com. There are just different kinds of images, not
source tree as in -root archives.

I will appreciate any ideas or knowledge how to customize 17.10-based image
using diskimage-builder or in diskimage-builder-like fashion.

You might like to investigate the ubuntu-minimal DIB element which will
build your ubuntu image from apt rather than starting with the pre-built
image.

good idea, but with

export DIST="ubuntu-minimal"
export DIB_RELEASE=artful

diskimage-builder fails with the following debug:

2018-02-09 10:33:22.426 | dib-run-parts Sourcing environment file 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 | + source 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 |  dirname 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.428 | +++ 
PATH='$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/tmp/in_target.d/pre-install.d/../environment.d/..'

2018-02-09 10:33:22.428 | +++ dib-init-system
2018-02-09 10:33:22.429 | + set -eu
2018-02-09 10:33:22.429 | + set -o pipefail
2018-02-09 10:33:22.429 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.429 | + [[ -f /sbin/initctl ]]
2018-02-09 10:33:22.429 | + [[ -f /etc/gentoo-release ]]
2018-02-09 10:33:22.429 | + [[ -f /sbin/init ]]
2018-02-09 10:33:22.429 | + echo 'Unknown init system'
2018-02-09 10:36:54.852 | + exit 1
2018-02-09 10:36:54.853 | ++ DIB_INIT_SYSTEM='Unknown init system

while earlier it find systemd

2018-02-09 10:33:22.221 | dib-run-parts Sourcing environment file 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 | + source 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 |  dirname 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.224 | +++ 
PATH=/home/doka/DIB/dib/bin:/home/doka/DIB/dib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/..

2018-02-09 10:33:22.224 | +++ dib-init-system
2018-02-09 10:33:22.225 | + set -eu
2018-02-09 10:33:22.225 | + set -o pipefail

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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/zaqar/

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/zaqar/log/?h=stable/queens

Release notes for zaqar can be found at:

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




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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/zaqar-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/zaqar-ui/log/?h=stable/queens

Release notes for zaqar-ui can be found at:

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

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

https://bugs.launchpad.net/zaqar-ui

and tag it *queens-rc-potential* to bring it to the zaqar-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] [OpenStack][Vitrage] .success error on vitrage-dashboard

2018-02-09 Thread MinWookKim
Hello Vitrage.

I installed the vitrage and vitrage-dashboard master versions and tested
them.

However, an unrecognized error ('.success () is not function') occurs and
all panels of the vitrage-dashboard do not appear normally.

I can not figure out the cause, but I changed the .success and .error of
each function to .then and .catch in dashboard / static / dashboard / projct
/ services / vitrage_topology.service.js.

As a result of this, I have confirmed the normal operation of the
vitrage-dashboard panel.

What is the cause?

Thanks :)


Best Regards,


Minwook.

__
OpenStack Development Mailing 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] diskimage-builder: prepare ubuntu 17.x images

2018-02-09 Thread Volodymyr Litovka

Hi Tony,

On 2/9/18 6:01 AM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 10:53:14PM +0200, Volodymyr Litovka wrote:

Hi colleagues,

does anybody here know how to prepare Ubuntu Artful (17.10) image using
diskimage-builder?

diskimage-builder use the following naming style for download -
$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz

and while "-root" names are there for trusty/amd64 and xenial/amd64 distros,
these archives for artful (and bionic) are absent on
cloud-images.ubuntu.com. There are just different kinds of images, not
source tree as in -root archives.

I will appreciate any ideas or knowledge how to customize 17.10-based image
using diskimage-builder or in diskimage-builder-like fashion.

You might like to investigate the ubuntu-minimal DIB element which will
build your ubuntu image from apt rather than starting with the pre-built
image.

good idea, but with

export DIST="ubuntu-minimal"
export DIB_RELEASE=artful

diskimage-builder fails with the following debug:

2018-02-09 10:33:22.426 | dib-run-parts Sourcing environment file 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 | + source 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 |  dirname 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.428 | +++ 
PATH='$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/tmp/in_target.d/pre-install.d/../environment.d/..'

2018-02-09 10:33:22.428 | +++ dib-init-system
2018-02-09 10:33:22.429 | + set -eu
2018-02-09 10:33:22.429 | + set -o pipefail
2018-02-09 10:33:22.429 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.429 | + [[ -f /sbin/initctl ]]
2018-02-09 10:33:22.429 | + [[ -f /etc/gentoo-release ]]
2018-02-09 10:33:22.429 | + [[ -f /sbin/init ]]
2018-02-09 10:33:22.429 | + echo 'Unknown init system'
2018-02-09 10:36:54.852 | + exit 1
2018-02-09 10:36:54.853 | ++ DIB_INIT_SYSTEM='Unknown init system

while earlier it find systemd

2018-02-09 10:33:22.221 | dib-run-parts Sourcing environment file 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 | + source 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 |  dirname 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.224 | +++ 
PATH=/home/doka/DIB/dib/bin:/home/doka/DIB/dib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/..

2018-02-09 10:33:22.224 | +++ dib-init-system
2018-02-09 10:33:22.225 | + set -eu
2018-02-09 10:33:22.225 | + set -o pipefail
2018-02-09 10:33:22.225 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.225 | + echo systemd
2018-02-09 10:33:22.226 | ++ DIB_INIT_SYSTEM=systemd
2018-02-09 10:33:22.226 | ++ export DIB_INIT_SYSTEM

it seems somewhere in the middle something happens to systemd package

In the meantime I'll look at how we can consume the .img file, which is
similar to what we'd need to do for Fedora
script 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball 
contains the function get_ubuntu_tarball() which, after all checks, does 
the following:


sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE


probably, the easiest hack around the issue is to change above to smth like

sudo (
mount -o loop  
tar cv   | tar xv -C $TARGET_ROOT ...
)

Will try this.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Re: [Openstack-operators] [Openstack] diskimage-builder: prepare ubuntu 17.x images

2018-02-09 Thread Volodymyr Litovka

Hi Tony,

On 2/9/18 6:01 AM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 10:53:14PM +0200, Volodymyr Litovka wrote:

Hi colleagues,

does anybody here know how to prepare Ubuntu Artful (17.10) image using
diskimage-builder?

diskimage-builder use the following naming style for download -
$DIB_RELEASE-server-cloudimg-$ARCH-root.tar.gz

and while "-root" names are there for trusty/amd64 and xenial/amd64 distros,
these archives for artful (and bionic) are absent on
cloud-images.ubuntu.com. There are just different kinds of images, not
source tree as in -root archives.

I will appreciate any ideas or knowledge how to customize 17.10-based image
using diskimage-builder or in diskimage-builder-like fashion.

You might like to investigate the ubuntu-minimal DIB element which will
build your ubuntu image from apt rather than starting with the pre-built
image.

good idea, but with

export DIST="ubuntu-minimal"
export DIB_RELEASE=artful

diskimage-builder fails with the following debug:

2018-02-09 10:33:22.426 | dib-run-parts Sourcing environment file 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 | + source 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.427 |  dirname 
/tmp/in_target.d/pre-install.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.428 | +++ 
PATH='$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/tmp/in_target.d/pre-install.d/../environment.d/..'

2018-02-09 10:33:22.428 | +++ dib-init-system
2018-02-09 10:33:22.429 | + set -eu
2018-02-09 10:33:22.429 | + set -o pipefail
2018-02-09 10:33:22.429 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.429 | + [[ -f /sbin/initctl ]]
2018-02-09 10:33:22.429 | + [[ -f /etc/gentoo-release ]]
2018-02-09 10:33:22.429 | + [[ -f /sbin/init ]]
2018-02-09 10:33:22.429 | + echo 'Unknown init system'
2018-02-09 10:36:54.852 | + exit 1
2018-02-09 10:36:54.853 | ++ DIB_INIT_SYSTEM='Unknown init system

while earlier it find systemd

2018-02-09 10:33:22.221 | dib-run-parts Sourcing environment file 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 | + source 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.223 |  dirname 
/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/10-dib-init-system.bash
2018-02-09 10:33:22.224 | +++ 
PATH=/home/doka/DIB/dib/bin:/home/doka/DIB/dib/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/tmp/dib_build.fJUf6F4d/hooks/extra-data.d/../environment.d/..

2018-02-09 10:33:22.224 | +++ dib-init-system
2018-02-09 10:33:22.225 | + set -eu
2018-02-09 10:33:22.225 | + set -o pipefail
2018-02-09 10:33:22.225 | + '[' -f /usr/bin/systemctl -o -f 
/bin/systemctl ']'

2018-02-09 10:33:22.225 | + echo systemd
2018-02-09 10:33:22.226 | ++ DIB_INIT_SYSTEM=systemd
2018-02-09 10:33:22.226 | ++ export DIB_INIT_SYSTEM

it seems somewhere in the middle something happens to systemd package

In the meantime I'll look at how we can consume the .img file, which is
similar to what we'd need to do for Fedora
script 
diskimage-builder/diskimage_builder/elements/ubuntu/root.d/10-cache-ubuntu-tarball 
contains the function get_ubuntu_tarball() which, after all checks, does 
the following:


sudo tar -C $TARGET_ROOT --numeric-owner -xzf 
$DIB_IMAGE_CACHE/$BASE_IMAGE_FILE


probably, the easiest hack around the issue is to change above to smth like

sudo (
mount -o loop  
tar cv   | tar xv -C $TARGET_ROOT ...
)

Will try this.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


[openstack-dev] [tc] Technical Committee Status update, February 9th

2018-02-09 Thread Thierry Carrez
Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker

If you are working on something (or plan to work on something)
governance-related that is not reflected on the tracker yet, please feel
free to add to it !


== Recently-approved changes ==

* Goal updates: neutron, vitrage
* New repo: ansible-role-k8s-cinder

Not much got approved this week, as the focus is on Queens release
candidate and PTG preparation.


== PTG preparation ==

The Dublin PTG will start in 17 days ! The schedule is now frozen at:

https://www.openstack.org/ptg#tab_schedule

That said, we have lots of openly-reservable rooms for last-minute
topics or continuing discussions beyond the allocated time.

Track leads have set up a number of etherpads to openly brainstorm what
to discuss. You can find those (or link to missing ones) here:

https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads


== Rocky goals ==

The most consensual set of goals for the Rocky cycle is still:
* Remove mox [1] (chandankumar)
* Enable toggling DEBUG option at runtime [2] (gcb)

Those will be approved on Tuesday unless new objections are posted that
result in TC members changing their votes.

As a reminder, the other proposed goals were:

* Storyboard Migration [3] (diablo_rojo)
* Ensure pagination links [4] (mordred)
* Add Cold upgrades capabilities [5] (masayuki)

Additionally, dhellmann proposed using StoryBoard to track goals[6].
This also has majority support and will be approved on Tuesday unless
new objections are posted.

[1] https://review.openstack.org/532361
[2] https://review.openstack.org/534605
[3] https://review.openstack.org/513875
[4] https://review.openstack.org/532627
[5] https://review.openstack.org/#/c/533544/
[6] https://review.openstack.org/534443


== Voting in progress ==

Monty proposed a resolution to dedicate the Queens release to the memory
of Shawn Pearce. This is still a few votes short:

https://review.openstack.org/541313


== Under discussion ==

A new project team was proposed to regroup people working on PowerVM
support in OpenStack. It is similar in many ways to the WinStackers team
(working on Hyper-V / Windows support). Please comment on the review at:

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

The discussion started by Graham Hayes to clarify how the testing of
interoperability programs should be organized in the age of add-on
trademark programs is still going on, now on an active mailing-list
thread. Please chime in to inform the TC choice:

https://review.openstack.org/521602
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126146.html


== TC member actions for the coming week(s) ==

In preparation for the PTG we need to do the final selection of
post-lunch presentations, proposed on:

https://etherpad.openstack.org/p/dublin-PTG-postlunch

We also need to start collecting topics of discussion for the TC track:

https://etherpad.openstack.org/p/PTG-Dublin-TC-topics

Finally we need to start the S release naming process. pabelanger
volunteered to lead that, and will push a release_naming.rst change
proposing dates and geographic area for the name choices.


== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on
#openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

For the coming week, I expect discussions to be around final Rocky goal
selection and PTG prep.

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


[Openstack-operators] DIB does not install trove-guestagent and mysql server in the image

2018-02-09 Thread okan sahiner
Hi everyone,

I followed the documentation Trove documentation mentioned here;

https://docs.openstack.org/trove/latest/admin/building_guest_images.html

However, I came up with the image I ran does not have trove agents and
mysql-server installed.

Elements I have used;

ubuntu vm cloud-init-datasources ubuntu-guest ubuntu-mysql

Regards,
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] [Openstack-sigs] [publiccloud-wg][keystone][Horizon] Multi-Factor Auth in OpenStack

2018-02-09 Thread Tobias Rydberg

Awesome reading Adrian!

This is really important stuff for the public cloud side if things, and 
much appreciated! Are you planning to come to the PTG in Dublin!


Cheers,
Tobias


On 2018-02-08 22:36, Adrian Turjak wrote:

Hello fellow Public Cloud operators!

I'm quite sorry I haven't been able to attend the last few public cloud 
meetings, have been deep in various bits of work, and been very asleep when the 
meetings normally were.

That said, I have some interesting things some of you might like to play with:
https://github.com/catalyst-cloud/adjutant-mfa

The above is a collection of plugins for Keystone, Horizon, and Adjutant that 
help facilitate MFA on an OpenStack cloud. Note, that while this is a working 
solution, it isn't merged or part of anything official upstream, just using the 
various plugin mechanisms. It uses existing pieces of working logic, and does 
nothing that isn't able to be migrated from.

My plan for the Rocky cycle is to work in Keystone and address the missing 
pieces I need to get MFA working properly throughout OpenStack in an actually 
useful way, and I'll provide updates for that once I have the specs ready to 
submit (am waiting until start of Rocky for that). The good thing, is that this 
current solution for MFA works, and it can be migrated from to the methods I 
intend to work on for Rocky. The same credential models will be used in 
Keystone, and I will write tools to take users with TOTP credentials and 
configure auth rules for them for more official MFA support in Keystone once it 
is useful.

We will be deploying the above MFA solution in our cloud in the next Month, and 
I'll provide you some updates as to how that goes, but do play with it 
yourselves, and tell me what you think. The solution does require technical 
domain knowledge to setup, but the docs in the above repo should hopefully be 
straightforward, if not, get in touch and I can help.

I hope to have some other useful bits of 'missing public cloud features' 
updates for you soon too.

Cheers,

Adrian Turjak



___
openstack-sigs mailing list
openstack-s...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs





smime.p7s
Description: S/MIME Cryptographic Signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [openstack-dev] [requirements] more help needed

2018-02-09 Thread Andrey Pavlov
Hi Matthew,

stable/queens has been created for ec2-api project.

project gce-api is mostly dead.

Regards,
Andrey Pavlov.
__
OpenStack Development Mailing 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]

2018-02-09 Thread Sam P
Hi Matthew,

 Thanks for the info.
 For Masakari, after discussing with release team, all following 3 project
will do independent
 release for Queens.
masakari   masakari
​​
masakari-monitorsmasakari
python-masakariclient   masakari

Still need 3-4 days to create stable/queens for masakari and
masakari-monitors
and python-masakariclinet can be done late today.
I will create stable/queens as soon as we merged the required patches.
Requirement update will unfreeze soon, and we will hold the requirement
updates till we create stable/queens.


--- Regards,
Sampath


On Thu, Feb 8, 2018 at 7:33 PM, Dmitry Tantsur  wrote:

> 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/refe
>> rence/projects.yaml#n1539
>>
>>
>>
>> 
>> __
>> 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


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

2018-02-09 Thread no-reply

Hello everyone,

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

https://tarballs.openstack.org/murano-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/murano-dashboard/log/?h=stable/queens

Release notes for murano-dashboard can be found at:

http://docs.openstack.org/releasenotes/murano-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