Re: [openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

looping heat-dashboard team

2018-05-05 12:02 GMT+08:00 Rico Lin :

> Dear all Heat members and friends
>
> As you might award, OpenStack projects are scheduled to migrating ([5])
> from Launchpad to StoryBoard [1].
> For whom who like to know where to file a bug/blueprint, here are some
> heads up for you.
>
> *What's StoryBoard?*
> StoryBoard is a cross-project task-tracker, contains numbers of
> ``project``, each project contains numbers of ``story`` which you can think
> it as an issue or blueprint. Within each story, contains one or multiple
> ``task`` (task separate stories into the tasks to resolve/implement). To
> learn more about StoryBoard or how to make a good story, you can reference
> [6].
>
> *How to file a bug?*
> This is actually simple, use your current ubuntu-one id to access to
> storyboard. Then find the corresponding project in [2] and create a story
> to it with a description of your issue. We should try to create tasks which
> to reference with patches in Gerrit.
>
> *How to work on a spec (blueprint)?*
> File a story like you used to file a Blueprint. Create tasks for your
> plan. Also you might want to create a task for adding spec( in heat-spec
> repo) if your blueprint needs documents to explain.
> I still leave current blueprint page open, so if you like to create a
> story from BP, you can still get information. Right now we will start work
> as task-driven workflow, so BPs should act no big difference with a bug in
> StoryBoard (which is a story with many tasks).
>
> *Where should I put my story?*
> We migrate all heat sub-projects to StoryBoard to try to keep the impact
> to whatever you're doing as small as possible. However, if you plan to
> create a new story, *please create it under heat project [4]* and tag it
> with what it might affect with (like python-heatclint, heat-dashboard,
> heat-agents). We do hope to let users focus their stories in one place so
> all stories will get better attention and project maintainers don't need to
> go around separate places to find it.
>
> *How to connect from Gerrit to StoryBoard?*
> We usually use following key to reference Launchpad
> Closes-Bug: ###
> Partial-Bug: ###
> Related-Bug: ###
>
> Now in StoryBoard, you can use following key.
> Task: ##
> Story: ##
> you can find more info in [3].
>
> *What I need to do for my exists bug/bps?*
> Your bug is automatically migrated to StoryBoard, however, the reference
> in your patches ware not, so you need to change your commit message to
> replace the old link to launchpad to new links to StoryBoard.
>
> *Do we still need Launchpad after all this migration are done?*
> As the plan, we won't need Launchpad for heat anymore once we have done
> with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
> provide new information as many as possible. Hopefully, we can make
> everyone happy. For those newly created bugs during/after migration, don't
> worry we will disallow further create new bugs/bps and do a second migrate
> so we won't missed yours.
>
> [1] https://storyboard.openstack.org/
> [2] https://storyboard.openstack.org/#!/project_group/82
> [3] https://docs.openstack.org/infra/manual/developers.
> html#development-workflow
> [4] https://storyboard.openstack.org/#!/project/989
> [5] https://docs.openstack.org/infra/storyboard/migration.html
> [6] https://docs.openstack.org/infra/storyboard/gui/
> tasks_stories_tags.html#what-is-a-story
>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

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

[openstack-dev] [Openstack-operators][heat][all] Heat now migrated to StoryBoard!!

[Rico Lin]

Dear all Heat members and friends

As you might award, OpenStack projects are scheduled to migrating ([5])
from Launchpad to StoryBoard [1].
For whom who like to know where to file a bug/blueprint, here are some
heads up for you.

*What's StoryBoard?*
StoryBoard is a cross-project task-tracker, contains numbers of
``project``, each project contains numbers of ``story`` which you can think
it as an issue or blueprint. Within each story, contains one or multiple
``task`` (task separate stories into the tasks to resolve/implement). To
learn more about StoryBoard or how to make a good story, you can reference
[6].

*How to file a bug?*
This is actually simple, use your current ubuntu-one id to access to
storyboard. Then find the corresponding project in [2] and create a story
to it with a description of your issue. We should try to create tasks which
to reference with patches in Gerrit.

*How to work on a spec (blueprint)?*
File a story like you used to file a Blueprint. Create tasks for your plan.
Also you might want to create a task for adding spec( in heat-spec repo) if
your blueprint needs documents to explain.
I still leave current blueprint page open, so if you like to create a story
from BP, you can still get information. Right now we will start work as
task-driven workflow, so BPs should act no big difference with a bug in
StoryBoard (which is a story with many tasks).

*Where should I put my story?*
We migrate all heat sub-projects to StoryBoard to try to keep the impact to
whatever you're doing as small as possible. However, if you plan to create
a new story, *please create it under heat project [4]* and tag it with what
it might affect with (like python-heatclint, heat-dashboard, heat-agents).
We do hope to let users focus their stories in one place so all stories
will get better attention and project maintainers don't need to go around
separate places to find it.

*How to connect from Gerrit to StoryBoard?*
We usually use following key to reference Launchpad
Closes-Bug: ###
Partial-Bug: ###
Related-Bug: ###

Now in StoryBoard, you can use following key.
Task: ##
Story: ##
you can find more info in [3].

*What I need to do for my exists bug/bps?*
Your bug is automatically migrated to StoryBoard, however, the reference in
your patches ware not, so you need to change your commit message to replace
the old link to launchpad to new links to StoryBoard.

*Do we still need Launchpad after all this migration are done?*
As the plan, we won't need Launchpad for heat anymore once we have done
with migrating. Will forbid new bugs/bps filed in Launchpad. Also, try to
provide new information as many as possible. Hopefully, we can make
everyone happy. For those newly created bugs during/after migration, don't
worry we will disallow further create new bugs/bps and do a second migrate
so we won't missed yours.

[1] https://storyboard.openstack.org/
[2] https://storyboard.openstack.org/#!/project_group/82
[3]
https://docs.openstack.org/infra/manual/developers.html#development-workflow
[4] https://storyboard.openstack.org/#!/project/989
[5] https://docs.openstack.org/infra/storyboard/migration.html
[6]
https://docs.openstack.org/infra/storyboard/gui/tasks_stories_tags.html#what-is-a-story



-- 
May The Force of OpenStack Be With You,

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

Re: [openstack-dev] [kolla-ansible] Configure OpenStack services to use Rabbit HA queues

[Jeffrey Zhang]

Hi vladispay,

I guess you are talking rabbit_ha_queues options. It is already marked as
deprecated[0].

cfg.BoolOpt('rabbit_ha_queues',
default=False,
deprecated_group='DEFAULT',
help='Try to use HA queues in RabbitMQ (x-ha-policy: all). '
'If you change this option, you must wipe the RabbitMQ '
'database. In RabbitMQ 3.0, queue mirroring is no longer '
'controlled by the x-ha-policy argument when declaring a '
'queue. If you just want to make sure that all queues
(except '
'those with auto-generated names) are mirrored across all '
'nodes, run: '
"""\"rabbitmqctl set_policy HA '^(?!amq\.).*' """
"""'{"ha-mode": "all"}' \),

In kolla, we configure a global ha-mode policy through its definition.json
file in rabbitmq, please check[1]

[0] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_
drivers/impl_rabbit.py#L165-L176
[1] https://github.com/openstack/kolla-ansible/blob/
d2d9c6622888416ad2e748706fd237f8588e993a/ansible/roles/rabbitmq/templates/
definitions.json.j2#L20

On Sat, May 5, 2018 at 12:58 AM,  wrote:

> Hi,
>
> is there a reason we don't configure services for rabbitmq ha queues like
> it is suggested in [0] ?
> Rabbitmq itself has ha policy 'on' via one of its templates.
>
> Thanks,
> Vladislav Belogrudov
>
> [0] https://docs.openstack.org/ha-guide/shared-messaging.html#ra
> bbitmq-services
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Eric K]

Thanks a lot Witold and Thomas!

So it doesn't seem that someone is currently using a keystone token to
authenticate web hook? Is is simply because most of the use cases had
involved services which do not use keystone?

Or is it unsuitable for another reason?

On 5/4/18, 2:36 AM, "Thomas Herve"  wrote:

>On Thu, May 3, 2018 at 9:49 PM, Eric K  wrote:
>> Question to the projects which send or consume webhook notifications
>> (telemetry, monasca, senlin, vitrage, etc.), what are your
>> supported/preferred authentication mechanisms? Bearer token (e.g.
>> Keystone)? Signing?
>>
>> Any pointers to past discussions on the topic? My interest here is
>>having
>> Congress consume and send webhook notifications.
>>
>> I know some people are working on adding the keystone auth option to
>> Monasca's webhook framework. If there is a project that already does it,
>> it could be a very helpful reference.
>
>Hi,
>
>I'll add a few that you didn't mention which consume such webhooks.
>
> * Heat has been using EC2 signatures basically since forever. It
>creates EC2 credentials for a Keystone user, and signs URL that way.
> * Zaqar has signed URLs
>(https://developer.openstack.org/api-ref/message/#pre-signed-queue)
>which allows sharing queues without authentication.
> * Swift temp URLs
>(https://docs.openstack.org/swift/latest/middleware.html#tempurl) is a
>good mechanism to share information as well.
>
>I'd say application credentials would make those operations a bit
>nicer, but they are not completely there yet. Everybody not
>reinventing its own wheel would be nice too :).
>
>-- 
>Thomas
>
>__
>OpenStack Development Mailing 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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

I will not attend the vancouver summit but I’ll try to attend the berlin
one as it’s closer to me.

However I’ll be happy to join the conversation and give a hand, especially
if you need an operational point of view as our Openstack usage is
constantly growing within an heterogeneous environment ranging from a
grizzly cluster (deprecating it this year) to a shiny Queens one on
multiple geographic area.

I think our setup gives us a really good point of view of what are the
Openstack PITA and what operators are expecting the foundation to do with
such challenges.
Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil  a écrit :

> Right, let's announce the Proof of Concept project as of Neutron, invite
> anyone interested and start it.
>
> There is an API SIG BoF at Vancouver, where we will announce it too. And
> for everyone who can attend, to be welcome to discuss it:
>
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
>
> Yeah, Graphene is the only one listed by GraphQL organization for Python:
> http://graphql.org/code/#python.
>
> I think we should take this discussion on the coming project thread.
>
> Thank you everyone and see you there.
>
> Cheers,
> Gilles
>
> On 04/05/18 23:16, Flint WALRUS wrote:
>
> As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
> control plan API and the workers api.
>
> Ok, how do start to work on that? What’s the next step?
>
> Which server library do we want to use?
> I personally use graphene with python as it is the library listed by the
> official GraphQL website. I don’t even know if there is another library
> available indeed.
>
> Are we ok to try to use neutron as a PoC service?
>
> Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil  a
> écrit :
>
>> Actually Mutations fields are only data to be displayed, if needed, by
>> the response.
>> The data changes comes with the parameters.
>> So the correct mutation syntax is:
>>
>> mutation rebootServer {
>>updateServer(id: ) {
>>  reboot(type: "HARD")
>>}
>> }
>>
>> Also the latter example would be a "data API" equivalent using CRUD
>> function like "updateServer"
>>
>> And the following example would be a "plane API" equivalent approach
>> with an action function:
>>
>> mutation hardReboot {
>>rebootServer(id: , type: "HARD")
>> }
>>
>> Sorry for the initial confusion but I think this is important because
>> GraphQL schema helps clarify data and the operations.
>>
>>
>> On 04/05/18 13:20, Gilles Dubreuil wrote:
>> >
>> > On 04/05/18 05:34, Fox, Kevin M wrote:
>> >> k8s does that I think by separating desired state from actual state
>> >> and working to bring the two inline. the same could (maybe even
>> >> should) be done to openstack. But your right, that is not a small
>> >> amount of work.
>> >
>> > K8s makes perfect sense to follow declarative approach.
>> >
>> > That said a mutation following control plane API action semantic could
>> > be very similar:
>> >
>> > mutation rebootServer {
>> >   Server(id: ) {
>> > reboot: {
>> >   type: "HARD"
>> > }
>> >   }
>> > }
>> >
>> >
>> > "rebootServer" being an alias to name the request.
>> >
>> >
>> >> Even without using GraphQL, Making the api more declarative anyway,
>> >> has advantages.
>> >
>> > +1
>> >
>> >> Thanks,
>> >> Kevin
>> >> 
>> >> From: Jay Pipes [jaypi...@gmail.com]
>> >> Sent: Thursday, May 03, 2018 10:50 AM
>> >> To: openstack-dev@lists.openstack.org
>> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> >> inception?
>> >>
>> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil 
>> >>> wrote:
>> > • We should get a common consensus before all projects start to
>> > implement it.
>>  This is going to be raised during the API SIG weekly meeting later
>>  this week.
>>  API developers (at least one) from every project are strongly
>>  welcomed to participate.
>>  I suppose it makes sense for the API SIG to be the place to discuss
>>  it, at least initially.
>> >>> It was indeed discussed, and we think that it would be a worthwhile
>> >>> experiment. But it would be a difficult, if not impossible, proposal
>> >>> to have adopted OpenStack-wide without some data to back it up. So
>> >>> what we thought would be a good starting point would be to have a
>> >>> group of individuals interested in GraphQL form an informal team and
>> >>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
>> >>> Taylor suggested Neutron as an excellent candidate, as its API
>> >>> exposes things at an individual table level, requiring the client to
>> >>> join that information to get the answers they need.
>> >>>
>> >>> Once that is done, we could examine the results, and use them as the
>> >>> basis for proceeding with something more comprehensive. Does that
>> >>> sound like a good 

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

Right, let's announce the Proof of Concept project as of Neutron, invite 
anyone interested and start it.


There is an API SIG BoF at Vancouver, where we will announce it too. And 
for everyone who can attend, to be welcome to discuss it:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session

Yeah, Graphene is the only one listed by GraphQL organization for 
Python: http://graphql.org/code/#python.


I think we should take this discussion on the coming project thread.

Thank you everyone and see you there.

Cheers,
Gilles


On 04/05/18 23:16, Flint WALRUS wrote:
As clarify by Gilles and Kevin we absolutely can  get GraphQL with the 
control plan API and the workers api.


Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by 
the official GraphQL website. I don’t even know if there is another 
library available indeed.


Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil > a écrit :


Actually Mutations fields are only data to be displayed, if
needed, by
the response.
The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
   updateServer(id: ) {
 reboot(type: "HARD")
   }
}

Also the latter example would be a "data API" equivalent using CRUD
function like "updateServer"

And the following example would be a "plane API" equivalent approach
with an action function:

mutation hardReboot {
   rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important because
GraphQL schema helps clarify data and the operations.


On 04/05/18 13:20, Gilles Dubreuil wrote:
>
> On 04/05/18 05:34, Fox, Kevin M wrote:
>> k8s does that I think by separating desired state from actual
state
>> and working to bring the two inline. the same could (maybe even
>> should) be done to openstack. But your right, that is not a small
>> amount of work.
>
> K8s makes perfect sense to follow declarative approach.
>
> That said a mutation following control plane API action semantic
could
> be very similar:
>
> mutation rebootServer {
>   Server(id: ) {
>     reboot: {
>   type: "HARD"
>     }
>   }
> }
>
>
> "rebootServer" being an alias to name the request.
>
>
>> Even without using GraphQL, Making the api more declarative
anyway,
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> 
>> From: Jay Pipes [jaypi...@gmail.com ]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org

>> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> inception?
>>
>> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil
>
>>> wrote:
> • We should get a common consensus before all projects start to
> implement it.
 This is going to be raised during the API SIG weekly meeting
later
 this week.
 API developers (at least one) from every project are strongly
 welcomed to participate.
 I suppose it makes sense for the API SIG to be the place to
discuss
 it, at least initially.
>>> It was indeed discussed, and we think that it would be a
worthwhile
>>> experiment. But it would be a difficult, if not impossible,
proposal
>>> to have adopted OpenStack-wide without some data to back it
up. So
>>> what we thought would be a good starting point would be to have a
>>> group of individuals interested in GraphQL form an informal
team and
>>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
>>> Taylor suggested Neutron as an excellent candidate, as its API
>>> exposes things at an individual table level, requiring the
client to
>>> join that information to get the answers they need.
>>>
>>> Once that is done, we could examine the results, and use them
as the
>>> basis for proceeding with something more comprehensive. Does that
>>> sound like a good approach to (all of) you?
>> Did anyone bring up the differences between control plane APIs
and data
>> APIs and the applicability of GraphQL to the latter and not the
former?
>>
>> For example, a control plane API to reboot a server instance
looks like
>> this:
>>
>> POST /servers/{uuid}/action
>> {
>>   "reboot" : {
>>   "type" : "HARD"
>>   }
>> }
>>
   

Re: [openstack-dev] [sdk] issues with using OpenStack SDK Python client

[gerard.d...@wipro.com]

Many thanks for the welcome ;)

And many thanks for the speedy and very useful response !

Details below.

Best regards,
Gerard



For add_gateway_to_router():

So I tried this:
external_network = conn.network.find_network(EXTERNAL_NETWORK_NAME)
network_dict_body = {'network_id' : external_network.id}
conn.network.add_gateway_to_router(onap_router, **network_dict_body)

==> no errors, but the router is not updated (no gateway is set)
(external_gateway_info is still None)

(same with conn.network.add_gateway_to_router(onap_router, 
network_id=external_network.id) )

Is the body parameter for add_gateway_to_router() expected to correspond to a 
Network ?
(from a router point of view, a "gateway" is an external network)

Should the network's subnet(s) be also specified in the dictionary ? Maybe only
if certain specific subnets are desired for the gateway role. Otherwise,
the default would apply: there is usually only 1 subnet, and that's the one
to be used. So network_id would be enough to specify a gateway used in a 
standard way.

Maybe more details about what is expected in this body dictionary should be 
documented
in the add_gateway_to_router() section?

In Horizon, when selecting a router, and selecting "Set Gateway", the user is 
only
asked to pick an external network from a dropdown list. Then, a router 
interface is
implicitly created, with an IP@ picked from the subnet of that network.



For router deletion: it looks like it's the "!= None" test on the returned 
object that has an issue

onap_router  = conn.network.find_router(ONAP_ROUTER_NAME)
if onap_router != None:
print('Deleting ONAP router...')
conn.network.delete_router(onap_router.id)
else:
print('No ONAP router found...')

I added traceback printouts in the code.

printing the router before trying to delete it:
 onap_router:
 openstack.network.v2.router.Router(updated_at=2018-05-04T21:07:23Z, 
description=Router created for ONAP, status=ACTIVE, ha=False, name=ONAP_router, 
created_at=2018-05-04T21:07:20Z, tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, 
availability_zone_hints=[], admin_state_up=True, availability_zones=['nova'], 
tags=[], revision=3, routes=[], id=675abd14-096a-4b28-b764-31ca7098913b, 
external_gateway_info=None, distributed=False, flavor_id=None)


*** Exception:  'NoneType' object has no attribute 
'_body'
*** traceback.print_tb():
  File "auto_script_config_openstack_for_onap.py", line 141, in delete_all_ONAP
if onap_router != None:
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
358, in __eq__
return all([self._body.attributes == comparand._body.attributes,
*** traceback.print_exception():
Traceback (most recent call last):
  File "auto_script_config_openstack_for_onap.py", line 141, in delete_all_ONAP
if onap_router != None:
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
358, in __eq__
return all([self._body.attributes == comparand._body.attributes,
AttributeError: 'NoneType' object has no attribute '_body'




For identity_api_version=3 :

yes, that worked !

Could that identity_api_version parameter also/instead be specified in the 
clouds.yaml file ?



Here's the traceback info for the flavor error, also on the "!= None" test :

*** Exception:  'NoneType' object has no attribute 
'_body'
*** traceback.print_tb():
  File "auto_script_config_openstack_for_onap.py", line 537, in 
configure_all_ONAP
if tiny_flavor != None:
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
358, in __eq__
return all([self._body.attributes == comparand._body.attributes,
*** traceback.print_exception():
Traceback (most recent call last):
  File "auto_script_config_openstack_for_onap.py", line 537, in 
configure_all_ONAP
if tiny_flavor != None:
  File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
358, in __eq__
return all([self._body.attributes == comparand._body.attributes,
AttributeError: 'NoneType' object has no attribute '_body'




For the image creation:

ah, OK, indeed, there is an image proxy (even 2: v1, v2),
and maybe the compute / image operations are redundant (or maybe not, for 
convenience) ?

and yes, it worked ! There was no need for additional parameters.



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender 

[openstack-dev] [keystone] Keystone Team Update - Week of 30 April 2018

[Lance Bragstad]

# Keystone Team Update - Week of 30 April 2018

## News

Most of this week was spent firming up specification details. There were
a couple good discussions on unified limits and the default role work
we're targeting for the release.

## Open Specs

Dashboard: https://tinyurl.com/yagxuyfr

We had some really good discussions [0] regarding unified limits and
hierarchical enforcement models. We actually have the behaviors of a
specific enforcement model written down [1][2] and ready for review.
CERN was able to review it and gave us some positive feedback on the
approach. Please have a look if this interests you.

We've also decided to refocus the default roles work after getting some
help from jroll and the TC earlier today [3]. Harry re-proposed the
openstack-spec [4] to the keystone-spec [5] repository and summarized
the discussion on the mailing list [6].

[0] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-05-01.log.html#t2018-05-01T14:56:46[1]
 https://review.openstack.org/#/c/540803/[2] 
https://review.openstack.org/#/c/565412/[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-04.log.html#t2018-05-04T14:23:09[4]
 https://review.openstack.org/#/c/523973/[5] 
https://review.openstack.org/#/c/566377/[6] 
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130207.html

## Recently Merged Changes

Dashboard: https://tinyurl.com/yagxuyfr

We merged 17 changes this week.

## Changes that need Attention

Dashboard: https://tinyurl.com/yagxuyfr

There are 60 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. If you have time to
review, it would be greatly appreciated.

## Bugs

This week we opened 4 new bugs and fixed 1. We have 14 patches in review
that are mergeable and close a bug. There are 23 that are bug related
and don't have any negative feedback.

Search query: https://tinyurl.com/yag837l2

## Milestone Outlook

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

Our next deadline is June 8th, which is specification freeze.

## Help with this newsletter

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



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] [octavia] Sometimes amphoras are not re-created if they are not reached for more than heartbeat_timeout

[Michael Johnson]

I have commented on both of those stories. Thank you for submitting them.

As for the values,this is hard as those settings depend on a lot of
factors. The default values are targeted towards developers and likely
need to be adjusted for production. We have not yet put together our
deployment guide where we would cover this type of tuning. Sigh, so
much to do and not enough team members.

Here are some comments I can give on those settings:
[health_manager]
failover_threads - This is the maximum number of parallel failovers
each instance (process) of the octavia-healthmanager can process at
the same time. Beyond this number they queue until a thread becomes
available. If your cloud is fairly stable and you have few health
managers, this can be a reasonably low number. Consider the maximum
number of amphora you would have on a single compute host should it
fail. Also take into account the CPU power available on the health
manager host.

status_update_threads - This is the maximum number of health heartbeat
messages each instance (process) of the octavia-healthmanager can
process at the same time.  The more octavia-healthmanagers you have,
the lower this can be. The upper limit on this is related to how fast
your database is processing the updates. Should this number be too
low, the heatlh manager will start logging warnings that you need more
health managers.

[haproxy_amphora]
build_rate_limit
build_active_retries
These two settings are only used if build rate limiting is enabled
(not by default). This would be set if your Nova infrastructure cannot
handle the rate of instance builds Octavia is asking of it. This will
prioritize instance builds based on the need and will limit the rate
of instance builds Octavia asks Nova for.  The only impact to the
Octavia controllers is increased memory utilization if there are a
large number of builds being queued waiting for Nova.

You missed these two:
connection_max_retries
connection_retry_interval
These values are typically adjusted in production environments as they
are tuned for exceeding slow development systems (virtualbox, etc.)
where booting instances can take up to twenty minutes. This is the
time after Nova declares the instance "ACTIVE" and when the kernel
finishes booting in the instance and the amphora agent is running. The
default is to wait 25 minutes. In production you would expect to drop
this number significantly.  On a typical cloud this should take less
than thirty seconds, but you should give it some buffer in case a host
is especially busy.  Again this depends on the performance of your
cloud.


[controller_worker]
workers - This is the number of worker threads pulling user requests
from the oslo messaging queue for each instance of the octavia-worker
process.  This number would be tuned depending on the number of worker
controllers you have in your cloud and the rate of user requests
(create, update, delete) that need to be serviced by a worker. GET
calls do not require a worker. This will also be limited by the
controller host CPU and RAM capacities.

amp_active_retries
amp_active_wait_sec
Both of these values depend on the performance of your Nova
environment. This is how many times and how often we check Nova to see
if a requested instance has become "ACTIVE". Unless your Nova
environment is unusually slow, you should not need to change these
values.


[task_flow]
max_workers - This value limits the parallelism inside the TaskFlow
flows used by the controllers. Currently there is little reason to
adjust this value as the degrees of parallelism in our flows are not
higher than this value. However, when we release Active-Active load
balancers this value will control the number of parallel amphora
builds up to the build limit above.

Michael

On Thu, May 3, 2018 at 1:51 AM,   wrote:
> Hi Michael,
>
> I build a new amphora image with the latest patches and I reproduced two 
> different bugs that I see in my environment. One of them is similar to the 
> one initially described in this thread. I opened two stories as you advised:
>
> https://storyboard.openstack.org/#!/story/2001960
> https://storyboard.openstack.org/#!/story/2001955
>
> Meanwhile, can you provide some recommendation of values for the following 
> parameters (maybe in relation with number of workers, cores, computes etc)?
>
> [health_manager]
> failover_threads
> status_update_threads
>
> [haproxy_amphora]
> build_rate_limit
> build_active_retries
>
> [controller_worker]
> workers
> amp_active_retries
> amp_active_wait_sec
>
> [task_flow]
> max_workers
>
> Thank you for your help,
> Mihaela Balas
>
> -Original Message-
> From: Michael Johnson [mailto:johnso...@gmail.com]
> Sent: Friday, April 27, 2018 8:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [octavia] Sometimes amphoras are not re-created 
> if they are not reached for more than heartbeat_timeout
>
> Hi Mihaela,
>
> I am sorry to 

Re: [openstack-dev] [tc] [nova] [octavia] [ironic] [keystone] [policy] Spec. Freeze Exception - Default Roles

[Lance Bragstad]

On 05/04/2018 02:55 PM, Harry Rybacki wrote:
> Greetings All,
>
> After a discussion in #openstack-tc[1] earlier today, the Keystone
> team is adjusting its approach in proposing default roles[2].
> Subsequently, I have ported the current default roles specification
> from openstack-specs[3] to keystone-specs[2].
>
> The original review has been in a pretty stable state for a few weeks.
> As such, I propose we allow the new spec an exception to the original
> Rocky-m1 proposal freeze date.

I don't have an issue with this, especially since we talked about it heavily at 
the PTG. We also had people familiar with keystone +1 the openstack-spec prior 
to keystone's proposal freeze. I'm OK granting an exception here if other 
keystone contributors don't object.

>
> I invite more discussion around default roles, and our proposed
> approach. The Keystone team has a forum session[4] dedicated to this
> topic at 1135 on day one of the Vancouver Summit. Everyone should feel
> welcome and encouraged to attend -- we hope that this work will lead
> to an OpenStack Community Goal in a not-so-distant release.

I think scoping this down to be keystone-specific is a smart move. It allows us 
to focus on building a solid template for other projects to learn from. I was 
pleasantly surprised to hear people in -tc suggest this as a candidate for a 
community goal in Stein or T.

Also, big thanks to jroll, dhellmann, ttx, zaneb, smcginnis, johnsom, and 
mnaser for taking time to work through this with us.

> [1] - 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-04.log.html#t2018-05-04T14:40:36
> [2] - https://review.openstack.org/#/c/566377/
> [3] - https://review.openstack.org/#/c/523973/
> [4] - 
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21761/default-roles
>
>
> /R
>
> Harry Rybacki
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [tc] [nova] [octavia] [ironic] [keystone] [policy] Spec. Freeze Exception - Default Roles

[Harry Rybacki]

Greetings All,

After a discussion in #openstack-tc[1] earlier today, the Keystone
team is adjusting its approach in proposing default roles[2].
Subsequently, I have ported the current default roles specification
from openstack-specs[3] to keystone-specs[2].

The original review has been in a pretty stable state for a few weeks.
As such, I propose we allow the new spec an exception to the original
Rocky-m1 proposal freeze date.

I invite more discussion around default roles, and our proposed
approach. The Keystone team has a forum session[4] dedicated to this
topic at 1135 on day one of the Vancouver Summit. Everyone should feel
welcome and encouraged to attend -- we hope that this work will lead
to an OpenStack Community Goal in a not-so-distant release.

[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-04.log.html#t2018-05-04T14:40:36
[2] - https://review.openstack.org/#/c/566377/
[3] - https://review.openstack.org/#/c/523973/
[4] - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21761/default-roles


/R

Harry Rybacki

__
OpenStack Development Mailing 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] Skipping Office Hours on Monday

[Dougal Matthews]

Hey folks,

I forgot to say - I wont be around on Monday for office hours. Feel free to
carry on without me. It should be less formal than a meeting, so anyone can
chat - just send some messages to #openstack-mistral so folks know you are
around for it.

The ehterpad has a pinglist you can use to remind regulars.

https://etherpad.openstack.org/p/mistral-office-hours

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

Re: [openstack-dev] [all][infra] Upcoming changes in ARA Zuul job reports

[David Moreau Simard]

Hi,

It took longer than ancitipated but the necessary changes have landed
in both ARA and logs.openstack.org.
The reports should now be faster and more reliable.

Please let me know if you see anything out of the ordinary.

Thanks !


David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Wed, Apr 4, 2018 at 6:16 PM, David Moreau Simard  wrote:
> Hi,
>
> You might have noticed that the performance (and reliability) of the
> new reports aren't up to par.
> If you see failures in loading content, a refresh will usually fix the issue.
>
> We have different fixes to improve the performance and the reliability
> of the reports and we hope
> to be able to land them soon.
>
> In the meantime, please let us know if there is any report that
> appears to be particularly
> problematic.
>
> Thanks !
>
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Thu, Mar 29, 2018 at 6:14 PM, David Moreau Simard
>  wrote:
>> Hi,
>>
>> By default, all jobs currently benefit from the generation of a static
>> ARA report located in the "ara" directory at the root of the log
>> directory.
>> Due to scalability concerns, these reports were only generated when a
>> job failed and were not available on successful runs.
>>
>> I'm happy to announce that you can expect ARA reports to be available
>> for every job from now on -- including the successful ones !
>>
>> You'll notice a subtle but important change: the report directory will
>> henceforth be named "ara-report" instead of "ara".
>>
>> Instead of generating and saving a HTML report, we'll now only save
>> the ARA database in the "ara-report" directory.
>> This is a special directory from the perspective of the
>> logs.openstack.org server and ARA databases located in such
>> directories will be loaded dynamically by a WSGI middleware.
>>
>> You don't need to do anything to benefit from this change -- it will
>> be pushed to all jobs that inherit from the base job by default.
>>
>> However, if you happen to be using a "nested" installation of ARA and
>> Ansible (i.e, OpenStack-Ansible, Kolla-Ansible, TripleO, etc.), this
>> means that you can also leverage this feature.
>> In order to do that, you'll want to create an "ara-report" directory
>> and copy your ARA database inside before your logs are collected and
>> uploaded.
>>
>> To help you visualize:
>> /ara-report <-- This is the default Zuul report
>> /logs/ara <-- This wouldn't be loaded dynamically
>> /logs/ara-report <-- This would be loaded dynamically
>> /logs/some/directory/ara-report <-- This would be loaded dynamically
>>
>> For more details on this feature of ARA, you can refer to the documentation 
>> [1].
>>
>> Let me know if you have any questions !
>>
>> [1]: https://ara.readthedocs.io/en/latest/advanced.html
>>
>> 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] [all] Recent failures to use ARA or generate reports in the gate

[David Moreau Simard]

Hi,

I forgot to follow up but this was resolved last Monday April 30th
when Flask released 0.12.4.

Please let me know if you see anything out of the ordinary.

Thanks !


David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Fri, Apr 27, 2018 at 11:41 AM, David Moreau Simard
 wrote:
> Hi,
>
> I was made aware today that new installations of ARA were not working
> or failing to generate reports in a variety of gate jobs with a stack
> trace that ends with:
> AttributeError: 'Blueprint' object has no attribute 'json_encoder'
>
> The root cause was identified to be a new release of Flask, 0.12.3,
> which shipped broken packages to PyPi [1].
> This should be fixed momentarily once upstream ships a fixed 0.12.4 package.
>
> In the meantime, we're going to merge a requirements.txt update to
> blacklist 0.12.3 but it won't be effective until we cut a new release
> of ARA which we hope to be able to do sometime next week.
>
> I'll take the opportunity to remind users of ARA that we're
> transitioning away from statically generated reports [3] and you
> should do that too if you haven't already.
>
> [1]: https://github.com/pallets/flask/issues/2728
> [2]: 
> https://github.com/openstack/requirements/blob/a5537a6f4b9cc477067949e1f9136415ac216f21/upper-constraints.txt#
> L480
> [3]: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128902.html
>
> 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] [sdk] issues with using OpenStack SDK Python client

[Monty Taylor]

On 05/04/2018 01:34 PM, gerard.d...@wipro.com wrote:

Hi everybody,

As a bit of a novice, I'm trying to use OpenStack SDK 0.13 in an 
OPNFV/ONAP project (Auto).


Yay! Welcome.

I'm able to use the compute and network proxies, but have problems with 
the identity proxy,


so I can't create projects and users.

With network, I can create a network, a router, router interfaces, but 
can't add a gateway to a router. Also, deleting a router fails.


With compute, I can't create flavors, and not sure if there is a 
"create_image" method ?


Specific issues are listed below with more details.

Any pointers (configuration, installation, usage, ...) and URLs to 
examples and documentation would be welcome.


For documentation, I've been looking mostly at:

https://docs.openstack.org/openstacksdk/latest/user/proxies/network.html

https://docs.openstack.org/openstacksdk/latest/user/proxies/compute.html

https://docs.openstack.org/openstacksdk/latest/user/proxies/identity_v3.html 


Yes, that's all good documentation to follow.



Thanks in advance,

Gerard

For all code, import statement and Connection creation is as follows 
(constants defined before):


import openstack

conn = openstack.connect(cloud=OPENSTACK_CLOUD_NAME, 
region_name=OPENSTACK_REGION_NAME)


1) problem adding a gateway (external network) to a router:

not sure how to build a dictionary body (couldn't find examples online)

tried this:

network_dict_body = {'network_id': public_network.id}

and this (from looking at a router printout):

network_dict_body = {

     'external_fixed_ips': [{'subnet_id' : public_subnet.id}],

     'network_id': public_network.id

}

in both cases, tried this command:

conn.network.add_gateway_to_router(onap_router,network_dict_body)

getting the error:

Exception:  add_gateway_to_router() takes 2 
positional arguments but 3 were given


The signature for add_gateway_to_router looks like this:

  def add_gateway_to_router(self, router, **body):

the ** indicate that it's looking for the body as keyword arguments. 
Change your code to:


  conn.network.add_gateway_to_router(onap_router, **network_dict_body)

and it should work.

You could also, should you feel like it, do:

  conn.network.add_gateway_to_router(
  onap_router,
  external_fixed_ips=[{'subnet_id' : public_subnet.id}],
  network_id=public_network.id
  )

which is basically what the ** in **network_dict_body is doing.


printing the router gave this:

openstack.network.v2.router.Router(distributed=False, 
tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, 
created_at=2018-05-01T01:16:08Z, external_gateway_info=None, 
status=ACTIVE, availability_zone_hints=[], ha=False, tags=[], 
description=Router created for ONAP, admin_state_up=True, revision=1, 
flavor_id=None, id=b923fba5-5027-47b6-b679-29c331ac1aba, 
updated_at=2018-05-01T01:16:08Z, routes=[], name=onap_router, 
availability_zones=[])


2) problem deleting routers:

onap_router = conn.network.find_router(ONAP_ROUTER_NAME)

conn.network.delete_router(onap_router.id)

(same if conn.network.delete_router(onap_router))

getting the error:

Exception:  'NoneType' object has no attribute 
'_body'


I'm not sure yet what's causing this - it's the same issue you're having 
below with flavors - I'm looking in to it.


Do you have tracebacks for the exception?


printing the router that had been created gave this:

openstack.network.v2.router.Router(description=Router created for ONAP, 
status=ACTIVE, routes=[], updated_at=2018-05-01T01:16:11Z, ha=False, 
id=b923fba5-5027-47b6-b679-29c331ac1aba, external_gateway_info=None, 
admin_state_up=True, availability_zone_hints=[], 
tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, name=onap_router, 
availability_zones=['nova'], tags=[], revision=3, distributed=False, 
flavor_id=None, created_at=2018-05-01T01:16:08Z)


3) problem reaching the identity service:


There is an underlying bug/deficiency in the code that's next on my list 
to fix, but I'm waiting to land a patch to keystoneauth first. For now, 
add identity_api_version=3 to your openstack.connect line and it should 
work.


Also - sorry about that - that's a terrible experience and is definitely 
not the way it should/will work.


(although I can reach compute and network services, and although there 
are users and projects in the Openstack instance: "admin" and "service" 
projects, "ceilometer", "nova", etc. (and "admin") users)


     print("\nList Users:")

     i=1

     for user in conn.identity.users():

     print('User',str(i),'\n',user,'\n')

     i+=1

getting the error:

List Users:

Exception:  
NotFoundException: 404


     print("\nList Projects:")

     i=1

     for project in conn.identity.projects():

     print('Project',str(i),'\n',project,'\n')

     i+=1

also getting an error, but not the same as users:

List Projects:

Exception:  'Proxy' object has no attribute 
'projects'


if trying to create a project:

     onap_project 

[openstack-dev] [sdk] issues with using OpenStack SDK Python client

[gerard.d...@wipro.com]

Hi everybody,

As a bit of a novice, I'm trying to use OpenStack SDK 0.13 in an OPNFV/ONAP 
project (Auto).

I'm able to use the compute and network proxies, but have problems with the 
identity proxy,
so I can't create projects and users.
With network, I can create a network, a router, router interfaces, but can't 
add a gateway to a router. Also, deleting a router fails.
With compute, I can't create flavors, and not sure if there is a "create_image" 
method ?

Specific issues are listed below with more details.

Any pointers (configuration, installation, usage, ...) and URLs to examples and 
documentation would be welcome.
For documentation, I've been looking mostly at:
https://docs.openstack.org/openstacksdk/latest/user/proxies/network.html
https://docs.openstack.org/openstacksdk/latest/user/proxies/compute.html
https://docs.openstack.org/openstacksdk/latest/user/proxies/identity_v3.html

Thanks in advance,
Gerard




For all code, import statement and Connection creation is as follows (constants 
defined before):
import openstack
conn = openstack.connect(cloud=OPENSTACK_CLOUD_NAME, 
region_name=OPENSTACK_REGION_NAME)


1) problem adding a gateway (external network) to a router:
not sure how to build a dictionary body (couldn't find examples online)

tried this:
network_dict_body = {'network_id': public_network.id}

and this (from looking at a router printout):
network_dict_body = {
'external_fixed_ips': [{'subnet_id' : public_subnet.id}],
'network_id': public_network.id
}

in both cases, tried this command:
conn.network.add_gateway_to_router(onap_router,network_dict_body)

getting the error:
Exception:  add_gateway_to_router() takes 2 positional 
arguments but 3 were given

printing the router gave this:
openstack.network.v2.router.Router(distributed=False, 
tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, created_at=2018-05-01T01:16:08Z, 
external_gateway_info=None, status=ACTIVE, availability_zone_hints=[], 
ha=False, tags=[], description=Router created for ONAP, admin_state_up=True, 
revision=1, flavor_id=None, id=b923fba5-5027-47b6-b679-29c331ac1aba, 
updated_at=2018-05-01T01:16:08Z, routes=[], name=onap_router, 
availability_zones=[])


2) problem deleting routers:
onap_router = conn.network.find_router(ONAP_ROUTER_NAME)
conn.network.delete_router(onap_router.id)
(same if conn.network.delete_router(onap_router))

getting the error:
Exception:  'NoneType' object has no attribute '_body'

printing the router that had been created gave this:
openstack.network.v2.router.Router(description=Router created for ONAP, 
status=ACTIVE, routes=[], updated_at=2018-05-01T01:16:11Z, ha=False, 
id=b923fba5-5027-47b6-b679-29c331ac1aba, external_gateway_info=None, 
admin_state_up=True, availability_zone_hints=[], 
tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, name=onap_router, 
availability_zones=['nova'], tags=[], revision=3, distributed=False, 
flavor_id=None, created_at=2018-05-01T01:16:08Z)



3) problem reaching the identity service:
(although I can reach compute and network services, and although there are 
users and projects in the Openstack instance: "admin" and "service" projects, 
"ceilometer", "nova", etc. (and "admin") users)

print("\nList Users:")
i=1
for user in conn.identity.users():
print('User',str(i),'\n',user,'\n')
i+=1

getting the error:
List Users:
Exception:  NotFoundException: 
404

print("\nList Projects:")
i=1
for project in conn.identity.projects():
print('Project',str(i),'\n',project,'\n')
i+=1

also getting an error, but not the same as users:
List Projects:
Exception:  'Proxy' object has no attribute 'projects'


if trying to create a project:

onap_project = conn.identity.find_project(ONAP_TENANT_NAME)
if onap_project != None:
print('ONAP project/tenant already exists')
else:
print('Creating ONAP project/tenant...')
onap_project = conn.identity.create_project(
name = ONAP_TENANT_NAME,
description = ONAP_TENANT_DESC,
is_enabled = True)


getting the error:
Exception:  'Proxy' object has no attribute 
'find_project'


4) problem creating flavors:

tiny_flavor = conn.compute.find_flavor("m1.tiny")
if tiny_flavor != None:
print('m1.tiny Flavor already exists')
   else:
print('Creating m1.tiny Flavor...')
tiny_flavor = conn.compute.create_flavor(
name = 'm1.tiny',
vcpus = 1,
disk = 1,
ram = 512,
ephemeral = 0,
#swap = 0,
#rxtx_factor = 1.0,
is_public = True)

(by the way, maybe swap and rxtx are not supposed to be set ?)

getting the error:
Exception:  'NoneType' object has no attribute '_body'


5) how to create images ?
there is a compute proxy method: find_image()
but it looks like there is no 

[openstack-dev] [kolla-ansible] Configure OpenStack services to use Rabbit HA queues

[vladislav . belogrudov]

Hi,

is there a reason we don't configure services for rabbitmq ha queues 
like it is suggested in [0] ?

Rabbitmq itself has ha policy 'on' via one of its templates.

Thanks,
Vladislav Belogrudov

[0] 
https://docs.openstack.org/ha-guide/shared-messaging.html#rabbitmq-services


__
OpenStack Development Mailing 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] Does the openstack ci vms start each time clear up enough?

[Clark Boylan]

On Fri, May 4, 2018, at 2:37 AM, Sean McGinnis wrote:
> On Fri, May 04, 2018 at 04:13:41PM +0800, linghucongsong wrote:
> > 
> > Hi all!
> > 
> > Recently we meet a strange problem in our ci. look this link: 
> > https://review.openstack.org/#/c/532097/
> > 
> > we can pass the ci in the first time, but when we begin to start the gate 
> > job, it will always failed in the second time.
> > 
> > we have rebased several times, it alway pass the ci in the first time and 
> > failed in the second time.
> > 
> > This have not happen before  and make me to guess is it really we start the 
> > ci from the new fresh vms each time?
> 
> A new VM is spun up for each test run, so I don't believe this is an issue 
> with
> stale artifacts on the host. I would guess this is more likely some sort of
> race condition, and you just happen to be hitting it 50% of the time.

Additionally you can check the job logs to see while these two jobs did run 
against the same cloud provider they did so in different regions on hosts with 
completely different IP addresses. The inventory files [0][1] are where I would 
start if you suspect oddness of this sort. Reading them I don't see anything to 
indicate the nodes were reused.

[0] 
http://logs.openstack.org/97/532097/16/check/legacy-tricircle-dsvm-multiregion/c9b3d29/zuul-info/inventory.yaml
[1] 
http://logs.openstack.org/97/532097/16/gate/legacy-tricircle-dsvm-multiregion/ad547d5/zuul-info/inventory.yaml

Clark

__
OpenStack Development Mailing 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] reboot a rescued instance?

[Chris Friesen]

On 05/04/2018 07:50 AM, Matt Riedemann wrote:

For full details on this, see the IRC conversation [1].

tl;dr: the nova compute manager and xen virt driver assume that you can reboot a
rescued instance [2] but the API does not allow that [3] and as far as I can
tell, it never has.

I can only assume that Rackspace had an out of tree change to the API to allow
rebooting a rescued instance. I don't know why that wouldn't have been
upstreamed, but the upstream API doesn't allow it. I'm also not aware of
anything internal to nova that reboots an instance in a rescued state.

So the question now is, should we add rescue to the possible states to reboot an
instance in the API? Or just rollback this essentially dead code in the compute
manager and xen virt driver? I don't know if any other virt drivers will support
rebooting a rescued instance.


Not sure where the more recent equivalent is, but the mitaka user guide[1] has 
this:

"Pause, suspend, and stop operations are not allowed when an instance is running 
in rescue mode, as triggering these actions causes the loss of the original 
instance state, and makes it impossible to unrescue the instance."


Would the same logic apply to reboot since it's basically stop/start?

Chris



[1] https://docs.openstack.org/mitaka/user-guide/cli_reboot_an_instance.html

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

[openstack-dev] [nova] reboot a rescued instance?

[Matt Riedemann]

For full details on this, see the IRC conversation [1].

tl;dr: the nova compute manager and xen virt driver assume that you can 
reboot a rescued instance [2] but the API does not allow that [3] and as 
far as I can tell, it never has.


I can only assume that Rackspace had an out of tree change to the API to 
allow rebooting a rescued instance. I don't know why that wouldn't have 
been upstreamed, but the upstream API doesn't allow it. I'm also not 
aware of anything internal to nova that reboots an instance in a rescued 
state.


So the question now is, should we add rescue to the possible states to 
reboot an instance in the API? Or just rollback this essentially dead 
code in the compute manager and xen virt driver? I don't know if any 
other virt drivers will support rebooting a rescued instance.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-05-03.log.html#t2018-05-03T18:49:58
[2] 
https://review.openstack.org/#/q/topic:bug/1170237+(status:open+OR+status:merged
[3] 
https://github.com/openstack/nova/blob/4b0d0ea9f18139d58103a520a6a4e9119e19a4de/nova/compute/vm_states.py#L69-L72


--

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] [nova] reboot a rescued instance?

[Matt Riedemann]

For full details on this, see the IRC conversation [1].

tl;dr: the nova compute manager and xen virt driver assume that you can 
reboot a rescued instance [2] but the API does not allow that [3] and as 
far as I can tell, it never has.


I can only assume that Rackspace had an out of tree change to the API to 
allow rebooting a rescued instance. I don't know why that wouldn't have 
been upstreamed, but the upstream API doesn't allow it. I'm also not 
aware of anything internal to nova that reboots an instance in a rescued 
state.


So the question now is, should we add rescue to the possible states to 
reboot an instance in the API? Or just rollback this essentially dead 
code in the compute manager and xen virt driver? I don't know if any 
other virt drivers will support rebooting a rescued instance.


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-05-03.log.html#t2018-05-03T18:49:58
[2] 
https://review.openstack.org/#/q/topic:bug/1170237+(status:open+OR+status:merged
[3] 
https://github.com/openstack/nova/blob/4b0d0ea9f18139d58103a520a6a4e9119e19a4de/nova/compute/vm_states.py#L69-L72


--

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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
control plan API and the workers api.

Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by the
official GraphQL website. I don’t even know if there is another library
available indeed.

Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil  a écrit :

> Actually Mutations fields are only data to be displayed, if needed, by
> the response.
> The data changes comes with the parameters.
> So the correct mutation syntax is:
>
> mutation rebootServer {
>updateServer(id: ) {
>  reboot(type: "HARD")
>}
> }
>
> Also the latter example would be a "data API" equivalent using CRUD
> function like "updateServer"
>
> And the following example would be a "plane API" equivalent approach
> with an action function:
>
> mutation hardReboot {
>rebootServer(id: , type: "HARD")
> }
>
> Sorry for the initial confusion but I think this is important because
> GraphQL schema helps clarify data and the operations.
>
>
> On 04/05/18 13:20, Gilles Dubreuil wrote:
> >
> > On 04/05/18 05:34, Fox, Kevin M wrote:
> >> k8s does that I think by separating desired state from actual state
> >> and working to bring the two inline. the same could (maybe even
> >> should) be done to openstack. But your right, that is not a small
> >> amount of work.
> >
> > K8s makes perfect sense to follow declarative approach.
> >
> > That said a mutation following control plane API action semantic could
> > be very similar:
> >
> > mutation rebootServer {
> >   Server(id: ) {
> > reboot: {
> >   type: "HARD"
> > }
> >   }
> > }
> >
> >
> > "rebootServer" being an alias to name the request.
> >
> >
> >> Even without using GraphQL, Making the api more declarative anyway,
> >> has advantages.
> >
> > +1
> >
> >> Thanks,
> >> Kevin
> >> 
> >> From: Jay Pipes [jaypi...@gmail.com]
> >> Sent: Thursday, May 03, 2018 10:50 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
> >> inception?
> >>
> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil 
> >>> wrote:
> > • We should get a common consensus before all projects start to
> > implement it.
>  This is going to be raised during the API SIG weekly meeting later
>  this week.
>  API developers (at least one) from every project are strongly
>  welcomed to participate.
>  I suppose it makes sense for the API SIG to be the place to discuss
>  it, at least initially.
> >>> It was indeed discussed, and we think that it would be a worthwhile
> >>> experiment. But it would be a difficult, if not impossible, proposal
> >>> to have adopted OpenStack-wide without some data to back it up. So
> >>> what we thought would be a good starting point would be to have a
> >>> group of individuals interested in GraphQL form an informal team and
> >>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
> >>> Taylor suggested Neutron as an excellent candidate, as its API
> >>> exposes things at an individual table level, requiring the client to
> >>> join that information to get the answers they need.
> >>>
> >>> Once that is done, we could examine the results, and use them as the
> >>> basis for proceeding with something more comprehensive. Does that
> >>> sound like a good approach to (all of) you?
> >> Did anyone bring up the differences between control plane APIs and data
> >> APIs and the applicability of GraphQL to the latter and not the former?
> >>
> >> For example, a control plane API to reboot a server instance looks like
> >> this:
> >>
> >> POST /servers/{uuid}/action
> >> {
> >>   "reboot" : {
> >>   "type" : "HARD"
> >>   }
> >> }
> >>
> >> how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
> >> doesn't really work since the server object isn't being mutated. I mean,
> >> the state of the server will *eventually* be mutated when the reboot
> >> action starts kicking in (the above is an async operation returning a
> >> 202 Accepted). But the act of hitting POST /servers/{uuid}/action
> >> doesn't actually mutate the server's state.
> >>
> >> This is just one example of where GraphQL doesn't necessarily map well
> >> to control plane APIs that happen to be built on top of REST/HTTP [1]
> >>
> >> Bottom line for me would be what is the perceivable benefit that all of
> >> our users would receive given the (very costly) overhaul of our APIs
> >> that would likely be required.
> >>
> >> Best,
> >> -jay
> >>
> >> [0] http://graphql.org/learn/queries/#mutations
> >> [1] One could argue (and I have in the past) that POST
> >> /servers/{uuid}/action isn't a RESTful interface at all...
> >>
> >>
> 

[openstack-dev] [tripleo] Upcoming changes to DLRN might affect TripleO

[Javier Pena]

Hi,

We are working on some changes to DLRN, which will improve its flexibility and 
ability to build packages using different backends [1]. While we try to make 
these changes backwards-compatible, we have detected an issue with existing CI 
jobs for TripleO.

Both tripleo-ci and oooq-extras change the build_rpm.sh script from DLRN, and 
that change will no longer be required (and actually the sed command that tries 
that will fail). I have proposed patches to both tripleo-ci and oooq-extras 
[2], which allow compatibility with the current and future DLRN.

Would it be possible to get some reviews on these patches? We need that 
functionality in DLRN and want to avoid breaking the TripleO gate.

Thanks,
Javier

[1] - 
https://softwarefactory-project.io/r/#/q/status:open+project:DLRN+branch:master+topic:modular-build-drivers
[2] - https://review.openstack.org/#/q/topic:dlrn-modular-build-drivers

__
OpenStack Development Mailing 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] Proposing Tobias Urdin to join Puppet OpenStack core

[Mohammed Naser]

Hi everyone,

Due to active cores having no objections, I have officially added
Tobias to our cores.

Welcome, Tobias! :)

Thanks,
Mohammed

On Fri, Apr 27, 2018 at 5:13 PM, Alex Schultz  wrote:
> +1
>
> On Fri, Apr 27, 2018 at 11:41 AM, Emilien Macchi  wrote:
>> +1, thanks Tobias for your contributions!
>>
>> On Fri, Apr 27, 2018 at 8:21 AM, Iury Gregory  wrote:
>>>
>>> +1
>>>
>>> On Fri, Apr 27, 2018, 12:15 Mohammed Naser  wrote:

 Hi everyone,

 I'm proposing that we add Tobias Urdin to the core Puppet OpenStack
 team as they've been putting great reviews over the past few months
 and they have directly contributed in resolving all the Ubuntu
 deployment issues and helped us bring Ubuntu support back and make the
 jobs voting again.

 Thank you,
 Mohammed


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

__
OpenStack Development Mailing 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][nova] live-migration broken after update of OVS/DPDK

[Sahid Orentino Ferdjaoui]

We have an issue with live-migration if operators update OVS from a
version that does not support dpdkvhostuserclient to a version that is
supporting it.

Basically from OVS2.6 to OVS2.7 or upper.

The problem is that, for libvirt driver all the instances created that
use vhu interfaces in server mode (OVS2.6) wont be able to
live-migrate anymore. That because Neutron to select which vhu mode to
use is looking at OVS capabilities [0].

Meaning that During the live-migration port details are going to be
updated but Nova and in particular libvirt driver does not update
guests domain XML to refer the changes.

- We can fix Neutron by making it consider to always use the same vhu
  mode if the ports already exist.

- We can enhance Nova and in particular libvirt driver to update
  guests domain XML during live-migration. The benefit is that the
  instances are going to be updated for free to use vhu in client mode
  which is totally better but it's probably not so trivial to
  implement.

- We can avoid fixing it meaning that operators will have to update
  their instances to use vhu mode client that by a way like
  snapshot/rebuild. Then live-migration will be possible.

[0] 
https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#n94

__
OpenStack Development Mailing 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] Does the openstack ci vms start each time clear up enough?

[Sean McGinnis]

On Fri, May 04, 2018 at 04:13:41PM +0800, linghucongsong wrote:
> 
> Hi all!
> 
> Recently we meet a strange problem in our ci. look this link: 
> https://review.openstack.org/#/c/532097/
> 
> we can pass the ci in the first time, but when we begin to start the gate 
> job, it will always failed in the second time.
> 
> we have rebased several times, it alway pass the ci in the first time and 
> failed in the second time.
> 
> This have not happen before  and make me to guess is it really we start the 
> ci from the new fresh vms each time?

A new VM is spun up for each test run, so I don't believe this is an issue with
stale artifacts on the host. I would guess this is more likely some sort of
race condition, and you just happen to be hitting it 50% of the time.

You can probably keep rechecking the patch until you get lucky. But it would be
dangerous to do that without knowing the source of the failure. You will just
most likely keep running into this in future patches then.

The failure looks very odd, with the test expecting a status to be returned but
instead getting a ServerDetail object:

http://logs.openstack.org/97/532097/16/gate/legacy-tricircle-dsvm-multiregion/ad547d5/job-output.txt.gz#_2018-05-04_03_57_05_399493


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

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

[Thomas Herve]

On Thu, May 3, 2018 at 9:49 PM, Eric K  wrote:
> Question to the projects which send or consume webhook notifications
> (telemetry, monasca, senlin, vitrage, etc.), what are your
> supported/preferred authentication mechanisms? Bearer token (e.g.
> Keystone)? Signing?
>
> Any pointers to past discussions on the topic? My interest here is having
> Congress consume and send webhook notifications.
>
> I know some people are working on adding the keystone auth option to
> Monasca's webhook framework. If there is a project that already does it,
> it could be a very helpful reference.

Hi,

I'll add a few that you didn't mention which consume such webhooks.

 * Heat has been using EC2 signatures basically since forever. It
creates EC2 credentials for a Keystone user, and signs URL that way.
 * Zaqar has signed URLs
(https://developer.openstack.org/api-ref/message/#pre-signed-queue)
which allows sharing queues without authentication.
 * Swift temp URLs
(https://docs.openstack.org/swift/latest/middleware.html#tempurl) is a
good mechanism to share information as well.

I'd say application credentials would make those operations a bit
nicer, but they are not completely there yet. Everybody not
reinventing its own wheel would be nice too :).

-- 
Thomas

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

Re: [openstack-dev] [horizon][nova][cinder] Horizon support for multiattach volumes

[Ivan Kolodyazhny]

Matt, thank you for all your efforts!

I'm going to work on Horizon blueprint soon to get it implemented in Rocky

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Apr 25, 2018 at 4:57 PM, Matt Riedemann  wrote:

> I wanted to advertise the need for some help in adding multiattach volume
> support to Horizon. There is a blueprint tracking the changes [1]. I
> started the ball rolling with [2] but there is more work to do, listed in
> the work items section of the blueprint.
>
> [2] was I think my first real code contribution to Horizon and it wasn't
> terrible (thanks for Akihiro's patience), so I'm sure others could easily
> jump in here and slice this up if we have people looking for something to
> hack on.
>
> [1] https://blueprints.launchpad.net/horizon/+spec/multi-attach-volume
> [2] https://review.openstack.org/#/c/547856/
>
> --
>
> 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] [keystone][monasca][congress][senlin][telemetry][vitrage] authenticated webhook notifications

[Bedyk, Witold]

Hi Eric,

In Monasca use cases sending the token in the request header should be enough, 
I guess. I'm adding the references to the HipChat [1] and Slack APIs [2] as 
well as two old blueprints [3, 4].

[1] https://developer.atlassian.com/server/hipchat/about-the-hipchat-rest-api/
[2] https://api.slack.com/web#authentication
[3] https://blueprints.launchpad.net/monasca/+spec/webhook-api-support
[4] https://blueprints.launchpad.net/monasca/+spec/secure-notification-params

Greetings
Witek

P.S. Adding Vitrage to the tags list.


> -Original Message-
> From: Eric K 
> Sent: Donnerstag, 3. Mai 2018 21:50
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [keystone][monasca][congress][senlin][telemetry]
> authenticated webhook notifications
> 
> Question to the projects which send or consume webhook notifications
> (telemetry, monasca, senlin, vitrage, etc.), what are your
> supported/preferred authentication mechanisms? Bearer token (e.g.
> Keystone)? Signing?
> 
> Any pointers to past discussions on the topic? My interest here is having
> Congress consume and send webhook notifications.
> 
> I know some people are working on adding the keystone auth option to
> Monasca's webhook framework. If there is a project that already does it, it
> could be a very helpful reference.
__
OpenStack Development Mailing 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] Does the openstack ci vms start each time clear up enough?

[linghucongsong]

Hi all!

Recently we meet a strange problem in our ci. look this link: 
https://review.openstack.org/#/c/532097/

we can pass the ci in the first time, but when we begin to start the gate job, 
it will always failed in the second time.

we have rebased several times, it alway pass the ci in the first time and 
failed in the second time.

This have not happen before  and make me to guess is it really we start the ci 
from the new fresh vms each time?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev