Re: [openstack-dev] Overriding project-templates in Zuul

[Ghanshyam Mann]

On Wed, May 2, 2018 at 11:21 PM, James E. Blair  wrote:
> Joshua Hesketh  writes:
>
>>>
>>> I think in actuality, both operations would end up as intersections:
>>>
>>>     ===  ===
>>> Matcher   Template  Project  Result
>>>     ===  ===
>>> files ABBC   B
>>> irrelevant-files  ABBC   B
>>>     ===  ===
>>>
>>> So with the "combine" method, it's always possible to further restrict
>>> where the job runs, but never to expand it.
>>
>> Ignoring the 'files' above, in the example of 'irrelevant-files' haven't
>> you just combined the results to expand when it runs? ie, A and C are /not/
>> excluded and therefore the job will run when there are changes to A or C?
>>
>> I would expect the table to be something like:
>>     ===  ===
>> Matcher   Template  Project  Result
>>     ===  ===
>> files ABBC   B
>> irrelevant-files  ABBC   ABC
>>     ===  ===
>
> Sure, we'll go with that.  :)
>
>>> > So a job with "files: tests/" and "irrelevant-files: docs/" would do
>>> > whatever it is that happens when you specify both.
>>>
>>> In this case, I'm pretty sure that would mean it reduces to just "files:
>>> tests/", but I've never claimed to understand irrelevant-files and I
>>> won't start now.
>>
>> Yes, I think you are right that this would reduce to that. However, what
>> about the use case of:
>>   files: tests/*
>>   irrelevant-files: tests/docs/*
>>
>> I could see a use case where both of those would be helpful. Yes you could
>> describe that as one regex but to the end user the above may be expected to
>> work. Unless we make the two options mutually exclusive I feel like this is
>> a feature we should support. (That said, it's likely a separate
>> feature/functionality than what is being described now).
>
> Today, that means: run the job if a file in tests/ is changed AND any
> file outside of tests/docs/* is changed.  A change to tests/foo matches
> the irrelevant-files matcher, and also the files matcher, so it runs.  A
> change to tests/docs/foo matches the files matcher but not the
> irrelevant-files matcher, so it doesn't run.  I really hope I got that
> right.  Anyway, that is an example of something that's possible to
> express with both.
>
> I lumped in the idea of pairing files/irrelevant-files with Proposal 2
> because I thought that being able to override them is key, and switching
> from one to the other was part of that, and, to be honest, I don't think
> people should ever combine them because it's hard enough to deal with
> one, but maybe that's too much of an implicit behavior change, and
> instead we should separate that out and consider it as its own change
> later.  I believe a user could still stop a the matchers by saying
> "files: .*" and "irrelevant-files: ^$" in the project-local variant.
>
> Let's revise Proposal #2 to omit that:
>
> Proposal 2: Files and irrelevant-files are treated as overwriteable
> attributes and evaluated after branch-matching variants are combined.
>
> * Files and irrelevant-files are overwritten, so the last value
>   encountered when combining all the matching variants (looking only at
>   branches) wins.
> * It's possible to both reduce and expand the scope of jobs, but the
>   user may need to manually copy values from a parent or other variant
>   in order to do so.
> * It will no longer be possible to alter a job attribute by adding a
>   variant with only a files matcher -- in all cases files and
>   irrelevant-files are used solely to determine whether the job is run,
>   not to determine whether to apply a variant.

This is limitation for this Proposal but i am not sure how many use
case of this features. I have not seen till now in jobs.
>

Yes, Proposal#2 looks good for nova use case [1] also where
integrated-gate templates job needs to be controlled by nova pipeline
definition mainly for 'irrelevant-files'. This approach gives benefit
of Easy to read from one place that this job is controlled by these
value of overridden var ('files', 'irrelevant-files').


-gmann

>> Anyway, I feel like Proposal #2 is more how I would expect the system to
>> behave.
>>
>> I can see an argument for combining the results (and feel like you could
>> evaulate that at the end after combining the branch-matching variants) to
>> give something like:
>>     ===  ===
>> Matcher   Template  Project  Result
>>     ===  ===
>> files ABBC   ABC
>> irrelevant-files  ABBC   ABC
>>     ===  ===
>>
>> However, that gives the user no way to remove a previously listed option.
>> Thus overwriting may be the better solution (ie proposal #2 as written)
>> unless we want to expl

Re: [openstack-dev] [nova] nova-manage cell_v2 map_instances uses invalid UUID as marker in the db

[Takashi Natsume]

The temporary fix to pass the gate jobs is to mock
the 'warnings.warn'　method in the test method.
Then add a TODO note to fix storing non-UUID value
in the 'map_instances' command of the 'CellV2Commands' class.

The fundamental solution is to change the design of
the 'map_instances' command.
In the first place, it is not good to store non-UUID value in the UUID 
field.


In some compute REST APIs, it returns the 'marker' parameter
in their pagination.
Then users can specify the 'marker' parameter in the next request.

So it is one way to change the command to stop storing a 'marker' value
in the InstanceMapping (instance_mappings) DB table
and return (print) a 'marker' value and be able to be specifid
the 'marker' value as the command line argument.

On 2018/05/08 18:49, Balázs Gibizer wrote:

Hi,

The oslo UUIDField emits a warning if the string used as a field value 
does not pass the validation of the uuid.UUID(str(value)) call [3]. All 
the offending places are fixed in nova except the nova-manage cell_v2 
map_instances call [1][2]. That call uses markers in the DB that are not 
valid UUIDs. If we could fix this last offender then we could merge the 
patch [4] that changes the this warning to an exception in the nova 
tests to avoid such future rule violations.


However I'm not sure it is easy to fix. Replacing 
'INSTANCE_MIGRATION_MARKER' at [1] to '----' 
might work but I don't know what to do with instance_uuid.replace(' ', 
'-') [2] to make it a valid uuid. Also I think that if there is an 
unfinished mapping in the deployment and then the marker is changed in 
the code that leads to inconsistencies.


I'm open to any suggestions.

Cheers,
gibi


[1] 
https://github.com/openstack/nova/blob/09af976016a83288df22ac6ed1cce1676c2294cc/nova/cmd/manage.py#L1168 

[2] 
https://github.com/openstack/nova/blob/09af976016a83288df22ac6ed1cce1676c2294cc/nova/cmd/manage.py#L1180 

[3] 
https://github.com/openstack/oslo.versionedobjects/blob/29e643e4a9866b33965b68fc8dfb8acf30fa/oslo_versionedobjects/fields.py#L359 


[4] https://review.openstack.org/#/c/540386


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


Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


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

[openstack-dev] [tripleo] gate jobs impacted RAX yum mirror

[Wesley Hayutin]

FYI.. https://bugs.launchpad.net/tripleo/+bug/1770298

I'm on #openstack-infra chatting w/ Ian atm.
Thanks
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ml2 plugin] unit test errors

[Sangho Shin]

Andreas,

Thank you for your answer. Actually, I was able to make it use the correct 
neutron API in my local tox tests, and all tests passed.
However, only in Zuul, I am still getting the following errors. :-(

Thank you,

Sangho


> 2018. 5. 9. 오후 4:04, Andreas Scheuring  작성:
> 
> neutron.plugins.ml2.driver_api got moved to neutron-lib. You probably need to 
> update the networking-onos code and fix all imports there and push the 
> changes...
> 
> 
> ---
> Andreas Scheuring (andreas_s)
> 
> 
> 
> On 9. May 2018, at 10:00, Sangho Shin  > wrote:
> 
> Hello, 
> 
> I am getting the following unit test error in Zuul test. See below.
> The error is caused only in the pike version, and in stable/ocata version, I 
> do not have the error.
> ( If you can give me any clue, it would be very helpful )
> 
> BTW, in nosetests, there is no error.
> However, in tox -e py27 tests, I am getting different errors like below. 
> Actually, it is caused because the tests are using different version of 
> neutron library somehow. Actual neutron is installed in /opt/stack/neutron 
> path, and it has correct python files such as callbacks and driver api, which 
> are complained below.
> 
> So, I would like to know how to specify the correct neutron location in tox 
> tests.
> 
> Thank you,
> 
> Sangho
> 
> 
> tox -e py27 errors.
> 
> -
> 
> 
> =
> Failures during discovery
> =
> --- import errors ---
> Failed to import test module: 
> networking_onos.tests.unit.extensions.test_driver
> Traceback (most recent call last):
>   File 
> "/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
>  line 456, in _find_test_path
> module = self._get_module_from_name(name)
>   File 
> "/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
>  line 395, in _get_module_from_name
> __import__(name)
>   File "networking_onos/tests/unit/extensions/test_driver.py", line 25, in 
> 
> import networking_onos.extensions.securitygroup as onos_sg_driver
>   File "networking_onos/extensions/securitygroup.py", line 21, in 
> from networking_onos.extensions import callback
>   File "networking_onos/extensions/callback.py", line 15, in 
> from neutron.callbacks import events
> ImportError: No module named callbacks
> 
> Failed to import test module: 
> networking_onos.tests.unit.plugins.ml2.test_driver
> Traceback (most recent call last):
>   File 
> "/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
>  line 456, in _find_test_path
> module = self._get_module_from_name(name)
>   File 
> "/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
>  line 395, in _get_module_from_name
> __import__(name)
>   File "networking_onos/tests/unit/plugins/ml2/test_driver.py", line 24, in 
> 
> from neutron.plugins.ml2 import driver_api as api
> ImportError: cannot import name driver_api
> 
> 
> 
> 
> 
> 
> Zuul errors.
> 
> ---
> 
> Traceback (most recent call last):
> 2018-05-09 05:12:30.077594 
> 
>  | ubuntu-xenial |   File 
> "/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py
>  
> ",
>  line 1182, in _execute_context
> 2018-05-09 05:12:30.077653 
> 
>  | ubuntu-xenial | context)
> 2018-05-09 05:12:30.077964 
> 
>  | ubuntu-xenial |   File 
> "/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py
>  
> ",
>  line 470, in do_execute
> 2018-05-09 05:12:30.078065 
> 
>  | ubuntu-xenial | cursor.execute(statement, parameters)
> 2018-05-09 05:12:30.078210 
> 
>  | ubuntu-xenial | InterfaceError: Error binding parameter 0 - probably 
> unsupported type.
> 2018-05-09 05:12:30.078282 
> 
>  | ubuntu-xenial | update failed: No details.
> 2018-05-09 0

[openstack-dev] [First Contact] [SIG] Forum Etherpads

[Kendall Nelson]

Hello Everyone!

I created etherpads for both of our Forum Sessions that were accepted and
added them to the master list[1]. Please feel free to add discussion topics
to them whether you can attend or not!

First Contact SIG Operator Inclusion:
https://etherpad.openstack.org/p/FC-SIG-Ops-Inclusion

Drafting Requirements for Organisations Contributing to Open
https://etherpad.openstack.org/p/Reqs-for-Organisations-Contributing-to-OpenStack

11 Days till Forum Fun

-Kendall Nelson (diablo_rojo)

[1]https://wiki.openstack.org/wiki/Forum/Vancouver2018#Wednesday.2C_May_23
__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Julia Kreger]

On Wed, May 9, 2018 at 5:10 PM, Casey Bodley  wrote:
>
> On 05/09/2018 11:40 AM, Casey Bodley wrote:
>>
>>
>> On 05/09/2018 11:22 AM, Matthew Thode wrote:
>>>
>>> python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
>>> tempurls.  That is, there was no official support, but it still worked.
>>>
>>> In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
>>> require /v1/account/container/object, which does not work with radosgw
>>> as it expects /v1/container/object.  This means that radosgw tempurls
>>> fail to work, which further means that radosgw will stop working for
>>> things like ironic.

What is the value in the validation of the URL path as such? It seems
like the client shouldn't really care as to the precise format of the
end user supplied URL as long as the server returns the expected
response.

>>> I can see the point that swiftclient should not care about ceph not
>>> fully implementing the swift spec and not supporting the radosgw url
>>> syntax, but it seems like a step back.  If this is not fixed then things
>>> like ironic will not work with radosgw for Ocata and above (as that's
>>> when this change was made).  We'd need to wait for either ceph to fix
>>> this and support the account part of the url (probably just dropping it)
>>> or have people fork python-swiftclient to 'fix' it.
>>>
>>> I'm not sure what the right answer is...

I'm personally -1 to pinning swiftclient as that will introduce
headaches if someone tries to install ironic along side anything that
expects a newer client or vise-versa.

I agree it seems like a step back, to which I'm curious about the
value of having the check. The forth option is for ironic to abruptly
drop all related code and support for radosgw temp urls, but that too
would be a setback and negative for OpenStack in general.

__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Casey Bodley]

On 05/09/2018 11:40 AM, Casey Bodley wrote:


On 05/09/2018 11:22 AM, Matthew Thode wrote:

python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
tempurls.  That is, there was no official support, but it still worked.

In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
require /v1/account/container/object, which does not work with radosgw
as it expects /v1/container/object.  This means that radosgw tempurls
fail to work, which further means that radosgw will stop working for
things like ironic.

I can see the point that swiftclient should not care about ceph not
fully implementing the swift spec and not supporting the radosgw url
syntax, but it seems like a step back.  If this is not fixed then things
like ironic will not work with radosgw for Ocata and above (as that's
when this change was made).  We'd need to wait for either ceph to fix
this and support the account part of the url (probably just dropping it)
or have people fork python-swiftclient to 'fix' it.

I'm not sure what the right answer is...

https://github.com/openstack/python-swiftclient/commit/4c955751d340a8f71a2eebdb3c58d90b36874a66
https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185

https://bugs.launchpad.net/ironic/+bug/1747384



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


Thanks for raising the issue. Radosgw does have a config option 
'rgw_swift_account_in_url' to expect this url format, though it 
defaults to false and I'm not 100% sure that it applies correctly to 
tempurls.


Marcus Watts confirmed that this does work with tempurl.

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

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

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

Many thanks !

Adding a gateway to a router: it looks like it works in the router creation 
method, but not in the router update method.
(i.e., passing a external_gateway_info dictionary in 
conn.network.create_router() worked,
but doing the same with conn.network.add_gateway_to_router() did not work)

the (verbose) code snippet is:

external_network = conn.network.find_network(EXTERNAL_NETWORK_NAME)

onap_gateway_external_subnets = []
for ext_subn_id in external_network.subnet_ids:
onap_gateway_external_subnets.append({'subnet_id':ext_subn_id})

network_dict_body = {
'network_id': external_network.id,
'enable_snat': True,
'external_fixed_ips': onap_gateway_external_subnets}

onap_router = conn.network.create_router(
name = ONAP_ROUTER_NAME,
description = ONAP_ROUTER_DESC,
external_gateway_info = network_dict_body,
is_admin_state_up = True)


I got the idea of trying at creation time, from the create_router API 
(external_gateway_info entry) at
https://developer.openstack.org/api-ref/network/v2/#layer-3-networking
(thanks for the tip!)

So there might be a difference between how network.create_router() handles this 
external_gateway_info,
versus how network.add_gateway_to_router() handles it.



About identity_api_version in clouds.yaml:
yep, that works !


About the "!=None" comparison problem: OK, thanks for the fixing effort in 
progress !

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] agenda for upcoming joint leadership meeting in vancouver

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-05-09 16:06:01 -0400:
> 
> The last time we had a joint leadership meeting, several TC members
> expressed the desire to have more information about what was going
> to be covered before the meeting. The agenda for the next meeting
> (to be held in Vancouver), is in the wiki at
> https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMeeting
> (I suggest "watching" that page to keep an eye on updates because
> it is still subject to change). The agenda items are a bit terse,
> so I thought I would send this email to give my understanding of
> what will be discussed. If you have questions or anything to add,
> please post a follow up message.
> 
> Welcome to new members --  We start with introductions for new
> folks, since there are new members of all 3 groups attending. This
> is usually just a chance to put a face with a name, but sometimes
> we mention employers. Because of the nature of the board, its members
> are usually more interested in who employs new board members than
> the TC or UC are about our members.
> 
> Executive Team Update -- Jonathan, Lauren, Mark, and Thierry will
> give updates about the summit and Foundation. We usually learn things
> like registration numbers for the event, major themes, etc.
> 
> User Committee Update -- Melvin and Matt will talk about the work
> the UC has been doing. I don't have any real details about that.
> 
> Strategic Discussions -- I put our topic about seeking more
> contributors with more time to spend upstream here. It's not entirely
> clear this is what Alan had in mind for this section, and since
> I've asked for the entire hour this may change.
> 
> As I've mentioned a few times in channel, I have been working on
> putting hard numbers together to demonstrate that individual
> contributors, given time to establish their credibility and actually
> do some work, can have a significant positive impact on the community
> and the direction of OpenStack. So far, I have a few cases drawn
> from contributions to our community goals and help-wanted list to
> demonstrate both success and failure to make this point. I hope
> that by framing it this way we can move on from the problem statement,
> which we have covered a few times in the past, and have a more
> fruitful discussion of how to convince engineering managers and
> other decision makers to allow developers to contribute in these
> ways. I will share the slide deck with everyone after the meeting,
> since it may change between now and then.
> 
> Updating the Foundation Mission Statement -- I'm not really sure
> what this is, beyond what it says.
> 
> Preview 2018 event strategy -- I've been told this is a
> presentation/discussion led by Lauren to talk about our in-person
> events such as the Summit/Forum and PTG.
> 
> Next steps for fixing bylaws typo -- This is our second agenda item,
> to talk about fixing the obvious error in the appendix to the bylaws
> that covers selecting TC members and defines "Active Technical
> Contributor" (section 3.b.i of
> https://www.openstack.org/legal/technical-committee-member-policy/).
> 
> When the bylaws were last modified, this section was changed to say
> "An Individual Member is an ATC who has..." meaning that a Foundation
> member must be an ATC. Clearly this is not the desired intent, and
> the text should read "An ATC is an Individual Member who has...".
> We need the Foundation legal folks to help us understand whether
> we need a membership vote to fix the wording, or if we can have the
> board amend it. The goal for this section of the meeting is to get
> someone to make that determination and then for the rest of us to
> settle on the next steps we will take to correct the issue.
> 
> Doug

Oops, I cut that off before the end of the agenda.

The last few items are part of a formal Board of Directors meeting.
Those are generally open except when they need to discuss something
in an Executive session, but only the Board members contribute to
the meeting unless someone else is specifically called on. As you
can see, it looks like this time around this section of the meeting
will only consist of committee updates.

Doug

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

Re: [openstack-dev] [tripleo] Migration to Storyboard

[Alex Schultz]

On Wed, May 9, 2018 at 2:20 PM, Wesley Hayutin  wrote:
>
>
> On Wed, May 9, 2018 at 3:25 PM Alex Schultz  wrote:
>>
>> Hello tripleo folks,
>>
>> So we've been experimenting with migrating some squads over to
>> storyboard[0] but this seems to be causing more issues than perhaps
>> it's worth.  Since the upstream community would like to standardize on
>> Storyboard at some point, I would propose that we do a cut over of all
>> the tripleo bugs/blueprints from Launchpad to Storyboard.
>>
>> In the irc meeting this week[1], I asked that the tripleo-ci team make
>> sure the existing scripts that we use to monitor bugs for CI support
>> Storyboard.  I would consider this a prerequisite for the migration.
>> I am thinking it would be beneficial to get this done before or as
>> close to M2.
>>
>> Thoughts, concerns, etc?
>
>
> Just clarifying.  You would like to have the tooling updated by M2, which is
> fine I think.  However squads are not expected to change all their existing
> procedures by M2 correct?   I'm concerned about migrating our current kanban
> boards to storyboard by M2.
>

I'm talking about tooling (irc bot/monitoring) and launchpad migration
complete by m2. Any other boards can wait until squads want to move
over.

Thanks,
-Alex

> Thanks
>
>>
>>
>> Thanks,
>> -Alex
>>
>> [0] https://storyboard.openstack.org/#!/project_group/76
>> [1]
>> http://eavesdrop.openstack.org/meetings/tripleo/2018/tripleo.2018-05-08-14.00.log.html#l-42
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [tripleo] Migration to Storyboard

[Wesley Hayutin]

On Wed, May 9, 2018 at 3:25 PM Alex Schultz  wrote:

> Hello tripleo folks,
>
> So we've been experimenting with migrating some squads over to
> storyboard[0] but this seems to be causing more issues than perhaps
> it's worth.  Since the upstream community would like to standardize on
> Storyboard at some point, I would propose that we do a cut over of all
> the tripleo bugs/blueprints from Launchpad to Storyboard.
>
> In the irc meeting this week[1], I asked that the tripleo-ci team make
> sure the existing scripts that we use to monitor bugs for CI support
> Storyboard.  I would consider this a prerequisite for the migration.
> I am thinking it would be beneficial to get this done before or as
> close to M2.
>
> Thoughts, concerns, etc?
>

Just clarifying.  You would like to have the tooling updated by M2, which
is fine I think.  However squads are not expected to change all their
existing procedures by M2 correct?   I'm concerned about migrating our
current kanban boards to storyboard by M2.

Thanks


>
> Thanks,
> -Alex
>
> [0] https://storyboard.openstack.org/#!/project_group/76
> [1]
> http://eavesdrop.openstack.org/meetings/tripleo/2018/tripleo.2018-05-08-14.00.log.html#l-42
>
> __
> OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Matthew Thode]

On 18-05-09 12:24:32, Clay Gerrard wrote:
> On Wed, May 9, 2018 at 12:08 PM, Matthew Thode 
> wrote:
> 
> >
> > * Proper fix would be to make ceph support the account field
> >
> 
> Is the 'rgw_swift_account_in_url' option not correct/sufficient?
> 

I didn't see that option, I'll test and get back to you on it.

> > * Workaround would be to specify an old swiftclient to install (3.1.0,
> > pre-ocata)
> >
> 
> Doesn't seem great if a sysadmin wants to co-install the newer swiftclient
> cli
> 
> 
> > * Workaround would be to for swiftclient to be forked and 'fixed'
> >
> >
> Not clear to me what the "fix" would be here - just don't do validation?
> I'll assume the "fork threat" here is for completeness/emphasis :D
> 
> Do you know if ironic works with "normal" swift tempurls or only the
> radosgw implementation of the swift api?
> 

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [tc] agenda for upcoming joint leadership meeting in vancouver

[Doug Hellmann]

The last time we had a joint leadership meeting, several TC members
expressed the desire to have more information about what was going
to be covered before the meeting. The agenda for the next meeting
(to be held in Vancouver), is in the wiki at
https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMeeting
(I suggest "watching" that page to keep an eye on updates because
it is still subject to change). The agenda items are a bit terse,
so I thought I would send this email to give my understanding of
what will be discussed. If you have questions or anything to add,
please post a follow up message.

Welcome to new members --  We start with introductions for new
folks, since there are new members of all 3 groups attending. This
is usually just a chance to put a face with a name, but sometimes
we mention employers. Because of the nature of the board, its members
are usually more interested in who employs new board members than
the TC or UC are about our members.

Executive Team Update -- Jonathan, Lauren, Mark, and Thierry will
give updates about the summit and Foundation. We usually learn things
like registration numbers for the event, major themes, etc.

User Committee Update -- Melvin and Matt will talk about the work
the UC has been doing. I don't have any real details about that.

Strategic Discussions -- I put our topic about seeking more
contributors with more time to spend upstream here. It's not entirely
clear this is what Alan had in mind for this section, and since
I've asked for the entire hour this may change.

As I've mentioned a few times in channel, I have been working on
putting hard numbers together to demonstrate that individual
contributors, given time to establish their credibility and actually
do some work, can have a significant positive impact on the community
and the direction of OpenStack. So far, I have a few cases drawn
from contributions to our community goals and help-wanted list to
demonstrate both success and failure to make this point. I hope
that by framing it this way we can move on from the problem statement,
which we have covered a few times in the past, and have a more
fruitful discussion of how to convince engineering managers and
other decision makers to allow developers to contribute in these
ways. I will share the slide deck with everyone after the meeting,
since it may change between now and then.

Updating the Foundation Mission Statement -- I'm not really sure
what this is, beyond what it says.

Preview 2018 event strategy -- I've been told this is a
presentation/discussion led by Lauren to talk about our in-person
events such as the Summit/Forum and PTG.

Next steps for fixing bylaws typo -- This is our second agenda item,
to talk about fixing the obvious error in the appendix to the bylaws
that covers selecting TC members and defines "Active Technical
Contributor" (section 3.b.i of
https://www.openstack.org/legal/technical-committee-member-policy/).

When the bylaws were last modified, this section was changed to say
"An Individual Member is an ATC who has..." meaning that a Foundation
member must be an ATC. Clearly this is not the desired intent, and
the text should read "An ATC is an Individual Member who has...".
We need the Foundation legal folks to help us understand whether
we need a membership vote to fix the wording, or if we can have the
board amend it. The goal for this section of the meeting is to get
someone to make that determination and then for the rest of us to
settle on the next steps we will take to correct the issue.

Doug

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

Re: [openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Clay Gerrard]

On Wed, May 9, 2018 at 12:35 PM, Jim Rollenhagen 
wrote:

>
> It works with both, see the link from earlier in the thread:
> https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546
> f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185
>
>
Ah!  Perfect!  Thanks for point that out (again 😅)

-Clay
__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Jim Rollenhagen]

On Wed, May 9, 2018 at 3:24 PM, Clay Gerrard  wrote:

>
>
> On Wed, May 9, 2018 at 12:08 PM, Matthew Thode 
> wrote:
>
>>
>> * Proper fix would be to make ceph support the account field
>>
>
> Is the 'rgw_swift_account_in_url' option not correct/sufficient?
>

I guess we could just document that people need to use this.


> * Workaround would be to specify an old swiftclient to install (3.1.0,
>> pre-ocata)
>>
>
> Doesn't seem great if a sysadmin wants to co-install the newer swiftclient
> cli
>
>
>> * Workaround would be to for swiftclient to be forked and 'fixed'
>>
>>
> Not clear to me what the "fix" would be here - just don't do validation?
> I'll assume the "fork threat" here is for completeness/emphasis :D
>
> Do you know if ironic works with "normal" swift tempurls or only the
> radosgw implementation of the swift api?
>

It works with both, see the link from earlier in the thread:
https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185

// 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-dev] [tripleo] Migration to Storyboard

[Alex Schultz]

Hello tripleo folks,

So we've been experimenting with migrating some squads over to
storyboard[0] but this seems to be causing more issues than perhaps
it's worth.  Since the upstream community would like to standardize on
Storyboard at some point, I would propose that we do a cut over of all
the tripleo bugs/blueprints from Launchpad to Storyboard.

In the irc meeting this week[1], I asked that the tripleo-ci team make
sure the existing scripts that we use to monitor bugs for CI support
Storyboard.  I would consider this a prerequisite for the migration.
I am thinking it would be beneficial to get this done before or as
close to M2.

Thoughts, concerns, etc?

Thanks,
-Alex

[0] https://storyboard.openstack.org/#!/project_group/76
[1] 
http://eavesdrop.openstack.org/meetings/tripleo/2018/tripleo.2018-05-08-14.00.log.html#l-42

__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Clay Gerrard]

On Wed, May 9, 2018 at 12:08 PM, Matthew Thode 
wrote:

>
> * Proper fix would be to make ceph support the account field
>

Is the 'rgw_swift_account_in_url' option not correct/sufficient?


> * Workaround would be to specify an old swiftclient to install (3.1.0,
> pre-ocata)
>

Doesn't seem great if a sysadmin wants to co-install the newer swiftclient
cli


> * Workaround would be to for swiftclient to be forked and 'fixed'
>
>
Not clear to me what the "fix" would be here - just don't do validation?
I'll assume the "fork threat" here is for completeness/emphasis :D

Do you know if ironic works with "normal" swift tempurls or only the
radosgw implementation of the swift api?

-Clay
__
OpenStack Development Mailing 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][third-party-ci]zKVM (s390x) CI broken

[melanie witt]

On Wed, 9 May 2018 10:28:42 -0700, Melanie Witt wrote:

On Wed, 9 May 2018 13:16:45 +0200, Andreas Scheuring wrote:

The root cause seems to be bug [1]. It’s related to nova cells v2
configuration in devstack. Stephen Finucane already promised to have a
look later the day (thx!!!). I keep the CI running for now...

[1] https://bugs.launchpad.net/devstack/+bug/1770143


Thanks for opening the bug about it. I'm going to investigate it too as
it's related to my recent patch to devstack.


Update: I've proposed a fix for the bug at 
https://review.openstack.org/567298


-melanie




__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Matthew Thode]

On 18-05-09 13:42:02, Jim Rollenhagen wrote:
> On Wed, May 9, 2018 at 11:22 AM, Matthew Thode 
> wrote:
> 
> > python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
> > tempurls.  That is, there was no official support, but it still worked.
> >
> > In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
> > require /v1/account/container/object, which does not work with radosgw
> > as it expects /v1/container/object.  This means that radosgw tempurls
> > fail to work, which further means that radosgw will stop working for
> > things like ironic.
> >
> > I can see the point that swiftclient should not care about ceph not
> > fully implementing the swift spec and not supporting the radosgw url
> > syntax, but it seems like a step back.  If this is not fixed then things
> > like ironic will not work with radosgw for Ocata and above (as that's
> > when this change was made).  We'd need to wait for either ceph to fix
> > this and support the account part of the url (probably just dropping it)
> > or have people fork python-swiftclient to 'fix' it.
> >
> > I'm not sure what the right answer is...
> >
> 
> Sounds like in the meantime ironic should pin python-swiftclient, yes?
> 

That's one solution.  The following three solutions are what I see as
ways forward if swiftclient isn't changed.

* Proper fix would be to make ceph support the account field
* Workaround would be to specify an old swiftclient to install (3.1.0, 
pre-ocata)
* Workaround would be to for swiftclient to be forked and 'fixed'

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [docs][openstack-ansible]

[Jeremy Stanley]

On 2018-05-09 13:13:44 + (+), Alexandra Settle wrote:
[...]
> I have had such a great time being a part of something as exciting
> and new as OpenStack, and I hope to continue to lurk in the
> background of IRC like a total weirdo. I hope to perform some
> super shit karaoke with you all in another part of the world :)
> (who knows, maybe I’ll just tag along to PTG’s as a social outing…
> how cool am I?!)
[...]

Your sheer awesomeness has touched our community in countless ways;
I really hope you do continue to hang out with the rest of us at
every opportunity!
-- 
Jeremy Stanley


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

Re: [openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Jim Rollenhagen]

On Wed, May 9, 2018 at 11:22 AM, Matthew Thode 
wrote:

> python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
> tempurls.  That is, there was no official support, but it still worked.
>
> In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
> require /v1/account/container/object, which does not work with radosgw
> as it expects /v1/container/object.  This means that radosgw tempurls
> fail to work, which further means that radosgw will stop working for
> things like ironic.
>
> I can see the point that swiftclient should not care about ceph not
> fully implementing the swift spec and not supporting the radosgw url
> syntax, but it seems like a step back.  If this is not fixed then things
> like ironic will not work with radosgw for Ocata and above (as that's
> when this change was made).  We'd need to wait for either ceph to fix
> this and support the account part of the url (probably just dropping it)
> or have people fork python-swiftclient to 'fix' it.
>
> I'm not sure what the right answer is...
>

Sounds like in the meantime ironic should pin python-swiftclient, yes?

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

Re: [openstack-dev] [nova][third-party-ci]zKVM (s390x) CI broken

[melanie witt]

On Wed, 9 May 2018 13:16:45 +0200, Andreas Scheuring wrote:
The root cause seems to be bug [1]. It’s related to nova cells v2 
configuration in devstack. Stephen Finucane already promised to have a 
look later the day (thx!!!). I keep the CI running for now...


[1] https://bugs.launchpad.net/devstack/+bug/1770143


Thanks for opening the bug about it. I'm going to investigate it too as 
it's related to my recent patch to devstack.


-melanie

__
OpenStack Development Mailing 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][forum] etherpad for tc retrospective at the forum

[Doug Hellmann]

I have created the etherpad for the TC Retrospective session planned for
Thursday at the Forum. I set up the document structure, but have not
added any substantive content. Please consider the questions in the
etherpad before the session and either add content or be prepared to add
it in the room on Thursday.

https://etherpad.openstack.org/p/YVR-tc-retrospective

Doug

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

[openstack-dev] [all][forum][python3] etherpad for python 2 deprecation timeline forum session

[Doug Hellmann]

I have created the etherpad for the forum session to discuss
deprecating python 2.

https://etherpad.openstack.org/p/YVR-python-2-deprecation-timeline

I pre-populated it with some of the details from the earlier mailing
list thread, but please add any additional notes you have that will
help lay out this timeline.

Doug

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

Re: [openstack-dev] [docs][openstack-ansible]

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2018-05-09 13:13:44 +:
> Hi all,
> 
> It is with a super heavy heart I have to say that I need to step down as core 
> from the OpenStack-Ansible and Documentation teams – and take a step back 
> from the community.
> 
> The last year has taken me in a completely different direction to what I 
> expected, and try as I might I just don’t have the time to be even a 
> part-time member of this great community :(
> 
> Although I’m moving on, and learning new things, nothing can beat the 
> memories of  SnowpenStack and Denver’s super awesome trains.
> 
> I know this isn’t some acceptance speech at the Oscars – but I just want to 
> thank the Foundation and everyone who donates to the travel program. Without 
> you guys, I wouldn’t have been a part of the community as much as I have been 
> and met all your lovely faces.
> 
> I have had such a great time being a part of something as exciting and new as 
> OpenStack, and I hope to continue to lurk in the background of IRC like a 
> total weirdo. I hope to perform some super shit karaoke with you all in 
> another part of the world :) (who knows, maybe I’ll just tag along to PTG’s 
> as a social outing… how cool am I?!)
> 
> I’d also like to thank Mugsie for this sweet shot which is the perfect 
> summary of my time with the OpenStack community. Read into this what you will:
> 
> [cid:image001.jpg@01D3E79F.EFDEF8E0]
> 
> Don’t be a stranger,
> 
> Alex
> 
> IRC: asettle
> Twitter: dewsday
> Email: a.set...@outlook.com

:-(

This is a sad, but not entirely surprising, notice.

Thank you for everything you did to help with the migration last
year.  It would not have been possible to make that work without
your assistance and energy. Our community is better because of your
contributions.

Doug

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

Re: [openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Casey Bodley]

On 05/09/2018 11:22 AM, Matthew Thode wrote:

python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
tempurls.  That is, there was no official support, but it still worked.

In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
require /v1/account/container/object, which does not work with radosgw
as it expects /v1/container/object.  This means that radosgw tempurls
fail to work, which further means that radosgw will stop working for
things like ironic.

I can see the point that swiftclient should not care about ceph not
fully implementing the swift spec and not supporting the radosgw url
syntax, but it seems like a step back.  If this is not fixed then things
like ironic will not work with radosgw for Ocata and above (as that's
when this change was made).  We'd need to wait for either ceph to fix
this and support the account part of the url (probably just dropping it)
or have people fork python-swiftclient to 'fix' it.

I'm not sure what the right answer is...

https://github.com/openstack/python-swiftclient/commit/4c955751d340a8f71a2eebdb3c58d90b36874a66
https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185

https://bugs.launchpad.net/ironic/+bug/1747384



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


Thanks for raising the issue. Radosgw does have a config option 
'rgw_swift_account_in_url' to expect this url format, though it defaults 
to false and I'm not 100% sure that it applies correctly to tempurls.
__
OpenStack Development Mailing 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above

[Matthew Thode]

python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw
tempurls.  That is, there was no official support, but it still worked.

In 3.2.0 (specifically the linked commit(s)) tempurls were validated to
require /v1/account/container/object, which does not work with radosgw
as it expects /v1/container/object.  This means that radosgw tempurls
fail to work, which further means that radosgw will stop working for
things like ironic.

I can see the point that swiftclient should not care about ceph not
fully implementing the swift spec and not supporting the radosgw url
syntax, but it seems like a step back.  If this is not fixed then things
like ironic will not work with radosgw for Ocata and above (as that's
when this change was made).  We'd need to wait for either ceph to fix
this and support the account part of the url (probably just dropping it)
or have people fork python-swiftclient to 'fix' it.

I'm not sure what the right answer is...

https://github.com/openstack/python-swiftclient/commit/4c955751d340a8f71a2eebdb3c58d90b36874a66
https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185

https://bugs.launchpad.net/ironic/+bug/1747384

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [docs][openstack-ansible]

[Andreas Jaeger]

Thanks for your leadership through troubled time!

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


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

Re: [openstack-dev] [docs][openstack-ansible]

[Markos Chandras]

On 09/05/18 14:13, Alexandra Settle wrote:
> Hi all,
> 
>  
> 
> It is with a super heavy heart I have to say that I need to step down as
> core from the OpenStack-Ansible and Documentation teams – and take a
> step back from the community.

I am sorry to see you go Alex. Thank you for all your work in the OSA
world :) I hope you have fun on your next adventure!

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

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

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

[Markos Chandras]

On 03/05/18 09:13, Andy McCrae wrote:
> 
> 
> I will gladly pick up my well-used meeting chair hat.
> It's a great idea, I think it would help make our meetings more productive.
> Once you've been chair you have a different view of how the meetings work.
> 
> Andy

I too think this is a great idea

+1

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

__
OpenStack Development Mailing 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] Vancouver Forum Etherpad List

[Sean McGinnis]

We are now less than two weeks away from the next Summit/Forum in Vancouver.
Hopefully teams are able to spend some time preparing for their Forum sessions
to make them productive.

I have updated the Forum wiki page to start collecting links to session
etherpads:

https://wiki.openstack.org/wiki/Forum/Vancouver2018

Please update this page with your etherpads as they are ready to make this one
easy place to go to for all sessions. I have started populating some sessions
so there is a start, but there are many that still need to be filled in.

Looking forward to another week in Vancouver.

Thanks!
Sean


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

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

[Mohammed Naser]

Hey Gerard,

Replies in-line!

Thanks,
Mohammed

On Fri, May 4, 2018 at 6:25 PM, gerard.d...@wipro.com
 wrote:
> Many thanks for the welcome ;)
>
> And many thanks for the speedy and very useful response !
>
> Details below.
>
> Best regards,
> Gerard
>
>
> 
> For add_gateway_to_router():
>
> So I tried this:
> external_network = conn.network.find_network(EXTERNAL_NETWORK_NAME)
> network_dict_body = {'network_id' : external_network.id}
> conn.network.add_gateway_to_router(onap_router, **network_dict_body)
>
> ==> no errors, but the router is not updated (no gateway is set)
> (external_gateway_info is still None)
>
> (same with conn.network.add_gateway_to_router(onap_router, 
> network_id=external_network.id) )
>
> Is the body parameter for add_gateway_to_router() expected to correspond to a 
> Network ?
> (from a router point of view, a "gateway" is an external network)
>
> Should the network's subnet(s) be also specified in the dictionary ? Maybe 
> only
> if certain specific subnets are desired for the gateway role. Otherwise,
> the default would apply: there is usually only 1 subnet, and that's the one
> to be used. So network_id would be enough to specify a gateway used in a 
> standard way.
>
> Maybe more details about what is expected in this body dictionary should be 
> documented
> in the add_gateway_to_router() section?
>
> In Horizon, when selecting a router, and selecting "Set Gateway", the user is 
> only
> asked to pick an external network from a dropdown list. Then, a router 
> interface is
> implicitly created, with an IP@ picked from the subnet of that network.

Have you reviewed the API reference regarding to this?  OpenStack SDK
really just pushes
the data straight through to the API in this case.

>
> 
> For router deletion: it looks like it's the "!= None" test on the returned 
> object that has an issue
>
> onap_router  = conn.network.find_router(ONAP_ROUTER_NAME)
> if onap_router != None:
> print('Deleting ONAP router...')
> conn.network.delete_router(onap_router.id)
> else:
> print('No ONAP router found...')
>
> I added traceback printouts in the code.
>
> printing the router before trying to delete it:
>  onap_router:
>  openstack.network.v2.router.Router(updated_at=2018-05-04T21:07:23Z, 
> description=Router created for ONAP, status=ACTIVE, ha=False, 
> name=ONAP_router, created_at=2018-05-04T21:07:20Z, 
> tenant_id=03aa47d3bcfd48199e0470b1c86a7f5b, availability_zone_hints=[], 
> admin_state_up=True, availability_zones=['nova'], tags=[], revision=3, 
> routes=[], id=675abd14-096a-4b28-b764-31ca7098913b, 
> external_gateway_info=None, distributed=False, flavor_id=None)
>
>
> *** Exception:  'NoneType' object has no attribute 
> '_body'
> *** traceback.print_tb():
>   File "auto_script_config_openstack_for_onap.py", line 141, in 
> delete_all_ONAP
> if onap_router != None:
>   File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
> 358, in __eq__
> return all([self._body.attributes == comparand._body.attributes,
> *** traceback.print_exception():
> Traceback (most recent call last):
>   File "auto_script_config_openstack_for_onap.py", line 141, in 
> delete_all_ONAP
> if onap_router != None:
>   File "/usr/local/lib/python3.5/dist-packages/openstack/resource.py", line 
> 358, in __eq__
> return all([self._body.attributes == comparand._body.attributes,
> AttributeError: 'NoneType' object has no attribute '_body'
>

This looks like a bug to me, I've pushed up a fix here which you can
follow: https://review.openstack.org/567230

>
> 
> For identity_api_version=3 :
>
> yes, that worked !
>
> Could that identity_api_version parameter also/instead be specified in the 
> clouds.yaml file ?
>

Yes, you can do that, your file would look something like this:

https://github.com/openstack/openstack-ansible-openstack_openrc/blob/master/templates/clouds.yaml.j2

This is a templated file but you can see how you can add
"identity_api_version" in there (note: it's not in the same level as
"auth")

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

Re: [openstack-dev] [docs][openstack-ansible]

[Jesse Pretorius]

From: Alexandra Settle 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, May 9, 2018 at 2:18 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [docs][openstack-ansible]


  *   It is with a super heavy heart I have to say that I need to step down as 
core from the OpenStack-Ansible and Documentation teams – and take a step back 
from the community.

It was fantastic, and even entertaining, working with you! Your value to 
OpenStack-Ansible’s documentation improvement was unparalleled – I thank you 
for your support during that time and after when you did a great job shaking 
things up as the docs PTL. ☺ I wish you the best for your next journey and hope 
it’s filled with more laughter and good times.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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] [FEMDC] IRC meeting postponed to next Wednesday

[lebre . adrien]

Dear all, 

Neither Paul-Andre nor me can chair the meeting today so we propose to postpone 
it for one week. 
The agenda will be delivered soon but you can consider that next meeting will 
focus on the preparation of the Vancouver summit (presentations, F2F 
meetings...). 

Best regards, 
ad_ri3n_

__
OpenStack Development Mailing 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] [placement] cinder + placement forum session etherpad

[Chris Dent]

I've started an etherpad for the forum session in Vancouver devoted
to discussing the possibility of tracking and allocation resources
in Cinder using the Placement service. This is not a done deal.
Instead the session is to discuss if it could work and how to make
it happen if it seems like a good idea.

The etherpad is at

https://etherpad.openstack.org/p/YVR-cinder-placement

but there's not a great deal there yet. Notably there's no
description of how scheduling and resource tracking currently works
in Cinder because I have no experience with that.

This session is mostly for exploring and sharing information so the
value of the etherpad may mostly be in the notes we take at the
session, but anything we write in advance will help keep things a
bit more structured and focused.

If this is a topic of interest for you please add some notes to the
etherpad, or if you prefer, here.

Thanks.

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

[openstack-dev] [nova] [placement] placement extraction session at forum

[Chris Dent]

I've started an etherpad related to the Vancouver Forum session on
extracting placement from nova. It's mostly just an outline for
now but is evolving:

https://etherpad.openstack.org/p/YVR-placement-extraction

If we can get some real information in there before the session we
are much more likely to have a productive session. Please feel free
to add any notes or questions you have there. Or on this thread if
you prefer.

The (potentially overly-optimistic) hope is that we can complete any
prepatory work before the end of Rocky and then do the extraction in
Stein. If we are willing to accept (please, let's) some form of
control plane downtime data migration issues can be vastly eased.
Getting agreement on how that might work is one of the goals of the
session.

Your input very appreciated.

--
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] [nova][third-party-ci]zKVM (s390x) CI broken

[Andreas Scheuring]

The root cause seems to be bug [1]. It’s related to nova cells v2 configuration 
in devstack. Stephen Finucane already promised to have a look later the day 
(thx!!!). I keep the CI running for now...

[1] https://bugs.launchpad.net/devstack/+bug/1770143

---
Andreas Scheuring (andreas_s)



On 9. May 2018, at 11:15, Andreas Scheuring  wrote:

Hi all, the nova CI for zKVM is currently broken - need to investigate. It 
seems like the vnc console gets configured for some reason (vnc is not 
supported on s390x)...

---
Andreas Scheuring (andreas_s)



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

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

[openstack-dev] [nova][third-party-ci]zKVM (s390x) CI broken

[Andreas Scheuring]

Hi all, the nova CI for zKVM is currently broken - need to investigate. It 
seems like the vnc console gets configured for some reason (vnc is not 
supported on s390x)...

---
Andreas Scheuring (andreas_s)



__
OpenStack Development Mailing 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] CI Squads’ Sprint 12 Summary: libvirt-reproducer, python-tempestconf

[Bogdan Dobrelya]

On 5/9/18 4:24 AM, Matt Young wrote:

Greetings,

The TripleO squads for CI and Tempest have just completed Sprint 12.  
The following is a summary of activities during this sprint.   Details 
on our team structure can be found in the spec [1].


---

# Sprint 12 Epic (CI): Libvirt Reproducer

* Epic Card: https://trello.com/c/JEGLSVh6/51-reproduce-ci-jobs-with-libvirt
* Tasks: http://ow.ly/O1vZ30jTSc3

"Allow developers to reproduce a multinode CI job on a bare metal host 
using libvirt"
"Enable the same workflows used in upstream CI / reproducer using 
libvirt instead of OVB as the provisioning mechanism"


The CI Squad prototyped, designed, and implemented new functionality for 
our CI reproducer.   “Reproducers” are scripts generated by each CI job 
that allow the job/test to be recreated.  These are useful to both CI 
team members when investigating failures, as well as developers creating 
failures with the intent to iteratively debug and/or fix issues.  Prior 
to this sprint, the reproducer scripts supported reproduction of 
upstream CI jobs using OVB, typically on RDO Cloud.  This sprint we 
extended this capability to support reproduction of jobs in libvirt.


This work was done for a few reasons:

* (short term) enable the team to work on upgrades and other CI team 
tasks more efficiently by mitigating recurring RDO Cloud infrastructure 
issues.  This was the primary motivator for doing this work at this time.
* (mid-longer term) enhance / enable iterative workflows such as THT 
development, debugging deployment scenarios, etc.  Snapshots in 
particular have proven quite useful.  As we look towards a future with a 
viable single-node deployment capability, libvirt has clear benefits for 
common developer scenarios.


Thank you for that, a really cool feature for tripleo development!



It is expected that further iteration and refinement of this initial 
implementation will be required before the tripleo-ci team is able to 
support this broadly.  What we’ve done works as designed.  While we 
welcome folks to explore, please note that we are not announcing a 
supported libvirt reproducer meant for use outside the tripleo-ci team 
at this time.  We expect some degree of change, and have a number of 
RFE’s resulting from our testing as well as documentation patches that 
we’re iterating on.


That said, we think it’s really cool, works well in its current form, 
and are optimistic about its future.


## We did the following (CI):

* Add support to the reproducer script [2,3] generated by CI to enable 
libvirt.

* Basic snapshot create/restore [4] capability.
* Tested Scenarios: featureset 3 (UC idem), 10 (multinode containers), 
37 (min OC + minor update).  See sprint cards for details.
* 14-18 RFE’s identified as part of testing for future work 
http://ow.ly/J2u830jTSLG


---

# Sprint 12 Epic (Tempest):

* Epic Card: https://trello.com/c/ifIYQsxs/75-sprint-12-undercloud-tempest
* Tasks: http://ow.ly/GGvc30jTSfV

“Run tempest on undercloud by using containerized and packaged tempest”
“Complete work items carried from sprint 11 or another side work going on.”

## We did the following (Tempest):

* Create tripleo-ci jobs that run containerized tempest on all stable 
branches.
* Create documentation for configuring and running tempest using 
containerized tempest on UC @tripleo.org , and blog 
posts. [5,6,7]

* Run certification tests via new Jenkins job using ansible role [8]
* Refactor validate-tempest CI role for UC and containers

---

# Ruck and Rover

Each sprint two of the team members assume the roles of Ruck and Rover 
(each for half of the sprint).


* Ruck is responsible to monitoring the CI, checking for failures, 
opening bugs, participate on meetings, and this is your focal point to 
any CI issues.
* Rover is responsible to work on these bugs, fix problems and the rest 
of the team are focused on the sprint. For more information about our 
structure, check [1]


## Ruck & Rover (Sprint 12), Etherpad [9,10]:

* Quique Llorente(quiquell)
* Gabriele Cerami (panda)

A few notable issues where substantial time was spent were:

1767099 
periodic-tripleo-ci-centos-7-multinode-1ctlr-featureset030-master vxlan 
tunnel fails randomly

1758899 reproducer-quickstart.sh building wrong gating package.
1767343 gate tripleo-ci-centos-7-containers-multinode fails to update 
packages in cron container
1762351 
periodic-tripleo-ci-centos-7-ovb-1ctlr_1comp-featureset002-queens-upload 
is timeout Depends on https://bugzilla.redhat.com/show_bug.cgi?id=1565179

1766873 quickstart on ovb doesn't yield a deployment
1767049 Error during test discovery : 'must specify exactly one of host 
or intercept' Depends on https://bugzilla.redhat.com/show_bug.cgi?id=1434385
1767076 Creating pingtest_sack fails: Failed to schedule instances: 
NoValidHost_Remote: No valid host was found

1763634 devmode.sh --ovb fails to deploy overcloud
1765680 Incorrect branch used for not gated tripleo-upgrade repo

If

Re: [openstack-dev] [neutron][ml2 plugin] unit test errors

[Sangho Shin]

I just manually installed neutron in .tox folder (I am not sure if this is a 
correct way to fix the problem) and run tox tests again.
And.. All tests passed.. as below..

But, I am not sure why Zuul tests fails as in my first email. :-(

Thank you,

Sangho

Tox tests success log in my local environment…
---

ubuntu@sangho-sona-pike-1:~/networking-onos$ tox -epy27 -vv
  removing /home/ubuntu/networking-onos/.tox/log
using tox.ini: /home/ubuntu/networking-onos/tox.ini
using tox-2.3.1 from /usr/lib/python3/dist-packages/tox/__init__.py
skipping sdist step
py27 start: getenv /home/ubuntu/networking-onos/.tox/py27
py27 reusing: /home/ubuntu/networking-onos/.tox/py27
py27 finish: getenv after 0.09 seconds
py27 start: developpkg /home/ubuntu/networking-onos
  /home/ubuntu/networking-onos$ 
/home/ubuntu/networking-onos/.tox/py27/bin/python 
/home/ubuntu/networking-onos/setup.py --name
py27 develop-inst-nodeps: /home/ubuntu/networking-onos
setting 
PATH=/home/ubuntu/networking-onos/.tox/py27/bin:/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
  /home/ubuntu/networking-onos$ 
/home/ubuntu/networking-onos/tools/tox_install.sh 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
 --no-deps -e /home/ubuntu/networking-onos 
>/home/ubuntu/networking-onos/.tox/py27/log/py27-4.log
py27 finish: developpkg after 10.28 seconds
py27 start: envreport
setting 
PATH=/home/ubuntu/networking-onos/.tox/py27/bin:/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
  /home/ubuntu/networking-onos$ /home/ubuntu/networking-onos/.tox/py27/bin/pip 
freeze >/home/ubuntu/networking-onos/.tox/py27/log/py27-5.log
py27 installed: 
alabaster==0.7.10,alembic==0.9.9,amqp==2.2.2,appdirs==1.4.3,asn1crypto==0.24.0,Babel==2.5.3,bcrypt==3.1.4,beautifulsoup4==4.6.0,cachetools==2.0.1,certifi==2018.4.16,cffi==1.11.5,chardet==3.0.4,cliff==2.11.0,cmd2==0.8.5,contextlib2==0.5.5,coverage==4.5.1,cryptography==2.2.2,debtcollector==1.19.0,decorator==4.3.0,deprecation==2.0.2,doc8==0.8.0,docutils==0.14,dogpile.cache==0.6.5,dulwich==0.19.2,enum-compat==0.0.2,enum34==1.1.6,eventlet==0.20.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,funcsigs==1.0.2,functools32==3.2.3.post2,future==0.16.0,futures==3.2.0,futurist==1.7.0,greenlet==0.4.13,hacking==0.12.0,httplib2==0.11.3,idna==2.6,imagesize==1.0.0,ipaddress==1.0.22,iso8601==0.1.12,Jinja2==2.10,jmespath==0.9.3,jsonpatch==1.23,jsonpointer==2.0,jsonschema==2.6.0,keystoneauth1==3.5.0,keystonemiddleware==5.0.0,kombu==4.1.0,linecache2==1.0.0,logutils==0.3.5,Mako==1.0.7,MarkupSafe==1.0,mccabe==0.2.1,mock==2.0.0,monotonic==1.4,mox3==0.25.0,msgpack==0.5.6,munch==2.3.1,netaddr==0.7.19,netifaces==0.10.6,-e
 
git+ssh://sanghos...@review.openstack.org:29418/openstack/networking-onos@678eaaf9c917b7037a426eaadecc252a07fdd47b#egg=networking_onos,-e
 
git+https://git.openstack.org/openstack/networking-sfc@379fcd5cfcb7a71e7dbbe969da0255bc3ff09a33#egg=networking_sfc,-e
 
git+ssh://sanghos...@review.openstack.org:29418/openstack/networking-onos@678eaaf9c917b7037a426eaadecc252a07fdd47b#egg=neutron&subdirectory=.tox/py27/lib/python2.7/site-packages,neutron-lib==1.14.0,openstacksdk==0.13.0,os-client-config==1.31.1,os-service-types==1.2.0,os-testr==1.0.0,os-xenapi==0.3.3,osc-lib==1.10.0,oslo.cache==1.30.1,oslo.concurrency==3.27.0,oslo.config==6.2.0,oslo.context==2.20.0,oslo.db==4.38.0,oslo.i18n==3.20.0,oslo.log==3.38.1,oslo.messaging==6.2.0,oslo.middleware==3.35.0,oslo.policy==1.35.0,oslo.privsep==1.29.0,oslo.reports==1.28.0,oslo.rootwrap==5.14.0,oslo.serialization==2.25.0,oslo.service==1.31.1,oslo.utils==3.36.1,oslo.versionedobjects==1.33.1,oslosphinx==4.18.0,oslotest==3.4.2,osprofiler==2.0.0,ovs==2.9.0,ovsdbapp==0.10.0,packaging==17.1,paramiko==2.4.1,Paste==2.0.3,PasteDeploy==1.5.2,pbr==4.0.2,pecan==1.3.2,pep8==1.5.7,pkg-resources==0.0.0,prettytable==0.7.2,psutil==5.4.5,pyasn1==0.4.2,pycadf==2.7.0,pycparser==2.18,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,PyNaCl==1.2.1,pyparsing==2.2.0,pyperclip==1.6.0,pyroute2==0.5.0,python-dateutil==2.7.2,python-designateclient==2.9.0,python-editor==1.0.3,python-keystoneclient==3.16.0,python-mimeparse==1.6.0,python-neutronclient==6.8.0,python-novaclient==10.2.0,python-subunit==1.3.0,pytz==2018.4,PyYAML==3.12,reno==2.9.1,repoze.lru==0.7,requests==2.18.4,requestsexceptions==1.4.0,restructuredtext-lint==1.1.3,rfc3986==1.1.0,Routes==2.4.1,ryu==4.24,simplejson==3.14.0,singledispatch==3.4.0.3,six==1.11.0,snowballstemmer==1.2.1,Sphinx==1.6.5,sphinxcontrib-websupport==1.0.1,SQLAlchemy==1.2.7,sqlalchemy-migrate==0.11.0,sqlparse==0.2.4,statsd==3.2.2,stestr==2.0.0,stevedore==1.28.0,subprocess32==3.2.7,Tempita==0.5.2,tenacity==4.11.0,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.3.0,tinyrpc==0.8,traceback2==1.4.0

Re: [openstack-dev] [neutron][ml2 plugin] unit test errors

[Andreas Scheuring]

neutron.plugins.ml2.driver_api got moved to neutron-lib. You probably need to 
update the networking-onos code and fix all imports there and push the 
changes...


---
Andreas Scheuring (andreas_s)



On 9. May 2018, at 10:00, Sangho Shin  wrote:

Hello, 

I am getting the following unit test error in Zuul test. See below.
The error is caused only in the pike version, and in stable/ocata version, I do 
not have the error.
( If you can give me any clue, it would be very helpful )

BTW, in nosetests, there is no error.
However, in tox -e py27 tests, I am getting different errors like below. 
Actually, it is caused because the tests are using different version of neutron 
library somehow. Actual neutron is installed in /opt/stack/neutron path, and it 
has correct python files such as callbacks and driver api, which are complained 
below.

So, I would like to know how to specify the correct neutron location in tox 
tests.

Thank you,

Sangho


tox -e py27 errors.

-


=
Failures during discovery
=
--- import errors ---
Failed to import test module: networking_onos.tests.unit.extensions.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/extensions/test_driver.py", line 25, in 

import networking_onos.extensions.securitygroup as onos_sg_driver
  File "networking_onos/extensions/securitygroup.py", line 21, in 
from networking_onos.extensions import callback
  File "networking_onos/extensions/callback.py", line 15, in 
from neutron.callbacks import events
ImportError: No module named callbacks

Failed to import test module: networking_onos.tests.unit.plugins.ml2.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/plugins/ml2/test_driver.py", line 24, in 

from neutron.plugins.ml2 import driver_api as api
ImportError: cannot import name driver_api






Zuul errors.

---

Traceback (most recent call last):
2018-05-09 05:12:30.077594 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py
 
",
 line 1182, in _execute_context
2018-05-09 05:12:30.077653 

 | ubuntu-xenial | context)
2018-05-09 05:12:30.077964 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py
 
",
 line 470, in do_execute
2018-05-09 05:12:30.078065 

 | ubuntu-xenial | cursor.execute(statement, parameters)
2018-05-09 05:12:30.078210 

 | ubuntu-xenial | InterfaceError: Error binding parameter 0 - probably 
unsupported type.
2018-05-09 05:12:30.078282 

 | ubuntu-xenial | update failed: No details.
2018-05-09 05:12:30.078367 

 | ubuntu-xenial | Traceback (most recent call last):
2018-05-09 05:12:30.078683 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/neutron/api/v2/resource.py
 

[openstack-dev] [neutron][ml2 plugin] unit test errors

[Sangho Shin]

Hello, 

I am getting the following unit test error in Zuul test. See below.
The error is caused only in the pike version, and in stable/ocata version, I do 
not have the error.
( If you can give me any clue, it would be very helpful )

BTW, in nosetests, there is no error.
However, in tox -e py27 tests, I am getting different errors like below. 
Actually, it is caused because the tests are using different version of neutron 
library somehow. Actual neutron is installed in /opt/stack/neutron path, and it 
has correct python files such as callbacks and driver api, which are complained 
below.

So, I would like to know how to specify the correct neutron location in tox 
tests.

Thank you,

Sangho


tox -e py27 errors.

-


=
Failures during discovery
=
--- import errors ---
Failed to import test module: networking_onos.tests.unit.extensions.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/extensions/test_driver.py", line 25, in 

import networking_onos.extensions.securitygroup as onos_sg_driver
  File "networking_onos/extensions/securitygroup.py", line 21, in 
from networking_onos.extensions import callback
  File "networking_onos/extensions/callback.py", line 15, in 
from neutron.callbacks import events
ImportError: No module named callbacks

Failed to import test module: networking_onos.tests.unit.plugins.ml2.test_driver
Traceback (most recent call last):
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
module = self._get_module_from_name(name)
  File 
"/opt/stack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
__import__(name)
  File "networking_onos/tests/unit/plugins/ml2/test_driver.py", line 24, in 

from neutron.plugins.ml2 import driver_api as api
ImportError: cannot import name driver_api






Zuul errors.

---

Traceback (most recent call last):
2018-05-09 05:12:30.077594 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1182, in _execute_context
2018-05-09 05:12:30.077653 

 | ubuntu-xenial | context)
2018-05-09 05:12:30.077964 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
 line 470, in do_execute
2018-05-09 05:12:30.078065 

 | ubuntu-xenial | cursor.execute(statement, parameters)
2018-05-09 05:12:30.078210 

 | ubuntu-xenial | InterfaceError: Error binding parameter 0 - probably 
unsupported type.
2018-05-09 05:12:30.078282 

 | ubuntu-xenial | update failed: No details.
2018-05-09 05:12:30.078367 

 | ubuntu-xenial | Traceback (most recent call last):
2018-05-09 05:12:30.078683 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/neutron/api/v2/resource.py",
 line 98, in resource
2018-05-09 05:12:30.078791 

 | ubuntu-xenial | result = method(request=request, **args)
2018-05-09 05:12:30.079085 

 | ubuntu-xenial |   File 
"/home/zuul/src/git.openstack.org/openstack/networking-onos/.tox/py27/local/lib/python2.7/site-packages/neutron/api/v2/base.py",
 line 615, in updat

[openstack-dev] [blazar][placement][nova] Placement support in Blazar

[Hiroaki Kobayashi]

Hello,

As we discussed at past summits and PTGs, Blazar plans to use Placement API for 
modernizing it's implementation.

Based on the ideas teams shared, the Blazar team has discussed possible 
approaches and listed them down here:


We want to make a consensus on the basic approach with the Placement team 
before we start detailed design because it highly depends on the Placement 
roadmap.

It would be a great help if Placement team could see the etherpad and give us 
feedback!

Thanks,
Hiroaki


__
OpenStack Development Mailing 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] [watcher] meeting today

[Чадин Александр]

Watcher team,

We have a meeting today on #openstack-meeting-alt channel at 08:00 UTC


Alex

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