[openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

[Eyal Leshem]

Hi all ,

In order to use kubernetes client that support network-policies ,
we plan to upgrade the python kubernetes package  from  1.0.0 to 4.0.0.

any objections ?

thanks,
leyal

clarification:
The purposed changed is for kubernetes-python-client - that called just
 "kubernetes" in  pypi
__
OpenStack Development Mailing 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] [ceilometer] about add transformer into libvirt

[Jaze Lee]

Hello,

What about move transformer to compute pollster? If we do this, we
do not need
transformer any more



-- 
谦谦君子

__
OpenStack Development Mailing 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] Regarding Networking-SFC

[Y Rajitha]

Hi All,

We are currently implementing SFC for the VNF's launched on plain 
Openstack(Ocata) and facing few issues mentioned below.

Problem Statement : "Bidirectional SFC in multi node setup is not working ,ping 
is working but wget and iperf traffic not working"

Devstack Setup:

1.Installed openstack-ocata on 2 nodes (1 controller+compute and 1 compute node)

2.Launched 4 vms on compute node while 1 VM is launched on controller node. Vms 
are Centos.And have enabled net.ipv4.ip_forward in all the VM's

3. vm1->vm2->vm3->vm4->vm5 (SFC port pairs and groups are created for vm2,vm3 
and vm4) 
SFC Flow classifier points the logical source port to vm1 and the source ip 
prefix is the ip of vm1 and destination ip prefix is of vm5.
Reverse SFC Flow Classifier is also written.

4.Disabled port security group
5.Bidirectional SFC is working when all vms are launched on single compute node 
(even wget is working)

Queries:

1.Are there any other parameters that we need to set for multinode setup 

2.Should mtu values be set? Because wget is working for files https://pastebin.com/vm7BwkjE

https://pastebin.com/Jqufw3Wv

printenv | grep OS_*  for compute : https://pastebin.com/UGLhXsrj

Kindly advice and provide your inputs for the same.

Best Regards
Yerrumsetty Rajitha
ITA
Tata Consultancy Services
Ph:- 04066673746
Mailto: y.raji...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


__
OpenStack Development Mailing 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] [placement] resource providers update 44

[Matt Riedemann]

On 12/8/2017 7:57 AM, Chris Dent wrote:


I'm feeling pressure from the (excellent and welcomed) Weekly Owl

 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125214.html 



and Keystone update:

 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125112.html 



to enhance the rp and placement update brand, to maximize market
penetration, global influence, and reader participation, but instead
I'll stick to habit.

# Most Important

The three main themes (nested providers, alternate hosts, migration)
continue to be the main priorities.

A thing to be aware of, now that some of nested has merged on the
placement side, is that the nova side is underway and the work
surrounding the ProviderTree concept is fairly penetrating. It will
supersede the "get_inventory" method in the virt drivers, and thus far
not all the virt drivers have get_inventory methods. See

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

way down inside the nested-resource-providers topic for a bit of
context.

# What's Changed

Microversion 1.14 has merged (causing a might microversion conflict
pileup behind it) meaning that some aspects of nested providers are in
the placement API. Hierarchies of providers can be created, and trees
of results can be returned:

 
https://developer.openstack.org/api-ref/placement/#create-resource-provider
 
https://developer.openstack.org/api-ref/placement/#list-resource-providers


I didn't help with the reviews when this merged, but did ask some 
questions about the "in_tree" filter functionality added in a review today:


https://review.openstack.org/#/c/520663/9/nova/tests/unit/scheduler/client/test_report.py@1400

It would be helpful for me, and I'll assume others, if we had something 
more in the API reference docs with example provider trees and what the 
results would be when listing providers with specific nodes in that 
tree, i.e. define what a "provider tree" is - where does it stop? I 
don't know if that's good to bake into the API reference parameter 
description itself or create it's own doc page to link to for an 
explanation and example usage.




A fix was merged that defaults the accept header, if not set, to
application/json. This means that whereas in the past an error
response could inadvertently be HTML, it will now be JSON, structured
(partially, critically the 'code' field is not there as we've stumbled
trying to create standards) according to the errors guideline:

     https://review.openstack.org/#/c/518223/
     http://specs.openstack.org/openstack/api-wg/guidelines/errors.html

Eric made the compute node be more alert when it encounters an error
condition when getting or creating resource providers:

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

This led to the discovery that in grenade placement was not being
properly stopped and restarted over the upgrade transition:

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

I mention all this because it's quite likely that latent bugs with
talking to placement (from nova) in grenade will be exposed. Be on
the lookout. If you find something weird, report a bug, and if
possible, fix it.

# Help Wanted

(unchanged from last week, no new data, yet)

A takeaway from summit is that we need, where possible, benchmarking
info from people who are making the transition from old methods of
scheduling to the newer allocation_candidate driven modes.  While
detailed numbers will be most useful, even anecdotal summaries of
"woot it's way better" or "hmmm, no it seems worse" are useful.

# Docs

Quite a few docs improvements have merged. Others need more review:

* https://review.openstack.org/#/c/512215/
    Add create inventories doc for placement

* https://review.openstack.org/#/c/523007/
    Add x-openstack-request-id in API ref

* https://review.openstack.org/#/c/521541/
    Add 'Location' parameters in API ref

* https://review.openstack.org/#/c/511342/
    add API reference for create inventory

# Nested Providers

The nested-resource-providers stack has grown a long tail of changes
for managing nested providers rooted on a compute node:

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

As mentioned above this has impact for virt drivers.

The current spec for nested providers

 
http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html 



doesn't really cover the ProviderTree and inventory management plans
that are currently being implemented in that long tail. That makes it
a bit harder to review than it might otherwise. We may not need a spec
but a sort of explanatory overview may help provide some context on
what needs to happen. A lot of the work that is in progress feels like
it is working to a design where the use cases are not entirely obvious.
There's a danger this can lead to an implementation that is somewhat
divorced for reality. There's no evidence as yet that this is
happening, but there's also none that 

Re: [openstack-dev] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

[Sing Chia]

Hi Martin,

I met exactly the same issue with yours, could you please show some details
about security groups deleting, resyncing and recreating? cause I cleared
DEFAULT security group and add 'ovn-sync-mode=repair' in config file then
restarted the neutron-server, but didn't work out.

best regards
   sing chia
__
OpenStack Development Mailing 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] [murano] Deployment fails with Murano Agent

[Rong Zhu]

Hi, Jerry

Please check the rabbitmq section config in your murano.conf


[rabbitmq]
password = rabbit_password
login = rabbit_user
host = rabbit_host


Thanks,
Rong Zhu


On Wed, Dec 13, 2017 at 5:26 AM, Sun, Yicheng (Jerry)
 wrote:
> Hi All,
>
>
>
> I am struggling with deploying the apache package with murano agent. I am
> using the pike version of murano. I was able to see the following trace many
> times in the murano agent logs:
>
>
>
> 2017-12-12 20:41:18.836 2382 ERROR muranoagent.app
>
> 2017-12-12 20:42:17.397 2382 WARNING muranoagent.app [-] Communication
> error: timeout: timed out
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app Traceback (most recent
> call last):
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/app.py", line 133, in
> _wait_plan
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app with
> self._create_rmq_client() as mq:
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/mqclient.py",
> line 72, in __enter__
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/mqclient.py",
> line 83, in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> self._connection.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 261, in
> connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return
> self.connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 802, in
> connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self._connection =
> self._establish_connection()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 757, in
> _establish_connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn =
> self.transport.establish_connection()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/transport/pyamqp.py", line
> 130, in establish_connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/connection.py", line 282, in
> connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> self.transport.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 109, in
> connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> self._connect(self.host, self.port, self.connect_timeout)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 150, in
> _connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.sock.connect(sa)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 252,
> in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> timeout_exc=socket.timeout("timed out"))
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 203,
> in _trampoline
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> mark_as_closed=self._mark_as_closed)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/__init__.py", line
> 162, in trampoline
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return hub.switch()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 294, in
> switch
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return
> self.greenlet.switch()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app timeout: timed out
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
>
>
>
> I have tried with both a self-built ubuntu image with pike murano agent as
> well as a newton debian image with murano agent from the community
> application catalog that no longer exist. The VM was created successfully. I
> have also tried deploying a package without using the murano agent
> functionality, which completed fine. Can anyone help me with this issue?
>
>
>
> Thanks in advance,
>
> Jerry
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

[Tony Breeds]

On Fri, Dec 08, 2017 at 04:34:09PM -0700, Alex Schultz wrote:
> Hey folks,
> 
> So I went through the list of blueprints and moved some that were
> either not updated or appeared to have a bunch of patches not in a
> mergable state.
> 
> Please take some time to review the list of blueprints currently
> associated with Rocky[0] to see if your efforts have been moved. If
> you believe you're close to implementing the feature in the next week
> or two, let me know and we can move it back into Queens. If you think
> it will take an extended period of time (more than 2 weeks) to land
> but we need it in Queens, please submit an FFE.

I'd like to get the ball rolling on applying for an FFE for:
https://blueprints.launchpad.net/tripleo/+spec/multiarch-support

So how do I do that thing?  For requirements it's just a thread on the
mailing list is there soemthing more formal for tripleo?

Yours Tony.

__
OpenStack Development Mailing 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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Doug Hellmann]

Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 21:36:51 +:
> 
> On 12/12/17, 3:15 PM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
> >+:
> >> 
> >> On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:
> >> 
> >> >
> >> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke 
> >>wrote:
> >> >> 
> >> >> From my understanding it would be a cleanup operation - which to be
> >> >>honest, would be very much welcomed. I recently did a little work with
> >> >>Castellan to integrate it with Murano and found the auth code to be
> >>very
> >> >>messy, and flat out broken in some cases. If it's possible to let the
> >> >>barbican client take care of this that sounds good to me.
> >> >> 
> >> >> > Which mode is used the most in the services that consume castellan
> >> >> > today?
> >> >> 
> >> >> Afaik Barbican is the only backend that currently exists in Castellan
> >> >>[0]. Looking again it seems some support has been added for vault
> >>which
> >> >>is great, but I reckon Barbican would still be the primary use.
> >> >> 
> >> >> I haven't been hugely active in Castellan but if the team would like
> >> >>some more input on this or reviews please do ping me, I'd be glad to
> >> >>help.
> >> >
> >> >What I mean is, in the services consuming Castellan, how do they expect
> >> >it to authenticate to Barbican? As the current user or as a hard-coded
> >> >fixed user controlled by the deployer? I would think most services
> >>would
> >> >need to connect as the ³current² user talking to them so they can
> >>access
> >> >that user¹s secrets from Barbican. Removing the keystoneauth stuff from
> >> >the driver would therefore break all of those applications.
> >> >
> >> >Doug
> >> 
> >> We're a mix right now.  Nova and Cinder pass through the a user's token
> >>to
> >> retrieve the user's key for encrypted volumes.  Octavia uses its service
> >> account to retrieve certificates for load balancing TLS connections.
> >> Users must grant Octavia read permissions in advance.
> >
> >OK, so it sounds like we do need to continue to support both
> >approaches to authentication.
> >
> >> Keystone is currently the only authentication option for Barbican.  I
> >> believe the proposal to decouple keystoneauth is advance work for adding
> >> new auth methods and backends as future work.  Vault and Custodia are
> >>two
> >> such backends in progress.  They don't support keystoneauth and likely
> >> won't, so we'll need alternatives.
> >
> >Each driver manages its own authentication, right? Why do we need to
> >remove the keystoneauth stuff in the barbican driver in order to enable
> >other drivers?
> 
> I would use the word "decouple", with the intent to give the option of
> using Castellan without having a dependency on keystoneauth.  But, I don't
> want to speak for original posters who used the word "remove" in case they
> have other ideas.
> 
> Until recently Barbican was the only secret store and Keystone was the
> only authentication service, so we didn't have to sort through the
> modularity.

I'm sorry that I missed the conversation about this in Denver.  It
seems like everyone else understands what's being proposed in a way
very different than I do, so I apologize for continuing to just ask
the same questions.  I'll try rephrasing, but it would be *very*
helpful if someone would summarize that discussion and lay out the
plan in more detail than "we want to remove the use of keystoneauth."
If we can't do it by email, then maybe via an Oslo spec.


The barbican driver has 2 modes for using keystoneauth. One is to
use the use the execution context to authenticate using the same
token that the current user passed in to the service calling into
castellan. The other is to use credentials from the configuration
file.

Those options seem to be pretty well abstracted in the API, so that
the application using castellan can just pass the right sort of
context and get the right behavior from the driver, without having
to know what the driver is. We currently only have a barbican driver,
and that driver uses keystoneauth directly because that is the only
way to control which authentication mode is used. Other drivers
would presumably use some means other than keystoneauth to authenticate
to the backends they talk to, with the difference in behavior (acting
like the current user or acting like a service user) triggered by
the context passed in.

If we don't use keystoneauth inside the castellan driver before
creating the barbican client, how will we support both modes in the
castellan API without exposing to the application which secret store
driver is being used? We can't, for example, require that an
application configured to use the barbican driver pass more (or
different) information to castellan than it would pass if castellan
was configured to use custodia, because that would break the
abstraction.

Are there 

Re: [openstack-dev] [keystone] multiple federated keystones with single Identity Provider

[Adrian Turjak]

On 08/12/17 11:47, Lance Bragstad wrote:
>
> On 12/07/2017 12:27 PM, Colleen Murphy wrote:
>> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
>>  wrote:
>>> Hi all,
>>>
>>> We have a following use case - several independent keystones (say KeyA and
>>> KeyB), using fernet tokens and synchronized fernet keys, and single external
>>> IdP for federated auth.
>>>
>>> Is it generally possible to configure both KeyA and KeyB such that scoped
>>> token issued by KeyA for a federated user is valid on KeyB?
>>>
>>> Currently we have the next problem - although domains/projects where
>>> keystone's mapping engine assigns federated users are equal by name between
>>> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB  are
>>> different, which seems to invalidate the scoped token issued by KeyA when
>>> trying to use it for KeyB. And it is not possible to create projects/domains
>>> with specific UUIDs via keystone API (which would probably solve this
>>> problem for non-autoprovisioned projects).
>>>
>>> Is such usage scenario supported? Or one should always use the unscoped
>>> token first to list projects/domains available on a specific keystone
>>> instance and then get a scoped token for usage o this instance only?
>> No, it is not currently possible to use the same token on projects in
>> different keystones, for the reasons you gave. You might be interested
>> in following https://review.openstack.org/#/c/323499/ if you're not
>> already aware of it, which has the goal of solving that problem.
>>
>> It's also been brought up before:
>>
>> https://review.openstack.org/#/c/403866/
>> http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html
>>
>> And we talked about it a lot at the last Forum (sorry my brief summary
>> does not really do the discussion justice):
>>
>> http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback
> I had a snippet about it in my recap under the "Other Feedback" section
> [0]. The TL;DR in my opinion is that we originally thought we could
> solve the problem with federation 100%, and if we couldn't we wanted to
> try and improve the parts of federation that would make that possible.
>
> The interesting bit we came up with during the feedback session in
> Sydney is what happens if a user no longer has a role on a project. For
> example;
>
> - A user has a role on Project A and in the us-east region and the
> us-west region, each region has it's own keystone deployment, but let's
> assume the ID for Project A are the same in each region
> - A user authenticates for a token scoped to Project A and starts
> creating instances in both regions
> - The user has their role from Project A removed in us-east, but not in
> us-west
> - The user isn't able to do anything within us-east since they no longer
> have a role assignment on Project A in that region, but they can still
> take the invalid token from the us-east region and effectively use it in
> the us-west region
>
> Without replicating revocation events, or syncing the assignment table,
> this will lead to security concerns.

Also worth noting is that this assumes both keystones have the same
fernet keys, so as to be able to generate tokens that the other can read.

From memory, the whole point of this exercise from the regulations side
was to make it so that data isn't 'replicated' and if one keystone was
compromised, the other wouldn't be, but if the fernet keys are the same,
then its still very bad if the host is compromised, since with the
fernet keys from the compromised keystone, you can now make bogus tokens
that the other keystone would trust. So that still doesn't solve the
problem and still probably falls out of regulations. In truth most of
this sounds like a loop hole around the regulations anyway rather than
honoring what they might intend (would be interesting to find out more
about that).

Unless I'm misremembering, this is all so that users in both 'regions'
can pretend it's all part of the same cloud, when in truth it isn't
really, and the regulations require that they are separate. Making that
fact clear, and that users have to swap between clouds, or generate a
token for each isn't that bad, and is overall much much safer. The user
can have the same project name in both, and getting a token from either
is as simple as just changing the auth url. Writing code to account for
this difference is probably easier than trying to solve this problem in
keystone and introducing weird potential security problems. :(
>> Lance mentioned today that we'd likely try to discuss it at our next
>> weekly meeting: http://eavesdrop.openstack.org/#Keystone_Team_Meeting
> Yep, I have it on the agenda for the next meeting [1].
>
> [0] https://www.lbragstad.com/blog/openstack-summit-sydney-recap
> [1] https://etherpad.openstack.org/p/keystone-weekly-meeting
>> Colleen
>>
>> __
>> OpenStack 

Re: [openstack-dev] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Dave McCowan (dmccowan)]

On 12/12/17, 3:15 PM, "Doug Hellmann"  wrote:

>Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
>+:
>> 
>> On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:
>> 
>> >
>> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke 
>>wrote:
>> >> 
>> >> From my understanding it would be a cleanup operation - which to be
>> >>honest, would be very much welcomed. I recently did a little work with
>> >>Castellan to integrate it with Murano and found the auth code to be
>>very
>> >>messy, and flat out broken in some cases. If it's possible to let the
>> >>barbican client take care of this that sounds good to me.
>> >> 
>> >> > Which mode is used the most in the services that consume castellan
>> >> > today?
>> >> 
>> >> Afaik Barbican is the only backend that currently exists in Castellan
>> >>[0]. Looking again it seems some support has been added for vault
>>which
>> >>is great, but I reckon Barbican would still be the primary use.
>> >> 
>> >> I haven't been hugely active in Castellan but if the team would like
>> >>some more input on this or reviews please do ping me, I'd be glad to
>> >>help.
>> >
>> >What I mean is, in the services consuming Castellan, how do they expect
>> >it to authenticate to Barbican? As the current user or as a hard-coded
>> >fixed user controlled by the deployer? I would think most services
>>would
>> >need to connect as the ³current² user talking to them so they can
>>access
>> >that user¹s secrets from Barbican. Removing the keystoneauth stuff from
>> >the driver would therefore break all of those applications.
>> >
>> >Doug
>> 
>> We're a mix right now.  Nova and Cinder pass through the a user's token
>>to
>> retrieve the user's key for encrypted volumes.  Octavia uses its service
>> account to retrieve certificates for load balancing TLS connections.
>> Users must grant Octavia read permissions in advance.
>
>OK, so it sounds like we do need to continue to support both
>approaches to authentication.
>
>> Keystone is currently the only authentication option for Barbican.  I
>> believe the proposal to decouple keystoneauth is advance work for adding
>> new auth methods and backends as future work.  Vault and Custodia are
>>two
>> such backends in progress.  They don't support keystoneauth and likely
>> won't, so we'll need alternatives.
>
>Each driver manages its own authentication, right? Why do we need to
>remove the keystoneauth stuff in the barbican driver in order to enable
>other drivers?

I would use the word "decouple", with the intent to give the option of
using Castellan without having a dependency on keystoneauth.  But, I don't
want to speak for original posters who used the word "remove" in case they
have other ideas.

Until recently Barbican was the only secret store and Keystone was the
only authentication service, so we didn't have to sort through the
modularity.


>
>> 
>> Reviews and contributions to Castellan and Barbican have been light over
>> the last cycle, while deployment interest and feature requests have been
>> high.  Any help will be appreciated!
>> 
>> --Dave
>> 

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

[openstack-dev] [murano] Deployment fails with Murano Agent

[Sun, Yicheng (Jerry)]

Hi All,

I am struggling with deploying the apache package with murano agent. I am using 
the pike version of murano. I was able to see the following trace many times in 
the murano agent logs:

2017-12-12 20:41:18.836 2382 ERROR muranoagent.app
2017-12-12 20:42:17.397 2382 WARNING muranoagent.app [-] Communication error: 
timeout: timed out
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app Traceback (most recent call 
last):
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/muranoagent/app.py", line 133, in 
_wait_plan
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app with 
self._create_rmq_client() as mq:
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/mqclient.py",
 line 72, in __enter__
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.connect()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/mqclient.py",
 line 83, in connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app 
self._connection.connect()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 261, in 
connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return self.connection
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 802, in 
connection
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self._connection = 
self._establish_connection()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 757, in 
_establish_connection
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn = 
self.transport.establish_connection()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/kombu/transport/pyamqp.py", line 130, 
in establish_connection
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn.connect()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/amqp/connection.py", line 282, in 
connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.transport.connect()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 109, in connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self._connect(self.host, 
self.port, self.connect_timeout)
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 150, in 
_connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.sock.connect(sa)
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 252, in 
connect
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app 
timeout_exc=socket.timeout("timed out"))
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 203, in 
_trampoline
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app 
mark_as_closed=self._mark_as_closed)
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/hubs/__init__.py", line 162, 
in trampoline
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return hub.switch()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 294, in 
switch
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return 
self.greenlet.switch()
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app timeout: timed out
2017-12-12 20:42:17.397 2382 ERROR muranoagent.app

I have tried with both a self-built ubuntu image with pike murano agent as well 
as a newton debian image with murano agent from the community application 
catalog that no longer exist. The VM was created successfully. I have also 
tried deploying a package without using the murano agent functionality, which 
completed fine. Can anyone help me with this issue?

Thanks in advance,
Jerry
__
OpenStack Development Mailing 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] Gerrit custom menu entries - help needed

[Sławek Kapłoński]

Thx. It looks very nice. I will have to try it :)

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Poulos, Brianna L.  w 
> dniu 12.12.2017, o godz. 16:46:
> 
> Hello,
> 
> I have found the Gerrit Dashboard Creator (see 
> https://github.com/openstack/gerrit-dash-creator ) to be very helpful when 
> putting together queries.
> 
> Thanks,
> ~Brianna
> 
> On 12/8/17, 16:25, "Sławek Kapłoński"  wrote:
> 
>Hello,
> 
>I’m trying to personalize my Gerrit menus in settings panel on 
> review.openstack.org.
>So I prepared query like:
> 
>(NOT owner:self) AND status:open AND label:Code-Review-0,self AND 
> label:Workflow=0 AND (project:openstack/neutron OR 
> project:openstack/neutron-lib) AND branch:master
> 
>And I wanted to create menu entry with this query. When I’m pasting query:
> 
>
> #/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master
> 
>On gerrit settings page it replaces me chars like , or = to something else 
> and query looks like:
> 
>
> #/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master
> 
>And it don’t work properly then.
>So I have a question to more experienced Gerrit users. What I’m doing 
> wrong here and how I should create menu entry with query which I really want?
> 
>—
>Best regards
>Slawek Kaplonski
>sla...@kaplonski.pl
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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: Message signed with OpenPGP
__
OpenStack Development Mailing 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] Race in FixedIP.associate_pool

[Arun SAG]

Hello,

We are running nova-network in ocata. We use mysql in a master-slave
configuration, The master is read/write, and all reads go to the slave
(slave_connection is set). When we tried to boot multiple VMs in
parallel (lets say 15), we see a race in allocate_for_instance's
FixedIP.associate_pool. We see FixedIP.associate_pool associates an
IP, but later in the code we try to read the allocated FixedIP using
objects.FixedIPList.get_by_instance_uuid and it throws
FixedIPNotFoundException. We also checked the slave replication status
and Seconds_Behind_Master: 0

mysql> show slave status \G
*** 1. row ***
   Slave_IO_State: Waiting for master to send event
  Master_Host: master.hostname
  Master_User: repl
  Master_Port: 3306
Connect_Retry: 60
  Master_Log_File: mysqld-bin.03
  Read_Master_Log_Pos: 142605121
   Relay_Log_File: mysqld-relay-bin.06
Relay_Log_Pos: 142602813
Relay_Master_Log_File: mysqld-bin.03
 Slave_IO_Running: Yes
Slave_SQL_Running: Yes
  Replicate_Do_DB:
  Replicate_Ignore_DB: mysql,mysql
   Replicate_Do_Table:
   Replicate_Ignore_Table:
  Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
   Last_Errno: 0
   Last_Error:
 Skip_Counter: 0
  Exec_Master_Log_Pos: 142605121
  Relay_Log_Space: 142603151
  Until_Condition: None
   Until_Log_File:
Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
  Master_SSL_Cert:
Master_SSL_Cipher:
   Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
   Last_SQL_Errno: 0
   Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
 Master_Server_Id: 172687130
  Master_UUID: 8112eeef-de1e-11e7-8098-ac162da46cbc
 Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
  SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Slave has read all relay log; waiting
for the slave I/O thread to update it
   Master_Retry_Count: 86400
  Master_Bind:
  Last_IO_Error_Timestamp:
 Last_SQL_Error_Timestamp:
   Master_SSL_Crl:
   Master_SSL_Crlpath:
   Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0

This kind of how the logs look like
2017-12-08 22:33:37,124 DEBUG
[yahoo.contrib.ocata_openstack_yahoo_plugins.nova.network.manager]
/opt/openstack/venv/nova/lib/python2.7/site-packages/yahoo/contrib/ocata_openstack_yahoo_plugins/nova/network/manager.py:get_instance_nw_info:894
Fixed IP NOT found for instance
2017-12-08 22:33:37,125 DEBUG
[yahoo.contrib.ocata_openstack_yahoo_plugins.nova.network.manager]
/opt/openstack/venv/nova/lib/python2.7/site-packages/yahoo/contrib/ocata_openstack_yahoo_plugins/nova/network/manager.py:get_instance_nw_info:965
Built network info: |[]|
2017-12-08 22:33:37,126 INFO [nova.network.manager]
/opt/openstack/venv/nova/lib/python2.7/site-packages/nova/network/manager.py:allocate_for_instance:428
Allocated network: '[]' for instance
2017-12-08 22:33:37,126 ERROR [oslo_messaging.rpc.server]
/opt/openstack/venv/nova/lib/python2.7/site-packages/oslo_messaging/rpc/server.py:_process_incoming:164
Exception during message handling
Traceback (most recent call last):
  File 
"/opt/openstack/venv/nova/lib/python2.7/site-packages/oslo_messaging/rpc/server.py",
line 155, in _process_incoming
res = self.dispatcher.dispatch(message)
  File 
"/opt/openstack/venv/nova/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
line 222, in dispatch
return self._do_dispatch(endpoint, method, ctxt, args)
  File 
"/opt/openstack/venv/nova/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
line 192, in _do_dispatch
result = func(ctxt, **new_args)
  File 
"/opt/openstack/venv/nova/lib/python2.7/site-packages/yahoo/contrib/ocata_openstack_yahoo_plugins/nova/network/manager.py",
line 347, in allocate_for_instance
vif = nw_info[0]
IndexError: list index out of range


This problem goes way when we get rid of the slave_connection setting
and just use single master. Has any one else seen this? Any
recommendation to fix this issue?

This issue is kind of  similar to https://bugs.launchpad.net/nova/+bug/1249065

-- 
Arun S A G
http://zer0c00l.in/

__
OpenStack Development Mailing 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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Doug Hellmann]

Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49 +:
> 
> On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:
> 
> >
> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke  wrote:
> >> 
> >> From my understanding it would be a cleanup operation - which to be
> >>honest, would be very much welcomed. I recently did a little work with
> >>Castellan to integrate it with Murano and found the auth code to be very
> >>messy, and flat out broken in some cases. If it's possible to let the
> >>barbican client take care of this that sounds good to me.
> >> 
> >> > Which mode is used the most in the services that consume castellan
> >> > today?
> >> 
> >> Afaik Barbican is the only backend that currently exists in Castellan
> >>[0]. Looking again it seems some support has been added for vault which
> >>is great, but I reckon Barbican would still be the primary use.
> >> 
> >> I haven't been hugely active in Castellan but if the team would like
> >>some more input on this or reviews please do ping me, I'd be glad to
> >>help.
> >
> >What I mean is, in the services consuming Castellan, how do they expect
> >it to authenticate to Barbican? As the current user or as a hard-coded
> >fixed user controlled by the deployer? I would think most services would
> >need to connect as the ³current² user talking to them so they can access
> >that user¹s secrets from Barbican. Removing the keystoneauth stuff from
> >the driver would therefore break all of those applications.
> >
> >Doug
> 
> We're a mix right now.  Nova and Cinder pass through the a user's token to
> retrieve the user's key for encrypted volumes.  Octavia uses its service
> account to retrieve certificates for load balancing TLS connections.
> Users must grant Octavia read permissions in advance.

OK, so it sounds like we do need to continue to support both
approaches to authentication.

> Keystone is currently the only authentication option for Barbican.  I
> believe the proposal to decouple keystoneauth is advance work for adding
> new auth methods and backends as future work.  Vault and Custodia are two
> such backends in progress.  They don't support keystoneauth and likely
> won't, so we'll need alternatives.

Each driver manages its own authentication, right? Why do we need to
remove the keystoneauth stuff in the barbican driver in order to enable
other drivers?

> 
> Reviews and contributions to Castellan and Barbican have been light over
> the last cycle, while deployment interest and feature requests have been
> high.  Any help will be appreciated!
> 
> --Dave
> 

__
OpenStack Development Mailing 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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Dave McCowan (dmccowan)]

On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:

>
>> On Dec 12, 2017, at 9:42 AM, Paul Bourke  wrote:
>> 
>> From my understanding it would be a cleanup operation - which to be
>>honest, would be very much welcomed. I recently did a little work with
>>Castellan to integrate it with Murano and found the auth code to be very
>>messy, and flat out broken in some cases. If it's possible to let the
>>barbican client take care of this that sounds good to me.
>> 
>> > Which mode is used the most in the services that consume castellan
>> > today?
>> 
>> Afaik Barbican is the only backend that currently exists in Castellan
>>[0]. Looking again it seems some support has been added for vault which
>>is great, but I reckon Barbican would still be the primary use.
>> 
>> I haven't been hugely active in Castellan but if the team would like
>>some more input on this or reviews please do ping me, I'd be glad to
>>help.
>
>What I mean is, in the services consuming Castellan, how do they expect
>it to authenticate to Barbican? As the current user or as a hard-coded
>fixed user controlled by the deployer? I would think most services would
>need to connect as the ³current² user talking to them so they can access
>that user¹s secrets from Barbican. Removing the keystoneauth stuff from
>the driver would therefore break all of those applications.
>
>Doug

We're a mix right now.  Nova and Cinder pass through the a user's token to
retrieve the user's key for encrypted volumes.  Octavia uses its service
account to retrieve certificates for load balancing TLS connections.
Users must grant Octavia read permissions in advance.

Keystone is currently the only authentication option for Barbican.  I
believe the proposal to decouple keystoneauth is advance work for adding
new auth methods and backends as future work.  Vault and Custodia are two
such backends in progress.  They don't support keystoneauth and likely
won't, so we'll need alternatives.

Reviews and contributions to Castellan and Barbican have been light over
the last cycle, while deployment interest and feature requests have been
high.  Any help will be appreciated!

--Dave


__
OpenStack Development Mailing 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] [First Contact] [OUI] Call for Project Liaisons

[Kendall Nelson]

Thanks gmann!

I added you to the project liaison section for QA.

-Kendall (diablo_rojo)

On Tue, Dec 12, 2017 at 6:03 AM Ghanshyam Mann 
wrote:

> On Tue, Dec 12, 2017 at 6:25 AM, Kendall Nelson 
> wrote:
> > Hello,
> >
> > As some of you may know there is a newly formed SIG focused on the
> initial
> > interactions of someone new to the community called the First Contact
> SIG.
> > While the team we have looking out for these first introductions is
> growing
> > they can only get us so far. After we get them up to speed with the tools
> > and community it is important that they are connected with someone who
> can
> > get them up to speed on a project. While these SIG members cover a
> variety
> > of projects, there are several projects that don’t have someone to help
> > these newcomers.
> >
> > If you are interested in being a project liaison please reply to this
> thread
> > with your name, irc nic, email, and timezone (UTC +/- x).
> >
> > Previously, Upstream Institute had started to collect a list of people
> > interested in helping get new community members up to speed in the past
> and
> > I think it would be good to unite these efforts. That list covers only 6
> > projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you
> signed
> > up before and are interested in this renewed effort please let me know!
>
> Thanks Kendall. Count me in to continue on project liaison too.
>
> >
> > Even if everyone from the initial effort participates, there are still
> many
> > projects missing from the list. How best to ensure the growth and
> success of
> > your project than to invest in the people interested in contributing to
> your
> > project?
> >
> > Thanks!
> >
> > Kendall Nelson (diablo_rojo)
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> -gmann
>
> __
> OpenStack Development Mailing 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] [First Contact] [OUI] Call for Project Liaisons

[Kendall Nelson]

Thanks Matt :)

I added you as a SIG member and as Project Liaison for Swift :)

You can see here[1].

-Kendall (diablo_rojo)

[1] https://wiki.openstack.org/wiki/First_Contact_SIG

On Tue, Dec 12, 2017 at 1:14 AM Matthew Oliver  wrote:

> Initially I meant project liaison, but who am I to say no to helping new
> people. I was new once, and had some great OpenStack mentors help me along
> the way :)
>
> Matt
>
> On Tue, Dec 12, 2017 at 9:40 AM, Amy Marrich  wrote:
>
>> Pretty sure he said both!:)
>>
>> Amy (spotz)
>>
>> On Mon, Dec 11, 2017 at 4:33 PM, Kendall Nelson 
>> wrote:
>>
>>> Thank you Matt!
>>>
>>> To clarify, you want to be Project Liaison for sSwift? Or a member of
>>> the SIG? Or both? :)
>>>
>>> -Kendall (diablo_rojo)
>>>
>>>
>>> On Mon, Dec 11, 2017 at 2:18 PM Matthew Oliver 
>>> wrote:
>>>
 I'll put my hand up for my timezone. Especially as interest in my side
 of the world grows I'd love to make sure there is someone available.

 Project: Swift
 Name: Matthew Oliver
 IRC: mattolverau
 email: m...@oliver.net.au
 timezone: UTC +11 (AEDT)

 Matt

 On Tue, Dec 12, 2017 at 8:25 AM, Kendall Nelson 
 wrote:

> Hello,
>
> As some of you may know there is a newly formed SIG focused on the
> initial interactions of someone new to the community called the First
> Contact SIG. While the team we have looking out for these first
> introductions is growing they can only get us so far. After we get them up
> to speed with the tools and community it is important that they are
> connected with someone who can get them up to speed on a project. While
> these SIG members cover a variety of projects, there are several projects
> that don’t have someone to help these newcomers.
>
> If you are interested in being a project liaison please reply to this
> thread with your name, irc nic, email, and timezone (UTC +/- x).
>
> Previously, Upstream Institute had started to collect a list of people
> interested in helping get new community members up to speed in the past 
> and
> I think it would be good to unite these efforts. That list covers only 6
> projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you signed
> up before and are interested in this renewed effort please let me know!
>
> Even if everyone from the initial effort participates, there are still
> many projects missing from the list. How best to ensure the growth and
> success of your project than to invest in the people interested in
> contributing to your project?
>
> Thanks!
>
> Kendall Nelson (diablo_rojo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

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

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

[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. The tempest plugin split
1.1. https://etherpad.openstack.org/p/ironic-tempest-plugin-migration
2. Authentication refactoring
2.1. FOR NEXT WEEK Use adapters for neutronclient: 
https://review.openstack.org/#/c/476170/
3. install guide update for hw types: https://review.openstack.org/#/c/517290/
4. BIOS interface spec: https://review.openstack.org/#/c/496481/
5. Rescue:
5.1. driver interface https://review.openstack.org/#/c/509335/
5.2. RPC https://review.openstack.org/#/c/509336/
5.3. network interface update: https://review.openstack.org/#/c/509342

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/525053 - firmware update for iLO5
irmc:
Follow up Add additional capabilities discovery for iRMC driver: 
https://review.openstack.org/#/c/524137/

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

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
  - allow concurrent updating of dnsmasq configuration 
https://review.openstack.org/#/c/504438/
  - fix dsvm (firewall) config deprecations 
https://review.openstack.org/#/c/523196/
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 04 Dec 2017 and 11 Dec 2017)
- Ironic: 220 bugs (+3) + 261 wishlist items. 1 new (-2), 158 in progress (+4), 
1 critical (+1), 32 high (+1) and 32 incomplete (-1)
- Inspector: 16 bugs + 30 wishlist items. 0 new, 15 in progress, 0 critical, 4 
high and 5 incomplete
- Nova bugs with Ironic tag: 13. 2 new, 0 critical, 1 high
- 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
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- 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

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:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/ - MERGED
- 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/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1671145
- status as of 11 Dec 2017:
- TODO:
- easier access to versions in ironicclient
- see 
https://etherpad.openstack.org/p/ironic-api-version-negotiation
- discussion of various ways to implement it happened on the 
midcycle
- dtantsur wants to have an API-SIG guideline on consuming 
versions in SDKs
- still TODO
- establish foundation for using version negotiation in nova

External project authentication rework (pas-ha, TheJulia)

Re: [openstack-dev] [infra] Zuul dashboard available

[Jeremy Stanley]

On 2017-12-12 10:13:28 -0800 (-0800), Tong Liu wrote:
> Today, there are lots of zuul jobs timed out and the dashboard is
> inaccessible with "proxy error". Can zuul team have a look at it?

The Infra team has been posting updates in most official IRC
channels using statusbot, but you can also see our status log at
https://wiki.openstack.org/wiki/Infrastructure_Status if you miss
them.

The current issue is suspected to be a memory leak in the Zuul
scheduler and impact is much farther reaching than just the
dashboard (the timeouts you're seeing are because the scheduler is
unable to respond to requests to its status API in a timely fashion
due to memory pressure). We're in the process of collecting a
detailed object graph from the interpreter before restarting it, at
which point performance should return to normal and we'll reenqueue
any changes from the check/gate pipelines at that point.
-- 
Jeremy Stanley


signature.asc
Description: 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] [cinder] Resigning as core reviewer

[Jay S Bryant]

Michal,

I am sorry that job changes have taken you away from Cinder. Thank you 
for letting us know and stepping down from Core.


Thank you for your past work on Cinder and for all you have done to help 
out.


Keep in touch and thank you for still being will to help out when needed!

Jay


On 12/12/2017 10:28 AM, mdu...@redhat.com wrote:

Hi,

Wanting to keep it fair with the community I want to resign from core
reviewer status in Cinder. During beginning of the year my team was
under continous changes and I wasn't able to participate deeply in
Cinder community. Now with upcoming challenges in my new position I
find it impossible to pay enough attention to Cinder to be confident
with reviewing patches with +2.

I'm still in the community, so I'll be happy to help in my expertise
areas - please feel free to bug me about anything on IRC or add me as
reviewer on patches.

Thanks,
Michal

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



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

Re: [openstack-dev] [cinder] Leaving the Cinder Core team

[Erlon Cruz]

Hey Scott,

Very sorry too, to see you go. My best wishes in your new position.

Erlon

2017-12-11 18:00 GMT-02:00 Jay S Bryant :

> Scott,
>
> Very sorry to have you go.  Thank you for letting us know that you won't
> be able to continue participating.  It has been a pleasure to work with you
> over the years and hope we will continue to cross paths.
>
> Best wishes and keep in touch!
>
> Sincerely,
>
> Jay
>
>
>
> On 12/11/2017 1:11 PM, Scott D'Angelo wrote:
>
> It is with mixed feelings that I announce my resignation from the
> OpenStack Cinder core reviewer team.
> It has been a great pleasure to watch the OpenStack project evolve over
> the years I have participated, and bit of sadness to move into a new role
> at work where I am no longer involved.
> After changing jobs I had attempted to keep up with Cinder reviews, but I
> clearly have not participated in a few months now. I appreciate Cinder and
> the other teams I've worked with in the OpenStack project, and consider the
> time I spent working with you all one of the best jobs I have had. I do
> not, however, think I will be able to keep up with reviews in the future,
> so I should go ahead and resign.
> Please feel free to contact me anytime about Cinder or for any other
> reason.
>
> scottda
> Scott D'Angelo
> scott.dang...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Zuul dashboard available

[Tong Liu]

Today, there are lots of zuul jobs timed out and the dashboard is
inaccessible with "proxy error". Can zuul team have a look at it?

Thanks,
Tong

On Mon, Dec 11, 2017 at 9:11 AM, James E. Blair  wrote:

> Hi,
>
> I'd like to draw your attention to a recently added feature in Zuul.
>
> If you visit http://zuulv3.openstack.org/ you will note three tabs at
> the top of the screen (you may need to shift-reload the page): Status,
> Jobs, Builds.  The "Jobs" page shows you a list of all of the jobs in
> the system, along with their descriptions.  And the "Builds" page lists
> the most recent runs.  You can query by pipeline, job, and project.
>
> This may be especially helpful in tracking down builds (and their logs)
> for periodic or other post-merge jobs.
>
> We have a lot of plans to expand on and enhance these pages in the
> future, however, for the next short while, we probably won't be making
> very substantial changes to them as we prepare for the actual Zuul v3.0
> release.
>
> We hope in the mean time, the additional functionality they provide will
> prove useful.
>
> Thanks very much to Tristan Cacqueray and Joshua Hesketh whose work has
> made this possible.
>
> -Jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] [all] TC Report 50

[Chris Dent]

( HTML at https://anticdent.org/tc-report-50.html )

Several members of the TC were at 
[KubeCon](http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america)
last week so there's been limited activity since the [last
report](https://anticdent.org/tc-report-49.html) and, of what has
happened, much of it is related to establishing productive relations
with the Kubernetes community.

## Coping with Strategic Contributions

One of the things that came out of the conversations that happened
with the k8s community is that they too are struggling to deal with
ensuring what ttx describes as strategic contributions: functionality
that is of benefit to the entire community as opposed to features
pushed upstream by corporations to enhance their position or
visibility in the market.

There's some discussion of this on
[Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-07.log.html#t2017-12-07T14:58:20)
and some again [Today
(Tuesday)](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html#t2017-12-12T09:41:59).

I expressed some confusion about the term, as what's strategic is
in the eye of the beholder and the executor, and a mind of a certain
disposition tends towards thinking of _strategic_ contributions as
advancing nefarious gains, and _clearly_ the happy world of open
source would _never_ be nefarious, so it must be corporations.

A positive outcome from the conversations last week is "...we'll push
the respective corporate sponsors of our respective foundations to
report 'how they contribute to the project'". An important
distinction here from other attempts at encouraging long-term, of
benefit to the entire community, contributions is that this would be
human narrative, not numbers. Stories of the ways in which corporate
sponsors have enabled lasting improvements.

Thursday afternoon's
[discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-07.log.html#t2017-12-07T15:18:14)
had some additional details on how and why human curated information
may be most useful for this kind of thing, but there are the usual
constraints of "who will do that?"

## Other KubeCon

There were also summaries from ttx and dhellman on a variety of additional
topics from KubeCon in [today's
log](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html).
Some interesting points in there beyond strategic contributions,
including:

* [dev
  
tooling](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html#t2017-12-12T09:35:12)
  (see also [dhellman a bit later in the
  
day](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html#t2017-12-12T14:22:59))
* [different styles of
  
governance](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html#t2017-12-12T09:53:46)
* [release
  
management](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-12.log.html#t2017-12-12T10:03:51)

There are going to be a lot of opportunities for learning and collaborating.
I hope we'll see some further summaries (human narrative!) from the
people who were there.

## Stuck Reviews

There are a couple of governance reviews in progress that need input
from the wider community. As things currently stand they are a bit stuck:

* [Clarify testing for interop 
programs](https://review.openstack.org/#/c/521602/)
* [Add Storyboard Migration (as a goal) to 
Rocky](https://review.openstack.org/#/c/513875/)

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] Upcoming Deadlines

[Lance Bragstad]

On 12/11/2017 07:08 PM, Adam Heczko wrote:
> Thanks Lance for a comprehensive summary.
> However I'm bit puzzled with application credentials spec,
> specifically with the sentence 'This model, while convenient for keystone,
> increases the risk of account compromise by requiring the distribution
> of unencrypted passwords.'
> My personal preference for securing OS cloud credentials is to
> leverage X.509/PKI rather than username and password.
> X.509 authN plugin is available since some time ago [4] and I'd really
> appreciate if Keystone team could explain how app credentials will
> interact with existing (e.g. x.509) authN plugin in federated
> scenario. How role assignment derived from federation mapping (and
> x.509 certificate) is going to interact with application credentials?
> This is important for me since I received a lot of complains about
> clear text passwords and typically my recommendation is to mitigate it
> with said x.509 approach.
As far as the application credentials implementation goes, there will
still be an ID and a secret that needs to be used when authenticating.
So if you have requirements around plaintext passwords in service
configuration files, you might still have that concern with application
credentials since the secret is essentially the password.

We have had a few sessions with oslo [0] about the storage of passwords
in configuration files that might be relevant to you though (if I'm
understanding correctly).

[0]
http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html

>
> [4] https://review.openstack.org/#/c/283905/16
> [5] 
> https://docs.openstack.org/keystone/pike/advanced-topics/federation/mapping_combinations.html
>
> On Mon, Dec 11, 2017 at 11:37 PM, Lance Bragstad  > wrote:
>
> Sending out a gentle reminder that feature proposal freeze will be
> next
> week. It looks like all possible features are in flight based on the
> current state of the specs repository. The only exception is the
> unified
> limit specification, which was rebased and passing today [0].
>
> Thanks!
>
> [0] https://review.openstack.org/#/c/455709/
> 
>
> On 11/20/2017 11:25 AM, Lance Bragstad wrote:
> > Sending out a reminder that we have a couple deadlines approaching.
> >
> > First, *specification* *freeze* is *two weeks away*. Here is a short
> > list of things we've committed to but need the specification to merge:
> >
> > - Unified Limits API [0]
> > - Application Credentials [1]
> > - System Scope [2]
> > - Scope Types [3]
> >
> > These reviews should take priority.
> >
> > Second, *feature* *proposal* *freeze* is *four weeks away*. Remember
> > that this deadline falls earlier than last release due to the holiday
> > season. So far, only application credentials and unified limits are
> > missing proposed implementations. Again, these are just proposals.
> > Feature freeze is January 26th.
> >
> > If you have spare cycles and want to tag-team one of these efforts
> > with an existing owner, please don't hesitate to reach out. Let me
> > know if there is anything I've missed. Thanks!
> >
> >
> > [0] https://review.openstack.org/#/c/455709/
> 
> > [1] https://review.openstack.org/#/c/512505/
> 
> > [2] https://review.openstack.org/#/c/464763/
> 
> > [3] https://review.openstack.org/#/c/500207/
> 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> -- 
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
>
> __
> OpenStack Development Mailing 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] [cinder] Resigning as core reviewer

[mdulko]

Hi,

Wanting to keep it fair with the community I want to resign from core
reviewer status in Cinder. During beginning of the year my team was
under continous changes and I wasn't able to participate deeply in
Cinder community. Now with upcoming challenges in my new position I
find it impossible to pay enough attention to Cinder to be confident
with reviewing patches with +2.

I'm still in the community, so I'll be happy to help in my expertise
areas - please feel free to bug me about anything on IRC or add me as
reviewer on patches.

Thanks,
Michal

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

Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Mooney, Sean K]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, December 12, 2017 3:02 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification
> on the scope of the capacity query
> 
> On 12/11/2017 12:41 PM, Csatari, Gergely (Nokia - HU/Budapest) wrote:
> > Hi Jay,
> >
> > Okay. Thanks for the clarification. Makes sense.
> >
> > Random-thinking:
> > Maybe the best would be to have a privilege level what covers the
> needs of MANO/NFVO, but still not full admin privileges. Do you think
> is this possible?
> 
> I think that the differences between the super-privileged user needs
> that a MANO system has and an administrative user are pretty small. The
> MANO system needs to be able to query and dynamically adjust resource
> inventories, move and grow/shrink workloads as needed and essentially
> act like the underlying hardware is wholly owned and operated by
> itself.
> 
> Really, the only privilege that the MANO system user *doesn't* need is
> the ability to create new users/projects in Keystone. Everything else
> is something that the MANO system user needs to be able to do. This is
> why I've called NFV (and particularly MANO/NFVO) a "purpose-built telco
> application" in the past. And I don't say that as some sort of put-down
> of NFV. I'm just pointing out the reality of things, that's all.
[Mooney, Sean K] not all mano system require admin privileges. ONAP/OpenO/Ecomp 
do,
As far as I am aware OSM does not strictly require admin privilege in all cases.
e.g. it is intended to be able query the a vim or an iaas system such as 
OpenStack
for preexisting flavors, and images and use them if they exist instead of always
needing to have the permissions to create them. If the cloud it is managing does
not have the features it requires and it does not have admin credentials to 
create them
it will be unable to fulfill the requested vnf instantiation. Similarly on the 
networking
side not all VNF will require provider network as such vlan network to 
function. Since the
networking-sfc api is non privilege  a wan optimizer or dpi engine can still be 
injected into
a neutron tenant network without admin rights. As such in principal a mano 
system can be a
standard unprivileged tenant, however ONAP/OpenO and ecomp do not support that 
use case
in their architecture. 
> 
> The ramification of this reality is that people deploying NFV using
> cloud infrastructure software like OpenStack really need to fully
> isolate the infrastructure environments that are used for VNFs (the
> things managed by the MANO/NFVO) from the infrastructure environments
> that are used for more "traditional" virtual private server or IT
> applications.
> 
> 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] Gerrit custom menu entries - help needed

[Poulos, Brianna L.]

Hello,

I have found the Gerrit Dashboard Creator (see 
https://github.com/openstack/gerrit-dash-creator ) to be very helpful when 
putting together queries.

Thanks,
~Brianna

On 12/8/17, 16:25, "Sławek Kapłoński"  wrote:

Hello,

I’m trying to personalize my Gerrit menus in settings panel on 
review.openstack.org.
So I prepared query like:

(NOT owner:self) AND status:open AND label:Code-Review-0,self AND 
label:Workflow=0 AND (project:openstack/neutron OR 
project:openstack/neutron-lib) AND branch:master

And I wanted to create menu entry with this query. When I’m pasting query:


#/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master

On gerrit settings page it replaces me chars like , or = to something else 
and query looks like:


#/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master

And it don’t work properly then.
So I have a question to more experienced Gerrit users. What I’m doing wrong 
here and how I should create menu entry with query which I really want?

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl






__
OpenStack Development Mailing 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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Doug Hellmann]

> On Dec 12, 2017, at 9:42 AM, Paul Bourke  wrote:
> 
> From my understanding it would be a cleanup operation - which to be honest, 
> would be very much welcomed. I recently did a little work with Castellan to 
> integrate it with Murano and found the auth code to be very messy, and flat 
> out broken in some cases. If it's possible to let the barbican client take 
> care of this that sounds good to me.
> 
> > Which mode is used the most in the services that consume castellan
> > today?
> 
> Afaik Barbican is the only backend that currently exists in Castellan [0]. 
> Looking again it seems some support has been added for vault which is great, 
> but I reckon Barbican would still be the primary use.
> 
> I haven't been hugely active in Castellan but if the team would like some 
> more input on this or reviews please do ping me, I'd be glad to help.

What I mean is, in the services consuming Castellan, how do they expect it to 
authenticate to Barbican? As the current user or as a hard-coded fixed user 
controlled by the deployer? I would think most services would need to connect 
as the “current” user talking to them so they can access that user’s secrets 
from Barbican. Removing the keystoneauth stuff from the driver would therefore 
break all of those applications.

Doug

> 
> -Paul
> 
> [0] https://github.com/openstack/castellan/tree/master/castellan/key_manager
> 
> On 06/12/17 22:12, Doug Hellmann wrote:
>> Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:
>>> It's been a bit since the summit but I believe this was also discussed at
>>> the Denver PTG as well:  https://etherpad.openstack.org/p/oslo-ptg-queens
>>> 
>>> The keystoneauth stuff seems to be more from Sydney, but if I remember
>>> correctly, Castellan authenticates through keystoneauth and passes the
>>> session to barbicanclient.  This is the only use of keystoneauth within
>>> Castellan, so one idea that was mentioned was to see if Castellan could
>>> simply pass the credentials to barbicanclient, which would auth through
>>> keystoneauth instead, removing the dependency from Castellan.
>> It looks like Castellan tries to authenticate using the token from
>> the context in two separate cases [1]. That would cause the service
>> using castellan to connect to barbican as the user making the API
>> request. Removing the use of keystoneauth would mean that feature
>> would no longer work, and all requests to barbican would be made
>> as a hard-coded user.  That seems like a pretty fundamental difference
>> in behavior.
>> Which mode is used the most in the services that consume castellan
>> today?
>> I'm still not understanding the real motivation for removing the
>> dependency. Is it just someone's notion of cleaning things up? Or is
>> there a runtime issue of some sort?
>> Doug
>> [1] 
>> http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140
>>> 
>>> On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann 
>>> wrote:
>>> 
 Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:
> So from my understanding now, we are wanting to remove the HARD
 dependency on Keystoneauth, not to remove it completely since that would
 break the barbican client. Currently seeing if we just remove the
 dependency from requirements.txt, if that stops Keystoneauth from being
 used until you try to use the barbican.
 
 There would need to be more changes than that, because we still need the
 package to be installed for testing the Barbican driver.
 
 Maybe if someone could explain what the issue is, I can offer more
 detailed advice. What is wrong with having the keystoneauth dependency?
 Is it breaking something? Is it interfering with some other library?
 
 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 Development Mailing 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

[openstack-dev] [tripleo] The Weekly Owl - 2nd Edition

[Emilien Macchi]

Note: this is the second edition of a weekly update of what happens in TripleO.
The goal is to provide a short reading (less than 5 minutes) to learn
where we are and what we're doing.
Any contributions and feedback are welcome.

+-+
| General announcements |
+-+

+--> Queens milestone 2 released, read Alex's notes:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125216.html
+--> Queens 2 numbers: 218 bugs fixed (232 in queens-1 and 196 in
pike-2) & 17 blueprints implemented (1 in queens-1 & 7 in pike-2).
Congrats everyone!
+--> New cores: Ronelle and Wes (on CI repos), Gael (on
tripleo-validations) - thanks for your hard work!
+--> New contributors: David Peacock, Gabriel Szasz and Hanish Gogada
- welcome here and please let us know any question!
+--> Get your Queens spec merged by the end of this week!
+--> We'll discuss about Newton EOL in January, please let us know any concern.

+--+
| Continuous Integration |
+--+

+--> Rover is still Sagi and ruck is still Matt. Please let them know any
new CI issue.
+--> RDO Infra is in maintenance (upgrade) so promotion jobs can't run properly.
+--> Master promotion is 5 days, Pike is 9 days and Ocata is 6 days.
+--> Community meeting today, end of sprint tomorrow. More updates to come!
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

+-+
| Upgrades |
+-+

+--> Major upgrade workflows is ready for review.
+--> gate-tripleo-ci-centos-7-containers-multinode-upgrades-master now
in experimental pipeline
+--> gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike now
in check pipeline
+--> Documentation for Upgrades CI is ready for review:
https://review.openstack.org/#/c/520636/
+--> tripleo-upgrade upstream repository is still being imported from
the redhat repo but good progress has been made.
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status
and https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting

+---+
| Containers |
+---+

+--> k8s: getting OpenShift running
+--> undercloud: we decided to not make it the default in Queens,
since it doesn't work in CI yet. Some good progress (see reviews) has
been made but we still haven't feature parity. Help is needed on that
area.
+--> Good progress on the "container-prepare-workflow" blueprint!
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| Integration |
+--+

+--> The team is still working on Multiple Ceph clusters blueprint
+--> Multiple Ceph pools for Cinder is complete!
+--> Ceph Luminous support is now ready!
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> Seeking reviews for roles management, waiting for some additional
tripleo-common patches to finish still.
+--> The team is still working on testing Pike.
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> The team has again requested more review from TripleO developers,
please help if you can!
https://etherpad.openstack.org/p/validations-reviews
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> Openvswitch SR-IOV offload is under review.
+--> Routed networks is good progress and ready for review.
+--> OVN Metadata agent is ready for review as well.
+--> Some folks are also focused on Octavia integration (Sprint).
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> Some work is being done on the zaqar message format:
https://etherpad.openstack.org/p/zaqar_message
+--> The team is working in improving Mistral CI jobs and making them voting!
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+-+
| Owl facts |
+-+

The Ashy-faced Owl (Tyto glaucops) is ashy-grey with a prominent
orange-brown rim. There is a faint brownish wash at the lower edge of
the eyes, which are blackish-brown. The bill is yellowish-horn.
Upperparts are yellowish-brown with blackish vermiculations. The edge
of the wings near the wrist is orange-brown, and the wings are
yellowish-brown, finely mottled dark. The primaries, secondaries and
tail have a few dark bars.
Underparts are yellowish-brown with dark arrow-shaped spots. The legs
are relatively long, and feathered yellowish-brown. The toes are bare,
greyish-brown, and sparsely bristled. The claws are blackish-brown.
(source:
https://www.owlpages.com/owls/species.php?s=40)


Stay tuned!
--
Your fellow reporter, Emilien Macchi

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

[Ed Leafe]

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.

>> That brought up another issue: the current meeting time for the API-SIG is 
>> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
>> Australia, and so it was the middle of the night for him! As one of the 
>> goals for the API-SIG is to expand our audience and membership, edleafe 
>> committed to seeing if there is an available meeting slot at 2200UTC, which 
>> would be convenient for APAC, and still early enough for US people to 
>> attend. If an APAC-friendly meeting time would be good for you, please keep 
>> an eye out on the mailing list for an announcement if we are able to set 
>> that up, and then please attend and participate!
> 
> Looking at the current meeting schedule, there are openings at 2200UTC  on 
> Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
> Wednesday afternoons in the US). 
> 
> I’ve set up a doodle so that people can record their preferences:
> 
> https://doodle.com/poll/bec9gfff38zvh3ud
> 
> If you’re interested in attending API-SIG meetings, please fill out the form 
> at that URL with your preferences. I’ll summarize the results at the next 
> API-SIG meeting.
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- Ed Leafe






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

Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Jay Pipes]

On 12/11/2017 12:41 PM, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Hi Jay,

Okay. Thanks for the clarification. Makes sense.

Random-thinking:
Maybe the best would be to have a privilege level what covers the needs of 
MANO/NFVO, but still not full admin privileges. Do you think is this possible?


I think that the differences between the super-privileged user needs 
that a MANO system has and an administrative user are pretty small. The 
MANO system needs to be able to query and dynamically adjust resource 
inventories, move and grow/shrink workloads as needed and essentially 
act like the underlying hardware is wholly owned and operated by itself.


Really, the only privilege that the MANO system user *doesn't* need is 
the ability to create new users/projects in Keystone. Everything else is 
something that the MANO system user needs to be able to do. This is why 
I've called NFV (and particularly MANO/NFVO) a "purpose-built telco 
application" in the past. And I don't say that as some sort of put-down 
of NFV. I'm just pointing out the reality of things, that's all.


The ramification of this reality is that people deploying NFV using 
cloud infrastructure software like OpenStack really need to fully 
isolate the infrastructure environments that are used for VNFs (the 
things managed by the MANO/NFVO) from the infrastructure environments 
that are used for more "traditional" virtual private server or IT 
applications.


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

Re: [openstack-dev] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Paul Bourke]

From my understanding it would be a cleanup operation - which to be 
honest, would be very much welcomed. I recently did a little work with 
Castellan to integrate it with Murano and found the auth code to be very 
messy, and flat out broken in some cases. If it's possible to let the 
barbican client take care of this that sounds good to me.


> Which mode is used the most in the services that consume castellan
> today?

Afaik Barbican is the only backend that currently exists in Castellan 
[0]. Looking again it seems some support has been added for vault which 
is great, but I reckon Barbican would still be the primary use.


I haven't been hugely active in Castellan but if the team would like 
some more input on this or reviews please do ping me, I'd be glad to help.


-Paul

[0] https://github.com/openstack/castellan/tree/master/castellan/key_manager

On 06/12/17 22:12, Doug Hellmann wrote:

Excerpts from Gage Hugo's message of 2017-12-06 15:16:14 -0600:

It's been a bit since the summit but I believe this was also discussed at
the Denver PTG as well:  https://etherpad.openstack.org/p/oslo-ptg-queens

The keystoneauth stuff seems to be more from Sydney, but if I remember
correctly, Castellan authenticates through keystoneauth and passes the
session to barbicanclient.  This is the only use of keystoneauth within
Castellan, so one idea that was mentioned was to see if Castellan could
simply pass the credentials to barbicanclient, which would auth through
keystoneauth instead, removing the dependency from Castellan.


It looks like Castellan tries to authenticate using the token from
the context in two separate cases [1]. That would cause the service
using castellan to connect to barbican as the user making the API
request. Removing the use of keystoneauth would mean that feature
would no longer work, and all requests to barbican would be made
as a hard-coded user.  That seems like a pretty fundamental difference
in behavior.

Which mode is used the most in the services that consume castellan
today?

I'm still not understanding the real motivation for removing the
dependency. Is it just someone's notion of cleaning things up? Or is
there a runtime issue of some sort?

Doug

[1] 
http://git.openstack.org/cgit/openstack/castellan/tree/castellan/key_manager/barbican_key_manager.py#n140



On Tue, Dec 5, 2017 at 10:54 AM, Doug Hellmann 
wrote:


Excerpts from ARORA, ROHAN's message of 2017-12-05 14:37:49 +:

So from my understanding now, we are wanting to remove the HARD

dependency on Keystoneauth, not to remove it completely since that would
break the barbican client. Currently seeing if we just remove the
dependency from requirements.txt, if that stops Keystoneauth from being
used until you try to use the barbican.

There would need to be more changes than that, because we still need the
package to be installed for testing the Barbican driver.

Maybe if someone could explain what the issue is, I can offer more
detailed advice. What is wrong with having the keystoneauth dependency?
Is it breaking something? Is it interfering with some other library?

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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][ceilometer] cinder capacity notifications

[gordon chung]

hi,

i'm attempting to add support for the cinder capacity notifications that 
were added a while back[1].

adding measurement support in ceilometer is pretty simple where in most 
cases you just add an entry to a yaml file[2]. the problem i have right 
now is i have no idea what resource these measurement are measuring so 
i'm unsure how to name the measurement in ceilometer so a user can 
understand what it's measuring.

the following are probably stupid questions but i see it measures two 
different resource types, a 'pool' and a 'backend' and they are 
ultimately tied to a host. are these measuring the amount of disk on 
each host? our pools confined to a host?

anyone with better knowledge is welcomed to take over my patch.

[1] https://review.openstack.org/#/c/206923
[2] https://review.openstack.org/#/c/526538

cheers,

-- 
gord
__
OpenStack Development Mailing 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] Blueprints moved out to Rocky

[Alex Schultz]

On Tue, Dec 12, 2017 at 4:56 AM, Moshe Levi  wrote:
> I believe so,
> Just regarding the use of sample-env-generator tool is not supporting 
> parameters for roles:
> Such as  :
>
>   # Kernel arguments for ComputeSriov node
>   ComputeSriovParameters:
> KernelArgs: "intel_iommu=on iommu=pt"
> OvsHwOffload: True
>

It can, you just have to document them in the env generator file. See
https://github.com/openstack/tripleo-heat-templates/blob/master/sample-env-generator/composable-roles.yaml#L128

This has the advantage of being able to properly document the
parameters for end user consumption.

> So can we merged the patches as is and fix the sample-env-generator late?

If you throw up a WIP patch for this on top of the existing one, I'll
merge it.  I just don't want it forgotten as it's important for the
end user to be able to consume these environment files via the UI as
well.

Thanks,
-Alex

>
>> -Original Message-
>> From: Alex Schultz [mailto:aschu...@redhat.com]
>> Sent: Tuesday, December 12, 2017 12:20 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky
>>
>> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet 
>> wrote:
>> >
>> >
>> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz  wrote:
>> >>
>> >> Hey folks,
>> >>
>> >> So I went through the list of blueprints and moved some that were
>> >> either not updated or appeared to have a bunch of patches not in a
>> >> mergable state.
>> >>
>> >> Please take some time to review the list of blueprints currently
>> >> associated with Rocky[0] to see if your efforts have been moved. If
>> >> you believe you're close to implementing the feature in the next week
>> >> or two, let me know and we can move it back into Queens. If you think
>> >> it will take an extended period of time (more than 2 weeks) to land
>> >> but we need it in Queens, please submit an FFE.
>> >>
>> >
>> > I think these are in a close enough state to warrant inclusion in Queens:
>> >
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fget-networks-
>> action=0
>> >
>> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
>> 51a%7Ca
>> >
>> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
>> ta=EKi
>> > 0yRd07V01KvoZoiQY%2FMIZU9OPZHez6%2F06PL7e7EU%3D=0
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-list-
>> availa
>> > ble-roles-
>> action=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee862294
>> >
>> 7ea8ccc08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7
>> C63648
>> >
>> 6276360618857=rNn1Ujf2XKCslsW7idN1qJwn0DWpN7I8A4gvYWiELbI
>> %3D
>> > erved=0
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-select-
>> role
>> > s-
>> workflow=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947
>> ea8cc
>> >
>> c08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
>> 8627636
>> >
>> 0618857=jpH6L7d1c0w6WDZxPoeDeHBzb0T2FIgEhHiT3PElEMg%3D
>> served=
>> > 0
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-networks-
>> action
>> >
>> a=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
>> e5651a%
>> >
>> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857&
>> sdata=
>> > AlBpvtX3kdMedrO%2BehaRaTUhl%2BUclJdesiqsu7HvvEA%3D=0
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fvalidate-roles-
>> networks
>> >
>> ta=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
>> e5651a
>> >
>> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63648627636061885
>> 7
>> >
>> =uDK%2F4Wo9S0D9qySb%2BORYVE1HDtrJ0J6Ec8qWU8hUwkw%3D
>> d=0
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
>> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-roles-
>> action=0
>> >
>> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
>> 51a%7Ca
>> >
>> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
>> ta=Oos
>> > SA5xeI4L4Ue6XbPh1Wd83tUU1SehQG%2BaSxRFXNW8%3D=0
>> >
>>
>> Ok I reviewed them and they do appear to have patches posted and are
>> getting reviews.  I'll pull them back in to Queens and set the milestone to
>> queens-3. Please make sure to update us on the status during this week and
>> next week's IRC meetings. I would like to make sure these land ASAP. Do you
>> think they should be in a state to land by the end of next week say 12/21?
>>
>> Thanks,
>> -Alex
>>
>> > There is a good chance of these being completed in the coming week.
>> >
>> > Thanks,
>> >
>> > Brad
>> >>
>> >>
>> > --
>> > Brad 

Re: [openstack-dev] [all] cyclomatic complexity check in flake8 & Python 3

[Thomas Herve]

On Tue, Dec 12, 2017 at 2:08 PM, Thierry Carrez  wrote:
> Zane Bitter wrote:
>> We have around 60 repos using the 'mccabe' package to do cyclomatic
>> complexity checks in flake8 in their gate jobs.[1] Based on advice
>> received at the time[2], the version of mccabe that we use in the gate
>> is effectively pinned to 0.2.1 by hacking (the project, not... never
>> mind).[3]
>>
>> This is starting to cause problems, because version 0.2.1 does not work
>> with Python 3. By 'does not work' I don't mean that it refuses to run, I
>> mean that it returns completely different numbers. (As far as I can tell
>> they're always the same or lower.) tox creates the pep8 environment
>> using the version of python that tox itself is running in, so as distros
>> increasingly prefer to install packages using python3, people will
>> increasingly be running flake8 under python3, and they'll run into
>> situations like the one I had today where their pep8 tests pass locally
>> but fail in the gate (which still runs under python2). When the gate
>> switches to python3, as I assume it eventually must, we'll get bogus
>> results.
>>
>> Unfortunately, moving to a later version is complicated by the fact that
>> 0.2.1 was... not good software. There is exactly one regression test.[4]
>> And if you're about to ask whether it was to check the trivial case that
>> the function:
>>
>>   def foo():
>>   return None
>>
>> has a cyclomatic complexity of 1, then the joke is on you because it
>> actually returns 2 for that function.
>>
>> Later versions have more tests and appear to be consistent with each
>> other and across python versions, but they return completely different
>> results to 0.2.1. And the results are mostly higher, so if we bump the
>> requirements many of those 60 projects will break.
>>
>> (I could also go into details on how the numbers that later versions
>> report are also wrong in different ways, but I'll save it for another day.)
>>
>> Here's how the allegedly most complex function in Heat[5] shakes out,
>> for example:
>>
>>   mccabe  py27  py36
>>   0.2.114 6
>>   0.3.12323
>>   0.6.12323
>>
>> I don't have a solution to suggest, but I burned most of my day digging
>> into this so I just wanted to let y'all know how screwed we are.
> Thanks for digging into this, Zane. I'd say we have two options, based
> on how useful running those tests is:
>
> 1/ If they are useful, we should bump the version, at the same time
> adjusting max-complexity per repo to match the most complex function
> (with some slack factor). Encourage more projects to use cyclomatic
> complexity checks and fix the biggest offenders using cycle goals.
>
> 2/ If they are not useful, just drop cyclomatic complexity tests overall
> rather than relying on wrong results and wasting CPU cycles

Hugely in favor of doing that. Even if it was working properly, I
don't think for Heat it was ever a useful test. We end up either
bumping the max or moving a conditional in a function, which doesn't
solve anything.

-- 
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] [First Contact] [OUI] Call for Project Liaisons

[Ghanshyam Mann]

On Tue, Dec 12, 2017 at 6:25 AM, Kendall Nelson  wrote:
> Hello,
>
> As some of you may know there is a newly formed SIG focused on the initial
> interactions of someone new to the community called the First Contact SIG.
> While the team we have looking out for these first introductions is growing
> they can only get us so far. After we get them up to speed with the tools
> and community it is important that they are connected with someone who can
> get them up to speed on a project. While these SIG members cover a variety
> of projects, there are several projects that don’t have someone to help
> these newcomers.
>
> If you are interested in being a project liaison please reply to this thread
> with your name, irc nic, email, and timezone (UTC +/- x).
>
> Previously, Upstream Institute had started to collect a list of people
> interested in helping get new community members up to speed in the past and
> I think it would be good to unite these efforts. That list covers only 6
> projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you signed
> up before and are interested in this renewed effort please let me know!

Thanks Kendall. Count me in to continue on project liaison too.

>
> Even if everyone from the initial effort participates, there are still many
> projects missing from the list. How best to ensure the growth and success of
> your project than to invest in the people interested in contributing to your
> project?
>
> Thanks!
>
> Kendall Nelson (diablo_rojo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-gmann

__
OpenStack Development Mailing 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][nova][cinder][os-brick]Unable to attach cinder volume in IPv6 environment

[Wang, Peter (Xu)]

Hi all

I am testing the cinder/nova within IPv6 environment but not luck.

I am testing the attatchment of volumes which are exposed by IPv6 iSCSI 
portals. We have modified the driver's interface *initialize_connection* to 
return correct connection information(wrap the IPv6 address with []) for use of 
nova's os-brick, below is the dict returned by driver:

{'driver_volume_type': u'iscsi', 'data': {'target_luns': [2, 2, 2, 2], 
'target_iqns': [u'iqn.1992-04.com.emc:cx.apm00150602415.b0', 
u'iqn.1992-04.com.emc:cx.apm00150602415.a0', 
u'iqn.1992-04.com.emc:cx.apm00150602415.a0', 
u'iqn.1992-04.com.emc:cx.apm00150602415.a0'], 'target_discovered': True, 
'target_iqn': u'iqn.1992-04.com.emc:cx.apm00150602415.a0', 'target_portals': 
[u'192.168.1.60:3260', u'192.168.1.59:3260', u'[fd00:0:0:0:0:0:0:4]:3260', 
u'[fd27:2e95:e174:0:0:0:0:100]:3260'], 'volume_id': 
u'87458755-78a8-4c4b-8e8c-c906b3267b6c', 'target_lun': 2, 'target_portal': 
u'[fd00:0:0:0:0:0:0:4]:3260'}}

After driver returns above data to nova/os-brick, the nova-compute failed into 
an infinite loop keeping updating the iscsi node, and consumed 30% of the cpu, 
log entry like below:

Dec 12 02:18:14 ubuntu16 nova-compute[1371]: DEBUG 
oslo_concurrency.processutils [None req-342eaed8-ca05-4387-b485-b4334e18e366 
admin admin] CMD "iscsiadm -m node -T iqn.1992-04.com.emc:cx.apm00150602415.a0 
-p [fd27:2e95:e174:0:0:0:0:100]:3260 --op update -n node.startup -v automatic" 
returned: 0 in 0.009s {{(pid=17633) execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:404}}

And around 18360 node update executed for a single volume attachment:
$ grep "\-\-op update \-n node.startup" n-cpu.log   | wc -l
18360

This should not a network issue since I have manually logged in ipv6 portal 
with iscsiadm successfully.

I am wondering whether this a known bug or a driver issue?

Thanks
Peter
__
OpenStack Development Mailing 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] Blueprints moved out to Rocky

[Brad P. Crochet]

On Mon, Dec 11, 2017 at 5:20 PM Alex Schultz  wrote:

> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet  wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz  wrote:
> >>
> >> Hey folks,
> >>
> >> So I went through the list of blueprints and moved some that were
> >> either not updated or appeared to have a bunch of patches not in a
> >> mergable state.
> >>
> >> Please take some time to review the list of blueprints currently
> >> associated with Rocky[0] to see if your efforts have been moved. If
> >> you believe you're close to implementing the feature in the next week
> >> or two, let me know and we can move it back into Queens. If you think
> >> it will take an extended period of time (more than 2 weeks) to land
> >> but we need it in Queens, please submit an FFE.
> >>
> >
> > I think these are in a close enough state to warrant inclusion in Queens:
> >
> > https://blueprints.launchpad.net/tripleo/+spec/get-networks-action
> >
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-list-available-roles-action
> >
> https://blueprints.launchpad.net/tripleo/+spec/tripleo-common-select-roles-workflow
> > https://blueprints.launchpad.net/tripleo/+spec/update-networks-action
> > https://blueprints.launchpad.net/tripleo/+spec/validate-roles-networks
> > https://blueprints.launchpad.net/tripleo/+spec/update-roles-action
> >
>
> Ok I reviewed them and they do appear to have patches posted and are
> getting reviews.  I'll pull them back in to Queens and set the
> milestone to queens-3. Please make sure to update us on the status
> during this week and next week's IRC meetings. I would like to make
> sure these land ASAP. Do you think they should be in a state to land
> by the end of next week say 12/21?
>
> Thanks,
> -Alex
>
>
Yes. They will be in a state to land by 12/21.

Thanks,

Brad


> > There is a good chance of these being completed in the coming week.
> >
> > Thanks,
> >
> > Brad
> >>
> >>
> > --
> > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> > Principal Software Engineer
> > (c) 704.236.9385 <(704)%20236-9385>
> >
> >
> >
> __
> > OpenStack Development Mailing 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
>
-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer
(c) 704.236.9385
__
OpenStack Development Mailing 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] cyclomatic complexity check in flake8 & Python 3

[Sean Dague]

On 12/12/2017 08:08 AM, Thierry Carrez wrote:
> Zane Bitter wrote:

>> Here's how the allegedly most complex function in Heat[5] shakes out,
>> for example:
>>
>>   mccabe  py27  py36
>>   0.2.1    14 6
>>   0.3.1    23    23
>>   0.6.1    23    23
>>
>> I don't have a solution to suggest, but I burned most of my day digging
>> into this so I just wanted to let y'all know how screwed we are.
> Thanks for digging into this, Zane. I'd say we have two options, based
> on how useful running those tests is:
> 
> 1/ If they are useful, we should bump the version, at the same time
> adjusting max-complexity per repo to match the most complex function
> (with some slack factor). Encourage more projects to use cyclomatic
> complexity checks and fix the biggest offenders using cycle goals.
> 
> 2/ If they are not useful, just drop cyclomatic complexity tests overall
> rather than relying on wrong results and wasting CPU cycles
> 
> So I'd like to hear from the 60+ repos on whether using those tests lead
> to any good results :)

I don't know how useful these end up being (#1), though I've seen
patches from time to time with people trying to reduce them.

The current max in Nova is 35. Moving to mccabe 0.6.1 generates 2 errors:

Running flake8 on all files
./nova/compute/manager.py:763:5: C901 'ComputeManager._init_instance' is
too complex (37)
./nova/tests/functional/api_samples_test_base.py:144:5: C901
'ApiSampleTestBase._compare_result' is too complex (36)

I honestly think this is one of the things that you declare a flag day a
couple weeks out, warn everyone they are going to have to adjust their
max, and move forward. It's a very easy fix when pep8 starts failing people.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] cyclomatic complexity check in flake8 & Python 3

[Thierry Carrez]

Zane Bitter wrote:
> We have around 60 repos using the 'mccabe' package to do cyclomatic
> complexity checks in flake8 in their gate jobs.[1] Based on advice
> received at the time[2], the version of mccabe that we use in the gate
> is effectively pinned to 0.2.1 by hacking (the project, not... never
> mind).[3]
> 
> This is starting to cause problems, because version 0.2.1 does not work
> with Python 3. By 'does not work' I don't mean that it refuses to run, I
> mean that it returns completely different numbers. (As far as I can tell
> they're always the same or lower.) tox creates the pep8 environment
> using the version of python that tox itself is running in, so as distros
> increasingly prefer to install packages using python3, people will
> increasingly be running flake8 under python3, and they'll run into
> situations like the one I had today where their pep8 tests pass locally
> but fail in the gate (which still runs under python2). When the gate
> switches to python3, as I assume it eventually must, we'll get bogus
> results.
> 
> Unfortunately, moving to a later version is complicated by the fact that
> 0.2.1 was... not good software. There is exactly one regression test.[4]
> And if you're about to ask whether it was to check the trivial case that
> the function:
> 
>   def foo():
>   return None
> 
> has a cyclomatic complexity of 1, then the joke is on you because it
> actually returns 2 for that function.
> 
> Later versions have more tests and appear to be consistent with each
> other and across python versions, but they return completely different
> results to 0.2.1. And the results are mostly higher, so if we bump the
> requirements many of those 60 projects will break.
> 
> (I could also go into details on how the numbers that later versions
> report are also wrong in different ways, but I'll save it for another day.)
> 
> Here's how the allegedly most complex function in Heat[5] shakes out,
> for example:
> 
>   mccabe  py27  py36
>   0.2.1    14 6
>   0.3.1    23    23
>   0.6.1    23    23
> 
> I don't have a solution to suggest, but I burned most of my day digging
> into this so I just wanted to let y'all know how screwed we are.
Thanks for digging into this, Zane. I'd say we have two options, based
on how useful running those tests is:

1/ If they are useful, we should bump the version, at the same time
adjusting max-complexity per repo to match the most complex function
(with some slack factor). Encourage more projects to use cyclomatic
complexity checks and fix the biggest offenders using cycle goals.

2/ If they are not useful, just drop cyclomatic complexity tests overall
rather than relying on wrong results and wasting CPU cycles

So I'd like to hear from the 60+ repos on whether using those tests lead
to any good results :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [masakari] problems starting up masakari instance monitoring in devstack @ master

[Waines, Greg]

Any thoughts on what i don’t have setup correctly wrt the masakari client from 
the errors below ?
Greg.

From: Greg Waines 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Monday, December 11, 2017 at 8:05 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [masakari] problems starting up masakari instance 
monitoring in devstack @ master

I started up a VM and then deleted the VM ... and got some errors that make me 
think i don’t have the masakari client setup correctly.
Any ideas ?
Greg.

i.e.
stack@devstack-masakari:~/devstack$ nova list


+--+-+++-+-+
| ID   | Name| Status | Task State | 
Power State | Networks|
+--+-+++-+-+
| de8922c6-450d-4e2e-954d-ee4bd05ab909 | vm-1-cirros | ACTIVE | -  | 
Running | private=10.0.0.10, fd1a:8f71:1a96:0:f816:3eff:fe5e:f315 |
+--+-+++-+-+
stack@devstack-masakari:~/devstack$
stack@devstack-masakari:~/devstack$ nova delete vm-1-cirros
Request to delete server vm-1-cirros has been accepted.
stack@devstack-masakari:~/devstack$ 2017-12-11 12:58:28.319 25974 INFO 
masakarimonitors.instancemonitor.libvirt_handler.callback [-] Libvirt Event: 
type=VM, hostname=devstack-masakari, uuid=de8922c6-450d-4e2e-954d-ee4bd05ab909, 
time=2017-12-11 12:58:28.318781, event_id=LIFECYCLE, detail=STOPPED_DESTROYED)
2017-12-11 12:58:28.319 25974 INFO masakarimonitors.ha.masakari [-] Send a 
notification. {'notification': {'hostname': 'devstack-masakari', 'type': 'VM', 
'payload': {'instance_uuid': 'de8922c6-450d-4e2e-954d-ee4bd05ab909', 
'vir_domain_event': 'STOPPED_DESTROYED', 'event': 'LIFECYCLE'}, 
'generated_time': datetime.datetime(2017, 12, 11, 12, 58, 28, 318781)}}
2017-12-11 12:58:28.351 25974 WARNING masakarimonitors.ha.masakari [-] Retry 
sending a notification. (HttpException: Expecting to find domain in project. 
The server could not comply with the request since it is either malformed or 
otherwise incorrect. The client is assumed to be in error. (HTTP 400) 
(Request-ID: req-feaa30f9-fbb2-4259-8851-488ff7ab82f9), Expecting to find 
domain in project. The server could not comply with the request since it is 
either malformed or otherwise incorrect. The client is assumed to be in 
error.): HttpException: HttpException: Expecting to find domain in project. The 
server could not comply with the request since it is either malformed or 
otherwise incorrect. The client is assumed to be in error. (HTTP 400) 
(Request-ID: req-feaa30f9-fbb2-4259-8851-488ff7ab82f9), Expecting to find 
domain in project. The server could not comply with the request since it is 
either malformed or otherwise incorrect. The client is assumed to be in error.
... several times ... and then eventually
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari Traceback 
(most recent call last):
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/masakarimonitors/ha/masakari.py", line 
91, in send_notification
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari 
payload=event['notification']['payload'])
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/masakariclient/sdk/ha/v1/_proxy.py", 
line 65, in create_notification
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari return 
self._create(_notification.Notification, **attrs)
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/openstack/proxy2.py", line 194, in 
_create
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari return 
res.create(self._session)
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/openstack/resource2.py", line 588, in 
create
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari 
json=request.body, headers=request.headers)
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/keystoneauth1/session.py", line 848, in 
post
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari return 
self.request(url, 'POST', **kwargs)
2017-12-11 13:00:28.536 25974 ERROR masakarimonitors.ha.masakari   File 
"/usr/local/lib/python2.7/dist-packages/openstack/session.py", line 64, in 
map_exceptions_wrapper
2017-12-11 13:00:28.536 25974 ERROR 

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

[Moshe Levi]

I believe so,
Just regarding the use of sample-env-generator tool is not supporting 
parameters for roles:
Such as  :

  # Kernel arguments for ComputeSriov node
  ComputeSriovParameters:
KernelArgs: "intel_iommu=on iommu=pt"
OvsHwOffload: True

So can we merged the patches as is and fix the sample-env-generator late?

> -Original Message-
> From: Alex Schultz [mailto:aschu...@redhat.com]
> Sent: Tuesday, December 12, 2017 12:20 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> 
> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet 
> wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz  wrote:
> >>
> >> Hey folks,
> >>
> >> So I went through the list of blueprints and moved some that were
> >> either not updated or appeared to have a bunch of patches not in a
> >> mergable state.
> >>
> >> Please take some time to review the list of blueprints currently
> >> associated with Rocky[0] to see if your efforts have been moved. If
> >> you believe you're close to implementing the feature in the next week
> >> or two, let me know and we can move it back into Queens. If you think
> >> it will take an extended period of time (more than 2 weeks) to land
> >> but we need it in Queens, please submit an FFE.
> >>
> >
> > I think these are in a close enough state to warrant inclusion in Queens:
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fget-networks-
> action=0
> >
> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
> 51a%7Ca
> >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
> ta=EKi
> > 0yRd07V01KvoZoiQY%2FMIZU9OPZHez6%2F06PL7e7EU%3D=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-list-
> availa
> > ble-roles-
> action=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee862294
> >
> 7ea8ccc08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7
> C63648
> >
> 6276360618857=rNn1Ujf2XKCslsW7idN1qJwn0DWpN7I8A4gvYWiELbI
> %3D
> > erved=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-select-
> role
> > s-
> workflow=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947
> ea8cc
> >
> c08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 8627636
> >
> 0618857=jpH6L7d1c0w6WDZxPoeDeHBzb0T2FIgEhHiT3PElEMg%3D
> served=
> > 0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-networks-
> action
> >
> a=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
> e5651a%
> >
> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857&
> sdata=
> > AlBpvtX3kdMedrO%2BehaRaTUhl%2BUclJdesiqsu7HvvEA%3D=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fvalidate-roles-
> networks
> >
> ta=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
> e5651a
> >
> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63648627636061885
> 7
> >
> =uDK%2F4Wo9S0D9qySb%2BORYVE1HDtrJ0J6Ec8qWU8hUwkw%3D
> d=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-roles-
> action=0
> >
> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
> 51a%7Ca
> >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
> ta=Oos
> > SA5xeI4L4Ue6XbPh1Wd83tUU1SehQG%2BaSxRFXNW8%3D=0
> >
> 
> Ok I reviewed them and they do appear to have patches posted and are
> getting reviews.  I'll pull them back in to Queens and set the milestone to
> queens-3. Please make sure to update us on the status during this week and
> next week's IRC meetings. I would like to make sure these land ASAP. Do you
> think they should be in a state to land by the end of next week say 12/21?
> 
> Thanks,
> -Alex
> 
> > There is a good chance of these being completed in the coming week.
> >
> > Thanks,
> >
> > Brad
> >>
> >>
> > --
> > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer
> > (c) 704.236.9385
> >
> >
> >
> __
> 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8cc
> c08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 86276360618857=vzMYyfhGhBEbJjEWeBCjQwAdsOdk7ZokGM7RI63Re
> NQ%3D=0
> >
> 
> 

Re: [openstack-dev] [neutron][l2gw] Preventing DB out-of-sync

[Ricardo Noriega De Soto]

Peng, I think you are right. We should have a common behavior among the
drivers, and move the implementation to the proper methods like
post-commits, do the validation on the pre-commits, etc, etc.

Second phase to tackle the out-of-sync could be the "revision number"
approach from networking-ovn.

Cheers

On Mon, Dec 11, 2017 at 4:32 PM, Peng Liu  wrote:

> Hi Michael,
>
> Yes, it's a similar issue but different aspect. Actually, the case for
> l2gw is worse, considering we have to deal with 2 existing back-end driver
> which have different understanding for the interfaces. But I think the
> proposed approach for networking-ovn is inspiring and helpful for l2gw.
>
> Thanks,
>
> On Fri, Dec 8, 2017 at 11:59 PM, Michael Bayer  wrote:
>
>> On Wed, Dec 6, 2017 at 3:46 AM, Peng Liu  wrote:
>> > Hi,
>> >
>> > During working on this patch[0], I encounter some DB out-of-sync
>> problem. I
>> > think maybe the design can be improved. Here is my thought, all
>> comments are
>> > welcome.
>>
>>
>> see also https://review.openstack.org/#/c/490834/ which I think is
>> dealing with a similar (if not the same) issue.
>>
>> >
>> > In plugin code, I found all the resource operations follow the pattern
>> in
>> > [1]. It is a very misleading design compare to [2].
>> >
>> > "For every action that can be taken on a resource, the mechanism driver
>> > exposes two methods - ACTION_RESOURCE_precommit, which is called within
>> the
>> > database transaction context, and ACTION_RESOURCE_postcommit, called
>> after
>> > the database transaction is complete."
>> >
>> > In result, if we focus on the out-of-sync between plugin DB and
>> > driver/backend DB:
>> >
>> > 1) In RPC driver, only methods Action_Resource and are implemented.
>> Which
>> > means the action is token before it was written in plugin DB. In case of
>> > action partial succeed (especially for update case) or plugin DB
>> operation
>> > failure, it will cause DB out-of-sync.
>> > 2) In ODL driver, only methods Action_Resource_postcommit are
>> implemented,
>> > which means there is no validation in ODL level before the record is
>> written
>> > in the plugin DB. In case of, ODL side failure, there is no rollback for
>> > plugin DB.
>> >
>> > So, to fix this issue is costly. Both plugin and driver sides need to be
>> > altered.
>> >
>> > The other side of this issue is a period db monitor mechanism between
>> plugin
>> > and drivers, and it is another story.
>> >
>> >
>> > [0] https://review.openstack.org/#/c/516256
>> > [1]
>> > ...
>> > def Action_Resource
>> > self.validate_Resource_for_Action
>> > self.driver.Action_Resource
>> > with context.session.begin(subtransactions=True):
>> > super.Action_Resource
>> > self.driver.Action_Resource_precommit
>> > try:
>> > self.driver.Action_Resource_postcommit
>> > ...
>> > [2] https://wiki.openstack.org/wiki/Neutron/ML2
>> >
>> > --
>> > Peng Liu
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Peng Liu | Senior Software Engineer
>
> Tel: +86 10 62608046 (direct)
> Mobile: +86 13801193245 <+86%20138%200119%203245>
>
> Red Hat Software (Beijing) Co., Ltd.
> 9/F, North Tower C,
> Raycom Infotech Park,
> No.2 Kexueyuan Nanlu, Haidian District,
> Beijing, China, POC 100190
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing 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] [qinling] [faas] project update

[Lingxian Kong]

Hi, all

Maybe there are aleady some people interested in faas implementation in
openstack, and also deployed other openstack services to be integrated with
(e.g. trigger function by object uploading in swift), Qinling is the thing
you probably don't want to miss out. The main motivation I creatd Qinling
project is from frequent requirements of our public cloud customers.

For people who have not heard about Qinling before, please take a look at
my presentation in Sydney Summit:
https://youtu.be/NmCmOfRBlIU
There is also a simple demo video:
https://youtu.be/K2SiMZllN_A

As the first project update email, I will just list the features
implemented for now:

- Python runtime
- Sync/Async function execution
- Job (invoke function on schedule)
- Function defined in swift object storage service
- Function defined in docker image
- Easy to interact with openstack services in function
- Function autoscaling based on request rate
- RBAC operation
- Function resource limitation
- Simple documentation

I will keep posting the project update by-weekly, but feel free to get in
touch in #openstack-qinling anytime.

Cheers,
Lingxian Kong (Larry)
__
OpenStack Development Mailing 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] [First Contact] [OUI] Call for Project Liaisons

[Matthew Oliver]

Initially I meant project liaison, but who am I to say no to helping new
people. I was new once, and had some great OpenStack mentors help me along
the way :)

Matt

On Tue, Dec 12, 2017 at 9:40 AM, Amy Marrich  wrote:

> Pretty sure he said both!:)
>
> Amy (spotz)
>
> On Mon, Dec 11, 2017 at 4:33 PM, Kendall Nelson 
> wrote:
>
>> Thank you Matt!
>>
>> To clarify, you want to be Project Liaison for sSwift? Or a member of the
>> SIG? Or both? :)
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Mon, Dec 11, 2017 at 2:18 PM Matthew Oliver 
>> wrote:
>>
>>> I'll put my hand up for my timezone. Especially as interest in my side
>>> of the world grows I'd love to make sure there is someone available.
>>>
>>> Project: Swift
>>> Name: Matthew Oliver
>>> IRC: mattolverau
>>> email: m...@oliver.net.au
>>> timezone: UTC +11 (AEDT)
>>>
>>> Matt
>>>
>>> On Tue, Dec 12, 2017 at 8:25 AM, Kendall Nelson 
>>> wrote:
>>>
 Hello,

 As some of you may know there is a newly formed SIG focused on the
 initial interactions of someone new to the community called the First
 Contact SIG. While the team we have looking out for these first
 introductions is growing they can only get us so far. After we get them up
 to speed with the tools and community it is important that they are
 connected with someone who can get them up to speed on a project. While
 these SIG members cover a variety of projects, there are several projects
 that don’t have someone to help these newcomers.

 If you are interested in being a project liaison please reply to this
 thread with your name, irc nic, email, and timezone (UTC +/- x).

 Previously, Upstream Institute had started to collect a list of people
 interested in helping get new community members up to speed in the past and
 I think it would be good to unite these efforts. That list covers only 6
 projects: Cinder, Keystone, Nova, Neutron, QA, and Trove[1]. If you signed
 up before and are interested in this renewed effort please let me know!

 Even if everyone from the initial effort participates, there are still
 many projects missing from the list. How best to ensure the growth and
 success of your project than to invest in the people interested in
 contributing to your project?

 Thanks!

 Kendall Nelson (diablo_rojo)

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


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

[openstack-dev] [tripleo] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 12/13/2017 at
1 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
 channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/7071866728



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