[openstack-dev] cancelled Re: [ironic] Ironic review party invitation

[Loo, Ruby]

Hi,

Effective immediately and indefinitely (or err in 10 minutes :)), the Ironic 
review parties have been cancelled. It was the best kept secret but frowned 
upon when discovered. Too much partying and drinking you know. [I am just 
kidding!]

If someone wants to resume this or do something similar in the future, please 
do so!

Thank you Mario and everyone else that attended, you all made it way too 
successful :)

--ruby

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

Date: Monday, March 20, 2017 at 11:20 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [ironic] Ironic review party invitation

Hi ironic team,

I'm proposing that we move this to 20:00 UTC Thursdays (8pm UTC, 4pm
in my timezone which is US Eastern). I think this will better fit with
the daylight saving time adjustment that most attendees had last week.
Please message me here or in IRC if there are objections. I've updated
the etherpad at https://etherpad.openstack.org/p/ironic-review-party
to reflect this new time.

I am now back from vacation and will be around for this week's review
party. Thanks to whoever led last week's review party.

Mario

On Tue, Feb 28, 2017 at 2:14 PM, Mario Villaplana
> wrote:
Hi ironic team,

Last cycle, I started holding some informal "review parties" for new
members of OSIC [0] to come together with other OSIC people who had
been working on OpenStack for a while and have group discussions about
technical topics related to ironic and generally how to be more
effective upstream community members.

People found this decently helpful, with a weighted average of 3.6
when polled for feedback on the usefulness of the event on a 1-5
scale.

As a result of some of this feedback, I thought it'd be good to invite
the whole ironic community to participate in this weekly event.

It'll now be happening Thursdays at 2100 UTC in a Google Hangouts room
so that more community members can join. Here's an etherpad with the
Hangouts link and more information about the event:
https://etherpad.openstack.org/p/ironic-review-party

This is a totally informal, unofficial event. Feel free to put any
topic you'd like to discuss with a larger audience on that etherpad in
the section for the current week. I'll be looking over whatever's on
that list 24 hours in advance of the party to get adequately prepared,
but feel free to show up with other topics, too.

Thanks!

Mario

[0] https://osic.org/

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

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

Re: [openstack-dev] [keystone][horizon] weekly meeting

[Rob Cresswell]

It's been a week since the original email; I think we should scale back to a 
monthly sync up. No preference on which week of the month it falls in. Thanks!

Rob

On 13 April 2017 at 22:03, Lance Bragstad 
> wrote:
Happy Thursday folks,

Rob and I have noticed that the weekly attendance for the Keystone/Horizon [0] 
meeting has dropped significantly in the last month or two. We contemplated 
changing the frequency of this meeting to be monthly instead of weekly. We 
still think it is important to have a sync point between the two projects, but 
maybe it doesn't need to be as often as we were expecting.

Does anyone have any objections to making this a monthly meeting?

Does anyone have a preference on the week or day of the month (i.e. 3rd 
Thursday of the month)?

Once we have consensus on a time, I'll submit a patch for the meeting agenda.

Thanks and have a great weekend!

[0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

__
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] [qa] [patrole] Question regarding patrole release management

[MONTEIRO, FELIPE C]

Thanks Ghanshyam,

That was really helpful. If Tempest is versioned via tags, then I agree that 
Patrole should do the same thing. I didn't quite know what you meant by 
"feature flag" but after finding [0] it became apparent to me: Patrole has been 
doing this wherever Tempest does it. Granted, we probably need more 
participation in the project to catch minute details like that, as we currently 
have a large body of tests, but currently we have been using feature flags 
where appropriate.

Case 3 as you mentioned is something that we've already had to account for: 
When Nova and then Keystone moved their policies into code, we had to add logic 
to the framework to account for those changes. Case 3 in theory would not be a 
problem, if there was a way to verify whether a policy action was enforced, 
other than by checking logs. If there was an API in OpenStack that could be 
called to retrieve oslo_policy enforcements per request id, then Case 3 would 
just result in an error being thrown by Patrole for a given test, which we 
would then notice and fix.

[0] https://review.openstack.org/#/c/418928/ 

--Felipe

-Original Message-
From: Ghanshyam Mann [mailto:ghanshyamm...@gmail.com] 
Sent: Wednesday, April 19, 2017 12:05 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [qa] [patrole] Question regarding patrole release 
management

On Wed, Apr 19, 2017 at 2:29 AM, MONTEIRO, FELIPE C  wrote:
> Hi all,
>
>
>
> I have a question regarding patrole and release management. Many projects
> like heat or murano have a tempest plugin within their repos, so by
> extension their tempest plugins have releases, as the projects change over
> time. However, since patrole is just a tempest plugin, yet heavily reliant
> on tempest, how should patrole do release management?

Hi Felipe,

Release management depends on whether Patrole is planning the
branchless model (i think it is) like Tempest or branch model., If
branchless, then it does not fall under release management. It can
adopt release model what Tempest has [1].

Branchless model gives many benefit like avoid backward incompatible
changes, avoid maintaining multiple Patrole repo across releases etc.

> Am I correct in
> thinking that it should, in the first place? With nova-network and other
> APIs slated for deprecation in Pike and beyond, Patrole will logically have
> to continuously be maintained to keep up, meaning that older tests, just
> like with Tempest, will have to be phased out. If Patrole, then, does not
> have releases, then older release-dependent tests and functionality will
> over time be lost.

We have 3 cases here:
1. Functionality is deprecated/removed in new release.
2. Functionality newly added in new release.
3. Policy enforcement change.

For case 1, Tempest keep testing deprecated functionality till it is
marked deprecated across all supported stable branches. Once all
stable branch has that functionality as deprecated marked, then we
discuss of removing its testing from Tempest.
With API Microversion model that is little bit different where
functionality might be deprecated after specific version or it is
deprecated from base version itself. For example, Nova proxy APIs
deprecated after 2.36, Certificate APIs might be gone from base
version (which is under discussion). This is more case by case and
based on all stack holder point of view, we will decide their testing
should be removed or stay till when.

For case 2, Tempest introduced testing of new functionality with
feature flag and those tests will be executed/skipped accordingly.

Case 3 is something important to consider for Patrole. Usually policy
changes will be done with backward compatible way where changes does
not break upgrade. Any change in policy enforcement will be done at
least with supporting old and new rules [2] or with old rules
deprecation of period of 1 release cycle at least. And branchless
model can detect any accidental changes which going to break upgrade.

IMO, branchless model is good value for Patrole in all 3 cases
consideration and feature flags to handle the new/old/policy-change
functionality. Similarly release model can be same as Tempest has.


>
>
>
> Thank You,
>
> Felipe Monteiro

..1 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_QA_releases=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=xgobDX0RcKxlQhqhOSmU6H11-k8u21HsinBnbYLB6mY=9eq8-o16PTMYfNYW0LjlVyRfN1W4wXWloI7jVij5W4g=
 
..2 
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_391113_13=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=X4GwEru-SJ9DRnCxhze-aw=xgobDX0RcKxlQhqhOSmU6H11-k8u21HsinBnbYLB6mY=A5axQVIlZlVMGaW0vwQxpqwx5uMZvZ1ZNwWAXgrIoAc=
 

-gmann


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

Re: [openstack-dev] [ironic]

[Don maillist]

Thanks Mike, I will check. This is an ATCA chassis. The reason I brought it
up here was to find out if I need to develop it. But to double check, I
have ATCA blades that use uboot. Not sure that makes a difference but I
will check your blog.

Best regards,
Don

On Thu, Apr 20, 2017 at 10:52 AM, Michael Turek 
wrote:

> Hey Don,
>
> Deployment to Power8 and beyond via the agent-ipmitool driver should work
> fine. We test it regularly here:
>
> https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI
>
> If you'd like some help setting up Ironic for power, feel free to ping me
> on #openstack-ironic. Also check out this blog that I worked on with a
> colleague for some advice:
>
> https://developer.ibm.com/linuxonpower/2017/03/20/
> setting-openstack-bare-metal-service-power8/
>
> Also a friendly reminder that this question is probably more suited for
> the OpenStack mailing list rather than openstack-dev.
>
> Thanks,
> mjturek
> On 04/20/2017 08:16 AM, Don maillist wrote:
>
> Does Ironic currently support non X86 systems? I have a power PC ATCA
> blade that I need to be used as a very specific blade function. I would
> need to PXE boot the blade to a ramdisk if possible (There are no hard
> drives. Only a flash drive).
>
> Best Regards,
> Don
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][monasca] Release of openstack/monasca-kibana-plugin failed

[Doug Hellmann]

The version of monasca-kibana-plugin in package.json does not match the
new tag, and that caused the publish job to fail. I'm available to help
debug or to quickly release an update after the problem is fixed.

Doug

--- Begin forwarded message from jenkins ---
From: jenkins 
To: release-job-failures 
Date: Wed, 19 Apr 2017 10:01:01 +
Subject: [Release-job-failures] Release of openstack/monasca-kibana-plugin 
failed

Build failed.

- monasca-kibana-plugin-nodejs4-npm-publish-tarball 
http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/
 : SUCCESS in 4m 48s
- monasca-kibana-plugin-tarball-signing 
http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-tarball-signing/28e6145/
 : SUCCESS in 10s
- monasca-kibana-plugin-npm-upload 
http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-npm-upload/f3dd81a/
 : FAILURE in 9s
- monasca-kibana-plugin-announce-release monasca-kibana-plugin-announce-release 
: SKIPPED

--- End forwarded message ---

__
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] Bridging the production/CI workflow gap with large periodic CI jobs

[Ben Nemec]

On 04/19/2017 12:17 PM, Justin Kilpatrick wrote:

More nodes is always better but I don't think we need to push the host
cloud to it's absolute limits right away. I have a list of several
pain points I expect to find with just 30ish nodes that should keep us
busy for a while.

I think the optimizations are a good idea though, especially if we
want to pave the way for the next level of this sort of effort. Which
is devs being able to ask for a 'scale ci' run on gerrit and schedule
a decent sized job for whenever it's convenient. The closer we can get
devs to large environments on demand the faster and easier these
issues can be solved.

But for now baby steps.


https://review.openstack.org/458651 should enable the heterogeneous 
environments I mentioned.  We need to be a little careful with a patch 
like that since they aren't actually tested in the gate, but something 
along those lines should work.  It may also need a larger controller 
flavor so the controller(s) don't OOM with that many computes, but if 
we've got a custom env for this use case anyway that should be doable too.




On Wed, Apr 19, 2017 at 12:30 PM, Ben Nemec  wrote:

TLDR: We have the capacity to do this.  One scale job can be absorbed into
our existing test infrastructure with minimal impact.


On 04/19/2017 07:50 AM, Flavio Percoco wrote:


On 18/04/17 14:28 -0400, Emilien Macchi wrote:


On Mon, Apr 17, 2017 at 3:52 PM, Justin Kilpatrick
 wrote:


Because CI jobs tend to max out about 5 nodes there's a whole class of
minor bugs that make it into releases.

What happens is that they never show up in small clouds, then when
they do show up in larger testing clouds the people deploying those
simply work around the issue and get onto what they where supposed to
be testing. These workarounds do get documented/BZ'd but since they
don't block anyone and only show up in large environments they become
hard for developers to fix.

So the issue gets stuck in limbo, with nowhere to test a patchset and
no one owning the issue.

These issues pile up and pretty soon there is a significant difference
between the default documented workflow and the 'scale' workflow which
is filled with workarounds which may or may not be documented
upstream.

I'd like to propose getting these issues more visibility to having a
periodic upstream job that uses 20-30 ovb instances to do a larger
deployment. Maybe at 3am on a Sunday or some other time where there's
idle execution capability to exploit. The goal being to make these
sorts of issues more visible and hopefully get better at fixing them.



Wait no, I know some folks at 3am on a Saturday night who use TripleO
CI (ok that was a joke).



Jokes apart, it really depends on the TZ and when you schedule it. 3:00
UTC on a
Sunday is Monday 13:00 in Sydney :) Saturdays might work better but
remember
that some countries work on Sundays.



With the exception of the brief period where the ovb jobs were running at
full capacity 24 hours a day, there has always been a lull in activity
during early morning UTC.  Yes, there are people working during that time,
but generally far fewer and the load on TripleO CI is at its lowest point.
Honestly I'd be okay running this scale job every night, not just on the
weekend.  A week of changes is a lot to sift through if a scaling issue
creeps into one of the many, many projects that affect such things in
TripleO.

Also, I should note that we're not currently being constrained by absolute
hardware limits in rh1.  The reason I haven't scaled our concurrent jobs
higher is that there is already performance degradation when we have a full
70 jobs running at once.  This type of scale job would require a lot of
theoretical resources, but those 30 compute nodes are mostly going to be
sitting there idle while the controller(s) get deployed, so in reality their
impact on the infrastructure is going to be less than if we just added more
concurrent jobs that used 30 additional nodes.  And we do have the
memory/cpu/disk to spare in rh1 to spin up more vms.

We could also take advantage of heterogeneous OVB environments now so that
the compute nodes are only 3 GB VMs instead of 8 as they are now. That would
further reduce the impact of this sort of job.  It would require some tweaks
to how the testenvs are created, but that shouldn't be a problem.




To be honest I'm not sure this is the best solution, but I'm seeing
this anti pattern across several issues and I think we should try and
come up with a solution.



Yes this proposal is really cool. There is an alternative to run this
periodic scenario outside TripleO CI and send results via email maybe.
But it is something we need to discuss with RDO Cloud people and see
if we would have such resources to make it on a weekly frequency.

Thanks for bringing this up, it's crucial for us to have this kind of
feedback, now let's take actions.



+1

Flavio

Re: [openstack-dev] [release][monasca] Release of openstack/monasca-kibana-plugin failed

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
> The version of monasca-kibana-plugin in package.json does not match the
> new tag, and that caused the publish job to fail. I'm available to help
> debug or to quickly release an update after the problem is fixed.

https://review.openstack.org/458629 should help us avoid this error in
the future.

> 
> Doug
> 
> --- Begin forwarded message from jenkins ---
> From: jenkins 
> To: release-job-failures 
> Date: Wed, 19 Apr 2017 10:01:01 +
> Subject: [Release-job-failures] Release of openstack/monasca-kibana-plugin 
> failed
> 
> Build failed.
> 
> - monasca-kibana-plugin-nodejs4-npm-publish-tarball 
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/
>  : SUCCESS in 4m 48s
> - monasca-kibana-plugin-tarball-signing 
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-tarball-signing/28e6145/
>  : SUCCESS in 10s
> - monasca-kibana-plugin-npm-upload 
> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-npm-upload/f3dd81a/
>  : FAILURE in 9s
> - monasca-kibana-plugin-announce-release 
> monasca-kibana-plugin-announce-release : SKIPPED
> 
> --- End forwarded message ---
> 

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

Re: [openstack-dev] [keystone][horizon] weekly meeting

[Steve Martinelli]

As someone who helped orchestrate the weekly sync-ups, I'll chime in. I
always intended for these meetings to end once we accomplished most of the
goals [1] we identified last summit. With most of the goals accomplished,
scaling back or ending them entirely seems appropriate. We can always start
them up again if our backlog grows again.

[1] https://etherpad.openstack.org/p/ocata-keystone-horizon

On Thu, Apr 20, 2017 at 3:46 PM, Lance Bragstad  wrote:

> I wonder if the meeting tooling supports a monthly cadence?
>
> On Thu, Apr 20, 2017 at 2:42 PM, Rob Cresswell <
> robert.cressw...@outlook.com> wrote:
>
>> It's been a week since the original email; I think we should scale back
>> to a monthly sync up. No preference on which week of the month it falls in.
>> Thanks!
>>
>> Rob
>>
>> On 13 April 2017 at 22:03, Lance Bragstad  wrote:
>>
>>> Happy Thursday folks,
>>>
>>> Rob and I have noticed that the weekly attendance for the
>>> Keystone/Horizon [0] meeting has dropped significantly in the last month or
>>> two. We contemplated changing the frequency of this meeting to be monthly
>>> instead of weekly. We still think it is important to have a sync point
>>> between the two projects, but maybe it doesn't need to be as often as we
>>> were expecting.
>>>
>>> Does anyone have any objections to making this a monthly meeting?
>>>
>>> Does anyone have a preference on the week or day of the month (i.e. 3rd
>>> Thursday of the month)?
>>>
>>> Once we have consensus on a time, I'll submit a patch for the meeting
>>> agenda.
>>>
>>> Thanks and have a great weekend!
>>>
>>> [0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collabo
>>> ration_Meeting
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

[Jay S Bryant]

Sean,

In the case that all the conflicts cannot be resolved I would be happy 
to cover the Onboarding session if you can keep me in the loop/take 
items for the Cinder Ephemeral session.


Let me know,

Jay



On 4/20/2017 9:55 AM, Sean McGinnis wrote:

Unfortunately I am way late at noticing this, but bringing it up in case
there's anything that can still be done about it.

Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me.
The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the
Cinder - Project Onboarding sessions are all at this slot.

While onboarding is something I feel is really imortant, out of these as
it is now I think I would have to go with the Cinder Nova discussion. But
that really would be a shame to have to miss that. I also would really
like to be part of the Track Chair discussion, but if I have to rank
these, that one will have to be last. I'm guessing there's really no
good time for that session that is not going to cause a conflict for
somebody.

So my question for the scheduling powers that be - is there any chance
we can move either the Cinder Onboarding or the Cinder-Nova sessions?

Thanks,
Sean (smcginnis)


__
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] [devstack] uwsgi for API services

[Takashi Yamamoto]

On Thu, Apr 13, 2017 at 9:01 PM, Sean Dague  wrote:
> One of the many reasons for getting all our API services running wsgi
> under a real webserver is to get out of the custom ports for all
> services game. However, because of some of the limits of apache
> mod_wsgi, we really haven't been able to do that in our development
> enviroment. Plus, the moment we go to mod_wsgi for some services, the
> entire development workflow for "change this library, refresh the
> following services" changes dramatically.
>
> It would be better to have a consistent story here.
>
> So there is some early work up to use apache mod_proxy_uwsgi as the
> listener, and uwsgi processes running under systemd for all the
> services. These bind only to a unix local socket, not to a port.
> https://review.openstack.org/#/c/456344/
>
> Early testing locally has been showing progress. We still need to prove
> out a few things, but this should simplify a bunch of the setup. And
> coming with systemd will converge us back to a more consistent
> development workflow when updating common code in a project that has
> both API services and workers.
>
> For projects that did the mod_wsgi thing in a devstack plugin, this is
> going to require some adjustment. Exactly what is not yet clear, but
> it's going to be worth following that patch.

networking-midonet needed this change.
https://review.openstack.org/#/c/458305

i guess some other projects need similar changes.
http://codesearch.openstack.org/?q=KEYSTONE_AUTH_PORT=nope==

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

__
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] [qa] [patrole] Question regarding patrole release management

[Ghanshyam Mann]

On Fri, Apr 21, 2017 at 4:19 AM, MONTEIRO, FELIPE C  wrote:
> Thanks Ghanshyam,
>
> That was really helpful. If Tempest is versioned via tags, then I agree that 
> Patrole should do the same thing. I didn't quite know what you meant by 
> "feature flag" but after finding [0] it became apparent to me: Patrole has 
> been doing this wherever Tempest does it. Granted, we probably need more 
> participation in the project to catch minute details like that, as we 
> currently have a large body of tests, but currently we have been using 
> feature flags where appropriate.

Very Nice. Feel free to ping us if you need any help on those things.

>
> Case 3 as you mentioned is something that we've already had to account for: 
> When Nova and then Keystone moved their policies into code, we had to add 
> logic to the framework to account for those changes. Case 3 in theory would 
> not be a problem, if there was a way to verify whether a policy action was 
> enforced, other than by checking logs. If there was an API in OpenStack that 
> could be called to retrieve oslo_policy enforcements per request id, then 
> Case 3 would just result in an error being thrown by Patrole for a given 
> test, which we would then notice and fix.

Yea that's true and it was due to lack of policy documentation. Nova
will (almost completed) have good documentation to solve that. John &
OSIC folks started very nice documentation on policy which tells you
what all policy being used by what all APIs with description [1]. And
on same page Keystone also [2]

This is how it looks like now [3]. This can help Patrole.


..1 https://blueprints.launchpad.net/nova/+spec/policy-docs
..2 https://blueprints.launchpad.net/keystone/+spec/policy-docs
..3 https://docs.openstack.org/developer/nova/sample_policy.html
>
> [0] https://review.openstack.org/#/c/418928/
>
> --Felipe
>
> -Original Message-
> From: Ghanshyam Mann [mailto:ghanshyamm...@gmail.com]
> Sent: Wednesday, April 19, 2017 12:05 AM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [qa] [patrole] Question regarding patrole 
> release management
>
> On Wed, Apr 19, 2017 at 2:29 AM, MONTEIRO, FELIPE C  wrote:
>> Hi all,
>>
>>
>>
>> I have a question regarding patrole and release management. Many projects
>> like heat or murano have a tempest plugin within their repos, so by
>> extension their tempest plugins have releases, as the projects change over
>> time. However, since patrole is just a tempest plugin, yet heavily reliant
>> on tempest, how should patrole do release management?
>
> Hi Felipe,
>
> Release management depends on whether Patrole is planning the
> branchless model (i think it is) like Tempest or branch model., If
> branchless, then it does not fall under release management. It can
> adopt release model what Tempest has [1].
>
> Branchless model gives many benefit like avoid backward incompatible
> changes, avoid maintaining multiple Patrole repo across releases etc.
>
>> Am I correct in
>> thinking that it should, in the first place? With nova-network and other
>> APIs slated for deprecation in Pike and beyond, Patrole will logically have
>> to continuously be maintained to keep up, meaning that older tests, just
>> like with Tempest, will have to be phased out. If Patrole, then, does not
>> have releases, then older release-dependent tests and functionality will
>> over time be lost.
>
> We have 3 cases here:
> 1. Functionality is deprecated/removed in new release.
> 2. Functionality newly added in new release.
> 3. Policy enforcement change.
>
> For case 1, Tempest keep testing deprecated functionality till it is
> marked deprecated across all supported stable branches. Once all
> stable branch has that functionality as deprecated marked, then we
> discuss of removing its testing from Tempest.
> With API Microversion model that is little bit different where
> functionality might be deprecated after specific version or it is
> deprecated from base version itself. For example, Nova proxy APIs
> deprecated after 2.36, Certificate APIs might be gone from base
> version (which is under discussion). This is more case by case and
> based on all stack holder point of view, we will decide their testing
> should be removed or stay till when.
>
> For case 2, Tempest introduced testing of new functionality with
> feature flag and those tests will be executed/skipped accordingly.
>
> Case 3 is something important to consider for Patrole. Usually policy
> changes will be done with backward compatible way where changes does
> not break upgrade. Any change in policy enforcement will be done at
> least with supporting old and new rules [2] or with old rules
> deprecation of period of 1 release cycle at least. And branchless
> model can detect any accidental changes which going to break upgrade.
>
> IMO, branchless model is good value for Patrole in all 3 cases
> 

Re: [openstack-dev] [kolla] [daisycloud-core][requirements][magnum] [oslo] Do we really need to upgrade pbr,docker-py and oslo.utils

[hu.zhijiang]

Steve,

Co-installation and global requirements are orthogonal to me: Two projects 
which can be (or need to be) co-installed do not need to be global requirements 
aligned, on the flip side, two projects which are global requirements aligned 
do not need to be tied together for user to use. So I would rather interpret 
global requirements alignement as a test to see if projects can run together 
than an updating of each projects requirement.txt.











B. R.,

Zhijiang






Original Mail



Sender:  ＜std...@cisco.com＞
To:  ＜openstack-dev@lists.openstack.org＞ ＜hongbin...@gmail.com＞
Date: 2017/04/20 18:08
Subject: Re: [openstack-dev] [kolla] [daisycloud-core][requirements][magnum] 
[oslo] Do we really need to upgrade pbr,docker-py and oslo.utils







Zhijang,


 


You have a point a view whereby Kolla is never co-installed with other 
OpenStack projects.  I agree I have never heard of this happening.  That 
doesn’t mean it doesn’t happen.


 


Even given this line of thinking, I have an impossible time rationalizing Kolla 
as a special snowflake.  Kolla conforms (as best as we know how) to OpenStack 
wide processes.


 


Regards


-steve


 



From: "hu.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org＞
 Date: Wednesday, April 19, 2017 at 11:24 PM
 To: "hongbin...@gmail.com" ＜hongbin...@gmail.com＞
 Cc: "openstack-dev@lists.openstack.org" ＜openstack-dev@lists.openstack.org＞
 Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils



 

Then IMO,  the global requirements process seems against the intention of 
requirement.txt file. Since requirement.txt is per-project, not global. It is 
(just for example) Zun that treat docker-py-1.8 as a must. As for Kolla, both 
1.6 and 1.8 are OK. Then  there is no need to force Kolla to change its 
requirement from "docker-py ＞=1.6.0" to "docker-py ＞=1.8.0" by the global 
requirements process, otherwise,  user may think Kolla really need a newer 
version, kind of easy to be misread.

 

We know it is valuable to upgrade requirements globally, as it is condusive to 
early bug detection of the co-installation circumstance. But can we not to do 
that detection in each project's CI by write it literally in each project's 
requirement.txt but just  upgrade required packages globally in a dedicated CI 
that tests the projects which really need to be co-installed? 

 

B. R.,

Zhijiang





Original Mail



Sender:  ＜hongbin...@gmail.com＞



To:  ＜openstack-dev@lists.openstack.org＞



Date: 2017/04/20 12:50



Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils




 


Zun required docker-py to be 1.8 or higher because older version of docker-py 
didn't have the API we need. Sorry if it caused difficulties on your side but I 
don't think it is feasible to downgrade the version for now since it will 
affect  a ton of other projects.


Best regards,



Hongbin




 


On Thu, Apr 20, 2017 at 12:15 AM, Steven Dake (stdake) ＜std...@cisco.com＞ wrote:


Hu,


 


Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber  stamp changes from the 
global requirements bot assuming  they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.


 


Taking a look at the specific issues you raised:


 


Pbr: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158


Here is the change: 
https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c


(from the infrastructure team)


 


Docker-py: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338


Here is the change: 
https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6


(from the magnum team)


 


oslo-utils: 
https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136


https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7


(I am not sure which team this is – the oslo team perhaps?)


 


I would recommend taking the changes up with the requirements team or the 
direct authors.


 


Regards


-steve


 


 


 



From: "hu.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org＞
 Date: Wednesday, April 19, 2017 at 8:45 PM
 To: "openstack-dev@lists.openstack.org" ＜openstack-dev@lists.openstack.org＞
 Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils 



 

Hello,

 

As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 

[openstack-dev] [tripleo] upgrade jobs status

[Emilien Macchi]

I found useful to share this super quick status about TripleO Upgrades CI jobs:

# ocata to pike
Upgrade jobs on master have made progress, see results on
https://review.openstack.org/#/c/457603/.
gate-tripleo-ci-centos-7-multinode-upgrades-nv : GREEN
gate-tripleo-ci-centos-7-scenario001-multinode-upgrades-nv: RED - need
investigation
gate-tripleo-ci-centos-7-scenario002-multinode-upgrades-nv: RED -
https://bugs.launchpad.net/tripleo/+bug/1685052
gate-tripleo-ci-centos-7-scenario003-multinode-upgrades-nv: GREEN
gate-tripleo-ci-centos-7-scenario004-multinode-upgrades-nv: GREEN

Once they are all green and not timeouting anymore:
- add them to promotion pipeline
- make them voting

# newton to ocata
Jobs were timeouting and we're attempting to reduce the runtime by
using more AFS mirrors:
https://review.openstack.org/#/c/458474/
I'll give an update by end of Friday or next week to see if it was
really useful.

Any feedback / help is very welcome.
Thanks,
-- 
Emilien Macchi

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

[openstack-dev] [neutron] - are you attending the Boston summit?

[Kevin Benton]

Hi,

If you are a Neutron developer attending the Boston summit, please add your
name to the etherpad here so we can plan a Neutron social and easily
coordinate in person meetings:
https://etherpad.openstack.org/p/neutron-boston-summit-attendees

Cheers,
Kevin Benton
__
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][elections] Technical Committee Election Results

[Tristan Cacqueray]

Please join me in congratulating the 7 newly elected members of the
Technical Committe (TC).

Chris Dent (cdent)
Davanum Srinivas (dims)
Dean Troyer (dtroyer)
Flavio Percoco (flaper87)
John Garbutt (johnthetubaguy)
Sean McGinnis (smcginnis)
Thierry Carrez (ttx)

Full results:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all of the candidates, having a good group of candidates helps
engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We need to
ensure your voice is heard.

Thank you for another great round.
-Tristan


pgpGrPlOJz9Lg.pgp
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] [TripleO][Heat] Conditionally passing properties in Heat

[Dan Sneddon]

On 04/20/2017 12:37 AM, Steven Hardy wrote:
> On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote:
>> On 04/13/2017 12:01 AM, Rabi Mishra wrote:
>>> On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon >> > wrote:
>>>
>>> On 04/12/2017 01:22 PM, Thomas Herve wrote:
>>> > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon >> > wrote:
>>> >> I'm implementing predictable control plane IPs for spine/leaf,
>>> and I'm
>>> >> running into a problem implementing this in the TripleO Heat
>>> templates.
>>> >>
>>> >> I have a review in progress [1] that works, but fails on upgrade,
>>> so I'm
>>> >> looking for an alternative approach. I'm trying to influence the IP
>>> >> address that is selected for overcloud nodes' Control Plane IP.
>>> Here is
>>> >> the current construct:
>>> >>
>>> >>   Controller:
>>> >> type: OS::TripleO::Server
>>> >> metadata:
>>> >>   os-collect-config:
>>> >> command: {get_param: ConfigCommand}
>>> >> properties:
>>> >>   image: {get_param: controllerImage}
>>> >>   image_update_policy: {get_param: ImageUpdatePolicy}
>>> >>   flavor: {get_param: OvercloudControlFlavor}
>>> >>   key_name: {get_param: KeyName}
>>> >>   networks:
>>> >> - network: ctlplane  # <- Here's where the port is created
>>> >>
>>> >> If I add fixed_ip: to the networks element at the end of the above, I
>>> >> can select an IP address from the 'ctlplane' network, like this:
>>> >>
>>> >>   networks:
>>> >> - network: ctlplane
>>> >>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
>>> >>
>>> >> But the problem is that if I pass a blank string to fixed_ip, I
>>> get an
>>> >> error on deployment. This means that the old behavior of
>>> automatically
>>> >> selecting an IP doesn't work.
>>> >>
>>> >> I thought I has solved this by passing an external Neutron port,
>>> like this:
>>> >>
>>> >>   networks:
>>> >> - network: ctlplane
>>> >>   port: {get_attr: [ControlPlanePort, port_id]}
>>> >>
>>> >> Which works for deployments, but that fails on upgrades, since the
>>> >> original port was created as part of the Nova::Server resource,
>>> instead
>>> >> of being an external resource.
>>> >
>>> > Can you detail how it fails? I was under the impression we never
>>> > replaced servers no matter what (or we try to do that, at least). Is
>>> > the issue that your new port is not the correct one?
>>> >
>>> >> I'm now looking for a way to use Heat conditionals to apply the
>>> fixed_ip
>>> >> only if the value is not unset. Looking at the intrinsic
>>> functions [2],
>>> >> I don't see a way to do this. Is what I'm trying to do with Heat
>>> possible?
>>> >
>>> > You should be able to write something like that (not tested):
>>> >
>>> > networks:
>>> >   if:
>>> > - 
>>> > - network: ctlplane
>>> >   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
>>> > - network: ctlplane
>>> >
>>> > The question is how to define your condition. Maybe:
>>> >
>>> > conditions:
>>> >   fixed_ip_condition:
>>> >  not:
>>> > equals:
>>> >   - {get_attr: [ControlPlanePort, ip_address]}
>>> >   - ''
>>> >
>>> > To get back to the problem you stated first.
>>> >
>>> >
>>> >> Another option I'm exploring is conditionally applying resources. It
>>> >> appears that would require duplicating the entire TripleO::Server
>>> stanza
>>> >> in *-role.yaml so that there is one that uses fixed_ip and one
>>> that does
>>> >> not. Which one is applied would be based on a condition that tested
>>> >> whether fixed_ip was blank or not. The downside of that is that
>>> it would
>>> >> make the role definition confusing because there would be a large
>>> >> resource that was implemented twice, with only one line difference
>>> >> between them.
>>> >
>>> > You can define properties with conditions, so you shouldn't need to
>>> > rewrite everything.
>>> >
>>>
>>> Thomas,
>>>
>>> Thanks, I will try your suggestions and that should get me closer.
>>>
>>> The full error log is available here:
>>> 
>>> http://logs.openstack.org/78/413278/11/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/8d91762/console.html
>>> 
>>> 
>>>
>>> We do an interface_detach/attach when a port is replaced.
>>> It seems to be failing[1] as this is not implemented for
>>> ironic/baremetal driver.  I could see a patch[2] to add that

Re: [openstack-dev] [all][elections] Technical Committee Election Results

[Amrith Kumar]

And thanks to the election officials, Kendall, Tristan, and Tony.

-amrith 

--
Amrith Kumar
amrith.ku...@gmail.com


> -Original Message-
> From: Tristan Cacqueray [mailto:tdeca...@redhat.com]
> Sent: Thursday, April 20, 2017 8:35 PM
> To: openstack-dev@lists.openstack.org; openstack-annou...@lists.openstack.org
> Subject: [openstack-dev] [all][elections] Technical Committee Election
> Results
> 
> Please join me in congratulating the 7 newly elected members of the Technical
> Committe (TC).
> 
> Chris Dent (cdent)
> Davanum Srinivas (dims)
> Dean Troyer (dtroyer)
> Flavio Percoco (flaper87)
> John Garbutt (johnthetubaguy)
> Sean McGinnis (smcginnis)
> Thierry Carrez (ttx)
> 
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5
> 
> Election process details and results are also available here:
> https://governance.openstack.org/election/
> 
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
> 
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voice is heard.
> 
> Thank you for another great round.
> -Tristan


__
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] keeping on top of neutron reviews

[Armando M.]

On 20 April 2017 at 17:20, Kevin Benton  wrote:

> Thanks! Do you have the link to where that script lives? It would be good
> to have it in the neutron devref.
>

It's here:

https://docs.openstack.org/developer/neutron/devref/
effective_neutron.html#code-review



>
> On Thu, Apr 20, 2017 at 9:23 AM, Rossella Sblendido 
> wrote:
>
>> Hi all,
>>
>> I'd like to remind that there's a dashboard that it's populated every
>> day showing patches that are fixes for high/critical bugs, approved
>> blueprints and RFE. You can find it here [1] under "Gerrit Dashboard
>> links"
>>
>> cheers,
>>
>> Rossella
>>
>> [1] http://status.openstack.org/reviews/
>>
>> On 04/18/2017 12:45 AM, Kevin Benton wrote:
>> > Hello Neutron reviewers,
>> >
>> > Please keep an eye on the review links
>> > in https://docs.openstack.org/developer/neutron/dashboards/index.html
>> as
>> > part of your review routine.
>> >
>> > I went through and reviewed a lot of old patches over the weekend so if
>> > we keep on top of that list it shouldn't get out of hand.
>> >
>> > Cheers,
>> > Kevin Benton
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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] About use oslo_service in nova and fix for OSSN-0039

[Chen CH Ji]

Hi
 In https://wiki.openstack.org/wiki/OSSN/OSSN-0039, it's
requested that SSL/TLS library (OpenSSL in this case) is compiled without
SSLv3 ,
 our internal discussion from some security experts suggested
we need add some code to
https://github.com/openstack/nova/blob/master/nova/wsgi.py#L168
 maybe something like:   dup_socket = eventlet.wrap_ssl
(dup_socket, ssl_version=ssl.PROTOCOL_TLSv1_2,
 so that nova client only requests TLSv1_2

 so the question is
1) why nova didn't use oslo service, so we can honor some options like
following while seems nova don't have?
https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py#L108
https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py#L114

2) is there a existing requirement to nova (and maybe other projects) on
OSSN 0039 in addition to recompile ssl library?


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
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] [glance] virtual midcycle summary

[Brian Rosmaita]

Hello Glancers,

Due to technical difficulties, today's virtual midcycle was not
recorded.  So here's a summary of the discussion; refer to the etherpad
for each session for more details, and feel free to ask for
clarifications in #openstack-glance or here on the ML.

A link to the etherpads for each of the six sessions discussed below can
be found here:
https://etherpad.openstack.org/p/glance-pike-virtual-midcycle


1. Ideas for encouraging new contributors
=

We began with a quick discussion of the recent events that appear to
have wiped out a large number of Glance cores.  It was mentioned at the
TC meeting earlier this week that Glance might have to go into
status:maintenance-mode, but we'd like to try to avoid that.  While you
could look at maintenance mode as a signal that the project needs more
help, it could also be perceived by prospective new contributors as a
reason not to work on Glance, and hence would be counterproductive with
respect to attracting new people to work on Glance.  In any case, we
decided to wait until after the summit when we should have a better idea
of what kind of developer resources Glance has.

We need a statement somewhere (maybe on the standing meeting agenda)
explaining the weekly priority emails, in two respects:

(a) The priorities listed aren't the only things that get attention in
any given week; the idea is that core reviewers should make sure the
priority items have all been reviewed before looking at other patches.

(b) The priorities for the week are set at the weekly Glance meeting.
So the way to get an item on the list is to make sure it's brought up
when priorities are discussed at the meeting, which in turn implies that
you should be present at the weekly meeting.

A strategy we'll try out to encourage new contributors is to have a
second weekly meeting attended by all the core reviewers, who will be
available at that time to answer questions about patches.  If no one
shows up, we can just work through the backlog of patches.  (Another
idea is that this weekly meeting could alternate between reviews and
bugs.)  This will start after the summit.

Finally, Nikhil and Erno (and possibly Flavio) will be at the Glance
on-boarding session during lunch on Monday at the summit (12:45-2:00),
so hopefully we can pick up some new contributors there.


2. How the $*@# are we going to complete image import?
==

This went much differently than I expected.  You can see the proposal
for an "economy-class" import outlined on the session etherpad, but Erno
made a convincing argument that we should stick with the current plan
and that an MVP can be completed in Pike (given other appropriate
adjustments to the Pike priorities).  So that's what we'll do.  Pike
will ship with import "off" so that there's no impact on deployers who
aren't interested in it yet.


3. A proposal for dealing with OSSN-0075


We discussed a proposal to introduce a new policy that would restrict
the ability to specify an image_id at the time an image is created.
Objections were that it's a breaking change, and that not having this
feature widely available would be a pain point for hybrid cloud use cases.

What we settled on was to modify the glance-manage db purge function to
purge images marked deleted *except* for those with 'public' visibility,
since those are the images that would most likely be attacked by this
exploit.  They're also likely to be a minority of images, especially
since the advent of community images in Ocata.

I'll write up a spec lite so that we can get more discussion on this
idea, and make sure it's publicized to the operators' list and security
team to get a wide set of comments.


4. What's remaining for zero-downtime upgrades, and what's our plan to
make it happen?
===

The dev docs explaining how to write the migrations have been completed.

We need to review/revise the operator docs explaining how to perform a
zero-downtime database migration.

Asserting the tags requires having upgrade tests in the gate.  There's
not likely going to be any bandwidth for working on this in Pike, so we
won't worry about trying to assert the tags until Queens.


5. Last chance for Pike specs
=

We have some good specs proposed for Pike, but it's not clear anymore
that there will be anyone to work on them.  We'll add an 'untargeted'
directory to the specs repo for specs that have been approved but not
implemented (so that they'll all be in one place; now you have to crawl
each previous release to find the approved-but-not-implemented specs).

See the specs review etherpad for more details; each spec proposed for
Pike has an "action" associated with it that describes what we decided
today.  (I'll get patches up in the next day or so completing the
"actions" and moving the specs around in the repo.)


6. Finalizing the 

Re: [openstack-dev] [oslo] Can we stop global requirements update?

[Joshua Harlow]

Doug Hellmann wrote:

Excerpts from gordon chung's message of 2017-04-20 17:12:26 +:

On 20/04/17 01:32 AM, Joshua Harlow wrote:

Wasn't there also some decision made in austin (?) about how we as a
group stated something along the line of co-installability isn't as
important as it once was (and may not even be practical or what people
care about anymore anyway)?


I don't remember that, but I may not have been in the room at the
time.  In the past when we've discussed that idea, we've continued
to maintain that co-installability is still needed for distributors
who have packaging constraints that require it and for use cases
like single-node deployments for POCs.


Ya, looking back I think it was:

https://etherpad.openstack.org/p/newton-global-requirements

I think that was robert that lead that session, but I might be incorrect 
there.





With kolla becoming more popular (tripleo I think is using it, and ...)
and the containers it creates making isolated per-application
environments it makes me wonder what of global-requirements is still
valid (as a concept) and what isn't.


We still need to review dependencies for license compatibility, to
minimize redundancy, and to ensure that we're not adding things to
the list that are not being maintained upstream. Even if we stop syncing
versions, official projects need to be those reviews, and having the
global list is a way to ensure that the reviews are done.


I do remember the days of free for all requirements (or requirements
sometimes just put/stashed in devstack vs elsewhere), which I don't
really want to go back to; but if we finally all agree that
co-installability isn't what people actually do and/or care about
(anymore?) then maybe we can re-think some things?

agree with all of ^... but i imagine to make progress on this, we'd have
to change/drop devstack usage in gate and that will take forever and a
lifetime (is that a chick flick title?) given how embedded devstack is
in everything. it seems like the solution starts with devstack.

cheers,



__
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] [monasca][swift][storyboard] migration experience

[Hochmuth, Roland M]

Hi John, Comments in-line below. I'm hoping that someone else will add more 
details.




On 4/17/17, 2:50 PM, "John Dickinson"  wrote:

>Moasca-teers
>
>As the migration away from Launchpad and to Storyboard moves forward,
>the Swift team has been considering making the move. Monasca has
>already made the move, so I'd love to hear your thoughts on that
>process.
>
>1) How did you do the change? All at once or gradually? If you did it
>over again, would you do it the same way?

[RH]: The change was done all at once and yes I would do it the same way. The 
migration went smoothly.
>
>2) Are you missing anything from the migration? How do you manage
>security bugs that are embargoed?

[RH]: It hasn't been very long since the change. I don't believe we've run into 
any issues other than folks getting used to it. For example, getting the story 
and task ID in the commit message.
>
>3) How are you managing being "different" in the OpenStack community
>for where to go file bugs or track work?

[RH]: It takes a bit of reminding as the old habits are hard to change. Since 
our community of developers is rather small we are able to track this. However, 
we have had some bugs get created in launchpad after the merge, which we'll 
need to migrate to storyboard. 
>
>4) Have you had any negative impact from old links to Launchpad bugs?
>What about links in commit messages? How did you manage links in
>patches that were open at the time of migration?

[RH]: It has been a little painful getting links in commit messages updated.
>
>5) What other thoughts do you have on the move?

[RH]: That is a good question. Maybe we should do a retrospective on this topic 
during our next meeting.
>
>Thank you for your time and thoughts,
>
>
>John
>
>
>
>
>
__
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] [release][monasca] Release of openstack/monasca-kibana-plugin failed

[Hochmuth, Roland M]

Thanks Doug. My understanding of the issue is that we need to

1. Update the version in package.json, 
https://github.com/openstack/monasca-kibana-plugin/blob/master/package.json, 
from "0.0.5" to "1.0.1". 
2. Cherry pick to Ocata.
3. Then apply a new release tag for Ocata for 1.0.1 in, 
https://review.openstack.org/#/c/433823/1/deliverables/ocata/monasca-kibana-plugin.yaml.

Does that sound correct?

Regards --Roland





On 4/20/17, 1:41 PM, "Doug Hellmann"  wrote:

>Excerpts from Doug Hellmann's message of 2017-04-20 15:26:47 -0400:
>> The version of monasca-kibana-plugin in package.json does not match the
>> new tag, and that caused the publish job to fail. I'm available to help
>> debug or to quickly release an update after the problem is fixed.
>
>https://review.openstack.org/458629 should help us avoid this error in
>the future.
>
>> 
>> Doug
>> 
>> --- Begin forwarded message from jenkins ---
>> From: jenkins 
>> To: release-job-failures 
>> Date: Wed, 19 Apr 2017 10:01:01 +
>> Subject: [Release-job-failures] Release of openstack/monasca-kibana-plugin 
>> failed
>> 
>> Build failed.
>> 
>> - monasca-kibana-plugin-nodejs4-npm-publish-tarball 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-nodejs4-npm-publish-tarball/4852b10/
>>  : SUCCESS in 4m 48s
>> - monasca-kibana-plugin-tarball-signing 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-tarball-signing/28e6145/
>>  : SUCCESS in 10s
>> - monasca-kibana-plugin-npm-upload 
>> http://logs.openstack.org/20/206249d12cb76a103cb84a851916ce415f7d5cf8/release/monasca-kibana-plugin-npm-upload/f3dd81a/
>>  : FAILURE in 9s
>> - monasca-kibana-plugin-announce-release 
>> monasca-kibana-plugin-announce-release : SKIPPED
>> 
>> --- End forwarded message ---
>> 
>
>__
>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] [kolla] Demystifying the kolla-kubernetes gate

[Matt Young]

Is there an invite for this?  I'm interested.

On Apr 19, 2017 1:20 PM, "Steven Dake (stdake)"  wrote:

Hey folks,



I am holding a workshop on how the kolla-kubernetes gate operates.  If you
are interested in this workshop, please sign up here:



http://doodle.com/poll/bee7umevf43nwi6y



Regards,

-steve



__
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] keeping on top of neutron reviews

[Kevin Benton]

Thanks! Do you have the link to where that script lives? It would be good
to have it in the neutron devref.

On Thu, Apr 20, 2017 at 9:23 AM, Rossella Sblendido 
wrote:

> Hi all,
>
> I'd like to remind that there's a dashboard that it's populated every
> day showing patches that are fixes for high/critical bugs, approved
> blueprints and RFE. You can find it here [1] under "Gerrit Dashboard links"
>
> cheers,
>
> Rossella
>
> [1] http://status.openstack.org/reviews/
>
> On 04/18/2017 12:45 AM, Kevin Benton wrote:
> > Hello Neutron reviewers,
> >
> > Please keep an eye on the review links
> > in https://docs.openstack.org/developer/neutron/dashboards/index.html as
> > part of your review routine.
> >
> > I went through and reviewed a lot of old patches over the weekend so if
> > we keep on top of that list it shouldn't get out of hand.
> >
> > Cheers,
> > Kevin Benton
> >
> >
> > 
> __
> > 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] [Blazar] Meeting time slots in Boston

[Masahito MUROI]

Hi all,

Thanks for choosing time slots!  Based on the table of Doodle, I'd like 
to pick following two slots for Blazar team meeting.


1. 1pm-4pm on Monday for Blazar's internal features
2. 9am-10am or 11am on Thursday for discussions with PlacementAPI team

The first meeting will focus on Blazar's internal features, roadmap and 
etc.  1pm-2pm is also Lunch time. So it could start as lunch meeting.


In the second slot, we plan to discuss with PlacementAPI team. Summit 
would have breakout rooms or tables as usual.  We'll gather one of these 
and discuss concerns and/or usecases of collaboration with PlacementAPI.



best regards,
Masahito


On 2017/04/18 13:21, Masahito MUROI wrote:

Hi Blazar folks,

I created doodle[1] to decide our meeting time slots in Boston summit.
Please check slots you can join the meeting by Thursday.  I'll decide
the slots on this Friday.

Additionally, I'd like to ask you to write down how many hours we have
the meeting in comments of the page.

1. http://doodle.com/poll/a7pccnhqsuk9tax7

best regards,
Masahito


__
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



--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] Reflections on the pike-1 milestone

[Maish Saidel-Keesing]

Perfect explanation and very clear - Thanks Matt!!


On 20/04/17 21:18, Matt Riedemann wrote:
> On 4/20/2017 2:01 AM, Maish Saidel-Keesing wrote:
>> Just as a matter of interest - from the numbers above you say 62
>> blueprints approved - was this only for this cycle - or *up until* this
>> cycle.
>>
>> When you mention several up for review - can you elaborate on exact
>> numbers?
>>
>> I am not looking to 'monitor' activity - but for me it would be
>> interesting to understand - what the workload is actually like. If the
>> ratio of 'incoming work' (blueprints) vs. completed/in-review is 62:3
>> then to me - this seems to be something that needs to be addressed.
>>
>> Or am I misunderstanding the comment above?
>
> That means 62 blueprints approved for Pike (this cycle). This does not
> mean the code is merged and the blueprint is completed. It means we
> agreed on the design proposal and can move forward with code for the
> blueprint.
>
> Several up for review means there are approved blueprints with code
> ready for review (they have started, or are more than just a POC).
> These numbers are probably low right now, but all blueprints targeted
> for Pike [1] with Delivery status of "Needs Code Review" is what I'm
> referring to here, which is currently 38.
>
> As for incoming work, and the ratio you point out, is not unusual in
> the first milestone before we do our spec freeze, where we then stop
> accepting new blueprint proposals for the release so we can focus on
> implementing and reviewing what we've already planned to do.
>
> If you want a much more detailed explanation of the numbers and
> trends, I provided that after the Ocata release [2].
>
> [1] https://blueprints.launchpad.net/nova/pike
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2017-February/111639.html
>

-- 
Best Regards,
Maish Saidel-Keesing

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

Re: [openstack-dev] [oslo] Can we stop global requirements update?

[Doug Hellmann]

Excerpts from gordon chung's message of 2017-04-20 17:12:26 +:
> 
> On 20/04/17 01:32 AM, Joshua Harlow wrote:
> > Wasn't there also some decision made in austin (?) about how we as a
> > group stated something along the line of co-installability isn't as
> > important as it once was (and may not even be practical or what people
> > care about anymore anyway)?

I don't remember that, but I may not have been in the room at the
time.  In the past when we've discussed that idea, we've continued
to maintain that co-installability is still needed for distributors
who have packaging constraints that require it and for use cases
like single-node deployments for POCs.

> > With kolla becoming more popular (tripleo I think is using it, and ...)
> > and the containers it creates making isolated per-application
> > environments it makes me wonder what of global-requirements is still
> > valid (as a concept) and what isn't.

We still need to review dependencies for license compatibility, to
minimize redundancy, and to ensure that we're not adding things to
the list that are not being maintained upstream. Even if we stop syncing
versions, official projects need to be those reviews, and having the
global list is a way to ensure that the reviews are done.

> > I do remember the days of free for all requirements (or requirements
> > sometimes just put/stashed in devstack vs elsewhere), which I don't
> > really want to go back to; but if we finally all agree that
> > co-installability isn't what people actually do and/or care about
> > (anymore?) then maybe we can re-think some things?
> 
> agree with all of ^... but i imagine to make progress on this, we'd have 
> to change/drop devstack usage in gate and that will take forever and a 
> lifetime (is that a chick flick title?) given how embedded devstack is 
> in everything. it seems like the solution starts with devstack.
> 
> cheers,
> 

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

Re: [openstack-dev] [puppet][fuel] stepping down from puppet/fuel core groups

[Alex Schultz]

On Thu, Apr 20, 2017 at 4:44 AM, Denis Egorenko  wrote:
> Hello puppet'ers!
>
> Now it's time to say "Goodbay" to you, i'm leaving Mirantis and as well
> stepping down from Puppet/Fuel core groups.
>
> It was a really cool to work with all of you! I've learn a lot! Thank you
> all for all your help and advises.
>
> Also want to especially say "Thank you" to Emilien Macchi, Alex Schultz,
> Sergii Golovatiuk, Vladimir Kuklin and other core guys - you're best! :)
>
> If you will need my help, please don't hesitate to add me to review or reach
> me: egorenko@gmail.com
>
> Thank you and good luck!
>

Thanks for everything Denis. And good luck on your future adventures.

Thanks,
-Alex

> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> 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]

[Don maillist]

Does Ironic currently support non X86 systems? I have a power PC ATCA blade
that I need to be used as a very specific blade function. I would need to
PXE boot the blade to a ramdisk if possible (There are no hard drives. Only
a flash drive).

Best Regards,
Don
__
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] [api] API-WG Liaisons in need of updates

[Chris Dent]

Near the end of the review process for new guidelines produced by
the API-WG a guideline is "frozen" and presented for review by the
wider OpenStack community. At that time the people who have
self-identified as liaisons to the working group from the projects
that produce APIs are added as reviewers to the guideline.

That adding is managed by a JSON file that associates projects with
designated liaisons:

http://git.openstack.org/cgit/openstack/api-wg/tree/doc/source/liaisons.json

It's been a while since that file has been updated, so there are
plenty of projects that are not represented at all and some projects
which are represented by people who have moved on. This means that
in some cases guidelines are being merged without being fully vetted
by the entire community.

If project members could provide up to date information for that
file, that would help ensure that guidelines are most effectively
verified before being published. Either submit a change to the file
or ask cdent, elmiko or edleafe in #openstack-sdks to do it for you.

Thanks!

For more information see:

* https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group
* http://specs.openstack.org/openstack/api-wg/liaisons.html

--
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] Launchpad bugs cleaning day on Tuesday 4/25

[Markus Zoeller]

On 20.04.2017 00:44, Maciej Szankin wrote:
> We are going to have a Launchpad bugs cleaning day for Nova on Tuesday 4/25.
> 
> This day will be purely about cleaning the garbage out of the Launchpad -
> it is not the bug squashing day where people propose patches.
> 
> If you are not familiar with bug triage, please refer to [1].
> 
> As indicated by the dashboard [2] created by Markus, we currently have:
> 
> * 75 bugs that are inconsistent
> * 44 bugs that are incomplete
> * 44 bugs that are stale incomplete
> * 170 bugs that are stale in progress
> 
> We also currently have 787 open bug reports (291 confirmed, 63 new), which
> is a lot.
> Keeping the bug queue ordered is just as important as doing reviews and
> contributes
> to overall development of Nova.
> 
> All help is more than welcome.
> 
> [1] https://wiki.openstack.org/wiki/Nova/BugTriage
> [2] http://45.55.105.55:8082/bugs-dashboard.html
> 
> Cheers,
> Maciej
> 
> 

You might also like to consider to expire some of the old bug reports
(>18months):
https://github.com/markuszoeller/openstack/blob/master/scripts/launchpad/expire_old_bug_reports.py

I did that back in July 2016 (be aware that some people may not like that):
http://openstack.markmail.org/thread/i4drtyqddluwnp2m

-- 
Regards, Markus Zoeller (markus_z)


__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Tom Fifield]

Still no email over here :)

On 20/04/17 14:43, Kevin Benton wrote:

FWIW mine just came through yesterday.

On Wed, Apr 19, 2017 at 12:13 PM, Jay S Bryant > wrote:

All,

For those of you haven't received an e-mail, check the inbox you use
for Gerrit.  You can verify what that is by going to
review.openstack.org  , click your
name, go to settings, the e-mail address is set there.

The naming vote and the TC vote e-mails got lost in that inbox for me.

Hopes this helps.

Jay




On 4/12/2017 7:09 AM, Dulko, Michal wrote:

On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:

On 04/06/2017 07:34 AM, Monty Taylor wrote:

Hey all!

I've started the R Release Name poll and currently am
submitting
everyone's email address to the system. In order to not
make our fine
friends at Carnegie Mellon (the folks who run the CIVS
voting service)
upset, I have a script that submits the emails one at a
time with a
half-second delay between each email. That means at
best, since there
are 40k people to process it'll take ~6 hours for them
all to go out.

Which is to say - emails are on their way - but if you
haven't gotten
yours yet, that's fine. I'll send another email when
they've all gone
out, so don't worry about not receiving one until I've
sent that mail.

Well- that took longer than I expected. Because of some rate
limiting,
1/2 second delay was not long enough...

Anyway - all of the emails should have gone out now. Because
that took
so long, I'm going to hold the poll open until next Wednesday.

Monty

Not sure why, but I haven't received an email yet.

Thanks,
Michal

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 




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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__
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] [glance] reminder: virtual midcycle at 14:00 UTC today

[Brian Rosmaita]

The Glance virtual midcycle is being held today (Thursday 20 April) from
14:00-17:00 UTC.

Please see the etherpad for signup, agenda, and connection information:

https://etherpad.openstack.org/p/glance-pike-virtual-midcycle

cheers,
brian

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

[openstack-dev] [puppet][fuel] stepping down from puppet/fuel core groups

[Denis Egorenko]

Hello puppet'ers!

Now it's time to say "Goodbay" to you, i'm leaving Mirantis and as well
stepping down from Puppet/Fuel core groups.

It was a really cool to work with all of you! I've learn a lot! Thank you
all for all your help and advises.

Also want to especially say "Thank you" to Emilien Macchi, Alex Schultz,
Sergii Golovatiuk, Vladimir Kuklin and other core guys - you're best! :)

If you will need my help, please don't hesitate to add me to review or
reach me: egorenko@gmail.com

Thank you and good luck!

-- 
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
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][ptls][tc] help needed filling out project-navigator data

[Andrey Kurilin]

Hi folks!

Does it possible to store history of the project without alignment to
OpenStack releases?

2017-04-19 17:54 GMT+03:00 Jimmy McArthur :

> Ideally, as far back as your project goes. That way we will have a
> complete API history, per release, on the project navigator.  This also
> helps us determine the project age.
>
> Thanks!
> Jimmy
>
> Telles Nobrega 
> April 19, 2017 at 9:48 AM
> Hi Monty,
>
> quick question, how far into past releases should we go?
>
> Thanks,
>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat I 
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
> __
> 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
> Monty Taylor 
> April 18, 2017 at 3:03 PM
> Hey everybody!
>
> The Foundation is rolling out a new version of the Project Navigator. One
> of the things it contains is a section that shows API versions available
> for each project for each release. They asked the TC's help in providing
> that data, so we spun up a new repository:
>
>   http://git.openstack.org/cgit/openstack/project-navigator-data
>
> that the Project Navigator will consume.
>
> We need your help!
>
> The repo contains a file for each project for each release with
> CURRENT/SUPPORTED/DEPRECATED major versions and also microversion ranges if
> they exist. The data is pretty much exactly what everyone already produces
> in their version discovery documents - although it's normalized into the
> format described by the API-WG:
>
>
> https://specs.openstack.org/openstack/api-wg/guidelines/
> microversion_specification.html#version-discovery
>
> What would be really helpful is if someone from each project could go make
> a patch to the repo adding the historical (and currently) info for your
> project. We'll come up with a process for maintaining it over time - but
> for now just crowdsourcing the data seems like the best way.
>
> The README file explains the format, and there is data from a few of the
> projects for Newton.
>
> It would be great to include an entry for every release - which for many
> projects will just be the same content copied a bunch of times back to the
> first release the project was part of OpenStack.
>
> This is only needed for service projects (something that registers in the
> keystone catalog) and is only needed for 'main' APIs (like, it is not
> needed, for now, to put in things like Placement)
>
> If y'all could help - it would be super great!
>
> Thanks!
> Monty
>
> __
>
> 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
>
>


-- 
Best regards,
Andrey Kurilin.
__
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] [QA] Meeting Thursday April 20th at 9:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, April 20th at 9:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:

https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_20th_2017_.280900_UTC.29

Anyone is welcome to add an item to the agenda.

Sorry for short notice.

-gmann

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

[openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

[Sean McGinnis]

Unfortunately I am way late at noticing this, but bringing it up in case
there's anything that can still be done about it.

Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me.
The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the
Cinder - Project Onboarding sessions are all at this slot.

While onboarding is something I feel is really imortant, out of these as
it is now I think I would have to go with the Cinder Nova discussion. But
that really would be a shame to have to miss that. I also would really
like to be part of the Track Chair discussion, but if I have to rank
these, that one will have to be last. I'm guessing there's really no
good time for that session that is not going to cause a conflict for
somebody.

So my question for the scheduling powers that be - is there any chance
we can move either the Cinder Onboarding or the Cinder-Nova sessions?

Thanks,
Sean (smcginnis)


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

Re: [openstack-dev] [Cinder][Nova] Scheduling issue for the Summit

[Sean McGinnis]

Will do, thanks!

On Thu, Apr 20, 2017 at 09:59:39AM -0500, Jimmy McArthur wrote:
> Sean,
> 
> Can you send this request into speakersupp...@openstack.org and we'll see if
> we can move it around.
> 
> Thanks,
> Jimmy
> 
> >Sean McGinnis 
> >April 20, 2017 at 9:55 AM
> >Unfortunately I am way late at noticing this, but bringing it up in case
> >there's anything that can still be done about it.
> >
> >Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me.
> >The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the
> >Cinder - Project Onboarding sessions are all at this slot.
> >
> >While onboarding is something I feel is really imortant, out of these as
> >it is now I think I would have to go with the Cinder Nova discussion. But
> >that really would be a shame to have to miss that. I also would really
> >like to be part of the Track Chair discussion, but if I have to rank
> >these, that one will have to be last. I'm guessing there's really no
> >good time for that session that is not going to cause a conflict for
> >somebody.
> >
> >So my question for the scheduling powers that be - is there any chance
> >we can move either the Cinder Onboarding or the Cinder-Nova sessions?
> >
> >Thanks,
> >Sean (smcginnis)
> >
> >
> >__
> >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] [Cinder][Nova] Scheduling issue for the Summit

[Jimmy McArthur]

Sean,

Can you send this request into speakersupp...@openstack.org and we'll 
see if we can move it around.


Thanks,
Jimmy


Sean McGinnis 
April 20, 2017 at 9:55 AM
Unfortunately I am way late at noticing this, but bringing it up in case
there's anything that can still be done about it.

Tuesday the 9th, from 11:15am-11:55am, is going to be a challenge for me.
The Track Chairs Recap, Using Cinder for Nova Ephemeral Storage, and the
Cinder - Project Onboarding sessions are all at this slot.

While onboarding is something I feel is really imortant, out of these as
it is now I think I would have to go with the Cinder Nova discussion. But
that really would be a shame to have to miss that. I also would really
like to be part of the Track Chair discussion, but if I have to rank
these, that one will have to be last. I'm guessing there's really no
good time for that session that is not going to cause a conflict for
somebody.

So my question for the scheduling powers that be - is there any chance
we can move either the Cinder Onboarding or the Cinder-Nova sessions?

Thanks,
Sean (smcginnis)


__
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] [puppet] Warning running low of contributors

[Alex Schultz]

Hey folks,

So in recent months, we've seen a drop off contributors and reviewers
to the various Puppet OpenStack modules. Additionally with the recent
resignation of a few of our cores, we're getting to a spot where the
modules under the Puppet OpenStack umbrella are becoming dangerously
close to being single-vendor. This means if we don't see any
additional contributors and the single vendor leaves, the modules will
no longer be updated.  I've previously mentioned this in the chef
thread[0] from earlier this year.

If you currently use Puppet to manage your OpenStack systems, please
consider contributing to upstream[1].

Thanks,
-Alex

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112194.html
[1] https://docs.openstack.org/developer/puppet-openstack-guide/

__
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] Asking Survey for I18n translation platform - Zanata usability

[Ian Y. Choi]

Hello all OpenStackers!

I am Ian from I18n team and I am doing PTL in Pike cycle.

Zanata is an open source translation tool - not only I18n team members 
but also many OpenStack translators

now mainly use Zanata as OpenStack translation platform [2].

Zanata development team wants users to do the following survey to 
collect feedback, but IMO it is not just limited to users.
If you have experienced Zanata on development and/or documentation side, 
then I would like to ask you to take the survey.


Please go to the following URL and participate in answering survey 
questionnaires:


- 
https://docs.google.com/forms/d/e/1FAIpQLSeqxia866yOv1GZEmCqCenzT31RO6gzndJ1w7QetRr6NvGvfQ/viewform?usp=sf_link


According to Zanata team, the survey will close on 6th May.

Note: If someone still remember Transifex and is not familiar with 
Zanata, [3] might be helpful to see

  the background of the migration from Transifex to Zanata.


With many thanks,

/Ian

[1] http://zanata.org/
[2] https://translate.openstack.org
[3] 
http://princessleia.com/journal/2015/09/the-migration-of-openstack-translations-to-zanata/



 Original Message 
Subject:Re: [OpenStack-I18n] Survey for Zanata platform
Date:   Thu, 20 Apr 2017 12:43:33 +1000
From:   Alex Eng 
To: Openstack-i18n Openstack-i18n 



Guys,

Sorry for this, but the updated link for the survey:
https://docs.google.com/forms/d/e/1FAIpQLSeqxia866yOv1GZEmCqCenzT31RO6gzndJ1w7QetRr6NvGvfQ/viewform?usp=sf_link 



On Thu, Apr 20, 2017 at 11:33 AM, Alex Eng > wrote:


   Hi guys,

   As part of our plan to improve Zanata translation platform, it is
   important for us to constantly collect feedback from users to
   understand problems and needs.

   It would be appreciated if you guys can spent few minutes to
   complete the survey

   https://drive.google.com/open?id=1lcbmbJ1snljrd5t_nRyGgDTH7SRWpp6PBKJaq7UiQkM
   



   PS. The survey will be closed on 6/MAY.

   Regards,

   -- 


   ALEX ENG

   SENIOR SOFTWARE ENGINEER, TEam lead

   Red Hat Asia-Pacific Pty Ltd 

   Level 1, 193 North Quay

   Brisbane 4000

   a...@redhat.com  M: +61423353457
    IM: aeng

   




--

ALEX ENG

SENIOR SOFTWARE ENGINEER

Red Hat Asia-Pacific Pty Ltd 

Level 1, 193 North Quay

Brisbane 4000

a...@redhat.com  M: +61423353457 
 IM: aeng




___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
__
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] [ironic] New mascot design

[Mateusz Kowalski]

Hi all,

Any updates on it ?
We would like to start using the logo, but the only version is the one from the 
email bellow with a grey background. Can we expect having rest of "the branding 
set" ?

Cheers,
Mateusz

> On 20 Mar 2017, at 15:47, Mario Villaplana  wrote:
> 
> +1, this looks like a nicely stylized version of PXE Boots. Thanks!
> 
> Mario
> 
> On Mon, Mar 13, 2017 at 3:25 PM, Jim Rollenhagen  
> wrote:
>> 
>> On Fri, Mar 10, 2017 at 11:28 AM, Heidi Joy Tretheway
>>  wrote:
>>> 
>>> Hi Ironic team,
>>> Here’s an update on your project logo. Our illustrator tried to be as true
>>> as possible to your original, while ensuring it matched the line weight,
>>> color palette and style of the rest. Thanks for your patience as we worked
>>> on this! Feel free to direct feedback to me; we really want to get this
>>> right for you.
>> 
>> 
>> This is fantastic! Thank you for putting up with us, I think it turned out
>> well in the end.
>> 
>> // jim
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



smime.p7s
Description: S/MIME cryptographic 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] [stable][heat] Nominate huangtianhua for heat-stable-maint

[Zane Bitter]

bump

On 30/03/17 16:45, Zane Bitter wrote:

We are feeling the pinch on stable-branch reviewers in Heat, so now that
I understand the process a bit better, let's try this again.

I'd like to nominate Huang Tianhua to join the heat-stable-maint team.
Tianhua is a heat-core member and one of our most prolific stable branch
reviewers:

https://review.openstack.org/#/q/reviewer:huangtianhua+-owner:huangtianhua+projects:openstack/heat+branch:%22%255Estable/.*%22


IMHO her track record displays an understanding of the stable branch
policies appropriate to a stable branch core. e.g.

* https://review.openstack.org/#/c/434030/
* https://review.openstack.org/#/c/371135/
* https://review.openstack.org/#/c/244948/

Also, I suggest we take this opportunity to remove Angus Salkeld, since
he is no longer actively working on OpenStack
(http://stackalytics.com/?release=all_id=asalkeld)

thanks,
Zane.

__
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][Heat] Conditionally passing properties in Heat

[Zane Bitter]

On 20/04/17 03:37, Steven Hardy wrote:

On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote:

Unfortunately, I tried the recommendation that Thomas Herve made about
using conditionals, but that failed. It appears that you can't use a
get_attr inside of a conditional statement, I get an error to that
effect. I can use a get_param, but that doesn't help me check a value in
a nested stack.


Yes I noticed the same thing recently, which is a limitation of conditions
that IMO we should look at fixing - everywhere else in HOT templates
get_param and get_attr can be used interchangably.


Right, but conditions are essentially preprocessor macros. They can't 
depend on data that is not available until runtime.


- ZB

__
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] [ceilometer]Looking for endpoint where event passed after first time

[gordon chung]

On 20/04/17 01:46 AM, Hui Xiang wrote:
> And yes I have known that ceilometer notification agent will listen for
> the notification topics, but my question is which file/class will do it.
> When I am debugging the code, at the first time when the event send out
> to ceilometer exchange notification topic, EventsNotificationEndpoint
>  in event/endpoint.py will handle it, however, when I send the same
> event again, with log/pdb enabled, the event is not processed in
> EventsNotificationEndpoint any more, and I can't find where it is done.
> It looks so weird or maybe that is by design for some reason? The
> behavior is same with/without definition in event_definition.yaml

this listener[1] is loading EventsNotificationEndpoint. if you look at 
EventsNotificationEndpoint, you can see it picks up stuff on .info and 
.error topics and normalises them to Event obj.

i'm assuming you're using oslo.messaging to push to queue as well. i 
don't think the system works if you are pushing your own format to queue.


>
> So I wonder how is different for the workflow by sending same events twice.

there is no difference. only difference is a different agent might be 
handling it (if you have multiple notification agents)

[1] 
https://github.com/openstack/ceilometer/blob/stable/mitaka/ceilometer/notification.py#L242-L245

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

Re: [openstack-dev] [puppet][fuel] stepping down from puppet/fuel core groups

[Emilien Macchi]

On Thu, Apr 20, 2017 at 6:44 AM, Denis Egorenko  wrote:
> Hello puppet'ers!
>
> Now it's time to say "Goodbay" to you, i'm leaving Mirantis and as well
> stepping down from Puppet/Fuel core groups.
>
> It was a really cool to work with all of you! I've learn a lot! Thank you
> all for all your help and advises.
>
> Also want to especially say "Thank you" to Emilien Macchi, Alex Schultz,
> Sergii Golovatiuk, Vladimir Kuklin and other core guys - you're best! :)

It was a real pleasure to work with you, your impact on the Puppet
modules has been really impressive.
Enjoy your next things and... have fun!

> If you will need my help, please don't hesitate to add me to review or reach
> me: egorenko@gmail.com
>
> Thank you and good luck!
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> Mirantis
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

[openstack-dev] [fuel] Weekly meeting April 20th is cancelled

[Vladimir Kuklin]

Fuelers

Agenda is empty for today, so the meeting is cancelled.
__
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] [ironic]

[Michael Turek]

Hey Don,

Deployment to Power8 and beyond via the agent-ipmitool driver should 
work fine. We test it regularly here:


https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI

If you'd like some help setting up Ironic for power, feel free to ping 
me on #openstack-ironic. Also check out this blog that I worked on with 
a colleague for some advice:


https://developer.ibm.com/linuxonpower/2017/03/20/setting-openstack-bare-metal-service-power8/

Also a friendly reminder that this question is probably more suited for 
the OpenStack mailing list rather than openstack-dev.


Thanks,
mjturek

On 04/20/2017 08:16 AM, Don maillist wrote:
Does Ironic currently support non X86 systems? I have a power PC ATCA 
blade that I need to be used as a very specific blade function. I 
would need to PXE boot the blade to a ramdisk if possible (There are 
no hard drives. Only a flash drive).


Best Regards,
Don


__
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] [Taskflow] Current state or the project ?

[Michael Johnson]

Hi Robin,

 

The Octavia project (shameless plug: 
https://docs.openstack.org/developer/octavia/) relies on TaskFlow for the core 
workflow.  For us, the TaskFlow project is very stable.

 

Michael

 

From: Robin De-Lillo [mailto:rdeli...@rodeofx.com] 
Sent: Wednesday, April 19, 2017 11:14 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Taskflow] Current state or the project ?

 

Hello Guys,

 

I'm Robin a Software developer for a VFX company based in Canada. As the 
company grow up, we are currently looking into redesigning our internal 
processes and workflows in a more nodal/graph based approach.

 

Ideally we would like to start from an existing library so we don't 
re-implement things from scratch. We found out TaskFlow which, after a couple 
of tests, looks very promising to us. Good work with that !!

 

We were wondering what is the current state of this project ? Is that still 
something under active development or a priority for OpenStack ? As we would 
definitely be happy to contribute to this library in the future, we are just 
gathering information around for now to ensure we pick up the best solution 
which suit our needs.

 

Thanks a lot,

Robin De Lillo

__
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] keeping on top of neutron reviews

[Rossella Sblendido]

Hi all,

I'd like to remind that there's a dashboard that it's populated every
day showing patches that are fixes for high/critical bugs, approved
blueprints and RFE. You can find it here [1] under "Gerrit Dashboard links"

cheers,

Rossella

[1] http://status.openstack.org/reviews/

On 04/18/2017 12:45 AM, Kevin Benton wrote:
> Hello Neutron reviewers,
> 
> Please keep an eye on the review links
> in https://docs.openstack.org/developer/neutron/dashboards/index.html as
> part of your review routine.
> 
> I went through and reviewed a lot of old patches over the weekend so if
> we keep on top of that list it shouldn't get out of hand.
> 
> Cheers,
> Kevin Benton
> 
> 
> __
> 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] Development workflow for bunch of patches

[Jeremy Stanley]

On 2017-04-19 15:48:04 -0700 (-0700), Clark Boylan wrote:
[...]
> The way I work is to always edit the tip of the series then "squash
> back" edits as necessary.
> So lets say we already have A <- B <- C and now I want to edit A and
> push everything back so that it is up to date.
> 
> To do this I make a new commit such that A <- B <- C <-D then `git
> rebase -i HEAD~4` and edit the rebase so that I have:
> 
>   pick A
>   squash D
>   pick B
>   pick C
> 
> Then after rebase I end up with A' <- B' <- C' and when I git review all
> three are updated properly in gerrit. The basic idea here is that you
> are working on a series not a single commit so any time you make changes
> you curate the entire series.
[...]

I use a similar solution, but with edit instead of squash:

  edit A
  pick B
  pick C

That drops me into a state where any edits I make and subsequently
git add will be integrated into commit A. Then when I git rebase
--continue I'll be prompted subsequently to resolve any resulting
merge conflicts the rest of the way back up the stack to C (assuming
there are any).
-- 
Jeremy Stanley

__
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] [release-announce] [oslo] pbr 3.0.0

[Doug Hellmann]

We've bumped pbr to a new major release. In the past this has triggered
issues for projects capping pbr, so please check your requirements list
and remove any caps if you have them. Projects following the
global-requirements process should also ready be clear of caps.

Doug

Excerpts from no-reply's message of 2017-04-20 16:03:13 +:
> We are pumped to announce the release of:
> 
> pbr 3.0.0: Python Build Reasonableness
> 
> The source is available from:
> 
> http://git.openstack.org/cgit/openstack-dev/pbr
> 
> Download the package from:
> 
> https://pypi.python.org/pypi/pbr
> 
> Please report issues through launchpad:
> 
> http://bugs.launchpad.net/pbr
> 
> For more details, please see below.
> 
> Changes in pbr 2.1.0..3.0.0
> ---
> 
> 1ed8531 Remove 'build_sphinx_latex'
> d4e4efd Stop building man pages by default
> 54fb6e7 docs: Use definition lists
> 84a8599 add image.nonlocal_uri to the list of warnings ignored
> b9c9630 doc: Document Sphinx integration
> 16a0a98 add changelog to published documentation
> 3cc5af1 Add Changelog build handling for invalid chars
> 
> 
> Diffstat (except docs and test files)
> -
> 
> README.rst  |   1 +
> pbr/builddoc.py |  15 +---
> pbr/git.py  |  22 ++
> pbr/hooks/commands.py   |   1 -
> pbr/packaging.py|   2 -
> 9 files changed, 194 insertions(+), 74 deletions(-)
> 

__
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][api] POST /api-wg/news

[Ed Leafe]

Greetings OpenStack community,

A bit of a lonely meeting today, as only cdent and edleafe were present for 
most of it, although having elmiko join at the end brightened all of our days. 
The main item of discussion was the status of the various project liaisons to 
the API WG [0], and how to handle that. edleafe agreed to ping the current 
liaisons to get an update as to their status.

Due to the lack of feeback from the liaisons, we agreed to postpone merging the 
three frozen guidelines for another week to make sure that there are no 
objections. After all, it was Easter and all, so perhaps lots of people are in 
chocolate-induced comas.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a set of api interoperability guidelines
  https://review.openstack.org/#/c/421846/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

# Guidelines Currently Under Review [3]

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/
  On hold.

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115723.html
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe







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

[openstack-dev] [vitrage] Change in Vitrage ID

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

A change that was committed today[0] modifies the Vitrage ID generation method. 
Instead of computing the vitrage-id based on the resource properties, it is now 
created as a standard OpenStack UUID.
Note that this change might affect your workflow, in case you counted on the 
previous name generation method.

Best Regards,
Ifat.

[0] https://review.openstack.org/#/c/457971/

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

Re: [openstack-dev] [oslo] Can we stop global requirements update?

[Doug Hellmann]

Excerpts from Matthew Oliver's message of 2017-04-20 14:41:38 +1000:
> We have started this work. I've been working on:
> https://review.openstack.org/#/c/444718/

Wonderful! I'm sorry I didn't realize you were working on it. Thank you!

> Which will do requirement checks, as specified in the Pike PTG ehterpad for
> Tuesday morning:
> https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike (line
> 40+).
> 
> Once done, Tony and I were going to start testing it on the experimental
> pipeline for Swift and Nova.

That sounds like a good approach. I'll subscribe to the review and
follow along.

Doug

> 
> Regards,
> Matt
> 
> On Thu, Apr 20, 2017 at 2:34 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Clark Boylan's message of 2017-04-19 08:10:43 -0700:
> > > On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote:
> > > > Hoy,
> > > >
> > > > So Gnocchi gate is all broken (agan) because it depends on "pbr"
> > and
> > > > some new release of oslo.* depends on pbr!=2.1.0.
> > > >
> > > > Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0
> > > > that got in banished by requirements Gods. It does not prevent it to be
> > > > used e.g. to install the software or get version information. But it
> > > > does break anything that is not in OpenStack because well, pip installs
> > > > the latest pbr (2.1.0) and then oslo.* is unhappy about it.
> > >
> > > It actually breaks everything, including OpenStack. Shade and others are
> > > affected by this as well. The specific problem here is that PBR is a
> > > setup_requires which means it gets installed by easy_install before
> > > anything else. This means that the requirements restrictions are not
> > > applied to it (neither are the constraints). So you get latest PBR from
> > > easy_install then later when something checks the requirements
> > > (pkg_resources console script entrypoints?) they break because latest
> > > PBR isn't allowed.
> > >
> > > We need to stop pinning PBR and more generally stop pinning any
> > > setup_requires (there are a few more now since setuptools itself is
> > > starting to use that to list its deps rather than bundling them).
> > >
> > > > So I understand the culprit is probably pip installation scheme, and we
> > > > can blame him until we fix it. I'm also trying to push pbr 2.2.0 to
> > > > avoid the entire issue.
> > >
> > > Yes, a new release of PBR undoing the "pin" is the current sane step
> > > forward for fixing this particular issue. Monty also suggested that we
> > > gate global requirements changes on requiring changes not pin any
> > > setup_requires.
> > >
> > > > But for the future, could we stop updating the requirements in oslo
> > libs
> > > > for no good reason? just because some random OpenStack project hit a
> > bug
> > > > somewhere?
> > > >
> > > > For example, I've removed requirements update on tooz¹ for more than a
> > > > year now, which did not break *anything* in the meantime, proving that
> > > > this process is giving more problem than solutions. Oslo libs doing
> > that
> > > > automatic update introduce more pain for all consumers than anything
> > (at
> > > > least not in OpenStack).
> > >
> > > You are likely largely shielded by the constraints list here which is
> > > derivative of the global requirements list. Basically by using
> > > constraints you get distilled global requirements and even without being
> > > part of the requirements updates you'd be shielded from breakages when
> > > installed via something like devstack or other deployment method using
> > > constraints.
> > >
> > > > So if we care about Oslo users outside OpenStack, I beg us to stop this
> > > > crazyness. If we don't, we'll just spend time getting rid of Oslo over
> > > > the long term…
> > >
> > > I think we know from experience that just stopping (eg reverting to the
> > > situation we had before requirements and constraints) would lead to
> > > sadness. Installations would frequently be impossible due to some
> > > unresolvable error in dependency resolution. Do you have some
> > > alternative in mind? Perhaps we loosen the in project requirements and
> > > explicitly state that constraints are known to work due to testing and
> > > users should use constraints? That would give users control to manage
> > > their own constraints list too if they wish. Maybe we do this in
> > > libraries while continuing to be more specific in applications?
> >
> > At the meeting in Austin, the requirements team accepted my proposal
> > to stop syncing requirements updates into projects, as described
> > in https://etherpad.openstack.org/p/ocata-requirements-notes
> >
> > We haven't been able to find anyone to work on the implementation,
> > though. I is my understanding that Tony did contact the Telemetry
> > and Swift teams, who are most interested in this area of change,
> > about devoting some resources to the tasks outlined in the proposal.
> >
> > Doug
> >
> > >
> > > >
> > 

Re: [openstack-dev] [tc][ptls] Apologies and update

[Jordan Pittier]

Hi Tony,
Thank you for this email and the good work you've been doing for OpenStack.

Take care,
Jordan

On Thu, Apr 20, 2017 at 8:56 AM, Tony Breeds 
wrote:

> Hi All,
> I'd belatedly like to apologise for my recent absence from my OpenStack
> duties.  As a few people know I needed to take a small break due to medical
> leave.
>
> Also unrelated to that my employment circumstances have changed recently
> so I'm
> still committed to the community and my roles I'm going to be a little
> distracted for the, hopefully, near future.
>
> I hope to see many of you in Boston, which thanks to the Foundation I'm
> able to
> attend. \o/
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][fuel] stepping down from puppet/fuel core groups

[Iury Gregory]

Thank you very much for your help and work Denis!
Good luck on your future work man!


2017-04-20 11:04 GMT-03:00 Emilien Macchi :

> On Thu, Apr 20, 2017 at 6:44 AM, Denis Egorenko 
> wrote:
> > Hello puppet'ers!
> >
> > Now it's time to say "Goodbay" to you, i'm leaving Mirantis and as well
> > stepping down from Puppet/Fuel core groups.
> >
> > It was a really cool to work with all of you! I've learn a lot! Thank you
> > all for all your help and advises.
> >
> > Also want to especially say "Thank you" to Emilien Macchi, Alex Schultz,
> > Sergii Golovatiuk, Vladimir Kuklin and other core guys - you're best! :)
>
> It was a real pleasure to work with you, your impact on the Puppet
> modules has been really impressive.
> Enjoy your next things and... have fun!
>
> > If you will need my help, please don't hesitate to add me to review or
> reach
> > me: egorenko@gmail.com
> >
> > Thank you and good luck!
> >
> > --
> > Best Regards,
> > Egorenko Denis,
> > Senior Deployment Engineer
> > Mirantis
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira *
*Master student in Computer Science at UFCG*

*Part of the puppet-manager-core team in OpenStack*
*E-mail:  iurygreg...@gmail.com *
~
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Reflections on the pike-1 milestone

[Matt Riedemann]

On 4/20/2017 2:01 AM, Maish Saidel-Keesing wrote:

Just as a matter of interest - from the numbers above you say 62
blueprints approved - was this only for this cycle - or *up until* this
cycle.

When you mention several up for review - can you elaborate on exact
numbers?

I am not looking to 'monitor' activity - but for me it would be
interesting to understand - what the workload is actually like. If the
ratio of 'incoming work' (blueprints) vs. completed/in-review is 62:3
then to me - this seems to be something that needs to be addressed.

Or am I misunderstanding the comment above?


That means 62 blueprints approved for Pike (this cycle). This does not 
mean the code is merged and the blueprint is completed. It means we 
agreed on the design proposal and can move forward with code for the 
blueprint.


Several up for review means there are approved blueprints with code 
ready for review (they have started, or are more than just a POC). These 
numbers are probably low right now, but all blueprints targeted for Pike 
[1] with Delivery status of "Needs Code Review" is what I'm referring to 
here, which is currently 38.


As for incoming work, and the ratio you point out, is not unusual in the 
first milestone before we do our spec freeze, where we then stop 
accepting new blueprint proposals for the release so we can focus on 
implementing and reviewing what we've already planned to do.


If you want a much more detailed explanation of the numbers and trends, 
I provided that after the Ocata release [2].


[1] https://blueprints.launchpad.net/nova/pike
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2017-February/111639.html


--

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] [oslo] Can we stop global requirements update?

[gordon chung]

On 20/04/17 01:32 AM, Joshua Harlow wrote:
> Wasn't there also some decision made in austin (?) about how we as a
> group stated something along the line of co-installability isn't as
> important as it once was (and may not even be practical or what people
> care about anymore anyway)?
>
> With kolla becoming more popular (tripleo I think is using it, and ...)
> and the containers it creates making isolated per-application
> environments it makes me wonder what of global-requirements is still
> valid (as a concept) and what isn't.
>
> I do remember the days of free for all requirements (or requirements
> sometimes just put/stashed in devstack vs elsewhere), which I don't
> really want to go back to; but if we finally all agree that
> co-installability isn't what people actually do and/or care about
> (anymore?) then maybe we can re-think some things?

agree with all of ^... but i imagine to make progress on this, we'd have 
to change/drop devstack usage in gate and that will take forever and a 
lifetime (is that a chick flick title?) given how embedded devstack is 
in everything. it seems like the solution starts with devstack.

cheers,

-- 
gord

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

Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils

[Steven Dake (stdake)]

Zhijang,

You have a point a view whereby Kolla is never co-installed with other 
OpenStack projects.  I agree I have never heard of this happening.  That 
doesn’t mean it doesn’t happen.

Even given this line of thinking, I have an impossible time rationalizing Kolla 
as a special snowflake.  Kolla conforms (as best as we know how) to OpenStack 
wide processes.

Regards
-steve

From: "hu.zhiji...@zte.com.cn" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 19, 2017 at 11:24 PM
To: "hongbin...@gmail.com" 
Cc: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Then IMO,  the global requirements process seems against the intention of 
requirement.txt file. Since requirement.txt is per-project, not global. It is 
(just for example) Zun that treat docker-py-1.8 as a must. As for Kolla, both 
1.6 and 1.8 are OK. Then there is no need to force Kolla to change its 
requirement from "docker-py ＞=1.6.0" to "docker-py ＞=1.8.0" by the global 
requirements process, otherwise,  user may think Kolla really need a newer 
version, kind of easy to be misread.



We know it is valuable to upgrade requirements globally, as it is condusive to 
early bug detection of the co-installation circumstance. But can we not to do 
that detection in each project's CI by write it literally in each project's 
requirement.txt but just upgrade required packages globally in a dedicated CI 
that tests the projects which really need to be co-installed?



B. R.,

Zhijiang
Original Mail
Sender:  ＜hongbin...@gmail.com＞;
To:  ＜openstack-dev@lists.openstack.org＞;
Date: 2017/04/20 12:50
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils


Zun required docker-py to be 1.8 or higher because older version of docker-py 
didn't have the API we need. Sorry if it caused difficulties on your side but I 
don't think it is feasible to downgrade the version for now since it will 
affect a ton of other projects.
Best regards,
Hongbin

On Thu, Apr 20, 2017 at 12:15 AM, Steven Dake (stdake) 
＜std...@cisco.com＞ wrote:
Hu,

Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber stamp changes from the 
global requirements bot assuming  they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.

Taking a look at the specific issues you raised:

Pbr: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158
Here is the change: 
https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c
(from the infrastructure team)

Docker-py: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338
Here is the change: 
https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6
(from the magnum team)

oslo-utils: 
https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136
https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7
(I am not sure which team this is – the oslo team perhaps?)

I would recommend taking the changes up with the requirements team or the 
direct authors.

Regards
-steve



From: "hu.zhiji...@zte.com.cn" 
＜hu.zhiji...@zte.com.cn＞
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org＞
Date: Wednesday, April 19, 2017 at 8:45 PM
To: 
"openstack-dev@lists.openstack.org" 
＜openstack-dev@lists.openstack.org＞
Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils


Hello,



As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] ,

docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on

oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to

generate UUID.



IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to,

and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean

If we keep Kolla's requirement in Ocata as what it was in Newton, upper layer

user of Kolla like daisycloud-core project can still keep other things unchanged

to upgrade Kolla from stable/newton to stable/ocata. Otherwise, we have to

upgrade from centos-release-openstack-newton to

centos-release-openstack-ocata(we do not use pip since it conflicts with yum

on files 

Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils

[hu.zhijiang]

Then IMO,  the global requirements process seems against the intention of 
requirement.txt file. Since requirement.txt is per-project, not global. It is 
(just for example) Zun that treat docker-py-1.8 as a must. As for Kolla, both 
1.6 and 1.8 are OK. Then there is no need to force Kolla to change its 
requirement from "docker-py ＞=1.6.0" to "docker-py ＞=1.8.0" by the global 
requirements process, otherwise,  user may think Kolla really need a newer 
version, kind of easy to be misread.




We know it is valuable to upgrade requirements globally, as it is condusive to 
early bug detection of the co-installation circumstance. But can we not to do 
that detection in each project's CI by write it literally in each project's 
requirement.txt but just upgrade required packages globally in a dedicated CI 
that tests the projects which really need to be co-installed? 





B. R.,

Zhijiang






Original Mail



Sender:  ＜hongbin...@gmail.com＞
To:  ＜openstack-dev@lists.openstack.org＞
Date: 2017/04/20 12:50
Subject: Re: [openstack-dev] [kolla] [daisycloud-core] [requirements][magnum] 
[oslo] Do we really need to upgrade pbr, docker-py and oslo.utils






Zun required docker-py to be 1.8 or higher because older version of docker-py 
didn't have the API we need. Sorry if it caused difficulties on your side but I 
don't think it is feasible to downgrade the version for now since it will 
affect a ton of other projects.
Best regards,
Hongbin




On Thu, Apr 20, 2017 at 12:15 AM, Steven Dake (stdake) ＜std...@cisco.com＞ wrote:



Hu,


 


Kolla does not manage the global requirements process as it is global to 
OpenStack.  The Kolla core reviewers essentially rubber stamp changes from the 
global requirements bot assuming  they pass our gating.  If they don’t pass our 
gating, we work with the committer to sort out a working solution.


 


Taking a look at the specific issues you raised:


 


Pbr: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L158


Here is the change: 
https://github.com/openstack/requirements/commit/74a8e159e3eda7c702a39e38ab96327ba85ced3c


(from the infrastructure team)


 


Docker-py: 
https://github.com/openstack/requirements/blame/stable/ocata/global-requirements.txt#L338


Here is the change: 
https://github.com/openstack/requirements/commit/330139835347a26f435ab1262f16cf9e559f32a6


(from the magnum team)


 


oslo-utils: 
https://github.com/openstack/requirements/blame/62383acc175b77fe7f723979cefaaca65a8d12fe/global-requirements.txt#L136


https://github.com/openstack/requirements/commit/510c4092f48a3a9ac7518decc5d3724df8088eb7


(I am not sure which team this is – the oslo team perhaps?)


 


I would recommend taking the changes up with the requirements team or the 
direct authors.


 


Regards


-steve


 


 


 



From: "hu.zhiji...@zte.com.cn" ＜hu.zhiji...@zte.com.cn＞
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org＞
 Date: Wednesday, April 19, 2017 at 8:45 PM
 To: "openstack-dev@lists.openstack.org" ＜openstack-dev@lists.openstack.org＞
 Subject: [openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade 
pbr, docker-py and oslo.utils 



 

Hello,

 

As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] , 

docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on 

oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to

generate UUID.

 

IMHO, Upgrading of [1] and [2] are actually not what Kolla really need to,

and uuidutils.generate_uuid() is also supported by oslo.utils-3.16. I mean

If we keep Kolla's requirement in Ocata as what it was in Newton, upper layer

user of Kolla like daisycloud-core project can still keep other things 
unchanged 

to upgrade Kolla from stable/newton to stable/ocata. Otherwise, we have to 

upgrade from centos-release-openstack-newton to 

centos-release-openstack-ocata(we do not use pip since it conflicts with yum 

on files installed by same packages). But this kind of upgrade may be too 

invasive that may impacts other applications. 

 

I know that there were some discusstions about global requirements update

these days. So if not really need to do these upgrades by Kolla itself, can

we just keep the requirement unchanged as long as possible?

 

My 2c.

 

[1] 
https://github.com/openstack/kolla/commit/2f50beb452918e37dec6edd25c53e407c6e47f53

[2] 
https://github.com/openstack/kolla/commit/85abee13ba284bb087af587b673f4e44187142da

[3] 
https://github.com/openstack/kolla/commit/cee89ee8bef92914036189d02745c08894a9955b
 

 

 

 

 

 

B. R.,

Zhijiang








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

Re: [openstack-dev] [qa][cinder] critical fix for ceph job

[Ghanshyam Mann]

On Tue, Apr 11, 2017 at 4:05 AM, Jon Bernard  wrote:
> * Matt Riedemann  wrote:
>> On 4/7/2017 9:43 AM, Jordan Pittier wrote:
>> >
>> >
>> > On Fri, Apr 7, 2017 at 4:15 PM, Ghanshyam Mann > > > wrote:
>> >
>> > Thanks. I am not sure these kind of driver specific behavior on APIs
>> > side. This bring up question that should not cinder APIs be consistent
>> > from usage point. In this case[1], create backup API can accept
>> > 'container' param and do/don't create pool as per configured driver?
>> > Then have better documentation for that what all driver honor that or
>> > not.
>> >
>> > Any suggestion ?
>> >
>> > ..1 https://review.openstack.org/#/c/454321/3
>> > 
>> >
>> >
>> > Yeah, I've left a comment on that review. And another comment on
>> > https://review.openstack.org/#/c/454722 :
>> >
>> > "I'd rather we revert the change completely than to see this merged.
>> >
>> > If the Ceph backup driver doesn't support the container argument it
>> > should either grow support for it, or ignore that argument, or we change
>> > Cinder's API completely so that the container argument is not part of
>> > the public API anymore.
>> >
>> > Do we expect each and every user to know what each and every drivers
>> > support ? I don"t think so, so Tempest shouldn"t either."
>> >
>> >
>> >
>> > __
>> > 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
>> >
>>
>> I left a comment in there too. This wasn't the right way to get around this.
>> I've tried the same thing before, back when the encrypted volume tests were
>> failing for ceph because it simply wasn't supported in nova.
>>
>> Jon, as we discussed at the PTG, you need to get a whitelist or blacklist
>> file into nova like we have for the cells v1 job and we can use that on the
>> ceph job config to control the tests that are run, so we don't need to make
>> changes like this in Tempest. Let's work on that and then we can revert this
>> workaround to Tempest.
>
> Ok, I understand the logic and I'm happy work towards this.  For
> reference, this commit https://review.openstack.org/#/c/345411/ added
> support for container names to the ceph backup driver and I think a
> discussion within Cinder is needed.  I will first create an analogous
> patch for nova's whitelist, and then revert this one.  And if we decide
> to change cinder's behaviour then all of it can go away.
>

Thanks Jon.

I feel whitelist/blacklist should be maintain on devstack-plugin-ceph
side instead of Nova. This job is used on Nova, Cinder, Glance,
Tempest, devstack.

Maintain on  openstack/devstack-plugin-ceph is much better as plugin
knows what all test to disable/enable.


Also infra patche[1] landed before the script was merged which removed
the mandatory arg ''--regex'' while running the tempest tox command.
Results to ceph job failing everywhere.  I am reverting[2] that change
and once we are ready with whitelst/blcklist script then we can change
job definition accordingly.

..1 https://review.openstack.org/#/c/455818
..2 https://review.openstack.org/#/c/458349/


> --
> Jon
>
> __
> 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] Emails for OpenStack R Release Name voting going out - please be patient

[Kevin Benton]

FWIW mine just came through yesterday.

On Wed, Apr 19, 2017 at 12:13 PM, Jay S Bryant  wrote:

> All,
>
> For those of you haven't received an e-mail, check the inbox you use for
> Gerrit.  You can verify what that is by going to review.openstack.org ,
> click your name, go to settings, the e-mail address is set there.
>
> The naming vote and the TC vote e-mails got lost in that inbox for me.
>
> Hopes this helps.
>
> Jay
>
>
>
>
> On 4/12/2017 7:09 AM, Dulko, Michal wrote:
>
>> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
>>
>>> On 04/06/2017 07:34 AM, Monty Taylor wrote:
>>>
 Hey all!

 I've started the R Release Name poll and currently am submitting
 everyone's email address to the system. In order to not make our fine
 friends at Carnegie Mellon (the folks who run the CIVS voting service)
 upset, I have a script that submits the emails one at a time with a
 half-second delay between each email. That means at best, since there
 are 40k people to process it'll take ~6 hours for them all to go out.

 Which is to say - emails are on their way - but if you haven't gotten
 yours yet, that's fine. I'll send another email when they've all gone
 out, so don't worry about not receiving one until I've sent that mail.

>>> Well- that took longer than I expected. Because of some rate limiting,
>>> 1/2 second delay was not long enough...
>>>
>>> Anyway - all of the emails should have gone out now. Because that took
>>> so long, I'm going to hold the poll open until next Wednesday.
>>>
>>> Monty
>>>
>> Not sure why, but I haven't received an email yet.
>>
>> Thanks,
>> Michal
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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][ptls] Apologies and update

[Tony Breeds]

Hi All,
I'd belatedly like to apologise for my recent absence from my OpenStack
duties.  As a few people know I needed to take a small break due to medical
leave.

Also unrelated to that my employment circumstances have changed recently so I'm
still committed to the community and my roles I'm going to be a little
distracted for the, hopefully, near future.

I hope to see many of you in Boston, which thanks to the Foundation I'm able to
attend. \o/

Yours Tony.


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] [nova] Reflections on the pike-1 milestone

[Maish Saidel-Keesing]

On 20/04/17 0:42, Matt Riedemann wrote:
> Hey everyone,
>
> Now that the pike-1 milestone is behind us I wanted to have a recap of
> the milestone to compare what progress we made against goals we set at
> the PTG, and to look forward to the pike-2 milestone.
>
> First some highlights of things accomplished in the pike-1 milestone
> in no particular order:
>
> - Jay Pipes got the Ironic virt driver reporting custom resource
> classes into the Placement service for compute node inventory.
> - There is good progress on the os-traits library and Alex Xu got the
> /traits API merged into the placement endpoint.
> - Sean Dague got high-level agreement on unifying limits in Keystone
> which is a foundation for supporting hierarchical quotas.
> - We merged the spec and plan for integrating Searchlight into
> nova-api. At this point that's all just spec, but it was a pretty
> complicated spec to work through and we have a plan going into pike-2.
> - Sean Dague got uwsgi working in devstack now and Chris Dent is
> working on making nova-api run under uwsgi per the Pike community goal.
> - Dan Smith has made good progress on enabling multi-cell support in
> the REST API and getting devstack to run and pass tests with a fleet
> of conductors. We'll be discussing this at the Forum [1].
> - We merged Ildiko Vancsa's patch to remove the check_attach code from
> Nova, and we merged John Garbutt's spec for integrating the new Cinder
> attachment APIs into Nova. Progress has been made on the code for
> using the new APIs too.
> - Chris Dent has been sending weekly emails giving updates on the work
> going on with placement, and Balazs Gibizer has been doing similar for
> the versioned notifications work. This has been helpful for keeping
> focus, recording decisions, and giving those outside the day-to-day
> involvement an idea of the progress made and where they can help.
> - Good progress from the OSIC team on documenting the various policy
> rules [2].
> - We have 62 blueprints/specs approved, 3 completed, and several with
> code up for review.
>
Just as a matter of interest - from the numbers above you say 62
blueprints approved - was this only for this cycle - or *up until* this
cycle.

When you mention several up for review - can you elaborate on exact
numbers?

I am not looking to 'monitor' activity - but for me it would be
interesting to understand - what the workload is actually like. If the
ratio of 'incoming work' (blueprints) vs. completed/in-review is 62:3
then to me - this seems to be something that needs to be addressed.

Or am I misunderstanding the comment above?
> Some targets we missed in pike-1:
>
> - We aren't as far along as we'd like to be with the counting quotas
> work, but to be fair, some of that was redone after initial review to
> make it easier to integrate. And we did approve the spec for putting a
> /usages API into placement which the quotas work will leverage.
> - We don't have the additional-notification-fields-for-searchlight
> blueprint done yet. We hit some snags during review but those have
> been ironed out now, so we should be able to finish this early in pike-2.
> - We never had a spec for using Cinder as an ephemeral backend.
> However, we will be discussing this at the Forum [3] so hopefully
> we'll have a plan going into Queens.
> - The versioned notifications transformation has been slowing down,
> probably due to a lack of reviews.
> - I never delivered a spec for deprecating personality files from the
> compute REST API (but I'm deprecating some other things from the API,
> so that counts, right?).
> - We didn't merge a spec to support the concept of service-locked
> instances. There is a draft work in progress spec though to pick up in
> Queens [4].
> - Little to no progress on merging the network-aware scheduling series
> which has been carried over since Newton. This is needed to support
> Neutron routed networks.
> - The PowerVM driver series has not landed a single change yet due to
> lack of reviews.
>
> Looking to pike-2 we have a few priority things to get done:
>
> - Get a dsvm job running with nova + searchlight and start writing the
> proof of concept for searchlight integration with nova-api. The goal
> here is going to be finding out what issues we didn't anticipate in
> the spec, even though there were plenty of issues already identified
> in the spec. We will also be discussing this at the forum [5].
> - Complete the additional-notification-fields-for-searchlight blueprint.
> - We need to make progress on landing the counting quotas changes
> early so we can shake out any bugs introduced by that complicated change.
> - Close on the plan for moving claims to the scheduler, discuss it
> with operators at the Forum [6], and make good progress on
> implementation by the end of the milestone.
> - Get more of the versioned notifications work done.
> - Now that the /traits API is available, we need to make progress on
> adding support for modeling shared storage 

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

[Steven Hardy]

On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote:
> On 04/13/2017 12:01 AM, Rabi Mishra wrote:
> > On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon  > > wrote:
> > 
> > On 04/12/2017 01:22 PM, Thomas Herve wrote:
> > > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon  > > wrote:
> > >> I'm implementing predictable control plane IPs for spine/leaf,
> > and I'm
> > >> running into a problem implementing this in the TripleO Heat
> > templates.
> > >>
> > >> I have a review in progress [1] that works, but fails on upgrade,
> > so I'm
> > >> looking for an alternative approach. I'm trying to influence the IP
> > >> address that is selected for overcloud nodes' Control Plane IP.
> > Here is
> > >> the current construct:
> > >>
> > >>   Controller:
> > >> type: OS::TripleO::Server
> > >> metadata:
> > >>   os-collect-config:
> > >> command: {get_param: ConfigCommand}
> > >> properties:
> > >>   image: {get_param: controllerImage}
> > >>   image_update_policy: {get_param: ImageUpdatePolicy}
> > >>   flavor: {get_param: OvercloudControlFlavor}
> > >>   key_name: {get_param: KeyName}
> > >>   networks:
> > >> - network: ctlplane  # <- Here's where the port is created
> > >>
> > >> If I add fixed_ip: to the networks element at the end of the above, I
> > >> can select an IP address from the 'ctlplane' network, like this:
> > >>
> > >>   networks:
> > >> - network: ctlplane
> > >>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
> > >>
> > >> But the problem is that if I pass a blank string to fixed_ip, I
> > get an
> > >> error on deployment. This means that the old behavior of
> > automatically
> > >> selecting an IP doesn't work.
> > >>
> > >> I thought I has solved this by passing an external Neutron port,
> > like this:
> > >>
> > >>   networks:
> > >> - network: ctlplane
> > >>   port: {get_attr: [ControlPlanePort, port_id]}
> > >>
> > >> Which works for deployments, but that fails on upgrades, since the
> > >> original port was created as part of the Nova::Server resource,
> > instead
> > >> of being an external resource.
> > >
> > > Can you detail how it fails? I was under the impression we never
> > > replaced servers no matter what (or we try to do that, at least). Is
> > > the issue that your new port is not the correct one?
> > >
> > >> I'm now looking for a way to use Heat conditionals to apply the
> > fixed_ip
> > >> only if the value is not unset. Looking at the intrinsic
> > functions [2],
> > >> I don't see a way to do this. Is what I'm trying to do with Heat
> > possible?
> > >
> > > You should be able to write something like that (not tested):
> > >
> > > networks:
> > >   if:
> > > - 
> > > - network: ctlplane
> > >   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
> > > - network: ctlplane
> > >
> > > The question is how to define your condition. Maybe:
> > >
> > > conditions:
> > >   fixed_ip_condition:
> > >  not:
> > > equals:
> > >   - {get_attr: [ControlPlanePort, ip_address]}
> > >   - ''
> > >
> > > To get back to the problem you stated first.
> > >
> > >
> > >> Another option I'm exploring is conditionally applying resources. It
> > >> appears that would require duplicating the entire TripleO::Server
> > stanza
> > >> in *-role.yaml so that there is one that uses fixed_ip and one
> > that does
> > >> not. Which one is applied would be based on a condition that tested
> > >> whether fixed_ip was blank or not. The downside of that is that
> > it would
> > >> make the role definition confusing because there would be a large
> > >> resource that was implemented twice, with only one line difference
> > >> between them.
> > >
> > > You can define properties with conditions, so you shouldn't need to
> > > rewrite everything.
> > >
> > 
> > Thomas,
> > 
> > Thanks, I will try your suggestions and that should get me closer.
> > 
> > The full error log is available here:
> > 
> > http://logs.openstack.org/78/413278/11/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/8d91762/console.html
> > 
> > 
> > 
> > We do an interface_detach/attach when a port is replaced.
> > It seems to be failing[1] as this is not implemented for
> > ironic/baremetal driver.  I could see a patch[2] to add that
> > functionality though.
> > 
> > [1]
> >