Re: [openstack-dev] [manila] [NEEDACTION] CI changes due to manila tempest tests new repository

[Silvan Kaiser]

Hi all!
Some late info for those not running DevStack gate, my migration took three
additions:

1) add the git checkout command as recommended
2) add "enable_plugin manila-tempest-plugin
https://github.com/openstack/manila-tempest-plugin"; to DevStacks local.conf
3) add running the setup.py command as recommended after stack.sh has been
run

Best regards & thanks for the migration hints!
Silvan



2017-12-13 14:22 GMT+01:00 Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com>:

> Hi all,
>
> As part of the effort of splitting tempest plugins to their own
> repositories [0], we are calling all Manila 3rd party CI maintainers to
> adjust their gate scripts to use the new tempest test repository
>
> If the third party CIs are configured to run with DevStack Gate, they only
> need to make a one line change to their gate scripts, manila-tempest-plugin
> can be installed and configured by Devstack gate prior to Devstack by using
> the "PROJECTS" variable, for example:
>
> export PROJECTS="openstack/manila-tempest-plugin $PROJECTS"
>
> This is how we used to set up python-manilaclient, so:
>
> export PROJECTS="openstack/python-manilaclient openstack/manila-tempest-plugin
> $PROJECTS"
>
> For those that are not using DevStack gate, you could just do this before
> Devstack:
>
> git clone https://git.openstack.org/openstack/manila-tempest-plugin
> /opt/stack/manila-tempest-plugin
> sudo python /opt/stack/manila-tempest-plugin/setup.py develop
>
> Both these methods will clone and install manila-tempest-plugin from
> git.openstack.org into $DEST/manila-tempest-plugin.
>
> We intend to make this change [1] effective after next weekly meeting, on
> Thursday 14th.
>
> It is important to note that CI mainteiners can make this change right
> away and it would not break CIs when this patch merges since all manila
> tempest tests
> are available in the new repo.
>
> Thanks,
>
> Victoria
>
> [0] https://governance.openstack.org/tc/goals/queens/split-
> tempest-plugins.html
> [1] https://review.openstack.org/#/c/512300/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Silvan Kaiser
Quobyte GmbH
Hardenbergplatz 2, 10623 Berlin - Germany
+49-30-814 591 800 - www.quobyte.com
Amtsgericht Berlin-Charlottenburg, HRB 149012B
Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
__
OpenStack Development Mailing 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] FFE Select Roles TripleO-UI

[Jiri Tomasek]

Hello,

I’d like to request an FFE to finish GUI work on roles management, specifically 
listing of roles and selection of roles for deployment. This feature is one of 
the main goals of current cycle. The pending patches are ready to be merged, 
mostly just waiting for tripleo-common patches to land (those already have FFE).

Blueprints:
https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-select-roles 

https://blueprints.launchpad.net/openstack/?searchtext=roles-crud-ui 


Patches:
https://review.openstack.org/#/q/topic:bp/tripleo-ui-select-roles+(status:open+OR+status:merged)
 


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

Re: [openstack-dev] [puppet] Ubuntu problems + Help needed

[Mohammed Naser]

Hi Tobias,

I think that's mainly the biggest issue we were dealing with which
forced us to stop Ubuntu from being voting.  I'm really not sure why
this is happening but it's happening only in Ubuntu.

Thanks,
Mohammed

On Sun, Jan 7, 2018 at 8:39 AM, Tobias Urdin  wrote:
> Hello everyone and a happy new year!
>
> I will follow this thread up with some information about the tempest failure 
> that occurs on Ubuntu.
> Saw it happen on my recheck tonight and took some time now to check it out 
> properly.
>
> * Here is the job: 
> http://logs.openstack.org/37/529837/1/check/puppet-openstack-integration-4-scenario003-tempest-ubuntu-xenial/84b60a7/
>
> * The following test is failing but only sometimes: 
> tempest.api.compute.servers.test_create_server.ServersTestManualDisk
> http://logs.openstack.org/37/529837/1/check/puppet-openstack-integration-4-scenario003-tempest-ubuntu-xenial/84b60a7/job-output.txt.gz#_2018-01-07_01_56_31_072370
>
> * Checking the nova API log is fails the request against neutron server
> http://logs.openstack.org/37/529837/1/check/puppet-openstack-integration-4-scenario003-tempest-ubuntu-xenial/84b60a7/logs/nova/nova-api.txt.gz#_2018-01-07_01_46_47_301
>
> So this is the call that times out: 
> https://github.com/openstack/nova/blob/3800cf6ae2a1370882f39e6880b7df4ec93f4b93/nova/api/openstack/compute/attach_interfaces.py#L61
>
> The timeout occurs at 01:46:47 but the first try is done at 01:46:17, 
> checking the log 
> http://logs.openstack.org/37/529837/1/check/puppet-openstack-integration-4-scenario003-tempest-ubuntu-xenial/84b60a7/logs/neutron/neutron-server.txt.gz
>  and searching for "GET 
> /v2.0/ports?device_id=285061f8-2e8e-4163-9534-9b02900a8887"
>
> You can see that neutron-server reports all request as 200 OK, so what I 
> think is that neutron-server performs the request properly but for some 
> reason nova-api does not get the reply and hence the timeout.
>
> This is where I get stuck because since I can see all requests coming in 
> there is no real way of seeing the replies.
> At the same time you can see nova-api and neutron-server are continously 
> handling requests so they are working but just that reply that neutron-server 
> should send to nova-api does not occur.
>
> Does anybody have any clue to why? Otherwise I guess the only way is to start 
> running the tests on a local machine until I get that issue, which does not 
> occur regularly.
>
> Maybe loop in the neutron and/or Canonical OpenStack team on this one.
>
> Best regards
> Tobias
>
>
> 
> From: Tobias Urdin 
> Sent: Friday, December 22, 2017 2:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [puppet] Ubuntu problems + Help needed
>
> Follow up, have been testing some integration runs on a tmp machine.
>
> Had to fix the following:
> * Ceph repo key E84AC2C0460F3994 perhaps introduced in [0]
> * Run glance-manage db_sync (have not seen in integration tests)
> * Run neutron-db-manage upgrade heads (have not seen in integration tests)
> * Disable l2gw because of
> https://bugs.launchpad.net/ubuntu/+source/networking-l2gw/+bug/1739779
>proposed temp fix until resolved as [1]
>
> [0] https://review.openstack.org/#/c/507925/
> [1] https://review.openstack.org/#/c/529830/
>
> Best regards
>
> On 12/22/2017 10:44 AM, Tobias Urdin wrote:
>> Ignore that, seems like it's the networking-l2gw package that fails[0]
>> Seems like it hasn't been packaged for queens yet[1] or more it seems
>> like a release has not been cut for queens for networking-l2gw[2]
>>
>> Should we try to disable l2gw like done in[3] recently for CentOS?
>>
>> [0]
>> http://logs.openstack.org/57/529657/2/check/puppet-openstack-integration-4-scenario004-tempest-ubuntu-xenial/ce6f987/logs/neutron/neutron-server.txt.gz#_2017-12-21_23_10_05_564
>> [1]
>> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/queens_versions.html
>> [2] https://git.openstack.org/cgit/openstack/networking-l2gw/refs/
>> [3] https://review.openstack.org/#/c/529711/
>>
>>
>> On 12/22/2017 10:19 AM, Tobias Urdin wrote:
>>> Follow up on Alex[1] point. The db sync upgrade for neutron fails here[0].
>>>
>>> [0] http://paste.openstack.org/show/629628/
>>>
>>> On 12/22/2017 04:57 AM, Alex Schultz wrote:
> Just a note, the queens repo is not currently synced in the infra so
> the queens repo patch is failing on Ubuntu jobs. I've proposed adding
> queens to the infra configuration to resolve this:
> https://review.openstack.org/529670
>
 As a follow up, the mirrors have landed and two of the four scenarios
 now pass.  Scenario001 is failing on ceilometer-api which was removed
 so I have a patch[0] to remove it. Scenario004 is having issues with
 neutron and the db looks to be very unhappy[1].

 Thanks,
 -Alex

 [0] https://review.openstack.org/529787
 [1] 
 http://logs.openstack.org/57/529657/2/check/puppet-op

[openstack-dev] [nova] Notification update week 2

[Balázs Gibizer]

Hi,

Here is the status update / focus settings mail for 2018 w2.

Bugs

[High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when 
sending notification during attach_interface

Fix merged to master. Backports have been proposed:
* Pike: https://review.openstack.org/#/c/531745/
* Queens: https://review.openstack.org/#/c/531746/

[High] https://bugs.launchpad.net/nova/+bug/1739325 Server operations 
fail to complete with versioned notifications if payload contains unset 
non-nullable fields

Patch has been proposed: https://review.openstack.org/#/c/529194/

[Low] https://bugs.launchpad.net/nova/+bug/1487038 
nova.exception._cleanse_dict should use 
oslo_utils.strutils._SANITIZE_KEYS

Old abandoned patches exist:
* https://review.openstack.org/#/c/215308/
* https://review.openstack.org/#/c/388345/


Versioned notification transformation
-
Here are the patches ready to review the rest are in merge  conflict or 
failing tests:
* https://review.openstack.org/#/c/410297 Transform missing delete 
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context 
manager
* https://review.openstack.org/#/c/403660 Transform instance.exists 
notification



Introduce instance.lock and instance.unlock notifications
---
A specless bp has been proposed to the Rocky cycle 
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
Some preliminary discussion happened in an earlier patch 
https://review.openstack.org/#/c/526251/



Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
There are two ongoing patches to look at.

Weekly meeting
--
The first meeting of 2018 is expected will be held on 9th of January.
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180109T17

Cheers,
gibi


__
OpenStack Development Mailing 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] questions about reno

[Doug Hellmann]

Excerpts from Gaetan's message of 2018-01-06 13:33:20 +0100:
> Hello
> 
> I played this week with reno and i really like it, but I have a bunch of
> question:
> - unreleased notes appear in release note with a title such as "0.1.0-2".
> Is it possible to not have any title or use "0.1.0-dev2" pattern like pbr ?

I'm not sure why it matters, but if you want to work on that patch I'll
help with reviews.

> - I guess that all notes should stay in the same folder version after
> versions, and the
> release notes of all versions will keep being automatically generated.
> Don't you think
> it might get difficult to manage all theses files? Is is possible to move
> them in different folder (at least a folder "archives?)

We've put off doing anything like that until we have a project with
enough notes that we can observe the problems and decide how to fix
them. Have you already reached that point or are you anticipating
problems in the future?

> - it is possible to generate the NEWS file using reno ? I started trying
> conversion with pandoc but the result are not great.

How is the NEWS file different from CHANGES.txt that pbr produces? Is it
the format, or the content?

> 
> If you find some features interesting, I'll be happy to contribute !
> 
> 
> -
> Gaetan / Stibbons

__
OpenStack Development Mailing 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] [oslo] proposing Stephen Finucan for oslo-core

[Doug Hellmann]

Stephen (sfinucan) has been working on pbr, oslo.config, and
oslo.policy and reviewing several of the other Oslo libraries for
a while now. His reviews are always helpful and I think he would
make a good addition to the oslo-core team.

As per our usual practice, please reply here with a +1 or -1 and
any reservations.

Doug

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

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Jay Pipes]

big +1 from me.

On 01/08/2018 09:55 AM, Doug Hellmann wrote:

Stephen (sfinucan) has been working on pbr, oslo.config, and
oslo.policy and reviewing several of the other Oslo libraries for
a while now. His reviews are always helpful and I think he would
make a good addition to the oslo-core team.

As per our usual practice, please reply here with a +1 or -1 and
any reservations.

Doug

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



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

[openstack-dev] [nova] [libvirt] [scaleio] ScaleIO libvirt volume driver native mode

[Balázs Gibizer]

Hi,

Two years ago a patch merged [1] that set AIO mode of some of the 
libivrt volume drivers to 'native' instead of the default 'threading'. 
At that time the ScaleIO driver was not modified. Recently we did some 
measurements (on Mitaka base) and we think that the ScaleIO volume 
driver could also benefit from the 'native' mode. So in Rocky we would 
like to propose a small change to set the 'native' mode for the ScaleIO 
volume driver too. Does anybody have opposing measurements or views?


Cheers,
gibi

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


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

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Davanum Srinivas]

+1 from me.

Thanks,
Dims

On Mon, Jan 8, 2018 at 9:58 AM, Jay Pipes  wrote:
> big +1 from me.
>
>
> On 01/08/2018 09:55 AM, Doug Hellmann wrote:
>>
>> Stephen (sfinucan) has been working on pbr, oslo.config, and
>> oslo.policy and reviewing several of the other Oslo libraries for
>> a while now. His reviews are always helpful and I think he would
>> make a good addition to the oslo-core team.
>>
>> As per our usual practice, please reply here with a +1 or -1 and
>> any reservations.
>>
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Lance Bragstad]

+1 from an oslo.policy perspective, his reviews have really been helping
me out there.


On 01/08/2018 08:58 AM, Jay Pipes wrote:
> big +1 from me.
>
> On 01/08/2018 09:55 AM, Doug Hellmann wrote:
>> Stephen (sfinucan) has been working on pbr, oslo.config, and
>> oslo.policy and reviewing several of the other Oslo libraries for
>> a while now. His reviews are always helpful and I think he would
>> make a good addition to the oslo-core team.
>>
>> As per our usual practice, please reply here with a +1 or -1 and
>> any reservations.
>>
>> Doug
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-01-08 09:55:26 -0500:
> Stephen (sfinucan) has been working on pbr, oslo.config, and

Oops, that's stephenfin. Sorry for the confusion.

Doug

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

Re: [openstack-dev] [congress] generic push driver

[Tim Hinrichs]

It's probably worth considering PATCH instead of PUT for updating the table.

http://restcookbook.com/HTTP%20Methods/patch/

You could also think about using JSON-patch to describe the requested
update.  It provides fine-grained update semantics:

https://tools.ietf.org/html/rfc6902

Tim

On Fri, Jan 5, 2018 at 5:50 PM Eric K  wrote:

> We've been discussing generic push drivers for Congress for quite a while.
> Finally sketching out something concrete and looking for some preliminary
> feedback. Below are sample interactions with a proposed generic push
> driver. A generic push driver could be used to receive push updates from
> vitrage, monasca, and many other sources.
>
> 1. creating a datasource:
>
> congress datasource create generic_push_driver vitrage --config schema='
> {
>   "tables":[
> {
>   "name":"alarms",
>   "columns":[
> "id",
> "name",
> "state",
> "severity",
>   ]
> }
>   ]
> }
> '
>
> 2. Update an entire table:
>
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> {
>   "rows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
> Note that a row can be either a {} or []
>
>
> 3. perform differential update:
>
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> {
>   "addrows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
>
> OR
>
> {
>   "deleterows":[
> {
>   "id":"1-1",
>   "name":"name1",
>   "state":"active",
>   "severity":1
> },
> [
>   "1-2",
>   "name2",
>   "active",
>   2
> ]
>   ]
> }
>
> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used
> together with some well defined semantics. Alternatively we may mandate
> that each request can have only one of the three pieces.
>
> Note 2: we leave it as the responsibility of the sender to send and
> confirm the requests for differential updates in correct order. We could
> add sequencing in future 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] [magnum] fedora atomic image with kubernetes with a CRI = frakti or clear containers

[Waines, Greg]

Hey there,

I am currently running magnum with the fedora-atomic image that is installed as 
part of the devstack installation of magnum.
This fedora-atomic image has kubernetes with a CRI of the standard docker 
container.

Where can i find (or how do i build) a fedora-atomic image with kubernetes and 
either frakti or clear containers (runV) as the CRI ?

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

Re: [openstack-dev] [tripleo] FFE Select Roles TripleO-UI

[Emilien Macchi]

On Mon, Jan 8, 2018 at 3:56 AM, Jiri Tomasek  wrote:
> Hello,
>
> I’d like to request an FFE to finish GUI work on roles management,
> specifically listing of roles and selection of roles for deployment. This
> feature is one of the main goals of current cycle. The pending patches are
> ready to be merged, mostly just waiting for tripleo-common patches to land
> (those already have FFE).
>
> Blueprints:
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-ui-select-roles
> https://blueprints.launchpad.net/openstack/?searchtext=roles-crud-ui
>
> Patches:
> https://review.openstack.org/#/q/topic:bp/tripleo-ui-select-roles+(status:open+OR+status:merged)

Since it's only affecting tripleo-ui and no impact on other projects,
+1 for me. It's indeed an important feature for Queens.

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] [oslo] proposing Stephen Finucan for oslo-core

[Ken Giusti]

+1 for Stephen!

On Mon, Jan 8, 2018 at 9:55 AM, Doug Hellmann  wrote:
> Stephen (sfinucan) has been working on pbr, oslo.config, and
> oslo.policy and reviewing several of the other Oslo libraries for
> a while now. His reviews are always helpful and I think he would
> make a good addition to the oslo-core team.
>
> As per our usual practice, please reply here with a +1 or -1 and
> any reservations.
>
> 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



-- 
Ken Giusti  (kgiu...@gmail.com)

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

Re: [openstack-dev] [reno] questions about reno

[Gaetan]

Hello

Thanks for your answers!

- unreleased notes appear in release note with a title such as "0.1.0-2".
> > Is it possible to not have any title or use "0.1.0-dev2" pattern like
> pbr ?
>
> I'm not sure why it matters, but if you want to work on that patch I'll
> help with reviews.
>

Ok, I'll see what I can do :)


>
> > - I guess that all notes should stay in the same folder version after
> > versions, and the
> > release notes of all versions will keep being automatically generated.
> > Don't you think
> > it might get difficult to manage all theses files? Is is possible to move
> > them in different folder (at least a folder "archives?)
>
> We've put off doing anything like that until we have a project with
> enough notes that we can observe the problems and decide how to fix
> them. Have you already reached that point or are you anticipating
> problems in the future?
>

No, just started using reno and just see that this folder might get messy
quickly. Maybe I over-think this, I agree with you to observe first

>
> > - it is possible to generate the NEWS file using reno ? I started trying
> > conversion with pandoc but the result are not great.
>
> How is the NEWS file different from CHANGES.txt that pbr produces? Is it
> the format, or the content?
>

So, I like PBR that generates ChangeLog from the git history, but it has
lot of details (maybe too much). So, I was thinking to store in NEWS only
the release note
As an example, you can look how I plan to use it for Guake:
https://github.com/Guake/guake
I usually write the NEWS at each release manually (
https://github.com/Guake/guake/blob/master/NEWS), and that's where reno
shines in my eyes :)

Regards,
Gaetan
__
OpenStack Development Mailing 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] [os-api-ref][doc] Adding openstack-doc-core to os-api-ref

[Petr Kovar]

On Thu, 4 Jan 2018 16:06:53 +
Graham Hayes  wrote:

> On 04/01/18 15:39, Stephen Finucane wrote:
> > I'm not sure what the procedure for this is but here goes.
> > 
> > I've noticed that the 'os-api-ref' project seems to have its own group
> > of cores [1], many of whom are no longer working on OpenStack (at
> > least, not full-time), and has a handful of open patches against it
> > [2]. Since the doc team has recently changed its scope from writing
> > documentation to enabling individual projects to maintain their own
> > docs, we've become mainly responsible for projects like 'openstack-doc-
> > theme'. Given that the 'os-api-ref' project is a Sphinx thing required
> > for multiple OpenStack projects, it seems like something that
> > could/should fall into the doc team's remit.
> > 
> > I'd like to move this project into the remit of the 'openstack-doc-
> > core' team, by way of removing the 'os-api-ref-core' group or adding
> > 'openstack-doc-core' to the list of included groups. In both cases,
> > existing active cores will be retained. Do any of the existing 'os-api-
> > ref' cores have any objections to this?
> 
> No objection from me
> 
> > Stephen
> > 
> > PS: I'm not sure how this affects things from a release management
> > perspective. Are there PTLs for these sorts of projects?
> 
> It does seem like a docs tooling thing, so maybe moving it to the docs
> project umbrella might be an idea?

What we do for other projects under that umbrella (such as
contributor-guide) is that we add openstack-doc-core as a group
member, as Stephen mentioned. This allows for other contributors to become
cores even if they are not interested in other aspects of the docs team's
work.

But I'm fine with whatever works for the current cores.

Thanks,
pk

__
OpenStack Development Mailing 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] [ResMgmt SIG]Proposal to form Resource Management SIG

[Zhipeng Huang]

Hi all,

With the maturing of resource provider/placement feature landing in
OpenStack in recent release, and also in light of Kubernetes community
increasing attention to the similar effort, I want to propose to form a
Resource Management SIG as a contact point for OpenStack community to
communicate with Kubernetes Resource Management WG[0] and other related
SIGs.

The formation of the SIG is to provide a gathering of similar interested
parties and establish an official channel. Currently we have already
OpenStack developers actively participating in kubernetes discussion (e.g.
[1]), we would hope the ResMgmt SIG could further help such activities and
better align the resource mgmt mechanism, especially the data modeling
between the two communities (or even more communities with similar desire).

I have floated the idea with Jay Pipes and Chris Dent and received positive
feedback. The SIG will have a co-lead structure so that people could
spearheading in the area they are most interested in. For example for me as
Cyborg dev, I will mostly lead in the area of acceleration[2].

If you are also interested please reply to this thread, and let's find a
efficient way to form this SIG. Efficient means no extra unnecessary
meetings and other undue burdens.

[0]
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU/edit?usp=sharing
[1] https://github.com/kubernetes/community/pull/782
[2] https://github.com/kubernetes/kubernetes/labels/area%2Fhw-accelerators

-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [Women of OpenStack] Kicking Off a New Year!

[Kendall Nelson]

Hello,

Today, Monday January 8th, we will be kicking off a new year of meetings
for the Women of OpenStack! Things have evolved a lot in the last few
months and we are excited to get started on our continued refresh. If you
are interested in what we are up to and want to get involved, or just want
to see what we are all about, please stop by our IRC Channel
#openstack-women at 20:00 UTC to join us for the meeting! If you are
interested in the proposed agenda or have something you want to add, check
it out here[0].

For more information about what we are about, check out our wiki page[1]!

Need help getting on IRC? Directions here[2]. I am also available by email
if you need extra help (knel...@openstack.org)

Can't wait to see you there!

-Kendall Nelson (diablo_rojo)

[0] https://etherpad.openstack.org/p/WOS_Agenda_Tracker
[1] https://wiki.openstack.org/wiki/Women_of_OpenStack
[2] https://docs.openstack.org/contributors/irc.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[Ben Nemec]

Definite +1

On 01/08/2018 08:55 AM, Doug Hellmann wrote:

Stephen (sfinucan) has been working on pbr, oslo.config, and
oslo.policy and reviewing several of the other Oslo libraries for
a while now. His reviews are always helpful and I think he would
make a good addition to the oslo-core team.

As per our usual practice, please reply here with a +1 or -1 and
any reservations.

Doug

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



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

[openstack-dev] [nova] Rocky PTG early planning

[Matt Riedemann]

As the Queens release winds to a close, I've started thinking about 
topics for Rocky that can be discussed at the PTG.


I've created an etherpad [1] for just throwing various topics in there, 
completely free-form at this point; just remember to add your name next 
to any topic you add.


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

--

Thanks,

Matt

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

Re: [openstack-dev] [nova] [libvirt] [scaleio] ScaleIO libvirt volume driver native mode

[Matt Riedemann]

On 1/8/2018 8:59 AM, Balázs Gibizer wrote:
Two years ago a patch merged [1] that set AIO mode of some of the 
libivrt volume drivers to 'native' instead of the default 'threading'. 
At that time the ScaleIO driver was not modified. Recently we did some 
measurements (on Mitaka base) and we think that the ScaleIO volume 
driver could also benefit from the 'native' mode. So in Rocky we would 
like to propose a small change to set the 'native' mode for the ScaleIO 
volume driver too. Does anybody have opposing measurements or views?


You should probably talk to Eric Young (e...@aceshome.com) who is 
working on adding the scaleio image backend for the libvirt driver.


--

Thanks,

Matt

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

Re: [openstack-dev] [nova] [libvirt] [scaleio] ScaleIO libvirt volume driver native mode

[young, eric]

On the surface, I have no problems with this.

Can you send me the measurements and an idea of what the patch would look like?

Please use my work email at eric.yo...@dell.com

Eric





On 1/8/18, 1:35 PM, "Matt Riedemann"  wrote:

>On 1/8/2018 8:59 AM, Balázs Gibizer wrote:
>> Two years ago a patch merged [1] that set AIO mode of some of the 
>> libivrt volume drivers to 'native' instead of the default 'threading'. 
>> At that time the ScaleIO driver was not modified. Recently we did some 
>> measurements (on Mitaka base) and we think that the ScaleIO volume 
>> driver could also benefit from the 'native' mode. So in Rocky we would 
>> like to propose a small change to set the 'native' mode for the ScaleIO 
>> volume driver too. Does anybody have opposing measurements or views?
>
>You should probably talk to Eric Young (e...@aceshome.com) who is 
>working on adding the scaleio image backend for the libvirt driver.
>
>-- 
>
>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-dev] [reno] questions about reno

[Doug Hellmann]

Excerpts from Gaetan's message of 2018-01-08 17:59:55 +0100:
> Hello
> 
> Thanks for your answers!
> 
> - unreleased notes appear in release note with a title such as "0.1.0-2".
> > > Is it possible to not have any title or use "0.1.0-dev2" pattern like
> > pbr ?
> >
> > I'm not sure why it matters, but if you want to work on that patch I'll
> > help with reviews.
> >
> 
> Ok, I'll see what I can do :)
> 
> >
> > > - I guess that all notes should stay in the same folder version after
> > > versions, and the
> > > release notes of all versions will keep being automatically generated.
> > > Don't you think
> > > it might get difficult to manage all theses files? Is is possible to move
> > > them in different folder (at least a folder "archives?)
> >
> > We've put off doing anything like that until we have a project with
> > enough notes that we can observe the problems and decide how to fix
> > them. Have you already reached that point or are you anticipating
> > problems in the future?
> >
> 
> No, just started using reno and just see that this folder might get messy
> quickly. Maybe I over-think this, I agree with you to observe first
> 
> >
> > > - it is possible to generate the NEWS file using reno ? I started trying
> > > conversion with pandoc but the result are not great.
> >
> > How is the NEWS file different from CHANGES.txt that pbr produces? Is it
> > the format, or the content?
> >
> 
> So, I like PBR that generates ChangeLog from the git history, but it has
> lot of details (maybe too much). So, I was thinking to store in NEWS only
> the release note
> As an example, you can look how I plan to use it for Guake:
> https://github.com/Guake/guake
> I usually write the NEWS at each release manually (
> https://github.com/Guake/guake/blob/master/NEWS), and that's where reno
> shines in my eyes :)

That looks similar to the output of the report command, although maybe
with less detail.

I can see a couple of ways to do this.

1. Use the report format as it is now.

2. Add a section to the note file to include a "highlight" or "news"
   entry that is ignored most of the time but can be used to produce
   summaries like this.

3. Try to somehow derive a summary from the text in the notes
   automatically.

Option 1 might work, although maybe you would end up with more detail
than you really want? If you were able to go this route, you could take
advantage of our plans to include release notes in source distributions
automatically (so you wouldn't even need to check the file into git).

Option 2 is do-able, but I'm a little concerned that having "magic"
sections makes the processing of the input files more complicated so
I'll have to think about whether it's really a good idea or not.

Option 3 sounds relatively hard, given that release notes just need to
be valid restructuredtext (meaning they don't need to be a list or other
structure that would be easy to take the "first" part of.

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] [infra][requirements][cinder] Handling requirements for driverfixes branches

[Eric Harney]

Hi all,

I'm trying to sort out how to run unit tests on Cinder driverfixes branches.

These branches are similar to stable branches, but live longer (and have
a different set of rules for what changes are appropriate).

In order for unit tests to work on these branches, requirements need to
be pinned in the same way they are for stable branches (i.e.
driverfixes/ocata matches stable/ocata's requirements).  Currently, unit
test jobs on these branches end up using requirements from master.

It is not clear how I can pin requirements on these branches, since they
aren't recognized as equivalent to stable branches by any of the normal
tooling used in CI.  I tried manually adding an upper-constraints.txt
here [1] but this does not result in the correct dependencies being used.

Where do changes need to be made for us to set the
requirements/upper-constraints correctly for these branches?


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

Thanks,
Eric

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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. ironic-lib patches to finish before the freeze
1.1. fix waiting for partition: https://review.openstack.org/#/c/529325/
2. Traits
2.1. https://review.openstack.org/#/c/528238/
3. Rescue:
3.1. RPC https://review.openstack.org/#/c/509336/
3.2. network interface update: https://review.openstack.org/#/c/509342
4. Routed Networks - Review for input only
4.1. Add baremetal neutron agent https://review.openstack.org/#/c/456235/
5. Finishing the CI for the ansible deploy work
5.1. https://review.openstack.org/529640
5.2. https://review.openstack.org/#/c/529383/
6. BIOS interface spec:
6.1. https://review.openstack.org/#/c/496481/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
https://review.openstack.org/#/c/530838/ - OOB Raid spec for iLO5
irmc:
None

oneview:
Introduce hpOneView and ilorest to OneView -  
https://review.openstack.org/#/c/523943/

Subproject priorities
-
bifrost:
Broken on recent fedora releases - TheJulia is working on it, patch should 
be up this week.
ironic-inspector (or its client):
(dtantsur) config options refactoring: 
https://review.openstack.org/#/c/515786/
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 18 Dec 2017 and 08 Jan 2018)
- Ironic: 219 bugs (+1) + 260 wishlist items (-1). 2 new, 158 in progress, 0 
critical, 34 high (+2) and 28 incomplete (-2)
- Inspector: 15 bugs (-2) + 28 wishlist items (-1). 0 new, 10 in progress (-5), 
0 critical, 3 high (-1) and 5 incomplete
- Nova bugs with Ironic tag: 13 (+1). 1 new (-1), 0 critical, 0 high
- via http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction
- may be fixed as part of https://review.openstack.org/#/c/460564/
- IPA may not find partition created by conductor 
https://bugs.launchpad.net/ironic-lib/+bug/1739421
- Fix proposed: https://review.openstack.org/#/c/529325/
- Inspector: Spurious race conditions detected white-/black-listing MAC 
addresses in dnsmasq PXE filter
- https://bugs.launchpad.net/ironic-inspector/+bug/1741035
- Milan's legacy - needs triaging

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/
- radosgw (https://bugs.launchpad.net/ironic/+bug/1737957)

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- Nova bug https://bugs.launchpad.n

Re: [openstack-dev] [infra][requirements][cinder] Handling requirements for driverfixes branches

[Doug Hellmann]

Excerpts from Eric Harney's message of 2018-01-08 14:05:35 -0500:
> Hi all,
> 
> I'm trying to sort out how to run unit tests on Cinder driverfixes branches.
> 
> These branches are similar to stable branches, but live longer (and have
> a different set of rules for what changes are appropriate).
> 
> In order for unit tests to work on these branches, requirements need to
> be pinned in the same way they are for stable branches (i.e.
> driverfixes/ocata matches stable/ocata's requirements).  Currently, unit
> test jobs on these branches end up using requirements from master.
> 
> It is not clear how I can pin requirements on these branches, since they
> aren't recognized as equivalent to stable branches by any of the normal
> tooling used in CI.  I tried manually adding an upper-constraints.txt
> here [1] but this does not result in the correct dependencies being used.
> 
> Where do changes need to be made for us to set the
> requirements/upper-constraints correctly for these branches?
> 
> 
> [1] https://review.openstack.org/#/c/503711/
> 
> Thanks,
> Eric
> 

You'll want to just update the UPPER_CONSTRAINTS_FILE setting in tox.ini
to point to the one for the relevant stable branch. If the branch no
longer exists, you should be able to refer to the version of the file
using the $release-eol tag instead of the branch name.

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] [neutron][all] nova_metadata_ip removal

[Brian Haley]

Hi,

As part of the normal deprecate/removal process, the 'nova_metadata_ip' 
option is being removed from neutron as it was replaced with 
'nova_metadata_host' in the Pike cycle, 
https://review.openstack.org/#/c/518836/


Codesearch did find various repos still using the old value, so I posted 
a number of cleanups for them since it was pretty painless, 
https://review.openstack.org/#/q/topic:nova_metadata_ip_deprecated+(status:open+OR+status:merged)


This is just an FYI for anyone else that might trip over the old value 
going away once it finally merges, most will probably never notice.


-Brian

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

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

[William M Edmonds]

> From: Matt Riedemann 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 01/03/2018 07:03 PM
> Subject: [openstack-dev] [nova] Working toward Queens feature freeze and
RC1
>
... snip ...
> The rest of the blueprints are tracked here:
>
> https://urldefense.proofpoint.com/v2/url?
>
u=https-3A__etherpad.openstack.org_p_nova-2Dqueens-2Dblueprint-2Dstatus&d=DwIGaQ&c=jf_iaSHvJObTbx-

>
siA1ZOg&r=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg&m=HVyvQHTZ4ft1C3JEJ9ij0uXwEy5_y3egSY7kNu_BvcU&s=mmvsEIKWRecnDlvYgLPwBAfPlVQQV5HEtHYMdDuaRME&e=


I updated that etherpad with the latest status for the powervm blueprint.
Should have 2 of the 3 remaining patches ready for review in the next day
or two, and the last later in the week.
__
OpenStack Development Mailing 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] [ResMgmt SIG]Proposal to form Resource Management SIG

[Jay Pipes]

On 01/08/2018 12:26 PM, Zhipeng Huang wrote:

Hi all,

With the maturing of resource provider/placement feature landing in 
OpenStack in recent release, and also in light of Kubernetes community 
increasing attention to the similar effort, I want to propose to form a 
Resource Management SIG as a contact point for OpenStack community to 
communicate with Kubernetes Resource Management WG[0] and other related 
SIGs.


The formation of the SIG is to provide a gathering of similar interested 
parties and establish an official channel. Currently we have already 
OpenStack developers actively participating in kubernetes discussion 
(e.g. [1]), we would hope the ResMgmt SIG could further help such 
activities and better align the resource mgmt mechanism, especially the 
data modeling between the two communities (or even more communities with 
similar desire).


I have floated the idea with Jay Pipes and Chris Dent and received 
positive feedback. The SIG will have a co-lead structure so that people 
could spearheading in the area they are most interested in. For example 
for me as Cyborg dev, I will mostly lead in the area of acceleration[2].


If you are also interested please reply to this thread, and let's find a 
efficient way to form this SIG. Efficient means no extra unnecessary 
meetings and other undue burdens.


+1

From the Nova perspective, the scheduler meeting (which is Mondays at 
1400 UTC) is the primary meeting where resource tracking and accounting 
issues are typically discussed.


Chris Dent has done a fabulous job recording progress on the resource 
providers and placement work over the last couple releases by issuing 
status emails to the openstack-dev@ mailing list each Friday.


I think having a bi-weekly cross-project (or even cross-ecosystem if 
we're talking about OpenStack+k8s) status email reporting any big events 
in the resource tracking world would be useful. As far as regular 
meetings for a resource management SIG, I'm +0 on that. I prefer to have 
targeted topical meetings over regular meetings.


Best,
-jay

__
OpenStack Development Mailing 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] Bug deputy report

[Miguel Lavalle]

   - https://bugs.launchpad.net/neutron/+bug/1741954:
   create_and_list_trunk_subports rally scenario failed with timeouts. Armando
   Migliaccio assigned to it
   - CRITICAL: https://bugs.launchpad.net/neutron/+bug/1741889 functional:
   DbAddCommand sometimes times out after 10 seconds. This is causing repeated
   failures of the functional tests jobs.
   - https://bugs.launchpad.net/neutron/+bug/1741411: Centralized floating
   ip Error status. Needs environment to be reproduced. Will ask Swami for
   input
   - https://bugs.launchpad.net/neutron/+bug/1741407: L3 HA: 2 masters
   after restart of l3 agent. Needs environment to be reproduced. Will ask
   Swami for input
   - https://bugs.launchpad.net/neutron/+bug/1741079: Deleting heat stack
   doesn't delete dns records. Seems to be a problem in Heat. Gathering data
   from submitter
   - https://bugs.launchpad.net/neutron/+bug/1740885: Security group
   updates fail when port hasn't been initialized yet. Jakub Libosvar assigned
   on it
__
OpenStack Development Mailing 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] [ResMgmt SIG]Proposal to form Resource Management SIG

[Eric Fried]

> I think having a bi-weekly cross-project (or even cross-ecosystem if
> we're talking about OpenStack+k8s) status email reporting any big events
> in the resource tracking world would be useful. As far as regular
> meetings for a resource management SIG, I'm +0 on that. I prefer to have
> targeted topical meetings over regular meetings.

Agree with this.  That said, please include me (efried) in whatever
shakes out.

On 01/08/2018 02:12 PM, Jay Pipes wrote:
> On 01/08/2018 12:26 PM, Zhipeng Huang wrote:
>> Hi all,
>>
>> With the maturing of resource provider/placement feature landing in
>> OpenStack in recent release, and also in light of Kubernetes community
>> increasing attention to the similar effort, I want to propose to form
>> a Resource Management SIG as a contact point for OpenStack community
>> to communicate with Kubernetes Resource Management WG[0] and other
>> related SIGs.
>>
>> The formation of the SIG is to provide a gathering of similar
>> interested parties and establish an official channel. Currently we
>> have already OpenStack developers actively participating in kubernetes
>> discussion (e.g. [1]), we would hope the ResMgmt SIG could further
>> help such activities and better align the resource mgmt mechanism,
>> especially the data modeling between the two communities (or even more
>> communities with similar desire).
>>
>> I have floated the idea with Jay Pipes and Chris Dent and received
>> positive feedback. The SIG will have a co-lead structure so that
>> people could spearheading in the area they are most interested in. For
>> example for me as Cyborg dev, I will mostly lead in the area of
>> acceleration[2].
>>
>> If you are also interested please reply to this thread, and let's find
>> a efficient way to form this SIG. Efficient means no extra unnecessary
>> meetings and other undue burdens.
> 
> +1
> 
> From the Nova perspective, the scheduler meeting (which is Mondays at
> 1400 UTC) is the primary meeting where resource tracking and accounting
> issues are typically discussed.
> 
> Chris Dent has done a fabulous job recording progress on the resource
> providers and placement work over the last couple releases by issuing
> status emails to the openstack-dev@ mailing list each Friday.
> 
> I think having a bi-weekly cross-project (or even cross-ecosystem if
> we're talking about OpenStack+k8s) status email reporting any big events
> in the resource tracking world would be useful. As far as regular
> meetings for a resource management SIG, I'm +0 on that. I prefer to have
> targeted topical meetings over regular meetings.
> 
> Best,
> -jay
> 
> __
> OpenStack Development Mailing 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] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Matthew Thode]

On 17-12-20 10:56:50, Matthew Thode wrote:
> On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> > Hi,
> > 
> > There is an open bug in launchpad about the new release of Networkx 2.0, 
> > that is backward incompatible with versions 1.x [1].
> > Is there a plan to change the Networkx version in the global requirements 
> > in Queens? We need to make some code refactoring in Vitrage, and I’m trying 
> > to understand how urgent it is.
> > 
> > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> > 
> 
> Mistral, Vitrage, Octavia, Taskflow, Watcher
> 
> Those are the projects using NetworkX that'd need to be updated.
> http://codesearch.openstack.org/?q=networkx&i=nope&files=.*requirements.*&repos=
> 
> I'm open to uncapping networkx if these projects have buyin.
> 

I've created https://review.openstack.org/531902 that your patches can
depend upon.

-- 
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] [neutron] Rocky PTG planning

[Miguel Lavalle]

Hi,

I have started an etherpad (
https://etherpad.openstack.org/p/neutron-ptg-rocky) to start planning the
topics we are going to discuss in the Neutron sessions during the Rocky PTG
in Dublin. At this point in time, it is entirely free form. Just make sure
you put your name and / or IRC nickname next to the topics you add

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

Re: [openstack-dev] [congress] generic push driver

[Eric K]

Hi Ifat,
From:  "Afek, Ifat (Nokia - IL/Kfar Sava)" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Sunday, January 7, 2018 at 4:00 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [congress] generic push driver

> Hi Eric,
>  
> I have two questions:
>  
> 1.  An alarm is usually raised on a resource, and in Vitrage we can send
> you the details of that resource. Is there a way in Congress for the alarm to
> reference a resource that exists in another table? And what if the resource
> does not exist in Congress?

First, the columns I chose are just a minimal sample to illustrate the
generic nature of the driver. In use with vitrage, we would probably also
want to include columns such as `resource_id`. Does that address the need to
reference a resource? That resource referenced by ID may or may not exist in
another part of Congress. It would be the job of the policy to resolve
references when taking appropriate actions. If referential integrity is
needed, additional policy rules can be specified to catch breakage.

This brings up a related question I had about vitrage:
Looking at the vertex properties listed here:
https://github.com/openstack/vitrage/blob/master/vitrage/common/constants.py
#L17

Where can I find more information about the type and content of data in each
property?

Exapmle:
- is the `resource` property an ID string or a python object reference?
- what does the property `is_real_vitrage_id` represent?
- what is the difference between `resource_id` and `vitrage_resource_id` ?

> 2.  Do you plan to support also updateRows? This can be useful for alarm
> state changes.

Are you thinking about updating an entire row or updating a specific field
of a row? That is, update
Row {"id":"1-1", "name":"name1", "state":"active", "severity":1} to become
{"id":"1-1", "name":"name1", "state":"active", "severity":100}
Vs
Update the severity field of row with id "1-1" to severity 100.
Both could be supported, but the second one is more complex to support
efficiently.

Thanks!
Eric
>  
> Thanks,
> Ifat
>  
>  
> 
> From: Eric K 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Saturday, 6 January 2018 at 3:50
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [congress] generic push driver
> 
>  
> 
> We've been discussing generic push drivers for Congress for quite a while.
> Finally sketching out something concrete and looking for some preliminary
> feedback. Below are sample interactions with a proposed generic push driver. A
> generic push driver could be used to receive push updates from vitrage,
> monasca, and many other sources.
> 
>  
> 
> 1. creating a datasource:
> 
>  
> 
> congress datasource create generic_push_driver vitrage --config schema='
> 
> {
> 
>   "tables":[
> 
> {
> 
>   "name":"alarms",
> 
>   "columns":[
> 
> "id",
> 
> "name",
> 
> "state",
> 
> "severity",
> 
>   ]
> 
> }
> 
>   ]
> 
> }
> 
> '
> 
>  
> 
> 2. Update an entire table:
> 
>  
> 
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> 
> {
> 
>   "rows":[
> 
> {
> 
>   "id":"1-1",
> 
>   "name":"name1",
> 
>   "state":"active",
> 
>   "severity":1
> 
> },
> 
> [
> 
>   "1-2",
> 
>   "name2",
> 
>   "active",
> 
>   2
> 
> ]
> 
>   ]
> 
> }
> 
> Note that a row can be either a {} or []
> 
>  
> 
>  
> 
> 3. perform differential update:
> 
>  
> 
> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
> 
> {
> 
>   "addrows":[
> 
> {
> 
>   "id":"1-1",
> 
>   "name":"name1",
> 
>   "state":"active",
> 
>   "severity":1
> 
> },
> 
> [
> 
>   "1-2",
> 
>   "name2",
> 
>   "active",
> 
>   2
> 
> ]
> 
>   ]
> 
> }
> 
>  
> 
> OR
> 
>  
> 
> {
> 
>   "deleterows":[
> 
> {
> 
>   "id":"1-1",
> 
>   "name":"name1",
> 
>   "state":"active",
> 
>   "severity":1
> 
> },
> 
> [
> 
>   "1-2",
> 
>   "name2",
> 
>   "active",
> 
>   2
> 
> ]
> 
>   ]
> 
> }
> 
>  
> 
> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together
> with some well defined semantics. Alternatively we may mandate that each
> request can have only one of the three pieces.
> 
>  
> 
> Note 2: we leave it as the responsibility of the sender to send and confirm
> the requests for differential updates in correct order. We could add
> sequencing in future 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 Development Mailing List (not for usage qu

Re: [openstack-dev] [congress] generic push driver

[Eric K]

From:  Tim Hinrichs 
Date:  Monday, January 8, 2018 at 7:31 AM
To:  Eric Kao 
Cc:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [congress] generic push driver

> It's probably worth considering PATCH instead of PUT for updating the table.
Ah right of course. PATCH makes more sense here.
> 
> http://restcookbook.com/HTTP%20Methods/patch/
> 
> You could also think about using JSON-patch to describe the requested update.
> It provides fine-grained update semantics:
> 
> https://tools.ietf.org/html/rfc6902
Hmm it would be very nice to follow an existing standard. Unfortunately the
json patch path specifications seem like an awkward fit with the set
semantics of congress tables. Removal, for example, must be done by
specifying the array index of the row to be removed. But perhaps we can
borrow the style of json patch for patching sets. For example:
PATCH '/v1/data-sources/vitrage/tables/alarms' with body:
[
  {
"op":"add",
"path":"/",
"value":{
  "id":"1-1",
  "name":"name1",
  "state":"active",
  "severity":1
}
  },
  {
"op":"add",
"path":"/",
"value":[
  "1-2",
  "name2",
  "active",
  2
]
  },
  {
"op":"remove",
"path":"/",
"value":[
  "1-2",
  "name2",
  "active",
  2
]
  }
]

Would that work well? At least there will be well-defined semantic based on
sequential operation.
> 
> Tim
> 
> On Fri, Jan 5, 2018 at 5:50 PM Eric K  wrote:
>> We've been discussing generic push drivers for Congress for quite a while.
>> Finally sketching out something concrete and looking for some preliminary
>> feedback. Below are sample interactions with a proposed generic push driver.
>> A generic push driver could be used to receive push updates from vitrage,
>> monasca, and many other sources.
>> 
>> 1. creating a datasource:
>> 
>> congress datasource create generic_push_driver vitrage --config schema='
>> {
>>   "tables":[
>> {
>>   "name":"alarms",
>>   "columns":[
>> "id",
>> "name",
>> "state",
>> "severity",
>>   ]
>> }
>>   ]
>> }
>> '
>> 
>> 2. Update an entire table:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "rows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> Note that a row can be either a {} or []
>> 
>> 
>> 3. perform differential update:
>> 
>> PUT '/v1/data-sources/vitrage/tables/alarms' with body:
>> {
>>   "addrows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> 
>> OR
>> 
>> {
>>   "deleterows":[
>> {
>>   "id":"1-1",
>>   "name":"name1",
>>   "state":"active",
>>   "severity":1
>> },
>> [
>>   "1-2",
>>   "name2",
>>   "active",
>>   2
>> ]
>>   ]
>> }
>> 
>> Note 1: we may allow 'rows', 'addrows', and 'deleterows' to be used together
>> with some well defined semantics. Alternatively we may mandate that each
>> request can have only one of the three pieces.
>> 
>> Note 2: we leave it as the responsibility of the sender to send and confirm
>> the requests for differential updates in correct order. We could add
>> sequencing in future 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] [designate] state of pdns4 backend

[Ritesh Anand]

Hi Stackers,

I see that we moved from PowerDNS Backend to PDNS4 backend, I have a few 
questions in that regard:

1. Should powerdns 3.4 (with PowerDNS backend) continue to work fine on Pike 
OpenStack?
2. Why did we change the default backend to BIND9?
3. How feasible is moving from one backend to other? Say if we move from 
PowerDNS to BIND9 backend, if I generate BIND zone files from PowerDNS mysql 
backed, and make necessary designate config changes, is that sufficient?

Thanks again for your help!

Best,
Ritesh

__
OpenStack Development Mailing 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] [ResMgmt SIG]Proposal to form Resource Management SIG

[Zhipeng Huang]

Agree 100% to avoid regular meeting and it is better to have bi-weekly
email report. Meeting should be arranged event based, and I think given the
status of OpenStack community's work on resource provider, mostly what we
need to do is attend k8s meetings (sig-scheduler, wg-resource-management,
etc.)

BTW for the RM SIG proposed here, let's not limit the scope to k8s only
since we might have broader collaborative efforts happening in the future.
k8s is our first primary target community to sync up with.

On Tue, Jan 9, 2018 at 4:12 AM, Jay Pipes  wrote:

> On 01/08/2018 12:26 PM, Zhipeng Huang wrote:
>
>> Hi all,
>>
>> With the maturing of resource provider/placement feature landing in
>> OpenStack in recent release, and also in light of Kubernetes community
>> increasing attention to the similar effort, I want to propose to form a
>> Resource Management SIG as a contact point for OpenStack community to
>> communicate with Kubernetes Resource Management WG[0] and other related
>> SIGs.
>>
>> The formation of the SIG is to provide a gathering of similar interested
>> parties and establish an official channel. Currently we have already
>> OpenStack developers actively participating in kubernetes discussion (e.g.
>> [1]), we would hope the ResMgmt SIG could further help such activities and
>> better align the resource mgmt mechanism, especially the data modeling
>> between the two communities (or even more communities with similar desire).
>>
>> I have floated the idea with Jay Pipes and Chris Dent and received
>> positive feedback. The SIG will have a co-lead structure so that people
>> could spearheading in the area they are most interested in. For example for
>> me as Cyborg dev, I will mostly lead in the area of acceleration[2].
>>
>> If you are also interested please reply to this thread, and let's find a
>> efficient way to form this SIG. Efficient means no extra unnecessary
>> meetings and other undue burdens.
>>
>
> +1
>
> From the Nova perspective, the scheduler meeting (which is Mondays at 1400
> UTC) is the primary meeting where resource tracking and accounting issues
> are typically discussed.
>
> Chris Dent has done a fabulous job recording progress on the resource
> providers and placement work over the last couple releases by issuing
> status emails to the openstack-dev@ mailing list each Friday.
>
> I think having a bi-weekly cross-project (or even cross-ecosystem if we're
> talking about OpenStack+k8s) status email reporting any big events in the
> resource tracking world would be useful. As far as regular meetings for a
> resource management SIG, I'm +0 on that. I prefer to have targeted topical
> meetings over regular meetings.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [ResMgmt SIG]Proposal to form Resource Management SIG

[Zhipeng Huang]

Hi Eric,

Glad to count you in :)

On Tue, Jan 9, 2018 at 4:57 AM, Eric Fried  wrote:

> > I think having a bi-weekly cross-project (or even cross-ecosystem if
> > we're talking about OpenStack+k8s) status email reporting any big events
> > in the resource tracking world would be useful. As far as regular
> > meetings for a resource management SIG, I'm +0 on that. I prefer to have
> > targeted topical meetings over regular meetings.
>
> Agree with this.  That said, please include me (efried) in whatever
> shakes out.
>
> On 01/08/2018 02:12 PM, Jay Pipes wrote:
> > On 01/08/2018 12:26 PM, Zhipeng Huang wrote:
> >> Hi all,
> >>
> >> With the maturing of resource provider/placement feature landing in
> >> OpenStack in recent release, and also in light of Kubernetes community
> >> increasing attention to the similar effort, I want to propose to form
> >> a Resource Management SIG as a contact point for OpenStack community
> >> to communicate with Kubernetes Resource Management WG[0] and other
> >> related SIGs.
> >>
> >> The formation of the SIG is to provide a gathering of similar
> >> interested parties and establish an official channel. Currently we
> >> have already OpenStack developers actively participating in kubernetes
> >> discussion (e.g. [1]), we would hope the ResMgmt SIG could further
> >> help such activities and better align the resource mgmt mechanism,
> >> especially the data modeling between the two communities (or even more
> >> communities with similar desire).
> >>
> >> I have floated the idea with Jay Pipes and Chris Dent and received
> >> positive feedback. The SIG will have a co-lead structure so that
> >> people could spearheading in the area they are most interested in. For
> >> example for me as Cyborg dev, I will mostly lead in the area of
> >> acceleration[2].
> >>
> >> If you are also interested please reply to this thread, and let's find
> >> a efficient way to form this SIG. Efficient means no extra unnecessary
> >> meetings and other undue burdens.
> >
> > +1
> >
> > From the Nova perspective, the scheduler meeting (which is Mondays at
> > 1400 UTC) is the primary meeting where resource tracking and accounting
> > issues are typically discussed.
> >
> > Chris Dent has done a fabulous job recording progress on the resource
> > providers and placement work over the last couple releases by issuing
> > status emails to the openstack-dev@ mailing list each Friday.
> >
> > I think having a bi-weekly cross-project (or even cross-ecosystem if
> > we're talking about OpenStack+k8s) status email reporting any big events
> > in the resource tracking world would be useful. As far as regular
> > meetings for a resource management SIG, I'm +0 on that. I prefer to have
> > targeted topical meetings over regular meetings.
> >
> > Best,
> > -jay
> >
> > 
> __
> > OpenStack Development Mailing 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
>



-- 
Zhipeng (Howard) Huang

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

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

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

[openstack-dev] [openstack-helm] normal team meeting tomorrow

[MCEUEN, MATT]

OpenStack-Helm team:

Due to availability of some folks who want to participate in our monthly 
CI/CD-focused meeting, we're going to push it back to 1/16.  Tomorrow's (1/9) 
meeting will be a normal weekly meeting instead.

Thanks!
Matt



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

Re: [openstack-dev] [infra][tempest][devstack][congress] tempest.config.CONF.service_available changed on Jan 2/3?

[Eric K]

On 1/7/18, 9:27 PM, "Ghanshyam Mann"  wrote:

>On Sat, Jan 6, 2018 at 3:41 PM, Chandan kumar 
>wrote:
>> Hello Eric,
>>
>> On Sat, Jan 6, 2018 at 4:46 AM, Eric K  wrote:
>>> Seems that sometime between 1/2 and 1/3 this year,
>>> tempest.config.CONF.service_available.aodh_plugin as well as
>>> ..service_available.mistral became unavailable in congress dsvm
>>>check/gate
>>> job. [1][2]
>>>
>>> I've checked the changes that went in to congress, tempest, devstack,
>>> devstack-gate, aodh, and mistral during that period but don't see
>>>obvious
>>> causes. Any suggestions on where to look next to fix the issue? Thanks
>>> very much!
>
>These config options should stay there even separating the tempest
>plugin.  I have checked aodh and mistral config options and there are
>present as tempest config.
>
>- 
>https://github.com/openstack/telemetry-tempest-plugin/blob/b30a19214d00361
>41de75047b444d48ae0d0b656/telemetry_tempest_plugin/config.py#L27
>- 
>https://github.com/openstack/mistral-tempest-plugin/blob/63a0fe20f98e0cb83
>16beb81ca77249ffdda29c5/mistral_tempest_tests/config.py#L18
>
>
>Issue occurred because of removing the in-tree plugins before congress
>was setup to use new repo. We should not remove the in-tree plugin
>before gate setup of consuming the new plugin is complete for each
>consumer of plugings.
>
>>>
>>
>> The aodh tempest plugin [https://review.openstack.org/#/c/526299/] is
>> moved to telemetry-tempest-plugin
>> [https://github.com/openstack/telemetry-tempest-plugin].
>> I have sent a patch to Congress project to fix the issue:
>> https://review.openstack.org/#/c/531534/
>
>Thanks Chandan, this will fix congress issue for Aodh, we need same
>fix for mistral case too.
Thank you Chandan Kumar and Ghanshyam Mann!
It seems that the adding of telemetry-tempest-plugin does not solve the
issue though.
I did a testing patch based-off of Chandan's, and the aodh test was still
skipped. Any ideas what more needs to be done? Thanks so much!
https://review.openstack.org/#/c/531922/
http://logs.openstack.org/22/531922/1/check/congress-devstack-api-mysql/381
2b5d/logs/testr_results.html.gz
>
>>
>> The mistral bundled intree tempest plugin
>> [https://review.openstack.org/#/c/526918/] is also moved to
>> mistral-tempest-plugin repo
>> [https://github.com/openstack/mistral-tempest-plugin]
>>
>> Tests are moved to a new repo as a part of Tempest Plugin Split goal
>> 
>>[https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.h
>>tml].
>> Feel free to consume the new tempest plugin and let me know if you
>> need any more help.
>>
>> Thanks,
>>
>> Chandan Kumar
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing 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] [os-vif]

[Sriharsha Basavapatna]

Hi,

I've uploaded a patch for review:
https://review.openstack.org/#/c/531674/

This is the first time I'm submitting a patch on openstack. I'd like
to add code reviewers on this patch. I'd appreciate if you could point
me to any guidelines on how to pick reviewers for a given project
(os-vif library in this case).

Thanks,
-Harsha

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

Re: [openstack-dev] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Renat Akhmerov]

We (Mistral) are ready to react too whenever the version is bumped. IMO, the 
sooner the better.

Thanks

Renat Akhmerov
@Nokia

On 9 Jan 2018, 04:00 +0700, Matthew Thode , wrote:
> On 17-12-20 10:56:50, Matthew Thode wrote:
> > On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> > > Hi,
> > >
> > > There is an open bug in launchpad about the new release of Networkx 2.0, 
> > > that is backward incompatible with versions 1.x [1].
> > > Is there a plan to change the Networkx version in the global requirements 
> > > in Queens? We need to make some code refactoring in Vitrage, and I’m 
> > > trying to understand how urgent it is.
> > >
> > > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> > >
> >
> > Mistral, Vitrage, Octavia, Taskflow, Watcher
> >
> > Those are the projects using NetworkX that'd need to be updated.
> > http://codesearch.openstack.org/?q=networkx&i=nope&files=.*requirements.*&repos=
> >
> > I'm open to uncapping networkx if these projects have buyin.
> >
>
> I've created https://review.openstack.org/531902 that your patches can
> depend upon.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-vif]

[Yatin Karel]

Hi Sriharsha,

You can check the core reviewers for os-vif here:-
https://review.openstack.org/#/admin/groups/1175,members

or from system:-  ssh -p 29418 @review.openstack.org gerrit ls-members os-vif-core  (This
can be run from the system for which you have added the puplic keys to
gerrit)

To add all core-reviewers, you can just type os-vif-core in Add
Reviewer Text box on gerrit.

For other projects:- Open Gerrit --> Go to People TAB --> Select "List
Groups" --> search project (look for -core)


Hope this helps.

On Tue, Jan 9, 2018 at 11:30 AM, Sriharsha Basavapatna
 wrote:
> Hi,
>
> I've uploaded a patch for review:
> https://review.openstack.org/#/c/531674/
>
> This is the first time I'm submitting a patch on openstack. I'd like
> to add code reviewers on this patch. I'd appreciate if you could point
> me to any guidelines on how to pick reviewers for a given project
> (os-vif library in this case).
>
> Thanks,
> -Harsha
>
> __
> OpenStack Development Mailing 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] [os-vif]

[Andreas Jaeger]

On 2018-01-09 07:00, Sriharsha Basavapatna wrote:
> Hi,
> 
> I've uploaded a patch for review:
> https://review.openstack.org/#/c/531674/
> 
> This is the first time I'm submitting a patch on openstack. I'd like
> to add code reviewers on this patch. I'd appreciate if you could point
> me to any guidelines on how to pick reviewers for a given project
> (os-vif library in this case).


In general, there's no need to add core reviewers to a review. Each of
us have their own dashboards or watch projects that we review and review
as time permits.

Since your change is failing the testsuite: Please fix tests first!

os-vif is part of nova, so if you want to discuss about it, best to join
the #openstack-nova freenode IRC channel,

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


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

[openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Hi root causers

I have been inspecting the code about aggregated state recently and have a
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured
data source, how do we apply the aggregation rules? It seems this is
handled in else clause.

if datasource_name in self.datasources_state_confs or \
datasource_name *not* in self.conf.datasources.types:
  ...

else:
self.category_normalizer[vitrage_category].set_aggregated_value(
new_vertex, self.UNDEFINED_DATASOURCE)
self.category_normalizer[vitrage_category].set_operational_value(
new_vertex, self.UNDEFINED_DATASOURCE)


There are some test case describing the expected behavior. But I
couldn't understand the design philosophy behind it. What is expected
when

   1. the data source is not defined
   2. data source defined but state config not exist
   3. data source defined, state config exist but the state is not found.

Could somebody shed some light on it?



-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
wrote:

> Hi root causers
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
> if datasource_name in self.datasources_state_confs or \
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
> self.category_normalizer[vitrage_category].set_aggregated_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
> self.category_normalizer[vitrage_category].set_operational_value(
> new_vertex, self.UNDEFINED_DATASOURCE)
>
>
> There are some test case describing the expected behavior. But I couldn't 
> understand the design philosophy behind it. What is expected when
>
>1. the data source is not defined
>2. data source defined but state config not exist
>3. data source defined, state config exist but the state is not found.
>
> Could somebody shed some light on it?
>
>
>
> --
> Yujun Zhang
>


-- 
Yujun Zhang
__
OpenStack Development Mailing 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] [os-vif]

[Andreas Jaeger]

On 2018-01-09 07:00, Sriharsha Basavapatna wrote:
> Hi,
> 
> I've uploaded a patch for review:
> https://review.openstack.org/#/c/531674/
> 
> This is the first time I'm submitting a patch on openstack. I'd like

Welcome to OpenStack, Harsha. Please read
https://docs.openstack.org/infra/manual/developers.html if you haven't.

I see that your change fails the basic tests, you can run these locally
as follows to check that your fixes will pass:

tox -e pep8
tox -e py27

Andreas

> to add code reviewers on this patch. I'd appreciate if you could point
> me to any guidelines on how to pick reviewers for a given project
> (os-vif library in this case).
> 
> Thanks,
> -Harsha
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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


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

Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core

[ChangBo Guo]

+1 for stephenfin.

2018-01-09 1:34 GMT+08:00 Ben Nemec :

> Definite +1
>
>
> On 01/08/2018 08:55 AM, Doug Hellmann wrote:
>
>> Stephen (sfinucan) has been working on pbr, oslo.config, and
>> oslo.policy and reviewing several of the other Oslo libraries for
>> a while now. His reviews are always helpful and I think he would
>> make a good addition to the oslo-core team.
>>
>> As per our usual practice, please reply here with a +1 or -1 and
>> any reservations.
>>
>> Doug
>>
>> 
>> __
>> 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
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing 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] [oslo] Rocky PTG planning

[ChangBo Guo]

Hi , The Dublin PTG is closing,  It' time to collect topics before the
PTG.  Just put your idea or discussion in
https://etherpad.openstack.org/p/oslo-ptg-rocky

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