Re: [openstack-dev] Help still needed at FOSDEM!

[Mary Thengvall]

Boris -

It's a fairly low commitment. It's just for an hour, standing at the
OpenStack booth, answering questions that tend to be at a very basic level
(e.g. What's OpenStack?).

You can sign up for a slot via the etherpad here:
https://etherpad.openstack.org/p/fosdem-2018

Best,
-m.
__
OpenStack Development Mailing 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][requirements] A freeze is coming and you should be prepared

[Matthew Thode]

On 18-01-26 00:12:38, Matthew Thode wrote:
> On 18-01-24 22:32:27, Matthew Thode wrote:
> > On 18-01-24 01:29:47, Matthew Thode wrote:
> > > On 18-01-23 01:23:50, Matthew Thode wrote:
> > > > Requirements is freezing Friday at 23:59:59 UTC so any last
> > > > global-requrements updates that need to get in need to get in now.
> > > > 
> > > > I'm afraid that my condition has left me cold to your pleas of mercy.
> > > > 
> > > 
> > > Just your daily reminder that the freeze will happen in about 3 days
> > > time.  Reviews seem to be winding down for requirements now (which is
> > > a good sign this release will be chilled to perfection).
> > > 
> > 
> > There's still a couple of things that may cause bumps for iso8601 and
> > oslo.versionedobjects but those are the main things.  The msgpack change
> > is also rolling out (thanks dirk :D).  Even with all these changes
> > though, in this universe, there's only one absolute. Everything freezes!
> > 
> > https://review.openstack.org/535520 (oslo.serialization)
> > 
> 
> Last day, gate is sad and behind, but not my fault you waited til the
> last minute :P  (see my first comment).  The Iceman Cometh!
> 

All right everyone, Chill.  Looks like we have another couple days to
get stuff in for gate's slowness.  The new deadline is 23:59:59 UTC
29-01-2018.

-- 
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] [blazar][release] we need a new blazar client release

[Masahito MUROI]

Hi Doug,

Thanks for the info and fixes. I pushed a patch for blazar client 1.0.1 
release[1].


1. https://review.openstack.org/538368

best regards,
Masahito

On 2018/01/27 6:44, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2018-01-26 16:41:23 -0500:

The PyPI service is now validating package metadata more strictly, and
the classifier values for python-blazarclient do not pass the validation
checks. This means the 1.0.0 package we built cannot be uploaded to
PyPI [1].

The fix will take several steps.

1. dmsimard has proposed [2] to master to fix the classifiers.

2. However, since the repository has
already been branched for queens we will also need to backport
that fix to stable/queens.  David has proposed that backport in
[3].

3. There are 2 other patches in stable/queens that need to be
approved as well [4].

4. After they are all merged we can release 1.0.1 from the stable/queens
branch using the SHA for the merge commit created when [3] lands.

So, blazar team, please approve all of those patches and then propose a
new 1.0.1 release quickly.

Doug

[1] 
http://logs.openstack.org/1d/1d46185bf1e0c18f69038adedd37cf6f6eaf06ab/release/release-openstack-python/13aa058/ara/result/26cee65c-b3cd-4267-9a03-1fe45be043d4/
[2] https://review.openstack.org/538340 Remove commas in setup.cfg package 
classifiers
[3] https://review.openstack.org/538343
[4] 
https://review.openstack.org/#/q/status:open+project:openstack/python-blazarclient+branch:stable/queens


In order to speed things along, I'm going to go ahead and use my release
manager ACLs to approve those stable branch changes. So please approve
the one on master so your next release there won't have the same 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






__
OpenStack Development Mailing 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] [congress][requirements][RFE] adding tenacity to congress requirements

[Eric K]

Looking to add tenacity to congress requirements because it's needed by a
forthcoming bug fix. No change to requirements repo. Does this need an
exception? Thanks a lot!

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

Eric Kao



__
OpenStack Development Mailing 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] Vancouver Summit CFP is open - what’s new

[Jimmy McArthur]

We will reach out to PTLs directly to solicit Protect Updates. 

Thanks!!
Jimmy McArthur 
512.965.4846


> On Jan 26, 2018, at 6:07 PM, Matt Riedemann  wrote:
> 
>> On 1/12/2018 2:59 PM, Lauren Sell wrote:
>> Hi everyone,
>> Today, we opened the Call for Presentations 
>> for 
>> the Vancouver Summit , 
>> which will take place May 21-24. The deadline to submit your proposal is 
>> February 8th.
>> What’s New?
>> We’re focused on open infrastructure integration. The Summit has evolved 
>> over the years to cover more than just OpenStack, but we’re making an even 
>> bigger effort to attract speakers across the open infrastructure ecosystem. 
>> In addition to OpenStack-related sessions, we’ll be featuring the newest 
>> project at the Foundation -- Kata Containers -- as well as recruiting many 
>> others from projects like Ansible, Ceph, Kubernetes, ONAP and many more.
>> We’ve also organized Tracks around specific problem domains. We encourage 
>> you to submit proposals covering OpenStack and the “open infrastructure” 
>> tools you’re using, as well as the integration work needed to address these 
>> problem domains. We also encourage you to invite peers from other open 
>> source communities to come speak and collaborate.
>> The Tracks are:
>>  *
>>CI/CD
>>  *
>>Container Infrastructure
>>  *
>>Edge Computing
>>  *
>>HPC / GPU / AI
>>  *
>>Open Source Community
>>  *
>>Private & Hybrid Cloud
>>  *
>>Public Cloud
>>  *
>>Telecom & NFV
>> Where previously we had Track Chairs, we now have Programming Committees 
>> for
>>  each Track, made up of both Members and a Chair (or co-chairs). We’re also 
>> recruiting members and chairs from many different open source communities 
>> working in open infrastructure, in addition to the many familiar faces in 
>> the OpenStack community who will lead the effort. If you’re interested in 
>> nominating yourself or someone else to be a member of the Summit Programming 
>> Committee for a specific Track, please fill out the nomination form 
>> .
>>  Nominations will close on January 26, 2018.
>> Again, the deadline to submit proposals 
>> is 
>> February 8, 2018. Please note topic submissions for the OpenStack Forum 
>> (planning/working sessions with OpenStack devs and operators) will open at a 
>> later date.
>> We can’t wait to see you in Vancouver! We’re working hard to make it the 
>> best Summit yet, and look forward to bringing together different open 
>> infrastructure communities to solve these hard problems together!
>> Want to provide feedback on this process? Please focus discussion on the 
>> openstack-community mailing list, or contact me or the OpenStack Foundation 
>> Summit Team directly at sum...@openstack.org .
>> Thank you,
>> Lauren
> 
> Will there be the usual project updates like in the last few summits, or do 
> we need to specifically submit those as talks now?
> 
> -- 
> 
> Thanks,
> 
> Matt
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[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. 
Sorry about the delay.

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

1. ironicclient version negotiation (deadline: Thu, Jan 25th)
1.1. expose negotiated latest: https://review.openstack.org/531029 MERGED
1.2. accept list of versions: https://review.openstack.org/#/c/531271/ 
MERGED
2. Classic drivers deprecation
2.1. upgrade: https://review.openstack.org/534373 2x+2
3. Traits
3.1. RPC objects https://review.openstack.org/#/c/532268/ MERGED
3.2. RPC API https://review.openstack.org/#/c/535296 MERGED
3.3. API https://review.openstack.org/#/c/532269/ MERGED
3.4. Client https://review.openstack.org/#/c/532622/ MERGED
3.5. API ref https://review.openstack.org/#/c/536384 MERGED
4. Rescue:
4.1. network interface update: https://review.openstack.org/#/c/509342 
MERGED
4.2. rescuewait timeout: https://review.openstack.org/#/c/353156/ MERGED
4.3. Agent rescue implementation: https://review.openstack.org/#/c/400437/ 
APPROVED
4.4. Add API methods for [un]rescue: 
https://review.openstack.org/#/c/350831/ APPROVED
4.5. Client Rescue Provision States https://review.openstack.org/#/c/408341
4.6. Client rescue_interface on node https://review.openstack.org/#/c/517302

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

oneview:
Remove python-oneviewclient from oneview hardware type - 
https://review.openstack.org/#/c/524729/

Subproject priorities
-
bifrost:
(TheJulia): Fedora support fixes -  https://review.openstack.org/#/c/471750/
ironic-inspector (or its client):
(dtantsur) keystoneauth adapters https://review.openstack.org/#/c/515787/ 
MERGED
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/ MERGED

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between  08 Jan 2018 and 15 Jan 2018)
- Ironic: 216 bugs (-3) + 260 wishlist items. 1 new (-1), 156 in progress (-2), 
0 critical, 33 high (-1) and 27 incomplete (-1)
- Inspector: 14 bugs (-1) + 28 wishlist items. 0 new, 10 in progress, 0 
critical, 2 high (-1) and 6 incomplete (+1)
- Nova bugs with Ironic tag: 13. 1 new, 0 critical, 0 high
- via http://dashboard-ironic.7e14.starter-us-west-2.openshiftapps.com/
- the dashboard was abruptly deleted and needs a new home :(
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.
- If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction
- may be fixed as part of https://review.openstack.org/#/c/460564/
- IPA may not find partition created by conductor 
https://bugs.launchpad.net/ironic-lib/+bug/1739421
- Fix proposed: https://review.openstack.org/#/c/529325/

CI refactoring and missing test coverage

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

Re: [openstack-dev] [tc] Technical Committee Status update, January 26th

[Matt Riedemann]

On 1/26/2018 10:26 AM, Thierry Carrez wrote:

NB: mriedem suggested on the ML that we wait until the PTG in Dublin to
make the final call. It gives more time to carefully consider the goals,
but delays the start of the work and makes planning pre-PTG a bit more
difficult.


Sorry. Did anyone talk about goals for Rocky in Sydney? I remember 
talking about goals in Boston, I think for Queens. That worked out 
better since we had a lot more lead time.


--

Thanks,

Matt

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

Re: [openstack-dev] Vancouver Summit CFP is open - what’s new

[Matt Riedemann]

On 1/12/2018 2:59 PM, Lauren Sell wrote:

Hi everyone,

Today, we opened the Call for Presentations 
for 
the Vancouver Summit , 
which will take place May 21-24. The deadline to submit your proposal is 
February 8th.


What’s New?
We’re focused on open infrastructure integration. The Summit has evolved 
over the years to cover more than just OpenStack, but we’re making an 
even bigger effort to attract speakers across the open infrastructure 
ecosystem. In addition to OpenStack-related sessions, we’ll be featuring 
the newest project at the Foundation -- Kata Containers -- as well as 
recruiting many others from projects like Ansible, Ceph, Kubernetes, 
ONAP and many more.


We’ve also organized Tracks around specific problem domains. We 
encourage you to submit proposals covering OpenStack and the “open 
infrastructure” tools you’re using, as well as the integration work 
needed to address these problem domains. We also encourage you to invite 
peers from other open source communities to come speak and collaborate.


The Tracks are:

  *
CI/CD
  *
Container Infrastructure
  *
Edge Computing
  *
HPC / GPU / AI
  *
Open Source Community
  *
Private & Hybrid Cloud
  *
Public Cloud
  *
Telecom & NFV


Where previously we had Track Chairs, we now have Programming Committees 
for 
each Track, made up of both Members and a Chair (or co-chairs). We’re 
also recruiting members and chairs from many different open source 
communities working in open infrastructure, in addition to the many 
familiar faces in the OpenStack community who will lead the effort. If 
you’re interested in nominating yourself or someone else to be a member 
of the Summit Programming Committee for a specific Track, please fill 
out the nomination form 
. 
Nominations will close on January 26, 2018.


Again, the deadline to submit proposals 
is 
February 8, 2018. Please note topic submissions for the OpenStack Forum 
(planning/working sessions with OpenStack devs and operators) will open 
at a later date.


We can’t wait to see you in Vancouver! We’re working hard to make it the 
best Summit yet, and look forward to bringing together different open 
infrastructure communities to solve these hard problems together!


Want to provide feedback on this process? Please focus discussion on the 
openstack-community mailing list, or contact me or the OpenStack 
Foundation Summit Team directly at sum...@openstack.org 
.


Thank you,
Lauren



Will there be the usual project updates like in the last few summits, or 
do we need to specifically submit those as talks now?


--

Thanks,

Matt

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

Re: [openstack-dev] [cliff][osc][barbican][oslo][sdk][all] avoiding option name conflicts with cliff and OSC plugins

[Michael Johnson]

Should be no issues with python-octaviaclient, we do not use the short options.

Michael

On Fri, Jan 26, 2018 at 1:03 PM, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2018-01-18 10:15:16 -0500:
>> We've been working this week to resolve an issue between cliff and
>> barbicanclient due to a collision in the option namespace [0].
>> Barbicanclient was using the -s option, and then cliff's lister
>> command base class added that option as an alias for sort-columns.
>>
>> The first attempt at resolving the conflict was to set the conflict
>> handler in argparse to 'resolve' [1]. Several reviewers pointed out
>> that this would have the unwanted side-effect of making some OSC
>> commands support the -s as an alias for --sort-columns while the
>> barbicanclient commands would use it for a different purpose.
>>
>> For now we have removed the -s alias from within cliff. However,
>> we want to avoid this problem coming up in the future so we want a
>> better solution.
>>
>> The OSC project has a policy that its command plugins do not use
>> short options (single letter). There are relatively few of them,
>> and it's easy to introduce collisions.  Therefore, they are seen
>> as reserved for more common "global" options such as provided by
>> the base classes in OSC and cliff.
>>
>> I propose that for Rocky we update cliff to change the way options
>> are registered so that conflicting options added by command subclasses
>> are ignored. This would effectively let cliff "own" the short option
>> namespace, and require command classes to use long option names.
>>
>> The implementation details need to be worked out a bit, but I think
>> we can do that by subclassing ArgumentParser and adding a new
>> conflict handler method similar to the existing _handle_conflict_error()
>> and _handle_conflict_resolve().
>>
>> This is going to introduce backwards-incompatible changes in the
>> commands derived from cliff, so before we take any action I wanted
>> to solicit input in the plan.
>>
>> Please let me know what you think,
>> Doug
>>
>> [0] https://bugs.launchpad.net/python-barbicanclient/+bug/1743578
>> [1] https://docs.python.org/3.5/library/argparse.html#conflict-handler
>
> I have a patch up to implement this in https://review.openstack.org/538335
>
> 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

Re: [openstack-dev] [requirements] [vitrage][glance][ironic] global requirements update for python-vitrageclient

[Brian Rosmaita]

Sorry for the late reply.  https://review.openstack.org/#/c/537453/
merged a few hours ago and the "can't copy" error should no longer
occur.

On Fri, Jan 26, 2018 at 10:22 AM, Matthew Thode
 wrote:
> On 18-01-26 10:47:38, Mark Goddard wrote:
>> Looks like this should be resolved by
>> https://review.openstack.org/#/c/537453/.
>> Mark
>>
>> On 26 January 2018 at 10:33, Mark Goddard  wrote:
>>
>> > Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient
>> > 2.2.0. These are required in order to use the ironic node traits feature in
>> > nova.
>> >
>> > [1] https://review.openstack.org/#/c/538093
>> > [2] https://review.openstack.org/#/c/538066/3
>> >
>> > On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) <
>> > ifat.a...@nokia.com> wrote:
>> >
>> >> Adding Glance team.
>> >> Any idea what could be wrong?
>> >>
>> >> Thanks,
>> >> Ifat.
>> >>
>> >>
>> >> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <
>> >> ifat.a...@nokia.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I tried to update the version of python-vitrageclient [1], but the
>> >> legacy-requirements-integration-dsvm test failed with an error that does
>> >> not seem related to my changes:
>> >>
>> >> error: can't copy 'etc/glance-image-import.conf': doesn't exist or
>> >> not a regular file
>> >>
>> >> I noticed that two other changes [2][3] failed with the same error.
>> >>
>> >> Can you please help?
>> >>
>> >> Thanks,
>> >> Ifat.
>> >>
>> >>
>> >> [1] https://review.openstack.org/#/c/537307
>> >> [2] https://review.openstack.org/#/c/535460/
>> >> [3] https://review.openstack.org/#/c/536142/
>
> yep, requirements is hard blocked on that atm
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron] q-3 tag and FFE being tracked

[Miguel Lavalle]

This is the patch for VPNaaS:

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

On Fri, Jan 26, 2018 at 1:39 PM, Miguel Lavalle  wrote:

> Hi Neutron Team,
>
> This is our Queens 3 milestone patch:
>
> https://review.openstack.org/#/c/537651/.
>
> Please note that we still have to create a tag for VPNaaS, which recently
> rejoined the Neutron Stadium
>
> We have also created a list that we are targeting for RC1:
>
> https://launchpad.net/neutron/+milestone/queens-rc1
>
> We are going to block master branch to everything that is not in that
> list. If we have left out anything that is critical to land in Queens,
> please reach out to me
>
>
> Cheers
>
> Miguel
>
__
OpenStack Development Mailing 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] [blazar][release] we need a new blazar client release

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-01-26 16:41:23 -0500:
> The PyPI service is now validating package metadata more strictly, and
> the classifier values for python-blazarclient do not pass the validation
> checks. This means the 1.0.0 package we built cannot be uploaded to
> PyPI [1].
> 
> The fix will take several steps.
> 
> 1. dmsimard has proposed [2] to master to fix the classifiers.
> 
> 2. However, since the repository has
>already been branched for queens we will also need to backport
>that fix to stable/queens.  David has proposed that backport in
>[3].
> 
> 3. There are 2 other patches in stable/queens that need to be
>approved as well [4].
> 
> 4. After they are all merged we can release 1.0.1 from the stable/queens
>branch using the SHA for the merge commit created when [3] lands.
> 
> So, blazar team, please approve all of those patches and then propose a
> new 1.0.1 release quickly.
> 
> Doug
> 
> [1] 
> http://logs.openstack.org/1d/1d46185bf1e0c18f69038adedd37cf6f6eaf06ab/release/release-openstack-python/13aa058/ara/result/26cee65c-b3cd-4267-9a03-1fe45be043d4/
> [2] https://review.openstack.org/538340 Remove commas in setup.cfg package 
> classifiers
> [3] https://review.openstack.org/538343
> [4] 
> https://review.openstack.org/#/q/status:open+project:openstack/python-blazarclient+branch:stable/queens

In order to speed things along, I'm going to go ahead and use my release
manager ACLs to approve those stable branch changes. So please approve
the one on master so your next release there won't have the same 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

[openstack-dev] [blazar][release] we need a new blazar client release

[Doug Hellmann]

The PyPI service is now validating package metadata more strictly, and
the classifier values for python-blazarclient do not pass the validation
checks. This means the 1.0.0 package we built cannot be uploaded to
PyPI [1].

The fix will take several steps.

1. dmsimard has proposed [2] to master to fix the classifiers.

2. However, since the repository has
   already been branched for queens we will also need to backport
   that fix to stable/queens.  David has proposed that backport in
   [3].

3. There are 2 other patches in stable/queens that need to be
   approved as well [4].

4. After they are all merged we can release 1.0.1 from the stable/queens
   branch using the SHA for the merge commit created when [3] lands.

So, blazar team, please approve all of those patches and then propose a
new 1.0.1 release quickly.

Doug

[1] 
http://logs.openstack.org/1d/1d46185bf1e0c18f69038adedd37cf6f6eaf06ab/release/release-openstack-python/13aa058/ara/result/26cee65c-b3cd-4267-9a03-1fe45be043d4/
[2] https://review.openstack.org/538340 Remove commas in setup.cfg package 
classifiers
[3] https://review.openstack.org/538343
[4] 
https://review.openstack.org/#/q/status:open+project:openstack/python-blazarclient+branch:stable/queens

__
OpenStack Development Mailing 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] [trove] Retiring the trove-integration repository, final call

[Manoj Kumar]

Initial indication was provided in July last year, that the 
trove-integration repository was going away.
All the elements have been merged into trove, and are being maintained 
there.

I do not believe anyone spoke up then. If anyone is depending on the 
separate repository, do speak up.

Cheers,
- Manoj

__
OpenStack Development Mailing 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] [cliff][osc][barbican][oslo][sdk][all] avoiding option name conflicts with cliff and OSC plugins

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-01-18 10:15:16 -0500:
> We've been working this week to resolve an issue between cliff and
> barbicanclient due to a collision in the option namespace [0].
> Barbicanclient was using the -s option, and then cliff's lister
> command base class added that option as an alias for sort-columns.
> 
> The first attempt at resolving the conflict was to set the conflict
> handler in argparse to 'resolve' [1]. Several reviewers pointed out
> that this would have the unwanted side-effect of making some OSC
> commands support the -s as an alias for --sort-columns while the
> barbicanclient commands would use it for a different purpose.
> 
> For now we have removed the -s alias from within cliff. However,
> we want to avoid this problem coming up in the future so we want a
> better solution.
> 
> The OSC project has a policy that its command plugins do not use
> short options (single letter). There are relatively few of them,
> and it's easy to introduce collisions.  Therefore, they are seen
> as reserved for more common "global" options such as provided by
> the base classes in OSC and cliff.
> 
> I propose that for Rocky we update cliff to change the way options
> are registered so that conflicting options added by command subclasses
> are ignored. This would effectively let cliff "own" the short option
> namespace, and require command classes to use long option names.
> 
> The implementation details need to be worked out a bit, but I think
> we can do that by subclassing ArgumentParser and adding a new
> conflict handler method similar to the existing _handle_conflict_error()
> and _handle_conflict_resolve().
> 
> This is going to introduce backwards-incompatible changes in the
> commands derived from cliff, so before we take any action I wanted
> to solicit input in the plan.
> 
> Please let me know what you think,
> Doug
> 
> [0] https://bugs.launchpad.net/python-barbicanclient/+bug/1743578
> [1] https://docs.python.org/3.5/library/argparse.html#conflict-handler

I have a patch up to implement this in https://review.openstack.org/538335

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] [masakari] BUG in Masakari Installation and Procedure and/or Documentation

[Waines, Greg]

Update on this.

It turned out that i had incorrectly set the ‘project_name’ and ‘username’ in  
/etc/masakarimonitors/masakarimonitors.conf

Setting both these attributes to ‘admin’ made it such that the 
instancemonitor’s notification to masakari-engine was successful.
e.g.
stack@devstack-masakari-louie:~/devstack$ masakari notification-list
+--++-+--+--+
| notification_uuid| generated_time | status  | 
source_host_uuid | type |
+--++-+--+--+
| b8c6c561-7a93-40a2-8d73-3783024865b4 | 2018-01-26T19:41:29.00 | running | 
51bc8b8b-324f-499a-9166-38c22b3842cd | VM   |
+--++-+--+--+
stack@devstack-masakari-louie:~/devstack$


However I now get the following error in masakari-engine, when the 
masakari-engine attempts to do the VM Recovery

Jan 26 19:41:28 devstack-masakari-louie masakari-engine[11795]: 2018-01-26 
19:41:28.968 TRACE masakari.engine.drivers.taskflow.driver EndpointNotFound: 
publicURL endpoint for compute service named Compute Service not found


Why is masakari-engine looking for a publicURL endpoint for 
service_type=’compute’ and service_name=’Compute Service’ ?
See below that the Service Name = ‘nova’ ... NOT ‘Compute Service’

stack@devstack-masakari-louie:~/devstack$ openstack endpoint list
+--+---+--++-+---+--+
| ID   | Region| Service Name | Service Type   
| Enabled | Interface | URL  |
+--+---+--++-+---+--+
| 0111643ef1584decb523524a3db5ce18 | RegionOne | nova_legacy  | compute_legacy 
| True| public| http://10.10.10.14/compute/v2/$(project_id)s |
| 01790448c22f49e69774adf290fba728 | RegionOne | gnocchi  | metric 
| True| internal  | http://10.10.10.14/metric|
| 0b31693c6650499a981d580721be9e48 | RegionOne | vitrage  | rca
| True| internal  | http://10.10.10.14:8999  |
| 40f66ed61b4e4310829aa69e11c75554 | RegionOne | neutron  | network
| True| public| http://10.10.10.14:9696/ |
| 47479cf64af944b996b1fbca42efd945 | RegionOne | nova | compute
| True| public| http://10.10.10.14/compute/v2.1  |
| 49dccfc61e8246a2a2c0b8d12b3db91a | RegionOne | vitrage  | rca
| True| admin | http://10.10.10.14:8999  |
| 5261ba0327de4c2d92842147636ee770 | RegionOne | masakari | ha 
| True| internal  | http://10.10.10.14:15868/v1/$(tenant_id)s|
| 5df28622c6f449ebad12d9b62110cd08 | RegionOne | gnocchi  | metric 
| True| admin | http://10.10.10.14/metric|
| 64f8f401431042a0ab1d053ca4f4df02 | RegionOne | glance   | image  
| True| public| http://10.10.10.14/image |
| 69ad6b9d0b0b4d0a8da6fa36af8289cb | RegionOne | masakari | ha 
| True| public| http://10.10.10.14:15868/v1/$(tenant_id)s|
| 7dd9d5396e9c49d4a41e2865b841f6a0 | RegionOne | masakari | ha 
| True| admin | http://10.10.10.14:15868/v1/$(tenant_id)s|
| 811fa7f4b3c14612b4aca354dc8ea77e | RegionOne | vitrage  | rca
| True| public| http://10.10.10.14:8999  |
| 8535da724c424363bffe1d033ee033e5 | RegionOne | cinder   | volume 
| True| public| http://10.10.10.14/volume/v1/$(project_id)s  |
| 853f1783f1014075a03c16f7c3a2568a | RegionOne | keystone | identity   
| True| admin | http://10.10.10.14/identity  |
| 9450f5611ca747f2a049f22ff0996dba | RegionOne | cinderv3 | volumev3   
| True| public| http://10.10.10.14/volume/v3/$(project_id)s  |
| 9a73696d88a9438cb0ab75a754a08e9d | RegionOne | gnocchi  | metric 
| True| public| http://10.10.10.14/metric|
| b1ff2b4d683c4a58a3b27232699d0058 | RegionOne | cinderv2 | volumev2   
| True| public| http://10.10.10.14/volume/v2/$(project_id)s  |
| d4e66240faff48f2b5e1d0fcfb73a74b | RegionOne | placement| placement  
| True| public| http://10.10.10.14/placement |
| fda917fd368a4a479c9c186df1beb8e9 | RegionOne | keystone | identity   
| True| public| http://10.10.10.14/identity  |

[openstack-dev] [Neutron] q-3 tag and FFE being tracked

[Miguel Lavalle]

Hi Neutron Team,

This is our Queens 3 milestone patch:

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

Please note that we still have to create a tag for VPNaaS, which recently
rejoined the Neutron Stadium

We have also created a list that we are targeting for RC1:

https://launchpad.net/neutron/+milestone/queens-rc1

We are going to block master branch to everything that is not in that list.
If we have left out anything that is critical to land in Queens, please
reach out to me


Cheers

Miguel
__
OpenStack Development Mailing 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][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

[James E. Blair]

Balázs Gibizer  writes:

> Hi,
>
> I'm getting more and more confused how the zuul job hierarchy works or
> is supposed to work.

Hi!

First, you (or others) may or may not have seen this already -- some of
it didn't exist when we first rolled out v3, and some of it has changed
-- but here are the relevant bits of the documentation that should help
explain what's going on.  It helps to understand freezing:

  https://docs.openstack.org/infra/zuul/user/config.html#job

and matching:

  https://docs.openstack.org/infra/zuul/user/config.html#matchers

> First there was a bug in nova that some functional tests are not
> triggered although the job (re-)definition in the nova part of the
> project-config should not prevent it to run [1].
>
> There we figured out that irrelevant-files parameter of the jobs are
> not something that can be overriden during re-definition or through
> parent-child relationship. The base job openstack-tox-functional has
> an irrelevant-files attribute that lists '^doc/.*$' as a path to be
> ignored [2]. In the other hand the nova part of the project-config
> tries to make this ignore less broad by adding only '^doc/source/.*$'
> . This does not work as we expected and the job did not run on changes
> that only affected ./doc/notification_samples path. We are fixing it
> by defining our own functional job in nova tree [4].
>
> [1] https://bugs.launchpad.net/nova/+bug/1742962
> [2]
> https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380
> [3]
> https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509
> [4] https://review.openstack.org/#/c/533210/

This is correct.  The issue here is that the irrelevant-files definition
on openstack-tox-functional is too broad.  We need to be *extremely*
careful applying matchers to jobs like that.  Generally I think that
irrelevant-files should be reserved for the project-pipeline invocations
only.  That's how they were effectively used in Zuul v2, after all.

Essentially, when someone puts an irrelevant-files section on a job like
that, they are saying "this job will never apply to these files, ever."
That's clearly not correct in this case.

So our solutions are to acknowledge that it's over-broad, and reduce or
eliminate the list in [2] and expand it elsewhere (as in [3]).  Or we
can say "we were generally correct, but nova is extra special so it
needs its own job".  If that's the choice, then I think [4] is a fine
solution.

> Then I started looking into other jobs to see if we made similar
> mistakes. I found two other examples in the nova related jobs where
> redefining the irrelevant-files of a job caused problems. In these
> examples nova tried to ignore more paths during the override than what
> was originally ignored in the job definition but that did not work
> [5][6].
>
> [5] https://bugs.launchpad.net/nova/+bug/1745405 (temptest-full)

As noted in that bug, the tempest-full job is invoked on nova via this
stanza:

https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10674-L10688

As expected, that did not match.  There is a second invocation of
tempest-full on nova here:

http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n126

That has no irrelevant-files matches, and so matches everything.  If you
drop the use of that template, it will work as expected.  Or, if you can
say with some certainty that nova's irrelevant-files set is not
over-broad, you could move the irrelevant-files from nova's invocation
into the template, or even the job, and drop nova's individual
invocation.

> [6] https://bugs.launchpad.net/nova/+bug/1745431 (neutron-grenade)

The same template invokes this job as well.

> So far the problem seemed to be consistent (i.e. override does not
> work). But then I looked into neutron-grenade-multinode. That job is
> defined in neutron tree (like neutron-grenade) but nova also refers to
> it in nova section of the project-config with different
> irrelevant-files than their original definition. So I assumed that
> this will lead to similar problem than in case of neutron-grenade, but
> it doesn't.
>
> The neutron-grenade-multinode original definition [1] does not try to
> ignore the 'nova/tests' path but the nova side of the definition in
> the project config does try to ignore that path [8]. Interestingly a
> patch in nova that only changes under the path: nova/tests/ does not
> trigger the job [9]. So in this case overriding the irrelevant-files
> of a job works. (It seems that overriding neutron-tempest-linuxbridge
> irrelevant-files works too).
>
> [7]
> https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159
> [8]
> 

Re: [openstack-dev] [horizon][packaging] django-openstack-auth retirement

[Jeremy Stanley]

On 2018-01-24 08:47:30 -0600 (-0600), Monty Taylor wrote:
[...]
> Horizon and neutron were updated to start publishing to PyPI
> already.
> 
> https://review.openstack.org/#/c/531822/
> 
> This is so that we can start working on unwinding the neutron and
> horizon specific versions of jobs for neutron and horizon plugins.

Nice! I somehow missed that merging a couple of weeks back. In that
case, I suppose we could in theory do one final transitional package
upload of DOA depending on the conflicting Horizon release if others
think that's a good idea.
-- 
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] [infra][all] New Zuul Depends-On syntax

[Jeremy Stanley]

On 2018-01-26 08:57:02 -0800 (-0800), James E. Blair wrote:
[...]
> Perhaps a method of automatically noting the dependencies in git
> notes could help with that case?  Or maybe use a different way of
> communicating that information -- even with change-ids, there's
> still a lot of missing information in that scenario (for instance,
> which changes still haven't merged).

For what it's worth, Git notes for change commits already include
their corresponding Gerrit change URLs so can be found offline that
way regardless (as long as you configure your git client to retrieve
them whenever you retrieve other Git objects, e.g. during a remote
update). Even with a Change-Id you don't have any means of
identifying the containing repository except through brute force
means or online searching, so aside from being tracked in notes
rather than commit messages there's not much else different in the
new model.
-- 
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] [neutron][l3][flavors][floatingip] FFE request for patch no 523257 and 532993

[Miguel Lavalle]

Manjeets,

This FFE has been approved. Tracking it here:
https://launchpad.net/neutron/+milestone/queens-rc1

Cheers

On Thu, Jan 25, 2018 at 12:17 PM, Bhatia, Manjeet S <
manjeet.s.bha...@intel.com> wrote:

> Hello all !
>
>
>
> I’d like to request a FFE for patch 523257 [1] that adds new resources and
> events to handle operations
>
> For routers if L3 flavors framework is used. The neutron-lib part is
> already merged [lib] thanks to Boden and
>
> Miguel for quick reviews on that. The second patch 53993 [2] adds the
> missing notifications for floatingip update
>
> and delete events without which l3 flavor drivers Backends isn’t able to
> perform the update and delete operations
>
> on floatingip’s correctly. These two patches are needed for L3 flavors
> driver in networking-odl [nodll3].
>
>
>
>
>
> [1]. https://review.openstack.org/#/c/523257
>
> [2]. https://review.openstack.org/#/c/532993
>
>
>
> [lib] https://review.openstack.org/#/c/535512/
>
> [nodll3] https://review.openstack.org/#/c/504182/
>
>
>
>
>
> Sorry for 2nd email on this I forgot to add [openstack-dev] subject in
> last one.
>
>
>
>
>
> Thanks and regards !
>
> Manjeet Singh Bhatia
>
>
>
> __
> OpenStack Development Mailing 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] [infra][all] New Zuul Depends-On syntax

[James E. Blair]

Mathieu Gagné  writes:

> On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair  wrote:
>> Mathieu Gagné  writes:
>>
>>> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec  wrote:


 I'm curious what this means as far as best practices for inter-patch
 references.  In the past my understanding was the the change id was
 preferred, both because if gerrit changed its URL format the change id 
 links
 would be updated appropriately, and also because change ids can be looked 
 up
 offline in git commit messages.  Would that still be the case for 
 everything
 except depends-on now?
>>
>> Yes, that's a down-side of URLs.  I personally think it's fine to keep
>> using change-ids for anything other than Depends-On, though in many of
>> those cases the commit sha may work as well.
>>
>>> That's my concern too. Also AFAIK, Change-Id is branch agnostic. This
>>> means you can more easily cherry-pick between branches without having
>>> to change the URL to match the new branch for your dependencies.
>>
>> Yes, there is a positive and negative aspect to this issue.
>>
>> On the one hand, for those times where it was convenient to say "depend
>> on this change in all its forms across all branches of all projects",
>> one must now add a URL for each.
>>
>> On the other hand, with URLs, it is now possible to indicate that a
>> change specifically depends on another change targeted to one branch, or
>> targeted to several branches.  Simply list each URL (or don't) as
>> appropriate.  That wasn't possible before -- it wall all or none.
>>
>> -Jim
>>
>
>> The old syntax will continue to work for a while
>
> I still believe Change-Id should be supported and not removed as
> suggested. The use of URL assumes you have access to Gerrit to fetch
> more information about the change.
> This might not always be true or possible, especially when Gerrit is
> kept private and only the git repository is replicated publicly and
> you which to cherry-pick something (and its dependencies) from it.

Perhaps a method of automatically noting the dependencies in git notes
could help with that case?  Or maybe use a different way of
communicating that information -- even with change-ids, there's still a
lot of missing information in that scenario (for instance, which changes
still haven't merged).

-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] [tc] Technical Committee Status update, January 26th

[Thierry Carrez]

Hi!

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

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

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


== Recently-approved changes ==

* Update Python PTI for tests to be specific and explicit [1]
* Allow public polling to choose release names [2]
* New repositories: networking-generic-switch-tempest-plugin,
tempest-stress, charm-neutron-api-genericswitch, charm-ironic, charm-panko
* Goal updates: trove, solum, monasca, ironic, heat

[1] https://review.openstack.org/#/c/519751/
[2] https://review.openstack.org/#/c/534226/

This week we finally merged updates to the language used in the Python
PTI to be much more specific about how projects should be running tests.
The objective is to have a more consistent experience between projects
when running tests. Please see the Python PTI (publication job pending) at:

https://governance.openstack.org/tc/reference/pti/python.html

We also approved release naming process changes to turn the vote into a
public poll (and not crash CIVS again with tens of thousands of emails
to send to Foundation members). Expect the naming process for the S
release to start soon. The updated process will be found here once the
publication job runs:

https://governance.openstack.org/tc/reference/release-naming.html


== Rocky goals ==

We are in the final steps of selecting a set of community goals for
Rocky. We need wide community input on which goals are doable and make
the most sense! Please see the list of proposed goals and associated
champions:

* Storyboard Migration [3] (diablo_rojo)
* Remove mox [4] (chandankumar)
* Ensure pagination links [5] (mordred)
* Add Cold upgrades capabilities [6] (masayuki)
* Enable mutable configuration [7] (gcb)

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

NB: mriedem suggested on the ML that we wait until the PTG in Dublin to
make the final call. It gives more time to carefully consider the goals,
but delays the start of the work and makes planning pre-PTG a bit more
difficult.


== Voting in progress ==

Doug proposed to use StoryBoard for tracking Rocky goal completion
(rather than a truckload of governance changes). This change now reached
majority votes, and will be approved on Tuesday unless new objections
are posted:

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

A new OpenStack project team was proposed to add a function-as-a-service
component to OpenStack (called Qinling). The proposal has majority
support at this point, but the review raised interesting side
discussions and questions. Since the team would be added for the Rocky
cycle, there is no hurry so let's continue those discussions for a bit
more time:

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


== Under discussion ==

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

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


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

One month out, we need to start looking into the discussions we need to
have at the PTG (and good post-lunch presentation topics). We have
plenty of room for additional discussion topics during the
Monday-Tuesday part of the event, so it is easy to dedicate a room for
half a day to a full day to make good progress on critical issues.

We might also finalize the Rocky goal selection, unless we take on
mriedem's suggestion to wait until PTG to make the final cut.


== Office hours ==

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

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

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

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc] [all] TC Report 18-04

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-01-26 10:08:46 -0600:
> On 1/26/2018 9:57 AM, Doug Hellmann wrote:
> > Ideally we would use the time at the PTG to discuss implementation
> > details.
> 
> For something like the mox one, there really are no implementation 
> details, are there?
> 

That one is unusual in that regard, yes.

__
OpenStack Development Mailing 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] [all] TC Report 18-04

[Matt Riedemann]

On 1/26/2018 9:57 AM, Doug Hellmann wrote:

Ideally we would use the time at the PTG to discuss implementation
details.


For something like the mox one, there really are no implementation 
details, are there?


--

Thanks,

Matt

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

Re: [openstack-dev] [tc] [all] TC Report 18-04

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-01-26 09:38:18 -0600:
> On 1/23/2018 12:40 PM, Chris Dent wrote:
> > ## OpenStack-wide Goals
> > 
> > There are four proposed [OpenStack-wide
> > goals](https://governance.openstack.org/tc/goals/index.html):
> > 
> > * [Add Cold upgrades
> >    capabilities](https://review.openstack.org/#/c/533544/)
> > * [Add Rocky goal to remove
> >    mox](https://review.openstack.org/#/c/532361/)
> > * [
> > Add Rocky goal to enable mutable
> > configuration](https://review.openstack.org/#/c/534605/)
> > * [
> > Add Rocky goal to ensure pagination
> > links](https://review.openstack.org/#/c/532627/)
> > 
> > These need to be validated by the community, but they are not [getting
> > as much
> > feedback](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-23.log.html#t2018-01-23T09:16:51)
> >  
> > 
> > as hoped. There are different theories as to why, from "people are
> > busy", to "people don't feel empowered to comment", to "people don't
> > care". Whatever it is, without input the onus falls on the TC to make
> > choices, increasing the risk that the goals will be perceived as a
> > diktat. As always, we need to work harder to have high fidelity
> > feedback loops. This is especially true in our "mature" phase.
> 
> What's the due date on approving the community wide goals for Rocky? 
> Given the PTG is around the corner (by a month I guess), why not just 
> have the discussion in person at the PTG (for those attending in person 
> anyway)?
> 

Ideally we would use the time at the PTG to discuss implementation
details.

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] [release][ptl][all] extending queens-3 milestone deadlines

[Doug Hellmann]

This morning during the release team meeting [1] the team agreed that
given the issues with CI this week it makes sense to extend the
deadlines for the milestone.

The queens-3 deadline for projects following the cycle-with-milestones
release model is extended to Monday 29 January.

The client-library release deadline is extended to Tuesday 30 January.

Milestone-projects that have already tagged their 0b3 release for Queens
should carry on with preparing their release candidates as planned.

Doug

[1] 
http://eavesdrop.openstack.org/meetings/releaseteam/2018/releaseteam.2018-01-26-15.03.html

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

Re: [openstack-dev] [tc] [all] TC Report 18-04

[Matt Riedemann]

On 1/23/2018 12:40 PM, Chris Dent wrote:

## OpenStack-wide Goals

There are four proposed [OpenStack-wide
goals](https://governance.openstack.org/tc/goals/index.html):

* [Add Cold upgrades
   capabilities](https://review.openstack.org/#/c/533544/)
* [Add Rocky goal to remove
   mox](https://review.openstack.org/#/c/532361/)
* [
Add Rocky goal to enable mutable
configuration](https://review.openstack.org/#/c/534605/)
* [
Add Rocky goal to ensure pagination
links](https://review.openstack.org/#/c/532627/)

These need to be validated by the community, but they are not [getting
as much
feedback](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-01-23.log.html#t2018-01-23T09:16:51) 


as hoped. There are different theories as to why, from "people are
busy", to "people don't feel empowered to comment", to "people don't
care". Whatever it is, without input the onus falls on the TC to make
choices, increasing the risk that the goals will be perceived as a
diktat. As always, we need to work harder to have high fidelity
feedback loops. This is especially true in our "mature" phase.


What's the due date on approving the community wide goals for Rocky? 
Given the PTG is around the corner (by a month I guess), why not just 
have the discussion in person at the PTG (for those attending in person 
anyway)?


--

Thanks,

Matt

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

Re: [openstack-dev] [requirements] [vitrage][glance][ironic] global requirements update for python-vitrageclient

[Matthew Thode]

On 18-01-26 10:47:38, Mark Goddard wrote:
> Looks like this should be resolved by
> https://review.openstack.org/#/c/537453/.
> Mark
> 
> On 26 January 2018 at 10:33, Mark Goddard  wrote:
> 
> > Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient
> > 2.2.0. These are required in order to use the ironic node traits feature in
> > nova.
> >
> > [1] https://review.openstack.org/#/c/538093
> > [2] https://review.openstack.org/#/c/538066/3
> >
> > On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) <
> > ifat.a...@nokia.com> wrote:
> >
> >> Adding Glance team.
> >> Any idea what could be wrong?
> >>
> >> Thanks,
> >> Ifat.
> >>
> >>
> >> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <
> >> ifat.a...@nokia.com> wrote:
> >>
> >> Hi,
> >>
> >> I tried to update the version of python-vitrageclient [1], but the
> >> legacy-requirements-integration-dsvm test failed with an error that does
> >> not seem related to my changes:
> >>
> >> error: can't copy 'etc/glance-image-import.conf': doesn't exist or
> >> not a regular file
> >>
> >> I noticed that two other changes [2][3] failed with the same error.
> >>
> >> Can you please help?
> >>
> >> Thanks,
> >> Ifat.
> >>
> >>
> >> [1] https://review.openstack.org/#/c/537307
> >> [2] https://review.openstack.org/#/c/535460/
> >> [3] https://review.openstack.org/#/c/536142/

yep, requirements is hard blocked on that atm

-- 
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] [ALL][requirements] A freeze is coming and you should be prepared

[Jim Rollenhagen]

On Fri, Jan 26, 2018 at 9:46 AM, Matt Riedemann  wrote:
>
> Well, the requirements jobs seem to be busted as well:
>
> http://logs.openstack.org/93/538093/1/check/legacy-requireme
> nts-integration-dsvm/157d877/job-output.txt.gz#_2018-01-26_11_17_31_182762


The fix is in the gate, FWIW: https://review.openstack.org/#/c/537453/

// 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] [ALL][requirements] A freeze is coming and you should be prepared

[Matt Riedemann]

On 1/26/2018 12:12 AM, Matthew Thode wrote:

Last day, gate is sad and behind, but not my fault you waited til the
last minute :P  (see my first comment).  The Iceman Cometh!


Well, the requirements jobs seem to be busted as well:

http://logs.openstack.org/93/538093/1/check/legacy-requirements-integration-dsvm/157d877/job-output.txt.gz#_2018-01-26_11_17_31_182762

http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22error%3A%20can't%20copy%20'etc%2Fglance-image-import.conf'%3A%20doesn't%20exist%20or%20not%20a%20regular%20file%5C%22%20AND%20tags%3A%5C%22console%5C%22=7d

--

Thanks,

Matt

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

[openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

[Balázs Gibizer]

Hi,

I'm getting more and more confused how the zuul job hierarchy works or 
is supposed to work.


First there was a bug in nova that some functional tests are not 
triggered although the job (re-)definition in the nova part of the 
project-config should not prevent it to run [1].


There we figured out that irrelevant-files parameter of the jobs are 
not something that can be overriden during re-definition or through 
parent-child relationship. The base job openstack-tox-functional has an 
irrelevant-files attribute that lists '^doc/.*$' as a path to be 
ignored [2]. In the other hand the nova part of the project-config 
tries to make this ignore less broad by adding only '^doc/source/.*$' . 
This does not work as we expected and the job did not run on changes 
that only affected ./doc/notification_samples path. We are fixing it by 
defining our own functional job in nova tree [4].


[1] https://bugs.launchpad.net/nova/+bug/1742962
[2] 
https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380
[3] 
https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509

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

Then I started looking into other jobs to see if we made similar 
mistakes. I found two other examples in the nova related jobs where 
redefining the irrelevant-files of a job caused problems. In these 
examples nova tried to ignore more paths during the override than what 
was originally ignored in the job definition but that did not work 
[5][6].


[5] https://bugs.launchpad.net/nova/+bug/1745405 (temptest-full)
[6] https://bugs.launchpad.net/nova/+bug/1745431 (neutron-grenade)

So far the problem seemed to be consistent (i.e. override does not 
work). But then I looked into neutron-grenade-multinode. That job is 
defined in neutron tree (like neutron-grenade) but nova also refers to 
it in nova section of the project-config with different 
irrelevant-files than their original definition. So I assumed that this 
will lead to similar problem than in case of neutron-grenade, but it 
doesn't.


The neutron-grenade-multinode original definition [1] does not try to 
ignore the 'nova/tests' path but the nova side of the definition in the 
project config does try to ignore that path [8]. Interestingly a patch 
in nova that only changes under the path: nova/tests/ does not trigger 
the job [9]. So in this case overriding the irrelevant-files of a job 
works. (It seems that overriding neutron-tempest-linuxbridge 
irrelevant-files works too).


[7] 
https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159
[8] 
https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530

[9] https://review.openstack.org/#/c/537936/

I don't see what is the difference between neutron-grenade and 
neutron-grenade-multinode jobs definitions from this perspective but it 
seems that the irrelevent-files attribute behaves  inconsistently in 
these two jobs. Could you please help me undestand how irrelevant-files 
in overriden jobs supposed to work?


cheers,
gibi




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

Re: [openstack-dev] [tripleo] Upgrade community weekly meeting

[mathieu bultel]

Hi All,

After few weeks and meetings on Friday, we decide to change a little bit
the pattern of this meeting.
We decided to keep the schedule up and open for anything/anyone, but
each times, we will check before the meeting if the agenda [1] is empty.
If so, then we won't make it, or we would use this schedule for another
topic.
This has been decided like that for few reasons. The main reason is that
we repeat and discuss the same status/issues that we previously discuss
on our normal scrum and most of the attendees is folks from inside the
DFG. So its a kind of a repetition for us and there is no big value in
this except when people external of the DFG bring things, like Weshay
used to or rdo-cloud folks.

Thank you all.
Mathieu

[1]

https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting



On 11/09/2017 01:23 PM, mathieu bultel wrote:
> Hi TripleO,
>
> As discuss on the last TripleO meeting, the Upgrade squad will stand a
> weekly meeting each Friday to discuss and share about the Upgrade
> related topics.
>
> Every body who are interested is welcome to join us and fell free to
> raise any questions/issues/concerns.
>
> Tomorrow will be our first session and it will be more CI oriented.
>
> We will use this etherpad to track the discussions and the status:
>
> https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting
>
> For the next meetings, I will setup agenda for each of those with the
> following topics: Bugs, CI and Features (Specs), but everybody can add
> his own items in the agenda.
>
> Mathieu
>
>
> __
> OpenStack Development Mailing 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] CI'ing ceph-ansible against TripleO scenarios

[Giulio Fidente]

On 01/26/2018 01:49 AM, Paul Belanger wrote:
> On Thu, Jan 25, 2018 at 04:22:56PM -0800, Emilien Macchi wrote:
>> Is there any plans to run TripleO CI jobs in ceph-ansible?
>> I know the project is on github but thanks to zuulv3 we can now easily
>> configure ceph-ansible to run Ci jobs in OpenStack Infra.
>>
>> It would be really great to investigate that in the near future so we avoid
>> eventual regressions.
>> Sebastien, Giulio, John, thoughts?
>> -- 
>> Emilien Macchi
> 
> Just a note, we haven't actually agree to enable CI for github projects just
> yet.  While it is something zuul can do now, I believe we still need to decide
> when / how to enable it.
> 
> We are doing some initial testing with ansible/ansible however.

but we like being on the front line! :D

we discussed this same topic with Sebastien and John a few weeks back
and agreed on having some gate job for ceph-ansible CI'ing against TripleO!

how do we start? I think the candidate branch on ceph-ansible to gate is
"beta-3.1" but there will be more ... I am just not sure we're stable
enough to gate master yet ... but we might do it non-voting, it's up for
debate

on TripleO side we'd be looking at running scenarios 001 and 004 ...
maybe initially 004 only is good enough as it covers (at least for ceph)
most of what is in 001 as well

can we continue on IRC? :D

and thanks Emilien and Paul for starting the thread and helping
-- 
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [requirements] [vitrage][glance][ironic] global requirements update for python-vitrageclient

[Mark Goddard]

Looks like this should be resolved by
https://review.openstack.org/#/c/537453/.
Mark

On 26 January 2018 at 10:33, Mark Goddard  wrote:

> Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient
> 2.2.0. These are required in order to use the ironic node traits feature in
> nova.
>
> [1] https://review.openstack.org/#/c/538093
> [2] https://review.openstack.org/#/c/538066/3
>
> On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) <
> ifat.a...@nokia.com> wrote:
>
>> Adding Glance team.
>> Any idea what could be wrong?
>>
>> Thanks,
>> Ifat.
>>
>>
>> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <
>> ifat.a...@nokia.com> wrote:
>>
>> Hi,
>>
>> I tried to update the version of python-vitrageclient [1], but the
>> legacy-requirements-integration-dsvm test failed with an error that does
>> not seem related to my changes:
>>
>> error: can't copy 'etc/glance-image-import.conf': doesn't exist or
>> not a regular file
>>
>> I noticed that two other changes [2][3] failed with the same error.
>>
>> Can you please help?
>>
>> Thanks,
>> Ifat.
>>
>>
>> [1] https://review.openstack.org/#/c/537307
>> [2] https://review.openstack.org/#/c/535460/
>> [3] https://review.openstack.org/#/c/536142/
>>
>>
>>
>> 
>> __
>> 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

Re: [openstack-dev] [requirements] [vitrage][glance][ironic] global requirements update for python-vitrageclient

[Mark Goddard]

Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient
2.2.0. These are required in order to use the ironic node traits feature in
nova.

[1] https://review.openstack.org/#/c/538093
[2] https://review.openstack.org/#/c/538066/3

On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Adding Glance team.
> Any idea what could be wrong?
>
> Thanks,
> Ifat.
>
>
> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <
> ifat.a...@nokia.com> wrote:
>
> Hi,
>
> I tried to update the version of python-vitrageclient [1], but the
> legacy-requirements-integration-dsvm test failed with an error that does
> not seem related to my changes:
>
> error: can't copy 'etc/glance-image-import.conf': doesn't exist or
> not a regular file
>
> I noticed that two other changes [2][3] failed with the same error.
>
> Can you please help?
>
> Thanks,
> Ifat.
>
>
> [1] https://review.openstack.org/#/c/537307
> [2] https://review.openstack.org/#/c/535460/
> [3] https://review.openstack.org/#/c/536142/
>
>
>
> __
> OpenStack Development Mailing 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] Upgrade community weekly meeting

[mathieu bultel]

Hi All,

After few weeks and meetings on Friday, we decide to change a little bit
the pattern of this meeting.
We decided to keep the schedule up and open for anything/anyone, but
each times, we will check before the meeting if the agenda [1] is empty.
If so, then we won't make it, or we would use this schedule for another
topic.
This has been decided like that for few reasons. The main reason is that
we repeat and discuss the same status/issues that we previously discuss
on our normal scrum and most of the attendees is folks from inside the
DFG. So its a kind of a repetition for us and there is no big value in
this except when people external of the DFG bring things, like Weshay
used to or rdo-cloud folks.

Thank you all.
Mathieu

[1]

https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting



On 11/09/2017 01:23 PM, mathieu bultel wrote:
> Hi TripleO,
>
> As discuss on the last TripleO meeting, the Upgrade squad will stand a
> weekly meeting each Friday to discuss and share about the Upgrade
> related topics.
>
> Every body who are interested is welcome to join us and fell free to
> raise any questions/issues/concerns.
>
> Tomorrow will be our first session and it will be more CI oriented.
>
> We will use this etherpad to track the discussions and the status:
>
> https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting
>
> For the next meetings, I will setup agenda for each of those with the
> following topics: Bugs, CI and Features (Specs), but everybody can add
> his own items in the agenda.
>
> Mathieu
>
>
> __
> OpenStack Development Mailing 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