[openstack-dev] [os-upstream-institute] No meeting on Monday (July 3)

[Ildiko Vancsa]

Hi Training Team,

It is a reminder that we are canceling the meeting next Monday (July 3) due to 
the holiday in the US.

The next meeting is on Tuesday, July 10, 0900 UTC on #openstack-mmeting-3. The 
next US friendly time slot is July 17, 2000 UTC.

Have a good (long) weekend! :)

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

Re: [openstack-dev] [openstack-ansible][neutron][designate][dns] dns plugin suppressed in neutron.conf.j2 template

[Lawrence J. Albinson]

On 30/06/17 16:12, Graham Hayes wrote:
> On 30/06/17 13:29, Lawrence J. Albinson wrote:
>> Good Afternoon Colleagues,
>>
>> I've been working to incorporate dynamic dns/designate updating from
>> neutron and nova within an OpenStack-Ansible built environment.
>>
>> I note that the dns plugin is explicitly suppressed in the
>> openstack-ansible-os_neutron role here:
>>
>> https://github.com/openstack/openstack-ansible-os_neutron/blob/master/templates/neutron.conf.j2#L5
>>
>> I'm curious to know why this is.
> So am I - I filed
> https://bugs.launchpad.net/openstack-ansible/+bug/1701609 with them, so
> we can follow up.
>
> - Graham
>
>> Kind regards, Lawrence
>>
>> Lawrence J Albinson
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
Thank you Graham,

For what it's worth, I don't see any dns or designate related drivers in
the neutron repo.

Regards, Lawrence


__
OpenStack Development Mailing 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] realtime kvm cpu affinities

[Chris Friesen]

On 06/30/2017 07:06 AM, sfinu...@redhat.com wrote:

On Thu, 2017-06-29 at 12:20 -0600, Chris Friesen wrote:

On 06/29/2017 10:59 AM, sfinu...@redhat.com wrote:



  From the above, there are 3-4 work items:

- Add a 'emulator_pin_set' or 'cpu_emulator_threads_mask' configuration
option

- If using a mask, rename 'vcpu_pin_set' to 'pin_set' (or, better,
  'usable_cpus')

- Add a 'emulator_overcommit_ratio', which will do for emulator threads
what
the other ratios do for vCPUs and memory


If we were going to support "emulator_overcommit_ratio", then we wouldn't
necessarily need an explicit mask/set as a config option. If someone wants
to run with 'hw:emulator_thread_policy=isolate' and we're below the
overcommit ratio then we run it, otherwise nova could try to allocate a new
pCPU to add to the emulator_pin_set internally tracked by nova.  This would
allow for the number of pCPUs in emulator_pin_set to vary depending on the
number of instances with 'hw:emulator_thread_policy=isolate'on the compute
node, which should allow for optimal packing.


So we'd now mark pCPUs not only as used, but also as used for a specific
purpose? That would probably be more flexible that using a static pool of CPUs,
particularly if instances are heterogeneous. I'd imagine it would, however, be
much tougher to do right. I need to think on this.


I think you could do it with a new "emulator_cpus" field in NUMACell, and a new 
"emulator_pcpu" field in InstanceNUMACell.



As an aside, what would we do about billing? Currently we include CPUs used for
emulator threads as overhead. Would this change?


We currently have local changes to allow instances with "shared" and "dedicated" 
CPUs to coexist on the same compute node.  For CPU usage, "dedicated" CPUs count 
as "1", and "shared" CPUs count as 1/cpu_overcommit_ratio.  That way the total 
CPU usage can never exceed the number of available CPUs.


You could follow this model and bill for an extra 1/emulator_overcommit_ratio 
worth of a CPU for instances with 'hw:emulator_thread_policy=isolate'.



- Deprecate 'hw:emulator_thread_policy'???


I'm not sure we need to deprecate it, it would instead signify whether the
emulator threads should be isolated from the vCPU threads.  If set to
"isolate" then they would run on the emulator_pin_set identified above
(potentially sharing them with emulator threads from other instances) rather
than each instance getting a whole pCPU for its emulator threads.


I'm confused, I thought we weren't going to need 'emulator_pin_set'?


I meant whatever field we use internally to track which pCPUs are currently 
being used to run emulator threads as opposed to vCPU threads.  (ie the 
"emulator_cpus" field in NUMACell suggested above.


> In any

case, it's probably less about deprecating the extra spec and instead changing
how things work under the hood. We'd actually still want something to signify
"I want my emulator overhead accounted for separately".


Agreed.

Chris

__
OpenStack Development Mailing 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] [FEMDC][MassivelyDistributed] Strawman proposal for message bus analysis

[Paul-Andre Raymond]

Hi Matthieu,

You mentioned 15000 connections with 1000 compute nodes.
Was that mostly Nova? Was ceilometer involved?
I would be curious to know how much AMQP traffic is Control related 
(e.g. spinning up VMs) vs how much is telemetry related in a typical openstack 
deployment.
Do we know that?

I have also left some comments in the doc.

Paul-Andre


-Original Message-
From: Matthieu Simonin 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, June 21, 2017 at 6:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman 
proposal formessage bus analysis

Hi Ken,

Thanks for starting this !
I've made a first pass on the epad and left some notes and questions 
there.

Best,

Matthieu
- Mail original -
> De: "Ken Giusti" 
> À: "OpenStack Development Mailing List (not for usage questions)" 

> Envoyé: Mercredi 21 Juin 2017 15:23:26
> Objet: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman 
proposal formessage bus analysis
> 
> Hi All,
> 
> Andy and I have taken a stab at defining some test scenarios for anal 
the
> different message bus technologies:
> 
> https://etherpad.openstack.org/p/1BGhFHDIoi
> 
> We've started with tests for just the oslo.messaging layer to analyze
> throughput and latency as the number of message bus clients - and the 
bus
> itself - scale out.
> 
> The next step will be to define messaging oriented test scenarios for 
an
> openstack deployment.  We've started by enumerating a few of the 
tools,
> topologies, and fault conditions that need to be covered.
> 
> Let's use this epad as a starting point for analyzing messaging - 
please
> feel free to contribute, question, and criticize :)
> 
> thanks,
> 
> 
> 
> --
> Ken Giusti  (kgiu...@gmail.com)
> 
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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




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

[openstack-dev] [ironic] [stable] another ironic-stable-maint update proposal

[Dmitry Tantsur]

Hi all!

I'd like to propose another round of changes to the ironic-stable-maint group 
[0]:

1. Add Julia Kreger (TheJulia) to the group. Julia is one of the top reviewers 
in Ironic, and she is quite active on stable branches as well [1].


2. Remove Jim Rollenhagen (sigh..) as he no longer works on OpenStack.

So for those on the team already, please reply with a +1 or -1 vote.
I'll also need somebody to apply this change, as I don't have ACL for that.

[0] https://review.openstack.org/#/admin/groups/950,members
[1] 
https://review.openstack.org/#/q/(project:openstack/ironic+OR+project:openstack/ironic-python-agent+OR+project:openstack/ironic-lib)+NOT+branch:master+reviewer:%22Julia+Kreger+%253Cjuliaashleykreger%2540gmail.com%253E%22


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

Re: [openstack-dev] [openstack-ansible][neutron][designate][dns] dns plugin suppressed in neutron.conf.j2 template

[Graham Hayes]

On 30/06/17 13:29, Lawrence J. Albinson wrote:
> Good Afternoon Colleagues,
> 
> I've been working to incorporate dynamic dns/designate updating from
> neutron and nova within an OpenStack-Ansible built environment.
> 
> I note that the dns plugin is explicitly suppressed in the
> openstack-ansible-os_neutron role here:
> 
> https://github.com/openstack/openstack-ansible-os_neutron/blob/master/templates/neutron.conf.j2#L5
> 
> I'm curious to know why this is.

So am I - I filed
https://bugs.launchpad.net/openstack-ansible/+bug/1701609 with them, so
we can follow up.

- Graham

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



0x23BA8E2E.asc
Description: application/pgp-keys


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] [tripleo] CI Squad Meeting Summary (week 26) - job renaming discussion

[Jiří Stránský]

On 30.6.2017 17:06, Jiří Stránský wrote:

On 30.6.2017 15:04, Attila Darazs wrote:

= Renaming the CI jobs =

When we started the job transition to Quickstart, we introduced the
concept of featuresets[1] that define a certain combination of features
for each job.

This seemed to be a sensible solution, as it's not practical to mention
all the individual features in the job name, and short names can be
misleading (for example ovb-ha job does so much more than tests HA).

We decided to keep the original names for these jobs to simplify the
transition, but the plan is to rename them to something that will help
to reproduce the jobs locally with Quickstart.

The proposed naming scheme will be the same as the one we're now using
for job type in project-config:

gate-tripleo-ci-centos-7-{node-config}-{featureset-config}

So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job
would look like "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001"


I'd prefer to keep the job names somewhat descriptive... If i had to
pick one or the other, i'd rather stick with the current way, as at
least for me it's higher priority to see descriptive names in CI results
than saving time on finding featureset file mapping when needing to
reproduce a job result. My eyes scan probably more than a hundred of
individual CI job results daily, but i only need to reproduce 0 or 1 job
failures locally usually.

Alternatively, could we rename "featureset001.yaml" into
"featureset-ovb-ha.yaml" and then have i guess something like
"gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-ovb-ha" for the job name?
Maybe "ovb" would be there twice, in case it's needed both in node
config and featureset parts of the job name...

Or we could pull the mapping between job name and job type in an
automated way from project-config.


^ I mean for the purposes of reproducing a CI job, in a similar way we 
do it for running the CI job in the first place.




(Will be on PTO for a week from now, apologies if i don't respond timely
here.)


Have a good day,

Jirka



The advantage of this will be that it will be easy to reproduce a gate
job on a local virthost by typing something like:

./quickstart.sh --release tripleo-ci/master \
   --nodes config/nodes/3ctlr_1comp.yml \
   --config config/general_config/featureset001.yml \
   

Please let us know if this method sounds like a step forward.



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

Re: [openstack-dev] [tripleo] CI Squad Meeting Summary (week 26) - job renaming discussion

[Jiří Stránský]

On 30.6.2017 15:04, Attila Darazs wrote:

= Renaming the CI jobs =

When we started the job transition to Quickstart, we introduced the
concept of featuresets[1] that define a certain combination of features
for each job.

This seemed to be a sensible solution, as it's not practical to mention
all the individual features in the job name, and short names can be
misleading (for example ovb-ha job does so much more than tests HA).

We decided to keep the original names for these jobs to simplify the
transition, but the plan is to rename them to something that will help
to reproduce the jobs locally with Quickstart.

The proposed naming scheme will be the same as the one we're now using
for job type in project-config:

gate-tripleo-ci-centos-7-{node-config}-{featureset-config}

So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job
would look like "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001"


I'd prefer to keep the job names somewhat descriptive... If i had to 
pick one or the other, i'd rather stick with the current way, as at 
least for me it's higher priority to see descriptive names in CI results 
than saving time on finding featureset file mapping when needing to 
reproduce a job result. My eyes scan probably more than a hundred of 
individual CI job results daily, but i only need to reproduce 0 or 1 job 
failures locally usually.


Alternatively, could we rename "featureset001.yaml" into 
"featureset-ovb-ha.yaml" and then have i guess something like 
"gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-ovb-ha" for the job name? 
Maybe "ovb" would be there twice, in case it's needed both in node 
config and featureset parts of the job name...


Or we could pull the mapping between job name and job type in an 
automated way from project-config.


(Will be on PTO for a week from now, apologies if i don't respond timely 
here.)



Have a good day,

Jirka



The advantage of this will be that it will be easy to reproduce a gate
job on a local virthost by typing something like:

./quickstart.sh --release tripleo-ci/master \
  --nodes config/nodes/3ctlr_1comp.yml \
  --config config/general_config/featureset001.yml \
  

Please let us know if this method sounds like a step forward.


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

[openstack-dev] [tripleo] [ui] Integration testing in tripleo-ci

[Honza Pokorny]

I'd like to write some integration tests for the TripleO UI.  Simple
configuration checks, workflow tests, websocket tests, etc.

I had a quick look at the tripleo-ci [1] repository, and it wasn't
immediately obvious to me how to extend the existing infrastructure to
add something like this.  It seems to me that the current way is just
"stick some shell script here and here".  The tripleo.sh script is about
1,600 LOC and it look rather intimidating.

I'm looking for help or pointers on how to do this.  Is there a standard
way of accomplishing this?  Are there any helpers I should be aware of?
Is there any documentation beyond what is in the git tree?

Any help would be appreciated

Thanks!

Honza Pokorny

[1]: https://github.com/openstack-infra/tripleo-ci

__
OpenStack Development Mailing 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] Retiring clouddocs-maven-plugin

[Anne Gentle | Just Write Click]

Yes! Thank you, nice to lift that up up and away!
 - 
Anne

> On Jun 30, 2017, at 9:30 AM, Alexandra Settle  wrote:
> 
> Sound proposal. +1 
> 
> Thanks Andreas
> 
> On 6/30/17, 2:16 PM, "Andreas Jaeger"  wrote:
> 
>It's IMHO time to retire
>http://git.openstack.org/cgit/openstack/clouddocs-maven-plugin/ - this
>was used to build documents from XML.
> 
>We converted all documents to RST, have released the last version in
>April 2015, and not merged anything since May 2016.
> 
>Current openstack-manuals got fully converted to RST with Mitaka, so we
>have no current branches that need this.
> 
>Thus I propose to retire the repo and will propose patches for it. Once
>those are submitted, I'll reply here with references to them,
> 
>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
> 
> 
> __
> OpenStack Development Mailing 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] [docs] Retiring clouddocs-maven-plugin

[Alexandra Settle]

Sound proposal. +1 

Thanks Andreas

On 6/30/17, 2:16 PM, "Andreas Jaeger"  wrote:

It's IMHO time to retire
http://git.openstack.org/cgit/openstack/clouddocs-maven-plugin/ - this
was used to build documents from XML.

We converted all documents to RST, have released the last version in
April 2015, and not merged anything since May 2016.

Current openstack-manuals got fully converted to RST with Mitaka, so we
have no current branches that need this.

Thus I propose to retire the repo and will propose patches for it. Once
those are submitted, I'll reply here with references to them,

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


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

Re: [openstack-dev] [OpenStack-docs] [docs] Retiring clouddocs-maven-plugin

[Andreas Jaeger]

On 2017-06-30 15:16, Andreas Jaeger wrote:
> It's IMHO time to retire
> http://git.openstack.org/cgit/openstack/clouddocs-maven-plugin/ - this
> was used to build documents from XML.
> 
> We converted all documents to RST, have released the last version in
> April 2015, and not merged anything since May 2016.
> 
> Current openstack-manuals got fully converted to RST with Mitaka, so we
> have no current branches that need this.
> 
> Thus I propose to retire the repo and will propose patches for it. Once
> those are submitted, I'll reply here with references to them,

Patches are up with topic retire-clouddocs-maven-plugin,

see https://review.openstack.org/#/q/topic:retire-clouddocs-maven-plugin

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][tc] How to deal with confusion around "hosted projects"

[Jeremy Stanley]

On 2017-06-30 11:31:01 +1000 (+1000), Joshua Hesketh wrote:
[...]
> has anybody looked at how difficult it would be to actually to
> fix gerrit,

There was an abandoned attempt to implement it in core:

https://gerrit-review.googlesource.com/q/project:gerrit+topic:rename-project

And there's still the vestige of an empty plugin attempt which never
had any code pushed up to it:

https://gerrit.googlesource.com/plugins/rename-project/

Being in Java is a bit of a roadblock for me personally to reattempt
to tackle it. I'm just a lowly sysadmin so if it's not
c/shell/perl/python my learning curve is pretty steep.

Given that Gerrit is used lots of places by lots of orgs and yet
their forums have a scant handful of posts on this subject from
people who suddenly discovered they needed to rename a single
project after years of running, I have to ask whether what we're
doing needing to rename things constantly isn't just plain counter
to the way the software is intended to be applied. Makes me think we
should just be finding ways to avoid renaming things over and over,
even if that means switching all repository names to UUIDs (okay,
mostly kidding there... _mostly_).

> automate github (perhaps through a newer API or simulating
> those clicks etc),

I poked around in the GH v3 REST API an v4 GraphQL-based API docs
and couldn't spot any methods for transferring a repo between orgs.
Given that the operation in the WebUI requires an account with
membership in both involved orgs, they may deem it beneath the value
threshold for inclusion. Also, I'd personally much rather stop
having Gerrit push replicate into GH, and hand maintenance of a
mirror there off to some other volunteers within the community who
have more of an interest in similar social media platforms.

> come up with a creative fix to git remotes (redirects, updating
> via git review or something) etc.
[...]

I've already been mulling over some ideas for useful
redirects/rewrites on our git.openstack.org service and that's not
too hard for HTTP(S) remotes to deal with, but for Git protocol
requests I don't think it's possible without significant
modification to the backend service (best I can come up with is
symlinking on the underlying filesystem, and maybe that's "good
enough").

But to circle back around to my earlier point, assuming that we're
just going to need to accept a constant flood of renames and then
try to engineer solutions to make that marginally less painful is
stretching my suspension of disbelief here. I'd rather find a way to
avoid project renames just for the sake of governance
inclusion/exclusion. We don't have any solid evidence that it will
"fix" the external confusion around OpenStack at all, but we
definitely know it will create a lot of additional work. I have a
hard time seeing justification in such a tradeoff.
-- 
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

[openstack-dev] [docs] Retiring clouddocs-maven-plugin

[Andreas Jaeger]

It's IMHO time to retire
http://git.openstack.org/cgit/openstack/clouddocs-maven-plugin/ - this
was used to build documents from XML.

We converted all documents to RST, have released the last version in
April 2015, and not merged anything since May 2016.

Current openstack-manuals got fully converted to RST with Mitaka, so we
have no current branches that need this.

Thus I propose to retire the repo and will propose patches for it. Once
those are submitted, I'll reply here with references to them,

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] realtime kvm cpu affinities

[sfinucan]

On Thu, 2017-06-29 at 12:20 -0600, Chris Friesen wrote:
> On 06/29/2017 10:59 AM, sfinu...@redhat.com wrote:
> 
> > Thus far, we've no clear conclusions on directions to go, so I've took a
> > stab
> > below. Henning, Sahid, Chris: does the above/below make sense, and is there
> > anything we need to further clarify?
> 
> The above is close enough. :)

Excellent :tentsfingers:

> > # Problem 1
> > 
> >  From the above, there are 3-4 work items:
> > 
> > - Add a 'emulator_pin_set' or 'cpu_emulator_threads_mask' configuration
> > option
> > 
> >    - If using a mask, rename 'vcpu_pin_set' to 'pin_set' (or, better,
> >  'usable_cpus')
> > 
> > - Add a 'emulator_overcommit_ratio', which will do for emulator threads  
> > what
> >    the other ratios do for vCPUs and memory
> 
> If we were going to support "emulator_overcommit_ratio", then we wouldn't 
> necessarily need an explicit mask/set as a config option. If someone wants
> to run with 'hw:emulator_thread_policy=isolate' and we're below the
> overcommit ratio then we run it, otherwise nova could try to allocate a new
> pCPU to add to the emulator_pin_set internally tracked by nova.  This would
> allow for the number of pCPUs in emulator_pin_set to vary depending on the
> number of instances with 'hw:emulator_thread_policy=isolate'on the compute
> node, which should allow for optimal packing.

So we'd now mark pCPUs not only as used, but also as used for a specific
purpose? That would probably be more flexible that using a static pool of CPUs,
particularly if instances are heterogeneous. I'd imagine it would, however, be
much tougher to do right. I need to think on this.

As an aside, what would we do about billing? Currently we include CPUs used for
emulator threads as overhead. Would this change?

> > - Deprecate 'hw:emulator_thread_policy'???
> 
> I'm not sure we need to deprecate it, it would instead signify whether the 
> emulator threads should be isolated from the vCPU threads.  If set to
> "isolate" then they would run on the emulator_pin_set identified above
> (potentially sharing them with emulator threads from other instances) rather
> than each instance getting a whole pCPU for its emulator threads.

I'm confused, I thought we weren't going to need 'emulator_pin_set'? In any
case, it's probably less about deprecating the extra spec and instead changing
how things work under the hood. We'd actually still want something to signify
"I want my emulator overhead accounted for separately".

> > # Problem 2
> > 
> > No clear conclusions yet?
> 
> I don't see any particular difficulty in supporting both RT and non-RT
> instances on the same host with one nova-compute process.  It might even be
> valid for a high-performance VM to make use 
> of 'hw:emulator_thread_policy=isolate' without enabling RT.  (Which is why
> I've been careful not to imply RT in the description above.)

Yeah, I might focus on the above problem for now, as I've no clear ideas or
suggestions on how to proceed here. Happy to work on specs if necessary,
though.

Stephen

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

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 26) - job renaming discussion

[Attila Darazs]

If the topics below interest you and you want to contribute to the 
discussion, feel free to join the next meeting:


Time: Thursdays, 14:30-15:30 UTC
Place: https://bluejeans.com/4113567798/

Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

= Renaming the CI jobs =

When we started the job transition to Quickstart, we introduced the 
concept of featuresets[1] that define a certain combination of features 
for each job.


This seemed to be a sensible solution, as it's not practical to mention 
all the individual features in the job name, and short names can be 
misleading (for example ovb-ha job does so much more than tests HA).


We decided to keep the original names for these jobs to simplify the 
transition, but the plan is to rename them to something that will help 
to reproduce the jobs locally with Quickstart.


The proposed naming scheme will be the same as the one we're now using 
for job type in project-config:


gate-tripleo-ci-centos-7-{node-config}-{featureset-config}

So for example the current "gate-tripleo-ci-centos-7-ovb-ha-oooq" job 
would look like "gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001"


The advantage of this will be that it will be easy to reproduce a gate 
job on a local virthost by typing something like:


./quickstart.sh --release tripleo-ci/master \
--nodes config/nodes/3ctlr_1comp.yml \
--config config/general_config/featureset001.yml \


Please let us know if this method sounds like a step forward.

= PTG nomination discussion =

We discussed who to nominate to attend the PTG. We decised to nominate 
John, Arx and Sagi to go to the PTG. Ronelle and I are going to apply 
for it without the nomination as well, maybe we'll have budget to meet 
there and discuss CI related topics.


= Smaller items =

* We're close to finish the transition of the "ovb-updates" promotion 
job, it might be the first one to get renamed by the method discussed above.


* The 
gate-tripleo-ci-centos-7-scenario00{1,2,3,4}-multinode-oooq-container 
jobs are now passing and voting (1 is still not in the gates, waiting 
for merge of [2])


* There were some issues found and fixed (by Sagi) on the stable branch 
promotion jobs.


* Gabriele keeps working on getting the promotion/periodic jobs hosted 
at the new RDO Cloud infrastructure, allowing us to run promotion more 
frequently.


* John keeps working on the libvirt multi-nic support, his patches are 
here[3].


Thank you for reading the summary. Have a great weekend!

Best regards,
Attila

[1] 
https://docs.openstack.org/developer/tripleo-quickstart/feature-configuration.html

[2] https://review.openstack.org/478979
[3] https://review.openstack.org/#/q/topic:libvirt-multi-nic

__
OpenStack Development Mailing 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] [horizon][trunk] forever spinning modalspinner when deleting resource from details page

[Lajos Katona]

Hi,

I am working on the neutron-trunk-ui, to make the possibility for the 
user to use trunks via web GUI.
For the patch which shows the details for the trunk 
(https://review.openstack.org/464727) I realized that
the Delete action actually seems to be hanging if I delete from the 
detail page.


Symptoms:

 * There is an error toast (and 404 in the console) that the trunk
   can't be accessed. That should be normal, as I just deleted it.
 o As I see from old django pages the way of working in these
   situations should be to suppress the 404 and the error toast,
   and go back to the list of resources table, am I right?
 * The modal spinner ("Please Wait") hangs for ever => That is the
   more serious problem.
 o I tried to check the fully working angular example which is for
   me the images panel, and actually that is working the same way:
 + Click on an image
 + On the details page click on delete and there is the forever
   spinning modal

In my latest patch I get rid of the forever spinning modal, and I should 
get rid of the error toast as well, and go back to the

list of trunks table.
BUT I have the feeling that I mess up the horizon framework.

Could somebody help me out what should be the direction to solve this 
problem in a horizon/angular way?


Thanks in advance for the help.

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

[openstack-dev] [openstack-ansible][neutron][designate][dns] dns plugin suppressed in neutron.conf.j2 template

[Lawrence J. Albinson]

Good Afternoon Colleagues,

I've been working to incorporate dynamic dns/designate updating from
neutron and nova within an OpenStack-Ansible built environment.

I note that the dns plugin is explicitly suppressed in the
openstack-ansible-os_neutron role here:

https://github.com/openstack/openstack-ansible-os_neutron/blob/master/templates/neutron.conf.j2#L5

I'm curious to know why this is.

Kind regards, Lawrence

Lawrence J Albinson

__
OpenStack Development Mailing 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] Plan description in the create/update plan form

[Jiri Tomasek]

On 29.6.2017 23:28, Ben Nemec wrote:



On 06/29/2017 07:25 AM, Ana Krivokapic wrote:

Resending with the [tripleo] tag, sorry...

On Thu, Jun 29, 2017 at 2:22 PM, Ana Krivokapic > wrote:

Hi TripleO devs,

I am working on adding a description field to the "Crate Plan" form
in the TripleO UI [1]. The goal is to make it possible for the user
to specify a plan description using a form field when creating a
plan. As the plan description lives in the plan-environment.yaml
file[2], the idea is to retrieve this value from
plan-environment.yaml when the user uploads the plan, populate the
form field with it, let the user change it, and then save it back to
the file.

I have a WIP patch up [3] which solves the issue in the case of
uploading the plan as a folder. However, I am having a hard time
solving the case of uploading the plan as a tarball. The issue is
obviously with accessing the contents of the tarball. Here are some
possible approaches that come to mind:

1) Use one of the existing third-party JS libraries that can extract
a tarball in the browser. Pros: front-end only solution, no need for
additional API calls, no need for back-end changes. Cons: adding a
new dependency, these libraries don't seem much maintained.

2) Use swift to upload and extract the tarball. Pros: no need for
back-end changes, we can just call the swift API. Cons: splitting
the tarball upload from plan creation, which should really be one
atomic operation.

3) Modify the plan create workflow to accept a plan description as a
parameter. Pros: keeps plan creation atomic. Cons: changes to the
plan create workflow interface needed. Also this way there is no way
to send back the information about the description to the UI, we
would have to just accept the value of the form field, and overwrite
whatever was in the plan-environment.yaml file.

Of course there is also a fourth option:

4) This is not worth the effort to implement and we should just drop
it. :)


So the user can update the description after the initial upload, 
right? I wouldn't have a huge problem with just saying that you don't 
get the description box pre-populated if you upload a binary format 
like tar. It's not quite as ideal, but as long as there is some way to 
set the description at some point in the process it should be fine 
until/unless we decide to pursue a more complicated solution.




My personal opinion is that the cons of 1) and 2) make these
approaches unacceptable. The cons of 3) make it kind of not worth it
- seems like a lot of work for a partial solution. So I'm leaning
towards 4) at the moment.

I'd like to hear your opinions on this, is there a another/better
approach that I'm missing? Jirka, you mentioned we could postpone
this work to the next cycle and there are improvements that we can
work on in the meantime which would make implementation of this
feature easier?

Any and all thoughts, comments, opinions are welcome.



I've taken a look into how the plan creation actually works and here are 
the outcomes:


There are 3 ways to create a plan using plan creation mistral workflow:
1. Create plan from default templates in undercloud machine
2. Create plan from Swift container
3. Create plan from git repository

TripleO UI currently only uses second option and it provides user to do 
it 2 ways:

1. Upload via directory (Chrome browser only)
2. Upload tarball

In both cases, the mistral workflow expects the Swift container to be 
created before the workflow is triggered. TripleO UI now does it as a 
single chain of API calls - call Swift API to create container and 
upload files, call Mistral to run the plan creation workflow. So in 
theory we could split this in UI into a wizard, where once the files are 
in place in swift, we could reach for plan-environment.yaml and let the 
user set the description. Once that is done user can continue with 
triggering the mistral workflow in wizard.


Problem with this is that this solution would not support options 1. and 
3. which we'd like to integrate in TripleO UI too. So alternatively, we 
can turn the Plan creation dialog into a wizard which first creates the 
plan (swift uploads if needed, run plan creation workflow) and when 
succeeds, wizards provides user to edit plan description which would 
finalize the plan creation wizard.


The same approach could be used for plan update and plan export.

I think this discussion is a nice start for Queens spec/blueprint which 
introduces additional plan creation options and description editting in 
TripleO UI.


-- Jirka



[1] https://bugs.launchpad.net/tripleo/+bug/1698818

[2] 
https://github.com/openstack/tripleo-heat-templates/blob/master/plan-environment.yaml#L4-L5

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Chandan kumar]

On Fri, Jun 30, 2017 at 3:08 PM, Thierry Carrez  wrote:
> Mike Perez wrote:
>> [...]
>> What do people think before we bikeshed on the name? Would having a
>> champion volunteer to each goal to help?
>
> It feels like most agree that having champions would help. Do we have
> any volunteer for the currently-proposed Pike goals ? As a reminder,
> those are:
>
> * Split Tempest plugins into separate repos/projects [1]

I would like to volunteer for Split Tempest plugins into separate
repos/projects .

> * Move policy and policy docs into code [2]
>
> [1]
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> [2] https://review.openstack.org/#/c/469954/
>

Thanks,

Chandan Kumar

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

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Thierry Carrez]

Mike Perez wrote:
> [...]
> What do people think before we bikeshed on the name? Would having a
> champion volunteer to each goal to help?

It feels like most agree that having champions would help. Do we have
any volunteer for the currently-proposed Pike goals ? As a reminder,
those are:

* Split Tempest plugins into separate repos/projects [1]
* Move policy and policy docs into code [2]

[1]
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] https://review.openstack.org/#/c/469954/

-- 
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-dev] [tc] Status update, Jun 30

[Thierry Carrez]

Hi!

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee


== Recently-approved changes ==

* Introduce assert:supports-api-interoperability tag [1]
* Move Fuel from official to unofficial (hosted) [2]
* Team diversity tags update [3]
* Do not use confusing "meritocracy" word in the opens [4]
* Goal completion updates from: glance
* New git repositories: neutron-fwaas-dashboard, freezer-tempest-plugin,
ptgbot, puppet-ptgbot, logstash-filters, ironic-python-agent-builder

[1] https://review.openstack.org/#/c/418010/
[2] https://review.openstack.org/#/c/475721/
[3] https://review.openstack.org/#/c/475844/
[4] https://review.openstack.org/#/c/473510/

The "assert:supports-api-interoperability" tag can be asserted for
deliverables which follow the API interoperability guidelines and that
they will not change (or remove) an API in a way that will break
existing users of an API. See details at:

https://governance.openstack.org/tc/reference/tags/assert_supports-api-interoperability.html


== Open discussions ==

The two changes around TC vision are still up for review. Please see
those at:

* Initial draft [5]
* Subsequent draft integrating feedback and editing for style [6]

[5] https://review.openstack.org/#/c/453262/
[6] https://review.openstack.org/#/c/473620/

Discussion also continues on John Garbutt's resolution on ensuring that
decisions are globally inclusive. At this stage it should probably be
turned into a guiding principle, and a chapter in the Project Team
Guide. Please see:

* Decisions should be globally inclusive [7]

[7] https://review.openstack.org/#/c/460946/

The following changes are also still in open discussion, although they
should probably have a new patchset published to take into account the
most recent feedback:

* Declare plainly the current state of PostgreSQL in OpenStack [8]
* Describe what upstream support means [9]

[8] https://review.openstack.org/427880
[9] https://review.openstack.org/440601

Finally, we also have a number of topics being brainstormed openly on
the mailing list. One is about replacing TC/UC side workgroups with
common SIGs [10], another is around finding a new leader for the
Stewardship WG [11], another about allowing teams to use their channel
for meetings [12], and the last one about dealing with the confusion
around "hosted" projects [13]. Please chime in if you have a strong
opinion one way or another:

[10]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118723.html
[11]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/119068.html
[12]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118899.html
[13]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/119043.html


== Voting in progress ==

Flavio's proposed addition to the top-5 wanted list is still missing a
couple of votes:

* Add "Glance Contributors " to top-5 wanted list [14]

[14] https://review.openstack.org/#/c/474604/


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

flaper87 to update "Drop Technical Committee meetings" with a new
revision

sdague or dirkm to post a new patchset on the database support
resolution, to address formatting issues

dims to sync with Stackube on progress and report back

We also need to find volunteers for the champion role in the proposed
(and already-approved) Pike goals. Please add your name on those if
you're willing to spearhead the effort on those.


== Need for a TC meeting next Tuesday ==

We could have used a meeting next week to discuss the next steps in the
vision if there were enough people interested in that. With July 4th
it's however unlikely that our usual meeting datetime would work for
that. I suggest we discuss it during the office hours or asynchronously
on the #openstack-tc channel instead.


Cheers!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [OpenStack][Cinder][backup]Get total files/objects disk size of backup

[Gorka Eguileor]

On 30/06, int32bit wrote:
> Currently the size in backup is src volume size rather than backup
> file/object size, it's used to record original volume size that avoid
> damaging target in restore operation if the volume has been resized.
>
> But it may be more useful for end user to tell them backup files/objects
> size(object count really make no sense for user). It's also useful for
> cloud provider to compute their bill.
>
> I think It's not very hard to implement it if we use or extend
> `chunkeddriver`.  Firstly we need add `get_backup_size` new interface in
> driver API and let's update backup size in `_finalize_backup`. The backend
> driver should implement this interface if possible. If the backend driver
> is not possible to implement like `CephBackupDriver`, we raise
> NotImplementedError. And then we need add a new field(named volume_size) in
> backup object as well as db model associated to backup, and store
> files/objects size in original size field. At last, we add this new
> field volume_size to backup ViewBuilder in API.

Hi,

I think this is a good idea, just a couple of comments.

We should not change the meaning of the size field in the backup model,
size should remain the original volume's size, and the new field should
refer to the allocated/consumed size.

Besides adding the size of the hash table to the size of the chunks when
calculating the consumed size of the backups, maybe we should also
include a mechanism for drivers to account for the overhead of having
additional objects.

Last I would like to thank you for being thorough and considering the
Ceph backup driver case as well, although it won't need to be an
exception, as it could also report the real size of the backup with one
of these 2 mechanisms:

- Piping the output from export-diff and processing the metadata in
  there to calculate the size.

- Once the backup has completed using the diff command to get the list
  of byte extents and calculate the real size of the image from the
  parent backup.

Cheers,
Gorka.

__
OpenStack Development Mailing 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] [watcher] Nominate Yumeng Bao to the core team

[Hidekazu Nakamura]

+1

> -Original Message-
> From: Чадин Александр (Alexander Chadin)
> [mailto:a.cha...@servionica.ru]
> Sent: Tuesday, June 27, 2017 10:44 PM
> To: OpenStack Development Mailing List
> 
> Subject: [openstack-dev] [watcher] Nominate Yumeng Bao to the core team
> 
> Hi watcher folks,
> 
> I’d like to nominate Yumeng Bao to the core team. She has made a lot of
> contributions including specifications,
> features and bug fixes. Yumeng has attended PTG and Summit with her
> presentation related to the Watcher.
> Yumeng is active on IRC channels and take a part on weekly meetings as well.
> 
> Please, vote with +1/-1.
> 
> Best Regards,
> _
> Alexander Chadin
> OpenStack Developer

__
OpenStack Development Mailing 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][tc] How to deal with confusion around "hosted projects"

[Thierry Carrez]

Fox, Kevin M wrote:
> [...]
> So whats really unclear to end users is that when they talk about a piece of 
> "openstack" they may be talking about a great many things:
> 1. is it managed under the 4 opens
> 2. is it in github.com/openstack.
> 3. is it under openstack governance.
> 4. is it an 'openstack project' (what does this mean anymore. I thought that 
> was #3, but maybe not?)
> 5. is "openstack" part of its title
> 
> Is a project part of openstack if it meets one of those? all of them? or some 
> subset? If we can't answer it, I'm not sure users will ever understand it.

We can totally answer it. The "official" answer is (3) (synonymous to
(4)). The trick is, the project list on our governance website is a
*lot* less visible than (2) or (5), so it's very easy to appear as an
openstack project while not being one. Which is precisely the confusion
I'd like us to clear out one way or another.

My initial suggestion (on the other thread) was to give some brand name
to things that are hosted/companion/friends/neighbors/stackforge, so
that we can more easily apply that mark and incrementally reduce the
confusion.

The thread went on discussing other corrective measures at the edge
(like turning github.org/openstack into more curated content, and/or
removing the openstack/ prefix from all of our repositories). All good
suggestions.

This thread introduced yet another possibility: no longer accept hosting
for projects outside of openstack governance. This clarifies things a
lot, but presents challenges of its own, as that space was pretty
convenient to bootstrap projects or host companion projects, as well as
build a community.

-- 
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-dev] [release] Release countdown for week R-8 and R-7, June 30 - July 14

[Thierry Carrez]

Welcome to our regular release countdown email!

Development Focus
-

Teams should be wrapping up library work in preparation for release
deadlines, starting R-6 week.


General Information
---

A number of libraries and projects following the cycle-with-intermediary
model still haven't released anything in Pike. We recommend that you
produce at least one release before the corresponding deadline (Jul 13
for non-client libs, Jul 20 for client libs, Aug 10 for other
deliverables), so that the release team has something to fall back to
when release branches need to be cut. If no Pike release was produced by
the deadline, the release team will have to trigger a release at the
current master HEAD, which is almost certainly not what you want. The
following deliverables are still concerned:

Jul 13: glance-store, instack, requestsexceptions

Jul 20: python-designateclient, python-searchlightclient, python-swiftclient

Aug 10: aodh, bifrost, ceilometer, cloudkitty[-dashboard], magnum[-ui],
murano-agent, networking-hyperv, panko, senlin-dashboard, tacker


Actions
---

If your team has a contributor whose work is not reflected in commit
authorship (or only appear as "Co-Authored-By" in commit messages), they
won't get the right to vote for upcoming elections, unless you
explicitly add them to the "extra-atc" list for your project. Please
review your contributors and submit patches to the openstack/governance
repository (reference/projects.yaml file) accordingly. The deadline for
submitting those requests is July 13 !

For projects following the cycle-with-milestones release model,
pre-release branches will be cut at RC1, and only members of the
$PROJECT-release group in Gerrit will be able to approve backports for
further RCs. In preparation for that release phase, you should review
who is in that group and adjust it accordingly.

Projects (especially those following stable policy) should also review
their stable branches and trigger stable point releases as necessary to
ship the backports that have landed on those branches, if any.


Upcoming Deadlines & Dates
--

Extra-ATC addition deadline: July 13
Non-client libraries final releases: July 20
Client libraries final releases: July 27
Pike-3 milestone (and Feature freeze): July 27
Final Pike release: August 30
Queens PTG in Denver: Sept 11-15

-- 
Thierry Carrez (ttx)


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

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

[Yaguang Tang]

 Thanks Along and Gordon , after making changes , it works.

On Fri, Jun 30, 2017 at 12:02 AM, Along Meng  wrote:

> Yes， and you need make sure ceilometer-agent-notification and panko was
> intalled in a same machine in your environment.
> Because ceilometer will load the publisher dispatcher panko from the
> module panko and use the database url[1] which configured in panko.conf to
> init the database connection.
>
> [1]
> https://github.com/openstack/panko/blob/stable/ocata/panko/
> dispatcher/database.py#L43
>
> MengAlong
>
>
> On Thu, Jun 29, 2017 at 8:56 PM, gordon chung  wrote:
>
>>
>>
>> On 29/06/17 07:24 AM, Yaguang Tang wrote:
>> > sinks:
>> > - name: event_sink
>> >   transformers:
>> >   triggers:
>> >   publishers:
>> >   - direct://
>> >   - panko://
>>
>> the publisher path is only available if you have Pike Panko. you need to
>> either backport[1] or configure your publisher as:
>>
>> direct://?dispatcher=panko
>>
>>
>> [1]
>> https://github.com/openstack/panko/commit/d785015552937455d7
>> 6f083d313a73a7c0c076b3
>>
>> cheers,
>> --
>> gord
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Tang Yaguang
__
OpenStack Development Mailing 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] [infra][nova] Corrupt nova-specs repo

[Ian Wienand]

Hi,

Unfortunately it seems the nova-specs repo has undergone some
corruption, currently manifesting itself in an inability to be pushed
to github for replication.

Upon examination, it seems there's a problem with a symlink and
probably jgit messing things up making duplicate files.  I have filed
a gerrit bug at [1] (although it's probably jgit, but it's just a
start).

Anyway, that leaves us the problem of cleaning up the repo into a
pushable state.  Here's my suggestion after some investigation:

The following are corrupt

---
$ git fsck
Checking object directories: 100% (256/256), done.
error in tree a494151b3c661dd9b6edc7b31764a2e2995bd60c: contains duplicate file 
entries
error in tree 26057d370ac90bc01c1cfa56be8bd381618e2b3e: contains duplicate file 
entries
error in tree 57423f5165f0f1f939e2ce141659234cbb5dbd4e: contains duplicate file 
entries
error in tree 05fd99ef56cd24c403424ac8d8183fea33399970: contains duplicate file 
entries
---

After some detective work [2], I related all these bad objects to the
refs that hold them.  It look as follows

---
fsck-bad: a494151b3c661dd9b6edc7b31764a2e2995bd60c
 -> 5fa34732b45f4afff3950253c74d7df11b0a4a36 refs/changes/26/463526/9

fsck-bad: 26057d370ac90bc01c1cfa56be8bd381618e2b3e
 -> 47128a23c2aad12761aa0df5742206806c1dfbb8 refs/changes/26/463526/8
 -> 7cf8302eb30b722a00b4d7e08b49e9b1cd5aacf4 refs/changes/26/463526/7
 -> 818dc055b971cd2b78260fd17d0b90652fb276fb refs/changes/26/463526/6

fsck-bad: 57423f5165f0f1f939e2ce141659234cbb5dbd4e

 -> 25bd72248682b584fb88cc01061e60a5a620463f refs/changes/26/463526/3
 -> c7e385eaa4f45b92e9e51dd2c49e799ab182ac2c refs/changes/26/463526/4
 -> 4b8870bbeda2320564d1a66580ba6e44fbd9a4a2 refs/changes/26/463526/5

fsck-bad: 05fd99ef56cd24c403424ac8d8183fea33399970
 -> e8161966418dc820a4499460b664d87864c4ce24 refs/changes/26/463526/2
---

So you may notice this is refs/changes/26/463526/[2-9]

Just deleting these refs and expiring the objects might be the easiest
way to go here, and seems to get things purged and fix up fsck

---
$ for i in `seq 2 9`; do
>  git update-ref -d refs/changes/26/463526/$i
> done

$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
Counting objects: 44756, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (43850/43850), done.
Writing objects: 100% (44756/44756), done.
Total 44756 (delta 31885), reused 12846 (delta 0)

$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (44756/44756), done.
---

I'm thinking if we then force push that to github, we're pretty much
OK ... a few intermediate reviews will be gone but I don't think
they're important in this context.

I had a quick play with "git ls-tree", edit the file, "git mktree",
"git replace" and then trying to use filter-branch, but couldn't get
it to work.  Suggestions welcome; you can play with the repo from [1]
I would say.

Thanks,

-i

[1] https://bugs.chromium.org/p/gerrit/issues/detail?id=6622
[2] "git log --all --format=raw --raw -t --no-abbrev" and search for
the change sha, then find it in "git show-refs"

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

[openstack-dev] [OpenStack][Cinder][backup]Get total files/objects disk size of backup

[int32bit]

Currently the size in backup is src volume size rather than backup
file/object size, it's used to record original volume size that avoid
damaging target in restore operation if the volume has been resized.

But it may be more useful for end user to tell them backup files/objects
size(object count really make no sense for user). It's also useful for
cloud provider to compute their bill.

I think It's not very hard to implement it if we use or extend
`chunkeddriver`.  Firstly we need add `get_backup_size` new interface in
driver API and let's update backup size in `_finalize_backup`. The backend
driver should implement this interface if possible. If the backend driver
is not possible to implement like `CephBackupDriver`, we raise
NotImplementedError. And then we need add a new field(named volume_size) in
backup object as well as db model associated to backup, and store
files/objects size in original size field. At last, we add this new field
volume_size to backup ViewBuilder in API.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev