[openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

[Chen CH Ji]

in analyzing other code, found seems we don't need PUT
/servers/{server_id}/metadata/{key} ?

as the id is only used for check whether it's in the body and we will honor
the whole body (body['meta'] in the code)
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80

looks like it's identical to
PUT /servers/{server_id}/metadata

why we need this API or it should be something like

PUT /servers/{server_id}/metadata/{key} but we only accept a value to
modify the meta given by {key} in the API side?

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] [nova] About live-resize spec

[Chen CH Ji]

spec [1] has been there since 2014 and some patches proposed but abandoned
after that, can someone
please provide some info/background about why it's postponed or due to some
limitations that nova hasn't been implemented yet?

some operators suggested that this is a valuable funcationality so better
to have it in the near feature... thanks


[1]:https://blueprints.launchpad.net/nova/+spec/instance-live-resize

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] [keystone] [policy] policy meeting 2017-09-20

[Lance Bragstad]

Hey all,

I won't be available to run the policy meeting tomorrow. It doesn't look
like there is anything posted to the agenda yet [0]. If someone feels
like hosting it, please feel free to do so. I'll catch the scroll back
afterwords.

Thanks,

Lance


[0] https://etherpad.openstack.org/p/keystone-policy-meeting




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

Re: [openstack-dev] [all] dashboard query changes since upgrade

[Lance Bragstad]

I should have read this thread before starting a new one [0]. The query
bits sound somewhat similar to what I experienced with a script to
generate a burndown chart, but querying a topic instead.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122315.html

On 09/19/2017 06:35 AM, Sean Dague wrote:
> On 09/19/2017 09:00 AM, Sean Dague wrote:
>> I've been iterating through gerrit dashboards this morning trying to
>> figure out why they no longer show any changes.
>>
>> It looks like the query: label:Code-Review>=-2,self now matches changes
>> you haven't voted on. Previously (probably to a bug) this only matched
>> patches where you had a -2,-1,+1,+2 vote on them.
>>
>> I'll be poking around today to figure out what the options are to get
>> equivalent functionality is out of the system, then update the gerrit
>> dashboards in gerrit-dash-creator based on that.
> It appears that reviewedby:self actually works like we were hacking the
> old one to work. I've pushed through a bulk fix for most of the
> dashboards here - https://review.openstack.org/#/c/505247/
>
> However local versions will need local patching.
>
>   -Sean
>




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

[openstack-dev] [all] policy in code burndown chart

[Lance Bragstad]

Hey all,

The upgrade to Gerrit 2.13.9 affected a script I was using to generate
the burndown chart by querying the REST api. I've pushed a fix [0] and
it should be working again in case you weren't seeing your project being
reflected in the burndown [1]. Let me know if you have any additional
questions.

Thanks,

Lance

[0]
https://github.com/lbragstad/openstack-doc-migration-burndown/commit/c46e4608620b4b0357794f96815e4d2e9e3de065
[1] https://www.lbragstad.com/policy-burndown/




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

Re: [openstack-dev] [karbor] Proposing Pengju Jiao to the Karbor core team

[Edison Xiang]

+1  Although I am not a Karbor Core Member:)

Pengju Jiao did a great contribution in Karbor Project, including lots of
bugs and bps.

He is very professional in Data Protection, and make an impressive speech
in OpenStack China Day.

Best Regards,
Edison Xiang

On Wed, Sep 20, 2017 at 10:09 AM, Chen Ying  wrote:


> From: Chen Ying 
> Date: 2017-09-19 17:53 GMT+08:00
> Subject: [openstack-dev] [karbor] Proposing Pengju Jiao to the Karbor core
> team
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
>
> Hey all,
>
>  I'm proposing that we add Pengju Jiao to the Karbor core team. Pengju
> Jiao has been actively contributing to the Karbor project from Pike.  His
> contributions include proposing high-quality codes, providing helpful code
> reviews, participating team discussion at weekly team meeting and IRC, etc.
> He also did a great job about s3 bank and the freezer integration with
> karbor. So I'm proposing adding him to the core team. Let me know if there
> are any objections.
>
>
> Best regards,
> Chen Ying
>
>
__
OpenStack Development Mailing 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] [rpm-packaging][karbor] Code review needed!

[Chen Ying]

OK. I will review it ASAP.

2017-07-27 10:48 GMT+08:00 Jiong Liu :

> Hello packaging team and folks,
>
>
>
> We(Karbor team) need your help to review https://review.openstack.org/#
> /c/480806/ which adds karbor to rpm-packaging repository.
>
> But it always failed in CI tests. It’s highly appreciated if anyone could
> help!
>
>
>
> Thanks!
>
> Jeremy
>
> __
> OpenStack Development Mailing 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] Why do we apt-get install NEW files/debs/general at job time ?

[Ian Wienand]

On 09/20/2017 09:30 AM, David Moreau Simard wrote:

At what point does it become beneficial to build more than one image per OS
that is more aggressively tuned/optimized for a particular purpose ?


... and we can put -dsvm- in the jobs names to indicate it should run
on these nodes :)

Older hands than myself will remember even more issues, but the
"thicker" the base-image has been has traditionally just lead to a lot
more corners for corner-cases can hide in.  We saw this all the time
with "snapshot" images where we'd be based on upstream images that
would change ever so slightly and break things, leading to
diskimage-builder and the -minimal build approach.

That said, in a zuulv3 world where we are not caching all git and have
considerably smaller images, a nodepool that has a scheduler that
accounts for flavor sizes and could conceivably understand similar for
images, and where we're building with discrete elements that could
"bolt-on" things like a list-of-packages install sanely to daily
builds ... it's not impossible to imagine.

-i

__
OpenStack Development Mailing 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] Marking <= mitaka EOL

[Tony Breeds]

On Thu, Aug 24, 2017 at 01:14:56PM +1000, Tony Breeds wrote:
> Hello all,
> We have a number of old stable/* branches hanging around and I'd
> like to mark anything <= stable/mitaka as EOL.  I've highlighted a few
> projects on the subject line:
> 
> QA: Are the older branches of grenade safe to go?  IIUC we don't use
> them as we don't do grenade testing on $oldest stable branch
> group-based-policy: In the past you've requested your old branches stay
> around Do you still need this?  Is there value in
> the *all* staying active?
> zaqar: I see that liberty was EOL and then reactivated do you still need
>liberty2?
> packaging_deb: As these repos have the $project origin using the
>standard series-eol tag doesn't make sense  for exaxple
>deb-nova gets a mitaka-eol from the nova repo.   So I've
>picked mitaka-eol-dpkg.
> fuel, networking-*: There are several entries for these projects groups
> so I'm calling them out here for attention.
> 
> I'm proposing we do this removal during the PTG.  Once we've done the
> series based branches we can look at old versioned releases like
> stable/16.04 etc.
> 
> It's hard to present the data in a clear way so given infra will be the
> ultimate actioners of this list I present this as a shell script:

Per previous discussion here's the list to EOL everything <= mitaka
except for:
openstack/group-based-policy,
openstack/group-based-policy-automation,
openstack/group-based-policy-ui,
openstack/python-group-based-policy-client
and openstack/networking-bigswitch

---
eol-branch.sh -- stable/essex essex-eol openstack/anvil
eol-branch.sh -- stable/folsom folsom-eol openstack/anvil
eol-branch.sh -- stable/grizzly grizzly-eol openstack/anvil
eol-branch.sh -- stable/havana havana-eol openstack/openstack
eol-branch.sh -- stable/icehouse icehouse-eol \
 openstack/astara openstack/networking-brocade \
 openstack/networking-cisco openstack/networking-mlnx \
 openstack/networking-odl openstack/networking-plumgrid \
 openstack/nova-solver-scheduler \
 openstack/sahara-image-elements openstack/tricircle \
 openstack/trio2o openstack/vmware-nsx
eol-branch.sh -- stable/icehouse icehouse-eol-dpkg \
 openstack/deb-networking-cisco \
 openstack/deb-networking-mlnx openstack/deb-networking-odl
eol-branch.sh -- stable/juno juno-eol \
 openstack/astara openstack/astara-appliance \
 openstack/astara-horizon openstack/astara-neutron \
 openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui openstack/mistral \
 openstack/mistral-dashboard openstack/mistral-extra \
 openstack/networking-bigswitch \
 openstack/networking-brocade openstack/networking-cisco \
 openstack/networking-mlnx openstack/networking-odl \
 openstack/networking-plumgrid \
 openstack/nova-solver-scheduler \
 openstack/openstack-resource-agents \
 openstack/powervc-driver openstack/proliantutils \
 openstack/puppet-n1k-vsm openstack/puppet-vswitch \
 openstack/python-group-based-policy-client \
 openstack/python-mistralclient \
 openstack/python-muranoclient openstack/vmware-nsx
eol-branch.sh -- stable/juno juno-eol-dpkg \
 openstack/deb-mistral openstack/deb-networking-cisco \
 openstack/deb-networking-mlnx openstack/deb-networking-odl \
 openstack/deb-python-mistralclient \
 openstack/deb-python-muranoclient \
 openstack/deb-python-proliantutils
eol-branch.sh -- stable/kilo kilo-eol \
 openstack-dev/grenade openstack/murano-apps \
 openstack/networking-h3c openstack/requirements
eol-branch.sh -- stable/kilo kilo-eol1 \
 openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui \
 openstack/python-group-based-policy-client
eol-branch.sh -- stable/kilo_v2 kilo_v2-eol openstack/networking-bigswitch
eol-branch.sh -- stable/liberty liberty-eol \
 openstack-dev/grenade openstack/ceilometer-powervm \
 openstack/ceilometer-zvm openstack/ceilometermiddleware \
 openstack/fuel-plugin-calico openstack/group-based-policy \
 openstack/group-based-policy-automation \
 openstack/group-based-policy-ui openstack/mistral-extra \
 openstack/networking-infoblox openstack/networking-powervm \
 openstack/networking-zvm openstack/nova-powervm \
  

[openstack-dev] [congress] IRC agenda 2017-09-21

[Eric K]

Hi all,

Looking forward to catching up at our IRC meeting tomorrow after a
productive PTG!

It¹d be helpful to look at these items ahead of the meeting:
- A work-in-progress list of priorities for Queens we can discuss and
finish in our meeting.
https://etherpad.openstack.org/p/congress-task-priority
- QoS neutron driver patch. We can discuss outstanding comments and move
toward a merge-ready patch. https://review.openstack.org/#/c/488992/
- A proposed blueprint for having a tier of ³unoffcial² drivers for
congress. We can discuss and decide.
https://blueprints.launchpad.net/congress/+spec/separate-unofficial-drivers



Feel free to add any other topics at the usual place:
https://etherpad.openstack.org/p/congress-meeting-topics
Also feel free to take a look at this bullet-list summary of the PTG
discussions and bring up any point for further discussion at our meeting:
https://etherpad.openstack.org/p/congress-ptg-queens

Cheers,
Eric Kao (ekcs)



__
OpenStack Development Mailing 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] [notification] not transforming HostAPI related versioned notifications

[Matt Riedemann]

On 9/19/2017 10:35 AM, Balazs Gibizer wrote:

Hi,

Similar to my earlier mail about not transforming legacy notifications 
in the networking area [1] now I want to propose not to transform 
HostAPI related notifications.
We have the following legacy notifications on our TODO list [2] to be 
transformed:

* HostAPI.power_action.end
* HostAPI.power_action.start
* HostAPI.set_enabled.end
* HostAPI.set_enabled.start
* HostAPI.set_maintenance.end
* HostAPI.set_maintenance.start

However os-hosts API has been depraceted since microversion 2.43. The 
suggested replacement is os-services API. The os-services API already 
emits service.update notification for every action on that API. So I 
suggest not to transform the above HostAPI notifications to the 
versioned notification format.


Cheers,
gibi


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121968.html 


[2] https://vntburndown-gibi.rhcloud.com/index.html


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


This also seems reasonable to me. I had to dig up what set_enabled was 
for again, but now I remember, it's basically the same thing as 
enable/disable a service in the os-services API, but only implemented 
for the xenapi driver.


So yeah, +1 to not converting these to versioned notifications.

As a side question: how do you keep track of the things we purposefully 
*aren't* going to implement for versioned notifications?


--

Thanks,

Matt

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

[openstack-dev] [nova] live migration tests are top fail in CI right now

[Matt Riedemann]

The live migration job is failing at a pretty high rate right now 
(around 50%). It's the top failure:


http://status.openstack.org/elastic-recheck/#1718295

It looks like it started within the last 24 hours, but I'm not sure what 
would be causing it, as I don't see any nova changes related to live 
migration in that time. I've left some notes in the bug:


https://bugs.launchpad.net/nova/+bug/1718295

I wonder if there is a new package we're pulling in. The version of qemu 
that we're using is new as of September 5, but it looks like we just 
started pulling the pike cloud archive packages:


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

So my guess is it's something from that which is blowing things up. 
devstack doesn't gate on the live migration job or the neutron multinode 
job, so that would explain why it wasn't caught there.


--

Thanks,

Matt

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

[openstack-dev] [ironic] [ironic-ui] Proposing Anup Navare (anupn) for ironic-ui-core

[Julia Kreger]

Greetings fellow stackers!

I would like to propose adding Anup Navare to ironic-ui-core. Anup has
been involved with ironic-ui this past cycle as well as various other
areas across ironic which gives me further confidence in making this
proposal.

I have already informally polled the existing ironic-ui-core members,
to which everyone has responded positively. If there are no
objections, I'll make the change in one week.

-Julia

__
OpenStack Development Mailing 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] Why do we apt-get install NEW files/debs/general at job time ?

[David Moreau Simard]

On Tue, Sep 19, 2017 at 9:03 AM, Jeremy Stanley  wrote:
>
> In order to reduce image sizes and the time it takes to build
> images, once we had local package caches in each provider we stopped
> pre-retrieving packages onto the images. Is the time spent at this
> stage mostly while downloading package files (which is what that
> used to alleviate) or is it more while retrieving indices or
> installing the downloaded packages (things having them pre-retrieved
> on the images never solved anyway)?
>

At what point does it become beneficial to build more than one image per OS
that is more aggressively tuned/optimized for a particular purpose ?

We could take more freedom in a devstack-specific image like pre-install
packages that are provided out of base OS, etc.
Different projects could take this kind of freedom to optimize build times
according to their needs as well.

Here's an example of something we once did in RDO:
1) Aggregate the list of every package installed (rpm -qa) at the end
of several jobs
2) From that sorted and uniq'd list, work out which repositories each
package came from
3) Blacklist every package that was not installed from a base
operating system repository
(i.e, blacklist every package and dependencies from RDO, since
we'll be testing these)
4) Pre-install every package that were not blacklisted in our images

The end result was a list of >700 packages [1] completely unrelated to
OpenStack that ended up
being installed anyway throughout different jobs.
To give an idea of numbers, a fairly vanilla CentOS image has ~400
packages installed.
You can find the (rudimentary) script to achieve this filtering is here [2].

[1]: 
https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/nodepool/scripts/weirdo-packages.txt
[2]: 
https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/nodepool/scripts/filter_packages.sh

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

[Sean McGinnis]

> > On 9/19/17, 2:43 PM, "Eric Fried"  wrote:
> >
> > Alex-
> > 
> > Regardless of what the dictionary might say, people associate 
> > the word
> > "Tutorial" with a set of step-by-step instructions to do a thing.
> > "Guide" would be a more general term.
> > 
> > I think of a "Tutorial" as being a *single* representative path 
> > through
> > a process.  A "Guide" could supply different alternatives.
> > 
> > I expect a "Tutorial" to get me from start to finish.  A 
> > "Guide" might
> > help me along the way, but could be sparser.
> > 
> > In summary, I believe the word "Tutorial" implies a very 
> > specific
> > thing, so we should use it if and only if the doc is exactly that.

I don't think we'll get consensus on this, as my association with those words
do not match Eric's. :)

For me, a tutorial is something that teaches. So after I've gone through a
tutorial I would expect to have learned how installs work and would just know
these things (with an occasional need to reference a few points) going forward.

A guide to me is something that I know I will use whenever I need to do
something. So for me, having an installation guide is what I would expect
from this as every time I need to do a package based install, I am going to pull
up the guide to go through it.

Sean

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

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

[Eric Fried]

Alex-

    The non-list reply was deliberate.  I honestly haven't looked at the
docs in question, so really my answer was just me being pedantic about
how I interpret those two words in general when I see them in technical
literature.  Jay's concerns about consistency are probably more important.

    However, posting back to the list, as requested.

Thanks,
Eric

On 09/19/2017 03:49 PM, Alexandra Settle wrote:
> Hi Eric,
>
> I’m not entirely too sure if you meant to just reply to me regarding this 
> thread? :)
>
> However, it would be helpful if you could bring it back to the mailing list 
> to highlight your concerns and continue this discussion :)
>
> Thanks for your reply,
>
> Alex
>
> On 9/19/17, 2:43 PM, "Eric Fried"  wrote:
>
> Alex-
> 
>   Regardless of what the dictionary might say, people associate the word
> "Tutorial" with a set of step-by-step instructions to do a thing.
> "Guide" would be a more general term.
> 
>   I think of a "Tutorial" as being a *single* representative path through
> a process.  A "Guide" could supply different alternatives.
> 
>   I expect a "Tutorial" to get me from start to finish.  A "Guide" might
> help me along the way, but could be sparser.
> 
>   In summary, I believe the word "Tutorial" implies a very specific
> thing, so we should use it if and only if the doc is exactly that.
> 
>   Eric
> 
> On 09/19/2017 07:23 AM, Alexandra Settle wrote:
> > Hi everyone,
> > 
> >  
> > 
> > I hope everyone had a safe trip home after the PTG!
> > 
> >  
> > 
> > Since the doc-migration, quite a number or individuals have had
> > questions regarding the usage of “Install Tutorial” vs. “Install Guide”
> > in our documentation in the openstack-manuals repo and in the
> > project-specific repos. We (the doc team) agree there should be
> > consistency across all repos and would like to bring this to the table
> > to discuss.
> > 
> >  
> > 
> > Previously, we have used the phrase ‘tutorial’ as the literal
> > translation of a tutorial is that of a /‘paper, book, film, or computer
> > program that provides practical information about a specific subject.’/
> > 
> > / /
> > 
> > Thoughts?
> > 
> >  
> > 
> > Alex
> > 
> > 
> > 
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
>


__
OpenStack Development Mailing 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] Why do we apt-get install NEW files/debs/general at job time ?

[Ian Wienand]

On 09/19/2017 11:03 PM, Jeremy Stanley wrote:

On 2017-09-19 14:15:53 +0200 (+0200), Attila Fazekas wrote:
[...]

The jobs does 120..220 sec apt-get install and packages defined
/files/debs/general are missing from the images before starting the job.



Is the time spent at this stage mostly while downloading package
files (which is what that used to alleviate) or is it more while
retrieving indices or installing the downloaded packages (things
having them pre-retrieved on the images never solved anyway)?


As you're both aware, but others may not be, at the end of the logs
devstack does keep a timing overview that looks something like

=
DevStack Component Timing
=
Total runtime1352

run_process   15
test_with_retry4
apt-get-update 2
pip_install  270
osc  365
wait_for_service  29
dbsync23
apt-get  137
=

That doesn't break things down into download v install, but apt does
have download summary that can be grepped for

---
$ cat devstacklog.txt.gz | grep Fetched
2017-09-19 17:52:45.808 | Fetched 39.3 MB in 1s (26.3 MB/s)
2017-09-19 17:53:41.115 | Fetched 185 kB in 0s (3,222 kB/s)
2017-09-19 17:54:16.365 | Fetched 23.5 MB in 1s (21.1 MB/s)
2017-09-19 17:54:25.779 | Fetched 18.3 MB in 0s (35.6 MB/s)
2017-09-19 17:54:39.439 | Fetched 59.1 kB in 0s (0 B/s)
2017-09-19 17:54:40.986 | Fetched 2,128 kB in 0s (40.0 MB/s)
2017-09-19 17:57:37.190 | Fetched 333 kB in 0s (1,679 kB/s)
2017-09-19 17:58:17.592 | Fetched 50.5 MB in 2s (18.1 MB/s)
2017-09-19 17:58:26.947 | Fetched 5,829 kB in 0s (15.5 MB/s)
2017-09-19 17:58:49.571 | Fetched 5,065 kB in 1s (3,719 kB/s)
2017-09-19 17:59:25.438 | Fetched 9,758 kB in 0s (44.5 MB/s)
2017-09-19 18:00:14.373 | Fetched 77.5 kB in 0s (286 kB/s)
---

As mentioned, we setup the package manager to point to a region-local
mirror during node bringup.  Depending on the i/o situation, it is
probably just as fast as coming off disk :) Note (also as mentioned)
these were never pre-installed, just pre-downloaded to an on-disk
cache area (as an aside, I don't think dnf was ever really happy with
that situation and kept being too smart and clearing it's caches).

If you're feeling regexy you could maybe do something similar with the
pip "Collecting" bits in the logs ... one idea for investigation down
that path is if we could save time by somehow collecting larger
batches of requirements and doing less pip invocations?

-i

__
OpenStack Development Mailing 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-job-failures][ara] Release of openstack/ara failed

[David Moreau Simard]

Ack, I must have missed that.

Thanks for letting me know.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Sep 19, 2017 3:22 PM, "Doug Hellmann"  wrote:

Excerpts from jenkins's message of 2017-09-19 19:10:12 +:
> Build failed.
>
> - ara-tarball http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc2
4e64d1dae6/release/ara-tarball/a75a87f/ : SUCCESS in 3m 17s
> - ara-tarball-signing http://logs.openstack.org/89/
89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-
tarball-signing/f812ce9/ : FAILURE in 41s
> - ara-pypi-both-upload http://logs.openstack.org/89/
89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-pypi-
both-upload/b3367cd/ : SUCCESS in 19s
> - hook-ara-rtfd http://logs.openstack.org/89/
89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/hook-ara-rtfd/574ecf9/ :
SUCCESS in 4s
>

I think we're still under release freeze until the infra team gives us
the all-clear, but when that's done the ara team may want to re-release
this version (or at least coordinate with the infra team to re-run the
failed signing job).

Doug

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

Re: [openstack-dev] [PTG][QA] Queens PTG - QA Summary

[Andrea Frittoli]

On Tue, Sep 19, 2017 at 6:51 PM Andrea Frittoli 
wrote:

> Dear Bats,
>
> thanks everyone for participating to the Queens PTG - in person and
> remotely - and for making it a successful and enjoyable event.
>
> Here's a summary of what we discussed and achieved during the week.
> This report is far from complete - please complement it with QA related
> stories I may have missed.
>
> Unfortunately I ran out of bat stickers, I hope to have some more for the
> next time we meet :)
>
> Pike Retrospective
> -
> We experimented this time with running a retrospective [0].
> The input for the retrospective was almost exclusively from members of the
> QA team, which means that either the retrospective was poorly advertised by
> me, or that we did a nice job for the community during the QA cycle. I hope
> the latter :)
>
> The outcome of the retrospective was mostly 'yay' for tasks completed, and
> 'next cycle' for things we did not have time to work on.
> A few extra things that came up were:
> - bug triage and fix: we may need a bug czar and more automation to stay
> on top of the bug queue
> - elastic recheck categorisation: we may need an e-r czar to ensure we
> don't leave gate failures and races uncategorised and accumulating
> - meetings are mostly attended in the APAC time zone and very seldom
> attended by non-qa folks. We will consider shortening / reducing them and
> complementing them with QA office hours
>
> Monitoring the Gate
> --
> At the beginning of the Pike cycle we had a number of stability issues in
> the gate.
> To prevent issues from accumulating over time we discussed a few ideas
> about monitoring the status of the gate and providing more feedback to
> reviewers to help catch patches that may introduce issues [1].
> There are a few things that can be done relatively easily (or that we
> already have) in terms of data collection: job duration and failure rates,
> aggregated dstat data, resources created by tests.
> We miss OpenStack Health contributors to create new views for this data.
> Links from gerrit and zuul dashboard into OpenStack Health would help
> making the data discoverable.
>
> Tempest
> 
> A large chunk of the patches required to mark test.py as a stable
> interface for plugins was merged during the summit.
> It was good to have them merged during PTG so it was easier to fix
> resulting issues in Tempest plugins - at least Manila and Sahara needed a
> small patch.
> There are two patch series left [2][3] which should have very little
> impact on plugins - we'll try to merge them as soon as possible to avoid
> disruptions later in the Queens cycle.
>
> We worked with a few project teams on the goal to split Tempest plugins to
> a dedicated repo.
> The step by step process [4] linked to the goal includes an example
> section - we hope to get more and more examples in there from team who
> already went through the process.
>
> Devstack
> 
> We discussed about devstack runtime. The time to setup an OpenStack cloud
> using devstack seems to have increased over time [5][6] - it would be good
> to investigate why and see if there is time we can save in the gate and on
> each developer laptop :) Between August and September the average runtime
> in the gate increased by about 200s.
>
> Upgrade Testing
> --
> Rolling upgrade testing via grenade is important for project that seek
> obtaining the support rolling upgrade tag [7].
> While the scope of Grenade is rather fixed, it should be possible to
> support ordering (or relative ordering) in project updates.
>
> Policy Testing
> --
> We discussed what's next for the Queens cycle - support for multi-policy
> testing is the largest chunk of work planned for now.
>
> stestr
> ---
> The migration in ostestr to use stestr internally happened shortly before
> the PTG [8] and we worked through the PTG to amend any deviation in
> behaviour that this may have caused.
> Next in the todo list is to run stestr natively in Tempest, bypassing
> ostestr completely.
> The plan is for this to lead the way for projects to gradually remove the
> dependency to ostestr completely.
>
> HA Testing
> ---
> We talked quite a bit about HA and non-functional testing in general.
> Non-functional testing is not a good fit for gate testing, since it's not
> as reliable as functional / integration testing and it often produces
> results which needs to be interpreted by a human being.
> It also has strong dependencies to the deployment tooling and
> architecture. Until now most of OpenStack non-functional testing has been
> done by vendors and operators using downstream tools.
>
> SamP and guatamdivgi presented to the QA team a proposal for an Ansible
> based framework for HA testing [9]. Plugins will allow to seamlessly port
> different test scenario against different cloud architecture, thus
> rendering the framework 

Re: [openstack-dev] [Release-job-failures][ara] Release of openstack/ara failed

[Doug Hellmann]

Excerpts from jenkins's message of 2017-09-19 19:10:12 +:
> Build failed.
> 
> - ara-tarball 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-tarball/a75a87f/
>  : SUCCESS in 3m 17s
> - ara-tarball-signing 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-tarball-signing/f812ce9/
>  : FAILURE in 41s
> - ara-pypi-both-upload 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-pypi-both-upload/b3367cd/
>  : SUCCESS in 19s
> - hook-ara-rtfd 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/hook-ara-rtfd/574ecf9/
>  : SUCCESS in 4s
> 

I think we're still under release freeze until the infra team gives us
the all-clear, but when that's done the ara team may want to re-release
this version (or at least coordinate with the infra team to re-run the
failed signing job).

Doug

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

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

[Jay S Bryant]

Alex,

I have been working on getting updates to the Cinder Installation 
Tutorial ... Hadn't really even considered the word Tutorial in there to 
be honest as it just fit.  So, I think the important thing is that the 
pages be consistent in the terminology.  It looks like the common top 
level documentation uses 'tutorial'.  I think we would want all the 
other pages to follow the same convention.


Jay


On 9/19/2017 7:23 AM, Alexandra Settle wrote:


Hi everyone,

I hope everyone had a safe trip home after the PTG!

Since the doc-migration, quite a number or individuals have had 
questions regarding the usage of “Install Tutorial” vs. “Install 
Guide” in our documentation in the openstack-manuals repo and in the 
project-specific repos. We (the doc team) agree there should be 
consistency across all repos and would like to bring this to the table 
to discuss.


Previously, we have used the phrase ‘tutorial’ as the literal 
translation of a tutorial is that of a /‘paper, book, film, or 
computer program that provides practical information about a specific 
subject.’/


//

Thoughts?

Alex



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


__
OpenStack Development Mailing 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] [glance] Queens PTG: Thursday summary

[Brian Rosmaita]

On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
 wrote:
> Hi Brian,
> Thanks for the sessions summaries.
>
> We are really interested in the image lifecycle support.
> Can you elaborate how searchlight would help solving this problem?

The role we see for searchlight is more on the image discovery end of
the problem. The context is that we were trying to think of a small
set of image metadata that could uniquely identify a series of images
(os_dist, os_version, local_version) so that it would be easy for end
users to discover the most recent revision with all the security
updates, etc.  For example, you might have:

initial release of public image: os_distro=MyOS, os_version=3.2, local_version=1
security update to package P1: os_distro=MyOS, os_version=3.2, local_version=2
security update to package P2: os_distro=MyOS, os_version=3.2, local_version=4

The image_id would be different on each of these, and the operator
would prefer that users boot from the most recent.  Suppose an
operator also offers a pre-built database image built on each of
these, and a pre-built LAMP stack built on each of these, etc.  Each
would have the same os_distro and os_version value, so we'd need
another field to distinguish them, maybe os_content (values: bare, db,
lamp).  But then with the database image, for a particular (os_distro,
os_version, os_content) tuple, there might be several different images
built for the popular versions of that DB, so we'd need another field
for that as well.  So ultimately it looks like you'd need to make a
complicated query across several image properties, and searchlight
would easily allow you to do that.

This still leaves us with the problem of making it simple to locate
the most recent version of each series of images, and that would be
where something like a 'hidden' property would come in.  It's been
proposed before, but was rejected, I think because it didn't cover
enough use cases.  But that was pre-searchlight, so introducing a
'hidden' field may be a good move now.  It would be interesting to
hear what you think about that.


>
> thanks,
> Belmiro
> CERN
>
> On Fri, Sep 15, 2017 at 4:46 PM, Brian Rosmaita 
> wrote:
>>
>> For those who couldn't attend, here's a quick synopsis of what was
>> discussed yesterday.
>>
>> Please consult the etherpad for each session for details.  Feel free
>> to put questions/comments on the etherpads, and then put an item on
>> the agenda for the weekly meeting on Thursday 21 September, and we'll
>> continue the discussion.
>>
>>
>> Complexity removal
>> --
>> https://etherpad.openstack.org/p/glance-queens-ptg-complexity-removal
>>
>> In terms of a complexity contribution barrier, everyone agreed that
>> the domain model is the largest factor.
>>
>> We also agreed that simplifying it is not something that could happen
>> in the Queens cycle.  It's probably a two-cycle effort, one cycle to
>> ensure sufficient test coverage, and one cycle to refactor.  Given the
>> strategic planning session yesterday, we probably wouldn't want to
>> tackle this until after the registry is completely removed, which is
>> projected to happen in S.
>>
>>
>> Image lifecycle support
>> ---
>> https://etherpad.openstack.org/p/glance-queens-ptg-lifecycle
>>
>> We sketched out several approaches, but trying to figure out a
>> solution that would work across different types of deployments and
>> various use cases gets complicated fast.  It would be better for
>> deployers to use Searchlight to configure complex queries that could
>> use all appropriate image metadata specified by the deployer.
>>
>> For interoperability, deployers could use the common image properties
>> with suggested values on their public images.
>>
>> We looked at two particular approaches that might help operators.  The
>> first would be introducing a kind of 'local_version' field that would
>> be auto-incremented by Glance, the idea being that an image-list query
>> that asked for the max value would yield the most recent version of
>> that image.  One problem, however, is what other metadata would be
>> used in the query, as there might be several versions of images with
>> the same os_distro and os_version properties (for example, the base
>> CentOS 7 image and the LAMP CentOS 7 image).
>>
>> The second approach is introducing a 'hidden' property which would
>> cause the image to be hidden from any image list calls (except for the
>> image owner or glance admin).  This has been requested before, but
>> hasn't been enthusiastically endorsed because it leaves out several
>> use cases.  But combined with Searchlight (with an updated glance
>> plugin to understand the 'hidden' field), it might be the best
>> solution.
>>
>>
>> Should Glance be replaced?
>> --
>> https://etherpad.openstack.org/p/glance-queens-ptg-glance-removal
>>
>> The short answer is No.  Glance is the best way for 

[openstack-dev] QA Forum Topics for Sydney Summit

[Andrea Frittoli]

Dear all,

I would like to start brainstorming about QA related topics for the Forum
at the OpenStack Summit in Sydney.
I setup an etherpad to collect and share ideas [1].

At the PTG in Denver we discussed about non-functional testing for
OpenStack, and I think it would be interesting to discuss about it with the
wider community of OpenStack users and operators, so I went ahead and added
that as a proposed general topic

If you have proposals for topics, please include your IRC nick and/or
contact details as well.

Thank you!

Andrea Frittoli (andreaf)

[1] https://etherpad.openstack.org/p/qa-sydney-forum-topics
__
OpenStack Development Mailing 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] [PTG][QA] Queens PTG - QA Summary

[Andrea Frittoli]

Dear Bats,

thanks everyone for participating to the Queens PTG - in person and
remotely - and for making it a successful and enjoyable event.

Here's a summary of what we discussed and achieved during the week.
This report is far from complete - please complement it with QA related
stories I may have missed.

Unfortunately I ran out of bat stickers, I hope to have some more for the
next time we meet :)

Pike Retrospective
-
We experimented this time with running a retrospective [0].
The input for the retrospective was almost exclusively from members of the
QA team, which means that either the retrospective was poorly advertised by
me, or that we did a nice job for the community during the QA cycle. I hope
the latter :)

The outcome of the retrospective was mostly 'yay' for tasks completed, and
'next cycle' for things we did not have time to work on.
A few extra things that came up were:
- bug triage and fix: we may need a bug czar and more automation to stay on
top of the bug queue
- elastic recheck categorisation: we may need an e-r czar to ensure we
don't leave gate failures and races uncategorised and accumulating
- meetings are mostly attended in the APAC time zone and very seldom
attended by non-qa folks. We will consider shortening / reducing them and
complementing them with QA office hours

Monitoring the Gate
--
At the beginning of the Pike cycle we had a number of stability issues in
the gate.
To prevent issues from accumulating over time we discussed a few ideas
about monitoring the status of the gate and providing more feedback to
reviewers to help catch patches that may introduce issues [1].
There are a few things that can be done relatively easily (or that we
already have) in terms of data collection: job duration and failure rates,
aggregated dstat data, resources created by tests.
We miss OpenStack Health contributors to create new views for this data.
Links from gerrit and zuul dashboard into OpenStack Health would help
making the data discoverable.

Tempest

A large chunk of the patches required to mark test.py as a stable interface
for plugins was merged during the summit.
It was good to have them merged during PTG so it was easier to fix
resulting issues in Tempest plugins - at least Manila and Sahara needed a
small patch.
There are two patch series left [2][3] which should have very little impact
on plugins - we'll try to merge them as soon as possible to avoid
disruptions later in the Queens cycle.

We worked with a few project teams on the goal to split Tempest plugins to
a dedicated repo.
The step by step process [4] linked to the goal includes an example section
- we hope to get more and more examples in there from team who already went
through the process.

Devstack

We discussed about devstack runtime. The time to setup an OpenStack cloud
using devstack seems to have increased over time [5][6] - it would be good
to investigate why and see if there is time we can save in the gate and on
each developer laptop :) Between August and September the average runtime
in the gate increased by about 200s.

Upgrade Testing
--
Rolling upgrade testing via grenade is important for project that seek
obtaining the support rolling upgrade tag [7].
While the scope of Grenade is rather fixed, it should be possible to
support ordering (or relative ordering) in project updates.

Policy Testing
--
We discussed what's next for the Queens cycle - support for multi-policy
testing is the largest chunk of work planned for now.

stestr
---
The migration in ostestr to use stestr internally happened shortly before
the PTG [8] and we worked through the PTG to amend any deviation in
behaviour that this may have caused.
Next in the todo list is to run stestr natively in Tempest, bypassing
ostestr completely.
The plan is for this to lead the way for projects to gradually remove the
dependency to ostestr completely.

HA Testing
---
We talked quite a bit about HA and non-functional testing in general.
Non-functional testing is not a good fit for gate testing, since it's not
as reliable as functional / integration testing and it often produces
results which needs to be interpreted by a human being.
It also has strong dependencies to the deployment tooling and architecture.
Until now most of OpenStack non-functional testing has been done by vendors
and operators using downstream tools.

SamP and guatamdivgi presented to the QA team a proposal for an Ansible
based framework for HA testing [9]. Plugins will allow to seamlessly port
different test scenario against different cloud architecture, thus
rendering the framework of interest as a general testing tool for
OpenStack. The same concept can be extended to non-functional testing in
general.

It's not clear yet if any of this could run as part of OpenStack CI.  We
hope to see a PoC after a couple of months in the Queens cycle.
The NFV ecosystem 

Re: [openstack-dev] [ironic][docs] I see, you see, we all see red*

[Loo, Ruby]

Hi,

In case folks wonder what happened, I submitted a patch [1] to change it to 
black :)

--ruby

[1] https://review.openstack.org/#/c/505348/


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

Date: Thursday, August 24, 2017 at 11:19 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [ironic][docs] I see, you see, we all see red*

Hi Alex,

Sorry, I don't know much about the docs stuff; Andreas' links were useful for 
enlightening me.

Clearly, I'm biased and would prefer no difference in colour. What about that 
(darker?) blue from [0], where it sez (I'm referring to the upper-cased words 
here) 'Modern color theory uses either the ... RED-CYAN, GREEN-MAGENTA, 
BLUE-YELLOW'. Would that blue clash with the blue you are mentioning? (Well, 
maybe it is the bold + blue that I like, not just the blue.)

I don't really think a complementary colour is good, orange is marginally 
better than red. I'd like it to be highlighted but I guess I like subtle, not 
strong.

Having said all that, I'm a reader/viewer of these documents and this is *just* 
my opinion. It seems to me that there might be research into what works best? 
Anyone know?

Thanks,
--ruby

On Thu, Aug 24, 2017 at 6:19 AM, Alexandra Settle 
> wrote:
Hey Ruby!

Good point – thanks for bringing it up :)

I was brought up to think that red was one of those colours that people had 
different (and sometimes really negative) associations with. When I look at our 
latest and greatest! ironic documentation (e.g. [1]), I see red. Not only do I 
see red, but the term has a different background colour and is bordered (or 
whatever it is called). Are we using the wrong .rst syntax, should we be 
highlighting terms differently? And/or is there some way to change the 
appearance of highlighted terms? I much prefer something simple, like bold 
black text in some uniform font. On the other hand, perhaps lots of others like 
this and I'm in the minority.

Andreas is right – the red definitely correct, and this is how we have always 
done it in manuals. But that doesn’t mean we have to continue. We just need to 
come up with another strong, inoffensive colour that matches; I believe the red 
was chosen to simply contrast the blue. A compromise, and complementary 
colour[0], would be orange. How would you feel about this?

I hesitated about sending this due to the wonderful bike shedding that could 
happen, don't disappoint me, cuz I'm sure we all have opinions about colour. :)

Not going to lie, also afraid of all the bike shedding! But you bring up a good 
point – and I don’t want others to also feel negatively about our 
documentation. We should be as inclusive as we can.

Also, this email thread isn't about discussing the green and orange colours 
used for the code blocks; feel free to start your own thread about that if you 
want!

No thanks, if I can avoid it :P

Cheers,

Alex

[0] https://en.wikipedia.org/wiki/Complementary_colors

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

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

[openstack-dev] [cinder] Team Photos from Queens PTG ...

[Jay S Bryant]

All,

Here are the photos from the Queens PTG: 
https://photos.app.goo.gl/tNb1gH6HMyfvfqJN2


Thanks to the foundation for continuing to do them.  They are great to have.

Jay


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

[openstack-dev] [neutron] neutron-lib impact: transitioning to callback payload objects

[Boden Russell]

If your project uses neutron callbacks, please read on.


As we discussed during the PTG [1] in the "Cross project related topics"
section, we'll treat the adoption of the new payload style objects as we
have been with other lib impact changes.

That said, the first (and easiest) set of patches are queued up [2]. All
sub-project patches in [2] should depend on the neutron change [3] and
ideally they can be ready to land when we pull the trigger on [3].

If folks could help with this reviewing effort, it'd go a long way in
making this transition smooth.

Thanks

[1] https://etherpad.openstack.org/p/neutron-queens-ptg
[2] https://review.openstack.org/#/q/message:%22use+new+payload+objects%22
[3] https://review.openstack.org/#/c/474213/

__
OpenStack Development Mailing 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] Queens priorities and release schedule (please read)

[Dmitry Tantsur]

Hi all!

This is an update to our processes based on what we discussed during the PTG.

(1) Queens cycle priorities

We realized that we took too much on ourselves during the Pike cycle. We also 
realized that it ended up with a (false) perception that the priorities list is 
our complete backlog, and what is out of it is out of the release.


This time we took less work overall, and less feature work in particular, to 
address both these issues. So while reviewing the priorities, please keep in 
mind that it is not the complete feature set we expect in Queens, but rather 
what we will consider our key achievements.


Finally, a big part of the priorities were picked by a voting on the PTG. This, 
of course, missed a lot of contributors, and we definitely do not mean to 
exclude them. So, please check the discussion notes at 
https://etherpad.openstack.org/p/ironic-queens-ptg-open-discussion and let us 
know if you think your vote(s) and/or opinion(s) would change the list.


Please leave your comments on the review: https://review.openstack.org/505173. I 
would really appreciate if you could do it by next Monday, especially if you 
have objections. Note that it's mandatory for all cores to vote!


(2) Weekly priorities update

We definitely liked setting weekly review priorities every team meeting. A 
common complain, however, was that this usually excluded vendor work and 
subteam-specific patches. By subteams here I mean bifrost, ironic-inspector, 
sushy, etc (but not ironic-python-agent, or python-ironicclient, or any 
unofficial project).


We decided to address it in a straightforward way. In addition to our regular 
weekly priorities we will accept exactly one patch from each supported driver 
vendor and one from each vendor subteam. The only condition is to put them there 
*before* the meeting, especially if you cannot attend it.


I have updated the whiteboard with a template (see "This Week's Priorities"), 
please do populate it before next Monday's meeting.


An important note: a requirement on exactly one patch does not mean we will not 
review any other patches from the same vendor that week. It only and solely 
means that we will consider only one patch *a priority*.


(3) Release schedule update

To address the difficulties we had with releasing in Pike, we decided the 
following:

a) We will finally stick to a release-often cadence. You can expect intermediary 
ironic releases roughly every months. This is to make sure we constantly keep 
the code base in a releasable form, instead of urgently cleaning it up in the 
end of the cycle.


b) This, in turn, has two consequences. We have to be ready to land incomplete 
features, so we should take care to not expose something non-working to users or 
operators. And we have to do release notes right from the first attempt, in the 
worst case in a follow-up.


c) To avoid issues with grenade in the end of the cycle, we will branch 
stable/queens at the same time as the other projects - on the RC1 week. Features 
not landed before that point will be out of the release.


d) To give us some time to prepare for the branching (e.g. set up rolling 
upgrade bits and finish docs), we will go back to following the standard 
OpenStack feature freeze starting at milestone 3 (2 weeks before branching). 
Feature freeze exceptions may be granted for features that are important enough 
and that are ready for landing by that date.


Please let me know if you have any questions.

Dmitry

__
OpenStack Development Mailing 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][deployment][kolla][tripleo][osa] Service diagnostics task force

[Lars Kellogg-Stedman]

On Wed, Sep 13, 2017 at 7:45 PM, Michał Jastrzębski 
wrote:

> We would to ask for volunteer project team to join us and spearhead this
> effort.
>
>
I would certainly be interested in this effort.

-- 
Lars Kellogg-Stedman 
__
OpenStack Development Mailing 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] Fwd: [Kolla] kolla-kubernetes production ready?

[Richard Wellum]

No it is currently still in development. We are targeting a 1.0 release for
Rocky.

Hope that helps,

||Rich

On Thu, Sep 7, 2017 at 3:52 AM Kim-Norman Sahm 
wrote:

> Hi,
>
> does anybody know when kolla-kubernetes is ready for production?
> is someone using kolla-kubernetes for production now?
>
> regards
> Kim
>
> --
> Kim-Norman Sahm
> Cloud & Infrastructure(OCI)
>
> noris network AG
> Thomas-Mann-Straße 16-20
> 90471 Nürnberg
> Deutschland
>
> Tel +49 911 9352 1433 <+49%20911%2093521433>
> Fax +49 911 9352 100 <+49%20911%209352100>
>
> kim-norman.s...@noris.de
>
> https://www.noris.de - Mehr Leistung als Standard
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
> Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Call for Sydney Summit Forum Topics ...

[Jay S Bryant]

All,

The Sydney Summit will be here before we know it.  With that in Mind, I 
wanted to start some discussion around Forum topics that people would 
like to see for Cinder at the Sydney Summit.  I have created an etherpad 
[1] to collect ideas and have discussion.


If you have possible topics please add them and include your IRC 
nickname and/or relevant contact information.


Thanks!

Jay (jungleboyj)

[1] https://etherpad.openstack.org/p/cinder-sydney-forum-topics


__
OpenStack Development Mailing 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] Reminder: New Etherpad for Meeting Agendas.

[Jay S Bryant]

Team,

Just a friendly reminder that I have moved us to using an Etherpad [1] 
for our weekly team meeting agendas and I will also be keeping notes 
during the meetings there.  If you have agenda items for tomorrow's 
meeting, please add them there.


Thanks!

Jay (jungleboyj)

[1] https://etherpad.openstack.org/p/cinder-queens-meeting-agendas


__
OpenStack Development Mailing 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] [notification] not transforming HostAPI related versioned notifications

[Balazs Gibizer]

Hi,

Similar to my earlier mail about not transforming legacy notifications 
in the networking area [1] now I want to propose not to transform 
HostAPI related notifications.
We have the following legacy notifications on our TODO list [2] to be 
transformed:

* HostAPI.power_action.end
* HostAPI.power_action.start
* HostAPI.set_enabled.end
* HostAPI.set_enabled.start
* HostAPI.set_maintenance.end
* HostAPI.set_maintenance.start

However os-hosts API has been depraceted since microversion 2.43. The 
suggested replacement is os-services API. The os-services API already 
emits service.update notification for every action on that API. So I 
suggest not to transform the above HostAPI notifications to the 
versioned notification format.


Cheers,
gibi


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121968.html

[2] https://vntburndown-gibi.rhcloud.com/index.html


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

Re: [openstack-dev] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Renat Akhmerov]

I confirm that you can delete mistral versions with “2015”.

Thanks

Renat Akhmerov
@Nokia

On 15 Sep 2017, 23:58 +0700, Rong Zhu , wrote:
> +1 for murano-dashboard and murano-agent
>
> On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez  wrote:
> > Claudiu Belu wrote:
> > > So, I believe the general consensus is that the easiest thing to do is to 
> > > unpublish the 2015.1.0 version from pypi, with which I also agree.
> > > [...]
> >
> > Yes, for a first batch I propose we clean up the following:
> >
> > python-congressclient 2015.1.0
> > python-congressclient 2015.1.0rc1
> > python-designateclient 2013.1.a8.g3a2a320
> > networking-hyperv 2015.1.0
> >
> > For the remaining (official) ones (mistral-extra, networking-odl,
> > murano-dashboard, networking-hyperv, networking-midonet,
> > sahara-image-elements, freezer-api, murano-agent, mistral-dashboard,
> > sahara-dashboard) let's wait until we can get PTL signoff.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][fwaas] Proposal to change the time for Firewall-as-a-Service Team Meeting

[reedip banerjee]

Dear All,
Due to clashes of the Firewal-as-a-Service team meetup with the bi-weekly
Neutron and Common-Classifier meeting, it was suggested in today's meetup
to change the timing.

https://doodle.com/poll/c5rgth6y54bpvncu is the Link to vote for the day
when the meeting can be held.

-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedip
__
OpenStack Development Mailing 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] TripleO/Ansible PTG session

[Giulio Fidente]

On 09/18/2017 05:37 PM, James Slagle wrote:
> On Wednesday at the PTG, TripleO held a session around our current use
> of Ansible and how to move forward. I'll summarize the results of the
> session. Feel free to add anything I forgot and provide any feedback
> or questions.

thanks for starting this!

> We discussed the existing uses of Ansible in TripleO and how they
> differ in terms of what they do and how they interact with Ansible. I
> covered this in a previous email[1], so I'll skip over summarizing
> those points again.
> 
> I explained a bit about the  "openstack overcloud config download"
> approach implemented in Pike by the upgrades squad. This method
> no-op's out the deployment steps during the actual Heat stack-update,
> then uses the cli to query stack outputs to create actual Ansible
> playbooks from those output values. The Undercloud is then used as the
> Ansible runner to apply the playbooks to each Overcloud node.
> 
> I created a sequence diagram for this method and explained how it
> would also work for initial stack deployment[2]:
> 
> https://slagle.fedorapeople.org/tripleo-ansible-arch.png
> 
> The high level proposal was to move in a direction where we'd use the
> config download method for all Heat driven stack operations
> (stack-create and stack-update).
> 
> We highlighted and discussed several key points about the method shown
> in the diagram:
> 
> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.

I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong
> - It would still be possible to run ansible-playbook directly for
> various use cases (dev/test/POC/demos). This preserves the quick
> iteration via Ansible that is often desired.
> 
> - The remaining SoftwareDeployment resources in tripleo-heat-templates
> need to be supported by config download so that the entire
> configuration can be driven with Ansible, not just the deployment
> steps. The success criteria for this point would be to illustrate
> using an image that does not contain a running os-collect-config.
> 
> - The ceph-ansible implementation done in Pike could be reworked to
> use this model. "config download" could generate playbooks that have
> hooks for calling external playbooks, or those hooks could be
> represented in the templates directly. The result would be the same
> either way though in that Heat would no longer be triggering a
> separate Mistral workflow just for ceph-ansible.

I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo (like tripleo-apb) and we "compose" from heat the
list of playbooks to be executed based on the roles/enabled services; in
this scenario we'd be much closer to what we had to do for ceph-ansible
and I feel like that might finally allow us merge back the ceph
deployment (or kubernetes deployment) process into the more general
approach driven by tripleo

James, Dan, comments?

> - We will need some centralized log storage for the ansible-playbook
> results and should consider using ARA.
> 
> As it would be a lot of work to eventually make this method the
> default, I don't expect or plan that we will complete all this work in
> Queens. We can however start moving in this direction.
> 
> Specifically, I hope to soon add support to config download for the
> rest of the SoftwareDeployment resources in tripleo-heat-templates as
> that will greatly simplify the undercloud container installer. Doing
> so will illustrate using the ephemeral heat-all process as simply a
> means for generating ansible playbooks.
> 
> I plan to create blueprints this week for Queens and beyond. If you're
> interested in this work, please let me know. I'm open to the idea of
> creating an official squad for this work, but I'm not 

Re: [openstack-dev] [Openstack-operators] [tripleo] Making containerized service deployment the default

[Shake Chen]

I think  tripleo use kolla and kolla-ansible would be perfect.

On Tue, Sep 19, 2017 at 3:47 AM, Mohammed Naser  wrote:

> On Mon, Sep 18, 2017 at 3:04 PM, Alex Schultz  wrote:
> > Hey ops & devs,
> >
> > We talked about containers extensively at the PTG and one of the items
> > that needs to be addressed is that currently we still deploy the
> > services as bare metal services via puppet. For Queens we would like
> > to switch the default to be containerized services.  With this switch
> > we would also start the deprecation process for deploying services as
> > bare metal services via puppet.  We still execute the puppet
> > configuration as part of the container configuration process so the
> > code will continue to be leveraged but we would be investing more in
> > the continual CI of the containerized deployments and reducing the
> > traditional scenario coverage.
> >
> > As we switch over to containerized services by default, we would also
> > begin to reduce installed software on the overcloud images that we
> > currently use.  We have an open item to better understand how we can
> > switch away from the golden images to a traditional software install
> > process during the deployment and make sure this is properly tested.
> > In theory it should work today by switching the default for
> > EnablePackageInstall[0] to true and configuring repositories, but this
> > is something we need to verify.
> >
> > If anyone has any objections to this default switch, please let us know.
>
> I think this is a great initiative.  It would be nice to share some of
> the TripleO experience in containerized deployments so that we can use
> Puppet for containerized deployments.  Perhaps we can work together on
> adding some classes which can help deploy and configure containerized
> services with Puppet.
>
> >
> > Thanks,
> > -Alex
> >
> > [0] https://github.com/openstack/tripleo-heat-templates/blob/
> master/puppet/services/tripleo-packages.yaml#L33-L36
> >
> > ___
> > OpenStack-operators mailing list
> > openstack-operat...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Shake Chen
__
OpenStack Development Mailing 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] [Senlin] Senlin Queens Meetup

[YUAN RUIJIE]

Hi all,

We are going to have a meetup to discuss the features and some other
details about Senlin in Oct.
Tentatively schedule：
Date: 15th Oct.
Location: Beijing, CHN


Please leave your comments if you have any suggestion or the have conflict
with the date.

Sincerely,
ruijie
__
OpenStack Development Mailing 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] dashboard query changes since upgrade

[Sean Dague]

On 09/19/2017 09:00 AM, Sean Dague wrote:
> I've been iterating through gerrit dashboards this morning trying to
> figure out why they no longer show any changes.
> 
> It looks like the query: label:Code-Review>=-2,self now matches changes
> you haven't voted on. Previously (probably to a bug) this only matched
> patches where you had a -2,-1,+1,+2 vote on them.
> 
> I'll be poking around today to figure out what the options are to get
> equivalent functionality is out of the system, then update the gerrit
> dashboards in gerrit-dash-creator based on that.

It appears that reviewedby:self actually works like we were hacking the
old one to work. I've pushed through a bulk fix for most of the
dashboards here - https://review.openstack.org/#/c/505247/

However local versions will need local patching.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [puppet] - No way to pass extra variables from a heat template to a puppet manifest

[James Slagle]

On Tue, Sep 19, 2017 at 6:32 AM, Roquesalane, Jean-Pierre <
jeanpierre.roquesal...@dell.com> wrote:

> Dear fellow stackers,
>
>
>
> I’m currently trying to run a manifest from within a heat template. This
> manifest test the hostname and  depending on the value will do different
> things. I need  to pass some extra variables that are set in an
> environment  file to the manifest, and It failed so far. I’m driving nuts
> at this moment and even though all of the things I found on google, there
> is no way to get it work.
>
> RHOSP 10 is driving my overcloud.
>
>
>
> Any help would be much appreciated.
>
>
>
> Below are the files I’m using.
>
>
>
> ·Heat Template
>
>
>
> heat_template_version: 2016-10-14
>
>
>
> description: >
>
>   NFV Feature Hugepages configured by Puppet for computeNfv role.
>
>
>
> parameters:
>
>   servers:
>
> type: json
>
>   HugePageSize:
>
> type: string
>
>   HugePageCount:
>
> type: string
>
>
>
> resources:
>
>
>
>   NovaComputeExtraConfig:
>
> type: OS::Heat::SoftwareConfig
>
> properties:
>
>   group: puppet
>
>   inputs:
>
>   - name: HugePageSize
>
>   - name: HugePageCount
>
>   config:
>
> get_file: ../manifests/hugepages.pp
>
>   options:
>
> enable_hiera: True
>
> enable_facter: False
>
>
>
>
>
>   ExtraPuppetDeployment:
>
> type: OS::Heat::SoftwareDeployments
>
> properties:
>
>   servers: {get_param: servers}
>
>   config: {get_resource: NovaComputeExtraConfig}
>
>   input_values:
>
> HugePageSize: {get_param: HugePageSize}
>
> HugePageCount: {get_param: HugePageCount}
>
>   actions: ['CREATE','UPDATE']
>
>
>
> ·Puppet manifest
>
> if $hostname =~ /compute-nfv/ {
>
>   file { '/tmp/test_puppet':
>
> ensure => 'file',
>
> content  => "This is an NFV node!!! Setting ${HugePageCount} pages of
> ${HugePageSize} each",
>
> owner => 'root',
>
> group => 'root',
>
> mode => 0777,
>
>   }
>
> } else {
>
>   file { '/tmp/test_puppet':
>
> ensure => 'file',
>
> content  => 'This is not an NFV node... Nothing to set',
>
> owner => 'root',
>
> group => 'root',
>
> mode => 0777,
>
>   }
>
> }
>
>
>
> ·Environment  file
>
> resource_registry:
>
>   OS::TripleO::NodeExtraConfigPost: puppet/services/hugepages.yaml
>
> parameter_defaults:
>
>   OvercloudComputeNfvFlavor: baremetal
>
>   ComputeNfvCount: 3
>
>   HugePageSize: 2048
>
>   HugePageCount: 4
>
>
>

​Since you're setting use_hiera:True in the config, there should be a
hieradata file created for the config under /etc/puppet/hieradata on the
node(s) associated with the deployment.

That hiera file should automatically be included whenever you run puppet
due to the ​FACTER_deploy_config_name fact, and the templated use of
deploy_config_name in the hierarchy configured in /etc/puppet/hiera.yaml.

I'd start by checking all that to see if it got configured correctly. You
should be able to see the full puppet command run by the agent in the
os-collect-config log output on each node, and that may help you
troubleshoot as you can copy/paste the command and rerun it.

Also, you may just try setting use_facter:True in the config and see if
that fixes it as well.

-- 
-- James Slagle
--
__
OpenStack Development Mailing 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] Why do we apt-get install NEW files/debs/general at job time ?

[Jeremy Stanley]

On 2017-09-19 14:15:53 +0200 (+0200), Attila Fazekas wrote:
[...]
> Let's start with the first obvious difference compared to the old-time
> jobs.:
> The jobs does 120..220 sec apt-get install and packages defined
> /files/debs/general are missing from the images before starting the job.
> 
> We used to bake multiple packages into the images based on the package list
> provided by devstack in order to save time.
> 
> Why this does not happens anymore ?
> Is anybody working on solving this issue ?
> Is any blocker technical issue / challenge exists ?
> Was it a design decision ?
[...]

In order to reduce image sizes and the time it takes to build
images, once we had local package caches in each provider we stopped
pre-retrieving packages onto the images. Is the time spent at this
stage mostly while downloading package files (which is what that
used to alleviate) or is it more while retrieving indices or
installing the downloaded packages (things having them pre-retrieved
on the images never solved anyway)?

Our earlier analysis of the impact of dropping package files from
images indicated it was negligible for most jobs because of the
caching package mirrors we maintain nearby.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [nova] Queens PTG recap - everything else

[Matt Riedemann]

On 9/19/2017 7:52 AM, Belmiro Moreira wrote:

I didn't find any mention to nested quotas.
Was it discussed in the PTG? and what can we expect for Queens?


There is no one driving the unified limits work [1] so nested quotas is 
stalled and we didn't spend any time discussing it at the PTG.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121944.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] [all] dashboard query changes since upgrade

[Sean Dague]

I've been iterating through gerrit dashboards this morning trying to
figure out why they no longer show any changes.

It looks like the query: label:Code-Review>=-2,self now matches changes
you haven't voted on. Previously (probably to a bug) this only matched
patches where you had a -2,-1,+1,+2 vote on them.

I'll be poking around today to figure out what the options are to get
equivalent functionality is out of the system, then update the gerrit
dashboards in gerrit-dash-creator based on that.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [nova] Queens PTG recap - everything else

[Belmiro Moreira]

Hi Matt,
thanks for these great summaries.

I didn't find any mention to nested quotas.
Was it discussed in the PTG? and what can we expect for Queens?

thanks,
Belmiro
CERN

On Mon, Sep 18, 2017 at 11:58 PM, Matt Riedemann 
wrote:

> There was a whole lot of other stuff discussed at the PTG. The details are
> in [1]. I won't go into everything here, so I'm just highlighting some of
> the more concrete items that had owners or TODOs.
>
> Ironic
> --
>
> The Ironic team came over on Wednesday afternoon. We talked a bit, had
> some laughs, it was a good time. Since I don't speak fluent baremetal,
> Dmitry Tantsur is going to recap those discussions in the mailing list.
> Thanks again, Dmitry.
>
> Privsep
> ---
>
> Michael Still has been going hog wild converting the nova libvirt driver
> code to use privsep instead of rootwrap. He has a series of changes tracked
> under this blueprint [2]. Most of the discussion was a refresh on privsep
> and a recap of what's already been merged and some discussion on
> outstanding patches. The goal for Queens is to get the entire libvirt
> driver converted and also try to get all of nova-compute converted, but we
> want to limit that to getting things merged early in the release to flush
> out bugs since a lot of these are weird, possibly untested code paths.
> There was also discussion of a kind of privsep heartbeat daemon to tell if
> it's running (even though it's not a separate service) but this is
> complicated and is not something we'll pursue for Queens.
>
> Websockify security proxy framework
> ---
>
> This is a long-standing security hardening feature [3] which has changed
> hands a few times and hasn't gotten much review. Sean Dague and Melanie
> Witt agreed to focus on reviewing this for Queens.
>
> Certificate validation
> --
>
> This is another item that's been discussed since at least the Ocata summit
> but hasn't made much progress. Sean Dague agreed to help review this, and
> Eric Fried said he knew someone that could help review the security aspects
> of this change. Sean also suggested scheduling a hangout so the John
> Hopkins University team working on this can give a primer on the feature
> and what to look out for during review. We also suggested getting a
> scenario test written for this in the barbican tempest plugin, which runs
> as an experimental queue job for nova.
>
> Notifications
> -
>
> Given the state of the Searchlight project and how we don't plan on using
> Searchlight as a global proxy for the compute REST API, we are not going to
> work on parity with versioned notifications there. There are some cleanups
> we still need to do in Nova for versioned notifications from a performance
> perspective. We also agreed that we aren't going to consider deprecating
> legacy unversioned notifications until we have parity with the versioned
> notifications, especially given legacy unversioned notification consumers
> have not yet moved to using the versioned notifications.
>
> vGPU support
> 
>
> This depends on nested resource providers (like lots of other things). It
> was not clear from the discussion if this is static or dynamic support,
> e.g. can we hot plug vGPUs using Cyborg? I assume we will not support hot
> plugging at first. We also need improved functional testing of this space
> before we can make big changes.
>
> Preemptible (spot) instances
> -
>
> This was continuing the discussion from the Boston forum session [5]. The
> major issue in Nova is that we don't want Nova to be in charge of
> orchestrating preempting instances when a request comes in for a "paid"
> instance. We agreed to start small where you can't burst over quota. Blazar
> also delivered some reservation features in Pike [6] which sound like they
> can be built on here, which also sound like expiration policies. Someone
> will have to prototype an external (to nova) "reaper" which will cull the
> preemptible instances based on some configurable policy. Honestly the notes
> here are confusing so we're going to need someone to drive this forward.
> That might mean picking up John Garbutt's draft spec for this (link not
> available right now).
>
> Driver updates
> --
>
> Various teams from IBM gave updates on plans for their drivers in Queens.
>
> PowerVM (in tree): the team is proposing a few more capabilities to the
> driver in Queens. Details are in the spec [7].
>
> zDPM (out of tree): this out of tree driver has had two releases (ocata
> and pike) and is working on 3rd party CI. One issue they have with Tempest
> is they can only boot from volume.
>
> zVM (out of tree): the team is working on refactoring some code into a
> library, similar to os-xenapi, os-powervm and oslo.vmware. They have CI
> running but are not yet reporting against nova changes.
>
> Endpoint discovery
> --
>
> This is carry-over work 

[openstack-dev] [neutron] [classifier] No meeting today

[Duarte Cardoso, Igor]

There is no CCF meeting today since key people are on vacation.

Current work can be seen at 
https://review.openstack.org/#/q/project:openstack/neutron-classifier.

Best regards,
Igor D.C.

__
OpenStack Development Mailing 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] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

[Michał Dulko]

On wto, 2017-09-19 at 09:19 +0200, Andreas Jaeger wrote:
> Two things currently:
> 
> * no post jobs are run, I suggest to not tag anything
> 
> * I don't get emails from gerrit anymore
> 

Same here, since the outage I've stopped receiving Gerrit notifications
to my email.

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-dev] [puppet] - No way to pass extra variables from a heat template to a puppet manifest

[Roquesalane, Jean-Pierre]

Dear fellow stackers,

I'm currently trying to run a manifest from within a heat template. This 
manifest test the hostname and  depending on the value will do different 
things. I need  to pass some extra variables that are set in an environment  
file to the manifest, and It failed so far. I'm driving nuts at this moment and 
even though all of the things I found on google, there is no way to get it work.
RHOSP 10 is driving my overcloud.

Any help would be much appreciated.

Below are the files I'm using.


*Heat Template

heat_template_version: 2016-10-14

description: >
  NFV Feature Hugepages configured by Puppet for computeNfv role.

parameters:
  servers:
type: json
  HugePageSize:
type: string
  HugePageCount:
type: string

resources:

  NovaComputeExtraConfig:
type: OS::Heat::SoftwareConfig
properties:
  group: puppet
  inputs:
  - name: HugePageSize
  - name: HugePageCount
  config:
get_file: ../manifests/hugepages.pp
  options:
enable_hiera: True
enable_facter: False


  ExtraPuppetDeployment:
type: OS::Heat::SoftwareDeployments
properties:
  servers: {get_param: servers}
  config: {get_resource: NovaComputeExtraConfig}
  input_values:
HugePageSize: {get_param: HugePageSize}
HugePageCount: {get_param: HugePageCount}
  actions: ['CREATE','UPDATE']


*Puppet manifest
if $hostname =~ /compute-nfv/ {
  file { '/tmp/test_puppet':
ensure => 'file',
content  => "This is an NFV node!!! Setting ${HugePageCount} pages of 
${HugePageSize} each",
owner => 'root',
group => 'root',
mode => 0777,
  }
} else {
  file { '/tmp/test_puppet':
ensure => 'file',
content  => 'This is not an NFV node... Nothing to set',
owner => 'root',
group => 'root',
mode => 0777,
  }
}


*Environment  file
resource_registry:
  OS::TripleO::NodeExtraConfigPost: puppet/services/hugepages.yaml
parameter_defaults:
  OvercloudComputeNfvFlavor: baremetal
  ComputeNfvCount: 3
  HugePageSize: 2048
  HugePageCount: 4

Thanks.
JP

Jean-Pierre Roquesalane
SW System Sr Principal Engineer
Dell | Service Provider Solutions
mobile +33 6 21 86 79 04
jeanpierre.roquesal...@dell.com
[cid:image002.jpg@01D33153.A5CB7F60]

__
OpenStack Development Mailing 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] [docs][ptls][install] Install guide vs. tutorial

[Alexandra Settle]

Hi everyone,

I hope everyone had a safe trip home after the PTG!

Since the doc-migration, quite a number or individuals have had questions 
regarding the usage of “Install Tutorial” vs. “Install Guide” in our 
documentation in the openstack-manuals repo and in the project-specific repos. 
We (the doc team) agree there should be consistency across all repos and would 
like to bring this to the table to discuss.

Previously, we have used the phrase ‘tutorial’ as the literal translation of a 
tutorial is that of a ‘paper, book, film, or computer program that provides 
practical information about a specific subject.’

Thoughts?

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

[openstack-dev] [devstack] Why do we apt-get install NEW files/debs/general at job time ?

[Attila Fazekas]

The gate-tempest-dsvm-neutron-full-ubuntu-xenial job is 20..30 min slower
than it supposed to be/used to be.

The extra time has multiple reasons and it is not because we test more :( .
Usually we are just less smart than before.

Huge time increment is visible in devstack as well.
devstack is advertised as:

Running devstack ... this takes 10 - 15 minutes (logs in
logs/devstacklog.txt.gz)

The actual time is 20 - 25 min according to openstack health:
http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day=P6M


Let's start with the first obvious difference compared to the old-time
jobs.:
The jobs does 120..220 sec apt-get install and packages defined
/files/debs/general are missing from the images before starting the job.

We used to bake multiple packages into the images based on the package list
provided by devstack in order to save time.

Why this does not happens anymore ?
Is anybody working on solving this issue ?
Is any blocker technical issue / challenge exists ?
Was it a design decision ?

We have similar issue with pypi usage as well.

PS.:
Generally a good idea to group these kind of package install commands to
one huge pip/apt-get/yum .. invocation, because these tools has significant
start up time and they also need to process the dependency graph at
install/update.
__
OpenStack Development Mailing 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] Team photos

[Dmitry Tantsur]

Hi all!

Here are wonderful team photos from the PTG:
serious - https://www.dropbox.com/s/9nz92cjm1sztqpl/ironic-team-serious.JPG?dl=0
funny - https://www.dropbox.com/s/ue4xcklvewhxdt2/ironic-team-funny.JPG?dl=0

Thanks Kendall for organizing it!

Dmitry.

P.S.
I have to apologize to people who did not get to these photos due to last-minute 
scheduling change.


__
OpenStack Development Mailing 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] [mogan] 0.1.0 release

[Zhenguo Niu]

Hi folks,

Today Mogan has been released first time, thanks all great people and
contributors who worked on Mogan 0.1.0 and everybody who helped us!

Mogan is a project which offers bare metals as first class resources to
users. During 0.1.0, we have almost wrapped up the work to catch up with
nova and filled the gaps between bare metals and virtual machines such as
aggregates and server groups.

Here are our release notes:
http://mogan.readthedocs.io/projects/releasenotes/en/latest/0.1.0.html

Other useful links:

- Wiki: https://wiki.openstack.org/wiki/Mogan
- Documentation: http://mogan.readthedocs.io/en/latest/
- APIs: http://mogan.readthedocs.io/projects/api-ref/en/latest/
- Source: https://git.openstack.org/cgit/openstack/mogan
- Launchpad: https://launchpad.net/mogan


-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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][3rd-party ci] Voting INSPUR-CI

[Ivan Kolodyazhny]

Thank you, Sean!

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

On Mon, Sep 18, 2017 at 11:49 PM, Sean McGinnis 
wrote:

> On Mon, Sep 18, 2017 at 12:20:24PM -0500, Jay S Bryant wrote:
> > All,
> >
> > I am adding the e-mails from the Inspur CI in the OpenStack 3rd Party CI
> > Wiki in case they do not monitor the mailing list.
> >
> > Inspur CI team,
> >
> > Please see the e-mails below.  Your job is currently voting and should
> not
> > be.  Please update your config to be non-voting.
> >
> > Thank you!
> >
> > Jay
> >
>
> Sorry, I think I caused this by adding them to the cinder-ci group in an
> attempt to get them to stop showing up even when Filter CI was toggled. I
> noticed that this morning and had removed them again before the gerrit down
> time. It should not show up anymore.
>
> Although I still need to remember how they need to be registered to get
> them
> out of the filtered comments.
>
>
> __
> OpenStack Development Mailing 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] [karbor] Proposing Pengju Jiao to the Karbor core team

[Chen Ying]

Hey all,

 I'm proposing that we add Pengju Jiao to the Karbor core team. Pengju Jiao
has been actively contributing to the Karbor project from Pike.  His
contributions include proposing high-quality codes, providing helpful code
reviews, participating team discussion at weekly team meeting and IRC, etc.
He also did a great job about s3 bank and the freezer integration with
karbor. So I'm proposing adding him to the core team. Let me know if there
are any objections.


Best regards,
Chen Ying
__
OpenStack Development Mailing 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] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

[Andreas Jaeger]

Two things currently:

* no post jobs are run, I suggest to not tag anything

* I don't get emails from gerrit anymore

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


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

Re: [openstack-dev] [all] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

[Andrea Frittoli]

On Tue, Sep 19, 2017 at 12:58 AM Clark Boylan  wrote:

> On Mon, Sep 18, 2017, at 06:43 AM, Andreas Jaeger wrote:
> > Just a friendly reminder that the upgrade will happen TODAY, Monday
> > 18th, starting at 15:00 UTC. The infra team expects that it takes 8
> > hours, so until 2359 UTC.
>
> This work was functionally completed at 23:43 UTC. We are now running
> Gerrit 2.13.9. There are some cleanup steps that need to be performed in
> Infra land, mostly to get puppet running properly again.
>

Thanks Clark and the infra team for the hard on this!


>
> You will also notice that newer Gerrit behaves in some new and exciting
> ways. Most of these should be improvements like not needing to reapprove
> changes that already have a +1 Workflow but also have a +1 Verified;
> recheck should now work for these cases. If you find a new behavior that
> looks like a bug please let us know, but we should also work to file
> them upstream so that newer Gerrit can address them.
>

The "review-inbox-dashboard
"
dashboards
seems not be working anymore - at least they show up empty for a few
projects I tried [0][1][2][3].

Andrea Frittoli (andreaf)

[0] Tempest:
https://review.openstack.org/#/projects/openstack/tempest,dashboards/important-changes:review-inbox-dashboard

[1] subunit2sql:
https://review.openstack.org/#/projects/openstack-infra/subunit2sql,dashboards/important-changes:review-inbox-dashboard

[2] devstack:
https://review.openstack.org/#/projects/openstack-dev/devstack,dashboards/important-changes:review-inbox-dashboard

[3] nova:
https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard



>
> Feel free to ask us questions if anything else comes up.
>


>
> Thank you to everyone that helped with the upgrade. Seems like these get
> more and more difficult with each Gerrit release so all the help is
> greatly appreciated.
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [Zun] Propose change of the core team

[Shuu Mutou]

+1 for both.

Thanks,
Shu

> -Original Message-
> From: Kumari, Madhuri [mailto:madhuri.kum...@intel.com]
> Sent: Monday, September 18, 2017 1:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose change of the core team
> 
> +1 for both. Thanks Kien for all your work in Zun, especially multi-node
> CI.
> 
> 
> 
> Regards,
> 
> Madhuri
> 
> 
> 
> From: Pradeep Singh [mailto:ps4openst...@gmail.com]
> Sent: Sunday, September 17, 2017 8:35 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Zun] Propose change of the core team
> 
> 
> 
> +1 for both
> 
> 
> 
> On Sun, Sep 17, 2017 at 4:26 AM, Kevin Zhao   > wrote:
> 
>   +1 on both
> 
> 
> 
>   On 15 September 2017 at 08:40, Qiming Teng
>  > wrote:
> 
>   +1 on both.
> 
> 
>   On Thu, Sep 14, 2017 at 01:58:48PM +, Hongbin Lu wrote:
>   > Hi all,
>   >
>   > I propose the following change of the Zun core reviewer
> team.
>   >
>   > + Kien Nguyen (kiennt2609)
>   > - Aditi Sharma (adi-sky17)
>   >
>   > Kien has been contributing to the Zun project for a few
> months. His contributions include proposing high-quality codes, providing
> helpful code reviews, participating team discussion at weekly team meeting
> and IRC, etc. He is the one who setup the multi-node job in the CI and the
> job is up and running now. I think his contribution is significant which
> qualifies him to be a core reviewer. Aditi is a member of the initial core
> team but becomes inactive for a while.
>   >
>   > Core reviewers, please cast your vote on this proposal.
>   >
>   > Best regards,
>   > Hongbin
> 
> 
> 
> 
>   __
> 
>   OpenStack Development Mailing 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