From gmann at ghanshyammann.com  Mon Apr  1 01:54:12 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Sun, 31 Mar 2019 20:54:12 -0500
Subject: [nova] "future" specs and blueprints
In-Reply-To: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
Message-ID: <169d69aa3a1.1154d6bf526152.5215579436310684500@ghanshyammann.com>

 ---- On Wed, 27 Mar 2019 14:45:02 -0500 Eric Fried <openstack at fried.cc> wrote ----
 > All- 
 >  
 > It seems like we don't have a great way of looking at a blueprint and 
 > saying, "this looks like a good idea, and yes we want to do it, but 
 > we're not going to be able to prioritize it for this release." Sometimes 
 > we just leave those blueprints "unspecified" and their specs stay open 
 > in limbo. And some blueprints we'll approve for the current series, and 
 > merge the spec under $current_cycle/approved, but not really intend to 
 > get the work completed. And at the end of the release, those pieces 
 > muddy our completion stats. It would be nice if those stats reflected 
 > only work we got done that we *intended* to get done. 
 >  
 > I'm not bringing this up just for the sake of making numbers pretty; it 
 > would just be nice to have a crisp picture of the work slated for the 
 > current release. And also a way for contributors to propose specs they 
 > *don't* intend for the current series, but still want to start 
 > discussing (I happen to know of at least one example of this for Train). 
 > And also a way to keep track of work we know we want to do eventually, 
 > just not now. 
 >  
 > === TL;DR >>> 
 > So I'd like to propose that we set up a "future" series in Launchpad, 
 > and a corresponding subdirectory in the specs repo. 
 > === TL;DR <<< 
 >  
 > The process would be pretty much as you would expect, including (but not 
 > limited to): 
 >  
 > - If we decide (e.g. at the PTG) that we like a spec that's proposed 
 > under $current/approved, but won't have time for it in the current 
 > series, we'll ask the author to move it to future/ and make sure the 
 > History section includes "$current: proposed and approved for 'future'". 
 > - If we decide in mid-release that we want to defer a blueprint, we can 
 > propose a patch to move it from $current/approved to future/ (including 
 > a redirect). 

Thanks for bringing this up.

What will be the conditions or criteria of the above two scenarios? 
- Review bandwidth?
- Author (contributors) wish not to complete the code in the cycle when he/she
is proposing the spec for? I mean do we have any scenario where spec author
says "please approve my spec in this cycle but I will not start the code in this cycle
so consider this a future spec"
- Technical scope etc ?
- Anything else ?

IMO, the first two scenarios should not be the reason to ask people to propose
your spec in future/ dir.  For other scenarios,  we should clearly say "NO: as of
now due to xyz reason so rejected or suggestion for repropose" etc.

future/ dir idea is good but main challenge it can face is "how many people going
to review the future/ items' because I feel everyone is so busy with their current
assignments.

 > - If a contributor wants to start work on a spec for a future release, 
 > they can propose it directly to the future/ path. 

+1, this is a nice idea to start the early discussion/feedback etc.

-gmann

 > - Every cycle when setting goals we can skim through the 'future' items 
 > to see if any should be pulled in. In which case we propose a patch to 
 > move the file from future/ to $current/approved (including a redirect) 
 > which we can fast-approve. 
 > - If we decide to flush a spec from 'future', we can move it to a 
 > 'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this 
 > part of the process out later. 
 >  
 > How do folks feel about this idea? 
 >  
 > -efried 
 > . 
 >  
 > 



From mnaser at vexxhost.com  Mon Apr  1 02:21:22 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Sun, 31 Mar 2019 22:21:22 -0400
Subject: [nova] super long online_data_migrations
Message-ID: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>

Hi there,

During upgrades, I've noticed that when running online_data_migrations
with "infinite-until-done" mode, it loops over all of the migrations
one by one.

However, one of the online data migrations
(instance_obj.populate_missing_availability_zones) makes a query that
takes a really long time as it seems inefficient (which eventually
results in 0, cause it already ran), which means as it loops in
"blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
environments.

The question ends up in specific:

SELECT count(*) AS count_1
FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
instance_extra.updated_at AS instance_extra_updated_at,
instance_extra.deleted_at AS instance_extra_deleted_at,
instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
instance_extra_id, instance_extra.instance_uuid AS
instance_extra_instance_uuid
FROM instance_extra
WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1

The explain for the DB query in this example:

+------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
| id   | select_type | table          | type | possible_keys | key  |
key_len | ref  | rows   | Extra       |
+------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
|    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
NULL    | NULL | 382473 | Using where |
+------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+

It's possible that it can be ever worse, as this number is from
another very-long running environments.

+------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
| id   | select_type | table          | type | possible_keys | key  |
key_len | ref  | rows    | Extra       |
+------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
|    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
NULL    | NULL | 3008741 | Using where |
+------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+

I'm not the SQL expert, could we not optimize this?  Alternatively,
could we update the online data migrations code to "pop out" any of
the migrations that return 0 for the next iteration, that way it only
works on those online_data_migrations that *have* to be done, and
ignore those it knows are done?

Thanks,
Mohammed

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From mnaser at vexxhost.com  Mon Apr  1 02:26:47 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Sun, 31 Mar 2019 22:26:47 -0400
Subject: [nova] super long online_data_migrations
In-Reply-To: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
Message-ID: <CAEs876gcpL3nesdzGhnqntubOLh105FfTNFtjMQ=Zz2O3Tm96g@mail.gmail.com>

On Sun, Mar 31, 2019 at 10:21 PM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> Hi there,
>
> During upgrades, I've noticed that when running online_data_migrations
> with "infinite-until-done" mode, it loops over all of the migrations
> one by one.
>
> However, one of the online data migrations
> (instance_obj.populate_missing_availability_zones) makes a query that
> takes a really long time as it seems inefficient (which eventually
> results in 0, cause it already ran), which means as it loops in
> "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
> environments.
>
> The question ends up in specific:
>
> SELECT count(*) AS count_1
> FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
> instance_extra.updated_at AS instance_extra_updated_at,
> instance_extra.deleted_at AS instance_extra_deleted_at,
> instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
> instance_extra_id, instance_extra.instance_uuid AS
> instance_extra_instance_uuid
> FROM instance_extra
> WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1
>
> The explain for the DB query in this example:
>
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows   | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 382473 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
>
> It's possible that it can be ever worse, as this number is from
> another very-long running environments.
>
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows    | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 3008741 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
>
> I'm not the SQL expert, could we not optimize this?  Alternatively,
> could we update the online data migrations code to "pop out" any of
> the migrations that return 0 for the next iteration, that way it only
> works on those online_data_migrations that *have* to be done, and
> ignore those it knows are done?

and while we're at it, can we just bump the default rows-per-run to
something more than
50 rows? it seems super .. small :)

> Thanks,
> Mohammed
>
> --
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From me at not.mn  Mon Apr  1 02:38:40 2019
From: me at not.mn (John Dickinson)
Date: Sun, 31 Mar 2019 19:38:40 -0700
Subject: [nova] "future" specs and blueprints
In-Reply-To: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
Message-ID: <594FD6B1-F46C-4B85-B7D0-4CB55D85BF8B@not.mn>

Apologies for top-posting, etc etc

I'd like to mention something the Swift team introduced back in 2016 and has been using quite successfully ever since. After trying both blueprints and specs, we have settled on our ideas wiki page. Basically, if you've got an idea, write it down and link to it. I'll let the original email do more of the explaining: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094026.html

Swift's ideas page is at https://wiki.openstack.org/wiki/Swift/ideas


--John





On 27 Mar 2019, at 12:45, Eric Fried wrote:

> All-
>
> It seems like we don't have a great way of looking at a blueprint and
> saying, "this looks like a good idea, and yes we want to do it, but
> we're not going to be able to prioritize it for this release." Sometimes
> we just leave those blueprints "unspecified" and their specs stay open
> in limbo. And some blueprints we'll approve for the current series, and
> merge the spec under $current_cycle/approved, but not really intend to
> get the work completed. And at the end of the release, those pieces
> muddy our completion stats. It would be nice if those stats reflected
> only work we got done that we *intended* to get done.
>
> I'm not bringing this up just for the sake of making numbers pretty; it
> would just be nice to have a crisp picture of the work slated for the
> current release. And also a way for contributors to propose specs they
> *don't* intend for the current series, but still want to start
> discussing (I happen to know of at least one example of this for Train).
> And also a way to keep track of work we know we want to do eventually,
> just not now.
>
> === TL;DR >>>
> So I'd like to propose that we set up a "future" series in Launchpad,
> and a corresponding subdirectory in the specs repo.
> === TL;DR <<<
>
> The process would be pretty much as you would expect, including (but not
> limited to):
>
> - If we decide (e.g. at the PTG) that we like a spec that's proposed
> under $current/approved, but won't have time for it in the current
> series, we'll ask the author to move it to future/ and make sure the
> History section includes "$current: proposed and approved for 'future'".
> - If we decide in mid-release that we want to defer a blueprint, we can
> propose a patch to move it from $current/approved to future/ (including
> a redirect).
> - If a contributor wants to start work on a spec for a future release,
> they can propose it directly to the future/ path.
> - Every cycle when setting goals we can skim through the 'future' items
> to see if any should be pulled in. In which case we propose a patch to
> move the file from future/ to $current/approved (including a redirect)
> which we can fast-approve.
> - If we decide to flush a spec from 'future', we can move it to a
> 'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this
> part of the process out later.
>
> How do folks feel about this idea?
>
> -efried
> .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 850 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190331/74450273/attachment.sig>

From anlin.kong at gmail.com  Mon Apr  1 03:24:33 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Mon, 1 Apr 2019 16:24:33 +1300
Subject: [trove] Trove for Train
Message-ID: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>

Hi,

I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev cycle.
Since the master branch is open for contribution and review, for those who
care about Trove, here are several things I'd like to bring to your
attention and most importantly, need your feedback.

- Deprecate nova-network.

  As I mentioned in the candidacy, The nova-network related code is spread
in the repo, which makes it very difficult for new feature implementation
and bugfix. Considering nova-network was deprecated in the OpenStack Newton
release, I propose we also deprecate nova-network support in Trove and
remove after several cycles according to the deprecation policy of the
community. I'm not sure if there is still anyone using nova-network for
Trove, especially in production.  If yes, please reply to this email.

- Create service VM in admin project by default

  Currently, Trove has configuration support to create the db instance in
the admin project, which I think should be the default deployment model to
reduce the security risk given all the db instances are communicating with
RabbitMQ in the control plane.

- Remove SecurityGroup API extension

  TBH, I don't know when and why that extension was added in Trove but
since it's not included in Trove API document(
https://developer.openstack.org/api-ref/database/), I assume there is on
one relies on that in production, so should be safe to remove.

- Remove SecurityGroup related database model

  I don't have the history development background in my mind, but IMHO, i
don't think it's reasonable for Trove to maintain such information in db.

- Security group management enhancement

  Removing the API extension and database model doesn't mean Trove
shouldn't support security group for the db instance, on the contrary,
security should always be the first thing we consider for new features. The
two tasks above are actually prerequisites for this one. In order to make
it easy to maintain and as more secure as possible, Trove is not going to
allow the end user to manipulate the security group associated with db
instance. Trove will try to provide as more information as possible to make
the debugging and performance tuning easy.

- Monitoring capability

  Currently, there is no monitoring capability support in Trove, and I
think that's the only main part missing for Trove to be running in
production. I don't have a full picture in mind now but will try to figure
out how to achieve that.

- Priorities of the previous dev cycles

  Of course, I shouldn't put the previous dev cycle priorities away from
the track, e.g. the Stein dev cycle priorities are well documented here
https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking

As Trove project has been experiencing some up and downs in the past, but
it's still very useful in some deployment use cases and has some advantages
over the container deployment model. As you could guess, the reason I
raised my hand to lead Trove is that we(Catalyst Cloud) have been deploying
Trove in production, so all those things are aiming at making Trove
production ready, not only for private cloud but also for the public.

If you have any concerns related to what's mentioned above, please don't
hesitate to reply. Alternately, I'm always in the #openstack-trove IRC
channel and could answer any questions during the working hours of UTC+12.

I really appreciate any feedback from the community.

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/3b3be934/attachment-0001.html>

From gouthampravi at gmail.com  Mon Apr  1 04:15:51 2019
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Sun, 31 Mar 2019 21:15:51 -0700
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190330204021.leizflkinun32bwy@barron.net>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <CAKSuTPZceozexAtuJtuKH=z4SUkK00n37H_=oniJ1wpWh+18Og@mail.gmail.com>
 <20190330204021.leizflkinun32bwy@barron.net>
Message-ID: <CAKSuTPYLgMTAaVjeD7bvRyoOuuY4hAqbqFg7LjQ6qSS+iXptWw@mail.gmail.com>

On Sat, Mar 30, 2019 at 1:40 PM Tom Barron <tpb at dyncloud.net> wrote:
>
> On 27/03/19 11:26 -0700, Goutham Pacha Ravi wrote:
> >On Wed, Mar 27, 2019 at 5:58 AM Tom Barron <tpb at dyncloud.net> wrote:
> >>
> >> In manila we recently merged backports of a change [1] that aims
> >> to fix up faulty configuration option deprecations in the
> >> Dell-EMC VMAX driver.  The question at hand is whether (a) we
> >> should revert these backports on the grounds that the
> >> deprecations were faulty and therefore are only effective from
> >> Stein forwards, or whether (b) the deprecations actually worked
> >> and took effect back when Ocata was the development branch but
> >> had faults that should be corrected all the way back to Pike
> >> before it goes EM.
> >>
> >> I think (b) is the correct answer but let's check.
> >>
> >> On Jan 10 2017 a review [2] merged that deprecated generic
> >> Dell-EMC driver options in favor of model-specific options [2].
> >> There were two models at the time, Unity and VNX.  This change
> >> was in itself unproblematic.
> >>
> >> On Jan 24 2017 a review [3] merged that introduced a third
> >> Dell-EMC model, VMAX.  This new code introduced VMAX specific
> >> options, consistent with the deprecation of the generic Dell-EMC
> >> options.  However it had two problems which review [1] corrects.
> >> When it defined the new VMAX-specific options it failed to
> >> indicate the corresponding old generic options via
> >> 'deprecated_name' [4].  Worse, the code that consumed the options
> >> actually looked for the old generic 'emc_interface_ports' option
> >> instead of the new 'vmax_ethernet_ports' option.  The only way to
> >> set a value for this option was to use its deprecated
> >> form.
> >>
> >> The change that we backported fixes both of these problems.
> >>
> >> I think it is a valid stable backport.
> >
> >
> >I don't agree with some parts of the change. However, I didn't review
> >this patch in time, so my opinion is late, and possibly annoying now.
> >A couple of things with this change are weird, and we could decide to
> >fix these:
> >
> >1) The EMC VMAX driver never had "emc_nas_server_container" or
> >"emc_nas_pool_names" as config options, but the bug fix [1], adds
> >these as deprecated names for valid options (vmax_server_container,
> >vmax_share_data_pools), in a retrospective manner.
>
> True, they are added as synonyms for the corresponing model-specific
> options, and are marked as deprecated.  This aligns the VMAX config
> with the other EMC models.
>
> >2) The EMC VMAX driver always used "emc_interface_ports", however,
> >there was no such configuration option wrt that backend. How would
> >users know to set it? Things passed because there was a "safe_get"
> >operation, and perhaps the vendor had called this out in their docs?
> >It's good they fixed this part in Stein.
>
> There is no question that the VMAX driver code was broken.
>
> >
> >
> >> If people set this "ports" option using the deprecated option it
> >> will still work.  The deprecated option has not been removed yet
> >> and will never be removed from any of the stable branches.
> >>
> >> If they tried to set it via the proper option then they would have
> >> had a functional problem, a bug, which this change now fixes.
> >
> >Agree with this point.
> >
> >> If on the other hand we say we cannot backport this then until
> >> stable/stein there will be no way for VMAX users of earlier stable
> >> branches to set this option except by magic -- by using an old
> >> deprecated form of the option that without the backported fix is not
> >> even visible in the customer-facing configuration for VMAX.
> >> All this said, I could well be missing something so I welcome
> >> analysis by stable/core folks.  The backports in question have not
> >> yet been released so it would not be a problem to revert them.
> >
> >I think it would be worth back porting the deprecation and association
> >between "emc_interface_ports" and "vmax_ethernet_ports" in the
> >interest of customers/users. However, I think [1] introduces another
> >bug by exposing net new options for this driver
> >("emc_nas_server_container" and "emc_nas_pool_names") as deprecated
> >forms of existing options ("vmax_server_container",
> >"vmax_share_data_pools"), and that is concerning.
> >
>
> What is the new bug that this change introduces?  Won't the net new
> options work and isn't the configuration backwards compatible in the
> sense that there are no options that used to work that will not work
> now?

The bug is introducing deprecated forms of the options, and back
porting that to older releases. Perhaps there's some business/customer
understanding reasoning I don't know of. It can be termed harmless,
because the original and legitimate options will continue to work.

>
> >> Thanks!
> >>
> >> -- Tom Barron
> >>
> >> [1] https://review.openstack.org/#/c/608725/
> >>
> >> [2] https://review.openstack.org/#/c/415079/
> >>
> >> [3] https://review.openstack.org/#/c/404859/
> >>
> >> [4] If this was the only issue then arguably it wasn't an error
> >> since the VMAX driver never operated with the old options.
> >>


From skaplons at redhat.com  Mon Apr  1 06:29:40 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 1 Apr 2019 08:29:40 +0200
Subject: [neutron] CI broken
Message-ID: <A1F14623-7C4E-4F98-BB0B-C3A51280874A@redhat.com>

Hi,

Just FYI, since few days we have broken neutron-tempest-plugin-designate-scenario job and it is failing 100% times. Bug is reported in [1].
If this job failed on Your patch, please don’t recheck as it will not solve the problem.

[1] https://bugs.launchpad.net/neutron/+bug/1822453

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From witold.bedyk at suse.com  Mon Apr  1 07:52:24 2019
From: witold.bedyk at suse.com (Witek Bedyk)
Date: Mon, 1 Apr 2019 09:52:24 +0200
Subject: [monasca][ptg] PTG Planning
In-Reply-To: <63b7c34a-1538-7597-6f3d-ac8073ef9366@suse.com>
References: <63b7c34a-1538-7597-6f3d-ac8073ef9366@suse.com>
Message-ID: <cfd25a2f-2c3e-22ee-3599-94d49f17b283@suse.com>

Good morning,

The correct URL is of course:

https://etherpad.openstack.org/p/monasca-ptg-train

Cheers
Witek


On 3/26/19 11:58 AM, Witek Bedyk wrote:
> Hello everyone,
> 
> the schedule for the next PTG in Denver has been published [1]. We have 
> a room reserved from Thursday afternoon until Saturday. I have started 
> an etherpad to collect topics for the discussion:
> 
> https://etherpad.openstack.org/p/monasca-ptg-stein
> 
> Please add your name and the times when you can attend (both F2F and 
> remotely). Please also put the topics you would like to discuss or 
> features you think we should add in the next release cycle.
> 
> Thanks for your input and I'm looking forward to see/hear you there.
> Witek
> 
> [1] https://www.openstack.org/ptg#tab_schedule
> 
> 


From frickler at offenerstapel.de  Mon Apr  1 08:43:50 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Mon, 01 Apr 2019 08:43:50 +0000
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
Message-ID: <1554108230.4997.13.camel@offenerstapel.de>

On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
> Hi,
> 
> During the summit in Tokyo (if I remember well), Sean Dague lead a
> discussion about removing the need for having 3 endpoints per
> service. I
> was very excited about the proposal, and it's IMO a shame it hasn't
> been
> implemented. Everyone in the room agreed. Here the content of the
> discussion as I remember it:
> 
> <discussion in Tokyo>
> 1/ The only service that needed the admin endpoint was Keystone. This
> requirement is now gone. So we could get rid of the admin endpoint
> all
> together.
> 
> 2/ The need for an interal vs public endpoint was only needed for
> accounting (of for example bandwidth when uploading to Glance), but
> this
> could be work-around by operators by using intelligent routing. So we
> wouldn't need the internal endpoint.
> 
> This makes us only need the public endpoint, and that's it.
> 
> Then, there are these %(tenant_id)s bits in the endpoints which are
> also
> very much annoying, and could be removed if the clients were smarter.
> These are still needed, apparently, for:
> - cinder
> - swift
> - heat
> </discussion in Tokyo>
> 
> Is anyone planning to implement (at least some parts of) the above?

For me as an operator, the distinction between internal and public
endpoints is helpful, as it allows to easily set up extended filtering
or rate limiting for public services without affecting internal API
calls, which in most deployments cause the majority of requests.

I'm not sure what "intelligent routing" is meant to be, but it sounds
more complicated and unstable than the current solution.

Big +1 on dropping the admin endpoint though, now that keystone doesn't
need it anymore.

Jens


From noonedeadpunk at ya.ru  Mon Apr  1 09:25:43 2019
From: noonedeadpunk at ya.ru (=?utf-8?B?0KDQsNCx0L7RgtGP0LPQvtCyINCU0LzQuNGC0YDQuNC5?=)
Date: Mon, 01 Apr 2019 12:25:43 +0300
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <1554108230.4997.13.camel@offenerstapel.de>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
Message-ID: <23799501554110743@sas2-7b909973f402.qloud-c.yandex.net>

+1 to Jens point. Internal endpoints seems to be pretty useful for me as well, as you may set internal networks to completely another physical interface (like internal infiniband connections), while leave public endpoints rate limited, and it's pretty easy to configure and maintain. And I guess it might be the case for a pretty big amount of public clouds.

01.04.2019, 11:48, "Jens Harbott" <frickler at offenerstapel.de>:
> On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
>>  Hi,
>>
>>  During the summit in Tokyo (if I remember well), Sean Dague lead a
>>  discussion about removing the need for having 3 endpoints per
>>  service. I
>>  was very excited about the proposal, and it's IMO a shame it hasn't
>>  been
>>  implemented. Everyone in the room agreed. Here the content of the
>>  discussion as I remember it:
>>
>>  <discussion in Tokyo>
>>  1/ The only service that needed the admin endpoint was Keystone. This
>>  requirement is now gone. So we could get rid of the admin endpoint
>>  all
>>  together.
>>
>>  2/ The need for an interal vs public endpoint was only needed for
>>  accounting (of for example bandwidth when uploading to Glance), but
>>  this
>>  could be work-around by operators by using intelligent routing. So we
>>  wouldn't need the internal endpoint.
>>
>>  This makes us only need the public endpoint, and that's it.
>>
>>  Then, there are these %(tenant_id)s bits in the endpoints which are
>>  also
>>  very much annoying, and could be removed if the clients were smarter.
>>  These are still needed, apparently, for:
>>  - cinder
>>  - swift
>>  - heat
>>  </discussion in Tokyo>
>>
>>  Is anyone planning to implement (at least some parts of) the above?
>
> For me as an operator, the distinction between internal and public
> endpoints is helpful, as it allows to easily set up extended filtering
> or rate limiting for public services without affecting internal API
> calls, which in most deployments cause the majority of requests.
>
> I'm not sure what "intelligent routing" is meant to be, but it sounds
> more complicated and unstable than the current solution.
>
> Big +1 on dropping the admin endpoint though, now that keystone doesn't
> need it anymore.
>
> Jens

-- 
Kind Regards,
Dmitriy Rabotyagov



From surya.seetharaman9 at gmail.com  Mon Apr  1 09:30:27 2019
From: surya.seetharaman9 at gmail.com (Surya Seetharaman)
Date: Mon, 1 Apr 2019 11:30:27 +0200
Subject: [nova] super long online_data_migrations
In-Reply-To: <CAEs876gcpL3nesdzGhnqntubOLh105FfTNFtjMQ=Zz2O3Tm96g@mail.gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
 <CAEs876gcpL3nesdzGhnqntubOLh105FfTNFtjMQ=Zz2O3Tm96g@mail.gmail.com>
Message-ID: <CAB+ArpZPqOCK1GiVeGmdN55d=pwWT+Vui-yUsOWJneUM_zPygg@mail.gmail.com>

Hi Mohammed,

On Mon, Apr 1, 2019 at 4:29 AM Mohammed Naser <mnaser at vexxhost.com> wrote:

> On Sun, Mar 31, 2019 at 10:21 PM Mohammed Naser <mnaser at vexxhost.com>
> wrote:
> >
> > Hi there,
> >
> > During upgrades, I've noticed that when running online_data_migrations
> > with "infinite-until-done" mode, it loops over all of the migrations
> > one by one.
> >
> > However, one of the online data migrations
> > (instance_obj.populate_missing_availability_zones) makes a query that
> > takes a really long time as it seems inefficient (which eventually
> > results in 0, cause it already ran), which means as it loops in
> > "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
> > environments.
>

Hmm, all we do in that migration is try to get instance records whose
availability_zone is None [1] and if no records are found we just return
all done. While I agree that once a migration is done, the next time we
loop through all the migrations we again do the query at least once to
ensure we get back zero records for most of the migrations (we don't always
use persistent markers to see if the migration was completed in the
previous run) which means we do run through the whole table.



> >
> > The question ends up in specific:
> >
> > SELECT count(*) AS count_1
> > FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
> > instance_extra.updated_at AS instance_extra_updated_at,
> > instance_extra.deleted_at AS instance_extra_deleted_at,
> > instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
> > instance_extra_id, instance_extra.instance_uuid AS
> > instance_extra_instance_uuid
> > FROM instance_extra
> > WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS
> anon_1
> >
>

This is the keypair_obj.migrate_keypairs_to_api_db migration that was added
in Newton.
Since we are just counting, we need not pull the whole record I guess (not
sure how much improvement that would cause),  I am myself not an SQL
expert, maybe jaypipes can help here.


> The explain for the DB query in this example:
> >
> >
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> > | id   | select_type | table          | type | possible_keys | key  |
> > key_len | ref  | rows   | Extra       |
> >
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> > |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> > NULL    | NULL | 382473 | Using where |
> >
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> >
> > It's possible that it can be ever worse, as this number is from
> > another very-long running environments.
> >
> >
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> > | id   | select_type | table          | type | possible_keys | key  |
> > key_len | ref  | rows    | Extra       |
> >
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> > |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> > NULL    | NULL | 3008741 | Using where |
> >
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> >
> > I'm not the SQL expert, could we not optimize this?  Alternatively,
> > could we update the online data migrations code to "pop out" any of
> > the migrations that return 0 for the next iteration, that way it only
> > works on those online_data_migrations that *have* to be done, and
> > ignore those it knows are done?
>

I don't know if there is a good way by which we can persistently store the
state of finished migrations to ensure they are not executed ever again (as
in not having to make the query) once done.
It would also be nice to also be able to opt-in into specific migrations
specially since these span over releases.


>
> and while we're at it, can we just bump the default rows-per-run to
> something more than
> 50 rows? it seems super .. small :)
>
>
I agree the default 50 is a pretty small batch size specially for large
deployments.

[1]
https://github.com/openstack/nova/blob/95a87bce9fa7575c172a7d06344fd3cd070db587/nova/objects/instance.py#L1302

Thanks for bringing this up,
Regards,
Surya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/8be3801f/attachment-0001.html>

From dmellado at redhat.com  Mon Apr  1 09:40:31 2019
From: dmellado at redhat.com (Daniel Mellado)
Date: Mon, 1 Apr 2019 11:40:31 +0200
Subject: [kuryr] Changing upstream meeting time
Message-ID: <9dcf55bd-570c-a387-dffc-a0e2c2dcd8f2@redhat.com>

Hi all!

Since most of our regular meeting attendees are in CEST time zone, I'm
shifting the time slot for our regular meetings to match DST, so the new
meeting time would be Mondays at 14:00 UTC.

I've already proposed a patch at [1]. Searching at
http://eavesdrop.openstack.org/ shows no conflict, so we'll be meeting
at that time at #openstack-meeting-4 (falling back to #openstack-kuryr
should any issues arise).

If you have any doubt or comment, feel free to ping me at the irc.

Best!

Daniel

[1] https://review.openstack.org/#/c/648927/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x13DDF774E05F5B85.asc
Type: application/pgp-keys
Size: 2208 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/da17831c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/da17831c/attachment.sig>

From tpb at dyncloud.net  Mon Apr  1 10:35:44 2019
From: tpb at dyncloud.net (Tom Barron)
Date: Mon, 1 Apr 2019 06:35:44 -0400
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <CAKSuTPYLgMTAaVjeD7bvRyoOuuY4hAqbqFg7LjQ6qSS+iXptWw@mail.gmail.com>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <CAKSuTPZceozexAtuJtuKH=z4SUkK00n37H_=oniJ1wpWh+18Og@mail.gmail.com>
 <20190330204021.leizflkinun32bwy@barron.net>
 <CAKSuTPYLgMTAaVjeD7bvRyoOuuY4hAqbqFg7LjQ6qSS+iXptWw@mail.gmail.com>
Message-ID: <20190401103544.ew26pngy2xaba62h@barron.net>

On 31/03/19 21:15 -0700, Goutham Pacha Ravi wrote:
>On Sat, Mar 30, 2019 at 1:40 PM Tom Barron <tpb at dyncloud.net> wrote:
>>
>> On 27/03/19 11:26 -0700, Goutham Pacha Ravi wrote:
>> >On Wed, Mar 27, 2019 at 5:58 AM Tom Barron <tpb at dyncloud.net> wrote:
>> >>
>> >> In manila we recently merged backports of a change [1] that aims
>> >> to fix up faulty configuration option deprecations in the
>> >> Dell-EMC VMAX driver.  The question at hand is whether (a) we
>> >> should revert these backports on the grounds that the
>> >> deprecations were faulty and therefore are only effective from
>> >> Stein forwards, or whether (b) the deprecations actually worked
>> >> and took effect back when Ocata was the development branch but
>> >> had faults that should be corrected all the way back to Pike
>> >> before it goes EM.
>> >>
>> >> I think (b) is the correct answer but let's check.
>> >>
>> >> On Jan 10 2017 a review [2] merged that deprecated generic
>> >> Dell-EMC driver options in favor of model-specific options [2].
>> >> There were two models at the time, Unity and VNX.  This change
>> >> was in itself unproblematic.
>> >>
>> >> On Jan 24 2017 a review [3] merged that introduced a third
>> >> Dell-EMC model, VMAX.  This new code introduced VMAX specific
>> >> options, consistent with the deprecation of the generic Dell-EMC
>> >> options.  However it had two problems which review [1] corrects.
>> >> When it defined the new VMAX-specific options it failed to
>> >> indicate the corresponding old generic options via
>> >> 'deprecated_name' [4].  Worse, the code that consumed the options
>> >> actually looked for the old generic 'emc_interface_ports' option
>> >> instead of the new 'vmax_ethernet_ports' option.  The only way to
>> >> set a value for this option was to use its deprecated
>> >> form.
>> >>
>> >> The change that we backported fixes both of these problems.
>> >>
>> >> I think it is a valid stable backport.
>> >
>> >
>> >I don't agree with some parts of the change. However, I didn't review
>> >this patch in time, so my opinion is late, and possibly annoying now.
>> >A couple of things with this change are weird, and we could decide to
>> >fix these:
>> >
>> >1) The EMC VMAX driver never had "emc_nas_server_container" or
>> >"emc_nas_pool_names" as config options, but the bug fix [1], adds
>> >these as deprecated names for valid options (vmax_server_container,
>> >vmax_share_data_pools), in a retrospective manner.
>>
>> True, they are added as synonyms for the corresponing model-specific
>> options, and are marked as deprecated.  This aligns the VMAX config
>> with the other EMC models.
>>
>> >2) The EMC VMAX driver always used "emc_interface_ports", however,
>> >there was no such configuration option wrt that backend. How would
>> >users know to set it? Things passed because there was a "safe_get"
>> >operation, and perhaps the vendor had called this out in their docs?
>> >It's good they fixed this part in Stein.
>>
>> There is no question that the VMAX driver code was broken.
>>
>> >
>> >
>> >> If people set this "ports" option using the deprecated option it
>> >> will still work.  The deprecated option has not been removed yet
>> >> and will never be removed from any of the stable branches.
>> >>
>> >> If they tried to set it via the proper option then they would have
>> >> had a functional problem, a bug, which this change now fixes.
>> >
>> >Agree with this point.
>> >
>> >> If on the other hand we say we cannot backport this then until
>> >> stable/stein there will be no way for VMAX users of earlier stable
>> >> branches to set this option except by magic -- by using an old
>> >> deprecated form of the option that without the backported fix is not
>> >> even visible in the customer-facing configuration for VMAX.
>> >> All this said, I could well be missing something so I welcome
>> >> analysis by stable/core folks.  The backports in question have not
>> >> yet been released so it would not be a problem to revert them.
>> >
>> >I think it would be worth back porting the deprecation and association
>> >between "emc_interface_ports" and "vmax_ethernet_ports" in the
>> >interest of customers/users. However, I think [1] introduces another
>> >bug by exposing net new options for this driver
>> >("emc_nas_server_container" and "emc_nas_pool_names") as deprecated
>> >forms of existing options ("vmax_server_container",
>> >"vmax_share_data_pools"), and that is concerning.
>> >
>>
>> What is the new bug that this change introduces?  Won't the net new
>> options work and isn't the configuration backwards compatible in the
>> sense that there are no options that used to work that will not work
>> now?
>
>The bug is introducing deprecated forms of the options, and back
>porting that to older releases. Perhaps there's some business/customer
>understanding reasoning I don't know of. It can be termed harmless,
>because the original and legitimate options will continue to work.

Hmm, that doesn't seem to me to be an error, flaw, failure or fault 
that causes the program or system to produce an incorrect or 
unexpected result, or to behave in unintended ways.  The change in 
question gets this VMAX model to *work*, and to work in a way that is 
consistent with config options and user expectations for the other EMC 
models.

Without introducing a bug a backport could still be a violation of 
stable/branch review guidelines [1] but that doesn't seem to be an 
issue either. This backport doesn't introduce a new feature, change 
HTTP APIs, change the AMQP API, change notification definitions, make 
DB schema changes, or make incompatible config file changes.

At the risk of stating the obvious, but for the record, this backport 
doesn't change *when* these deprecations occurred for VMAX.  They 
occurred in Stein development cycle, not during the Ocata development 
cycle, and the earliest the deprecated options could be removed is 
Train.

[1] https://docs.openstack.org/project-team-guide/stable-branches.html

>
>>
>> >> Thanks!
>> >>
>> >> -- Tom Barron
>> >>
>> >> [1] https://review.openstack.org/#/c/608725/
>> >>
>> >> [2] https://review.openstack.org/#/c/415079/
>> >>
>> >> [3] https://review.openstack.org/#/c/404859/
>> >>
>> >> [4] If this was the only issue then arguably it wasn't an error
>> >> since the VMAX driver never operated with the old options.
>> >>


From jaypipes at gmail.com  Mon Apr  1 12:06:27 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 1 Apr 2019 08:06:27 -0400
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <1554108230.4997.13.camel@offenerstapel.de>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
Message-ID: <83ea0995-c5be-4f5a-208f-25c81a29657f@gmail.com>

On 04/01/2019 04:43 AM, Jens Harbott wrote:
> On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
>> Hi,
>>
>> During the summit in Tokyo (if I remember well), Sean Dague lead a
>> discussion about removing the need for having 3 endpoints per
>> service. I
>> was very excited about the proposal, and it's IMO a shame it hasn't
>> been
>> implemented. Everyone in the room agreed. Here the content of the
>> discussion as I remember it:
>>
>> <discussion in Tokyo>
>> 1/ The only service that needed the admin endpoint was Keystone. This
>> requirement is now gone. So we could get rid of the admin endpoint
>> all
>> together.
>>
>> 2/ The need for an interal vs public endpoint was only needed for
>> accounting (of for example bandwidth when uploading to Glance), but
>> this
>> could be work-around by operators by using intelligent routing. So we
>> wouldn't need the internal endpoint.
>>
>> This makes us only need the public endpoint, and that's it.
>>
>> Then, there are these %(tenant_id)s bits in the endpoints which are
>> also
>> very much annoying, and could be removed if the clients were smarter.
>> These are still needed, apparently, for:
>> - cinder
>> - swift
>> - heat
>> </discussion in Tokyo>
>>
>> Is anyone planning to implement (at least some parts of) the above?
> 
> For me as an operator, the distinction between internal and public
> endpoints is helpful, as it allows to easily set up extended filtering
> or rate limiting for public services without affecting internal API
> calls, which in most deployments cause the majority of requests.
> 
> I'm not sure what "intelligent routing" is meant to be, but it sounds
> more complicated and unstable than the current solution.

Maybe Thomas was referring to having Keystone just return a single set 
of endpoints depending on the source CIDR.

Or maybe he is referring to performing rate-limiting using a lower-level 
tool that was purpose-built for it -- something like iptables?

i.e. ACCEPT all new connections from your private subnet/CIDR and jump 
all new connections not in your private subnet to a RATE-LIMIT chain 
that applies rate-limiting thresholds.

In other words, use a single HTTP endpoint and do the rate-limiting in 
the Linux kernel instead of higher-level applications.

Related: this is why having "quotas" for things like # of metadata items 
in Nova was always a terrible "feature" that was abusing the quota 
system as a terrible rate-limiting middleware when things like iptables 
or tc were a more appropriate solution.

Best,
-jay

> Big +1 on dropping the admin endpoint though, now that keystone doesn't
> need it anymore.
> 
> Jens
> 


From jaypipes at gmail.com  Mon Apr  1 12:21:10 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 1 Apr 2019 08:21:10 -0400
Subject: [nova] super long online_data_migrations
In-Reply-To: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
Message-ID: <f140f4d1-68c3-a8ec-cf1a-1cf6c23c0b4e@gmail.com>

On 03/31/2019 10:21 PM, Mohammed Naser wrote:
> Hi there,
> 
> During upgrades, I've noticed that when running online_data_migrations
> with "infinite-until-done" mode, it loops over all of the migrations
> one by one.
> 
> However, one of the online data migrations
> (instance_obj.populate_missing_availability_zones) makes a query that
> takes a really long time as it seems inefficient (which eventually
> results in 0, cause it already ran), which means as it loops in
> "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
> environments.
> 
> The question ends up in specific:
> 
> SELECT count(*) AS count_1
> FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
> instance_extra.updated_at AS instance_extra_updated_at,
> instance_extra.deleted_at AS instance_extra_deleted_at,
> instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
> instance_extra_id, instance_extra.instance_uuid AS
> instance_extra_instance_uuid
> FROM instance_extra
> WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1

Ugh. :(

The online data migration shouldn't be calling the above SQL statement 
at all.

Instead, the migration should be doing something like this:

SELECT ie.instance_uuid FROM instance_extra AS ie
WHERE ie.keypairs IS NULL AND ie.deletd = 0
LIMIT 100

and then while getting any rows returned from the above, perform the 
work of transforming the problematic data in the table for each matched 
instance_uuid.

I'm actually not sure what the above query has to do with availability 
zones, but I'll look into it later on this morning.

Can you report a bug about this and we'll get on it ASAP?

Best,
-jay

> The explain for the DB query in this example:
> 
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows   | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 382473 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> 
> It's possible that it can be ever worse, as this number is from
> another very-long running environments.
> 
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows    | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 3008741 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> 
> I'm not the SQL expert, could we not optimize this?  Alternatively,
> could we update the online data migrations code to "pop out" any of
> the migrations that return 0 for the next iteration, that way it only
> works on those online_data_migrations that *have* to be done, and
> ignore those it knows are done?
> 
> Thanks,
> Mohammed
> 


From bence.romsics at gmail.com  Mon Apr  1 12:31:11 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Mon, 1 Apr 2019 14:31:11 +0200
Subject: [neutron] bug deputy report for week of 2019-03-25
In-Reply-To: <CAHeS+39HjwqkQvS-V-HysMRAKuM02=kgSo+PDYhC=x5Trj5VZA@mail.gmail.com>
References: <CAHeS+39HjwqkQvS-V-HysMRAKuM02=kgSo+PDYhC=x5Trj5VZA@mail.gmail.com>
Message-ID: <CAHeS+38oOpA+OsoAOosLMCnHt_fViiWMHX-ei3ydKqw=GkVQnw@mail.gmail.com>

Hi,

Please excuse my self-reply, but here comes the updated, more complete
version of my bug deputy report. I will not be able to attend today's
meeting, but if I may, let me call your attention to the top 3 bugs:

Critical:
* https://bugs.launchpad.net/neutron/+bug/1822453
neutron-tempest-plugin-designate-scenario is broken
gate-failure, fix proposed: https://review.openstack.org/648951

High:
* https://bugs.launchpad.net/neutron/+bug/1821912
intermittent ssh failures in various scenario tests
gate failure, no fix proposed yet
* https://bugs.launchpad.net/neutron/+bug/1822256
Ip segments lost when restart ovs-agent with openvswitch firewall
packet loss at agent restart, no fix proposed yet

Medium:
* https://bugs.launchpad.net/neutron/+bug/1822100
Network Update if current provider net attribure key/value pair in request
fix proposed: https://review.openstack.org/648522
* https://bugs.launchpad.net/neutron/+bug/1822105
Policy rules related to "sub parameters" doesn't work properly
fix proposed: https://review.openstack.org/648532
* https://bugs.launchpad.net/neutron/+bug/1821948
Unstable unit test uses subnet broadcast address
low frequency gate failure, fix merged: https://review.openstack.org/648172

Low:
* https://bugs.launchpad.net/neutron/+bug/1822155
neutron-keepalived-state-change can not start on some python3 distro
problem specific to (unsupported) python3.4, fix proposed:
https://review.openstack.org/648459
* https://bugs.launchpad.net/neutron/+bug/1822199
neutron-vpn-netns-wrapper not invoked with --rootwrap_config parameter
low hanging fruit, no fix proposed yet

Needs further triaging:
* https://bugs.launchpad.net/neutron/+bug/1821963
Rally test delete-subnets fails at higher concurrency
could not reproduce yet, waiting to hear back from reporter

Incomplete:
* https://bugs.launchpad.net/neutron/+bug/1821567
network_segment_ranges could not load in tricirlce test
likely not a neutron bug but a tricircle one
* https://bugs.launchpad.net/neutron/+bug/1821925
Limit test coverage for Extended Maintenance stable branches
please look at it if you're interested in stable / extended maintenance process

Duplicate:
* https://bugs.launchpad.net/neutron/+bug/1821357
VRRP vip on VM not reachable from other network on DVR setup
duplicate of https://bugs.launchpad.net/bugs/1774459

Invalid:
* https://bugs.launchpad.net/neutron/+bug/1822382
DBDeadlock for INSERT INTO resourcedeltas

Cheers,
Bence
irc: rubasov


From frickler at offenerstapel.de  Mon Apr  1 13:45:16 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Mon, 01 Apr 2019 13:45:16 +0000
Subject: [dev][neutron] CI broken
In-Reply-To: <A1F14623-7C4E-4F98-BB0B-C3A51280874A@redhat.com>
References: <A1F14623-7C4E-4F98-BB0B-C3A51280874A@redhat.com>
Message-ID: <1554126316.4997.15.camel@offenerstapel.de>

On Mon, 2019-04-01 at 08:29 +0200, Slawomir Kaplonski wrote:
> Hi,
> 
> Just FYI, since few days we have broken neutron-tempest-plugin-
> designate-scenario job and it is failing 100% times. Bug is reported
> in [1].
> If this job failed on Your patch, please don’t recheck as it will not
> solve the problem.
> 
> [1] https://bugs.launchpad.net/neutron/+bug/1822453

Actually a patch in devstack caused this regression, affecting all jobs
that use multiple tempest plugins. A fix for that is being reviewed,
see the above bug report for details.

Jens


From navdeep.uniyal at bristol.ac.uk  Mon Apr  1 13:54:02 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Mon, 1 Apr 2019 13:54:02 +0000
Subject: [Magnum] Cluster Create failure
In-Reply-To: <AM6PR06MB5879B7A1A1A0B9075128A793DE5A0@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879BCCDEBCEA70CA704D7B9DE580@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FA4ACC0B-E2B8-42E4-B4B5-2B2301743BD7@stackhpc.com>
 <AM6PR06MB587923F5E56DAA1BC825B7C7DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <BA0C1973-9CF7-48DE-A95D-2312A43D0F2E@stackhpc.com>
 <AM6PR06MB5879B08F8D31E08904056292DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FDBA865F-9F3D-4B1C-98C7-78E050066FC7@stackhpc.com>
 <AM6PR06MB5879A7A3C0DC6A49B72B8BE3DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAEs876gYAQQ3+RXe0SdiZLTTZaCJLMSSmqNTuj0BUpDJ9dcVew@mail.gmail.com>
 <AM6PR06MB5879B7A1A1A0B9075128A793DE5A0@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <AM6PR06MB5879EF9DEA3A344EA66FA7E5DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear All,

My Kubernetes Cluster is timing out after 60 mins.

Following is the update I am getting in magnum.log:

{"stack": {"parent": null, "disable_rollback": true, "description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n", "parameters": {"magnum_url": "http://10.68.48.4:9511/v1", "kube_tag": "v1.11.6", "http_proxy": "", "cgroup_driver": "cgroupfs", "registry_container": "container", "kubernetes_port": "6443", "calico_kube_controllers_tag": "v1.0.3", "octavia_enabled": "False", "etcd_volume_size": "0", "kube_dashboard_enabled": "True", "master_flavor": "medium", "etcd_tag": "v3.2.7", "kube_version": "v1.11.6", "k8s_keystone_auth_tag": "1.13.0", "kube_service_account_private_key": "******", "keystone_auth_enabled": "True", "cloud_provider_tag": "v0.2.0", "ca_key": "******", "tiller_enabled": "False", "registry_enabled": "False", "verify_ca": "True", "password": "******", "dns_service_ip": "10.254.0.10", "ssh_key_name": "magnum_key", "flannel_tag": "v0.10.0-amd64", "flannel_network_subnetlen": "24", "dns_nameserver": "8.8.8.8", "number_of_masters": "1", "wait_condition_timeout": "6000", "portal_network_cidr": "10.254.0.0/16", "admission_control_list": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota", "pods_network_cidr": "10.100.0.0/16", "ingress_controller": "", "external_network": "751ae6e5-71af-4f78-b846-b0e1843093c8", "docker_volume_type": "", "registry_port": "5000", "tls_disabled": "False", "trust_id": "******", "swift_region": "", "influx_grafana_dashboard_enabled": "False", "volume_driver": "", "kubescheduler_options": "", "calico_tag": "v2.6.7", "loadbalancing_protocol": "TCP", "cloud_provider_enabled": "True", "OS::stack_id": "06c05715-ac05-4287-905c-38f1964f09fe", "flannel_cni_tag": "v0.3.0", "prometheus_monitoring": "False", "kubelet_options": "", "fixed_network": "", "kube_dashboard_version": "v1.8.3", "trustee_username": "d7ff417e-85b6-4b9a-94c3-211e7b830a51_4c6bc4445c764249921a0a6e40b192dd", "availability_zone": "", "server_image": "fedora-feduser-atomic", "flannel_network_cidr": "10.100.0.0/16", "cert_manager_api": "False", "minion_flavor": "medium", "kubeproxy_options": "", "calico_cni_tag": "v1.11.2", "cluster_uuid": "d7ff417e-85b6-4b9a-94c3-211e7b830a51", "grafana_admin_passwd": "******", "flannel_backend": "udp", "trustee_domain_id": "ac26210ad4f74217b3abf28a9b5cf56d", "fixed_subnet": "", "https_proxy": "", "username": "admin", "insecure_registry_url": "", "docker_volume_size": "0", "grafana_tag": "5.1.5", "kube_allow_priv": "true", "node_problem_detector_tag": "v0.6.2", "docker_storage_driver": "overlay2", "project_id": "4c6bc4445c764249921a0a6e40b192dd", "registry_chunksize": "5242880", "trustee_user_id": "d1983ea926c34536aabc8d50a85503e8", "container_infra_prefix": "", "number_of_minions": "1", "tiller_tag": "v2.12.3", "auth_url": "http://pluto:5000/v3", "registry_insecure": "True", "tiller_namespace": "magnum-tiller", "prometheus_tag": "v1.8.2", "OS::project_id": "4c6bc4445c764249921a0a6e40b192dd", "kubecontroller_options": "", "fixed_network_cidr": "10.0.0.0/24", "kube_service_account_key": "******", "ingress_controller_role": "ingress", "region_name": "RegionOne", "kubeapi_options": "", "openstack_ca": "******", "trustee_password": "******", "nodes_affinity_policy": "soft-anti-affinity", "minions_to_remove": "", "octavia_ingress_controller_tag": "1.13.2-alpha", "OS::stack_name": "kubernetes-cluster-wwmvqecjiznb", "system_pods_timeout": "5", "system_pods_initial_delay": "30", "dns_cluster_domain": "cluster.local", "calico_ipv4pool": "192.168.0.0/16", "network_driver": "flannel", "monitoring_enabled": "False", "heat_container_agent_tag": "stein-dev", "no_proxy": "", "discovery_url": "https://discovery.etcd.io/b8fe011e8b281615904de97ee05511a7"}, "deletion_time": null, "stack_name": "kubernetes-cluster-wwmvqecjiznb", "stack_user_project_id": "8204d11826fb4253ae7c9063306cb4e1", "tags": null, "creation_time": "2019-04-01T13:19:53Z", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-wwmvqecjiznb/06c05715-ac05-4287-905c-38f1964f09fe", "rel": "self"}], "capabilities": [], "notification_topics": [], "timeout_mins": 60, "stack_status": "CREATE_IN_PROGRESS", "stack_owner": null, "updated_time": null, "id": "06c05715-ac05-4287-905c-38f1964f09fe", "stack_status_reason": "Stack CREATE started", "template_description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n"}}

I am not sure how to triage this issue as I cannot see any errors in heat.log as well. 
Even I can see both Master and Minion node running but the task errors out during OS::Heat::SoftwareDeployment in kube_cluster_deploy and OS::Heat::ResourceGroup in kube_minions

I don't have much experience with Kubernetes clusters as well so please forgive me if I am raising any silly queries.

Kind Regards,
Navdeep


-----Original Message-----
From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> 
Sent: 29 March 2019 12:16
To: Mohammed Naser <mnaser at vexxhost.com>; Bharat Kunwar <bharat at stackhpc.com>
Cc: openstack at lists.openstack.org
Subject: RE: [Magnum] Cluster Create failure

Hi Guys,

I am able to resolve the issue in nova. (it was a problem with the oslo.db version - Somehow I installed version 4.44 instead of 4.25 for my pike installation) However, moving forward, I started my kube cluster, I could see 2 instances running for Kube-master and kube-minion. But the deployment failed after that with the following error:

{"message": "The resource was found at <a href=\"http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb/resources?status=FAILED&nested_d
epth=2\">http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb/resources?status=FAILED&nested_depth=2</a>;\nyou should be redirected au tomatically.\n\n", "code": "302 Found", "title": "Found"}  log_http_response /var/lib/magnum/env/local/lib/python2.7/site-packages/heatclient/common/http.py:157
2019-03-29 12:05:51.225 157681 DEBUG heatclient.common.http [req-76e55dec-9511-4aad-aa52-af9978b40eed - - - - -] curl -g -i -X GET -H 'User-Agent: python-heatclient' -H 'Content-Type: application/json' -H 'X-Aut
h-Url: http://pluto:5000/v3' -H 'Accept: application/json' -H 'X-Auth-Token: {SHA1}f2c32656c7103ad0b89d83ff9f1b6cebc0a6eee7' http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgka
nhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb/resources?status=FAILED&nested_depth=2 log_curl_request /var/lib/magnum/env/local/lib/python2.7/site-packages/heatclient/common/http.py:144
2019-03-29 12:05:51.379 157681 DEBUG heatclient.common.http [req-76e55dec-9511-4aad-aa52-af9978b40eed - - - - -]
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 4035
X-Openstack-Request-Id: req-942ef8fa-1bba-4573-9022-0d4e135772e0
Date: Fri, 29 Mar 2019 12:05:51 GMT
Connection: keep-alive

{"resources": [{"resource_name": "kube_cluster_deploy", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb/resources/kube_cluster_deploy", "rel": "self"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb", "rel": "stack"}], "logical_resource_id": "kube_cluster_deploy", "creation_time": "2019-03-29T10:40:00Z", "resource_status": "CREATE_FAILED", "updated_time": "2019-03-29T10:40:00Z", "required_by": [], "resource_status_reason": "CREATE aborted (Task create from SoftwareDeployment \"kube_cluster_deploy\" Stack \"kubernetes-cluster-eovgkanhoa4x\" [384d8725-bca3-4fa4-a9fd-f18687aab8fb] Timed out)", "physical_resource_id": "8d715a3f-6ec8-4772-ba4b-1056cd4ab7d3", "resource_type": "OS::Heat::SoftwareDeployment"}, {"resource_name": "kube_minions", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb/resources/kube_minions", "rel": "self"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x/384d8725-bca3-4fa4-a9fd-f18687aab8fb", "rel": "stack"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46/33700819-0766-4d30-954b-29aace6048cc", "rel": "nested"}], "logical_resource_id": "kube_minions", "creation_time": "2019-03-29T10:40:00Z", "resource_status_reason": "CREATE aborted (Task create from ResourceGroup \"kube_minions\" Stack \"kubernetes-cluster-eovgkanhoa4x\" [384d8725-bca3-4fa4-a9fd-f18687aab8fb] Timed out)", "updated_time": "2019-03-29T10:40:00Z", "required_by": [], "resource_status": "CREATE_FAILED", "physical_resource_id": "33700819-0766-4d30-954b-29aace6048cc", "resource_type": "OS::Heat::ResourceGroup"}, {"parent_resource": "kube_minions", "resource_name": "0", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46/33700819-0766-4d30-954b-29aace6048cc/resources/0", "rel": "self"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46/33700819-0766-4d30-954b-29aace6048cc", "rel": "stack"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46-0-ftjzf76onzqn/d1a8214c-c5b0-488c-83d6-f0a9cacbe844", "rel": "nested"}], "logical_resource_id": "0", "creation_time": "2019-03-29T10:40:59Z", "resource_status_reason": "resources[0]: Stack CREATE cancelled", "updated_time": "2019-03-29T10:40:59Z", "required_by": [], "resource_status": "CREATE_FAILED", "physical_resource_id": "d1a8214c-c5b0-488c-83d6-f0a9cacbe844", "resource_type": "file:///var/lib/magnum/env/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubeminion.yaml"}, {"parent_resource": "0", "resource_name": "minion_wait_condition", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46-0-ftjzf76onzqn/d1a8214c-c5b0-488c-83d6-f0a9cacbe844/resources/minion_wait_condition", "rel": "self"}, {"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46-0-ftjzf76onzqn/d1a8214c-c5b0-488c-83d6-f0a9cacbe844", "rel": "stack"}], "logical_resource_id": "minion_wait_condition", "creation_time": "2019-03-29T10:41:01Z", "resource_status": "CREATE_FAILED", "updated_time": "2019-03-29T10:41:01Z", "required_by": [], "resource_status_reason": "CREATE aborted (Task create from HeatWaitCondition \"minion_wait_condition\" Stack \"kubernetes-cluster-eovgkanhoa4x-kube_minions-otcpiw3oye46-0-ftjzf76onzqn\" [d1a8214c-c5b0-488c-83d6-f0a9cacbe844] Timed out)", "physical_resource_id": "", "resource_type": "OS::Heat::WaitCondition"}]}

I am not sure how to debug this. Please advise.

Kind Regards,
Navdeep

-----Original Message-----
From: Mohammed Naser <mnaser at vexxhost.com>
Sent: 28 March 2019 13:27
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: Bharat Kunwar <bharat at stackhpc.com>; openstack at lists.openstack.org
Subject: Re: [Magnum] Cluster Create failure

your placement service seems to be broken :)

On Thu, Mar 28, 2019 at 9:10 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
>
> Yes, there seems to be some issue with the server creation now.
> I will check and try resolving that. Thank you
>
> Regards,
> Navdeep
>
> -----Original Message-----
> From: Bharat Kunwar <bharat at stackhpc.com>
> Sent: 28 March 2019 12:40
> To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> Cc: openstack at lists.openstack.org
> Subject: Re: [Magnum] Cluster Create failure
>
> Can you create a server normally?
>


--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com

From bharat at stackhpc.com  Mon Apr  1 13:58:48 2019
From: bharat at stackhpc.com (Bharat Kunwar)
Date: Mon, 1 Apr 2019 14:58:48 +0100
Subject: [Magnum] Cluster Create failure
In-Reply-To: <AM6PR06MB5879EF9DEA3A344EA66FA7E5DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879BCCDEBCEA70CA704D7B9DE580@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FA4ACC0B-E2B8-42E4-B4B5-2B2301743BD7@stackhpc.com>
 <AM6PR06MB587923F5E56DAA1BC825B7C7DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <BA0C1973-9CF7-48DE-A95D-2312A43D0F2E@stackhpc.com>
 <AM6PR06MB5879B08F8D31E08904056292DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FDBA865F-9F3D-4B1C-98C7-78E050066FC7@stackhpc.com>
 <AM6PR06MB5879A7A3C0DC6A49B72B8BE3DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAEs876gYAQQ3+RXe0SdiZLTTZaCJLMSSmqNTuj0BUpDJ9dcVew@mail.gmail.com>
 <AM6PR06MB5879B7A1A1A0B9075128A793DE5A0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB5879EF9DEA3A344EA66FA7E5DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <29BAEF27-99CE-410D-B9EF-C3E5851C9D26@stackhpc.com>

Hi Navdeep,

Have you tried logging into the master/worker node and gripping for `fail` inside /var/log/cloud-init.log and /var/log/cloud-init-output.log? Also how did you deploy your OpenStack services? 

Bharat

> On 1 Apr 2019, at 14:54, Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
> 
> Dear All,
> 
> My Kubernetes Cluster is timing out after 60 mins.
> 
> Following is the update I am getting in magnum.log:
> 
> {"stack": {"parent": null, "disable_rollback": true, "description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n", "parameters": {"magnum_url": "http://10.68.48.4:9511/v1", "kube_tag": "v1.11.6", "http_proxy": "", "cgroup_driver": "cgroupfs", "registry_container": "container", "kubernetes_port": "6443", "calico_kube_controllers_tag": "v1.0.3", "octavia_enabled": "False", "etcd_volume_size": "0", "kube_dashboard_enabled": "True", "master_flavor": "medium", "etcd_tag": "v3.2.7", "kube_version": "v1.11.6", "k8s_keystone_auth_tag": "1.13.0", "kube_service_account_private_key": "******", "keystone_auth_enabled": "True", "cloud_provider_tag": "v0.2.0", "ca_key": "******", "tiller_enabled": "False", "registry_enabled": "False", "verify_ca": "True", "password": "******", "dns_service_ip": "10.254.0.10", "ssh_key_name": "magnum_key", "flannel_tag": "v0.10.0-amd64", "flannel_network_subnetlen": "24", "dns_nameserver": "8.8.8.8", "number_of_masters": "1", "wait_condition_timeout": "6000", "portal_network_cidr": "10.254.0.0/16", "admission_control_list": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota", "pods_network_cidr": "10.100.0.0/16", "ingress_controller": "", "external_network": "751ae6e5-71af-4f78-b846-b0e1843093c8", "docker_volume_type": "", "registry_port": "5000", "tls_disabled": "False", "trust_id": "******", "swift_region": "", "influx_grafana_dashboard_enabled": "False", "volume_driver": "", "kubescheduler_options": "", "calico_tag": "v2.6.7", "loadbalancing_protocol": "TCP", "cloud_provider_enabled": "True", "OS::stack_id": "06c05715-ac05-4287-905c-38f1964f09fe", "flannel_cni_tag": "v0.3.0", "prometheus_monitoring": "False", "kubelet_options": "", "fixed_network": "", "kube_dashboard_version": "v1.8.3", "trustee_username": "d7ff417e-85b6-4b9a-94c3-211e7b830a51_4c6bc4445c764249921a0a6e40b192dd", "availability_zone": "", "server_image": "fedora-feduser-atomic", "flannel_network_cidr": "10.100.0.0/16", "cert_manager_api": "False", "minion_flavor": "medium", "kubeproxy_options": "", "calico_cni_tag": "v1.11.2", "cluster_uuid": "d7ff417e-85b6-4b9a-94c3-211e7b830a51", "grafana_admin_passwd": "******", "flannel_backend": "udp", "trustee_domain_id": "ac26210ad4f74217b3abf28a9b5cf56d", "fixed_subnet": "", "https_proxy": "", "username": "admin", "insecure_registry_url": "", "docker_volume_size": "0", "grafana_tag": "5.1.5", "kube_allow_priv": "true", "node_problem_detector_tag": "v0.6.2", "docker_storage_driver": "overlay2", "project_id": "4c6bc4445c764249921a0a6e40b192dd", "registry_chunksize": "5242880", "trustee_user_id": "d1983ea926c34536aabc8d50a85503e8", "container_infra_prefix": "", "number_of_minions": "1", "tiller_tag": "v2.12.3", "auth_url": "http://pluto:5000/v3", "registry_insecure": "True", "tiller_namespace": "magnum-tiller", "prometheus_tag": "v1.8.2", "OS::project_id": "4c6bc4445c764249921a0a6e40b192dd", "kubecontroller_options": "", "fixed_network_cidr": "10.0.0.0/24", "kube_service_account_key": "******", "ingress_controller_role": "ingress", "region_name": "RegionOne", "kubeapi_options": "", "openstack_ca": "******", "trustee_password": "******", "nodes_affinity_policy": "soft-anti-affinity", "minions_to_remove": "", "octavia_ingress_controller_tag": "1.13.2-alpha", "OS::stack_name": "kubernetes-cluster-wwmvqecjiznb", "system_pods_timeout": "5", "system_pods_initial_delay": "30", "dns_cluster_domain": "cluster.local", "calico_ipv4pool": "192.168.0.0/16", "network_driver": "flannel", "monitoring_enabled": "False", "heat_container_agent_tag": "stein-dev", "no_proxy": "", "discovery_url": "https://discovery.etcd.io/b8fe011e8b281615904de97ee05511a7"}, "deletion_time": null, "stack_name": "kubernetes-cluster-wwmvqecjiznb", "stack_user_project_id": "8204d11826fb4253ae7c9063306cb4e1", "tags": null, "creation_time": "2019-04-01T13:19:53Z", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-wwmvqecjiznb/06c05715-ac05-4287-905c-38f1964f09fe", "rel": "self"}], "capabilities": [], "notification_topics": [], "timeout_mins": 60, "stack_status": "CREATE_IN_PROGRESS", "stack_owner": null, "updated_time": null, "id": "06c05715-ac05-4287-905c-38f1964f09fe", "stack_status_reason": "Stack CREATE started", "template_description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n"}}
> 
> I am not sure how to triage this issue as I cannot see any errors in heat.log as well. 
> Even I can see both Master and Minion node running but the task errors out during OS::Heat::SoftwareDeployment in kube_cluster_deploy and OS::Heat::ResourceGroup in kube_minions
> 
> I don't have much experience with Kubernetes clusters as well so please forgive me if I am raising any silly queries.
> 
> Kind Regards,
> Navdeep
> 



From mnaser at vexxhost.com  Mon Apr  1 14:12:56 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Mon, 1 Apr 2019 10:12:56 -0400
Subject: [nova] super long online_data_migrations
In-Reply-To: <f140f4d1-68c3-a8ec-cf1a-1cf6c23c0b4e@gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
 <f140f4d1-68c3-a8ec-cf1a-1cf6c23c0b4e@gmail.com>
Message-ID: <CAEs876hffL4wU8gnVk6JSLz=Cb7t0LbrkzMs9r3s0ROeGJo1_A@mail.gmail.com>

On Mon, Apr 1, 2019 at 8:25 AM Jay Pipes <jaypipes at gmail.com> wrote:
>
> On 03/31/2019 10:21 PM, Mohammed Naser wrote:
> > Hi there,
> >
> > During upgrades, I've noticed that when running online_data_migrations
> > with "infinite-until-done" mode, it loops over all of the migrations
> > one by one.
> >
> > However, one of the online data migrations
> > (instance_obj.populate_missing_availability_zones) makes a query that
> > takes a really long time as it seems inefficient (which eventually
> > results in 0, cause it already ran), which means as it loops in
> > "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
> > environments.
> >
> > The question ends up in specific:
> >
> > SELECT count(*) AS count_1
> > FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
> > instance_extra.updated_at AS instance_extra_updated_at,
> > instance_extra.deleted_at AS instance_extra_deleted_at,
> > instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
> > instance_extra_id, instance_extra.instance_uuid AS
> > instance_extra_instance_uuid
> > FROM instance_extra
> > WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1
>
> Ugh. :(
>
> The online data migration shouldn't be calling the above SQL statement
> at all.
>
> Instead, the migration should be doing something like this:
>
> SELECT ie.instance_uuid FROM instance_extra AS ie
> WHERE ie.keypairs IS NULL AND ie.deletd = 0
> LIMIT 100
>
> and then while getting any rows returned from the above, perform the
> work of transforming the problematic data in the table for each matched
> instance_uuid.
>
> I'm actually not sure what the above query has to do with availability
> zones, but I'll look into it later on this morning.
>
> Can you report a bug about this and we'll get on it ASAP?

Thanks for looking into this.  I've noticed some of the newer data
migrations actually
take into question the limit, but this one doesn't from the looks of it.

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

I'd be happy to test it out against a big data set, if you'd like.

> Best,
> -jay
>
> > The explain for the DB query in this example:
> >
> > +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> > | id   | select_type | table          | type | possible_keys | key  |
> > key_len | ref  | rows   | Extra       |
> > +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> > |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> > NULL    | NULL | 382473 | Using where |
> > +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> >
> > It's possible that it can be ever worse, as this number is from
> > another very-long running environments.
> >
> > +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> > | id   | select_type | table          | type | possible_keys | key  |
> > key_len | ref  | rows    | Extra       |
> > +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> > |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> > NULL    | NULL | 3008741 | Using where |
> > +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> >
> > I'm not the SQL expert, could we not optimize this?  Alternatively,
> > could we update the online data migrations code to "pop out" any of
> > the migrations that return 0 for the next iteration, that way it only
> > works on those online_data_migrations that *have* to be done, and
> > ignore those it knows are done?
> >
> > Thanks,
> > Mohammed
> >
>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From openstack at fried.cc  Mon Apr  1 14:15:49 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 1 Apr 2019 09:15:49 -0500
Subject: [nova][CI] nova-live-migration failing
Message-ID: <9f43b784-2dfb-3d63-0212-51f758a36e32@fried.cc>

> I've noticed the nova-live-migration job failing consistently over the
> weekend on clearly unrelated patches. Haven't had a chance to look
> into it at all. Please consider holding off blind rechecks for a bit.

Matt identified bug [1], cause [2], and fix [3]. Please wait until the
latter has merged (or rebase on top of it) before rechecking in nova.

Thanks,
efried

[1] https://bugs.launchpad.net/nova/+bug/1822605
[2] https://review.openstack.org/#/c/601433/
[3] https://review.openstack.org/#/c/649036/


From navdeep.uniyal at bristol.ac.uk  Mon Apr  1 14:19:03 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Mon, 1 Apr 2019 14:19:03 +0000
Subject: [Magnum] Cluster Create failure
In-Reply-To: <29BAEF27-99CE-410D-B9EF-C3E5851C9D26@stackhpc.com>
References: <AM6PR06MB5879BCCDEBCEA70CA704D7B9DE580@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FA4ACC0B-E2B8-42E4-B4B5-2B2301743BD7@stackhpc.com>
 <AM6PR06MB587923F5E56DAA1BC825B7C7DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <BA0C1973-9CF7-48DE-A95D-2312A43D0F2E@stackhpc.com>
 <AM6PR06MB5879B08F8D31E08904056292DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FDBA865F-9F3D-4B1C-98C7-78E050066FC7@stackhpc.com>
 <AM6PR06MB5879A7A3C0DC6A49B72B8BE3DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAEs876gYAQQ3+RXe0SdiZLTTZaCJLMSSmqNTuj0BUpDJ9dcVew@mail.gmail.com>
 <AM6PR06MB5879B7A1A1A0B9075128A793DE5A0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB5879EF9DEA3A344EA66FA7E5DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <29BAEF27-99CE-410D-B9EF-C3E5851C9D26@stackhpc.com>
Message-ID: <AM6PR06MB58794B0C3CA5AEEE5AE5CEFDDE550@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Bharat,

Thank you for your response.

I am getting following errors in my worker VM (Master VM has similar errors):

[feduser at kubernetes-cluster-wwmvqecjiznb-minion-0 ~]$ less /var/log/cloud-init.log | grep fail
2019-03-29 16:20:37,018 - cc_growpart.py[DEBUG]: '/' SKIPPED: device_part_info(/dev/mapper/atomicos-root) failed: /dev/mapper/atomicos-root not a partition
2019-03-29 16:20:37,219 - main.py[DEBUG]: Ran 14 modules with 0 failures
2019-03-29 16:20:38,450 - main.py[DEBUG]: Ran 7 modules with 0 failures
2019-03-29 16:20:39,501 - main.py[DEBUG]: Ran 16 modules with 0 failures
2019-04-01 13:21:07,978 - util.py[WARNING]: failed stage init-local
2019-04-01 13:21:07,978 - util.py[DEBUG]: failed stage init-local
2019-04-01 13:21:09,250 - url_helper.py[DEBUG]: Calling 'http://169.254.169.254/openstack' failed [0/-1s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /openstack (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67d6c50>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:09,252 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67eb588>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:10,255 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67eb2b0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:11,259 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67ebe10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:12,264 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f35f8>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:13,268 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [4/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f3e10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:14,272 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [5/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67fa668>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:16,278 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [7/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f3550>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:18,283 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [9/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67ebe10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:36,442 - cc_growpart.py[DEBUG]: '/' SKIPPED: device_part_info(/dev/mapper/atomicos-root) failed: /dev/mapper/atomicos-root not a partition
2019-04-01 13:21:36,609 - main.py[DEBUG]: Ran 14 modules with 0 failures
2019-04-01 13:21:37,847 - main.py[DEBUG]: Ran 7 modules with 0 failures
2019-04-01 13:24:19,548 - util.py[WARNING]: Running module scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3.5/site-packages/cloudinit/config/cc_scripts_user.py'>) failed
2019-04-01 13:24:19,548 - util.py[DEBUG]: Running module scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3.5/site-packages/cloudinit/config/cc_scripts_user.py'>) failed
    return self._runners.run(name, functor, args, freq, clear_on_fail)
    % (len(failed), len(attempted)))
RuntimeError: Runparts: 2 failures in 11 attempted commands
2019-04-01 13:24:19,614 - main.py[DEBUG]: Ran 16 modules with 1 failures

I cannot see any error in the metadata service logs and I can reach the server from my VM.

I used the Openstack (pike) guide to deploy it manually without using any other system. In my setup, I have nova, neutron(Self-Service), Glance, Horizon, Keystone, Heat and Magnum running.


Kind Regards,
Navdeep

-----Original Message-----
From: Bharat Kunwar <bharat at stackhpc.com> 
Sent: 01 April 2019 14:59
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: Mohammed Naser <mnaser at vexxhost.com>; openstack at lists.openstack.org
Subject: Re: [Magnum] Cluster Create failure

Hi Navdeep,

Have you tried logging into the master/worker node and gripping for `fail` inside /var/log/cloud-init.log and /var/log/cloud-init-output.log? Also how did you deploy your OpenStack services? 

Bharat

> On 1 Apr 2019, at 14:54, Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
> 
> Dear All,
> 
> My Kubernetes Cluster is timing out after 60 mins.
> 
> Following is the update I am getting in magnum.log:
> 
> {"stack": {"parent": null, "disable_rollback": true, "description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n", "parameters": {"magnum_url": "http://10.68.48.4:9511/v1", "kube_tag": "v1.11.6", "http_proxy": "", "cgroup_driver": "cgroupfs", "registry_container": "container", "kubernetes_port": "6443", "calico_kube_controllers_tag": "v1.0.3", "octavia_enabled": "False", "etcd_volume_size": "0", "kube_dashboard_enabled": "True", "master_flavor": "medium", "etcd_tag": "v3.2.7", "kube_version": "v1.11.6", "k8s_keystone_auth_tag": "1.13.0", "kube_service_account_private_key": "******", "keystone_auth_enabled": "True", "cloud_provider_tag": "v0.2.0", "ca_key": "******", "tiller_enabled": "False", "registry_enabled": "False", "verify_ca": "True", "password": "******", "dns_service_ip": "10.254.0.10", "ssh_key_name": "magnum_key", "flannel_tag": "v0.10.0-amd64", "flannel_network_subnetlen": "24", "dns_nameserver": "8.8.8.8", "number_of_masters": "1", "wait_condition_timeout": "6000", "portal_network_cidr": "10.254.0.0/16", "admission_control_list": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota", "pods_network_cidr": "10.100.0.0/16", "ingress_controller": "", "external_network": "751ae6e5-71af-4f78-b846-b0e1843093c8", "docker_volume_type": "", "registry_port": "5000", "tls_disabled": "False", "trust_id": "******", "swift_region": "", "influx_grafana_dashboard_enabled": "False", "volume_driver": "", "kubescheduler_options": "", "calico_tag": "v2.6.7", "loadbalancing_protocol": "TCP", "cloud_provider_enabled": "True", "OS::stack_id": "06c05715-ac05-4287-905c-38f1964f09fe", "flannel_cni_tag": "v0.3.0", "prometheus_monitoring": "False", "kubelet_options": "", "fixed_network": "", "kube_dashboard_version": "v1.8.3", "trustee_username": "d7ff417e-85b6-4b9a-94c3-211e7b830a51_4c6bc4445c764249921a0a6e40b192dd", "availability_zone": "", "server_image": "fedora-feduser-atomic", "flannel_network_cidr": "10.100.0.0/16", "cert_manager_api": "False", "minion_flavor": "medium", "kubeproxy_options": "", "calico_cni_tag": "v1.11.2", "cluster_uuid": "d7ff417e-85b6-4b9a-94c3-211e7b830a51", "grafana_admin_passwd": "******", "flannel_backend": "udp", "trustee_domain_id": "ac26210ad4f74217b3abf28a9b5cf56d", "fixed_subnet": "", "https_proxy": "", "username": "admin", "insecure_registry_url": "", "docker_volume_size": "0", "grafana_tag": "5.1.5", "kube_allow_priv": "true", "node_problem_detector_tag": "v0.6.2", "docker_storage_driver": "overlay2", "project_id": "4c6bc4445c764249921a0a6e40b192dd", "registry_chunksize": "5242880", "trustee_user_id": "d1983ea926c34536aabc8d50a85503e8", "container_infra_prefix": "", "number_of_minions": "1", "tiller_tag": "v2.12.3", "auth_url": "http://pluto:5000/v3", "registry_insecure": "True", "tiller_namespace": "magnum-tiller", "prometheus_tag": "v1.8.2", "OS::project_id": "4c6bc4445c764249921a0a6e40b192dd", "kubecontroller_options": "", "fixed_network_cidr": "10.0.0.0/24", "kube_service_account_key": "******", "ingress_controller_role": "ingress", "region_name": "RegionOne", "kubeapi_options": "", "openstack_ca": "******", "trustee_password": "******", "nodes_affinity_policy": "soft-anti-affinity", "minions_to_remove": "", "octavia_ingress_controller_tag": "1.13.2-alpha", "OS::stack_name": "kubernetes-cluster-wwmvqecjiznb", "system_pods_timeout": "5", "system_pods_initial_delay": "30", "dns_cluster_domain": "cluster.local", "calico_ipv4pool": "192.168.0.0/16", "network_driver": "flannel", "monitoring_enabled": "False", "heat_container_agent_tag": "stein-dev", "no_proxy": "", "discovery_url": "https://discovery.etcd.io/b8fe011e8b281615904de97ee05511a7"}, "deletion_time": null, "stack_name": "kubernetes-cluster-wwmvqecjiznb", "stack_user_project_id": "8204d11826fb4253ae7c9063306cb4e1", "tags": null, "creation_time": "2019-04-01T13:19:53Z", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-wwmvqecjiznb/06c05715-ac05-4287-905c-38f1964f09fe", "rel": "self"}], "capabilities": [], "notification_topics": [], "timeout_mins": 60, "stack_status": "CREATE_IN_PROGRESS", "stack_owner": null, "updated_time": null, "id": "06c05715-ac05-4287-905c-38f1964f09fe", "stack_status_reason": "Stack CREATE started", "template_description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n"}}
> 
> I am not sure how to triage this issue as I cannot see any errors in heat.log as well. 
> Even I can see both Master and Minion node running but the task errors out during OS::Heat::SoftwareDeployment in kube_cluster_deploy and OS::Heat::ResourceGroup in kube_minions
> 
> I don't have much experience with Kubernetes clusters as well so please forgive me if I am raising any silly queries.
> 
> Kind Regards,
> Navdeep
> 



From mbooth at redhat.com  Mon Apr  1 14:23:03 2019
From: mbooth at redhat.com (Matthew Booth)
Date: Mon, 1 Apr 2019 14:23:03 +0000
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
Message-ID: <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>

On Sat, 30 Mar 2019 at 08:32, Michael Still <mikal at stillhq.com> wrote:
>
> On Sat., 30 Mar. 2019, 6:28 pm Thierry Carrez, <thierry at openstack.org> wrote:
>>
>> Michael Still wrote:
>> > The reality is that privsep was always going to be a process. It's taken
>> > more than 80 patches to get close to removing rootwrap.
>> >
>> > There are other advantages to removing rootwrap, mainly around
>> > performance, the integration of library code, and general
>> > non-bonkersness (cat to tee to write to a file as root), etc.
>> >
>> > There is president in the code to mark calls as undesirable, and others
>> > could be marked like that as well, but ultimately someone needs to do an
>> > audit and fix things... That's more than one person can reasonably do.
>> >
>> > So, who wants to help try and improve this? Patches welcome.
>>
>> It's been on my priority-2 TODO list for a while to help with that...
>> Now if people would stop adding to my priority-1 TODO list...
>>
>> Agree that's definitely more than a one-person job, but migrating a
>> specific call is also a reasonably self-contained unit of work that (1)
>> does not require a deep understanding of all the code around it, and (2)
>> does not commit you for a lifelong feature maintenance duty... So maybe
>> it would be a good thing to suggest newcomers / students to get a poke
>> at? I'm happy to help with the reviewing if we can come up with a topic
>> name that helps finding those.
>
>
> One concern I have is that I am not sure it's always as simple as it looks. For example, we could enforce that device files are always in /dev, but is that always true on all architectures with all hypervisors? How do we know that?

I think the answer here is that we don't have privsep functions like
that *at all*. So instead of a generic
privsep.data.discombobulate(device) you have
privsep.libvirt.volume.foo.discombobulate(volume). I mentioned this as
a general principal in my original mail which has since been snipped,
that we should probably *never* pass a reference to a system resource
(the most obvious example being a path) to a privsep function.
Instead, privsep has its own config and can work that out for itself.
This does mean a proliferation of specific privsep functions over a
few generic ones, but that's how the security model works. In general
we should expect classes to have a shadow privsep class containing
security-sensitive logic.

> We could add enforcement and at the same time add a workaround flag to turn it off, which is immediately deprecated so people have a release to notice a breakage. Do we do that per enforcement rule? That's a lot of flags!
>
> Finally, the initial forklift has been a series of relatively simple code swaps (which is really the root of Mr Booth's concern). Even with taking the easy path there haven't been heaps of volunteers helping and some of this code has been in review for quite a long time. Do we really think that volunteers are going to show up now?

Exactly. Most folks acknowledge the importance of this stuff, but not
to the extend of prioritising it for review: it's boring, involves
large code churn, and doesn't immediately add anything obvious. Worse
the code churn means that unless it lands quickly it's very soon going
to be in merge conflict hell. Writing the code is likely the easy bit.
Unless we can agree on this as a priority theme for a while I don't
see us making any progress on it in practise.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)


From ed at leafe.com  Mon Apr  1 14:51:12 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 1 Apr 2019 09:51:12 -0500
Subject: [placement] update 19-12
In-Reply-To: <alpine.OSX.2.21.1903291407130.89401@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1903291407130.89401@cdent-a01.vmware.com>
Message-ID: <AFCAAFE6-9C8C-4E44-A1A5-0852B986E20C@leafe.com>

On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> * Some [image type traits](https://review.openstack.org/648147) have
>  merged (to be used in a nova-side request pre-filter), but the
>  change  has exposed an issue we'll need to resolve: os-traits and
>  os-resource-classes are under the cycle-with-intermediary style
>  release which means that at this time in the cycle it is difficult
>  to make a release which can delay work. We could switch to
>  independent. This would make sense for libraries that are
>  basically lists of strings. It's hard to break that.

Especially since strings cannot be removed. +1 to moving to independent releases.

> We could also
>  investigate making os-traits and os-resource-classes
>  required-projects in job templates in zuul. This would allow them
>  to be "tox siblings". Or we could wait. Please express an
>  opinion if you have one.

I googled ’tox siblings’ and got a lot of family relationship advice. So no, I have no opinion on this.

> We should do a bug squash day at some point. Should we wait until
> after the PTG or no?

I don’t think PTG makes a difference. Let’s wait until after Stein is released, and figure out a good date then.


-- Ed Leafe







From cdent+os at anticdent.org  Mon Apr  1 14:55:44 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 1 Apr 2019 15:55:44 +0100 (BST)
Subject: [placement] update 19-12
In-Reply-To: <AFCAAFE6-9C8C-4E44-A1A5-0852B986E20C@leafe.com>
References: <alpine.OSX.2.21.1903291407130.89401@cdent-a01.vmware.com>
 <AFCAAFE6-9C8C-4E44-A1A5-0852B986E20C@leafe.com>
Message-ID: <alpine.OSX.2.21.1904011555250.29870@cdent-a01.vmware.com>

On Mon, 1 Apr 2019, Ed Leafe wrote:
> On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>> We could also
>>  investigate making os-traits and os-resource-classes
>>  required-projects in job templates in zuul. This would allow them
>>  to be "tox siblings". Or we could wait. Please express an
>>  opinion if you have one.
>
> I googled ’tox siblings’ and got a lot of family relationship advice. So no, I have no opinion on this.

https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling-requirements


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From skaplons at redhat.com  Mon Apr  1 14:56:45 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 1 Apr 2019 16:56:45 +0200
Subject: [dev][neutron] CI broken
In-Reply-To: <1554126316.4997.15.camel@offenerstapel.de>
References: <A1F14623-7C4E-4F98-BB0B-C3A51280874A@redhat.com>
 <1554126316.4997.15.camel@offenerstapel.de>
Message-ID: <FDD4C27E-CDB3-4D97-86F4-C84E0B837A13@redhat.com>

Hi,

Thx Jens for pointing to the culprit of the issue.

My patch for neutron-tempest-plugin is now merged so neutron jobs should be fine now and You can recheck Your patches now :)

> Wiadomość napisana przez Jens Harbott <frickler at offenerstapel.de> w dniu 01.04.2019, o godz. 15:45:
> 
> On Mon, 2019-04-01 at 08:29 +0200, Slawomir Kaplonski wrote:
>> Hi,
>> 
>> Just FYI, since few days we have broken neutron-tempest-plugin-
>> designate-scenario job and it is failing 100% times. Bug is reported
>> in [1].
>> If this job failed on Your patch, please don’t recheck as it will not
>> solve the problem.
>> 
>> [1] https://bugs.launchpad.net/neutron/+bug/1822453
> 
> Actually a patch in devstack caused this regression, affecting all jobs
> that use multiple tempest plugins. A fix for that is being reviewed,
> see the above bug report for details.
> 
> Jens
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From mriedemos at gmail.com  Mon Apr  1 14:57:23 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 1 Apr 2019 07:57:23 -0700
Subject: [nova][CI] nova-live-migration failing
In-Reply-To: <F8C1474F-FEA3-4668-B55E-889DDAB71325@fried.cc>
References: <F8C1474F-FEA3-4668-B55E-889DDAB71325@fried.cc>
Message-ID: <64c8c2ec-3136-baae-31e6-703106a478df@gmail.com>

On 3/31/2019 4:00 AM, Eric Fried wrote:
> I've noticed the nova-live-migration job failing consistently over the weekend on clearly unrelated patches. Haven't had a chance to look into it at all. Please consider holding off blind rechecks for a bit.

https://review.openstack.org/#/c/649036/ fixes it, so avoid rechecks 
until that has merged.

-- 

Thanks,

Matt


From florian.engelmann at everyware.ch  Mon Apr  1 15:40:57 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Mon, 1 Apr 2019 17:40:57 +0200
Subject: [nova] retire a flavor
In-Reply-To: <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
Message-ID: <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>

Hi,

as far as I tested it is not possible to change a flavor from public to 
private. Managing access to flavors on a project basis might be an 
option for a private cloud but not for a public one.

There are a lot of unit tests about:

             "alias": "OS-FLV-DISABLED",
             "description": "Support to show the disabled status of a 
flavor.",

What's that feature for? How does it work? Is this ongoing?

I think we need some method to retire images and flavors.

All the best,
Florian

Am 3/31/19 um 11:57 AM schrieb Sean Mooney:
> On Fri, 2019-03-29 at 11:25 -0500, Eric Fried wrote:
>> Florian-
>>
>> You can definitely delete a flavor [1].
>>
>> Don't worry about it affecting existing instances that were created with
>> that flavor: nova stores a copy of the flavor with the instance itself
>> so the information is preserved.
>>
>> Thanks for the question!
> the other option if you want to keep the flavor but not make it usable by
> new instances in general is to use the os-flavor-access api.
> https://developer.openstack.org/api-ref/compute/?expanded=#flavors-access-flavors-os-flavor-access
> This allows you to make a flavor private and control what project can use it.
> 
> 
> unfortunetly we seam to have almost no documentation for this however that is what the --project argument
> to openstack flavor set is used to contol.
> https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/flavor.html#flavor-set
> e.g. openstack flavor set --project <my admin/hidden project> <flavor i want to retire>
> 
> this will allow you to retire the flavor more selectively.
> so if you have a important customer that needs a little more time to move to your new flavor offerings
> you can similarly add them to the now private flavor to aide there transition before you actually delete it.
> 
> as efried said you can delete the flavor without issue so if you are not worred about it breaking
> ci or other automation and can simply remove the flavor that hsould be safe to do so.
>>
>> -efried
>>
>> [1]
>> https://docs.openstack.org/nova/latest/admin/flavors.html#delete-a-flavor
>>
>> On 3/29/19 10:43 AM, Florian Engelmann wrote:
>>> Hi,
>>>
>>> I would like to retire old flavors we don't want to be use any more. I
>>> guess deleting is the wrong way to retire flavors? I was not able to
>>> find any documentation about how the life-cycle of a flavor works.
>>>
>>> Any help is very welcome.
>>>
>>> All the best,
>>> Florian
>>
>>
> 
> 

-- 

EveryWare AG
Florian Engelmann
Senior UNIX Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: mailto:florian.engelmann at everyware.ch
web: http://www.everyware.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/9c4a3048/attachment-0001.bin>

From cdent+os at anticdent.org  Mon Apr  1 15:50:23 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 1 Apr 2019 16:50:23 +0100 (BST)
Subject: [placement][nova][infra] best way to add to required-projects on
 several zuul jobs
Message-ID: <alpine.OSX.2.21.1904011637160.29870@cdent-a01.vmware.com>


The extraction of placement led to the development of os-traits and
os-resource-classes [1,2] which are python modules which contain
symbols that represent "blessed" strings used as traits and resource
classes in at least nova, placement and neutron, but plenty of
others soon.

These symbols are actively used when developing new features, so
being able to access the python modules via tox-siblings [3] in both
unit and functional tests, from multiple projects, would be grand:
developers could depends-on changes in modules as they are being
developed, or rely on symbols in master of the modules before there
is a release to pypi.

What is the best way to do this? Many projects are using templates
like "openstack-python-jobs" but as far as I can tell there's no
easy way to override just a part of a template in a local .zuul.yaml
and the usual thing is to create another template such as
"openstack-python-jobs-neutron" which re-lists all the jobs within,
and adds a custom required-projects to each job.

Is this (creating another template) the right/best way to add to
required-projects for this kind of thing? If not, what's the best
way? Presumably it is better to create a centralized job or template
when >1 projects will need the additional libraries?

Ideas? Thanks.

[1] https://docs.openstack.org/os-traits/latest/
[2] https://docs.openstack.org/os-resource-classes/latest/
[3] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling-requirements



-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From navdeep.uniyal at bristol.ac.uk  Mon Apr  1 16:14:35 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Mon, 1 Apr 2019 16:14:35 +0000
Subject: [Magnum] Cluster Create failure
In-Reply-To: <AM6PR06MB58794B0C3CA5AEEE5AE5CEFDDE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879BCCDEBCEA70CA704D7B9DE580@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FA4ACC0B-E2B8-42E4-B4B5-2B2301743BD7@stackhpc.com>
 <AM6PR06MB587923F5E56DAA1BC825B7C7DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <BA0C1973-9CF7-48DE-A95D-2312A43D0F2E@stackhpc.com>
 <AM6PR06MB5879B08F8D31E08904056292DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <FDBA865F-9F3D-4B1C-98C7-78E050066FC7@stackhpc.com>
 <AM6PR06MB5879A7A3C0DC6A49B72B8BE3DE590@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAEs876gYAQQ3+RXe0SdiZLTTZaCJLMSSmqNTuj0BUpDJ9dcVew@mail.gmail.com>
 <AM6PR06MB5879B7A1A1A0B9075128A793DE5A0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB5879EF9DEA3A344EA66FA7E5DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <29BAEF27-99CE-410D-B9EF-C3E5851C9D26@stackhpc.com>
 <AM6PR06MB58794B0C3CA5AEEE5AE5CEFDDE550@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <AM6PR06MB5879A9B43C8AF470911301D9DE550@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Bharat,

Adding to my previous email, I did some changes and cloud-init seems to be running fine (it was an issue with the image I was using).
However, now I am using the fedora-atomic image with 80GB disk, 4vCPUs and 4GB RAM. I am getting 'no space left errors'. 

[  213.443636] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.444282] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.postinst: Cannot open: No such file or directory
[  213.444696] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.445345] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.postrm: Cannot open: No such file or directory
[  213.445811] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.499407] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.shlibs: Cannot open: No such file or directory
[  213.499788] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.500409] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.symbols: Cannot open: No such file or directory
[  213.500822] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.501247] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.templates: Cannot open: No such file or directory
[  213.501644] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.502302] cloud-init[1307]: tar: var/lib/dpkg/info/libssl1.1\:amd64.triggers: Cannot open: No such file or directory
[  213.502784] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.503401] cloud-init[1307]: tar: var/lib/dpkg/info/libtalloc2\:amd64.list: Cannot open: No such file or directory
[  213.503833] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.504258] cloud-init[1307]: tar: var/lib/dpkg/info/libtalloc2\:amd64.md5sums: Cannot open: No such file or directory
[  213.504660] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.505286] cloud-init[1307]: tar: var/lib/dpkg/info/libtalloc2\:amd64.shlibs: Cannot open: No such file or directory
[  213.505692] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device
[  213.506358] cloud-init[1307]: tar: var/lib/dpkg/info/libtalloc2\:amd64.symbols: Cannot open: No such file or directory
[  213.506831] cloud-init[1307]: tar: var: Cannot mkdir: No space left on device

-----Original Message-----
From: Navdeep Uniyal 
Sent: 01 April 2019 15:19
To: 'Bharat Kunwar' <bharat at stackhpc.com>
Cc: Mohammed Naser <mnaser at vexxhost.com>; openstack at lists.openstack.org
Subject: RE: [Magnum] Cluster Create failure

Hi Bharat,

Thank you for your response.

I am getting following errors in my worker VM (Master VM has similar errors):

[feduser at kubernetes-cluster-wwmvqecjiznb-minion-0 ~]$ less /var/log/cloud-init.log | grep fail
2019-03-29 16:20:37,018 - cc_growpart.py[DEBUG]: '/' SKIPPED: device_part_info(/dev/mapper/atomicos-root) failed: /dev/mapper/atomicos-root not a partition
2019-03-29 16:20:37,219 - main.py[DEBUG]: Ran 14 modules with 0 failures
2019-03-29 16:20:38,450 - main.py[DEBUG]: Ran 7 modules with 0 failures
2019-03-29 16:20:39,501 - main.py[DEBUG]: Ran 16 modules with 0 failures
2019-04-01 13:21:07,978 - util.py[WARNING]: failed stage init-local
2019-04-01 13:21:07,978 - util.py[DEBUG]: failed stage init-local
2019-04-01 13:21:09,250 - url_helper.py[DEBUG]: Calling 'http://169.254.169.254/openstack' failed [0/-1s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /openstack (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67d6c50>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:09,252 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67eb588>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:10,255 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67eb2b0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:11,259 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67ebe10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:12,264 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f35f8>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:13,268 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [4/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f3e10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:14,272 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [5/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67fa668>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:16,278 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [7/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67f3550>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:18,283 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [9/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f6ea67ebe10>: Failed to establish a new connection: [Errno 101] Network is unreachable',))]
2019-04-01 13:21:36,442 - cc_growpart.py[DEBUG]: '/' SKIPPED: device_part_info(/dev/mapper/atomicos-root) failed: /dev/mapper/atomicos-root not a partition
2019-04-01 13:21:36,609 - main.py[DEBUG]: Ran 14 modules with 0 failures
2019-04-01 13:21:37,847 - main.py[DEBUG]: Ran 7 modules with 0 failures
2019-04-01 13:24:19,548 - util.py[WARNING]: Running module scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3.5/site-packages/cloudinit/config/cc_scripts_user.py'>) failed
2019-04-01 13:24:19,548 - util.py[DEBUG]: Running module scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3.5/site-packages/cloudinit/config/cc_scripts_user.py'>) failed
    return self._runners.run(name, functor, args, freq, clear_on_fail)
    % (len(failed), len(attempted)))
RuntimeError: Runparts: 2 failures in 11 attempted commands
2019-04-01 13:24:19,614 - main.py[DEBUG]: Ran 16 modules with 1 failures

I cannot see any error in the metadata service logs and I can reach the server from my VM.

I used the Openstack (pike) guide to deploy it manually without using any other system. In my setup, I have nova, neutron(Self-Service), Glance, Horizon, Keystone, Heat and Magnum running.


Kind Regards,
Navdeep

-----Original Message-----
From: Bharat Kunwar <bharat at stackhpc.com> 
Sent: 01 April 2019 14:59
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: Mohammed Naser <mnaser at vexxhost.com>; openstack at lists.openstack.org
Subject: Re: [Magnum] Cluster Create failure

Hi Navdeep,

Have you tried logging into the master/worker node and gripping for `fail` inside /var/log/cloud-init.log and /var/log/cloud-init-output.log? Also how did you deploy your OpenStack services? 

Bharat

> On 1 Apr 2019, at 14:54, Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
> 
> Dear All,
> 
> My Kubernetes Cluster is timing out after 60 mins.
> 
> Following is the update I am getting in magnum.log:
> 
> {"stack": {"parent": null, "disable_rollback": true, "description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n", "parameters": {"magnum_url": "http://10.68.48.4:9511/v1", "kube_tag": "v1.11.6", "http_proxy": "", "cgroup_driver": "cgroupfs", "registry_container": "container", "kubernetes_port": "6443", "calico_kube_controllers_tag": "v1.0.3", "octavia_enabled": "False", "etcd_volume_size": "0", "kube_dashboard_enabled": "True", "master_flavor": "medium", "etcd_tag": "v3.2.7", "kube_version": "v1.11.6", "k8s_keystone_auth_tag": "1.13.0", "kube_service_account_private_key": "******", "keystone_auth_enabled": "True", "cloud_provider_tag": "v0.2.0", "ca_key": "******", "tiller_enabled": "False", "registry_enabled": "False", "verify_ca": "True", "password": "******", "dns_service_ip": "10.254.0.10", "ssh_key_name": "magnum_key", "flannel_tag": "v0.10.0-amd64", "flannel_network_subnetlen": "24", "dns_nameserver": "8.8.8.8", "number_of_masters": "1", "wait_condition_timeout": "6000", "portal_network_cidr": "10.254.0.0/16", "admission_control_list": "NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota", "pods_network_cidr": "10.100.0.0/16", "ingress_controller": "", "external_network": "751ae6e5-71af-4f78-b846-b0e1843093c8", "docker_volume_type": "", "registry_port": "5000", "tls_disabled": "False", "trust_id": "******", "swift_region": "", "influx_grafana_dashboard_enabled": "False", "volume_driver": "", "kubescheduler_options": "", "calico_tag": "v2.6.7", "loadbalancing_protocol": "TCP", "cloud_provider_enabled": "True", "OS::stack_id": "06c05715-ac05-4287-905c-38f1964f09fe", "flannel_cni_tag": "v0.3.0", "prometheus_monitoring": "False", "kubelet_options": "", "fixed_network": "", "kube_dashboard_version": "v1.8.3", "trustee_username": "d7ff417e-85b6-4b9a-94c3-211e7b830a51_4c6bc4445c764249921a0a6e40b192dd", "availability_zone": "", "server_image": "fedora-feduser-atomic", "flannel_network_cidr": "10.100.0.0/16", "cert_manager_api": "False", "minion_flavor": "medium", "kubeproxy_options": "", "calico_cni_tag": "v1.11.2", "cluster_uuid": "d7ff417e-85b6-4b9a-94c3-211e7b830a51", "grafana_admin_passwd": "******", "flannel_backend": "udp", "trustee_domain_id": "ac26210ad4f74217b3abf28a9b5cf56d", "fixed_subnet": "", "https_proxy": "", "username": "admin", "insecure_registry_url": "", "docker_volume_size": "0", "grafana_tag": "5.1.5", "kube_allow_priv": "true", "node_problem_detector_tag": "v0.6.2", "docker_storage_driver": "overlay2", "project_id": "4c6bc4445c764249921a0a6e40b192dd", "registry_chunksize": "5242880", "trustee_user_id": "d1983ea926c34536aabc8d50a85503e8", "container_infra_prefix": "", "number_of_minions": "1", "tiller_tag": "v2.12.3", "auth_url": "http://pluto:5000/v3", "registry_insecure": "True", "tiller_namespace": "magnum-tiller", "prometheus_tag": "v1.8.2", "OS::project_id": "4c6bc4445c764249921a0a6e40b192dd", "kubecontroller_options": "", "fixed_network_cidr": "10.0.0.0/24", "kube_service_account_key": "******", "ingress_controller_role": "ingress", "region_name": "RegionOne", "kubeapi_options": "", "openstack_ca": "******", "trustee_password": "******", "nodes_affinity_policy": "soft-anti-affinity", "minions_to_remove": "", "octavia_ingress_controller_tag": "1.13.2-alpha", "OS::stack_name": "kubernetes-cluster-wwmvqecjiznb", "system_pods_timeout": "5", "system_pods_initial_delay": "30", "dns_cluster_domain": "cluster.local", "calico_ipv4pool": "192.168.0.0/16", "network_driver": "flannel", "monitoring_enabled": "False", "heat_container_agent_tag": "stein-dev", "no_proxy": "", "discovery_url": "https://discovery.etcd.io/b8fe011e8b281615904de97ee05511a7"}, "deletion_time": null, "stack_name": "kubernetes-cluster-wwmvqecjiznb", "stack_user_project_id": "8204d11826fb4253ae7c9063306cb4e1", "tags": null, "creation_time": "2019-04-01T13:19:53Z", "links": [{"href": "http://pluto:8004/v1/4c6bc4445c764249921a0a6e40b192dd/stacks/kubernetes-cluster-wwmvqecjiznb/06c05715-ac05-4287-905c-38f1964f09fe", "rel": "self"}], "capabilities": [], "notification_topics": [], "timeout_mins": 60, "stack_status": "CREATE_IN_PROGRESS", "stack_owner": null, "updated_time": null, "id": "06c05715-ac05-4287-905c-38f1964f09fe", "stack_status_reason": "Stack CREATE started", "template_description": "This template will boot a Kubernetes cluster with one or more minions (as specified by the number_of_minions parameter, which defaults to 1).\n"}}
> 
> I am not sure how to triage this issue as I cannot see any errors in heat.log as well. 
> Even I can see both Master and Minion node running but the task errors out during OS::Heat::SoftwareDeployment in kube_cluster_deploy and OS::Heat::ResourceGroup in kube_minions
> 
> I don't have much experience with Kubernetes clusters as well so please forgive me if I am raising any silly queries.
> 
> Kind Regards,
> Navdeep
> 



From smooney at redhat.com  Mon Apr  1 16:35:34 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 01 Apr 2019 17:35:34 +0100
Subject: [nova] retire a flavor
In-Reply-To: <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
Message-ID: <ac730819a9ea080e2c7d0fb1ff57b630eb59c76e.camel@redhat.com>

On Mon, 2019-04-01 at 17:40 +0200, Florian Engelmann wrote:
> Hi,
> 
> as far as I tested it is not possible to change a flavor from public to 
> private. Managing access to flavors on a project basis might be an 
> option for a private cloud but not for a public one.
if you cannot retrict a flavor to a singel porject in a public cloud
you also can never delete a flavor in a public cloud.

from an api perspective it will have the same effect.
> 
> There are a lot of unit tests about:
> 
>              "alias": "OS-FLV-DISABLED",
>              "description": "Support to show the disabled status of a 
> flavor.",
> 
> What's that feature for? How does it work? Is this ongoing?
> 
> I think we need some method to retire images and flavors.
well it depend on what you mean by retire.
my definition of retire means it still exist but is no longer
requestable for new instances. idealy if you retire something from
service it should be possible to reinstate it again even if that is unlikely.

if your definitoin of retire delete it then you can certenly do that.
restoring a delete flavor is technicaly possible as you cna just recreated it
but its harder to do that then unrestrict the acess to the flavor.

but yes we shoudl have a documented procedure to "retire" a flavor  or image in the
admin guide somewhere but we also need to define what that means first and that might
change form deployment to deployment at least in some cases.


> 
> All the best,
> Florian
> 
> Am 3/31/19 um 11:57 AM schrieb Sean Mooney:
> > On Fri, 2019-03-29 at 11:25 -0500, Eric Fried wrote:
> > > Florian-
> > > 
> > > You can definitely delete a flavor [1].
> > > 
> > > Don't worry about it affecting existing instances that were created with
> > > that flavor: nova stores a copy of the flavor with the instance itself
> > > so the information is preserved.
> > > 
> > > Thanks for the question!
> > 
> > the other option if you want to keep the flavor but not make it usable by
> > new instances in general is to use the os-flavor-access api.
> > https://developer.openstack.org/api-ref/compute/?expanded=#flavors-access-flavors-os-flavor-access
> > This allows you to make a flavor private and control what project can use it.
> > 
> > 
> > unfortunetly we seam to have almost no documentation for this however that is what the --project argument
> > to openstack flavor set is used to contol.
> > https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/flavor.html#flavor-set
> > e.g. openstack flavor set --project <my admin/hidden project> <flavor i want to retire>
> > 
> > this will allow you to retire the flavor more selectively.
> > so if you have a important customer that needs a little more time to move to your new flavor offerings
> > you can similarly add them to the now private flavor to aide there transition before you actually delete it.
> > 
> > as efried said you can delete the flavor without issue so if you are not worred about it breaking
> > ci or other automation and can simply remove the flavor that hsould be safe to do so.
> > > 
> > > -efried
> > > 
> > > [1]
> > > https://docs.openstack.org/nova/latest/admin/flavors.html#delete-a-flavor
> > > 
> > > On 3/29/19 10:43 AM, Florian Engelmann wrote:
> > > > Hi,
> > > > 
> > > > I would like to retire old flavors we don't want to be use any more. I
> > > > guess deleting is the wrong way to retire flavors? I was not able to
> > > > find any documentation about how the life-cycle of a flavor works.
> > > > 
> > > > Any help is very welcome.
> > > > 
> > > > All the best,
> > > > Florian
> > > 
> > > 
> > 
> > 
> 
> 



From massimo.sgaravatto at gmail.com  Mon Apr  1 16:39:41 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Mon, 1 Apr 2019 18:39:41 +0200
Subject: [nova] retire a flavor
In-Reply-To: <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
Message-ID: <CALaZjRH07fHY-jw+J+VjvDc84ssk4pYxtOG5Lp6SdMphEURBkw@mail.gmail.com>

On Fri, Mar 29, 2019 at 5:27 PM Eric Fried <openstack at fried.cc> wrote:

> Florian-
>
> You can definitely delete a flavor [1].
>
> Don't worry about it affecting existing instances that were created with
> that flavor: nova stores a copy of the flavor with the instance itself
> so the information is preserved.
>


Is this the case also if the extra_specs field attribute was set for the
flavor and the AggregateInstanceExtraSpecsFilter filter is used ?
Aren't there problems rescheduling an instance created with that flavor ?


Thanks, Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/3788b9c3/attachment.html>

From mriedemos at gmail.com  Mon Apr  1 16:46:41 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 1 Apr 2019 09:46:41 -0700
Subject: [nova] retire a flavor
In-Reply-To: <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
Message-ID: <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>

On 4/1/2019 8:40 AM, Florian Engelmann wrote:
> There are a lot of unit tests about:
> 
>              "alias": "OS-FLV-DISABLED",
>              "description": "Support to show the disabled status of a 
> flavor.",
> 
> What's that feature for? How does it work? Is this ongoing?

The flavor.disabled attribute was added a long long time ago and has no 
external API hook or even nova-manage CLI to change the value of that 
attribute, so if you want to set it you have to do it in the database 
manually (yes, it sucks, it's half-baked, and I don't know if we should 
just remove it or officially support it in the API).

> 
> I think we need some method to retire images and flavors.

Agreed, please report a nova bug for retiring a flavor.

As for retiring an image, I already pointed out there is a story for that:

https://storyboard.openstack.org/#!/story/2004892

But that's not really a nova bug.

-- 

Thanks,

Matt


From mriedemos at gmail.com  Mon Apr  1 16:48:43 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 1 Apr 2019 09:48:43 -0700
Subject: [nova] retire a flavor
In-Reply-To: <CALaZjRH07fHY-jw+J+VjvDc84ssk4pYxtOG5Lp6SdMphEURBkw@mail.gmail.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <CALaZjRH07fHY-jw+J+VjvDc84ssk4pYxtOG5Lp6SdMphEURBkw@mail.gmail.com>
Message-ID: <bddf77f3-f61c-a262-20a8-e9c1de2cb4ed@gmail.com>

On 4/1/2019 9:39 AM, Massimo Sgaravatto wrote:
> Is this the case also if the extra_specs field attribute was set for the 
> flavor and the AggregateInstanceExtraSpecsFilter filter is used ?
> Aren't there problems rescheduling an instance created with that flavor ?

Rescheduling uses the RequestSpec, which contains a copy of the Flavor 
from the last resize or when the server was initially created. The 
RequestSpec is around for the lifetime of the instance, so you can 
delete the original flavor and still reschedule.

Now if you created a server or resized a server with a given flavor, and 
then modified that flavors extra_specs, that won't be reflected back in 
the persisted RequestSpec, but it's probably not a great idea in general 
to modify extra_specs on public flavors which are already being used.

-- 

Thanks,

Matt


From mnaser at vexxhost.com  Mon Apr  1 17:31:57 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Mon, 1 Apr 2019 13:31:57 -0400
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <83ea0995-c5be-4f5a-208f-25c81a29657f@gmail.com>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
 <83ea0995-c5be-4f5a-208f-25c81a29657f@gmail.com>
Message-ID: <CAEs876hBeLUf80U+TK0Vc3_Rb2KO+aXu_AOUMkZ8RVSQjpO1LA@mail.gmail.com>

On Mon, Apr 1, 2019 at 8:10 AM Jay Pipes <jaypipes at gmail.com> wrote:
>
> On 04/01/2019 04:43 AM, Jens Harbott wrote:
> > On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
> >> Hi,
> >>
> >> During the summit in Tokyo (if I remember well), Sean Dague lead a
> >> discussion about removing the need for having 3 endpoints per
> >> service. I
> >> was very excited about the proposal, and it's IMO a shame it hasn't
> >> been
> >> implemented. Everyone in the room agreed. Here the content of the
> >> discussion as I remember it:
> >>
> >> <discussion in Tokyo>
> >> 1/ The only service that needed the admin endpoint was Keystone. This
> >> requirement is now gone. So we could get rid of the admin endpoint
> >> all
> >> together.
> >>
> >> 2/ The need for an interal vs public endpoint was only needed for
> >> accounting (of for example bandwidth when uploading to Glance), but
> >> this
> >> could be work-around by operators by using intelligent routing. So we
> >> wouldn't need the internal endpoint.
> >>
> >> This makes us only need the public endpoint, and that's it.
> >>
> >> Then, there are these %(tenant_id)s bits in the endpoints which are
> >> also
> >> very much annoying, and could be removed if the clients were smarter.
> >> These are still needed, apparently, for:
> >> - cinder
> >> - swift
> >> - heat
> >> </discussion in Tokyo>
> >>
> >> Is anyone planning to implement (at least some parts of) the above?
> >
> > For me as an operator, the distinction between internal and public
> > endpoints is helpful, as it allows to easily set up extended filtering
> > or rate limiting for public services without affecting internal API
> > calls, which in most deployments cause the majority of requests.
> >
> > I'm not sure what "intelligent routing" is meant to be, but it sounds
> > more complicated and unstable than the current solution.
>
> Maybe Thomas was referring to having Keystone just return a single set
> of endpoints depending on the source CIDR.
>
> Or maybe he is referring to performing rate-limiting using a lower-level
> tool that was purpose-built for it -- something like iptables?
>
> i.e. ACCEPT all new connections from your private subnet/CIDR and jump
> all new connections not in your private subnet to a RATE-LIMIT chain
> that applies rate-limiting thresholds.
>
> In other words, use a single HTTP endpoint and do the rate-limiting in
> the Linux kernel instead of higher-level applications.
>
> Related: this is why having "quotas" for things like # of metadata items
> in Nova was always a terrible "feature" that was abusing the quota
> system as a terrible rate-limiting middleware when things like iptables
> or tc were a more appropriate solution.

I'm personally a fan of single endpoint, you can use your own methods to
determine if traffic is coming from a certain place.

Anyways, in all of OpenStack's APIs, there is zero assumption that the API
you talk to will be different depending on the endpoint.  I think Keystone had
that assumption but that was ripped out.

In our case, we deploy a single SSL secured endpoint which all public users
and internal services talk to.  If our services are doing something that needs
to be rate limited, we probably need to revisit that :)

+1 for me, however, I know some people use this type of thing for "network
isolation".  However, I think this issue can be delegated a layer lower (split
DNS, hard-coding a different URL).

> Best,
> -jay
>
> > Big +1 on dropping the admin endpoint though, now that keystone doesn't
> > need it anymore.
> >
> > Jens
> >
>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From mnaser at vexxhost.com  Mon Apr  1 17:33:05 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Mon, 1 Apr 2019 13:33:05 -0400
Subject: [trove] Trove for Train
In-Reply-To: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
Message-ID: <CAEs876h5nOwFicePxDqxrqp0rvhMn0YYBoM=T9d3ajOFho2Jrg@mail.gmail.com>

On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong at gmail.com> wrote:
>
> Hi,
>
> I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev cycle. Since the master branch is open for contribution and review, for those who care about Trove, here are several things I'd like to bring to your attention and most importantly, need your feedback.
>
> - Deprecate nova-network.
>
>   As I mentioned in the candidacy, The nova-network related code is spread in the repo, which makes it very difficult for new feature implementation and bugfix. Considering nova-network was deprecated in the OpenStack Newton release, I propose we also deprecate nova-network support in Trove and remove after several cycles according to the deprecation policy of the community. I'm not sure if there is still anyone using nova-network for Trove, especially in production.  If yes, please reply to this email.
>
> - Create service VM in admin project by default
>
>   Currently, Trove has configuration support to create the db instance in the admin project, which I think should be the default deployment model to reduce the security risk given all the db instances are communicating with RabbitMQ in the control plane.
>
> - Remove SecurityGroup API extension
>
>   TBH, I don't know when and why that extension was added in Trove but since it's not included in Trove API document(https://developer.openstack.org/api-ref/database/), I assume there is on one relies on that in production, so should be safe to remove.
>
> - Remove SecurityGroup related database model
>
>   I don't have the history development background in my mind, but IMHO, i don't think it's reasonable for Trove to maintain such information in db.
>
> - Security group management enhancement
>
>   Removing the API extension and database model doesn't mean Trove shouldn't support security group for the db instance, on the contrary, security should always be the first thing we consider for new features. The two tasks above are actually prerequisites for this one. In order to make it easy to maintain and as more secure as possible, Trove is not going to allow the end user to manipulate the security group associated with db instance. Trove will try to provide as more information as possible to make the debugging and performance tuning easy.
>
> - Monitoring capability
>
>   Currently, there is no monitoring capability support in Trove, and I think that's the only main part missing for Trove to be running in production. I don't have a full picture in mind now but will try to figure out how to achieve that.
>
> - Priorities of the previous dev cycles
>
>   Of course, I shouldn't put the previous dev cycle priorities away from the track, e.g. the Stein dev cycle priorities are well documented here https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking
>
> As Trove project has been experiencing some up and downs in the past, but it's still very useful in some deployment use cases and has some advantages over the container deployment model. As you could guess, the reason I raised my hand to lead Trove is that we(Catalyst Cloud) have been deploying Trove in production, so all those things are aiming at making Trove production ready, not only for private cloud but also for the public.
>
> If you have any concerns related to what's mentioned above, please don't hesitate to reply. Alternately, I'm always in the #openstack-trove IRC channel and could answer any questions during the working hours of UTC+12.

I think another thing is the deployment model of relying on RabbitMQ
to talk to the control plane.  That has been the biggest sticking
point for deployers.  I think adopting something similar to the
Octavia service VM model with public/private key and HTTP API might be
far more successful.

> I really appreciate any feedback from the community.
>
> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From openstack at nemebean.com  Mon Apr  1 18:06:00 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 1 Apr 2019 13:06:00 -0500
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
Message-ID: <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>



On 4/1/19 9:23 AM, Matthew Booth wrote:
> On Sat, 30 Mar 2019 at 08:32, Michael Still <mikal at stillhq.com> wrote:
>>
>> On Sat., 30 Mar. 2019, 6:28 pm Thierry Carrez, <thierry at openstack.org> wrote:
>>>
>>> Michael Still wrote:
>>>> The reality is that privsep was always going to be a process. It's taken
>>>> more than 80 patches to get close to removing rootwrap.
>>>>
>>>> There are other advantages to removing rootwrap, mainly around
>>>> performance, the integration of library code, and general
>>>> non-bonkersness (cat to tee to write to a file as root), etc.
>>>>
>>>> There is president in the code to mark calls as undesirable, and others
>>>> could be marked like that as well, but ultimately someone needs to do an
>>>> audit and fix things... That's more than one person can reasonably do.
>>>>
>>>> So, who wants to help try and improve this? Patches welcome.
>>>
>>> It's been on my priority-2 TODO list for a while to help with that...
>>> Now if people would stop adding to my priority-1 TODO list...
>>>
>>> Agree that's definitely more than a one-person job, but migrating a
>>> specific call is also a reasonably self-contained unit of work that (1)
>>> does not require a deep understanding of all the code around it, and (2)
>>> does not commit you for a lifelong feature maintenance duty... So maybe
>>> it would be a good thing to suggest newcomers / students to get a poke
>>> at? I'm happy to help with the reviewing if we can come up with a topic
>>> name that helps finding those.
>>
>>
>> One concern I have is that I am not sure it's always as simple as it looks. For example, we could enforce that device files are always in /dev, but is that always true on all architectures with all hypervisors? How do we know that?
> 
> I think the answer here is that we don't have privsep functions like
> that *at all*. So instead of a generic
> privsep.data.discombobulate(device) you have
> privsep.libvirt.volume.foo.discombobulate(volume). I mentioned this as
> a general principal in my original mail which has since been snipped,
> that we should probably *never* pass a reference to a system resource
> (the most obvious example being a path) to a privsep function.
> Instead, privsep has its own config and can work that out for itself.
> This does mean a proliferation of specific privsep functions over a
> few generic ones, but that's how the security model works. In general
> we should expect classes to have a shadow privsep class containing
> security-sensitive logic.

This matches my understanding of the intent behind privsep. Instead of 
trying to figure out how to filter out dangerous paths or whatever, you 
have the privileged code build the path out of sanitized data passed in. 
You still have to be careful about preventing injection attacks (say I 
pass in [uuid]/../../..), but at least you don't have to try to write a 
rootwrap filter for every possible path in every possible driver. The 
privileged driver code itself knows the correct path and won't allow 
anything else.


From openstack at fried.cc  Mon Apr  1 18:13:40 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 1 Apr 2019 13:13:40 -0500
Subject: [nova] "future" specs and blueprints
In-Reply-To: <m2d0ma26pi.fsf@caffeine.hv.danplanet.com>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <1553766105.28590.1@smtp.office365.com>
 <6a726943-18f9-2b7f-e83a-0855d1d53800@gmail.com>
 <m2d0ma26pi.fsf@caffeine.hv.danplanet.com>
Message-ID: <f73d0540-0274-4f11-d5bb-8f53ab6ff7c6@fried.cc>

Folks-

The response to this has been mostly, "meh, if you like." Since I'm now
the guy who gets to track the paperwork, I would like to give it a try
for a cycle. If it doesn't work, or imposes too much process, or if
people otherwise hate it, we can trash it, no harm no foul.

To that end, I have proposed a patch [1] with some tooling and
documentation. If you do nothing else, please read the (updated) section
on "Backlog specifications" [2] and the (new) section on "Abandoning a
specification" [3].

I have also eaten my own dogfood and proposed patches to abandon the
four existing backlog specs [4]. I added those specs' original authors
and assignees as reviewers (fwiw; some are surely inactive at this point).

One of those had a Train spec that sounds eerily similar [5] so I
suggested "move-spec" there.

There's also a Train spec the author told me was intended for "future"
[6] so I suggested that be moved to the backlog directory.

I ask for help from nova-core to review and merge the tooling (including
Mel's blueprint counting utility [7] which has been ready for a while)
and the scrub patches.

Moving forward, hopefully we can make it a recurring agenda item at PTGs
to review backlog specs and promote, defer, or abandon them as appropriate.

Thanks,
efried

[1] https://review.openstack.org/#/c/648800/
[2]
http://logs.openstack.org/00/648800/3/check/openstack-tox-docs/e601952/html/readme.html#backlog-specifications
[3]
http://logs.openstack.org/00/648800/3/check/openstack-tox-docs/e601952/html/readme.html#abandoning-a-specification
[4]
https://review.openstack.org/#/q/topic:scrub-backlog-specs+(status:open+OR+status:merged)
[5] https://review.openstack.org/#/c/635408/
[6] https://review.openstack.org/#/c/648665/
[7] https://review.openstack.org/#/c/581914/


From lbragstad at gmail.com  Mon Apr  1 18:14:34 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Mon, 1 Apr 2019 13:14:34 -0500
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <CAEs876hBeLUf80U+TK0Vc3_Rb2KO+aXu_AOUMkZ8RVSQjpO1LA@mail.gmail.com>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
 <83ea0995-c5be-4f5a-208f-25c81a29657f@gmail.com>
 <CAEs876hBeLUf80U+TK0Vc3_Rb2KO+aXu_AOUMkZ8RVSQjpO1LA@mail.gmail.com>
Message-ID: <f559f677-0fcd-eac1-a485-64db3072b283@gmail.com>



On 4/1/19 12:31 PM, Mohammed Naser wrote:
> On Mon, Apr 1, 2019 at 8:10 AM Jay Pipes <jaypipes at gmail.com> wrote:
>> On 04/01/2019 04:43 AM, Jens Harbott wrote:
>>> On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
>>>> Hi,
>>>>
>>>> During the summit in Tokyo (if I remember well), Sean Dague lead a
>>>> discussion about removing the need for having 3 endpoints per
>>>> service. I
>>>> was very excited about the proposal, and it's IMO a shame it hasn't
>>>> been
>>>> implemented. Everyone in the room agreed. Here the content of the
>>>> discussion as I remember it:
>>>>
>>>> <discussion in Tokyo>
>>>> 1/ The only service that needed the admin endpoint was Keystone. This
>>>> requirement is now gone. So we could get rid of the admin endpoint
>>>> all
>>>> together.
>>>>
>>>> 2/ The need for an interal vs public endpoint was only needed for
>>>> accounting (of for example bandwidth when uploading to Glance), but
>>>> this
>>>> could be work-around by operators by using intelligent routing. So we
>>>> wouldn't need the internal endpoint.
>>>>
>>>> This makes us only need the public endpoint, and that's it.
>>>>
>>>> Then, there are these %(tenant_id)s bits in the endpoints which are
>>>> also
>>>> very much annoying, and could be removed if the clients were smarter.
>>>> These are still needed, apparently, for:
>>>> - cinder
>>>> - swift
>>>> - heat
>>>> </discussion in Tokyo>
>>>>
>>>> Is anyone planning to implement (at least some parts of) the above?
>>> For me as an operator, the distinction between internal and public
>>> endpoints is helpful, as it allows to easily set up extended filtering
>>> or rate limiting for public services without affecting internal API
>>> calls, which in most deployments cause the majority of requests.
>>>
>>> I'm not sure what "intelligent routing" is meant to be, but it sounds
>>> more complicated and unstable than the current solution.
>> Maybe Thomas was referring to having Keystone just return a single set
>> of endpoints depending on the source CIDR.
>>
>> Or maybe he is referring to performing rate-limiting using a lower-level
>> tool that was purpose-built for it -- something like iptables?
>>
>> i.e. ACCEPT all new connections from your private subnet/CIDR and jump
>> all new connections not in your private subnet to a RATE-LIMIT chain
>> that applies rate-limiting thresholds.
>>
>> In other words, use a single HTTP endpoint and do the rate-limiting in
>> the Linux kernel instead of higher-level applications.
>>
>> Related: this is why having "quotas" for things like # of metadata items
>> in Nova was always a terrible "feature" that was abusing the quota
>> system as a terrible rate-limiting middleware when things like iptables
>> or tc were a more appropriate solution.
> I'm personally a fan of single endpoint, you can use your own methods to
> determine if traffic is coming from a certain place.
>
> Anyways, in all of OpenStack's APIs, there is zero assumption that the API
> you talk to will be different depending on the endpoint.  I think Keystone had
> that assumption but that was ripped out.

Correct, that assumption only existed with v2.0, which we ripped out in
Queens. The unfortunate side-effect of that design is that it made
security solely an operator problem. It also didn't force developers to
really think through those authoritative use cases when designing or
writing APIs.

The v3 API was designed from the beginning to be single application that
implemented a policy engine so that we didn't need an endpoint for
administrators and "everyone else". FWIW - we have some documentation in
keystone that is related to this thread (but more general that this
specific case) [0].

[0]
https://docs.openstack.org/keystone/latest/contributor/service-catalog.html
>
> In our case, we deploy a single SSL secured endpoint which all public users
> and internal services talk to.  If our services are doing something that needs
> to be rate limited, we probably need to revisit that :)
>
> +1 for me, however, I know some people use this type of thing for "network
> isolation".  However, I think this issue can be delegated a layer lower (split
> DNS, hard-coding a different URL).
>
>> Best,
>> -jay
>>
>>> Big +1 on dropping the admin endpoint though, now that keystone doesn't
>>> need it anymore.
>>>
>>> Jens
>>>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/87760e75/attachment.sig>

From openstack at fried.cc  Mon Apr  1 19:36:12 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 1 Apr 2019 14:36:12 -0500
Subject: [placement] update 19-12
In-Reply-To: <alpine.OSX.2.21.1904011555250.29870@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1903291407130.89401@cdent-a01.vmware.com>
 <AFCAAFE6-9C8C-4E44-A1A5-0852B986E20C@leafe.com>
 <alpine.OSX.2.21.1904011555250.29870@cdent-a01.vmware.com>
Message-ID: <793c34f5-8aac-8a7e-77c0-47d5c1fd1803@fried.cc>

Chris-

On 4/1/19 9:55 AM, Chris Dent wrote:
> On Mon, 1 Apr 2019, Ed Leafe wrote:
>> On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>>> We could also
>>>  investigate making os-traits and os-resource-classes
>>>  required-projects in job templates in zuul. This would allow them
>>>  to be "tox siblings". Or we could wait. Please express an
>>>  opinion if you have one.

If this is the magic potion that makes it possible for e.g. my nova
patch to Depends-On: my os-traits patch and have that actually work,
then yes, please, definitely do this.

Otherwise I have to wait until the os-traits patch is merged, released,
and percolated through u-c before the nova patch has a hope of running
through the check pipeline.

If "tox siblings" is something different, then I have no opinion due to
ignorance.

-efried


From mikal at stillhq.com  Mon Apr  1 19:59:28 2019
From: mikal at stillhq.com (Michael Still)
Date: Tue, 2 Apr 2019 06:59:28 +1100
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
Message-ID: <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>

On Tue, Apr 2, 2019 at 5:06 AM Ben Nemec <openstack at nemebean.com> wrote:

[snip]

This matches my understanding of the intent behind privsep. Instead of
> trying to figure out how to filter out dangerous paths or whatever, you
> have the privileged code build the path out of sanitized data passed in.
> You still have to be careful about preventing injection attacks (say I
> pass in [uuid]/../../..), but at least you don't have to try to write a
> rootwrap filter for every possible path in every possible driver. The
> privileged driver code itself knows the correct path and won't allow
> anything else.
>

I don't think anyone disputes that theory.

The issue here is that the calling code in nova makes that very hard in
some cases. For example, nova.privsep.path.readfile exists because it is
called by nova.virt.disk.localfs.read_file [1], which takes a raw path to
read. That is in turn used by calling code to read at least two paths that
are generated in calling code. Now all of that is fixable, and that's a
relatively simple example, but it requires a call by call analysis that is
quite expensive to do and will cause a lot of code churn to fix.

No one is saying we shouldn't do it. However, the current privsep code took
the approach of an incremental improvement on top of what we already had,
instead of attempting to boil the ocean in a single patch series. The code
for nova.virt.disk.localfs.read_file used to call a method called
read_file_as_root that was just as bad as what we have now, but used
rootwrap to cat arbitrary files in the filesystem (git
sha f535e8bb9905b5632416135af5789704db6d2867 is the original transition).

My point is that we need to start somewhere, and proposing that we abandon
privsep entirely because its not immediately perfect isn't very helpful.

Michael

1: Well, there is one other caller, but you get the idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/c4643213/attachment-0001.html>

From sergey at vilgelm.info  Mon Apr  1 20:09:18 2019
From: sergey at vilgelm.info (Sergey Vilgelm)
Date: Mon, 1 Apr 2019 15:09:18 -0500
Subject: [keystone] how to write a plugin?
In-Reply-To: <4e04e924-15c3-4eae-864c-77bc91907b55@Spark>
References: <4e04e924-15c3-4eae-864c-77bc91907b55@Spark>
Message-ID: <64af72b3-8f3e-4f7c-b67a-0eac43a1c43f@Spark>

Hello community,

Please help me to figure out how to write a plugin for keystone to modify the current functionality. I planned to create a middleware, but found that the paste was removed in Rocky and now Keystone uses the hard-coded list of middleware/apps.

I need to call an additional script/api when creating a domain or a project. Is it possible to implement this without patching Keystone?

--
Sergey Vilgelm
https://www.vilgelm.info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/1998736b/attachment.html>

From anlin.kong at gmail.com  Mon Apr  1 20:24:49 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Tue, 2 Apr 2019 09:24:49 +1300
Subject: [trove] Trove for Train
In-Reply-To: <CAEs876h5nOwFicePxDqxrqp0rvhMn0YYBoM=T9d3ajOFho2Jrg@mail.gmail.com>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
 <CAEs876h5nOwFicePxDqxrqp0rvhMn0YYBoM=T9d3ajOFho2Jrg@mail.gmail.com>
Message-ID: <CALjNAZ1w+yrvpyWEX+wq2hM4FDrv89aT=VNGiDv_oOz7Dezpnw@mail.gmail.com>

Thanks for the advise, Mohammed :-)

The several differences between current Trove and Octavia communication
model are:

- The attack surface between database and haproxy is different, it's much
easier to hack database than haproxy. So the Octavia model is good, but
doesn't mean it's suitable for Trove as well.
- The Octavia guest agent normally doesn't initialize the communication
with the control plane, except for sending the monitoring status via UDP,
but Trove guest agent has to notify update back to control plane for
database status change. This could be changed though.

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Tue, Apr 2, 2019 at 6:33 AM Mohammed Naser <mnaser at vexxhost.com> wrote:

> On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong at gmail.com>
> wrote:
> >
> > Hi,
> >
> > I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev
> cycle. Since the master branch is open for contribution and review, for
> those who care about Trove, here are several things I'd like to bring to
> your attention and most importantly, need your feedback.
> >
> > - Deprecate nova-network.
> >
> >   As I mentioned in the candidacy, The nova-network related code is
> spread in the repo, which makes it very difficult for new feature
> implementation and bugfix. Considering nova-network was deprecated in the
> OpenStack Newton release, I propose we also deprecate nova-network support
> in Trove and remove after several cycles according to the deprecation
> policy of the community. I'm not sure if there is still anyone using
> nova-network for Trove, especially in production.  If yes, please reply to
> this email.
> >
> > - Create service VM in admin project by default
> >
> >   Currently, Trove has configuration support to create the db instance
> in the admin project, which I think should be the default deployment model
> to reduce the security risk given all the db instances are communicating
> with RabbitMQ in the control plane.
> >
> > - Remove SecurityGroup API extension
> >
> >   TBH, I don't know when and why that extension was added in Trove but
> since it's not included in Trove API document(
> https://developer.openstack.org/api-ref/database/), I assume there is on
> one relies on that in production, so should be safe to remove.
> >
> > - Remove SecurityGroup related database model
> >
> >   I don't have the history development background in my mind, but IMHO,
> i don't think it's reasonable for Trove to maintain such information in db.
> >
> > - Security group management enhancement
> >
> >   Removing the API extension and database model doesn't mean Trove
> shouldn't support security group for the db instance, on the contrary,
> security should always be the first thing we consider for new features. The
> two tasks above are actually prerequisites for this one. In order to make
> it easy to maintain and as more secure as possible, Trove is not going to
> allow the end user to manipulate the security group associated with db
> instance. Trove will try to provide as more information as possible to make
> the debugging and performance tuning easy.
> >
> > - Monitoring capability
> >
> >   Currently, there is no monitoring capability support in Trove, and I
> think that's the only main part missing for Trove to be running in
> production. I don't have a full picture in mind now but will try to figure
> out how to achieve that.
> >
> > - Priorities of the previous dev cycles
> >
> >   Of course, I shouldn't put the previous dev cycle priorities away from
> the track, e.g. the Stein dev cycle priorities are well documented here
> https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking
> >
> > As Trove project has been experiencing some up and downs in the past,
> but it's still very useful in some deployment use cases and has some
> advantages over the container deployment model. As you could guess, the
> reason I raised my hand to lead Trove is that we(Catalyst Cloud) have been
> deploying Trove in production, so all those things are aiming at making
> Trove production ready, not only for private cloud but also for the public.
> >
> > If you have any concerns related to what's mentioned above, please don't
> hesitate to reply. Alternately, I'm always in the #openstack-trove IRC
> channel and could answer any questions during the working hours of UTC+12.
>
> I think another thing is the deployment model of relying on RabbitMQ
> to talk to the control plane.  That has been the biggest sticking
> point for deployers.  I think adopting something similar to the
> Octavia service VM model with public/private key and HTTP API might be
> far more successful.
>
> > I really appreciate any feedback from the community.
> >
> > ---
> > Cheers,
> > Lingxian Kong
> > Catalyst Cloud
>
>
>
> --
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/a5f31023/attachment.html>

From skaplons at redhat.com  Mon Apr  1 20:49:22 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 1 Apr 2019 22:49:22 +0200
Subject: [neutron] CI meeting cancel
Message-ID: <7F72391B-1A33-4A9F-A87C-DC94A7BE6951@redhat.com>

Hi,

I can’t chair neutron CI meeting this Tuesday (2.04) so I cancel it.
See You on next meeting on 9.04.

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From jonathan.rosser at rd.bbc.co.uk  Mon Apr  1 20:54:24 2019
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Mon, 1 Apr 2019 21:54:24 +0100
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <1554108230.4997.13.camel@offenerstapel.de>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
Message-ID: <0f2c4edc-8bc9-36fc-157b-eb641b923db1@rd.bbc.co.uk>



On 01/04/2019 09:43, Jens Harbott wrote:
> On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
>> Hi,
>>
>> During the summit in Tokyo (if I remember well), Sean Dague lead a
>> discussion about removing the need for having 3 endpoints per
>> service. I
>> was very excited about the proposal, and it's IMO a shame it hasn't
>> been
>> implemented. Everyone in the room agreed. Here the content of the
>> discussion as I remember it:
>>
>> <discussion in Tokyo>
>> 1/ The only service that needed the admin endpoint was Keystone. This
>> requirement is now gone. So we could get rid of the admin endpoint
>> all
>> together.
>>
>> 2/ The need for an interal vs public endpoint was only needed for
>> accounting (of for example bandwidth when uploading to Glance), but
>> this
>> could be work-around by operators by using intelligent routing. So we
>> wouldn't need the internal endpoint.
>>
>> This makes us only need the public endpoint, and that's it.
>>
>> Then, there are these %(tenant_id)s bits in the endpoints which are
>> also
>> very much annoying, and could be removed if the clients were smarter.
>> These are still needed, apparently, for:
>> - cinder
>> - swift
>> - heat
>> </discussion in Tokyo>
>>
>> Is anyone planning to implement (at least some parts of) the above?
> 
> For me as an operator, the distinction between internal and public
> endpoints is helpful, as it allows to easily set up extended filtering
> or rate limiting for public services without affecting internal API
> calls, which in most deployments cause the majority of requests.
> 

If 2/ were implemented a class of deployment where the cloud control 
plane is isolated from any public networks becomes difficult to 
engineer. There is currently no requirement for there to be connectivity 
between the control plane and public networks, so 2/ results in the 
required architecture becoming more opinionated and reduces choices for 
the deployer.

In openstack-ansible (and no doubt other deployment projects) a wide 
range of topologies are supported, from simplistic networks where 
internal and public are the same subnet, through to full isolation. We 
have deployers who choose to sit at various points along that spectrum 
as their particular situation requires.

2/ seems to require deployers to in some way NAT or route between their 
control plane network and the public endpoint, something that I expect 
most people do right now anyway. However this is not universal and there 
are set of OSA users (myself included) with non-routable control planes 
who would like to keep them that way.

> I'm not sure what "intelligent routing" is meant to be, but it sounds
> more complicated and unstable than the current solution.
> 

I also don't understand what this would mean in practice.

Jon.


From anlin.kong at gmail.com  Mon Apr  1 20:56:25 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Tue, 2 Apr 2019 09:56:25 +1300
Subject: [trove] Use storyboard
Message-ID: <CALjNAZ1DixayL=Rb2JB2TmCT7C-BuV5bfbe9Q_4N=71UNEX+xQ@mail.gmail.com>

Hi trove team,

We are going to use storyboard[1] for task tracking from Train dev cycle,
please make sure there is related story/task for every new patch from now
on.

I didn't migrate things from launchpad so the links in the existing patches
are still valid.

[1]: https://storyboard.openstack.org/#!/project_group/trove

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/d8945396/attachment-0001.html>

From julianmeier at mailtower.ch  Mon Apr  1 20:42:24 2019
From: julianmeier at mailtower.ch (Julian Meier)
Date: Mon, 1 Apr 2019 22:42:24 +0200
Subject: [training-labs] DHCP IP conflict with Ubuntu 18.04.2
Message-ID: <CABWNwy_9_AaBTYhu9t+cc4e4HvQ9NTayLj-PCyzFeQm1Rb03Tw@mail.gmail.com>

Hi,

we are currently working on a new environment for our school to teach
some basic knowledge about OpenStack.
Our goal is to run OpenStack training-labs for each student on VMs
running on ESXi.

Therefor we've enabled nested virtualization (vhv.enable=TRUE) for the
VMs in vSphere. Then we basically do following on Ubuntu 18.04.2:
```
echo 1 > /sys/module/kvm/parameters/ignore_msr
# to avoid following error while building the base image: "This
usually means the libguestfs appliance failed to start or crashed."

sudo apt-get install -y qemu-kvm libvirt-bin libguestfs-tools
bridge-utils virt-manager

virsh pool-create-as --name default --type dir --target /var/lib/libvirt/images

wget http://tarballs.openstack.org/training-labs/dist/labs-stable-rocky.tgz
tar xzf labs-stable-rocky.tgz
cd labs/
```
We build the base image ubuntu-18.04-server-amd64 with `./st.py
--build basedisk --provider kvm` and then the cluster `./st.py --build
cluster --provider kvm`.
Everything works fine till...:

stacktrain.log:
```
12256 13:08:19.992 stacktrain.core.autostart INFO Start
autostart/04_setup_nova_compute.sh
12256 13:08:19.994 stacktrain.core.ssh DEBUG vm_ssh: ssh -q -i
/opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o
ConnectTimeout=20 -o ControlPath=none -p 22 osbash at 192.168.122.208
bash autostart/04_setup_nova_compute.sh && rm -vf
autostart/04_setup_nova_compute.sh
12256 13:08:19.994 stacktrain.core.ssh DEBUG Writing live log for ssh
call at /opt/oslab/labs/log/021_04_setup_nova_compute.auto.
12256 13:08:56.551 stacktrain.core.ssh ERROR ssh returned status 255.
12256 13:08:56.552 stacktrain.core.autostart ERROR Script failure:
04_setup_nova_compute
11272 13:08:57.110 stacktrain.core.autostart ERROR Script failed. Exiting.
```

ssh.log:
```
ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o
ConnectTimeout=20 -o ControlPath=none -p 22 osbash at 192.168.122.208
mkdir -p autostart
ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o
UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o
ConnectTimeout=20 -o ControlPath=none -p 22 osbash at 192.168.122.208
bash autostart/04_setup_nova_compute.sh && rm -vf
autostart/04_setup_nova_compute.sh
```

For me it looks like both VMs (controller + compute1) get the same IP
address (with `./st.py --build nodes_only --provider kvm`):
...
Your cluster nodes:
INFO VM name: compute1
INFO SSH login: ssh osbash at 192.168.122.47
INFO            (password: osbash)
INFO VM name: controller
INFO SSH login: ssh osbash at 192.168.122.47
INFO            (password: osbash)
INFO Dashboard: Assuming horizon is on controller VM.
INFO            http://192.168.122.47/horizon/
INFO            User  : myuser (password: myuser_user_pass)
INFO            User  : admin (password: admin_user_secret)
INFO Network: mgmt
INFO          Network address: 10.0.0.0
INFO Network: provider
INFO          Network address: 203.0.113.0
```

>From within the VMs:
```
# controller:
osbash at osbash:~$ ifconfig ens3
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.47  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::5054:ff:fed9:b165  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:d9:b1:65  txqueuelen 1000  (Ethernet)
...
osbash at osbash:~$ netplan ip leases ens3
# This is private data. Do not parse.
ADDRESS=192.168.122.47
NETMASK=255.255.255.0
ROUTER=192.168.122.1
SERVER_ADDRESS=192.168.122.1
NEXT_SERVER=192.168.122.1
BROADCAST=192.168.122.255
T1=1800
T2=3150
LIFETIME=3600
DNS=192.168.122.1
HOSTNAME=osbash
CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5

osbash at osbash:~$ cat /etc/machine-id
b8c7057a4c084e69aa3743960d41d5ce

# compute1:
osbash at compute1:~$ ifconfig ens3
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.47  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::5054:ff:fe17:b640  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:17:b6:40  txqueuelen 1000  (Ethernet)
...
osbash at compute1:~$ netplan ip leases ens3
# This is private data. Do not parse.
ADDRESS=192.168.122.47
NETMASK=255.255.255.0
ROUTER=192.168.122.1
SERVER_ADDRESS=192.168.122.1
NEXT_SERVER=192.168.122.1
BROADCAST=192.168.122.255
T1=1800
T2=3150
LIFETIME=3600
DNS=192.168.122.1
HOSTNAME=compute1
CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5

osbash at compute1:~$ cat /etc/machine-id
b8c7057a4c084e69aa3743960d41d5ce
```

I believe the VMs share the same IP address because of the same
machine-id (which is used as DUID:
http://manpages.ubuntu.com/manpages/bionic/man5/networkd.conf.5.html)

Am I wrong?
Thanks for your help,
Julian


From openstack at nemebean.com  Mon Apr  1 21:10:31 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 1 Apr 2019 16:10:31 -0500
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
Message-ID: <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>



On 4/1/19 2:59 PM, Michael Still wrote:
> On Tue, Apr 2, 2019 at 5:06 AM Ben Nemec <openstack at nemebean.com 
> <mailto:openstack at nemebean.com>> wrote:
> 
> [snip]
> 
>     This matches my understanding of the intent behind privsep. Instead of
>     trying to figure out how to filter out dangerous paths or whatever, you
>     have the privileged code build the path out of sanitized data passed
>     in.
>     You still have to be careful about preventing injection attacks (say I
>     pass in [uuid]/../../..), but at least you don't have to try to write a
>     rootwrap filter for every possible path in every possible driver. The
>     privileged driver code itself knows the correct path and won't allow
>     anything else.
> 
> 
> I don't think anyone disputes that theory.
> 
> The issue here is that the calling code in nova makes that very hard in 
> some cases. For example, nova.privsep.path.readfile exists because it is 
> called by nova.virt.disk.localfs.read_file [1], which takes a raw path 
> to read. That is in turn used by calling code to read at least two paths 
> that are generated in calling code. Now all of that is fixable, and 
> that's a relatively simple example, but it requires a call by call 
> analysis that is quite expensive to do and will cause a lot of code 
> churn to fix.
> 
> No one is saying we shouldn't do it. However, the current privsep code 
> took the approach of an incremental improvement on top of what we 
> already had, instead of attempting to boil the ocean in a single patch 
> series. The code for nova.virt.disk.localfs.read_file used to call a 
> method called read_file_as_root that was just as bad as what we have 
> now, but used rootwrap to cat arbitrary files in the filesystem (git 
> sha f535e8bb9905b5632416135af5789704db6d2867 is the original transition).
> 
> My point is that we need to start somewhere, and proposing that we 
> abandon privsep entirely because its not immediately perfect isn't very 
> helpful.

For the record, that was not at all my intent. It doesn't sound to me 
like the current privsep implementation is meaningfully worse than using 
rootwrap, and it seems to me that it should be much easier (note: 
easier, not easy) to move forward now that everything is using privsep. 
I was just +1'ing the desired end state of privsep calls not taking 
paths as input anymore.

> 
> Michael
> 
> 1: Well, there is one other caller, but you get the idea.


From openstack at nemebean.com  Mon Apr  1 21:17:34 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 1 Apr 2019 16:17:34 -0500
Subject: [trove] Trove for Train
In-Reply-To: <CALjNAZ1w+yrvpyWEX+wq2hM4FDrv89aT=VNGiDv_oOz7Dezpnw@mail.gmail.com>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
 <CAEs876h5nOwFicePxDqxrqp0rvhMn0YYBoM=T9d3ajOFho2Jrg@mail.gmail.com>
 <CALjNAZ1w+yrvpyWEX+wq2hM4FDrv89aT=VNGiDv_oOz7Dezpnw@mail.gmail.com>
Message-ID: <98ac4496-8b8d-8773-0db7-f1fdf36f9b11@nemebean.com>



On 4/1/19 3:24 PM, Lingxian Kong wrote:
> Thanks for the advise, Mohammed :-)
> 
> The several differences between current Trove and Octavia communication 
> model are:
> 
> - The attack surface between database and haproxy is different, it's 
> much easier to hack database than haproxy. So the Octavia model is good, 
> but doesn't mean it's suitable for Trove as well.

Doesn't that make it _more_ important for the database nodes to not have 
access to the control plane rabbitmq? If a VM gets compromised I'd much 
rather that it not have access to a core piece of my infrastructure.

> - The Octavia guest agent normally doesn't initialize the communication 
> with the control plane, except for sending the monitoring status via 
> UDP, but Trove guest agent has to notify update back to control plane 
> for database status change. This could be changed though.
> 
> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud
> 
> 
> On Tue, Apr 2, 2019 at 6:33 AM Mohammed Naser <mnaser at vexxhost.com 
> <mailto:mnaser at vexxhost.com>> wrote:
> 
>     On Sun, Mar 31, 2019 at 11:27 PM Lingxian Kong <anlin.kong at gmail.com
>     <mailto:anlin.kong at gmail.com>> wrote:
>      >
>      > Hi,
>      >
>      > I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train
>     dev cycle. Since the master branch is open for contribution and
>     review, for those who care about Trove, here are several things I'd
>     like to bring to your attention and most importantly, need your
>     feedback.
>      >
>      > - Deprecate nova-network.
>      >
>      >   As I mentioned in the candidacy, The nova-network related code
>     is spread in the repo, which makes it very difficult for new feature
>     implementation and bugfix. Considering nova-network was deprecated
>     in the OpenStack Newton release, I propose we also deprecate
>     nova-network support in Trove and remove after several cycles
>     according to the deprecation policy of the community. I'm not sure
>     if there is still anyone using nova-network for Trove, especially in
>     production.  If yes, please reply to this email.
>      >
>      > - Create service VM in admin project by default
>      >
>      >   Currently, Trove has configuration support to create the db
>     instance in the admin project, which I think should be the default
>     deployment model to reduce the security risk given all the db
>     instances are communicating with RabbitMQ in the control plane.
>      >
>      > - Remove SecurityGroup API extension
>      >
>      >   TBH, I don't know when and why that extension was added in
>     Trove but since it's not included in Trove API
>     document(https://developer.openstack.org/api-ref/database/), I
>     assume there is on one relies on that in production, so should be
>     safe to remove.
>      >
>      > - Remove SecurityGroup related database model
>      >
>      >   I don't have the history development background in my mind, but
>     IMHO, i don't think it's reasonable for Trove to maintain such
>     information in db.
>      >
>      > - Security group management enhancement
>      >
>      >   Removing the API extension and database model doesn't mean
>     Trove shouldn't support security group for the db instance, on the
>     contrary, security should always be the first thing we consider for
>     new features. The two tasks above are actually prerequisites for
>     this one. In order to make it easy to maintain and as more secure as
>     possible, Trove is not going to allow the end user to manipulate the
>     security group associated with db instance. Trove will try to
>     provide as more information as possible to make the debugging and
>     performance tuning easy.
>      >
>      > - Monitoring capability
>      >
>      >   Currently, there is no monitoring capability support in Trove,
>     and I think that's the only main part missing for Trove to be
>     running in production. I don't have a full picture in mind now but
>     will try to figure out how to achieve that.
>      >
>      > - Priorities of the previous dev cycles
>      >
>      >   Of course, I shouldn't put the previous dev cycle priorities
>     away from the track, e.g. the Stein dev cycle priorities are well
>     documented here
>     https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking
>      >
>      > As Trove project has been experiencing some up and downs in the
>     past, but it's still very useful in some deployment use cases and
>     has some advantages over the container deployment model. As you
>     could guess, the reason I raised my hand to lead Trove is that
>     we(Catalyst Cloud) have been deploying Trove in production, so all
>     those things are aiming at making Trove production ready, not only
>     for private cloud but also for the public.
>      >
>      > If you have any concerns related to what's mentioned above,
>     please don't hesitate to reply. Alternately, I'm always in the
>     #openstack-trove IRC channel and could answer any questions during
>     the working hours of UTC+12.
> 
>     I think another thing is the deployment model of relying on RabbitMQ
>     to talk to the control plane.  That has been the biggest sticking
>     point for deployers.  I think adopting something similar to the
>     Octavia service VM model with public/private key and HTTP API might be
>     far more successful.
> 
>      > I really appreciate any feedback from the community.
>      >
>      > ---
>      > Cheers,
>      > Lingxian Kong
>      > Catalyst Cloud
> 
> 
> 
>     -- 
>     Mohammed Naser — vexxhost
>     -----------------------------------------------------
>     D. 514-316-8872
>     D. 800-910-1726 ext. 200
>     E. mnaser at vexxhost.com <mailto:mnaser at vexxhost.com>
>     W. http://vexxhost.com
> 


From juliaashleykreger at gmail.com  Mon Apr  1 21:19:10 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 1 Apr 2019 14:19:10 -0700
Subject: [all][ops] Train goal: removing and simplifying the endpoint
 tripplets?
In-Reply-To: <CAEs876hBeLUf80U+TK0Vc3_Rb2KO+aXu_AOUMkZ8RVSQjpO1LA@mail.gmail.com>
References: <d201e6bc-bcd4-3054-a91c-723b51be0e4b@debian.org>
 <1554108230.4997.13.camel@offenerstapel.de>
 <83ea0995-c5be-4f5a-208f-25c81a29657f@gmail.com>
 <CAEs876hBeLUf80U+TK0Vc3_Rb2KO+aXu_AOUMkZ8RVSQjpO1LA@mail.gmail.com>
Message-ID: <CAF7gwdjEWvLWUookVJ63=uSnw0fd4e9=hLZEMfd245OG_YbgpA@mail.gmail.com>

On Mon, Apr 1, 2019 at 10:38 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> On Mon, Apr 1, 2019 at 8:10 AM Jay Pipes <jaypipes at gmail.com> wrote:
> >
> > On 04/01/2019 04:43 AM, Jens Harbott wrote:
> > > On Thu, 2019-03-28 at 16:49 +0100, Thomas Goirand wrote:
> > >> Hi,
> > >>
> > >> During the summit in Tokyo (if I remember well), Sean Dague lead a
> > >> discussion about removing the need for having 3 endpoints per
> > >> service. I
> > >> was very excited about the proposal, and it's IMO a shame it hasn't
> > >> been
> > >> implemented. Everyone in the room agreed. Here the content of the
> > >> discussion as I remember it:
> > >>
> > >> <discussion in Tokyo>
> > >> 1/ The only service that needed the admin endpoint was Keystone. This
> > >> requirement is now gone. So we could get rid of the admin endpoint
> > >> all
> > >> together.
> > >>
> > >> 2/ The need for an interal vs public endpoint was only needed for
> > >> accounting (of for example bandwidth when uploading to Glance), but
> > >> this
> > >> could be work-around by operators by using intelligent routing. So we
> > >> wouldn't need the internal endpoint.
> > >>
> > >> This makes us only need the public endpoint, and that's it.
> > >>
> > >> Then, there are these %(tenant_id)s bits in the endpoints which are
> > >> also
> > >> very much annoying, and could be removed if the clients were smarter.
> > >> These are still needed, apparently, for:
> > >> - cinder
> > >> - swift
> > >> - heat
> > >> </discussion in Tokyo>
> > >>
> > >> Is anyone planning to implement (at least some parts of) the above?
> > >
> > > For me as an operator, the distinction between internal and public
> > > endpoints is helpful, as it allows to easily set up extended filtering
> > > or rate limiting for public services without affecting internal API
> > > calls, which in most deployments cause the majority of requests.
> > >
> > > I'm not sure what "intelligent routing" is meant to be, but it sounds
> > > more complicated and unstable than the current solution.
> >
> > Maybe Thomas was referring to having Keystone just return a single set
> > of endpoints depending on the source CIDR.
> >
> > Or maybe he is referring to performing rate-limiting using a lower-level
> > tool that was purpose-built for it -- something like iptables?
> >
> > i.e. ACCEPT all new connections from your private subnet/CIDR and jump
> > all new connections not in your private subnet to a RATE-LIMIT chain
> > that applies rate-limiting thresholds.
> >
> > In other words, use a single HTTP endpoint and do the rate-limiting in
> > the Linux kernel instead of higher-level applications.
> >
> > Related: this is why having "quotas" for things like # of metadata items
> > in Nova was always a terrible "feature" that was abusing the quota
> > system as a terrible rate-limiting middleware when things like iptables
> > or tc were a more appropriate solution.
>
> I'm personally a fan of single endpoint, you can use your own methods to
> determine if traffic is coming from a certain place.
>
> Anyways, in all of OpenStack's APIs, there is zero assumption that the API
> you talk to will be different depending on the endpoint.  I think Keystone had
> that assumption but that was ripped out.

But I know of at least one case where there is a knob to control if
some REST endpoints are available. While not explicitly tied to the
endpoint type, we do provide baremetal operators some behavior knobs
to disable the exposure of internal traffic versus public traffic as
two different services have been launched with slightly different
configurations. Overall I think making the ability to only populate
one and use it is great. I think the other endpoints need to be
optional to allow more advanced configurations as-needed. That will at
least lessen the initial confusion barrier for people trying to setup
keystone for the first time.

>
> In our case, we deploy a single SSL secured endpoint which all public users
> and internal services talk to.  If our services are doing something that needs
> to be rate limited, we probably need to revisit that :)
>
> +1 for me, however, I know some people use this type of thing for "network
> isolation".  However, I think this issue can be delegated a layer lower (split
> DNS, hard-coding a different URL).
>
> > Best,
> > -jay
> >
> > > Big +1 on dropping the admin endpoint though, now that keystone doesn't
> > > need it anymore.
> > >
> > > Jens
> > >
> >
>
>
> --
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com
>


From mnaser at vexxhost.com  Mon Apr  1 21:25:55 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Mon, 1 Apr 2019 17:25:55 -0400
Subject: [tc] next meeting
Message-ID: <CAEs876g_jNaL4htVSoWwdz3cHeC=YAZubgu6iemxMkwty5JMwg@mail.gmail.com>

Hi everyone:

It's quite a busy time but our monthly meeting is due.

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

I left the list of past agenda topics in order to leave it for anyone
to reference back if they'd like.  Please add topics by most Wednesday
so we can send out an agenda before the meeting.

Thanks,
Mohammed

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From anlin.kong at gmail.com  Mon Apr  1 22:26:18 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Tue, 2 Apr 2019 11:26:18 +1300
Subject: [trove] Trove for Train
In-Reply-To: <98ac4496-8b8d-8773-0db7-f1fdf36f9b11@nemebean.com>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
 <CAEs876h5nOwFicePxDqxrqp0rvhMn0YYBoM=T9d3ajOFho2Jrg@mail.gmail.com>
 <CALjNAZ1w+yrvpyWEX+wq2hM4FDrv89aT=VNGiDv_oOz7Dezpnw@mail.gmail.com>
 <98ac4496-8b8d-8773-0db7-f1fdf36f9b11@nemebean.com>
Message-ID: <CALjNAZ0auF1F4v4iRejJQcF8WtGpUfBXMV0wOhNL1hkdMaOU-g@mail.gmail.com>

On Tue, Apr 2, 2019 at 10:17 AM Ben Nemec <openstack at nemebean.com> wrote:

>
> Doesn't that make it _more_ important for the database nodes to not have
> access to the control plane rabbitmq? If a VM gets compromised I'd much
> rather that it not have access to a core piece of my infrastructure.
>

Yes, it does. That's why I said in the following that the communication
model of Trove could be changed by making the guest agent only repond
rather than sending request.

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/03623e4d/attachment.html>

From colleen at gazlene.net  Mon Apr  1 22:58:44 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Mon, 01 Apr 2019 18:58:44 -0400
Subject: [keystone] how to write a plugin?
In-Reply-To: <64af72b3-8f3e-4f7c-b67a-0eac43a1c43f@Spark>
References: <4e04e924-15c3-4eae-864c-77bc91907b55@Spark>
 <64af72b3-8f3e-4f7c-b67a-0eac43a1c43f@Spark>
Message-ID: <4165129e-26b7-47a2-bab0-9d3afcaca9aa@www.fastmail.com>

Hi Sergey,

On Mon, Apr 1, 2019, at 1:10 PM, Sergey Vilgelm wrote:
> Hello community, 
> 
> Please help me to figure out how to write a plugin for keystone to 
> modify the current functionality. I planned to create a middleware, but 
> found that the paste was removed in Rocky and now Keystone uses the 
> hard-coded list of middleware/apps.
> 
> I need to call an additional script/api when creating a domain or a 
> project. Is it possible to implement this without patching Keystone?
> 
> --
>  Sergey Vilgelm 
> https://www.vilgelm.info
>

We have instructions for developing a plugin here:

https://docs.openstack.org/keystone/latest/contributor/developing-drivers.html

The short description is to subclass one of the base drivers (e.g. keystone.resource.backends.base.ResourceDriverBase) and to create a setuptools entrypoint for it, which you can then use to configure the driver option in keystone.conf.

The driver interface is subject to change from release to release so be sure to read the release notes and update your driver implementation.

Colleen


From corvus at inaugust.com  Mon Apr  1 23:15:01 2019
From: corvus at inaugust.com (James E. Blair)
Date: Mon, 01 Apr 2019 16:15:01 -0700
Subject: [placement][nova][infra] best way to add to required-projects on
 several zuul jobs
In-Reply-To: <alpine.OSX.2.21.1904011637160.29870@cdent-a01.vmware.com> (Chris
 Dent's message of "Mon, 1 Apr 2019 16:50:23 +0100 (BST)")
References: <alpine.OSX.2.21.1904011637160.29870@cdent-a01.vmware.com>
Message-ID: <87imvxmi6i.fsf@meyer.lemoncheese.net>

Chris Dent <cdent+os at anticdent.org> writes:

> The extraction of placement led to the development of os-traits and
> os-resource-classes [1,2] which are python modules which contain
> symbols that represent "blessed" strings used as traits and resource
> classes in at least nova, placement and neutron, but plenty of
> others soon.
>
> These symbols are actively used when developing new features, so
> being able to access the python modules via tox-siblings [3] in both
> unit and functional tests, from multiple projects, would be grand:
> developers could depends-on changes in modules as they are being
> developed, or rely on symbols in master of the modules before there
> is a release to pypi.
>
> What is the best way to do this? Many projects are using templates
> like "openstack-python-jobs" but as far as I can tell there's no
> easy way to override just a part of a template in a local .zuul.yaml
> and the usual thing is to create another template such as
> "openstack-python-jobs-neutron" which re-lists all the jobs within,
> and adds a custom required-projects to each job.

While technically you can override settings from a project-template in a
project stanza, when the templates are as simple as those under
discussion, it's exactly as much typing as either omitting the template
or creating a new one (since you have to identify the job and pipeline
whose attributes you want to override).

We have bandied about the idea of adding project-level
requires-projects, and may still do so, though that may not be an
entirely satisfactory solution if there are any jobs where you don't
want the siblings behavior to manifest -- you would have the opposite
problem.

Which leads me to a point which I didn't see explicitly addressed in
your email (though it may have been implicitly addressed): there are
some cases where the siblings behavior is desired, and some where it
isn't.  The siblings behavior helps test multiple project integration
before release, but disallowing it ensures that projects can't depend on
unreleased features.  In some situations one behavior is desired, in
others, the other, and in some, both (and in those cases, projects run
two versions of jobs, with and without siblings).  Just make sure to
keep those caveats in mind when choosing which of the three options to
use.

> Is this (creating another template) the right/best way to add to
> required-projects for this kind of thing? If not, what's the best
> way? Presumably it is better to create a centralized job or template
> when >1 projects will need the additional libraries?

I don't have any rabbits to pull out.

I think a template shared between the involved projects makes sense.

I would also consider creating a new job or jobs (either in addition or
in preference to creating the template).  By the time you're describing
a system that requires multiple dependent projects to test, the idea of
a "placement-tox-py35" job starts to become somewhat descriptive.

-Jim


From sergey at vilgelm.info  Mon Apr  1 23:43:02 2019
From: sergey at vilgelm.info (Sergey Vilgelm)
Date: Mon, 1 Apr 2019 18:43:02 -0500
Subject: [keystone] how to write a plugin?
In-Reply-To: <4165129e-26b7-47a2-bab0-9d3afcaca9aa@www.fastmail.com>
References: <4e04e924-15c3-4eae-864c-77bc91907b55@Spark>
 <64af72b3-8f3e-4f7c-b67a-0eac43a1c43f@Spark>
 <4165129e-26b7-47a2-bab0-9d3afcaca9aa@www.fastmail.com>
Message-ID: <359eaba0-6a78-415a-810f-3826b111b4f6@Spark>

Hi Colleen,

Thank you so much. Seems I need to rewrite resource driver, but I didn’t find where the Keystone uses the `[resource] driver` option[0]. The Resource Manger just creates an instance of resource_sql.Resource[1].
I changed the `[resource] driver` option to `sql1` in the `/etc/keystone/keystone.conf` file and everything works fine :)



[0] https://github.com/openstack/keystone/blob/master/keystone/conf/resource.py#L19
[1] https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L63

--
Sergey Vilgelm
https://www.vilgelm.info

On Apr 1, 2019, 6:00 PM -0500, Colleen Murphy <colleen at gazlene.net>, wrote:
> Hi Sergey,
>
> On Mon, Apr 1, 2019, at 1:10 PM, Sergey Vilgelm wrote:
> > Hello community,
> >
> > Please help me to figure out how to write a plugin for keystone to
> > modify the current functionality. I planned to create a middleware, but
> > found that the paste was removed in Rocky and now Keystone uses the
> > hard-coded list of middleware/apps.
> >
> > I need to call an additional script/api when creating a domain or a
> > project. Is it possible to implement this without patching Keystone?
> >
> > --
> > Sergey Vilgelm
> > https://www.vilgelm.info
> >
>
> We have instructions for developing a plugin here:
>
> https://docs.openstack.org/keystone/latest/contributor/developing-drivers.html
>
> The short description is to subclass one of the base drivers (e.g. keystone.resource.backends.base.ResourceDriverBase) and to create a setuptools entrypoint for it, which you can then use to configure the driver option in keystone.conf.
>
> The driver interface is subject to change from release to release so be sure to read the release notes and update your driver implementation.
>
> Colleen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190401/691c54ad/attachment.html>

From mikal at stillhq.com  Tue Apr  2 03:11:11 2019
From: mikal at stillhq.com (Michael Still)
Date: Tue, 2 Apr 2019 14:11:11 +1100
Subject: [Gerrit][Infra] Marking bot comments in email headers?
Message-ID: <CAEd1pt65hGrkM6fEtRBFDmphvSoSci+sz7ktbSRp7CgHHh6E4g@mail.gmail.com>

Hi,

wouldn't it be cool if we could somehow mark email from gerrit that came
from a bot? Or inversely, call out email sent by a human somehow. That way
I could null route all the bot spam and suddenly gerrit email would be
useful again.

Is this a thing upstream gerrit supports at all?

Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/fbdc0773/attachment-0001.html>

From dangtrinhnt at gmail.com  Tue Apr  2 03:33:03 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 2 Apr 2019 12:33:03 +0900
Subject: [searchlight] Searchlight for Train
Message-ID: <CADJ6S4Hc2_BAyMu+yB7m4xCNO4_cA9UsUMPD47CYiwM+4TVtKQ@mail.gmail.com>

Hi team,

As we are reaching the final weeks of the Stein cycle, I would like to
discuss a little bit about what we've done in Stein and planning for the
Train cycle.

Stein cycle highlights as putting in [1]:

   - Searchlight now works with Elasticsearch 5.x
   - We have released a new vision to make Searchlight a multi-cloud
   application [2]. Moreover, we did a comparison of our vision and the
   OpenStack clouds vision
   - Functional test setup has been improved
   - Searchlight now can work and be tested with Python 3.7

And for the Train cycle, we would like to accomplish these main goals to
fulfill the vision:

   - Make searchlight work with multiple cloud platforms including multiple
   OpenStack clouds [6], Azure [9], Google Cloud [10], AWS [11].
   - Add support for other OpenStack resources: Tacker [7], Octavia [8]
   - Deprecate support for Elasticsearch 2.x [5]

There is a lot of work to be done so I would continue putting effort to
encourage new contributors to Searchlight and explore the values it could
bring the world.

Let's rock it!!!

Yours,


[1]
https://releases.openstack.org/stein/highlights.html#searchlight-search-service
[2]
https://docs.openstack.org/searchlight/latest/contributor/searchlight-vision.html
[3]
https://docs.openstack.org/searchlight/latest/contributor/vision-reflection.html
[4] https://governance.openstack.org/tc/reference/technical-vision.html
[5] https://storyboard.openstack.org/#!/story/2004904
[6] https://storyboard.openstack.org/#!/story/2004840
[7] https://storyboard.openstack.org/#!/story/2004968
[8] https://storyboard.openstack.org/#!/story/2004383
[9] https://storyboard.openstack.org/#!/story/2004718
[10] https://storyboard.openstack.org/#!/story/2004996
[11] https://storyboard.openstack.org/#!/story/2004719



-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/e3cdb0cb/attachment.html>

From colleen at gazlene.net  Tue Apr  2 03:41:16 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Mon, 01 Apr 2019 23:41:16 -0400
Subject: [keystone] how to write a plugin?
In-Reply-To: <359eaba0-6a78-415a-810f-3826b111b4f6@Spark>
References: <4e04e924-15c3-4eae-864c-77bc91907b55@Spark>
 <64af72b3-8f3e-4f7c-b67a-0eac43a1c43f@Spark>
 <4165129e-26b7-47a2-bab0-9d3afcaca9aa@www.fastmail.com>
 <359eaba0-6a78-415a-810f-3826b111b4f6@Spark>
Message-ID: <4fa5bc4b-c44e-477e-9a12-6e0200cccedf@www.fastmail.com>

On Mon, Apr 1, 2019, at 4:43 PM, Sergey Vilgelm wrote:
> Hi Colleen, 
> 
> Thank you so much. Seems I need to rewrite resource driver, but I 
> didn’t find where the Keystone uses the `[resource] driver` option[0]. 
> The Resource Manger just creates an instance of 
> resource_sql.Resource[1].
> I changed the `[resource] driver` option to `sql1` in the 
> `/etc/keystone/keystone.conf` file and everything works fine :)
> 
> 
> 
> [0] 
> https://github.com/openstack/keystone/blob/master/keystone/conf/resource.py#L19
> [1] 
> https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L63
> 

My mistake, we unfortunately removed the ability to override the resource driver a few releases ago:

https://docs.openstack.org/releasenotes/keystone/pike.html#upgrade-notes

It relies on foreign keys with another table and so isn't suitable to be overridden by an out-of-tree driver.

Colleen

> --
>  Sergey Vilgelm 
> https://www.vilgelm.info
> 
> On Apr 1, 2019, 6:00 PM -0500, Colleen Murphy <colleen at gazlene.net>, wrote:
> > Hi Sergey,
> > 
> >  On Mon, Apr 1, 2019, at 1:10 PM, Sergey Vilgelm wrote:
> >> Hello community,
> >> 
> >>  Please help me to figure out how to write a plugin for keystone to
> >>  modify the current functionality. I planned to create a middleware, but
> >>  found that the paste was removed in Rocky and now Keystone uses the
> >>  hard-coded list of middleware/apps.
> >> 
> >>  I need to call an additional script/api when creating a domain or a
> >>  project. Is it possible to implement this without patching Keystone?
> >> 
> >>  --
> >>  Sergey Vilgelm
> >>  https://www.vilgelm.info
> >> 
> > 
> >  We have instructions for developing a plugin here:
> > 
> >  https://docs.openstack.org/keystone/latest/contributor/developing-drivers.html
> > 
> >  The short description is to subclass one of the base drivers (e.g. keystone.resource.backends.base.ResourceDriverBase) and to create a setuptools entrypoint for it, which you can then use to configure the driver option in keystone.conf.
> > 
> >  The driver interface is subject to change from release to release so be sure to read the release notes and update your driver implementation.
> > 
> >  Colleen
> >


From dangtrinhnt at gmail.com  Tue Apr  2 04:20:33 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 2 Apr 2019 13:20:33 +0900
Subject: [telemetry] Telemetry for Train
Message-ID: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>

Hi team,

As we discussed last time [1], the Telemetry team needs help to maintain
its projects in Train. I and Lingxian Kong [2] will give it a try this
cycle hopefully will keep Telemetry as healthy as possible.

I would like to kick start Telemetry in Train by calling for a team meeting
this week to figure out what really happening and plan for actions in Train.

   - IRC Channel: #openstack-telemetry
   - Time: TBD (dangtrinhnt UTC+9)
   - Discussion etherpad (put your name to the attendee list):
   https://etherpad.openstack.org/p/telemetry-train

Please reply here or ping me on the IRC channel (dangtrinhnt) what your
options are and we will set up the meeting.

Moreover, I would like to ask the current core members of Telemetry to
grant me and Lingxian Kong core reviewers privileges on all of the
Telemetry projects on Gerrit (ceilometer, aodh, panko, etc.).

Thanks and love to talk to you soon.

Yours,

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.html
[2] https://review.openstack.org/#/c/645122/

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/b4e774a6/attachment.html>

From anlin.kong at gmail.com  Tue Apr  2 05:00:05 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Tue, 2 Apr 2019 18:00:05 +1300
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
Message-ID: <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>

Hi Trinh,

I'm available from 22:00 - 04:30 in UTC

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Tue, Apr 2, 2019 at 5:20 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> As we discussed last time [1], the Telemetry team needs help to maintain
> its projects in Train. I and Lingxian Kong [2] will give it a try this
> cycle hopefully will keep Telemetry as healthy as possible.
>
> I would like to kick start Telemetry in Train by calling for a team
> meeting this week to figure out what really happening and plan for actions
> in Train.
>
>    - IRC Channel: #openstack-telemetry
>    - Time: TBD (dangtrinhnt UTC+9)
>    - Discussion etherpad (put your name to the attendee list):
>    https://etherpad.openstack.org/p/telemetry-train
>
> Please reply here or ping me on the IRC channel (dangtrinhnt) what your
> options are and we will set up the meeting.
>
> Moreover, I would like to ask the current core members of Telemetry to
> grant me and Lingxian Kong core reviewers privileges on all of the
> Telemetry projects on Gerrit (ceilometer, aodh, panko, etc.).
>
> Thanks and love to talk to you soon.
>
> Yours,
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.html
> [2] https://review.openstack.org/#/c/645122/
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/1afd310b/attachment-0001.html>

From renat.akhmerov at gmail.com  Tue Apr  2 06:13:33 2019
From: renat.akhmerov at gmail.com (Renat Akhmerov)
Date: Tue, 2 Apr 2019 13:13:33 +0700
Subject: [sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible
 with
In-Reply-To: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
References: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
Message-ID: <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>

Hi,

We have a problem with "openstack-tox-docs” CI job, see [1]. It seems like the new version of Sphinx (2.0.0) is not compatible with sphinxcontrib-pecanwsme 0.9.0.

Does anyone know how to better address this? I guess there needs to be a new version of sphinxcontrib-pecanwsme that fixes this bug but I’m not even sure that this project is maintained.


[1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-output.txt.gz#_2019-04-02_04_58_28_249658


Thanks

Renat Akhmerov
@Nokia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/ea45c110/attachment.html>

From manuel.sb at garvan.org.au  Tue Apr  2 06:15:35 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Tue, 2 Apr 2019 06:15:35 +0000
Subject: qemu emulation or virtualiztion, which one is it using?
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>

Hi,

"openstack hypervisor list" command shows qemu as type of hypervisor.
How do I know it is using virtualization and not qemu emulation?

Thank you

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/d4ecea26/attachment.html>

From gkotton at vmware.com  Tue Apr  2 06:21:34 2019
From: gkotton at vmware.com (Gary Kotton)
Date: Tue, 2 Apr 2019 06:21:34 +0000
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>

Hi,
This depends on the virtualization driver configured on your hypervisors. This can be one of many. For example, KVM, VMware VC, Hyper-V...
Thanks
Gary

________________________________
From: Manuel Sopena Ballesteros <manuel.sb at garvan.org.au>
Sent: Tuesday, April 2, 2019 9:15 AM
To: openstack at lists.openstack.org
Subject: qemu emulation or virtualiztion, which one is it using?


Hi,



“openstack hypervisor list” command shows qemu as type of hypervisor.

How do I know it is using virtualization and not qemu emulation?



Thank you



NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/5cb6682d/attachment.html>

From manuel.sb at garvan.org.au  Tue Apr  2 06:37:48 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Tue, 2 Apr 2019 06:37:48 +0000
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
 <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>

Ok,

Thank you for your prompt response. I can see this in the nova.conf file:

[libvirt]
...
virt_type = kvm
...

Can I assume qemu is using virtualization through kvm?

Thank you

Manuel

From: Gary Kotton [mailto:gkotton at vmware.com]
Sent: Tuesday, April 2, 2019 5:22 PM
To: Manuel Sopena Ballesteros; openstack at lists.openstack.org
Subject: Re: qemu emulation or virtualiztion, which one is it using?

Hi,
This depends on the virtualization driver configured on your hypervisors. This can be one of many. For example, KVM, VMware VC, Hyper-V...
Thanks
Gary

________________________________
From: Manuel Sopena Ballesteros <manuel.sb at garvan.org.au>
Sent: Tuesday, April 2, 2019 9:15 AM
To: openstack at lists.openstack.org
Subject: qemu emulation or virtualiztion, which one is it using?


Hi,



"openstack hypervisor list" command shows qemu as type of hypervisor.

How do I know it is using virtualization and not qemu emulation?



Thank you


NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/0cdc5eb0/attachment-0001.html>

From openstack at fried.cc  Tue Apr  2 06:59:51 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 2 Apr 2019 01:59:51 -0500
Subject: [sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
In-Reply-To: <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>
References: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
 <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>
Message-ID: <C3E7FD33-E11F-4371-909E-E90632CD9EDF@fried.cc>

Stephen has been going around fixing these. See for example https://review.openstack.org/#/c/648670/

I'm not sure about the maintainers/releases issue though.

efried

> On Apr 2, 2019, at 01:13, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:
> 
> Hi,
> 
> We have a problem with "openstack-tox-docs” CI job, see [1]. It seems like the new version of Sphinx (2.0.0) is not compatible with sphinxcontrib-pecanwsme 0.9.0.
> 
> Does anyone know how to better address this? I guess there needs to be a new version of sphinxcontrib-pecanwsme that fixes this bug but I’m not even sure that this project is maintained.
> 
> 
> [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-output.txt.gz#_2019-04-02_04_58_28_249658
> 
> 
> Thanks
> 
> Renat Akhmerov
> @Nokia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/9f3175df/attachment.html>

From renat.akhmerov at gmail.com  Tue Apr  2 07:01:00 2019
From: renat.akhmerov at gmail.com (Renat Akhmerov)
Date: Tue, 2 Apr 2019 14:01:00 +0700
Subject: [summit][ptg][mistral] Mistral PTL is at the Summit and the PTG
In-Reply-To: <41bcb3a0-97ef-4fce-83dc-9ce86aabf902@Spark>
References: <41bcb3a0-97ef-4fce-83dc-9ce86aabf902@Spark>
Message-ID: <423ee73a-3a95-4293-8f20-96dc44b33115@Spark>

Hi,

Just want to make sure that people interested in any Mistral discussions know that I’m going to Denver and will be there almost till the end of the PTG. So if you’d like to catch me there, just ping me over email or in IRC (rakhmerov).

Unfortunately, the approval to go was given quite late and we (again) failed to arrange a full event for Mistral. For that reason I don’t expect many Mistral team members to be in Denver. We’ll fix that in future. But for now we’ll have to be satisfied with informal talks.

Some possible reasons why you may want to meet me there:

• You already use Mistral but you need additional features in it and you are not sure wether it’s doable or not
• You are just looking at Mistral as a technology that might be potentially useful for you and you have questions about architecture, use cases, real experience with it etc.
• You’ve already tried Mistral in the past but had issues with it and you’re not sure wether it's worth trying again
• You want to help with the development of the project but you don’t know what to begin with and how to better communicate with us


Also, if anyone thinks I may be useful at some sessions that are somehow related to Mistral then please let me know and I’ll come.


Thanks!

Renat Akhmerov
@Nokia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/93768d25/attachment.html>

From renat.akhmerov at gmail.com  Tue Apr  2 07:09:35 2019
From: renat.akhmerov at gmail.com (Renat Akhmerov)
Date: Tue, 2 Apr 2019 14:09:35 +0700
Subject: [sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
In-Reply-To: <C3E7FD33-E11F-4371-909E-E90632CD9EDF@fried.cc>
References: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
 <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>
 <C3E7FD33-E11F-4371-909E-E90632CD9EDF@fried.cc>
Message-ID: <70cf7d30-097e-4141-8805-d3b1a797b2db@Spark>

Ok, thanks. Good to know :)


Renat
On 2 Apr 2019, 14:00 +0700, Eric Fried <openstack at fried.cc>, wrote:
> Stephen has been going around fixing these. See for example https://review.openstack.org/#/c/648670/
>
> I'm not sure about the maintainers/releases issue though.
>
> efried
>
> On Apr 2, 2019, at 01:13, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:
>
> > Hi,
> >
> > We have a problem with "openstack-tox-docs” CI job, see [1]. It seems like the new version of Sphinx (2.0.0) is not compatible with sphinxcontrib-pecanwsme 0.9.0.
> >
> > Does anyone know how to better address this? I guess there needs to be a new version of sphinxcontrib-pecanwsme that fixes this bug but I’m not even sure that this project is maintained.
> >
> >
> > [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-output.txt.gz#_2019-04-02_04_58_28_249658
> >
> >
> > Thanks
> >
> > Renat Akhmerov
> > @Nokia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/c8439985/attachment.html>

From gkotton at vmware.com  Tue Apr  2 07:26:00 2019
From: gkotton at vmware.com (Gary Kotton)
Date: Tue, 2 Apr 2019 07:26:00 +0000
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
 <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>,
 <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <CO2PR05MB245327E3580B13D446EF2A1BCD560@CO2PR05MB2453.namprd05.prod.outlook.com>

Please see https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html
This should provide you with the information are looking for
OpenStack Docs: KVM<https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html>
Configure Compute backing storage¶. Backing Storage is the storage used to provide the expanded operating system image, and any ephemeral storage.
docs.openstack.org



________________________________
From: Manuel Sopena Ballesteros <manuel.sb at garvan.org.au>
Sent: Tuesday, April 2, 2019 9:37 AM
To: Gary Kotton; openstack at lists.openstack.org
Subject: RE: qemu emulation or virtualiztion, which one is it using?


Ok,



Thank you for your prompt response. I can see this in the nova.conf file:



[libvirt]

…

virt_type = kvm

…



Can I assume qemu is using virtualization through kvm?



Thank you



Manuel



From: Gary Kotton [mailto:gkotton at vmware.com]
Sent: Tuesday, April 2, 2019 5:22 PM
To: Manuel Sopena Ballesteros; openstack at lists.openstack.org
Subject: Re: qemu emulation or virtualiztion, which one is it using?



Hi,

This depends on the virtualization driver configured on your hypervisors. This can be one of many. For example, KVM, VMware VC, Hyper-V...

Thanks

Gary



________________________________

From: Manuel Sopena Ballesteros <manuel.sb at garvan.org.au>
Sent: Tuesday, April 2, 2019 9:15 AM
To: openstack at lists.openstack.org
Subject: qemu emulation or virtualiztion, which one is it using?



Hi,



“openstack hypervisor list” command shows qemu as type of hypervisor.

How do I know it is using virtualization and not qemu emulation?



Thank you



NOTICE

Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/837ba83b/attachment-0001.html>

From ignaziocassano at gmail.com  Tue Apr  2 08:07:39 2019
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 2 Apr 2019 10:07:39 +0200
Subject: [octavia-api][queens] broken pipe
Message-ID: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>

Hello All,
I installed octavia queens with centos and it works but in
/var/log/messages I got a lot of errors like the following:


Apr  2 09:53:15 tst2-osctrl01 octavia-api:
self.RequestHandlerClass(request, client_address, self)
Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
"/usr/lib64/python2.7/SocketServer.py", line 651, in __init__
Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.finish()
Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
"/usr/lib64/python2.7/SocketServer.py", line 710, in finish
Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.wfile.close()
Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
"/usr/lib64/python2.7/socket.py", line 279, in close
Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.flush()
Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
"/usr/lib64/python2.7/socket.py", line 303, in flush
Apr  2 09:53:15 tst2-osctrl01 octavia-api:
self._sock.sendall(view[write_offset:write_offset+buffer_size])
Apr  2 09:53:15 tst2-osctrl01 octavia-api: error: [Errno 32] Broken pipe


octavia-api is under haproxy:

 listen octavia_cluster
  bind 10.102.184.190:9876
  balance  source
option  tcpka
  option  httpchk
option  tcplog
  server tst2-osctrl01 10.102.184.191:9876 check fall 5 inter 2000 rise 2
  server tst2-osctrl02 10.102.184.192:9876 check fall 5 inter 2000 rise 2
  server tst2-osctrl03 10.102.184.193:9876 check fall 5 inter 2000 rise 2

Any help, please ?


Another question is related to openstack command:
Must I use neutron lbbas command or openstack loadbalancer command for
octavia ?

Loadbalancers created with neutron command cannot be shown with openstack
loadbalancer command .

Many thanks
Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/06682003/attachment.html>

From smooney at redhat.com  Tue Apr  2 08:51:16 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 02 Apr 2019 09:51:16 +0100
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
 <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>
 <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <04ca988f9e7b796ecdcba9e32d23bd169ba2285f.camel@redhat.com>

On Tue, 2019-04-02 at 06:37 +0000, Manuel Sopena Ballesteros wrote:
> Ok,
> 
> Thank you for your prompt response. I can see this in the nova.conf file:
> 
> [libvirt]
> ...
> virt_type = kvm
> ...
> 
> Can I assume qemu is using virtualization through kvm?
the short answer is yes the long answer is its using both.

qemu support several accleration drivers for lack of  a better term
kvm,xen and event the mttcg implementaion are all accleration drivers
that qemu can offload some of the compute context (the environment in which
a nova instance executes) it create.

specifically when using kvm the cpu instruction are offloaded via kvm to hardware virtualiastion
functionality in your cpu but devices like virtio-net-pci nics are still emulated by qemu.

this is why cpu architecutres that do not match the host cannot be acclerated with kvm,
qemu offloads the cpu emulation to kvm to virtualise using the host cpu hardware virualisation
feature if available. in doing so that mean the the cpu emulation code in qemu that woudl have
translated the machine instruction from the guest into somethign the host can execute is bypassed
and as a result you cant execute are arm vms on an x86 host with kvm.

you can however use still use other alleration backend like the multi threaded tiny code generator (mttcg)
which is just a muli thread version of qemus defualt non acclerated backend. when using mttcg you are using
pure software emulation that just happens to also execute 1 thread per guest cpu which provides more performance.

so in short the combinaiton of qemu and optionally an acceleration driver and the linux kernel together form a hypervior
that can levgerage hardware virtualisation or software emulation to provide a compute context which can execute a
gust. if virt_type is kvm however you can just say yes its using virtualistiaon to keep it simple but hopefully this has
helped a little.
> 
> Thank you
> 
> Manuel
> 
> From: Gary Kotton [mailto:gkotton at vmware.com]
> Sent: Tuesday, April 2, 2019 5:22 PM
> To: Manuel Sopena Ballesteros; openstack at lists.openstack.org
> Subject: Re: qemu emulation or virtualiztion, which one is it using?
> 
> Hi,
> This depends on the virtualization driver configured on your hypervisors. This can be one of many. For example, KVM,
> VMware VC, Hyper-V...
> Thanks
> Gary
> 
> ________________________________
> From: Manuel Sopena Ballesteros <manuel.sb at garvan.org.au>
> Sent: Tuesday, April 2, 2019 9:15 AM
> To: openstack at lists.openstack.org
> Subject: qemu emulation or virtualiztion, which one is it using?
> 
> 
> Hi,
> 
> 
> 
> "openstack hypervisor list" command shows qemu as type of hypervisor.
> 
> How do I know it is using virtualization and not qemu emulation?
> 
> 
> 
> Thank you
> 
> 
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.



From kchamart at redhat.com  Tue Apr  2 09:32:33 2019
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 2 Apr 2019 11:32:33 +0200
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
 <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>
 <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <20190402093233.GA28897@paraplu>

On Tue, Apr 02, 2019 at 06:37:48AM +0000, Manuel Sopena Ballesteros wrote:
> Ok,
> 
> Thank you for your prompt response. I can see this in the nova.conf file:
> 
> [libvirt]
> ...
> virt_type = kvm
> ...
> 
> Can I assume qemu is using virtualization through kvm?

If `virt_type = kvm` is set, then yes, your instance should be using
KVM.

You can confirm it in a couple of ways:

  - Check that your Nova instance's QEMU process has this in its QEMU
    command-line: "-machine accel=kvm".  (`ps -ef | grep qemu`, and look
    for the relevant process.)

  - SSH into your instance, run `systemd-detect-virt` (or `virt-what` if
    you have it).  It should report 'kvm', if KVM is really being used.

[...]

-- 
/kashyap


From sfinucan at redhat.com  Tue Apr  2 09:46:14 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Tue, 02 Apr 2019 10:46:14 +0100
Subject: [sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
In-Reply-To: <70cf7d30-097e-4141-8805-d3b1a797b2db@Spark>
References: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
 <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>
 <C3E7FD33-E11F-4371-909E-E90632CD9EDF@fried.cc>
 <70cf7d30-097e-4141-8805-d3b1a797b2db@Spark>
Message-ID: <5225eddd511e071bfd4b07552bb7ba831a3f39c7.camel@redhat.com>

I've fixed this and released a 0.10.0 [1]. I'll work through updating
global-requirements now. I would encourage moving away from both this
extension and WSME in general as both have very little activity on them
and I don't imagine that will change going forward. Chris Dent (CC'd)
_might_ have some thoughts on how to approach this, but that's just a
guess.

Stephen

[1] https://pypi.org/project/sphinxcontrib-pecanwsme/0.10.0/

On Tue, 2019-04-02 at 14:09 +0700, Renat Akhmerov wrote:
> Ok, thanks. Good to know :)
> 
> 
> Renat
> On 2 Apr 2019, 14:00 +0700, Eric Fried <openstack at fried.cc>, wrote:
> > Stephen has been going around fixing these. See for example https://review.openstack.org/#/c/648670/
> > 
> > I'm not sure about the maintainers/releases issue though.
> > 
> > efried
> > 
> > On Apr 2, 2019, at 01:13, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:
> > 
> > > Hi,
> > > 
> > > We have a problem with "openstack-tox-docs” CI job, see [1]. It
> > > seems like the new version of Sphinx (2.0.0) is not compatible
> > > with sphinxcontrib-pecanwsme 0.9.0.
> > > 
> > > Does anyone know how to better address this? I guess there needs
> > > to be a new version of sphinxcontrib-pecanwsme that fixes this
> > > bug but I’m not even sure that this project is maintained.
> > > 
> > > 
> > > [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-output.txt.gz#_2019-04-02_04_58_28_249658
> > > 
> > > 
> > > Thanks
> > > 
> > > Renat Akhmerov
> > > @Nokia




From smooney at redhat.com  Tue Apr  2 09:52:04 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 02 Apr 2019 10:52:04 +0100
Subject: qemu emulation or virtualiztion, which one is it using?
In-Reply-To: <20190402093233.GA28897@paraplu>
References: <9D8A2486E35F0941A60430473E29F15B017E896EDB@MXDB1.ad.garvan.unsw.edu.au>
 <CO2PR05MB245348E48BA7D0043D4FD6D5CD560@CO2PR05MB2453.namprd05.prod.outlook.com>
 <9D8A2486E35F0941A60430473E29F15B017E896F43@MXDB1.ad.garvan.unsw.edu.au>
 <20190402093233.GA28897@paraplu>
Message-ID: <f4eee4faf9a4b015fa4bc41e52c6f5d4cfdd370f.camel@redhat.com>

On Tue, 2019-04-02 at 11:32 +0200, Kashyap Chamarthy wrote:
> On Tue, Apr 02, 2019 at 06:37:48AM +0000, Manuel Sopena Ballesteros wrote:
> > Ok,
> > 
> > Thank you for your prompt response. I can see this in the nova.conf file:
> > 
> > [libvirt]
> > ...
> > virt_type = kvm
> > ...
> > 
> > Can I assume qemu is using virtualization through kvm?
> 
> If `virt_type = kvm` is set, then yes, your instance should be using
> KVM.
> 
> You can confirm it in a couple of ways:
> 
>   - Check that your Nova instance's QEMU process has this in its QEMU
>     command-line: "-machine accel=kvm".  (`ps -ef | grep qemu`, and look
>     for the relevant process.)
this should always work
> 
>   - SSH into your instance, run `systemd-detect-virt` (or `virt-what` if
>     you have it).  It should report 'kvm', if KVM is really being used.
not in all cases. you can turn on hypervior hiding which may or may not be viable
to endusers in a public cloud setting.
> 
> [...]
> 



From renat.akhmerov at gmail.com  Tue Apr  2 09:53:46 2019
From: renat.akhmerov at gmail.com (Renat Akhmerov)
Date: Tue, 2 Apr 2019 16:53:46 +0700
Subject: [sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
In-Reply-To: <5225eddd511e071bfd4b07552bb7ba831a3f39c7.camel@redhat.com>
References: <36b0802a-1594-49f0-8823-5a169123b679@Spark>
 <1adbc99f-d770-4e48-a398-c5c68edc51ee@Spark>
 <C3E7FD33-E11F-4371-909E-E90632CD9EDF@fried.cc>
 <70cf7d30-097e-4141-8805-d3b1a797b2db@Spark>
 <5225eddd511e071bfd4b07552bb7ba831a3f39c7.camel@redhat.com>
Message-ID: <1df18fc2-dd78-45d7-b553-b2bdcb33e1d3@Spark>

Thanks!

Renat Akhmerov
@Nokia
On 2 Apr 2019, 16:46 +0700, Stephen Finucane <sfinucan at redhat.com>, wrote:
> I've fixed this and released a 0.10.0 [1]. I'll work through updating
> global-requirements now. I would encourage moving away from both this
> extension and WSME in general as both have very little activity on them
> and I don't imagine that will change going forward. Chris Dent (CC'd)
> _might_ have some thoughts on how to approach this, but that's just a
> guess.
>
> Stephen
>
> [1] https://pypi.org/project/sphinxcontrib-pecanwsme/0.10.0/
>
> On Tue, 2019-04-02 at 14:09 +0700, Renat Akhmerov wrote:
> > Ok, thanks. Good to know :)
> >
> >
> > Renat
> > On 2 Apr 2019, 14:00 +0700, Eric Fried <openstack at fried.cc>, wrote:
> > > Stephen has been going around fixing these. See for example https://review.openstack.org/#/c/648670/
> > >
> > > I'm not sure about the maintainers/releases issue though.
> > >
> > > efried
> > >
> > > On Apr 2, 2019, at 01:13, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > We have a problem with "openstack-tox-docs” CI job, see [1]. It
> > > > seems like the new version of Sphinx (2.0.0) is not compatible
> > > > with sphinxcontrib-pecanwsme 0.9.0.
> > > >
> > > > Does anyone know how to better address this? I guess there needs
> > > > to be a new version of sphinxcontrib-pecanwsme that fixes this
> > > > bug but I’m not even sure that this project is maintained.
> > > >
> > > >
> > > > [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-output.txt.gz#_2019-04-02_04_58_28_249658
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Renat Akhmerov
> > > > @Nokia
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/6fe6d65c/attachment-0001.html>

From kchamart at redhat.com  Tue Apr  2 10:56:51 2019
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 2 Apr 2019 12:56:51 +0200
Subject: [nova] "future" specs and blueprints
In-Reply-To: <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
Message-ID: <20190402105651.GB28897@paraplu>

On Wed, Mar 27, 2019 at 04:10:09PM -0500, Eric Fried wrote:

(Just catching up with this thread, post-PTO.)

[...]

> New proposal: How do folks feel about using the `backlog` directory
> again? Presumably starting with scrubbing the four specs that are in it.

Hi,

I get a nagging feeling at the back of my head whenever I see specs in
the "approved" directory for a given release, but they are not
completed, or needs to be re-proposed for any number of good reasons.

So yes, having this `specs/backlog/approved` does have a benefit (even
if it is 'marginal') than "leaving things as unmerged in Gerrit", where
every spec is a bland Gerrit URL, and their HTML renderings will have
gotten purged.

I agree with you that it gives a "crisper picture" of reality by not
muddying the waters of what is actually completed.  Plus it gives us a
clean, rendered overview of what ideas we thought were worth pursuing
(which, as Gibi noted, will be re-evaluated at the time of transition
from "backlog" to "approved").  And, as you stated in the "Backlog
specifications" section[2] in the README, it can act as a robust
starting point for those (especially for experienced developers) who
want to get involved with Nova.

        * * *

On the topic of merging 'nova-specs' into 'nova' repo, Jeremy raised
some really good points in his repsonse[2].  Unless I see his points
addressed with compelling answers, I'd vote for keeping the 'nova-specs'
repo separate.  (I should admit that I don't know what was the original
impetus for merging it into the 'nova' repo.)

[1] http://logs.openstack.org/00/648800/3/check/openstack-tox-docs/e601952/html/readme.html#backlog-specifications
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004314.html

[...]

-- 
/kashyap


From smooney at redhat.com  Tue Apr  2 11:44:39 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 02 Apr 2019 12:44:39 +0100
Subject: [nova] "future" specs and blueprints
In-Reply-To: <20190402105651.GB28897@paraplu>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <20190402105651.GB28897@paraplu>
Message-ID: <c7f9a17414c22126800a86020039048ba9d9316f.camel@redhat.com>

On Tue, 2019-04-02 at 12:56 +0200, Kashyap Chamarthy wrote:
> On Wed, Mar 27, 2019 at 04:10:09PM -0500, Eric Fried wrote:
> 
> (Just catching up with this thread, post-PTO.)
> 
> [...]
> 
> > New proposal: How do folks feel about using the `backlog` directory
> > again? Presumably starting with scrubbing the four specs that are in it.
> 
> Hi,
> 
> I get a nagging feeling at the back of my head whenever I see specs in
> the "approved" directory for a given release, but they are not
> completed, or needs to be re-proposed for any number of good reasons.
> 
> So yes, having this `specs/backlog/approved` does have a benefit (even
> if it is 'marginal') than "leaving things as unmerged in Gerrit", where
> every spec is a bland Gerrit URL, and their HTML renderings will have
> gotten purged.
well the html rendering are not really useful for reviewign a spec
you might want to look at the near the end when the content is correct so that
the archive form looks nice but i would expects most peopel to read the rst
directly.
> 
> I agree with you that it gives a "crisper picture" of reality by not
> muddying the waters of what is actually completed.
well actully completed specs get copied into the implemented directory.
i dont think we tend to get a lot of future reaching specs. we get some
that can not be completed due to developer or review bandwith in a singel
cycle or that end up haveing depencies that mean the get punted to a follow
up release. i have found most feature related to numa/nfv often take 2-3 cycles
to fully land but that is generally not by intent.
>   Plus it gives us a
> clean, rendered overview of what ideas we thought were worth pursuing
> (which, as Gibi noted, will be re-evaluated at the time of transition
> from "backlog" to "approved").  And, as you stated in the "Backlog
> specifications" section[2] in the README, it can act as a robust
> starting point for those (especially for experienced developers) who
> want to get involved with Nova.
> 
>         * * *
> 
> On the topic of merging 'nova-specs' into 'nova' repo, Jeremy raised
> some really good points in his repsonse[2].  Unless I see his points
> addressed with compelling answers, I'd vote for keeping the 'nova-specs'
> repo separate.
i tought i had fully adressed all of jeremy's questions in 
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004317.html
i abandonded that direction simply because peopel seamed to feel the
git subtree magic need to create a muli root git tree to extract
the spec directory form nova-specs and add it to nova was more hassel then it was worth.
if i missed  one of jeremy's point please respond but i didnt see any of the as a blocker
for this work but perserving the history is something im willing to conceed is slightly
more effort then i would like given the rewards.

>   (I should admit that I don't know what was the original
> impetus for merging it into the 'nova' repo.)
> 
> [1] http://logs.openstack.org/00/648800/3/check/openstack-tox-docs/e601952/html/readme.html#backlog-specifications
> [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004314.html
> 
> [...]
> 



From beagles at redhat.com  Tue Apr  2 12:29:41 2019
From: beagles at redhat.com (Brent Eagles)
Date: Tue, 2 Apr 2019 09:59:41 -0230
Subject: [octavia-api][queens] broken pipe
In-Reply-To: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
References: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
Message-ID: <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>

This looks similar to this bug:
https://bugs.launchpad.net/tripleo/+bug/1815811. The default octavia server
uses wsgiref.simple_server which doesn't appear to deal with haproxy
interaction very well. We are fixing TripleO to run octavia api under
apache instead which appears to fix the problem.

Cheers,

Brent

On Tue, Apr 2, 2019 at 5:44 AM Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Hello All,
> I installed octavia queens with centos and it works but in
> /var/log/messages I got a lot of errors like the following:
>
>
> Apr  2 09:53:15 tst2-osctrl01 octavia-api:
> self.RequestHandlerClass(request, client_address, self)
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
> "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.finish()
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
> "/usr/lib64/python2.7/SocketServer.py", line 710, in finish
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.wfile.close()
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
> "/usr/lib64/python2.7/socket.py", line 279, in close
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.flush()
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
> "/usr/lib64/python2.7/socket.py", line 303, in flush
> Apr  2 09:53:15 tst2-osctrl01 octavia-api:
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
> Apr  2 09:53:15 tst2-osctrl01 octavia-api: error: [Errno 32] Broken pipe
>
>
> octavia-api is under haproxy:
>
>  listen octavia_cluster
>   bind 10.102.184.190:9876
>   balance  source
> option  tcpka
>   option  httpchk
> option  tcplog
>   server tst2-osctrl01 10.102.184.191:9876 check fall 5 inter 2000 rise 2
>   server tst2-osctrl02 10.102.184.192:9876 check fall 5 inter 2000 rise 2
>   server tst2-osctrl03 10.102.184.193:9876 check fall 5 inter 2000 rise 2
>
> Any help, please ?
>
>
> Another question is related to openstack command:
> Must I use neutron lbbas command or openstack loadbalancer command for
> octavia ?
>
> Loadbalancers created with neutron command cannot be shown with openstack
> loadbalancer command .
>
> Many thanks
> Ignazio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/ae2692d6/attachment.html>

From ignaziocassano at gmail.com  Tue Apr  2 12:57:56 2019
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 2 Apr 2019 14:57:56 +0200
Subject: [octavia-api][queens] broken pipe
In-Reply-To: <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>
References: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
 <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>
Message-ID: <CAB7j8cUWVwTEu6wtYczWB58bXgffo1Xgdo+zWqQHPzz55o2y0w@mail.gmail.com>

Many thanls.
Do you know in which openstack version that fix wil be available ?

Regards
Ignazio

Il giorno mar 2 apr 2019 alle ore 14:29 Brent Eagles <beagles at redhat.com>
ha scritto:

> This looks similar to this bug:
> https://bugs.launchpad.net/tripleo/+bug/1815811. The default octavia
> server uses wsgiref.simple_server which doesn't appear to deal with haproxy
> interaction very well. We are fixing TripleO to run octavia api under
> apache instead which appears to fix the problem.
>
> Cheers,
>
> Brent
>
> On Tue, Apr 2, 2019 at 5:44 AM Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
>
>> Hello All,
>> I installed octavia queens with centos and it works but in
>> /var/log/messages I got a lot of errors like the following:
>>
>>
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api:
>> self.RequestHandlerClass(request, client_address, self)
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
>> "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.finish()
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
>> "/usr/lib64/python2.7/SocketServer.py", line 710, in finish
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.wfile.close()
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
>> "/usr/lib64/python2.7/socket.py", line 279, in close
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: self.flush()
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: File
>> "/usr/lib64/python2.7/socket.py", line 303, in flush
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api:
>> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>> Apr  2 09:53:15 tst2-osctrl01 octavia-api: error: [Errno 32] Broken pipe
>>
>>
>> octavia-api is under haproxy:
>>
>>  listen octavia_cluster
>>   bind 10.102.184.190:9876
>>   balance  source
>> option  tcpka
>>   option  httpchk
>> option  tcplog
>>   server tst2-osctrl01 10.102.184.191:9876 check fall 5 inter 2000 rise 2
>>   server tst2-osctrl02 10.102.184.192:9876 check fall 5 inter 2000 rise 2
>>   server tst2-osctrl03 10.102.184.193:9876 check fall 5 inter 2000 rise 2
>>
>> Any help, please ?
>>
>>
>> Another question is related to openstack command:
>> Must I use neutron lbbas command or openstack loadbalancer command for
>> octavia ?
>>
>> Loadbalancers created with neutron command cannot be shown with openstack
>> loadbalancer command .
>>
>> Many thanks
>> Ignazio
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/e94c68ce/attachment.html>

From jaypipes at gmail.com  Tue Apr  2 13:42:00 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 2 Apr 2019 09:42:00 -0400
Subject: [nova] super long online_data_migrations
In-Reply-To: <CAB+ArpZPqOCK1GiVeGmdN55d=pwWT+Vui-yUsOWJneUM_zPygg@mail.gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
 <CAEs876gcpL3nesdzGhnqntubOLh105FfTNFtjMQ=Zz2O3Tm96g@mail.gmail.com>
 <CAB+ArpZPqOCK1GiVeGmdN55d=pwWT+Vui-yUsOWJneUM_zPygg@mail.gmail.com>
Message-ID: <284e8def-666d-bf27-88a1-0d01be3d99df@gmail.com>

On 04/01/2019 05:30 AM, Surya Seetharaman wrote:
> I don't know if there is a good way by which we can persistently store 
> the state of finished migrations to ensure they are not executed ever 
> again (as in not having to make the query) once done.
> It would also be nice to also be able to opt-in into specific migrations 
> specially since these span over releases.

Well, that's another problem with not doing data migrations inside an 
Alembic/sqlalchemy-migrate migration script... you have to re-execute 
the query over and over again to see if a migration is necessary. If the 
data migrations were in the Alembic/sqlalchemy-migrate script, then the 
migrate_version DB table could be used to determine if a migration was 
done and none of this would be an issue.

Best,
-jay


From openstack at fried.cc  Tue Apr  2 13:48:58 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 2 Apr 2019 08:48:58 -0500
Subject: [nova] "future" specs and blueprints
In-Reply-To: <c7f9a17414c22126800a86020039048ba9d9316f.camel@redhat.com>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <20190402105651.GB28897@paraplu>
 <c7f9a17414c22126800a86020039048ba9d9316f.camel@redhat.com>
Message-ID: <9db80f35-82af-f853-5739-dd4a9cabd9a5@fried.cc>

>> So yes, having this `specs/backlog/approved` does have a benefit (even
>> if it is 'marginal') than "leaving things as unmerged in Gerrit", where
>> every spec is a bland Gerrit URL, and their HTML renderings will have
>> gotten purged.

This.

And hard to discover. Which of these (currently 64) unmerged nova specs
[0] are (a) for train, (b) from a previous release but still viable for
consideration, (c) dead? Today I can click through and look for file
paths to determine (a) or not-(a); but I have to go full Sherlock to
figure out (b) vs (c). Or count on the author to ask on IRC, add it to
the PTG agenda, etc.

> well the html rendering are not really useful for reviewign a spec
> you might want to look at the near the end when the content is correct so that
> the archive form looks nice but i would expects most peopel to read the rst
> directly.

Totally personal preference. I read the rendered version any time it's
available. This is especially useful when things like seqdiag are used
([1] vs [2] if you please).

>> I agree with you that it gives a "crisper picture" of reality by not
>> muddying the waters of what is actually completed.
> well actully completed specs get copied into the implemented directory.

Right, so the distinction between "never approved" and "approved for
$release but not implemented" remains the same: unmerged gerrit review
vs specs/$release/approved (but not specs/$release/implemented),
respectively. What we're adding is "approved, but not for $release".

> i dont think we tend to get a lot of future reaching specs.

Part of what pushed me over the edge to want to do this right now was
[3] which I happened to know from talking to the author was intended for
post-Train.

But generally I agree, that's the exception rather than the rule.

However...

> we get some
> that can not be completed due to developer or review bandwith in a singel
> cycle

...this. We could make better use of the backlog directory to stage work
we know is going to take multiple cycles.

>> On the topic of merging 'nova-specs' into 'nova' repo, Jeremy raised
>> some really good points in his repsonse

One of the main original motivations was to remove the concept of
separate "spec cores". This was already accomplished a couple of weeks
ago by adding nova-core to nova-specs-core [4], and the remaining
potential benefits were deemed not worth the trouble.

-efried

[0]
https://review.openstack.org/#/q/project:openstack/nova-specs+status:open
[1]
http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#proposed-change
[2]
https://review.openstack.org/#/c/572583/11/specs/rocky/approved/reshape-provider-tree.rst at 48
[3] https://review.openstack.org/#/c/648665/
[4] https://review.openstack.org/#/admin/groups/302,members


From fungi at yuggoth.org  Tue Apr  2 14:21:31 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Apr 2019 14:21:31 +0000
Subject: [Gerrit][Infra] Marking bot comments in email headers?
In-Reply-To: <CAEd1pt65hGrkM6fEtRBFDmphvSoSci+sz7ktbSRp7CgHHh6E4g@mail.gmail.com>
References: <CAEd1pt65hGrkM6fEtRBFDmphvSoSci+sz7ktbSRp7CgHHh6E4g@mail.gmail.com>
Message-ID: <20190402142130.6feg3bbv7tf2wf2h@yuggoth.org>

On 2019-04-02 14:11:11 +1100 (+1100), Michael Still wrote:
> wouldn't it be cool if we could somehow mark email from gerrit
> that came from a bot? Or inversely, call out email sent by a human
> somehow. That way I could null route all the bot spam and suddenly
> gerrit email would be useful again.
> 
> Is this a thing upstream gerrit supports at all?

The way CI systems and similar automation currently provide feedback
on Gerrit changes is to authenticate with a regular account and
submit a comment just like any normal user. To counter this, we long
ago developed standard naming conventions for those accounts to
simplify client-side filters. We have a couple of outliers ("Zuul"
and "Elastic Recheck") but otherwise you should be able to trust
that any account ending in " CI" or " Bot" is from an automated
source. On my personal mailserver I use filter rules matching on
"$USER has posted comments" in the message body (when found in a
message with a "review.openstack.org" List-Id header) to catch the
bulk of these.

I gather Gerrit's upstream maintainers are working on a new
mechanism specially designed for handling result reporting from CI
systems, so this is probably a great time to engage and suggest that
any E-mail notifications triggered by that feature include easily
parsed headers identifying them as such.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/9b288d07/attachment.sig>

From fungi at yuggoth.org  Tue Apr  2 14:36:22 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Apr 2019 14:36:22 +0000
Subject: [octavia-api][queens] broken pipe
In-Reply-To: <CAB7j8cUWVwTEu6wtYczWB58bXgffo1Xgdo+zWqQHPzz55o2y0w@mail.gmail.com>
References: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
 <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>
 <CAB7j8cUWVwTEu6wtYczWB58bXgffo1Xgdo+zWqQHPzz55o2y0w@mail.gmail.com>
Message-ID: <20190402143622.c367hxioghjvo7j3@yuggoth.org>

On 2019-04-02 14:57:56 +0200 (+0200), Ignazio Cassano wrote:
> Do you know in which openstack version that fix wil be available ?
[...]

(Sorry for not including much context, the top-posting in your reply
has made it extremely difficult to do so.) The "fix" mentioned by
Brent, as I understand, is to simply use Apache with its mod_wsgi
module to serve the API rather than exposing a WSGI service directly
on a socket. If the deployment tooling you're using supports this
operational model then you should simply be able to switch to it at
any time. If your deployment tooling does not yet support this, then
when it appears as an option in a release will depend on the tool in
question. Are you asking when TripleO will switch to that model
because you're using TripleO to manage your OpenStack deployment, or
did you misunderstand the answer?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/fe63f5fa/attachment.sig>

From jaosorior at redhat.com  Tue Apr  2 14:36:46 2019
From: jaosorior at redhat.com (Juan Antonio Osorio Robles)
Date: Tue, 2 Apr 2019 17:36:46 +0300
Subject: [tripleo] disbanding security squad
Message-ID: <471ac376-ae8a-d714-5374-29228b4605c6@redhat.com>

Hello,


So, the security squad hasn't had any activity for some time now. So I'm
disbanding it for the time being. Folks can revive it if the need arises.

The review to remove it from our docs is the following:
https://review.openstack.org/#/c/649346/


Best regards



From fungi at yuggoth.org  Tue Apr  2 14:41:49 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 2 Apr 2019 14:41:49 +0000
Subject: [nova] "future" specs and blueprints
In-Reply-To: <20190402105651.GB28897@paraplu>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <20190402105651.GB28897@paraplu>
Message-ID: <20190402144149.ls57ybt5n4celdxy@yuggoth.org>

On 2019-04-02 12:56:51 +0200 (+0200), Kashyap Chamarthy wrote:
[...]
> So yes, having this `specs/backlog/approved` does have a benefit (even
> if it is 'marginal') than "leaving things as unmerged in Gerrit", where
> every spec is a bland Gerrit URL, and their HTML renderings will have
> gotten purged.
[...]

If the draft rendering has expired and you don't feel like
generating one locally with tox (or even just by calling
sphinx-build directly), you can also leave a "recheck" comment on
the change and come back later.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/54f61d68/attachment.sig>

From mark at stackhpc.com  Tue Apr  2 15:33:42 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Tue, 2 Apr 2019 15:33:42 +0000
Subject: [stable][kolla] EOL kolla ocata branch
In-Reply-To: <af161d60-7e84-ef80-5e3b-0a0d705d9ec2@gmail.com>
References: <CAKZYVLy+7h3RPLGpHkrmxGL+vTFLs5bpGWiCheXG-UGXNfMnXA@mail.gmail.com>
 <CAKZYVLy1hsv9urJicCzLejZcVT+shdJXyjwvDQ1ixoc+Zq2zbA@mail.gmail.com>
 <af161d60-7e84-ef80-5e3b-0a0d705d9ec2@gmail.com>
Message-ID: <CAFHSqWoTn4qEYHFQpvHeZsUZmgrLpnMoiwu7Brvkrh4HXHavPA@mail.gmail.com>

On Fri, 21 Dec 2018 at 14:53, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 12/21/2018 7:58 AM, Eduardo Gonzalez wrote:
> > I don't fully understand what's the process for extended maintenance
> > mode, who is responsible of the management and to take care of it. Is
> > the core group responsible at all of the branch? Change any policy
> > regarding what can be merged, backport, etc?
>
> Details are in [1][2].
>
> The same project stable core team is responsible for the branch, it
> doesn't transfer to some new stable EM core team.
>
> The appropriate fix model is essentially the same - only backport fixes,
> not features, no new dependencies, etc. Gauge risk vs reward as normal.
>
> >
> > Ocata branch has been unmaintained for a few months until a couple of
> > patches fixes before putting into EOL. If someone wants to maintain
> > ocata, I guess we should tag as EM.
>
> Generally if CI is still working for the branch and people are using it,
> and it's not a burden, it's fine to leave it open. If it starts failing
> CI and no one is caring for it (fixing CI issues etc) then it's
> acceptable to move to EOL after 6 months (see the "Unmaintained" section
> in [2]).
>
>
Just pointing out that the last successful run of at least one of the
periodic kolla image publish job was at 2019-01-07T06:06:47. If anyone is
using Ocata and wants to maintain this, please get in touch. Otherwise I
guess we'll mark is as unmaintained on 2019-07-07.

It does seem a bit wasteful of CI resources to have 6 months of failing
periodic jobs. Should we disable them on the ocata branch until a volunteer
steps forward?

> >
> > Should the core group vote this decision or is something decided based
> > of people whiling to maintaining the branch?
>
> It's really up to the core group. If there are people willing to
> maintain the branch outside of the core group, they should work with the
> core group, essentially like a liaison.
>
> [1]
>
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
> [2] https://docs.openstack.org/project-team-guide/stable-branches.html
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/b2fb3465/attachment-0001.html>

From colleen at gazlene.net  Tue Apr  2 17:52:32 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Tue, 02 Apr 2019 13:52:32 -0400
Subject: [dev][keystone] Meeting time
In-Reply-To: <a9f1b4ed-d56a-4eef-bcf0-b053d4d15370@www.fastmail.com>
References: <3b570448-8b6e-4cc5-b95b-bbe5ae1b6728@www.fastmail.com>
 <a9f1b4ed-d56a-4eef-bcf0-b053d4d15370@www.fastmail.com>
Message-ID: <9d2b7cec-1f8a-46cb-ac71-6b0775718adc@www.fastmail.com>

On Wed, Mar 27, 2019, at 9:57 AM, Colleen Murphy wrote:
> On Tue, Mar 19, 2019, at 10:08 PM, Colleen Murphy wrote:
> > As discussed in today's meeting, the end of the cycle is a good time to 
> > revisit the team meeting time. Please fill out the poll:
> > 
> > https://doodle.com/poll/zxv6d2mxngmhb3vc
> > 
> > We'll plan on having next week's meeting at the normal time in the 
> > normal meeting channel and discuss/announce any changes then.
> > 
> > Colleen
> > 
> >
> 
> Gentle prod to fill out this poll so we can try to find a time that's 
> not so terrible for part of our team. We'll hold off deciding a time 
> until a decent number of people have completed it.
> 
> Colleen
> 
>

As discussed in today's meeting, based on the poll results and followup discussion in the meeting, we'll keep the current meeting time and day (Tuesdays 16:00 UTC in #openstack-meeting-alt). Thanks everyone for going through this exercise to try to ensure we're as timezone-inclusive as possible.

Colleen


From stig.openstack at telfer.org  Tue Apr  2 19:10:19 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Tue, 2 Apr 2019 20:10:19 +0100
Subject: [scientific-sig] IRC Meeting today 2100 UTC
Message-ID: <796294BC-B9A4-446D-B827-D64DEFDB83AE@telfer.org>

Hi All - 

We have a Scientific SIG IRC meeting today at 2100 UTC in channel #openstack-meeting.  Everyone is welcome.

Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_2nd_2019

We have a CFP for high-performance containerised workloads, follow-up on the discussion around help most needed for SIGs, and planning for SIG activities at the Denver summit.

Cheers,
Stig



From mihalis68 at gmail.com  Tue Apr  2 19:14:21 2019
From: mihalis68 at gmail.com (Chris Morgan)
Date: Tue, 2 Apr 2019 15:14:21 -0400
Subject: [ops] ops meetups twitter
Message-ID: <CA+NmNoN4++1qhrTOoqFu618p24BDz4dq31q=TQ-9sR4sHLdPHA@mail.gmail.com>

Hey all,
  Those of you who use twitter, please follow
https://twitter.com/osopsmeetup to receive low-volume technical-only
notifications of news relevant to openstack operators, mainly meetups. The
account is run by the OpenStack Ops Meetups team.

Chris

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/a0e16aea/attachment.html>

From openstack at fried.cc  Tue Apr  2 19:47:55 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 2 Apr 2019 14:47:55 -0500
Subject: [nova] Pre-PTG spec review day(s)
Message-ID: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>

Dear Nova spec authors and reviewers-

Since our PTG time is shorter than usual this cycle, and we usually run
out of time before we finish our agenda anyway, I would like to try to
get as much spec review work wrapped up as possible before Denver.

To that end, I would like to propose at least one spec review day over
the next couple of weeks. This will be a chance for authors and
reviewers to interact in a more synchronous fashion and hopefully let us
close on some of the more significant issues.

Can we do this next Tuesday, April 9th; and if necessary (and seeming
productive) the following Tuesday, April 16th?

If folks are amenable, I'll follow up with some logistics by the end of
this week.

Thanks,
efried
.


From mthode at mthode.org  Tue Apr  2 22:40:56 2019
From: mthode at mthode.org (Matthew Thode)
Date: Tue, 2 Apr 2019 17:40:56 -0500
Subject: [release][heat] missing releases on tarballs.openstack.org
Message-ID: <20190402224056.hlg2fu4vckeqsnte@mthode.org>

Hi, there are a few tags missing for heat at
https://tarballs.openstack.org/heat/

The missing releases are 11.0.1 and 12.0.0rc1 at the least.

The cause may be the package name was changed in setup.cfg because it
needed to be openstack-heat to be an available name on pypi.
(via smcginnis).

--
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190402/47ed87da/attachment.sig>

From dangtrinhnt at gmail.com  Wed Apr  3 01:52:30 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 3 Apr 2019 10:52:30 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
Message-ID: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>

Dear TC,

As I am the new PTL for Telemetry in Train [1] and the current cores seem
inactive, I would like to ask the TC team to grant myself <
dangtrinhnt at gmail.com> and Lingxian Kong <anlin.kong at gmail.com> to the core
team of these Telemetry managed projects:

+ ceilometer
+ aodh
+ panko

Next step for me is to re-organize core members and meetings.

Many thanks,

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

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/c5fd6677/attachment.html>

From ignaziocassano at gmail.com  Wed Apr  3 05:33:25 2019
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 3 Apr 2019 07:33:25 +0200
Subject: [octavia-api][queens] broken pipe
In-Reply-To: <20190402143622.c367hxioghjvo7j3@yuggoth.org>
References: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
 <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>
 <CAB7j8cUWVwTEu6wtYczWB58bXgffo1Xgdo+zWqQHPzz55o2y0w@mail.gmail.com>
 <20190402143622.c367hxioghjvo7j3@yuggoth.org>
Message-ID: <CAB7j8cUR9rjeeSSOkqGjZtVG+6BxdrtNRmSec7j3okRK-Be9+g@mail.gmail.com>

Hello, thanks for tour answer.
I am not using tripleo but I installed openstack manually  in high
availability using haproxy.
I understood fine the issue is caused by haproxy when it tries to check
Octavia api controllers and octavia api in not under apache.
Will tripleo modify haproxy rules or it will out octavia api under apache?
In the second case, is there any document for moving octavia api under
apache in Centos 7 environments ?
Regards
ignazio



Il Mar 2 Apr 2019 16:39 Jeremy Stanley <fungi at yuggoth.org> ha scritto:

> On 2019-04-02 14:57:56 +0200 (+0200), Ignazio Cassano wrote:
> > Do you know in which openstack version that fix wil be available ?
> [...]
>
> (Sorry for not including much context, the top-posting in your reply
> has made it extremely difficult to do so.) The "fix" mentioned by
> Brent, as I understand, is to simply use Apache with its mod_wsgi
> module to serve the API rather than exposing a WSGI service directly
> on a socket. If the deployment tooling you're using supports this
> operational model then you should simply be able to switch to it at
> any time. If your deployment tooling does not yet support this, then
> when it appears as an option in a release will depend on the tool in
> question. Are you asking when TripleO will switch to that model
> because you're using TripleO to manage your OpenStack deployment, or
> did you misunderstand the answer?
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/69d42b63/attachment-0001.html>

From manuel.sb at garvan.org.au  Wed Apr  3 06:18:46 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Wed, 3 Apr 2019 06:18:46 +0000
Subject: NVMe PCI-passthrough
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>

Dear Openstack community,

I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason it is not working.

This is my physical host details:

[root at zeus-59 ~]# lspci -nn -D | grep -i ssd
0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)

My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm

This is how I identify the block devices for each pci device:

[root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme
total 0
drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme0
[root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme
total 0
drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme1

I installed the OS on the physical machine leaving those 2 drives intact:

[root at zeus-59 ~]# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    0 59.6G  0 disk
├─sda1        8:1    0    1G  0 part /boot
└─sda2        8:2    0    4G  0 part [SWAP]
sr0          11:0    1  906M  0 rom
nvme0n1     259:15   0  1.8T  0 disk
nvme1n1     259:0    0  1.8T  0 disk
nvme2n1     259:11   0  1.8T  0 disk
└─nvme2n1p1 259:12   0  1.8T  0 part /var/lib/docker/btrfs
nvme3n1     259:6    0  1.8T  0 disk
└─nvme3n1p1 259:7    0  1.8T  0 part
nvme4n1     259:13   0  1.8T  0 disk
└─nvme4n1p1 259:14   0  1.8T  0 part
nvme5n1     259:5    0  1.8T  0 disk
└─nvme5n1p1 259:8    0  1.8T  0 part
nvme6n1     259:17   0  1.8T  0 disk
└─nvme6n1p1 259:18   0  1.8T  0 part
nvme7n1     259:9    0  1.8T  0 disk
└─nvme7n1p1 259:10   0  1.8T  0 part
nvme8n1     259:3    0  1.8T  0 disk
└─nvme8n1p1 259:4    0  1.8T  0 part
nvme9n1     259:1    0  1.8T  0 disk
└─nvme9n1p1 259:2    0  1.8T  0 part

The next thing is to configure Openstack

nova api config

[pci]
alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}


nova scheduler config

[filter_scheduler]
enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
available_filters = nova.scheduler.filters.all_filters


nova compute config

[filter_scheduler]
enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
available_filters = nova.scheduler.filters.all_filters

[pci]
passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ]
alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}


Then I create my flavor
openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1"


I created the vm towards the host with the free nvme drives

[root at openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small


Vm creation fails and I can see this error in the nova compute logs

2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain with XML: <domain type='kvm'>
  <name>instance-00000090</name>
...
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
...
2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support passthrough of host PCI devices

Any idea or advice would be very helpful

Thank you very much
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/73e790f0/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr  3 06:32:16 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 3 Apr 2019 15:32:16 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
Message-ID: <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>

Hi Lingxian. That should work for me too even though it's a little bit
early :)

Rong Zhu, Matthias, please tell us your available time slots for the
meeting.

Thank guys,



On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com> wrote:

> Hi Trinh,
>
> I'm available from 22:00 - 04:30 in UTC
>
> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud
>
>
> On Tue, Apr 2, 2019 at 5:20 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:
>
>> Hi team,
>>
>> As we discussed last time [1], the Telemetry team needs help to maintain
>> its projects in Train. I and Lingxian Kong [2] will give it a try this
>> cycle hopefully will keep Telemetry as healthy as possible.
>>
>> I would like to kick start Telemetry in Train by calling for a team
>> meeting this week to figure out what really happening and plan for actions
>> in Train.
>>
>>    - IRC Channel: #openstack-telemetry
>>    - Time: TBD (dangtrinhnt UTC+9)
>>    - Discussion etherpad (put your name to the attendee list):
>>    https://etherpad.openstack.org/p/telemetry-train
>>
>> Please reply here or ping me on the IRC channel (dangtrinhnt) what your
>> options are and we will set up the meeting.
>>
>> Moreover, I would like to ask the current core members of Telemetry to
>> grant me and Lingxian Kong core reviewers privileges on all of the
>> Telemetry projects on Gerrit (ceilometer, aodh, panko, etc.).
>>
>> Thanks and love to talk to you soon.
>>
>> Yours,
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.html
>> [2] https://review.openstack.org/#/c/645122/
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/467ecb72/attachment-0001.html>

From amoralej at redhat.com  Wed Apr  3 07:47:44 2019
From: amoralej at redhat.com (Alfredo Moralejo Alonso)
Date: Wed, 3 Apr 2019 09:47:44 +0200
Subject: [release][heat] missing releases on tarballs.openstack.org
In-Reply-To: <20190402224056.hlg2fu4vckeqsnte@mthode.org>
References: <20190402224056.hlg2fu4vckeqsnte@mthode.org>
Message-ID: <CACrbaxikuyYLce-G9Yfz8dxJCJUES77dTtGXU++3m4id-aMn4g@mail.gmail.com>

On Wed, Apr 3, 2019 at 12:41 AM Matthew Thode <mthode at mthode.org> wrote:

> Hi, there are a few tags missing for heat at
> https://tarballs.openstack.org/heat/
>
> The missing releases are 11.0.1 and 12.0.0rc1 at the least.
>

and 10.0.3.


> The cause may be the package name was changed in setup.cfg because it
> needed to be openstack-heat to be an available name on pypi.
> (via smcginnis).
>
> --
> Matthew Thode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/08a93550/attachment.html>

From ignaziocassano at gmail.com  Wed Apr  3 08:17:36 2019
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Wed, 3 Apr 2019 10:17:36 +0200
Subject: [octavia-api][queens] broken pipe
In-Reply-To: <20190402143622.c367hxioghjvo7j3@yuggoth.org>
References: <CAB7j8cUW9ZF9gyWH4ofe=MVmnbz9a6M7zZSY61v0g6eit0V75w@mail.gmail.com>
 <CADnDpCZA8DJifPEPqtscA+ivF_ZN0kCms4MC8LsOmV6WaZduRQ@mail.gmail.com>
 <CAB7j8cUWVwTEu6wtYczWB58bXgffo1Xgdo+zWqQHPzz55o2y0w@mail.gmail.com>
 <20190402143622.c367hxioghjvo7j3@yuggoth.org>
Message-ID: <CAB7j8cXYigg_3585mvQVi-82SwPc8sr0HtU+jN3G-Cm9wOrO1A@mail.gmail.com>

Hello,
I solved using ocatvia-api under apache ,
I created a file under /etc/httpd/conf.d .
The file in octavia-api.conf:

Listen controlleraddress:9876

<VirtualHost *:9876>

    WSGIDaemonProcess octavia-wsgi user=octavia group=octavia processes=5
threads=1 display-name=%{GROUP}
    WSGIProcessGroup octavia-wsgi
    WSGIScriptAlias / /usr/local/bin/octavia-wsgi
    WSGIApplicationGroup %{GLOBAL}

    ErrorLog /var/log/httpd/octavia-wsgi.log

    <Directory /usr/local/bin/>
        WSGIProcessGroup octavia-wsgi
        <IfVersion >= 2.4>
            Require all granted
        </IfVersion>
        <IfVersion < 2.4>
            Order allow,deny
            Allow from all
        </IfVersion>
    </Directory>


Il giorno mar 2 apr 2019 alle ore 16:39 Jeremy Stanley <fungi at yuggoth.org>
ha scritto:

> On 2019-04-02 14:57:56 +0200 (+0200), Ignazio Cassano wrote:
> > Do you know in which openstack version that fix wil be available ?
> [...]
>
> (Sorry for not including much context, the top-posting in your reply
> has made it extremely difficult to do so.) The "fix" mentioned by
> Brent, as I understand, is to simply use Apache with its mod_wsgi
> module to serve the API rather than exposing a WSGI service directly
> on a socket. If the deployment tooling you're using supports this
> operational model then you should simply be able to switch to it at
> any time. If your deployment tooling does not yet support this, then
> when it appears as an option in a release will depend on the tool in
> question. Are you asking when TripleO will switch to that model
> because you're using TripleO to manage your OpenStack deployment, or
> did you misunderstand the answer?
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/ea4e3a6e/attachment.html>

From chkumar246 at gmail.com  Wed Apr  3 08:44:25 2019
From: chkumar246 at gmail.com (Chandan kumar)
Date: Wed, 3 Apr 2019 14:14:25 +0530
Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update
 XVII - Apr 03, 2019
Message-ID: <CAMzQOdmQdFM+Pzi2-FMJe-sYAL4ZJYdvPkCp=B+eWNGnWnA-uA@mail.gmail.com>

Hello,

Here is the 17th update (Mar 27 to Apr 02, 2019) on collaboration
on os_tempest[1] role between TripleO and OpenStack-Ansible projects.

Highlights of the week:
* os_tempest got support of new source build process using python_venv_build
  role and it removes tempest_developer_mode from the os_tempest var
* keystone_service_internaluri_insecure var got removed from
  os_tempest playbook and tempest_tempest_conf_overrides is passed to handle
  tempestconf overrides using zuul jobs.

Thanks to odyssey4me, jrosser and mnaser for helping on new source
build process patch.

Things got merged:
os_tempest:
* Reuse tempest_tempest_conf_overrides in tempestconf extra args -
https://review.openstack.org/648137
* Update role for new source build process - https://review.openstack.org/648026
* Test using integrated build - https://review.openstack.org/648580

tripleo
* Update os_tempest playbook var for source install -
https://review.openstack.org/648617
* Add tempest_tempest_conf_overrides to fs overrides -
https://review.openstack.org/648373
* Remove keystone_service_internaluri_insecure var from os_tempest -
https://review.openstack.org/647782

Things in progress:
os_tempest:
* user guide - https://review.openstack.org/#/c/644570/

tripleo
* Introduce tempest_services var for installing tempest_plugins -
https://review.openstack.org/#/c/648678/
* Add tempest_test_whitelist to allowed_override -
https://review.openstack.org/648110
* Remove the tempest_test_whitelist from playbook -
https://review.openstack.org/648111

What is coming for next week?
* Arx is working on moving vars from os_tempest tripleo playbook to
zuul var overrides so
  that it will be consumable while porting tripleo standalone scenario
jobs to os_tempest.


Here is the 16th update [2]. Have queries, Feel free to ping us on
#tripleo or #openstack-ansible channel.

Links:
[1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest
[2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004270.html

Thanks,

Chandan Kumar


From thierry at openstack.org  Wed Apr  3 09:10:18 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 3 Apr 2019 11:10:18 +0200
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
Message-ID: <14435d5f-fa1e-3b81-7a62-fa0343502c38@openstack.org>

Trinh Nguyen wrote:
> As I am the new PTL for Telemetry in Train [1] and the current cores 
> seem inactive, I would like to ask the TC team to grant myself 
> <dangtrinhnt at gmail.com <mailto:dangtrinhnt at gmail.com>> and Lingxian Kong 
> <anlin.kong at gmail.com <mailto:anlin.kong at gmail.com>> to the core team of 
> these Telemetry managed projects:
> 
> + ceilometer
> + aodh
> + panko
> 
> Next step for me is to re-organize core members and meetings.

As the PTL should ultimately decide who is on the core reviewers group, 
I support/second this request. TC members can't directly force Gerrit 
group contents but I expect the infra team will be able to help.

-- 
Thierry Carrez


From thierry at openstack.org  Wed Apr  3 09:12:23 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 3 Apr 2019 11:12:23 +0200
Subject: [release][heat] missing releases on tarballs.openstack.org
In-Reply-To: <CACrbaxikuyYLce-G9Yfz8dxJCJUES77dTtGXU++3m4id-aMn4g@mail.gmail.com>
References: <20190402224056.hlg2fu4vckeqsnte@mthode.org>
 <CACrbaxikuyYLce-G9Yfz8dxJCJUES77dTtGXU++3m4id-aMn4g@mail.gmail.com>
Message-ID: <fc406e93-871c-8fc2-3082-f12df1656538@openstack.org>

Alfredo Moralejo Alonso wrote:
> 
> 
> On Wed, Apr 3, 2019 at 12:41 AM Matthew Thode <mthode at mthode.org 
> <mailto:mthode at mthode.org>> wrote:
> 
>     Hi, there are a few tags missing for heat at
>     https://tarballs.openstack.org/heat/
> 
>     The missing releases are 11.0.1 and 12.0.0rc1 at the least.
> 
> 
> and 10.0.3.

Yes we should probably have 11.0.2 12.0.0.0rc2 and 10.0.4 releases once 
the tarball name mismatch issue is handled.

-- 
Thierry Carrez (ttx)


From sfinucan at redhat.com  Wed Apr  3 09:20:09 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Wed, 03 Apr 2019 10:20:09 +0100
Subject: NVMe PCI-passthrough
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <6b3d5a50a39759ebe4547080c93225d56fb6c78c.camel@redhat.com>

On Wed, 2019-04-03 at 06:18 +0000, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
>  
> I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason it is not working.
>  
> This is my physical host details:
>  
> [root at zeus-59 ~]# lspci -nn -D | grep -i ssd
> 0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
>  
> My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm
>  
> This is how I identify the block devices for each pci device:
>  
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme0
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme1
>  
> I installed the OS on the physical machine leaving those 2 drives intact:
>  
> [root at zeus-59 ~]# lsblk
> NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> sda           8:0    0 59.6G  0 disk
> ├─sda1        8:1    0    1G  0 part /boot
> └─sda2        8:2    0    4G  0 part [SWAP]
> sr0          11:0    1  906M  0 rom
> nvme0n1     259:15   0  1.8T  0 disk
> nvme1n1     259:0    0  1.8T  0 disk
> nvme2n1     259:11   0  1.8T  0 disk
> └─nvme2n1p1 259:12   0  1.8T  0 part /var/lib/docker/btrfs
> nvme3n1     259:6    0  1.8T  0 disk
> └─nvme3n1p1 259:7    0  1.8T  0 part
> nvme4n1     259:13   0  1.8T  0 disk
> └─nvme4n1p1 259:14   0  1.8T  0 part
> nvme5n1     259:5    0  1.8T  0 disk
> └─nvme5n1p1 259:8    0  1.8T  0 part
> nvme6n1     259:17   0  1.8T  0 disk
> └─nvme6n1p1 259:18   0  1.8T  0 part
> nvme7n1     259:9    0  1.8T  0 disk
> └─nvme7n1p1 259:10   0  1.8T  0 part
> nvme8n1     259:3    0  1.8T  0 disk
> └─nvme8n1p1 259:4    0  1.8T  0 part
> nvme9n1     259:1    0  1.8T  0 disk
> └─nvme9n1p1 259:2    0  1.8T  0 part
>  
> The next thing is to configure Openstack
>  
> nova api config
>  
> [pci]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
>  
>  
> nova scheduler config
>  
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
>  
>  
> nova compute config
>  
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
>  
> [pci]
> passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
>  
>  
> Then I create my flavor
> openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1"
>  
>  
> I created the vm towards the host with the free nvme drives
>  
> [root at openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small
>  
>  
> Vm creation fails and I can see this error in the nova compute logs
>  
> 2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain with XML: <domain type='kvm'>
>   <name>instance-00000090</name>
> …
>   <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>     </disk>
> …
> 2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support passthrough of host PCI devices

This error suggests you haven't enabled IOMMU. See the troubleshooting
section of this page for more information:

  http://ask.xmodulo.com/pci-passthrough-virt-manager.html

If this isn't called out in the docs, it should be.

Stephen

> Any idea or advice would be very helpful



From yamamoto at midokura.com  Wed Apr  3 09:33:08 2019
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Wed, 3 Apr 2019 18:33:08 +0900
Subject: [taas] tap-as-a-service tempest plugin going to move
Message-ID: <CAH=wFzR8AQ8JdeyiRPuR+W=v7neef+xvE0Kca1vxMgTdEkJm1w@mail.gmail.com>

hi,

tap-as-a-service tempest plugin is going to be moved into
a separate branch-less repository. [1][2]
i'm not sure what projects are using the plugin for their jobs.
(thus this heads-up)
i will update networking-midonet jobs. [3]

[1] https://github.com/openstack/tap-as-a-service-tempest-plugin
[2] https://review.openstack.org/#/c/649304/
[3] https://review.openstack.org/#/c/649309/


From thierry at openstack.org  Wed Apr  3 09:34:29 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 3 Apr 2019 11:34:29 +0200
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
Message-ID: <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>

Ben Nemec wrote:
> On 4/1/19 2:59 PM, Michael Still wrote:
>> On Tue, Apr 2, 2019 at 5:06 AM Ben Nemec <openstack at nemebean.com 
>> <mailto:openstack at nemebean.com>> wrote:
>>
>> [snip]
>>     This matches my understanding of the intent behind privsep. 
>> Instead of
>>     trying to figure out how to filter out dangerous paths or 
>> whatever, you
>>     have the privileged code build the path out of sanitized data passed
>>     in.
>>     You still have to be careful about preventing injection attacks 
>> (say I
>>     pass in [uuid]/../../..), but at least you don't have to try to 
>> write a
>>     rootwrap filter for every possible path in every possible driver. The
>>     privileged driver code itself knows the correct path and won't allow
>>     anything else.
>>
>> I don't think anyone disputes that theory.
>>
>> The issue here is that the calling code in nova makes that very hard 
>> in some cases. For example, nova.privsep.path.readfile exists because 
>> it is called by nova.virt.disk.localfs.read_file [1], which takes a 
>> raw path to read. That is in turn used by calling code to read at 
>> least two paths that are generated in calling code. Now all of that is 
>> fixable, and that's a relatively simple example, but it requires a 
>> call by call analysis that is quite expensive to do and will cause a 
>> lot of code churn to fix.
>>
>> No one is saying we shouldn't do it. However, the current privsep code 
>> took the approach of an incremental improvement on top of what we 
>> already had, instead of attempting to boil the ocean in a single patch 
>> series. The code for nova.virt.disk.localfs.read_file used to call a 
>> method called read_file_as_root that was just as bad as what we have 
>> now, but used rootwrap to cat arbitrary files in the filesystem (git 
>> sha f535e8bb9905b5632416135af5789704db6d2867 is the original transition).
>>
>> My point is that we need to start somewhere, and proposing that we 
>> abandon privsep entirely because its not immediately perfect isn't 
>> very helpful.
> 
> For the record, that was not at all my intent. It doesn't sound to me 
> like the current privsep implementation is meaningfully worse than using 
> rootwrap, and it seems to me that it should be much easier (note: 
> easier, not easy) to move forward now that everything is using privsep. 
> I was just +1'ing the desired end state of privsep calls not taking 
> paths as input anymore.

Also, the reason why the calling Nova code has generic things like 
nova.virt.disk.localfs.read_file is because rootwrap /encouraged/ 
reusing generic filters across calling code. I see the privsep 
transition as having 3 steps:

1- introduce privsep
2- change rootwrap calls into generic privsep functions
3- start refactoring calling code so that generic privsep functions can 
be replaced by narrow, context-aware functions

You can tackle (2) and (3) at the same time. You get performance gains 
as soon as you start doing (2) bits, but you won't really gain security 
until (3) bits are completed for all the actually-this-means-root 
generic functions.

So I'm not sure we should "immediately stop adding or using generic 
privsep functions" as they don't really make the situation worse than it 
already is security-wise. For *new* features we should definitely avoid 
the privsep generic functions antipattern -- but transforming a generic 
rootwrap call into a generic privsep function still sounds like a gain.

It would be good to describe the antipattern and how to write "good" 
privsep functions though, if only to be able to point developers and 
reviewers to that. Suggestions on where we could do that?

-- 
Thierry Carrez (ttx)


From berendt at betacloud-solutions.de  Wed Apr  3 10:12:27 2019
From: berendt at betacloud-solutions.de (Christian Berendt)
Date: Wed, 3 Apr 2019 12:12:27 +0200
Subject: [stable][kolla] EOL kolla ocata branch
In-Reply-To: <CAFHSqWoTn4qEYHFQpvHeZsUZmgrLpnMoiwu7Brvkrh4HXHavPA@mail.gmail.com>
References: <CAKZYVLy+7h3RPLGpHkrmxGL+vTFLs5bpGWiCheXG-UGXNfMnXA@mail.gmail.com>
 <CAKZYVLy1hsv9urJicCzLejZcVT+shdJXyjwvDQ1ixoc+Zq2zbA@mail.gmail.com>
 <af161d60-7e84-ef80-5e3b-0a0d705d9ec2@gmail.com>
 <CAFHSqWoTn4qEYHFQpvHeZsUZmgrLpnMoiwu7Brvkrh4HXHavPA@mail.gmail.com>
Message-ID: <0A7D1B1B-7BAF-4A40-AC1D-B3D60E6D19BA@betacloud-solutions.de>

Hello Mark.

> On 2. Apr 2019, at 17:33, Mark Goddard <mark at stackhpc.com> wrote:
> 
> It does seem a bit wasteful of CI resources to have 6 months of failing periodic jobs. Should we disable them on the ocata branch until a volunteer steps forward?

I’d be in favour of that.

If someone is still actively building Ocata and needs the CI, the errors would have to be corrected first anyway.

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: berendt at betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139



From e0ne at e0ne.info  Wed Apr  3 12:33:12 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Wed, 3 Apr 2019 15:33:12 +0300
Subject: [horizon] Unused xstatic-* projects retirement
In-Reply-To: <CAGocpaF3V-P2GdzEuD0xittYHpzrenSxszYNWJYuPK9jBL6TbQ@mail.gmail.com>
References: <CAGocpaFbiqNhTV3nKX1tpoHD-wTFdJ+C5=dj5Mt0RKG3n=0sig@mail.gmail.com>
 <985ba1a5-d5de-b5d8-91f0-2e92fca1b00e@alumni.enseeiht.fr>
 <CAGocpaF3V-P2GdzEuD0xittYHpzrenSxszYNWJYuPK9jBL6TbQ@mail.gmail.com>
Message-ID: <CAGocpaGn3FZ6Nn+X6+dRroiVTaDhdDH6+dO=gqVruMH0mRYdgA@mail.gmail.com>

Hi all,

After checking xstatic-* usages using https://libraries.io/pypi/, I've
found only two libraries which are not used anywhere:
* xstatic-angular-ui-router
* xstatic-vis

These packages will be marked as retired.

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


On Fri, Jan 18, 2019 at 9:32 PM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> Thank you Clark, Francios,
>
> My bad, I just checked via codesearch.openstack.org. I'll double check
> for pypi dependencies and update my patch.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Wed, Jan 16, 2019 at 11:37 PM François Magimel <
> francois.magimel at alumni.enseeiht.fr> wrote:
>
>> Hi !
>>
>> Le 16/01/2019 à 14:15, Ivan Kolodyazhny a écrit :
>>
>> Hi team,
>>
>> There are some xstatic packages which I didn't start to use in Horizon or
>> plugins. We didn't do any release of them.
>>
>> During the last meeting [1] we agreed to mark them as retired. I'll start
>> retired procedure [2] today. If you're going to use them, please let me
>> know.
>>
>> The list of the projects to be retired:
>> - xstatic-angular-ui-router
>> - xstatic-bootstrap-datepicker
>> - xstatic-hogan
>> - xstatic-jquery-migrate
>> - xstatic-jquery.quicksearch
>> - xstatic-jquery.tablesorter
>> - xstatic-rickshaw
>>
>>
>> We have some work in progress [2] in the CloudKitty dashboard plugin to
>> use xstatic-rickshaw instead of including the JS script our the repo.
>>
>> [2] https://storyboard.openstack.org/#!/story/2003578
>>
>> François
>>
>>
>> - xstatic-spin
>> - xstatic-vis
>>
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.02.log.html#l-110
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/4a668963/attachment.html>

From smooney at redhat.com  Wed Apr  3 12:37:10 2019
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 03 Apr 2019 13:37:10 +0100
Subject: NVMe PCI-passthrough
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <79abd755096b06063f81ec87c1574b2969290383.camel@redhat.com>

On Wed, 2019-04-03 at 06:18 +0000, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
> 
> I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason
> it is not working.
> 
> This is my physical host details:
> 
> [root at zeus-59 ~]# lspci -nn -D | grep -i ssd
> 0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 
> My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm
> 
> This is how I identify the block devices for each pci device:
> 
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme0
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme1
> 
> I installed the OS on the physical machine leaving those 2 drives intact:
> 
> [root at zeus-59 ~]# lsblk
> NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> sda           8:0    0 59.6G  0 disk
> ├─sda1        8:1    0    1G  0 part /boot
> └─sda2        8:2    0    4G  0 part [SWAP]
> sr0          11:0    1  906M  0 rom
> nvme0n1     259:15   0  1.8T  0 disk
> nvme1n1     259:0    0  1.8T  0 disk
> nvme2n1     259:11   0  1.8T  0 disk
> └─nvme2n1p1 259:12   0  1.8T  0 part /var/lib/docker/btrfs
> nvme3n1     259:6    0  1.8T  0 disk
> └─nvme3n1p1 259:7    0  1.8T  0 part
> nvme4n1     259:13   0  1.8T  0 disk
> └─nvme4n1p1 259:14   0  1.8T  0 part
> nvme5n1     259:5    0  1.8T  0 disk
> └─nvme5n1p1 259:8    0  1.8T  0 part
> nvme6n1     259:17   0  1.8T  0 disk
> └─nvme6n1p1 259:18   0  1.8T  0 part
> nvme7n1     259:9    0  1.8T  0 disk
> └─nvme7n1p1 259:10   0  1.8T  0 part
> nvme8n1     259:3    0  1.8T  0 disk
> └─nvme8n1p1 259:4    0  1.8T  0 part
> nvme9n1     259:1    0  1.8T  0 disk
> └─nvme9n1p1 259:2    0  1.8T  0 part
> 
> The next thing is to configure Openstack
> 
> nova api config
> 
> [pci]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
> 
> 
> nova scheduler config
> 
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter,
> ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
> 
> 
> nova compute config
> 
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter,
> ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
> 
> [pci]
> passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
> 
> 
> Then I create my flavor
> openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1"
> 
> 
> I created the vm towards the host with the free nvme drives
> 
> [root at openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --
> security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small
> 
> 
> Vm creation fails and I can see this error in the nova compute logs
> 
> 2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae
> 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain
> with XML: <domain type='kvm'>
>   <name>instance-00000090</name>
> ...
>   <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>     </disk>
> ...
> 2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae
> 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-
> 8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support
> passthrough of host PCI devices
> 
> Any idea or advice would be very helpful
you have not provided you the kernel command line you have on the hsot but i woudl guess you are missing

intel_iommu=on iommu=pt

puthing the iommu in passthough mode "iommu=pt" may not be required dependign on how the device will be used.
there is a similar option for AMD systesm amd_iommu if you are not on an intel plathform.
https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html

> 
> Thank you very much
as a side note you may want to contact your system adminstarotr or update you email client setting as
the question of if we can leagal respond to email with notices such as V has been rasied in the past.
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.



From florian.engelmann at everyware.ch  Wed Apr  3 12:38:17 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Wed, 3 Apr 2019 14:38:17 +0200
Subject: [neutron] question: default QoS rule for all routers/fip and all
 future once
In-Reply-To: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
Message-ID: <d60abeda-089f-2554-2a70-f6d9a55b7d8e@everyware.ch>

Hi,

the documentation about neutron and QoS talks about setting a default 
QoS rule for a project.

"Each project can have at most one default QoS policy, although it is 
not mandatory. If a default QoS policy is defined, all new networks 
created within this project will have this policy assigned, as long as 
no other QoS policy is explicitly attached during the creation process. 
If the default QoS policy is unset, no change to existing networks will 
be made.

In order to set a QoS policy as default, the parameter --default must be 
used. To unset this QoS policy as default, the parameter --no-default 
must be used."

So if a cloud provider wants to limit all router egress traffic to eg. 
1Gbits this policy has to be set as default to all projects. But what if 
the customer is allowed to create new projects? This project will not 
have any default policy applied, right?

And it looks like the is no API/logic in place to allow a self service 
customer to choose between different "network flavors"?
Is something like that on the roadmap?

All the best,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/7a41e436/attachment.bin>

From e0ne at e0ne.info  Wed Apr  3 12:54:24 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Wed, 3 Apr 2019 15:54:24 +0300
Subject: [horizon] Proposing Vishal Manchanda (vishalmanchanda) for core
Message-ID: <CAGocpaGn5B+VbPc6=OF4V+mG+8V0M-i6AgoVcubnOvV7YcLbLQ@mail.gmail.com>

Hi everybody,

I would like to propose adding vishalmanchanda to the horizon-core team.

Vishal did a great contribution during the last six months both with
commits [1]  and reviews [2],[3].

He fixed a lot of bugs not only in a master branch but in stable branches
too. Regular quality reviews during the last cycles show that he's on the
same page with the rest of the team and understands the code base well too.

If there are no objections, I'll add Vishal to the horizon-core team in a
week.

[1]
https://review.openstack.org/#/q/owner:manchandavishal143%2540gmail.com+status:merged+project:openstack/horizon
[2] https://www.stackalytics.com/report/contribution/horizon-group/90
[3] https://www.stackalytics.com/report/contribution/horizon-group/180

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/069b360d/attachment.html>

From openstack at fried.cc  Wed Apr  3 13:15:05 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 3 Apr 2019 08:15:05 -0500
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
 <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
Message-ID: <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>

> 1- introduce privsep
> 2- change rootwrap calls into generic privsep functions
> 3- start refactoring calling code so that generic privsep functions can
> be replaced by narrow, context-aware functions
> 
> You can tackle (2) and (3) at the same time.

In Nova at least, (2) (without (3)) already has patches proposed all the
way up [A], so I'm going to go out on a limb and say we're going to wait
to tackle (3) until after that series [B], at least for existing code.

> It would be good to describe the antipattern and how to write "good"
> privsep functions though, if only to be able to point developers and
> reviewers to that. Suggestions on where we could do that?
Agree with this for sure. I understand the rootwrap->privsep thing well
enough to review the existing series, but will need help understanding
how (3) will need to look.

Long-term, the document should obviously live somewhere
non-project-specific, and I don't know where that would be.
Short(er)-term, since we have momentum on the issue in Nova, as well as
a clear picture of all the places it needs to be applied (thanks to
(2)/[A]), how about we include it in a Nova spec, since we're going to
need one anyway?

-efried

[A]
https://review.openstack.org/#/q/topic:my-own-personal-alternative-universe+(status:open+OR+status:merged)
[B] Note that that series has been in flight for quite a while. The
patch that actually removes rootwrap
(https://review.openstack.org/#/c/554438/) was first proposed right
about a year ago. I'm hoping this email thread gets the series some more
review attention.


From dangtrinhnt at gmail.com  Wed Apr  3 14:06:18 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 3 Apr 2019 23:06:18 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <20190403064440.GA3615@hilbert.berg.ol>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
Message-ID: <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>

Since more than 50% of the participants voted, I finalized the meeting time
at 6-7AM UTC, April 9.

Awesome!

Talk to you later :)

On Wed, Apr 3, 2019 at 3:44 PM Matthias Runge <mrunge at redhat.com> wrote:

> On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
> > Hi Lingxian. That should work for me too even though it's a little bit
> > early :)
> >
> > Rong Zhu, Matthias, please tell us your available time slots for the
> > meeting.
> >
> > Thank guys,
> >
> >
> >
> > On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com>
> wrote:
> >
> > > Hi Trinh,
> > >
> > > I'm available from 22:00 - 04:30 in UTC
>
>
> Hi,
>
> I'm available from 6:00 am UTC to 11am, and then in the evening starting
> from 5 pm to 9 pm, that's early EU business hours, and also early US
> West business hours. That should suit most of us.
>
> Matthias
>
> --
> Matthias Runge <mrunge at redhat.com>
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric
> Shander
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/f8d18113/attachment-0001.html>

From skaplons at redhat.com  Wed Apr  3 14:24:29 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Wed, 3 Apr 2019 16:24:29 +0200
Subject: [neutron] question: default QoS rule for all routers/fip and all
 future once
In-Reply-To: <d60abeda-089f-2554-2a70-f6d9a55b7d8e@everyware.ch>
References: <CALjNAZ2M+0Auo=54Lsja8MY-6rip3MBqvseYk6H7+oe02-y=zw@mail.gmail.com>
 <d60abeda-089f-2554-2a70-f6d9a55b7d8e@everyware.ch>
Message-ID: <6446C114-ED92-41A0-8403-3A4F7EA1A8E4@redhat.com>

Hi,

> Wiadomość napisana przez Florian Engelmann <florian.engelmann at everyware.ch> w dniu 03.04.2019, o godz. 14:38:
> 
> Hi,
> 
> the documentation about neutron and QoS talks about setting a default QoS rule for a project.
> 
> "Each project can have at most one default QoS policy, although it is not mandatory. If a default QoS policy is defined, all new networks created within this project will have this policy assigned, as long as no other QoS policy is explicitly attached during the creation process. If the default QoS policy is unset, no change to existing networks will be made.
> 
> In order to set a QoS policy as default, the parameter --default must be used. To unset this QoS policy as default, the parameter --no-default must be used."
> 
> So if a cloud provider wants to limit all router egress traffic to eg. 1Gbits this policy has to be set as default to all projects. But what if the customer is allowed to create new projects? This project will not have any default policy applied, right?

Correct. You will have to apply QoS policy to such new tenant by Your self.

> 
> And it looks like the is no API/logic in place to allow a self service customer to choose between different "network flavors"?
> Is something like that on the roadmap?

Currently not.

> 
> All the best,
> Florian

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From frickler at offenerstapel.de  Wed Apr  3 14:34:45 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Wed, 03 Apr 2019 14:34:45 +0000
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
Message-ID: <1554302085.4997.19.camel@offenerstapel.de>

On Wed, 2019-04-03 at 10:52 +0900, Trinh Nguyen wrote:
> Dear TC,
> 
> As I am the new PTL for Telemetry in Train [1] and the current cores
> seem
> inactive, I would like to ask the TC team to grant myself <
> dangtrinhnt at gmail.com> and Lingxian Kong <anlin.kong at gmail.com> to
> the core
> team of these Telemetry managed projects:
> 
> + ceilometer
> + aodh
> + panko
> 
> Next step for me is to re-organize core members and meetings.
> 
> Many thanks,
> 
> [1] https://review.openstack.org/#/c/645122/

On behalf of the openstack-infra team I have added you to the
corresponding groups in gerrit, you should be able to handle all
further adjustments now by yourself. If you need further assistance,
the easiest way will be to come visit us in the #openstack-infra IRC
channel on Freenode.

Jens


From dangtrinhnt at gmail.com  Wed Apr  3 14:43:01 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 3 Apr 2019 23:43:01 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <1554302085.4997.19.camel@offenerstapel.de>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
Message-ID: <CADJ6S4HHSJN+4FCjeja2sy21UFtVRm2NOrGe81xm-4zdegPm4A@mail.gmail.com>

Hi Jens. Thank you for all your assistance.

On Wed, Apr 3, 2019 at 11:37 PM Jens Harbott <frickler at offenerstapel.de>
wrote:

> On Wed, 2019-04-03 at 10:52 +0900, Trinh Nguyen wrote:
> > Dear TC,
> >
> > As I am the new PTL for Telemetry in Train [1] and the current cores
> > seem
> > inactive, I would like to ask the TC team to grant myself <
> > dangtrinhnt at gmail.com> and Lingxian Kong <anlin.kong at gmail.com> to
> > the core
> > team of these Telemetry managed projects:
> >
> > + ceilometer
> > + aodh
> > + panko
> >
> > Next step for me is to re-organize core members and meetings.
> >
> > Many thanks,
> >
> > [1] https://review.openstack.org/#/c/645122/
>
> On behalf of the openstack-infra team I have added you to the
> corresponding groups in gerrit, you should be able to handle all
> further adjustments now by yourself. If you need further assistance,
> the easiest way will be to come visit us in the #openstack-infra IRC
> channel on Freenode.
>
> Jens
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/fa5b6462/attachment.html>

From aspiers at suse.com  Wed Apr  3 14:42:54 2019
From: aspiers at suse.com (Adam Spiers)
Date: Wed, 3 Apr 2019 09:42:54 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
Message-ID: <20190403144254.q42iezxop3bxwh74@arabian.linksys.moosehall>

Eric Fried <openstack at fried.cc> wrote:
>Dear Nova spec authors and reviewers-
>
>Since our PTG time is shorter than usual this cycle, and we usually run
>out of time before we finish our agenda anyway, I would like to try to
>get as much spec review work wrapped up as possible before Denver.
>
>To that end, I would like to propose at least one spec review day over
>the next couple of weeks. This will be a chance for authors and
>reviewers to interact in a more synchronous fashion and hopefully let us
>close on some of the more significant issues.
>
>Can we do this next Tuesday, April 9th; and if necessary (and seeming
>productive) the following Tuesday, April 16th?
>
>If folks are amenable, I'll follow up with some logistics by the end of
>this week.

I've been preoccupied with other stuff recently (including our company
conference), but I'll do my best to get the SEV spec resubmission
ready in time for this review day, whenever it happens.


From openstack at nemebean.com  Wed Apr  3 15:23:21 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 3 Apr 2019 10:23:21 -0500
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
 <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
 <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
Message-ID: <a461c85a-f3c7-6957-fc99-1c9cb4fe9d64@nemebean.com>



On 4/3/19 8:15 AM, Eric Fried wrote:
>> 1- introduce privsep
>> 2- change rootwrap calls into generic privsep functions
>> 3- start refactoring calling code so that generic privsep functions can
>> be replaced by narrow, context-aware functions
>>
>> You can tackle (2) and (3) at the same time.
> 
> In Nova at least, (2) (without (3)) already has patches proposed all the
> way up [A], so I'm going to go out on a limb and say we're going to wait
> to tackle (3) until after that series [B], at least for existing code.
> 
>> It would be good to describe the antipattern and how to write "good"
>> privsep functions though, if only to be able to point developers and
>> reviewers to that. Suggestions on where we could do that?
> Agree with this for sure. I understand the rootwrap->privsep thing well
> enough to review the existing series, but will need help understanding
> how (3) will need to look.
> 
> Long-term, the document should obviously live somewhere
> non-project-specific, and I don't know where that would be.
> Short(er)-term, since we have momentum on the issue in Nova, as well as
> a clear picture of all the places it needs to be applied (thanks to
> (2)/[A]), how about we include it in a Nova spec, since we're going to
> need one anyway?

Wouldn't we put privsep best practices in the privsep docs? Currently 
the usage docs[0] just link to Michael's blog posts about implementing 
privsep, but that seems like the logical place to keep the guidelines 
for writing good privileged functions.

0: https://docs.openstack.org/oslo.privsep/latest/user/index.html

> 
> -efried
> 
> [A]
> https://review.openstack.org/#/q/topic:my-own-personal-alternative-universe+(status:open+OR+status:merged)
> [B] Note that that series has been in flight for quite a while. The
> patch that actually removes rootwrap
> (https://review.openstack.org/#/c/554438/) was first proposed right
> about a year ago. I'm hoping this email thread gets the series some more
> review attention.
> 


From sean.mcginnis at gmx.com  Wed Apr  3 15:34:00 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 3 Apr 2019 10:34:00 -0500
Subject: [release][ptl] Delays on releasing RC requests
Message-ID: <20190403153400.GA32420@sm-workstation>

Just a heads up to anyone that is proposing a new RC release by this Thursday's
final RC deadline.

Sphinx 2.0 was released last Thursday, removing some deprecations that were not
noticed in various libs and extensions that end up being used in our docs jobs.

Our immediate issue is sphinxcontib.datatemplates that has been updated to
handle not using the deprecated calls. But we have been blocked on a
requirements update to allow that newer release to be used.

We think (fingers crossed) that we have all the stars aligned where that should
be merging in about an hour or so. Once it does, we should be able to recheck
any existing release requests that have failing doc jobs and get those
processed.

If you were planning on requesting a new RC today, please go ahead and submit
the request. If you have any questions, please stop by the #openstack-release
channel.

Thanks!
Sean


From navdeep.uniyal at bristol.ac.uk  Wed Apr  3 15:47:40 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Wed, 3 Apr 2019 15:47:40 +0000
Subject: [Zun] Address already belongs to a bound Neutron port Error
Message-ID: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear All,

I have just installed Zun and tried creating a container following the instructions as per the following webpage:
https://docs.openstack.org/zun/rocky/install/index.html

I am getting following error while starting my test container using 'openstack appcontainer run --name container2 --net network=$NET_ID cirros ping 8.8.8.8':

status_reason     | Docker internal error: 500 Server Error: Internal Server Error ("IpamDriver.RequestAddress: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.147'} already belongs to a bound Neutron port: f0d6153a-7408-4cd5-82c3-9abed48ad056").

The network I selected is a flat network on openstack with external flag true.

Please advise me how to solve the issue or if there is a specific requirement for this.

Thank you,
Kind Regards,
Navdeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/ca0fcaf3/attachment-0001.html>

From mark at stackhpc.com  Wed Apr  3 16:05:31 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 3 Apr 2019 16:05:31 +0000
Subject: [kolla] IRC meeting time
In-Reply-To: <CAM2hn1CurKwHwL-6RBcocJ8yi6tKLFvhcegaqZZUx5SPZxRzhA@mail.gmail.com>
References: <CAFHSqWqmJkHK5kps6usK-CtxJh1zrK6ZPQ9r9QmALnbu7HY13A@mail.gmail.com>
 <CAM2hn1CurKwHwL-6RBcocJ8yi6tKLFvhcegaqZZUx5SPZxRzhA@mail.gmail.com>
Message-ID: <CAFHSqWpfGiuRwnsYFK2zp809XqY+TEDyntj=WoHLGJJdS0iLqg@mail.gmail.com>

On Fri, 22 Mar 2019 at 14:21, Martin André <m.andre at redhat.com> wrote:

> On Thu, Mar 21, 2019 at 8:25 PM Mark Goddard <mark at stackhpc.com> wrote:
> >
> > Hi,
> >
> > As discussed in the last weekly meeting [1], I'd like to see if there is
> a meeting time that better suits our contributor base. Our current meeting
> slot is on Wednesday at 1500 UTC, which isn't good for contributors in APAC.
> >
> > If you are interested in joining the kolla IRC meetings on an at least
> semi-regular basis (let's say once per month minimum), please respond here
> with a broad range of UTC times that generally suit you. Feel free to add
> ideal/if need be annotations. Non-cores are of course welcome.
> >
> > I'll get the ball rolling.
> >
> > Ideal: 0900 - 1800 UTC
> > If need be: 0800 - 2100 UTC
>
> Let's use a doodle for this. I've created
> https://doodle.com/poll/y4934shapcc32usx and added time for the people
> who already responded.
>
>
To follow up on this, the voting showed that 1500UTC is still the best time
for us - pretty much the only crossover for people in Asia and the US
(although I suspect it's rather late in parts of Asia). We had a very quiet
meeting today, I suspect because the switch to daylight savings time caught
a few people out. Please adjust your vote or reply here if your original
times didn't allow for DST.

Also, just to finish off the process - if the current day of Wednesday does
not suit you, but a different day at 1500UTC would, please reply here.

Martin
>
> > Cheers,
> > Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/a0d4fa25/attachment.html>

From mriedemos at gmail.com  Wed Apr  3 16:11:58 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 3 Apr 2019 11:11:58 -0500
Subject: [nova] super long online_data_migrations
In-Reply-To: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
Message-ID: <3000ed54-695b-309d-bd9c-ea15c02dbb56@gmail.com>

Following up on bug https://bugs.launchpad.net/nova/+bug/1822613 there 
are a few things:

1. https://review.openstack.org/#/c/649648/ drops the problematic 
migrate_keypairs_to_api_db data migration since we shouldn't need it 
anymore.

2. As noted in the bug and this thread, some online data migrations 
track a marker for paging and some don't, but there is no generic marker 
to say an online data migration is 'done' and doesn't need to be run 
again (like the migrations table for the sqlalchemy-migrate based schema 
migrations). Persisting something like that would require more thought 
for the online data migrations.

3. The other complaint in the bug is that --max-rows defaulting to 50 is 
too small in a large cloud (similar to bug 1742649 for --max-count on 
the map_instances command). I think a compromise here could be something 
like what Dan added for the archive_deleted_rows command:

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

Where you could specify a batch size using --max-rows but also specify 
an --until-complete option to run through all of the online data 
migrations rather than just stopping at --max-size records migrated. If 
people like that idea, then I think we just want a specless blueprint 
for it like what was used for the change above for archive_deleted_rows.

On 3/31/2019 9:21 PM, Mohammed Naser wrote:
> Hi there,
> 
> During upgrades, I've noticed that when running online_data_migrations
> with "infinite-until-done" mode, it loops over all of the migrations
> one by one.
> 
> However, one of the online data migrations
> (instance_obj.populate_missing_availability_zones) makes a query that
> takes a really long time as it seems inefficient (which eventually
> results in 0, cause it already ran), which means as it loops in
> "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
> environments.
> 
> The question ends up in specific:
> 
> SELECT count(*) AS count_1
> FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
> instance_extra.updated_at AS instance_extra_updated_at,
> instance_extra.deleted_at AS instance_extra_deleted_at,
> instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
> instance_extra_id, instance_extra.instance_uuid AS
> instance_extra_instance_uuid
> FROM instance_extra
> WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1
> 
> The explain for the DB query in this example:
> 
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows   | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 382473 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
> 
> It's possible that it can be ever worse, as this number is from
> another very-long running environments.
> 
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> | id   | select_type | table          | type | possible_keys | key  |
> key_len | ref  | rows    | Extra       |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
> NULL    | NULL | 3008741 | Using where |
> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
> 
> I'm not the SQL expert, could we not optimize this?  Alternatively,
> could we update the online data migrations code to "pop out" any of
> the migrations that return 0 for the next iteration, that way it only
> works on those online_data_migrations that *have* to be done, and
> ignore those it knows are done?
> 
> Thanks,
> Mohammed
> 


-- 

Thanks,

Matt


From thierry at openstack.org  Wed Apr  3 16:20:44 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 3 Apr 2019 18:20:44 +0200
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <a461c85a-f3c7-6957-fc99-1c9cb4fe9d64@nemebean.com>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
 <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
 <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
 <a461c85a-f3c7-6957-fc99-1c9cb4fe9d64@nemebean.com>
Message-ID: <08eb29f3-3d9a-0692-40ff-d51ab4161294@openstack.org>

Ben Nemec wrote:
>> [...]
>>> It would be good to describe the antipattern and how to write "good"
>>> privsep functions though, if only to be able to point developers and
>>> reviewers to that. Suggestions on where we could do that?
>> Agree with this for sure. I understand the rootwrap->privsep thing well
>> enough to review the existing series, but will need help understanding
>> how (3) will need to look.
>>
>> Long-term, the document should obviously live somewhere
>> non-project-specific, and I don't know where that would be.
>> Short(er)-term, since we have momentum on the issue in Nova, as well as
>> a clear picture of all the places it needs to be applied (thanks to
>> (2)/[A]), how about we include it in a Nova spec, since we're going to
>> need one anyway?
> 
> Wouldn't we put privsep best practices in the privsep docs? Currently 
> the usage docs[0] just link to Michael's blog posts about implementing 
> privsep, but that seems like the logical place to keep the guidelines 
> for writing good privileged functions.

Makes sense. I'll try to describe the antipattern, unless someone beats 
me to it.

-- 
Thierry Carrez (ttx)


From mrunge at redhat.com  Wed Apr  3 06:44:40 2019
From: mrunge at redhat.com (Matthias Runge)
Date: Wed, 3 Apr 2019 08:44:40 +0200
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
Message-ID: <20190403064440.GA3615@hilbert.berg.ol>

On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
> Hi Lingxian. That should work for me too even though it's a little bit
> early :)
> 
> Rong Zhu, Matthias, please tell us your available time slots for the
> meeting.
> 
> Thank guys,
> 
> 
> 
> On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com> wrote:
> 
> > Hi Trinh,
> >
> > I'm available from 22:00 - 04:30 in UTC


Hi,

I'm available from 6:00 am UTC to 11am, and then in the evening starting
from 5 pm to 9 pm, that's early EU business hours, and also early US
West business hours. That should suit most of us.

Matthias

-- 
Matthias Runge <mrunge at redhat.com>

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander


From melwittt at gmail.com  Wed Apr  3 16:51:47 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 3 Apr 2019 09:51:47 -0700
Subject: [nova] super long online_data_migrations
In-Reply-To: <3000ed54-695b-309d-bd9c-ea15c02dbb56@gmail.com>
References: <CAEs876iJbSzYUpuTL+697P9WJ1aXLZAACkZZK3NAsp8W1j+goA@mail.gmail.com>
 <3000ed54-695b-309d-bd9c-ea15c02dbb56@gmail.com>
Message-ID: <c637967f-15fc-9c37-6a77-2485c8e3a43f@gmail.com>

On Wed, 3 Apr 2019 11:11:58 -0500, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> Following up on bug https://bugs.launchpad.net/nova/+bug/1822613 there
> are a few things:
> 
> 1. https://review.openstack.org/#/c/649648/ drops the problematic
> migrate_keypairs_to_api_db data migration since we shouldn't need it
> anymore.

Thanks for doing that, it's now approved.

> 2. As noted in the bug and this thread, some online data migrations
> track a marker for paging and some don't, but there is no generic marker
> to say an online data migration is 'done' and doesn't need to be run
> again (like the migrations table for the sqlalchemy-migrate based schema
> migrations). Persisting something like that would require more thought
> for the online data migrations.
> 
> 3. The other complaint in the bug is that --max-rows defaulting to 50 is
> too small in a large cloud (similar to bug 1742649 for --max-count on
> the map_instances command). I think a compromise here could be something
> like what Dan added for the archive_deleted_rows command:
> 
> https://review.openstack.org/#/c/378718/
> 
> Where you could specify a batch size using --max-rows but also specify
> an --until-complete option to run through all of the online data
> migrations rather than just stopping at --max-size records migrated. If
> people like that idea, then I think we just want a specless blueprint
> for it like what was used for the change above for archive_deleted_rows.

I think it's a good idea -- I think we need it for larger deployments. 
Specless blueprint sounds good to me.

-melanie

> On 3/31/2019 9:21 PM, Mohammed Naser wrote:
>> Hi there,
>>
>> During upgrades, I've noticed that when running online_data_migrations
>> with "infinite-until-done" mode, it loops over all of the migrations
>> one by one.
>>
>> However, one of the online data migrations
>> (instance_obj.populate_missing_availability_zones) makes a query that
>> takes a really long time as it seems inefficient (which eventually
>> results in 0, cause it already ran), which means as it loops in
>> "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large
>> environments.
>>
>> The question ends up in specific:
>>
>> SELECT count(*) AS count_1
>> FROM (SELECT instance_extra.created_at AS instance_extra_created_at,
>> instance_extra.updated_at AS instance_extra_updated_at,
>> instance_extra.deleted_at AS instance_extra_deleted_at,
>> instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS
>> instance_extra_id, instance_extra.instance_uuid AS
>> instance_extra_instance_uuid
>> FROM instance_extra
>> WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1
>>
>> The explain for the DB query in this example:
>>
>> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
>> | id   | select_type | table          | type | possible_keys | key  |
>> key_len | ref  | rows   | Extra       |
>> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
>> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
>> NULL    | NULL | 382473 | Using where |
>> +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+
>>
>> It's possible that it can be ever worse, as this number is from
>> another very-long running environments.
>>
>> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
>> | id   | select_type | table          | type | possible_keys | key  |
>> key_len | ref  | rows    | Extra       |
>> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
>> |    1 | SIMPLE      | instance_extra | ALL  | NULL          | NULL |
>> NULL    | NULL | 3008741 | Using where |
>> +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+
>>
>> I'm not the SQL expert, could we not optimize this?  Alternatively,
>> could we update the online data migrations code to "pop out" any of
>> the migrations that return 0 for the next iteration, that way it only
>> works on those online_data_migrations that *have* to be done, and
>> ignore those it knows are done?
>>
>> Thanks,
>> Mohammed
>>
> 
> 






From lbragstad at gmail.com  Wed Apr  3 16:59:11 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Wed, 3 Apr 2019 11:59:11 -0500
Subject: [dev][tc][all] Train Goal Schedule and Update
Message-ID: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>

Hi all,

Since the community goal selection process has taken a turn, we wanted
to send  an update regarding the current goals. We originally wanted to
have the goals for Train be merged by this point to give project teams
ample time to plan for them accordingly in their PTG scheduled. Due to
discussions raised in each [0][1], it doesn't sound like either will be
making it into Train as a feasible community goal. Fortunately, a couple
of last minute goals might be a perfect fit for Train, instead of having
a release without any community goals.

The first one suggested is to render documentation as PDFs [2]. The
second goal, which still needs to be proposed, is for IPv6 support. The
advantage is that both of these goals are much smaller in scope, but
still useful. We're running up against the clock on getting goals
selected for Train, but we still have an opportunity to come to
agreement on the new proposals before the PTG.

We'd like to ask TC and members of the community to review the proposed
goals at their earliest convenience. Additionally, if someone wants help
write up the IPv6 support goal [3][4], please reach out gmann and
mnaser. Even though we were originally trying to make sure we had firm
goals well before the PTG, the reduced scope of the new goals should
make them easier to talk about in impromptu sessions or the hallway track.

Thanks,

JP & Lance

[0] https://review.openstack.org/#/c/639376/
[1] https://review.openstack.org/#/c/639010/
[2] https://review.openstack.org/#/c/647712/
[3] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-03-28.log.html#t2019-03-28T15:10:36
[4] Note that this goal is for testing IPv6 networking setups in all
projects. We already have a tempest full ipv6 job, it would be a matter
of making these jobs passing and voting in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/89a9b5ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/89a9b5ce/attachment.sig>

From mriedemos at gmail.com  Wed Apr  3 18:20:46 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 3 Apr 2019 13:20:46 -0500
Subject: [nova] critical bug around reload/upgrades
In-Reply-To: <CAEs876jsQJMm1s_af=+Gd9s3ubY14TPn1KZREFaD8Z7gyGU6oA@mail.gmail.com>
References: <CAEs876grRzxYn+2_v27=Yib9pSyOzpwiW1OH54CkoidgNgz5FQ@mail.gmail.com>
 <CAFHSqWrdN8Lqp0YZJUsvg8bFLdDJ+A9Nnk2R0YSXEtK9U=4CGA@mail.gmail.com>
 <CAEs876jsQJMm1s_af=+Gd9s3ubY14TPn1KZREFaD8Z7gyGU6oA@mail.gmail.com>
Message-ID: <99e420bd-3e99-4bcb-5bb4-eb32b8c3f1d4@gmail.com>

On 3/28/2019 7:42 PM, Mohammed Naser wrote:
> Looks like some progress has been made but we're pretty confident that this
> is more and more an Oslo.service bug:
> 
> Matt & Dan have both left ideas around this with possible solutions on how to
> make a change like this back portable..
> 
> https://review.openstack.org/#/c/641907/

Another update on this, but I was trying to recreate the original 
reported issue in the nova bug:

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

And I didn't even get to the point of the libvirt driver waiting for the 
network-vif-plugged event because privsep blows up much earlier during 
server create after SIGHUP'ing the service. Details start at comment 34 
in that bug, but the tl;dr is the privsep-helper child processes are 
gone after the SIGHUP so anything that relies on privsep (which is 
anything using root in the libvirt driver and os-vif utils code now I 
think) won't work until you restart the service.

I don't yet know if this is a regression in Stein but I'm going to 
create a stable/rocky devstack and try to find out.

-- 

Thanks,

Matt


From mriedemos at gmail.com  Wed Apr  3 18:24:29 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 3 Apr 2019 13:24:29 -0500
Subject: [dev][tc][all] Train Goal Schedule and Update
In-Reply-To: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
References: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
Message-ID: <4bfb3599-e719-082a-ec62-e9f415af035c@gmail.com>

On 4/3/2019 11:59 AM, Lance Bragstad wrote:
> The first one suggested is to render documentation as PDFs [2].

/me waits for mtreinish to propose the same with LaTeX.

-- 

Thanks,

Matt


From mtreinish at kortar.org  Wed Apr  3 18:55:24 2019
From: mtreinish at kortar.org (Matthew Treinish)
Date: Wed, 3 Apr 2019 14:55:24 -0400
Subject: [dev][tc][all] Train Goal Schedule and Update
In-Reply-To: <4bfb3599-e719-082a-ec62-e9f415af035c@gmail.com>
References: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
 <4bfb3599-e719-082a-ec62-e9f415af035c@gmail.com>
Message-ID: <20190403185524.GA6476@zeong>

On Wed, Apr 03, 2019 at 01:24:29PM -0500, Matt Riedemann wrote:
> On 4/3/2019 11:59 AM, Lance Bragstad wrote:
> > The first one suggested is to render documentation as PDFs [2].
> 
> /me waits for mtreinish to propose the same with LaTeX.
> 

Oh, I already commented on the review. It uses LaTeX internally, Sphinx
generates LaTeX (and a makefile) and then you compile that into the pdf.
The goal is basically to do what I did for Nova 4 years ago [3] (although that
has bitrotted quite a bit since then and no longer works) for all projects and
add the infrastructure to run and host that as part of docs builds.

I wouldn't miss the opportunity to talk LaTeX. :)

-Matt Treinish

[3] https://github.com/openstack/nova/commit/62575dd40e5b7698d9ba54641558246489f0614e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/cdc2d44d/attachment.sig>

From sean.mcginnis at gmx.com  Wed Apr  3 19:48:36 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 3 Apr 2019 14:48:36 -0500
Subject: [release][ptl] Delays on releasing RC requests
In-Reply-To: <20190403153400.GA32420@sm-workstation>
References: <20190403153400.GA32420@sm-workstation>
Message-ID: <20190403194836.GA25840@sm-workstation>

>
> We think (fingers crossed) that we have all the stars aligned where that should
> be merging in about an hour or so. Once it does, we should be able to recheck
> any existing release requests that have failing doc jobs and get those
> processed.
>

All necessary patches have landed and I've confirmed things are working with
releases now. I've done a few rechecks and have started process RC requests.

Just let me know if you see anything that does not look right.

Thanks,
Sean


From no-reply at openstack.org  Wed Apr  3 20:14:52 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 20:14:52 -0000
Subject: openstack-placement 1.0.0.0rc3 (stein)
Message-ID: <mailman.480.1554322494.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for openstack-placement for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/placement/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/placement/log/?h=stable/stein

Release notes for openstack-placement can be found at:

    https://docs.openstack.org/releasenotes/placement/

If you find an issue that could be considered release-critical, please
file it at:

    https://storyboard.openstack.org/#!/project/openstack/placement

and tag it *stein-rc-potential* to bring it to the openstack-placement
release crew's attention.



From no-reply at openstack.org  Wed Apr  3 20:21:48 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 20:21:48 -0000
Subject: nova_powervm 8.0.0.0rc2 (stein)
Message-ID: <mailman.481.1554322924.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for nova_powervm for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/nova-powervm/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/nova-powervm/log/?h=stable/stein

Release notes for nova_powervm can be found at:

    https://docs.openstack.org/releasenotes/nova-powervm/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/nova-powervm/+bugs

and tag it *stein-rc-potential* to bring it to the nova_powervm
release crew's attention.



From no-reply at openstack.org  Wed Apr  3 20:22:19 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 20:22:19 -0000
Subject: ceilometer-powervm 8.0.0.0rc2 (stein)
Message-ID: <mailman.482.1554322952.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for ceilometer-powervm for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/ceilometer-powervm/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/ceilometer-powervm/log/?h=stable/stein

Release notes for ceilometer-powervm can be found at:

    https://docs.openstack.org/releasenotes/ceilometer-powervm/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/ceilometer-powervm/+bugs

and tag it *stein-rc-potential* to bring it to the ceilometer-powervm
release crew's attention.



From no-reply at openstack.org  Wed Apr  3 20:22:37 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 20:22:37 -0000
Subject: networking-powervm 8.0.0.0rc2 (stein)
Message-ID: <mailman.483.1554322958.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for networking-powervm for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/networking-powervm/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/stein

Release notes for networking-powervm can be found at:

    https://docs.openstack.org/releasenotes/networking-powervm/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/networking-powervm/+bugs

and tag it *stein-rc-potential* to bring it to the networking-powervm
release crew's attention.



From no-reply at openstack.org  Wed Apr  3 20:30:45 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 20:30:45 -0000
Subject: keystone 15.0.0.0rc2 (stein)
Message-ID: <mailman.484.1554323446.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for keystone for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/keystone/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/keystone/log/?h=stable/stein

Release notes for keystone can be found at:

    https://docs.openstack.org/releasenotes/keystone/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/keystone/+bugs

and tag it *stein-rc-potential* to bring it to the keystone
release crew's attention.



From anlin.kong at gmail.com  Wed Apr  3 21:50:06 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Thu, 4 Apr 2019 10:50:06 +1300
Subject: [trove] CI job migration to Bionic for stable/stein
Message-ID: <CALjNAZ1uvbGmZUU20ooTNVAoUu3H9RWMuNoQAKHFO_XZEXU0PA@mail.gmail.com>

Hi team,

I've fixed the problems that blocked the job migration for the master, now
according to the community requirement, we also need to finish the
migration for stable/stein. I've already backported the needed patches,
please review or reply directly to this email if you have any concerns.

https://review.openstack.org/#/c/649744/
https://review.openstack.org/#/c/649745/

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/625b38dd/attachment.html>

From mriedemos at gmail.com  Wed Apr  3 22:23:27 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 3 Apr 2019 17:23:27 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
Message-ID: <aef43449-d075-4826-cb81-6a32ff995800@gmail.com>

On 4/2/2019 2:47 PM, Eric Fried wrote:
> Can we do this next Tuesday, April 9th; and if necessary (and seeming
> productive) the following Tuesday, April 16th?

Works for me.

-- 

Thanks,

Matt


From no-reply at openstack.org  Wed Apr  3 22:33:28 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Wed, 03 Apr 2019 22:33:28 -0000
Subject: cinder 14.0.0.0rc2 (stein)
Message-ID: <mailman.491.1554330826.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for cinder for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/stein

Release notes for cinder can be found at:

    https://docs.openstack.org/releasenotes/cinder/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/cinder/+bugs

and tag it *stein-rc-potential* to bring it to the cinder
release crew's attention.



From johnsomor at gmail.com  Wed Apr  3 23:24:41 2019
From: johnsomor at gmail.com (Michael Johnson)
Date: Wed, 3 Apr 2019 16:24:41 -0700
Subject: [octavia] Proposal to change the Octavia IRC meeting time.
Message-ID: <CAMH0Mg+Lf2wMED3pFJbZmoLonRCDMDUovEZB5WUkc9Vqntxhsw@mail.gmail.com>

As the composition of the Octavia team has changed over time, it was
proposed at today's meeting that we may want to change our weekly IRC
meeting time to accommodate more participants from around the world.

Seven time slots were proposed during the meeting and I have created a
doodle poll to help us find a time that works for most of the team.
Please note, the intent is to pick a new UTC time. Doodle attempts to
adapt the times to your local timezone.

The proposed times are Tuesday-Friday at 15:00 or 16:00 UTC. We have
also included the current meeting time of 20:00 UTC on Wednesday.

Please vote your preferences at the following Doodle poll:

https://doodle.com/poll/9sxbzfhwirqiyqe8

We will discuss the results at next week's regularly scheduled IRC
meeting, Wednesday at 20:00 UTC.

Please reply to this e-mail or to me directly if you have trouble with
the poll or would like to propose additional time slots.

Michael


From manuel.sb at garvan.org.au  Wed Apr  3 23:46:13 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Wed, 3 Apr 2019 23:46:13 +0000
Subject: NVMe PCI-passthrough
In-Reply-To: <6b3d5a50a39759ebe4547080c93225d56fb6c78c.camel@redhat.com>
References: <9D8A2486E35F0941A60430473E29F15B017E89A745@MXDB1.ad.garvan.unsw.edu.au>
 <6b3d5a50a39759ebe4547080c93225d56fb6c78c.camel@redhat.com>
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E89B672@MXDB1.ad.garvan.unsw.edu.au>

Thank you this was the actual problem.

Now it works

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-862.el7.x86_64 root=UUID=da7b03a2-d0f5-42f2-a660-861fcb5c8488 ro rootflags=subvol=root crashkernel=auto rhgb quiet intel_iommu=on iommu=pt

Manuel


-----Original Message-----
From: Stephen Finucane [mailto:sfinucan at redhat.com]
Sent: Wednesday, April 3, 2019 8:20 PM
To: Manuel Sopena Ballesteros; openstack at lists.openstack.org
Subject: Re: NVMe PCI-passthrough

On Wed, 2019-04-03 at 06:18 +0000, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
>
> I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason it is not working.
>
> This is my physical host details:
>
> [root at zeus-59 ~]# lspci -nn -D | grep -i ssd
> 0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
> 0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01)
>
> My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm
>
> This is how I identify the block devices for each pci device:
>
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme0
> [root at zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme
> total 0
> drwxr-xr-x. 4 root root 0 Apr  3 14:02 nvme1
>
> I installed the OS on the physical machine leaving those 2 drives intact:
>
> [root at zeus-59 ~]# lsblk
> NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> sda           8:0    0 59.6G  0 disk
> ├─sda1        8:1    0    1G  0 part /boot
> └─sda2        8:2    0    4G  0 part [SWAP]
> sr0          11:0    1  906M  0 rom
> nvme0n1     259:15   0  1.8T  0 disk
> nvme1n1     259:0    0  1.8T  0 disk
> nvme2n1     259:11   0  1.8T  0 disk
> └─nvme2n1p1 259:12   0  1.8T  0 part /var/lib/docker/btrfs
> nvme3n1     259:6    0  1.8T  0 disk
> └─nvme3n1p1 259:7    0  1.8T  0 part
> nvme4n1     259:13   0  1.8T  0 disk
> └─nvme4n1p1 259:14   0  1.8T  0 part
> nvme5n1     259:5    0  1.8T  0 disk
> └─nvme5n1p1 259:8    0  1.8T  0 part
> nvme6n1     259:17   0  1.8T  0 disk
> └─nvme6n1p1 259:18   0  1.8T  0 part
> nvme7n1     259:9    0  1.8T  0 disk
> └─nvme7n1p1 259:10   0  1.8T  0 part
> nvme8n1     259:3    0  1.8T  0 disk
> └─nvme8n1p1 259:4    0  1.8T  0 part
> nvme9n1     259:1    0  1.8T  0 disk
> └─nvme9n1p1 259:2    0  1.8T  0 part
>
> The next thing is to configure Openstack
>
> nova api config
>
> [pci]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
>
>
> nova scheduler config
>
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
>
>
> nova compute config
>
> [filter_scheduler]
> enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter
> available_filters = nova.scheduler.filters.all_filters
>
> [pci]
> passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ]
> alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"}
>
>
> Then I create my flavor
> openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1"
>
>
> I created the vm towards the host with the free nvme drives
>
> [root at openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small
>
>
> Vm creation fails and I can see this error in the nova compute logs
>
> 2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain with XML: <domain type='kvm'>
>   <name>instance-00000090</name>
> …
>   <devices>
>     <emulator>/usr/libexec/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>     </disk>
> …
> 2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support passthrough of host PCI devices

This error suggests you haven't enabled IOMMU. See the troubleshooting
section of this page for more information:

  http://ask.xmodulo.com/pci-passthrough-virt-manager.html

If this isn't called out in the docs, it should be.

Stephen

> Any idea or advice would be very helpful

NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

From mnaser at vexxhost.com  Wed Apr  3 23:57:40 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 3 Apr 2019 19:57:40 -0400
Subject: [tc] next meeting
In-Reply-To: <CAEs876g_jNaL4htVSoWwdz3cHeC=YAZubgu6iemxMkwty5JMwg@mail.gmail.com>
References: <CAEs876g_jNaL4htVSoWwdz3cHeC=YAZubgu6iemxMkwty5JMwg@mail.gmail.com>
Message-ID: <CAEs876hatD=Ocm2+8MoyCYvch4s5rfqZJBTgHB=oAAqcNLLYfQ@mail.gmail.com>

Hi,

Due to no feedback from any TC members, the fact we're deep into the
into release time and most TC members on IRC have mostly voiced that
they're okay with skipping it, I propose that we skip this as we'll be
mostly seeing each other in a few weeks at the PTG anyways.

I'm hoping that one we have the release out, we're able to free up
time to catch up on some of our TC activities.  In the meantime,
please try to put the priorities on reviewing the goals due to their
time sensitive nature (getting them before the PTG is essential).

Thanks,
Mohammed

On Mon, Apr 1, 2019 at 5:25 PM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> Hi everyone:
>
> It's quite a busy time but our monthly meeting is due.
>
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
>
> I left the list of past agenda topics in order to leave it for anyone
> to reference back if they'd like.  Please add topics by most Wednesday
> so we can send out an agenda before the meeting.
>
> Thanks,
> Mohammed
>
> --
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From dangtrinhnt at gmail.com  Thu Apr  4 00:33:48 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 4 Apr 2019 09:33:48 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
Message-ID: <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>

I've sent out the google calendar invitation to those who voted. If you
want to join the meeting and help Telemetry out, drop me an email by this
Saturday.

Also, look at the etherpad: https://etherpad.openstack.org/p/telemetry-train

Yours,

On Wed, Apr 3, 2019 at 11:06 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Since more than 50% of the participants voted, I finalized the meeting
> time at 6-7AM UTC, April 9.
>
> Awesome!
>
> Talk to you later :)
>
> On Wed, Apr 3, 2019 at 3:44 PM Matthias Runge <mrunge at redhat.com> wrote:
>
>> On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
>> > Hi Lingxian. That should work for me too even though it's a little bit
>> > early :)
>> >
>> > Rong Zhu, Matthias, please tell us your available time slots for the
>> > meeting.
>> >
>> > Thank guys,
>> >
>> >
>> >
>> > On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com>
>> wrote:
>> >
>> > > Hi Trinh,
>> > >
>> > > I'm available from 22:00 - 04:30 in UTC
>>
>>
>> Hi,
>>
>> I'm available from 6:00 am UTC to 11am, and then in the evening starting
>> from 5 pm to 9 pm, that's early EU business hours, and also early US
>> West business hours. That should suit most of us.
>>
>> Matthias
>>
>> --
>> Matthias Runge <mrunge at redhat.com>
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric
>> Shander
>>
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/fa2411b1/attachment-0001.html>

From aaronzhu1121 at gmail.com  Thu Apr  4 00:52:37 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Thu, 4 Apr 2019 08:52:37 +0800
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
Message-ID: <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>

Hi,

Meeting time is really good for us. But shall we change the meeting channel
just in the IRC channel? You may know we, from China, can't visit Google.

Thanks,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月4日 周四08:34写道：

> I've sent out the google calendar invitation to those who voted. If you
> want to join the meeting and help Telemetry out, drop me an email by this
> Saturday.
>
> Also, look at the etherpad:
> https://etherpad.openstack.org/p/telemetry-train
>
> Yours,
>
> On Wed, Apr 3, 2019 at 11:06 PM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Since more than 50% of the participants voted, I finalized the meeting
>> time at 6-7AM UTC, April 9.
>>
>> Awesome!
>>
>> Talk to you later :)
>>
>> On Wed, Apr 3, 2019 at 3:44 PM Matthias Runge <mrunge at redhat.com> wrote:
>>
>>> On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
>>> > Hi Lingxian. That should work for me too even though it's a little bit
>>> > early :)
>>> >
>>> > Rong Zhu, Matthias, please tell us your available time slots for the
>>> > meeting.
>>> >
>>> > Thank guys,
>>> >
>>> >
>>> >
>>> > On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com>
>>> wrote:
>>> >
>>> > > Hi Trinh,
>>> > >
>>> > > I'm available from 22:00 - 04:30 in UTC
>>>
>>>
>>> Hi,
>>>
>>> I'm available from 6:00 am UTC to 11am, and then in the evening starting
>>> from 5 pm to 9 pm, that's early EU business hours, and also early US
>>> West business hours. That should suit most of us.
>>>
>>> Matthias
>>>
>>> --
>>> Matthias Runge <mrunge at redhat.com>
>>>
>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric
>>> Shander
>>>
>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/d1de0a1a/attachment.html>

From dangtrinhnt at gmail.com  Thu Apr  4 00:57:10 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 4 Apr 2019 09:57:10 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
Message-ID: <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>

Hi Rong Zhu,

Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
<https://jitsi.org/> should work? Let me know.

Bests,

On Thu, Apr 4, 2019 at 9:52 AM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Hi,
>
> Meeting time is really good for us. But shall we change the meeting
> channel just in the IRC channel? You may know we, from China, can't visit
> Google.
>
> Thanks,
> Rong Zhu
>
> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月4日 周四08:34写道：
>
>> I've sent out the google calendar invitation to those who voted. If you
>> want to join the meeting and help Telemetry out, drop me an email by this
>> Saturday.
>>
>> Also, look at the etherpad:
>> https://etherpad.openstack.org/p/telemetry-train
>>
>> Yours,
>>
>> On Wed, Apr 3, 2019 at 11:06 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>> wrote:
>>
>>> Since more than 50% of the participants voted, I finalized the meeting
>>> time at 6-7AM UTC, April 9.
>>>
>>> Awesome!
>>>
>>> Talk to you later :)
>>>
>>> On Wed, Apr 3, 2019 at 3:44 PM Matthias Runge <mrunge at redhat.com> wrote:
>>>
>>>> On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
>>>> > Hi Lingxian. That should work for me too even though it's a little bit
>>>> > early :)
>>>> >
>>>> > Rong Zhu, Matthias, please tell us your available time slots for the
>>>> > meeting.
>>>> >
>>>> > Thank guys,
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com>
>>>> wrote:
>>>> >
>>>> > > Hi Trinh,
>>>> > >
>>>> > > I'm available from 22:00 - 04:30 in UTC
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm available from 6:00 am UTC to 11am, and then in the evening starting
>>>> from 5 pm to 9 pm, that's early EU business hours, and also early US
>>>> West business hours. That should suit most of us.
>>>>
>>>> Matthias
>>>>
>>>> --
>>>> Matthias Runge <mrunge at redhat.com>
>>>>
>>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>>> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric
>>>> Shander
>>>>
>>>
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/1034b784/attachment.html>

From aaronzhu1121 at gmail.com  Thu Apr  4 01:02:49 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Thu, 4 Apr 2019 09:02:49 +0800
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
Message-ID: <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>

Hi Trinh,

I think Zoom is OK to us.

Regards,
Rong Zhu


Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月4日 周四08:57写道：

> Hi Rong Zhu,
>
> Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
> <https://jitsi.org/> should work? Let me know.
>
> Bests,
>
> On Thu, Apr 4, 2019 at 9:52 AM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>
>> Hi,
>>
>> Meeting time is really good for us. But shall we change the meeting
>> channel just in the IRC channel? You may know we, from China, can't visit
>> Google.
>>
>> Thanks,
>> Rong Zhu
>>
>> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月4日 周四08:34写道：
>>
>>> I've sent out the google calendar invitation to those who voted. If you
>>> want to join the meeting and help Telemetry out, drop me an email by this
>>> Saturday.
>>>
>>> Also, look at the etherpad:
>>> https://etherpad.openstack.org/p/telemetry-train
>>>
>>> Yours,
>>>
>>> On Wed, Apr 3, 2019 at 11:06 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>>> wrote:
>>>
>>>> Since more than 50% of the participants voted, I finalized the meeting
>>>> time at 6-7AM UTC, April 9.
>>>>
>>>> Awesome!
>>>>
>>>> Talk to you later :)
>>>>
>>>> On Wed, Apr 3, 2019 at 3:44 PM Matthias Runge <mrunge at redhat.com>
>>>> wrote:
>>>>
>>>>> On Wed, Apr 03, 2019 at 03:32:16PM +0900, Trinh Nguyen wrote:
>>>>> > Hi Lingxian. That should work for me too even though it's a little
>>>>> bit
>>>>> > early :)
>>>>> >
>>>>> > Rong Zhu, Matthias, please tell us your available time slots for the
>>>>> > meeting.
>>>>> >
>>>>> > Thank guys,
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Tue, Apr 2, 2019 at 2:00 PM Lingxian Kong <anlin.kong at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > > Hi Trinh,
>>>>> > >
>>>>> > > I'm available from 22:00 - 04:30 in UTC
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm available from 6:00 am UTC to 11am, and then in the evening
>>>>> starting
>>>>> from 5 pm to 9 pm, that's early EU business hours, and also early US
>>>>> West business hours. That should suit most of us.
>>>>>
>>>>> Matthias
>>>>>
>>>>> --
>>>>> Matthias Runge <mrunge at redhat.com>
>>>>>
>>>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>>>> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric
>>>>> Shander
>>>>>
>>>>
>>>>
>>>> --
>>>> *Trinh Nguyen*
>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>
>>>>
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>> --
>> Thanks,
>> Rong Zhu
>>
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/fa5ecc4a/attachment-0001.html>

From hongbin034 at gmail.com  Thu Apr  4 01:48:54 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Wed, 3 Apr 2019 21:48:54 -0400
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>

Hi Navdeep,

It looks I cannot reproduce the problem using rocky with flat network. If
possible, would you provide the following:

* Your kuryr-libnetwork log (with sensitive information removed). You can
get it by running "sudo journalctl -u devstack at kuryr-libnetwork".
* Your flat network (openstack network show XXX)
* Your subnet (openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc)
* Your port (openstack port show f0d6153a-7408-4cd5-82c3-9abed48ad056)

Best regards,
Hongbin

On Wed, Apr 3, 2019 at 11:52 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Dear All,
>
>
>
> I have just installed Zun and tried creating a container following the
> instructions as per the following webpage:
>
> https://docs.openstack.org/zun/rocky/install/index.html
>
>
>
> I am getting following error while starting my test container using
> ‘openstack appcontainer run --name container2 --net network=$NET_ID cirros
> ping 8.8.8.8’:
>
>
>
> status_reason     | Docker internal error: 500 Server Error: Internal
> Server Error ("IpamDriver.RequestAddress: Requested ip address
> {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address':
> u'10.68.48.147'} already belongs to a bound Neutron port:
> f0d6153a-7408-4cd5-82c3-9abed48ad056").
>
>
>
> The network I selected is a flat network on openstack with external flag
> true.
>
> Please advise me how to solve the issue or if there is a specific
> requirement for this.
>
>
>
> Thank you,
>
> Kind Regards,
>
> Navdeep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190403/22782970/attachment.html>

From gmann at ghanshyammann.com  Thu Apr  4 03:57:30 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 03 Apr 2019 22:57:30 -0500
Subject: [dev] [nova] API updates week 19-14
Message-ID: <169e67e9a37.aeaa100e58173.2449215536656227052@ghanshyammann.com>

Hi All, 

After a long break, I am continuing nova API updates over email. 

Please find the Nova API highlights of this week. 

Weekly Office Hour: 
=============== 
API office hour is on hold as of now. We can continue it if people are intrested. I am asking
the feedback on this ML thread- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004336.html 

Planned Features : 
============== 
Now we are in Train developement cycle, so I am adding the Train proposed spec first and second part
includes all previously approved BP but not completed . 

Code Ready for Review:
------------------------------
- None

Spec Ready for Review:
-----------------------------
1. Support adding description while locking an instance: 
- Spec: https://review.openstack.org/#/c/638629/
- Weekly Progress: Spec is in review. 

2. Nova API policy improvement
- Spec: https://review.openstack.org/#/c/547850/ 
- PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:open+OR+status:merged)
- Weekly Progress: Spec is ready to review, pushed the PoC patches for each proposed changed 

3. Support deleting data volume when destroy instance
- Spec: https://review.openstack.org/#/c/580336/ 
- Weekly Progress: Proposed for Train. Ready to review.

4. Nova API cleanup 
- Spec: https://review.openstack.org/#/c/603969/ 
- Weekly Progress: Proposed for Train. Ready to review.

5. Add host and hypervisor_hostname flag to create server
- Spec: https://review.openstack.org/#/c/645458/
- Weekly Progress: Spec under review

6. Specifying az when restore shelved server
- Spec: https://review.openstack.org/#/c/624689/ 
- Weekly Progress: Spec under review

7. default value of swap in the show flavor details API
- Spec: https://review.openstack.org/#/c/648919/
- Weekly Progress: New spec, ready for review.

8. Support for changing deleted_on_termination after boot
-Spec: https://review.openstack.org/#/c/580336/
- Weekly Progress: Ready for review.

9. Support delete_on_termination in volume attach api\
-Spec: https://review.openstack.org/#/c/612949/
 - Weekly Progress: Ready for review.

10. Add API ref guideline for body text  
- ~8 api-ref are left to fix.

Previously approved Spec needs to be re-proposed for Train:
---------------------------------------------------------------------------
1. Detach and attach boot volumes: 
- https://blueprints.launchpad.net/nova/+spec/detach-boot-volume 
- https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged) 

2. Servers Ips non-unique network names : 
- https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names 
- https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged) 

3. Volume multiattach enhancements: 
- https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements 
- https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged) 

BP Completed: 
-------------------
- None

Bugs: 
====
No progress report in this week.

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those are not in above list. Tag such bugs so that we can keep our eyes. 

-gmann



From kchamart at redhat.com  Thu Apr  4 08:17:53 2019
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Thu, 4 Apr 2019 10:17:53 +0200
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
Message-ID: <20190404081753.GC28897@paraplu>

On Tue, Apr 02, 2019 at 02:47:55PM -0500, Eric Fried wrote:
> Dear Nova spec authors and reviewers-
> 
> Since our PTG time is shorter than usual this cycle, and we usually
> run out of time before we finish our agenda anyway, I would like to
> try to get as much spec review work wrapped up as possible before
> Denver.
> 
> To that end, I would like to propose at least one spec review day over
> the next couple of weeks. This will be a chance for authors and
> reviewers to interact in a more synchronous fashion and hopefully let
> us close on some of the more significant issues.
> 
> Can we do this next Tuesday, April 9th; and if necessary (and seeming
> productive) the following Tuesday, April 16th?

FWIW, works for me.

I have two irons in the fire:

(1) Add "Secure Boot support for KVM & QEMU guests" spec
    https://review.openstack.org/#/c/506720/

(2) Add "CPU selection with hypervisor consideration" spec
    https://review.openstack.org/#/c/645814/

The first spec has had some detailed review in the past.  I had to put
it on hold for a while, as we needed some major work to be done (refer
to the periodic updates I posted on the Gerrit change) in the lower
layer components: OVMF, QEMU, and libvirt.  That work is now is
completed, with libvirt merging the "auto-selection of firmware
binaries" in its latest release, 5.2.0.  Nova should now be set to start
designing the support for Secure Boot for KVM/QEMU guests.  I have
refreshed the spec, and am rewriting it to reflect the new reality.

The second spec is also fairly uncontroversial (refer to the problem
description and work items in the spec).  It has had some intial
reviews, and I'm addressing the feedback.

PS: I've also briefly described both of the above in the PTG Etherpad.

[...] 

-- 
/kashyap


From ekcs.openstack at gmail.com  Thu Apr  4 09:20:18 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 01:20:18 -0800
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
Message-ID: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>

Requesting exception to remove a requirement to resolve a packaging issue.

The package is needed only for an experimental feature, but causes
packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
require manual install to enable the experimental feature.

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




From james.page at canonical.com  Thu Apr  4 09:01:33 2019
From: james.page at canonical.com (James Page)
Date: Thu, 4 Apr 2019 10:01:33 +0100
Subject: [charms] Enabling Neutron DVR & ovs
In-Reply-To: <CAG1bqQrKG_=aNhQFB+-SEyYjpk8KCnXOPtvOWgHq2xaET39L5A@mail.gmail.com>
References: <HE1PR0102MB2586ECE7A8B4F2A8D51C8050F15B0@HE1PR0102MB2586.eurprd01.prod.exchangelabs.com>
 <CAG1bqQrKG_=aNhQFB+-SEyYjpk8KCnXOPtvOWgHq2xaET39L5A@mail.gmail.com>
Message-ID: <CAG1bqQp0tsMYxbknF4zFEqMVzu-2P4BLc0RZAZRcgTWsVJz6Vg@mail.gmail.com>

Hi Emil

On Sat, Mar 30, 2019 at 1:55 PM Emil Larsson <Emil.Larsson at zetup.se> wrote:

> Hi guys,
>
> I have been experimenting with the enable-dvr option in neutron-api. I
> cannot find a clear guide on how to configure this.
> However I have ran into some issues trying to figure out the configuration
> to enable dvr.
>
> This is where juju stops:
> unit-neutron-openvswitch-1: 11:45:35 INFO
> unit.neutron-openvswitch/1.juju-log Creating bridge br-int
> unit-neutron-openvswitch-1: 11:45:35 INFO
> unit.neutron-openvswitch/1.juju-log Creating bridge br-ex
> unit-neutron-openvswitch-1: 11:45:36 DEBUG
> unit.neutron-openvswitch/1.juju-log Replacing iface 'eno1' with bond master
> 'os'
> unit-neutron-openvswitch-1: 11:45:36 DEBUG
> unit.neutron-openvswitch/1.juju-log Replacing iface 'eno2' with bond master
> 'os'
> unit-neutron-openvswitch-1: 11:45:36 DEBUG
> unit.neutron-openvswitch/1.juju-log Replacing iface 'eno3' with bond master
> 'stor'
> unit-neutron-openvswitch-1: 11:45:36 DEBUG
> unit.neutron-openvswitch/1.juju-log Replacing iface 'eno4' with bond master
> 'stor'
> unit-neutron-openvswitch-1: 11:45:37 INFO
> unit.neutron-openvswitch/1.juju-log Creating bridge br-data
> unit-neutron-openvswitch-1: 11:45:37 DEBUG
> unit.neutron-openvswitch/1.juju-log Interface os.392 is not a Linux bridge
> unit-neutron-openvswitch-1: 11:45:37 INFO
> unit.neutron-openvswitch/1.juju-log Adding port os.392 to bridge br-data
> unit-neutron-openvswitch-1: 11:45:37 DEBUG
> unit.neutron-openvswitch/1.config-changed Failed to restart
> os-charm-phy-nic-mtu.service: Unit os-charm-phy-nic-mtu.service not found.
>

That restart failure is a bit of a red-herring (and needs tidying) - it
relates to a tactical fix for MTU configuration of interfaces in Trusty
(for which we are due to drop support this year).

snip
[...]

>
> Any help appreciated :)
>

The current release of OpenStack Charms still requires use of the
neutron-gateway charm for snat traffic routing; that said we have
gateway-less features currently in development which allow the agents
managed by the neutron-openvswitch charm to be configured for snat routing
as well, removing the need for the gateway.

Here is a bundle based on the openstack-base bundle which I've been testing
with:

http://paste.ubuntu.com/p/nsx86snZpb/

Obviously the network space binding, storage configuration and maas tags
are all specific to my testing environment - but it demonstrates how to get
this working.

HTH

Regards

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/075f6586/attachment-0001.html>

From no-reply at openstack.org  Thu Apr  4 10:09:04 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 10:09:04 -0000
Subject: cloudkitty 9.0.0.0rc2 (stein)
Message-ID: <mailman.503.1554372567.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for cloudkitty for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/cloudkitty/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/cloudkitty/log/?h=stable/stein

Release notes for cloudkitty can be found at:

    https://docs.openstack.org/releasenotes/cloudkitty/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/cloudkitty/+bugs

and tag it *stein-rc-potential* to bring it to the cloudkitty
release crew's attention.



From anlin.kong at gmail.com  Thu Apr  4 10:28:48 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Thu, 4 Apr 2019 23:28:48 +1300
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
Message-ID: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>

Hi Stable Maintenance Core team,

I'm current Trove PTL, could you please add myself to trove-stable-maint so
that I could merge those patches[1][2][3] for stable/stein?

[1] https://review.openstack.org/#/c/645647/
[2] https://review.openstack.org/#/c/645646/
[3] https://review.openstack.org/#/c/645648/

---
Cheers,
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/a999a458/attachment.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 11:06:20 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 11:06:20 +0000
Subject: SFC delete port chain failed
Message-ID: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear All,

I am facing errors while creating/deleting the SF Chain:

2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.

Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/22b9a3f1/attachment-0001.html>

From thierry at openstack.org  Thu Apr  4 13:41:03 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Thu, 4 Apr 2019 15:41:03 +0200
Subject: [nova] Privsep is not giving us any security
In-Reply-To: <08eb29f3-3d9a-0692-40ff-d51ab4161294@openstack.org>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
 <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
 <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
 <a461c85a-f3c7-6957-fc99-1c9cb4fe9d64@nemebean.com>
 <08eb29f3-3d9a-0692-40ff-d51ab4161294@openstack.org>
Message-ID: <a7c56896-d454-bf78-2a02-0037a57291f1@openstack.org>

Thierry Carrez wrote:
> Ben Nemec wrote:
>>> [...]
>>>> It would be good to describe the antipattern and how to write "good"
>>>> privsep functions though, if only to be able to point developers and
>>>> reviewers to that. Suggestions on where we could do that?
>>> Agree with this for sure. I understand the rootwrap->privsep thing well
>>> enough to review the existing series, but will need help understanding
>>> how (3) will need to look.
>>>
>>> Long-term, the document should obviously live somewhere
>>> non-project-specific, and I don't know where that would be.
>>> Short(er)-term, since we have momentum on the issue in Nova, as well as
>>> a clear picture of all the places it needs to be applied (thanks to
>>> (2)/[A]), how about we include it in a Nova spec, since we're going to
>>> need one anyway?
>>
>> Wouldn't we put privsep best practices in the privsep docs? Currently 
>> the usage docs[0] just link to Michael's blog posts about implementing 
>> privsep, but that seems like the logical place to keep the guidelines 
>> for writing good privileged functions.
> 
> Makes sense. I'll try to describe the antipattern, unless someone beats 
> me to it.

A start at:
https://review.openstack.org/649997

-- 
Thierry Carrez (ttx)


From correajl at gmail.com  Thu Apr  4 13:53:45 2019
From: correajl at gmail.com (Jorge Luiz Correa)
Date: Thu, 4 Apr 2019 10:53:45 -0300
Subject: [nova][ops] Help with kernel panic on cirros image boot process.
Message-ID: <CAE2bT_2R-1+MmuX2JoW-MnL6hnQmxNCmAJG5NmFEtHVayJiQrA@mail.gmail.com>

Hi all!

I'm having kernel panic randomically with cirros image. Sometimes the
instances boots, sometimes not.

I'm using Openstack Queens, Ubuntu Server 18.04 and KVM (following the
install guide). The nova/instances directory, where are stored
ephemeral disks, is over a GlusterFS system.

I've noted that other images, like Ubuntu Cloud Image, do not get this
error. It's just with cirros and sometimes.

I appreciate any help guiding on where I can look for to identify what
is causing these errors. I've analyzed libvirt logs and them show just
a launched instance, everything ok. The _base/<ID> file used to launch
the instances is the same that is used with cirros instances that
worked (it's in a GlusterFS). Something got wrong during the instance
boot process.

Boot log:

[    1.586076] EDD information not available.
[    1.590261] Freeing unused kernel memory: 1480K (ffffffff81f42000 -
ffffffff820b4000)
[    1.594823] Write protecting the kernel read-only data: 14336k
[    1.598951] Freeing unused kernel memory: 1860K (ffff88000182f000 -
ffff880001a00000)
[    1.625178] Freeing unused kernel memory: 168K (ffff880001dd6000 -
ffff880001e00000)

info: initramfs: up at 1.07
modprobe: module virtio_pci not found in modules.dep
modprobe: module virtio_blk not found in modules.dep
modprobe: module virtio_net not found in modules.dep
modprobe: module vfat not found in modules.dep
modprobe: module nls_cp437 not found in modules.dep
info: copying initramfs to /dev/vda1
[    2.028648] jbd2_journal_bmap: journal block not found at offset 12 on vda1-8
[    2.034075] Aborting journal on device vda1-8.
mount: mounting /dev on ./dev failed: No such file or directory
info: initramfs loading root from /dev/vda1
switch_root: can't execute '/sbin/init': No such file or directory
[    2.692399] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[    2.692399]
[    2.696061] CPU: 0 PID: 1 Comm: switch_root Not tainted
4.4.0-28-generic #47-Ubuntu
[    2.699012] Hardware name: OpenStack Foundation OpenStack Nova,
BIOS 1.10.2-1ubuntu1 04/01/2014
[    2.702373]  0000000000000086 000000004016d54a ffff88003e2fbe10
ffffffff813eb1a3
[    2.705849]  ffffffff81cb10d8 ffff88003e2fbea8 ffff88003e2fbe98
ffffffff8118bf57
[    2.709353]  ffff880000000010 ffff88003e2fbea8 ffff88003e2fbe40
000000004016d54a
[    2.712875] Call Trace:
[    2.714013]  [<ffffffff813eb1a3>] dump_stack+0x63/0x90
[    2.715995]  [<ffffffff8118bf57>] panic+0xd3/0x215
[    2.717840]  [<ffffffff81184e1e>] ? perf_event_exit_task+0xbe/0x350
[    2.720105]  [<ffffffff81084541>] do_exit+0xae1/0xaf0
[    2.722090]  [<ffffffff810845d3>] do_group_exit+0x43/0xb0
[    2.724150]  [<ffffffff81084654>] SyS_exit_group+0x14/0x20
[    2.726207]  [<ffffffff818276b2>] entry_SYSCALL_64_fastpath+0x16/0x71
[    2.729271] Kernel Offset: disabled
[    2.730741] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000100

Thank you!


From mthode at mthode.org  Thu Apr  4 13:54:10 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 08:54:10 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
Message-ID: <20190404135410.ph2o55jej57binmx@mthode.org>

On 19-04-04 01:20:18, Eric K wrote:
> Requesting exception to remove a requirement to resolve a packaging issue.
> 
> The package is needed only for an experimental feature, but causes
> packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
> require manual install to enable the experimental feature.
> 
> https://review.openstack.org/#/c/649772/
> 

I imagine psycopg2 is one of many dependencies that are not fully
compliant with our upper-constraints (and probably a bunch of projects
global-constraints).  Is it possible to lower the version required (be
compatible with 2.6 or whatever is in centos)?  The requirements project
itself sets no lower bound for psycopg2.

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/24397dba/attachment.sig>

From gmann at ghanshyammann.com  Thu Apr  4 13:56:27 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 04 Apr 2019 08:56:27 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
Message-ID: <169e8a2f334.d1e984e875880.649627850850459039@ghanshyammann.com>

 ---- On Tue, 02 Apr 2019 14:47:55 -0500 Eric Fried <openstack at fried.cc> wrote ----
 > Dear Nova spec authors and reviewers- 
 >  
 > Since our PTG time is shorter than usual this cycle, and we usually run 
 > out of time before we finish our agenda anyway, I would like to try to 
 > get as much spec review work wrapped up as possible before Denver. 
 >  
 > To that end, I would like to propose at least one spec review day over 
 > the next couple of weeks. This will be a chance for authors and 
 > reviewers to interact in a more synchronous fashion and hopefully let us 
 > close on some of the more significant issues. 
 >  
 > Can we do this next Tuesday, April 9th; and if necessary (and seeming 
 > productive) the following Tuesday, April 16th? 

Both dates work for me.  Thanks 

-gmann

 >  
 > If folks are amenable, I'll follow up with some logistics by the end of 
 > this week. 
 >  
 > Thanks, 
 > efried 
 > . 
 >  
 > 



From sergey at vilgelm.info  Thu Apr  4 13:57:06 2019
From: sergey at vilgelm.info (Sergey Vilgelm)
Date: Thu, 4 Apr 2019 08:57:06 -0500
Subject: [qa][patrole] get_tenant_network found None
In-Reply-To: <478c2524-be5b-45ea-989c-7c5d659bfc30@Spark>
References: <478c2524-be5b-45ea-989c-7c5d659bfc30@Spark>
Message-ID: <83dcbb8b-40a2-4558-8a8d-e72ab188f08d@Spark>

Hello,

There is an issue with get_tenant_network function in the Patrole tests. Zuul failed on patch set [0] due to 'Multiple possible networks found, use a Network ID to be more specific’[1]. Tempest logs[2] contain an message: '(ServerActionsRbacTest:setUpClass) Found network None available for tenant’.

Who knows why this can happen? I have an idea, that this could happen in case of a parallel test running and one test rewrote the roles and another test didn’t find a tenant's network at same time because of the wrong roles.


[0] https://review.openstack.org/#/c/648255/
[1] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/testr_results.html.gz
[2] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/controller/logs/tempest_log.txt.gz


--
Sergey Vilgelm
https://www.vilgelm.info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/48e5f129/attachment.html>

From no-reply at openstack.org  Thu Apr  4 14:04:21 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 14:04:21 -0000
Subject: tacker 1.0.0.0rc2 (stein)
Message-ID: <mailman.504.1554386714.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for tacker for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/tacker/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/tacker/log/?h=stable/stein

Release notes for tacker can be found at:

    https://docs.openstack.org/releasenotes/tacker/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/tacker/+bugs

and tag it *stein-rc-potential* to bring it to the tacker
release crew's attention.



From nsitlani03 at gmail.com  Thu Apr  4 14:11:51 2019
From: nsitlani03 at gmail.com (Namrata Sitlani)
Date: Thu, 4 Apr 2019 19:41:51 +0530
Subject: [Magnum] How to use docker CLI against a Magnum-managed Kubernetes
 cluster
Message-ID: <CAP-MmQ+hwqrmMXuVnz-nssE+HLLeB_nmJMZ_m6S=6VVW8wsicg@mail.gmail.com>

Hello,

I am trying to use docker CLI against a Magnum-managed Kubernetes cluster
so as to interact with its Docker registry.

I followed the steps as explained in
https://docs.openstack.org/magnum/rocky/user/#interfacing-with-a-secure-cluster
but magnum does not setup docker on tcp port so it cannot be accessed
outside the minion node(where docker is running).

I appreciate any help guiding how to use docker CLI.

Thanks
Namrata Sitlani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/39517569/attachment-0001.html>

From hoanq13 at viettel.com.vn  Thu Apr  4 02:59:50 2019
From: hoanq13 at viettel.com.vn (hoanq13 at viettel.com.vn)
Date: Thu,  4 Apr 2019 09:59:50 +0700 (ICT)
Subject: [Vitrage] Find solution on integrate vitrage to current monitor
In-Reply-To: <1135240140.823214.1554345841979.JavaMail.zimbra@viettel.com.vn>
Message-ID: <1923699737.906723.1554346789954.JavaMail.zimbra@viettel.com.vn>

Hi, 

I sent this mail for finding solution when integrate vitrage to my current monitor system. 
I my system we use Tick stack monitor: with telegraf is collector metric, influxdb for storing metric, and kapacitor for alarming. 
It been work for a long while, all our monitor data in influxdb. I'm wondering have any tool can read influxdb, create alarm so vitrage can get input alarm from it?. 
Or any ideal you can recommend me on integrate vitrage to my system? 

p/s: i was think about write datasource driver kapacitor can alarm vitrage, but it take time, and I'm not good at codding. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/00556b7e/attachment-0001.html>

From mrunge at redhat.com  Thu Apr  4 06:17:22 2019
From: mrunge at redhat.com (Matthias Runge)
Date: Thu, 4 Apr 2019 08:17:22 +0200
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
 <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
Message-ID: <20190404061722.GA3766@hilbert.berg.ol>

On Thu, Apr 04, 2019 at 09:02:49AM +0800, Rong Zhu wrote:
> >
> > Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
> > <https://jitsi.org/> should work? Let me know.


> >> Meeting time is really good for us. But shall we change the meeting
> >> channel just in the IRC channel? You may know we, from China, can't visit
> >> Google.

> >>> I've sent out the google calendar invitation to those who voted. If you
> >>> want to join the meeting and help Telemetry out, drop me an email by this
> >>> Saturday.
> >>>
> >>> Also, look at the etherpad:
> >>> https://etherpad.openstack.org/p/telemetry-train

Hi,

thank you for setting this up! For the first meeting, having a video
chat would probably be good, but I'd second the request for using IRC.

Matthias
-- 
Matthias Runge <mrunge at matthias-runge.de>


From anyrude10 at gmail.com  Thu Apr  4 09:51:05 2019
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Thu, 4 Apr 2019 15:21:05 +0530
Subject: [Magnum] Unable to create Kubernetes cluster
Message-ID: <CAKxkTi1T5Zb9Xcv5+-9JknXJL5kjY8zGUABbUa2W8Kpr5q_GdQ@mail.gmail.com>

Hi Team,

I am trying to create kubernetes cluster using Magnum Openstack.

My External Network configuration is as follows:

neutron net-create MGMT_NET --shared --router:external
--provider:physical_network provider1 --provider:network_type flat

neutron subnet-create MGMT_NET 10.0.61.0/24 --name MGMT_SUBNET
--allocation-pool start=10.0.61.10,end=10.0.61.250 --disable-dhcp --gateway
10.0.61.1

Then I am creating a template with docker storage driver as "Overlay"

openstack coe cluster template create kubernetes-cluster-template
--image fedora-atomic-latest
--docker-storage-driver overlay  --external-network public --dns-nameserver
8.8.8.8 --master-flavor m1.small --flavor m1.small --coe kubernetes

Creating a cluster with 1 master node

openstack coe cluster create kubernetes-cluster --cluster-template
kubernetes-cluster-template --master-count 1 --node-count 1 --keypair
key-pair

When I look into my stack, it shows the event
kube_masters
<http://192.168.121.118/horizon/project/stacks/stack/58ddd64a-8779-495d-8d31-27f3615c8103/kube_masters/>
Create in Progress and eventaully after 1 hr, it gets failed.

I have checked the Troubleshooting Guide as well, but found nothing that
could help me resolving the issue.
https://docs.openstack.org/magnum/rocky/admin/troubleshooting-guide.html

Can you please suggest some pointers in order to resolve the issue.

Regards
Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/f5c07892/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 11:07:52 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 11:07:52 +0000
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
Message-ID: <AM6PR06MB58791E1476619C260FF56C27DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Hongbin,

I could not see the logs. I have installed zun on the baremetal machine with full openstack (not devstack)
-- Logs begin at Tue 2019-04-02 16:23:14 UTC, end at Thu 2019-04-04 09:05:59 UTC. --
-- No entries –

Please advise me how can I enable logging for this.
I can’t find anything in /etc/kuryr/kuryr.log
In my kuryr.conf file I have set the value to debug and the log file as ‘/etc/kuryr/kuryr.log’

My flat network is:
openstack network show 5guknet
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Field                     | Value                                                                                                                                   |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| admin_state_up            | UP                                                                                                                                      |
| availability_zone_hints   |                                                                                                                                         |
| availability_zones        | nova                                                                                                                                    |
| created_at                | 2019-04-03T15:30:50Z                                                                                                                    |
| description               |                                                                                                                                         |
| dns_domain                | None                                                                                                                                    |
| id                        | a9decbf0-e8c8-4574-86f8-242756fce63b                                                                                                    |
| ipv4_address_scope        | None                                                                                                                                    |
| ipv6_address_scope        | None                                                                                                                                    |
| is_default                | False                                                                                                                                   |
| is_vlan_transparent       | None                                                                                                                                    |
| mtu                       | 1500                                                                                                                                    |
| name                      | 5guknet                                                                                                                                 |
| port_security_enabled     | True                                                                                                                                    |
| project_id                | a8888997d0da4d3d80fe7ca833e74bb7                                                                                                        |
| provider:network_type     | flat                                                                                                                                    |
| provider:physical_network | 5guknet                                                                                                                                 |
| provider:segmentation_id  | None                                                                                                                                    |
| qos_policy_id             | None                                                                                                                                    |
| revision_number           | 4                                                                                                                                       |
| router:external           | External                                                                                                                                |
| segments                  | None                                                                                                                                    |
| shared                    | True                                                                                                                                    |
| status                    | ACTIVE                                                                                                                                  |
| subnets                   | e684a17b-6b17-4ea2-bbc9-752a21304dcc                                                                                                    |
| tags                      | kuryr.net.existing:7c34de9e89a3, kuryr.net.uuid.lh:7c34de9e89a3e86ee3561834520bc2ea, kuryr.net.uuid.uh:35c16ff10c1821c06a7098833e0bf131 |
| updated_at                | 2019-04-03T15:33:37Z                                                                                                                    |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+

Subnet:

openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| allocation_pools  | 10.68.48.131-10.68.48.150            |
| cidr              | 10.68.48.0/24                        |
| created_at        | 2019-04-03T15:30:51Z                 |
| description       |                                      |
| dns_nameservers   | 8.8.8.8                              |
| enable_dhcp       | True                                 |
| gateway_ip        | 10.68.48.1                           |
| host_routes       |                                      |
| id                | e684a17b-6b17-4ea2-bbc9-752a21304dcc |
| ip_version        | 4                                    |
| ipv6_address_mode | None                                 |
| ipv6_ra_mode      | None                                 |
| name              | 5guknet                              |
| network_id        | a9decbf0-e8c8-4574-86f8-242756fce63b |
| project_id        | a8888997d0da4d3d80fe7ca833e74bb7     |
| revision_number   | 1                                    |
| segment_id        | None                                 |
| service_types     |                                      |
| subnetpool_id     | None                                 |
| tags              | b130d090-9b7f-4c68-9f45-775a18bbb649 |
| updated_at        | 2019-04-03T15:33:37Z                 |
+-------------------+--------------------------------------+

Port:
openstack port show 8b203580-2051-4ad0-8057-c7885324d0b9
+-----------------------+-----------------------------------------------------------------------------+
| Field                 | Value                                                                       |
+-----------------------+-----------------------------------------------------------------------------+
| admin_state_up        | UP                                                                          |
| allowed_address_pairs |                                                                             |
| binding_host_id       | bedminster                                                                  |
| binding_profile       |                                                                             |
| binding_vif_details   | port_filter='True'                                                          |
| binding_vif_type      | bridge                                                                      |
| binding_vnic_type     | normal                                                                      |
| created_at            | 2019-04-04T09:05:33Z                                                        |
| data_plane_status     | None                                                                        |
| description           |                                                                             |
| device_id             | c6428670-2846-4862-8ecb-611293cabc2c                                        |
| device_owner          | compute:kuryr                                                               |
| dns_assignment        | None                                                                        |
| dns_domain            | None                                                                        |
| dns_name              | None                                                                        |
| extra_dhcp_opts       |                                                                             |
| fixed_ips             | ip_address='10.68.48.143', subnet_id='e684a17b-6b17-4ea2-bbc9-752a21304dcc' |
| id                    | 8b203580-2051-4ad0-8057-c7885324d0b9                                        |
| mac_address           | fa:16:3e:2e:07:ad                                                           |
| name                  |                                                                             |
| network_id            | a9decbf0-e8c8-4574-86f8-242756fce63b                                        |
| port_security_enabled | True                                                                        |
| project_id            | a8888997d0da4d3d80fe7ca833e74bb7                                            |
| qos_policy_id         | None                                                                        |
| revision_number       | 2                                                                           |
| security_group_ids    | 49839b6f-79c7-4db7-bb71-ffecbdd645d5                                        |
| status                | DOWN                                                                        |
| tags                  |                                                                             |
| trunk_details         | None                                                                        |
| updated_at            | 2019-04-04T09:05:33Z                                                        |
+-----------------------+-----------------------------------------------------------------------------+
Thank you,
Kind Regards,
Navdeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/079a7d21/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 11:31:18 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 11:31:18 +0000
Subject: SFC delete port chain failed
In-Reply-To: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <AM6PR06MB587931DB42754C8F9DE40FBDDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Following are the logs while creating the Port Chain:

2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/base.py", line 58, in create_port_chain_postcommit
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     self.create_port_chain(context)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 881, in create_port_chain
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     None)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 809, in _update_path_nodes
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     add_fc_ids, del_fc_ids)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 802, in _update_path_node_flowrules
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     port, pc_corr, add_fc_ids, del_fc_ids)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 790, in _update_path_node_port_flowrules
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     self._update_agent_fdb_entries(context, flow_rule)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 189, in _update_agent_fdb_entries
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "add_fdb_entries", flow_rule)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:27:23.441 182047 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.driver_manager [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in create_port_chain_postcommit
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] create_port_chain_postcommit failed.: SfcDriverError: create_port_chain_postcommit failed.
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 59, in create_port_chain
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin     portchain_db_context)
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 121, in create_port_chain_postcommit
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("create_port_chain_postcommit", context)
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin SfcDriverError: create_port_chain_postcommit failed.
2019-04-04 12:27:23.443 182047 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:27:23.444 182047 ERROR networking_sfc.services.sfc.plugin [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Create port chain failed, deleting port_chain '7ec277f2-913d-4541-ab8d-b0d3a5c9c8b2': SfcDriverError: create_port_chain_postcommit failed.
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:27:23.706 182047 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.driver_manager [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:27:23.707 182047 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:27:23.708 182047 ERROR networking_sfc.services.sfc.plugin [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain '7ec277f2-913d-4541-ab8d-b0d3a5c9c8b2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:27:23.708 182047 ERROR root [req-3b14375a-a47c-49ee-bf2e-da7755536742 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Original exception being dropped: ['Traceback (most recent call last):\n', '  File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 59, in create_port_chain\n    portchain_db_context)\n', '  File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 121, in create_port_chain_postcommit\n    self._call_drivers("create_port_chain_postcommit", context)\n', '  File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers\n    method=method_name\n', 'SfcDriverError: create_port_chain_postcommit failed.\n']: SfcDriverError: delete_port_chain failed.

Kind Regards,
Navdeep

From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Sent: 04 April 2019 12:06
To: openstack at lists.openstack.org
Subject: SFC delete port chain failed

Dear All,

I am facing errors while creating/deleting the SF Chain:

2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.

Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/da161abb/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 11:39:22 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 11:39:22 +0000
Subject: SFC delete port chain failed
In-Reply-To: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

In addition to the following logs, I have attached the logs I captured while creating the port chain.

From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Sent: 04 April 2019 12:06
To: openstack at lists.openstack.org
Subject: SFC delete port chain failed

Dear All,

I am facing errors while creating/deleting the SF Chain:

2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.

Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/d4f97b76/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SFC Creation Logs-Neutron.txt
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/d4f97b76/attachment-0001.txt>

From hongbin034 at gmail.com  Thu Apr  4 13:09:57 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Thu, 4 Apr 2019 09:09:57 -0400
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>

On Thu, Apr 4, 2019 at 5:14 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Hi Hongbin,
>
>
>
> I could not see the logs. I have installed zun on the baremetal machine
> with full openstack (not devstack)
>
> -- Logs begin at Tue 2019-04-02 16:23:14 UTC, end at Thu 2019-04-04
> 09:05:59 UTC. --
>
> -- No entries –
>

My bad. If you were following the installation guide, you should run "sudo
journalctl -u kuryr-libnetwork"


>
>
> Please advise me how can I enable logging for this.
>
> I can’t find anything in /etc/kuryr/kuryr.log
> In my kuryr.conf file I have set the value to debug and the log file as
> ‘/etc/kuryr/kuryr.log’
>

It is systemd process so uses journalctl to retrieve the log. No further
configuration is needed, although it is always helpful to turn on debug on
troubleshooting


>
> My flat network is:
>
> openstack network show 5guknet
>
>
> +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
>
> | Field                     |
> Value
> |
>
>
> +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
>
> | admin_state_up            |
> UP
> |
>
> | availability_zone_hints
> |
> |
>
> | availability_zones        |
> nova
>                                                                       |
>
> | created_at                |
> 2019-04-03T15:30:50Z
> |
>
> | description
>             |
> |
>
> | dns_domain                |
> None
>                                                               |
>
> | id                        |
> a9decbf0-e8c8-4574-86f8-242756fce63b
> |
>
> | ipv4_address_scope        |
> None
> |
>
> | ipv6_address_scope        |
> None
>                                                       |
>
> | is_default                |
> False
> |
>
> | is_vlan_transparent       |
> None
> |
>
> | mtu                       |
> 1500
>                                               |
>
> | name                      |
> 5guknet
> |
>
> | port_security_enabled     | True
>                                                                                                                               |
>
> | project_id                |
> a8888997d0da4d3d80fe7ca833e74bb7
>                                       |
>
> | provider:network_type     |
> flat
> |
>
> | provider:physical_network | 5guknet
>                                                                                                                       |
>
> | provider:segmentation_id  |
> None
>                               |
>
> | qos_policy_id             |
> None
> |
>
> | revision_number           | 4
>                                                                                                               |
>
> | router:external           |
> External
>                       |
>
> | segments                  |
> None
> |
>
> | shared                    | True
>                                                                                                       |
>
> | status                    |
> ACTIVE
>               |
>
> | subnets                   |
> e684a17b-6b17-4ea2-bbc9-752a21304dcc
> |
>
> | tags                      | kuryr.net.existing:7c34de9e89a3,
> kuryr.net.uuid.lh:7c34de9e89a3e86ee3561834520bc2ea,
> kuryr.net.uuid.uh:35c16ff10c1821c06a7098833e0bf131 |
>
> | updated_at                |
> 2019-04-03T15:33:37Z
>       |
>
>
> +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
>
>
>
> Subnet:
>
> openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc
>
> +-------------------+--------------------------------------+
>
> | Field             | Value                                |
>
> +-------------------+--------------------------------------+
>
> | allocation_pools  | 10.68.48.131-10.68.48.150            |
>
> | cidr              | 10.68.48.0/24                        |
>
> | created_at        | 2019-04-03T15:30:51Z                 |
>
> | description       |                                      |
>
> | dns_nameservers   | 8.8.8.8                              |
>
> | enable_dhcp       | True                                 |
>
> | gateway_ip        | 10.68.48.1                           |
>
> | host_routes       |                                      |
>
> | id                | e684a17b-6b17-4ea2-bbc9-752a21304dcc |
>
> | ip_version        | 4                                    |
>
> | ipv6_address_mode | None                                 |
>
> | ipv6_ra_mode      | None                                 |
>
> | name              | 5guknet                              |
>
> | network_id        | a9decbf0-e8c8-4574-86f8-242756fce63b |
>
> | project_id        | a8888997d0da4d3d80fe7ca833e74bb7     |
>
> | revision_number   | 1                                    |
>
> | segment_id        | None                                 |
>
> | service_types     |                                      |
>
> | subnetpool_id     | None                                 |
>
> | tags              | b130d090-9b7f-4c68-9f45-775a18bbb649 |
>
> | updated_at        | 2019-04-03T15:33:37Z                 |
>
> +-------------------+--------------------------------------+
>
>
>
> Port:
> openstack port show 8b203580-2051-4ad0-8057-c7885324d0b9
>
>
> +-----------------------+-----------------------------------------------------------------------------+
>
> | Field                 |
> Value
> |
>
>
> +-----------------------+-----------------------------------------------------------------------------+
>
> | admin_state_up        | UP
>                                                       |
>
> | allowed_address_pairs
> |
> |
>
> | binding_host_id       |
> bedminster
>       |
>
> | binding_profile
> |
> |
>
> | binding_vif_details   |
> port_filter='True'
> |
>
> | binding_vif_type      | bridge
>                                                               |
>
> | binding_vnic_type     |
> normal
> |
>
> | created_at            |
> 2019-04-04T09:05:33Z
>               |
>
> | data_plane_status     |
> None
> |
>
> | description
> |
> |
>
> | device_id             |
> c6428670-2846-4862-8ecb-611293cabc2c
> |
>
> | device_owner          |
> compute:kuryr
> |
>
> | dns_assignment        |
> None
>                       |
>
> | dns_domain            |
> None
> |
>
> | dns_name              |
> None
> |
>
> | extra_dhcp_opts
> |
> |
>
> | fixed_ips             | ip_address='10.68.48.143',
> subnet_id='e684a17b-6b17-4ea2-bbc9-752a21304dcc' |
>
> | id                    | 8b203580-2051-4ad0-8057-c7885324d0b9
>                               |
>
> | mac_address           |
> fa:16:3e:2e:07:ad
> |
>
> | name
> |
> |
>
> | network_id            |
> a9decbf0-e8c8-4574-86f8-242756fce63b
> |
>
> | port_security_enabled |
> True
> |
>
> | project_id            | a8888997d0da4d3d80fe7ca833e74bb7
>                                       |
>
> | qos_policy_id         |
> None
> |
>
> | revision_number       |
> 2
> |
>
> | security_group_ids    |
> 49839b6f-79c7-4db7-bb71-ffecbdd645d5
> |
>
> | status                |
> DOWN
> |
>
> | tags
> |
> |
>
> | trunk_details         |
> None
> |
>
> | updated_at            | 2019-04-04T09:05:33Z
>                                                       |
>
>
> +-----------------------+-----------------------------------------------------------------------------+
>
> Thank you,
>
> Kind Regards,
>
> Navdeep
>
>
>
>
>
> *From:* Hongbin Lu <hongbin034 at gmail.com>
> *Sent:* 04 April 2019 02:49
> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error
>
>
>
> Hi Navdeep,
>
>
>
> It looks I cannot reproduce the problem using rocky with flat network. If
> possible, would you provide the following:
>
>
>
> * Your kuryr-libnetwork log (with sensitive information removed). You can
> get it by running "sudo journalctl -u devstack at kuryr-libnetwork".
>
> * Your flat network (openstack network show XXX)
>
> * Your subnet (openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc)
>
> * Your port (openstack port show f0d6153a-7408-4cd5-82c3-9abed48ad056)
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> On Wed, Apr 3, 2019 at 11:52 AM Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
> Dear All,
>
>
>
> I have just installed Zun and tried creating a container following the
> instructions as per the following webpage:
>
> https://docs.openstack.org/zun/rocky/install/index.html
>
>
>
> I am getting following error while starting my test container using
> ‘openstack appcontainer run --name container2 --net network=$NET_ID cirros
> ping 8.8.8.8’:
>
>
>
> status_reason     | Docker internal error: 500 Server Error: Internal
> Server Error ("IpamDriver.RequestAddress: Requested ip address
> {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address':
> u'10.68.48.147'} already belongs to a bound Neutron port:
> f0d6153a-7408-4cd5-82c3-9abed48ad056").
>
>
>
> The network I selected is a flat network on openstack with external flag
> true.
>
> Please advise me how to solve the issue or if there is a specific
> requirement for this.
>
>
>
> Thank you,
>
> Kind Regards,
>
> Navdeep
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/824c6c82/attachment-0001.html>

From correajl at gmail.com  Thu Apr  4 13:18:58 2019
From: correajl at gmail.com (Jorge Luiz Correa)
Date: Thu, 4 Apr 2019 10:18:58 -0300
Subject: Help with kernel panic on cirros image boot process.
Message-ID: <CAE2bT_25e1DSrczFKy1ovz+R9qV-OJjribmW6xbi21--eYrOSQ@mail.gmail.com>

Hi all!

I'm having kernel panic randomically with cirros image. Sometimes the
instances boots, sometimes not.

I'm using Openstack Queens, Ubuntu Server 18.04 and KVM (following the
install guide). The nova/instances directory, where are stored ephemeral
disks, is over a GlusterFS system.

I've noted that other images, like Ubuntu Cloud Image, do not get this
error. It's just with cirros and sometimes.

I appreciate any help guiding on where I can look for to identify what is
causing these errors. I've analyzed libvirt logs and them show just a
launched instance, everything ok. The _base/<ID> file used to launch the
instances is the same that is used with cirros instances that worked (it's
in a GlusterFS). Something got wrong during the instance boot process.

Thank you!

[    1.586076] EDD information not available.
[    1.590261] Freeing unused kernel memory: 1480K (ffffffff81f42000 -
ffffffff820b4000)
[    1.594823] Write protecting the kernel read-only data: 14336k
[    1.598951] Freeing unused kernel memory: 1860K (ffff88000182f000 -
ffff880001a00000)
[    1.625178] Freeing unused kernel memory: 168K (ffff880001dd6000 -
ffff880001e00000)

info: initramfs: up at 1.07
modprobe: module virtio_pci not found in modules.dep
modprobe: module virtio_blk not found in modules.dep
modprobe: module virtio_net not found in modules.dep
modprobe: module vfat not found in modules.dep
modprobe: module nls_cp437 not found in modules.dep
info: copying initramfs to /dev/vda1
[    2.028648] jbd2_journal_bmap: journal block not found at offset 12 on
vda1-8
[    2.034075] Aborting journal on device vda1-8.
mount: mounting /dev on ./dev failed: No such file or directory
info: initramfs loading root from /dev/vda1
switch_root: can't execute '/sbin/init': No such file or directory
[    2.692399] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[    2.692399]
[    2.696061] CPU: 0 PID: 1 Comm: switch_root Not tainted 4.4.0-28-generic
#47-Ubuntu
[    2.699012] Hardware name: OpenStack Foundation OpenStack Nova, BIOS
1.10.2-1ubuntu1 04/01/2014
[    2.702373]  0000000000000086 000000004016d54a ffff88003e2fbe10
ffffffff813eb1a3
[    2.705849]  ffffffff81cb10d8 ffff88003e2fbea8 ffff88003e2fbe98
ffffffff8118bf57
[    2.709353]  ffff880000000010 ffff88003e2fbea8 ffff88003e2fbe40
000000004016d54a
[    2.712875] Call Trace:
[    2.714013]  [<ffffffff813eb1a3>] dump_stack+0x63/0x90
[    2.715995]  [<ffffffff8118bf57>] panic+0xd3/0x215
[    2.717840]  [<ffffffff81184e1e>] ? perf_event_exit_task+0xbe/0x350
[    2.720105]  [<ffffffff81084541>] do_exit+0xae1/0xaf0
[    2.722090]  [<ffffffff810845d3>] do_group_exit+0x43/0xb0
[    2.724150]  [<ffffffff81084654>] SyS_exit_group+0x14/0x20
[    2.726207]  [<ffffffff818276b2>] entry_SYSCALL_64_fastpath+0x16/0x71
[    2.729271] Kernel Offset: disabled
[    2.730741] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000100
[    2.730741]

- JLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/b9f5f71d/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 13:21:04 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 13:21:04 +0000
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
Message-ID: <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Hongbin,

Thank you for your reply.
Following are the log errors I am getting:

LogFile:
2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-] Received JSON data {u'Address': u'10.68.48.137', u'Options': {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'}, u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for /IpamDriver.RequestAddress ipam_request_address /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected error happened: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0

Journald:
Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent call last):
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv = self.dispatch_request()
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     return self.view_functions[rule.endpoint](**req.view_args)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 1740, in ipam_request_address
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port, fixed_ip, req_mac_address)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 542, in _update_existing_port
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0


Kind Regards,
Navdeep

From: Hongbin Lu <hongbin034 at gmail.com>
Sent: 04 April 2019 14:10
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: openstack at lists.openstack.org
Subject: Re: [Zun] Address already belongs to a bound Neutron port Error



On Thu, Apr 4, 2019 at 5:14 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Hi Hongbin,

I could not see the logs. I have installed zun on the baremetal machine with full openstack (not devstack)
-- Logs begin at Tue 2019-04-02 16:23:14 UTC, end at Thu 2019-04-04 09:05:59 UTC. --
-- No entries –

My bad. If you were following the installation guide, you should run "sudo journalctl -u kuryr-libnetwork"


Please advise me how can I enable logging for this.
I can’t find anything in /etc/kuryr/kuryr.log
In my kuryr.conf file I have set the value to debug and the log file as ‘/etc/kuryr/kuryr.log’

It is systemd process so uses journalctl to retrieve the log. No further configuration is needed, although it is always helpful to turn on debug on troubleshooting


My flat network is:
openstack network show 5guknet
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Field                     | Value                                                                                                                                   |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| admin_state_up            | UP                                                                                                                                      |
| availability_zone_hints   |                                                                                                                                         |
| availability_zones        | nova                                                                                                                                    |
| created_at                | 2019-04-03T15:30:50Z                                                                                                                    |
| description               |                                                                                                                                         |
| dns_domain                | None                                                                                                                                    |
| id                        | a9decbf0-e8c8-4574-86f8-242756fce63b                                                                                                    |
| ipv4_address_scope        | None                                                                                                                                    |
| ipv6_address_scope        | None                                                                                                                                    |
| is_default                | False                                                                                                                                   |
| is_vlan_transparent       | None                                                                                                                                    |
| mtu                       | 1500                                                                                                                                    |
| name                      | 5guknet                                                                                                                                 |
| port_security_enabled     | True                                                                                                                                    |
| project_id                | a8888997d0da4d3d80fe7ca833e74bb7                                                                                                        |
| provider:network_type     | flat                                                                                                                                    |
| provider:physical_network | 5guknet                                                                                                                                 |
| provider:segmentation_id  | None                                                                                                                                    |
| qos_policy_id             | None                                                                                                                                    |
| revision_number           | 4                                                                                                                                       |
| router:external           | External                                                                                                                                |
| segments                  | None                                                                                                                                    |
| shared                    | True                                                                                                                                    |
| status                    | ACTIVE                                                                                                                                  |
| subnets                   | e684a17b-6b17-4ea2-bbc9-752a21304dcc                                                                                                    |
| tags                      | kuryr.net.existing:7c34de9e89a3, kuryr.net.uuid.lh:7c34de9e89a3e86ee3561834520bc2ea, kuryr.net.uuid.uh:35c16ff10c1821c06a7098833e0bf131 |
| updated_at                | 2019-04-03T15:33:37Z                                                                                                                    |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+

Subnet:

openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| allocation_pools  | 10.68.48.131-10.68.48.150            |
| cidr              | 10.68.48.0/24<http://10.68.48.0/24>                        |
| created_at        | 2019-04-03T15:30:51Z                 |
| description       |                                      |
| dns_nameservers   | 8.8.8.8                              |
| enable_dhcp       | True                                 |
| gateway_ip        | 10.68.48.1                           |
| host_routes       |                                      |
| id                | e684a17b-6b17-4ea2-bbc9-752a21304dcc |
| ip_version        | 4                                    |
| ipv6_address_mode | None                                 |
| ipv6_ra_mode      | None                                 |
| name              | 5guknet                              |
| network_id        | a9decbf0-e8c8-4574-86f8-242756fce63b |
| project_id        | a8888997d0da4d3d80fe7ca833e74bb7     |
| revision_number   | 1                                    |
| segment_id        | None                                 |
| service_types     |                                      |
| subnetpool_id     | None                                 |
| tags              | b130d090-9b7f-4c68-9f45-775a18bbb649 |
| updated_at        | 2019-04-03T15:33:37Z                 |
+-------------------+--------------------------------------+

Port:
openstack port show 8b203580-2051-4ad0-8057-c7885324d0b9
+-----------------------+-----------------------------------------------------------------------------+
| Field                 | Value                                                                       |
+-----------------------+-----------------------------------------------------------------------------+
| admin_state_up        | UP                                                                          |
| allowed_address_pairs |                                                                             |
| binding_host_id       | bedminster                                                                  |
| binding_profile       |                                                                             |
| binding_vif_details   | port_filter='True'                                                          |
| binding_vif_type      | bridge                                                                      |
| binding_vnic_type     | normal                                                                      |
| created_at            | 2019-04-04T09:05:33Z                                                        |
| data_plane_status     | None                                                                        |
| description           |                                                                             |
| device_id             | c6428670-2846-4862-8ecb-611293cabc2c                                        |
| device_owner          | compute:kuryr                                                               |
| dns_assignment        | None                                                                        |
| dns_domain            | None                                                                        |
| dns_name              | None                                                                        |
| extra_dhcp_opts       |                                                                             |
| fixed_ips             | ip_address='10.68.48.143', subnet_id='e684a17b-6b17-4ea2-bbc9-752a21304dcc' |
| id                    | 8b203580-2051-4ad0-8057-c7885324d0b9                                        |
| mac_address           | fa:16:3e:2e:07:ad                                                           |
| name                  |                                                                             |
| network_id            | a9decbf0-e8c8-4574-86f8-242756fce63b                                        |
| port_security_enabled | True                                                                        |
| project_id            | a8888997d0da4d3d80fe7ca833e74bb7                                            |
| qos_policy_id         | None                                                                        |
| revision_number       | 2                                                                           |
| security_group_ids    | 49839b6f-79c7-4db7-bb71-ffecbdd645d5                                        |
| status                | DOWN                                                                        |
| tags                  |                                                                             |
| trunk_details         | None                                                                        |
| updated_at            | 2019-04-04T09:05:33Z                                                        |
+-----------------------+-----------------------------------------------------------------------------+
Thank you,
Kind Regards,
Navdeep


From: Hongbin Lu <hongbin034 at gmail.com<mailto:hongbin034 at gmail.com>>
Sent: 04 April 2019 02:49
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>>
Cc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Subject: Re: [Zun] Address already belongs to a bound Neutron port Error

Hi Navdeep,

It looks I cannot reproduce the problem using rocky with flat network. If possible, would you provide the following:

* Your kuryr-libnetwork log (with sensitive information removed). You can get it by running "sudo journalctl -u devstack at kuryr-libnetwork".
* Your flat network (openstack network show XXX)
* Your subnet (openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc)
* Your port (openstack port show f0d6153a-7408-4cd5-82c3-9abed48ad056)

Best regards,
Hongbin

On Wed, Apr 3, 2019 at 11:52 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Dear All,

I have just installed Zun and tried creating a container following the instructions as per the following webpage:
https://docs.openstack.org/zun/rocky/install/index.html

I am getting following error while starting my test container using ‘openstack appcontainer run --name container2 --net network=$NET_ID cirros ping 8.8.8.8’:

status_reason     | Docker internal error: 500 Server Error: Internal Server Error ("IpamDriver.RequestAddress: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.147'} already belongs to a bound Neutron port: f0d6153a-7408-4cd5-82c3-9abed48ad056").

The network I selected is a flat network on openstack with external flag true.

Please advise me how to solve the issue or if there is a specific requirement for this.

Thank you,
Kind Regards,
Navdeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/f6eb6ac7/attachment-0001.html>

From ralf.teckelmann at bertelsmann.de  Thu Apr  4 14:14:37 2019
From: ralf.teckelmann at bertelsmann.de (Teckelmann, Ralf, NMU-OIP)
Date: Thu, 4 Apr 2019 14:14:37 +0000
Subject: OpenStack Newton MessagingTimeouts for os-getVNCConsole
In-Reply-To: <AM6PR04MB4711F9E88C93A6F66F270F2689500@AM6PR04MB4711.eurprd04.prod.outlook.com>
References: <AM6PR04MB4711F9E88C93A6F66F270F2689500@AM6PR04MB4711.eurprd04.prod.outlook.com>
Message-ID: <AM6PR04MB4711661696592F5F37357FBD89500@AM6PR04MB4711.eurprd04.prod.outlook.com>

Hello everyone,

My colleagues and I are maintaining a newton-based openstack installation.
We use linux containers on ubuntu 16.04 nodes for service separation and HA.
After switiching to HTTPS + Domain for all our Endpoints (was http and IP-based before) we face the problem of MessagingTimeout for os-getVNCConsole-Requests.

In (1) you can find the Stack Trace we get on a request for VNCConsole Access.
We have traced this down to the point were we actually tcpdumped the communication and we can see the response message arriving back(2).

The timeline looks like:

- 13:37:22 GMT        - Sending request via nova get-vnc-console a29f9b95-055e-4f30-8a30-ac0bcde32dd1 novnc
- xx:xx:xx                  - Arrival at RabbitMQ
- 14:37:22.806 CET  - Compute Hosts gets the request
- 14:37:22.810 CET  - Compute Hosts sends response to RabbitMQ
- xx:xx:xx                  - Response enters RabbitMQ
- 14:37:22.812 CET  - tcpdumped response at the interface of the control node where the nova cloud controller resides on, who send the request
- 13:38:22.826 UTC  - Timeout /var/log/nova/nova-api-os-compute.log

It could be expected, that the response messages actually arrives at the requesting process.
However, I can not narrow it down to exactly this point, because
- I can't tcpdump in an lxd container
- The system is highly productive and possibilities for debugging are limited
- We have no other problems with this installation in any matter, so a global problem can be excluded

We are actually not sure if the mismatch in timezones acutally leads to a problem.
The fact, that our problem is isolated and all other communication runs fine makes us believe it's not.

Taking the returned "access_url" from the sniffed package(2) and e.g. pasting it to a browser, we get the Standard VNC Console Screen.
This shows the general communication via port 6080 is also possible.
Nonetheless, even doing the as soon as the package was sniffed I never got an actual novnc-session to the VM.

We are stuck at this point, because we simply can't completely understand the python code :(
I hope you can ask some helping questions to get us a step further.

You can find a list of our current dpkg and pip packages in (3).

Questions we are currently able formulate are:
- Is there any communication taking place besides the regular ports (8774, 6080, 5672) in the process?
- are the generated access_urls verified in any way after receiving the response message from RabbitMQ, which could lead to an exception being thrown?
- are we looking at the right communication flow (https://docs.openstack.org/nova/pike/_images/SCH_5009_V00_NUAC-VNC_OpenStack.png, there is no one for newton!?) at all?

Best regards

Ralf Teckelmann

(1)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions Traceback (most recent call last):
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 338, in wrapped
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return f(*args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in wrapper
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return func(*args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/remote_consoles.py", line 56, in get_vnc_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions console_type)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 157, in wrapped
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 3283, in get_vnc_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions access_url=connect_info['access_url'])
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/consoleauth/rpcapi.py", line 89, in authorize_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return cctxt.call(ctxt, 'authorize_console', **msg_args)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 169, in call
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=self.retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 97, in _send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions timeout=timeout, retry=retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 464, in send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 453, in _send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions result = self._waiter.wait(msg_id, timeout)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in wait
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions message = self.waiters.get(msg_id, timeout=timeout)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 238, in get
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions 'to message ID %s' % msg_id)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions MessagingTimeout: Timed out waiting for a reply to message ID bd66ed7b4fe44f5c8527573081379639

(2) IP addresses are obfuscate in order to meet company regulation
2019-03-29 14:37:22.812563 IP (tos 0x0, ttl 64, id 36768, offset 0, flags [DF], proto TCP (6), length 662)
 x.31.129.217.5672 > x.31.129.206.45604: Flags [P.], cksum 0x83a3 (correct), seq 959640600:959641210, ack 3516429040, win 243, options [nop,nop,TS val 3070303066 ecr 3070033633], length 610
E..... at .@.L..........(.$92....r............
...Z..........].<.<.1.......N.&reply_d5cb71955a3a4a39b1e8f6539a72be4f&reply_d5cb71955a3a4a39b1e8f6539a72be4f.......+.<.............application/json.utf-8..............{"oslo.message": "{\"_msg_id\": \"ae4ea417e79c43af9d1cd2d603b32076\", \"failure\": null, \"_unique_id\": \"e357642aaef34d1fbaa4d240c405d572\", \"result\": {\"internal_access_path\": null, \"host\": \"x.31.129.164\", \"access_url\": \"https://api.secret.cloud:6080/vnc_auto.html?token=44b7d9be-2aab-4239-914c-971d615fa9c0\", \"token\": \"44b7d9be-2aab-4239-914c-971d615fa9c0\", \"port\": \"5912\"}, \"ending\": true}", "oslo.version": "2.0"}.

(3)
:~# dpkg -l | grep amqp
ii  python-amqp                      1.4.9-1                                    all          Low-level AMQP client

:~# dpkg -l | grep oslo.messaging
ii  python-oslo.messaging            5.10.0-0ubuntu2~cloud0                     all          oslo messaging library - Python 2.x

:~# dpkg -l | grep nova
ii  nova-api-os-compute              2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - OpenStack Compute API frontend
ii  nova-cert                        2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - certificate management
ii  nova-common                      2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - common files
ii  nova-conductor                   2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - conductor service
ii  nova-consoleauth                 2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - Console Authenticator
ii  nova-novncproxy                  2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - NoVNC proxy
ii  nova-scheduler                   2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - virtual machine scheduler
ii  python-nova                      2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute Python libraries
ii  python-novaclient                2:6.0.0-0ubuntu1~cloud0                    all          client library for OpenStack Compute API - Python 2.7

:~# pip list | grep amqp
amqp (1.4.9)

:~# pip list | grep oslo
oslo.cache (1.14.0)
oslo.concurrency (3.14.0)
oslo.config (3.17.0)
oslo.context (2.9.0)
oslo.db (4.13.3)
oslo.i18n (3.9.0)
oslo.log (3.16.0)
oslo.messaging (5.10.0)
oslo.middleware (3.19.0)
oslo.policy (1.14.0)
oslo.privsep (1.13.0)
oslo.reports (1.14.0)
oslo.rootwrap (5.1.0)
oslo.serialization (2.13.0)
oslo.service (1.16.0)
oslo.utils (3.16.0)
oslo.versionedobjects (1.17.0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/04961b15/attachment-0001.html>

From aschultz at redhat.com  Thu Apr  4 14:32:56 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Thu, 4 Apr 2019 08:32:56 -0600
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <20190404135410.ph2o55jej57binmx@mthode.org>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
Message-ID: <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>

On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org> wrote:
>
> On 19-04-04 01:20:18, Eric K wrote:
> > Requesting exception to remove a requirement to resolve a packaging issue.
> >
> > The package is needed only for an experimental feature, but causes
> > packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
> > require manual install to enable the experimental feature.
> >
> > https://review.openstack.org/#/c/649772/
> >
>
> I imagine psycopg2 is one of many dependencies that are not fully
> compliant with our upper-constraints (and probably a bunch of projects
> global-constraints).  Is it possible to lower the version required (be
> compatible with 2.6 or whatever is in centos)?  The requirements project
> itself sets no lower bound for psycopg2.
>

Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
optional it would be nice for it not to be included by default. We hit
the issue in puppet-congress so we disabled out actual test jobs[0]
because congress currently doesn't work on ubuntu[1] and was broken on
centos[2] by this new requirement.

[0] https://review.openstack.org/#/c/649439/
[1] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubuntu-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
[2] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-centos-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47


> --
> Matthew Thode


From sean.mcginnis at gmx.com  Thu Apr  4 14:35:27 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 4 Apr 2019 09:35:27 -0500
Subject: [Release-job-failures][freezer] Tag of openstack/freezer-api failed
Message-ID: <20190404143526.GA16891@sm-workstation>

The release of freezer-api failed due to the use of oslosphinx.

Sphinx 2.0 was released late last week, and with the major version bump, it has
now removed some deprecated things that the oslosphinx theme was using.

Projects have been migrating to openstackdocstheme for some time now, with the
majority using that instead. Since oslosphinx was going away anyway, it is now
being retired and compatibility issues will not be fixed.

I have proposed a patch to get freezer-api moved over to openstackdocstheme:

https://review.openstack.org/650032

This (or something like it) will need to be merged before we can do a
successful release of freezer-api since release notes are generated off of the
master branch.

Sean

----- Forwarded message from zuul at openstack.org -----

Date: Thu, 04 Apr 2019 14:14:59 +0000
From: zuul at openstack.org
To: release-job-failures at lists.openstack.org
Subject: [Release-job-failures] Tag of openstack/freezer-api failed
Reply-To: openstack-discuss at lists.openstack.org

Build failed.

- publish-openstack-releasenotes-python3 http://logs.openstack.org/59/59a8e662bb73926eb35cd49fbc7371c9dc7170bd/tag/publish-openstack-releasenotes-python3/e2f81b5/ : FAILURE in 3m 01s



From saphi070 at gmail.com  Thu Apr  4 14:40:07 2019
From: saphi070 at gmail.com (Sa Pham)
Date: Thu, 4 Apr 2019 23:40:07 +0900
Subject: SFC delete port chain failed
In-Reply-To: <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAA1DRz=K+FjEY2R3+eDxoFDG=MrT5VR7eE34gkOrB3inT1Un_g@mail.gmail.com>

What is the version of Openstack and networking-sfc you are running?

On Thu, Apr 4, 2019 at 11:38 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> In addition to the following logs, I have attached the logs I captured
> while creating the port chain.
>
>
>
> *From:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Sent:* 04 April 2019 12:06
> *To:* openstack at lists.openstack.org
> *Subject:* SFC delete port chain failed
>
>
>
> Dear All,
>
>
>
> I am facing errors while creating/deleting the SF Chain:
>
>
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956
> 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext'
> object has no attribute 'session': AttributeError: 'PortChainContext'
> object has no attribute 'session'
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager Traceback (most recent call
> last):
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py",
> line 101, in _call_drivers
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     getattr(driver.obj,
> method_name)(context)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     return method(*args,
> **kwargs)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 887, in delete_port_chain
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> self._delete_portchain_path(context, port_chain)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     return method(*args,
> **kwargs)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 594, in _delete_portchain_path
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> port_chain['flow_classifiers']
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 577, in _delete_path_node_flowrule
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     context, node, port,
> pc_corr, fc_ids)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 568, in _delete_path_node_port_flowrule
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> self._delete_agent_fdb_entries(context, flow_rule)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 192, in _delete_agent_fdb_entries
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 170, in _call_on_l2pop_driver
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     pop_ports =
> self._get_remote_pop_ports(context, flow_rule)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     return method(*args,
> **kwargs)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py",
> line 133, in _get_remote_pop_ports
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager   File
> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py",
> line 152, in get_agent_network_active_port_count
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager     query =
> context.session.query(models_v2.Port)
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager AttributeError:
> 'PortChainContext' object has no attribute 'session'
>
> 2019-04-04 12:00:10.186 182062 ERROR
> networking_sfc.services.sfc.driver_manager
>
> 2019-04-04 12:00:10.188 182062 ERROR
> networking_sfc.services.sfc.driver_manager
> [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956
> 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed
> in delete_port_chain
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956
> 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain
> failed.: SfcDriverError: delete_port_chain failed.
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> Traceback (most recent call last):
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py",
> line 99, in delete_port_chain
>
> 2019-04-04 12:00:10.189 182062 ERROR
> networking_sfc.services.sfc.plugin
> self.driver_manager.delete_port_chain(pc_context)
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py",
> line 130, in delete_port_chain
>
> 2019-04-04 12:00:10.189 182062 ERROR
> networking_sfc.services.sfc.plugin
> self._call_drivers("delete_port_chain", context)
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py",
> line 113, in _call_drivers
>
> 2019-04-04 12:00:10.189 182062 ERROR
> networking_sfc.services.sfc.plugin     method=method_name
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> SfcDriverError: delete_port_chain failed.
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
>
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956
> 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain
> failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError:
> delete_port_chain failed.
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956
> 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No
> details.: SfcDriverError: delete_port_chain failed.
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback
> (most recent call last):
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in
> resource
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result =
> method(request=request, **args)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in
> delete
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return
> self._delete(request, id, **kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> setattr(e, '_RETRY_EXCEEDED', True)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220,
> in __exit__
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self.force_reraise()
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196,
> in force_reraise
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> six.reraise(self.type_, self.value, self.tb)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return
> f(*args, **kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> ectxt.value = e.inner_exc
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220,
> in __exit__
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self.force_reraise()
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196,
> in force_reraise
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> six.reraise(self.type_, self.value, self.tb)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return
> f(*args, **kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> LOG.debug("Retry wrapper got retriable exception: %s", e)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220,
> in __exit__
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self.force_reraise()
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196,
> in force_reraise
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> six.reraise(self.type_, self.value, self.tb)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return
> f(*dup_args, **dup_kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in
> _delete
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> obj_deleter(request.context, id, **kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return
> method(*args, **kwargs)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py",
> line 104, in delete_port_chain
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> portchain_id)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220,
> in __exit__
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self.force_reraise()
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196,
> in force_reraise
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> six.reraise(self.type_, self.value, self.tb)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py",
> line 99, in delete_port_chain
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self.driver_manager.delete_port_chain(pc_context)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py",
> line 130, in delete_port_chain
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> self._call_drivers("delete_port_chain", context)
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File
> "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py",
> line 113, in _call_drivers
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> method=method_name
>
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource
> SfcDriverError: delete_port_chain failed.
>
>
>
> Due to this error, I am unable to delete the existing chain. I am using
> openstack queens Full installation. Please let me know how to triage this
> issue.
>
>
>
> Kind Regards,
>
> Navdeep
>
>
>


-- 
Sa Pham Dang
Master Student - Soongsil University
Kakaotalk: sapd95
Skype: great_bn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/f32ea8dc/attachment-0001.html>

From gmann at ghanshyammann.com  Thu Apr  4 14:46:27 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 04 Apr 2019 09:46:27 -0500
Subject: [qa][patrole] get_tenant_network found None
In-Reply-To: <83dcbb8b-40a2-4558-8a8d-e72ab188f08d@Spark>
References: <478c2524-be5b-45ea-989c-7c5d659bfc30@Spark>
 <83dcbb8b-40a2-4558-8a8d-e72ab188f08d@Spark>
Message-ID: <169e8d0bc98.b5c1eb5d78051.7217687696537549233@ghanshyammann.com>

---- On Thu, 04 Apr 2019 08:57:06 -0500 Sergey Vilgelm <sergey at vilgelm.info> wrote ----
 >  Hello, 
 >  There is an issue with get_tenant_network function in the Patrole tests. Zuul failed on patch set [0] due to 'Multiple possible networks found, use a Network ID to be more specific’[1]. Tempest logs[2] contain an message: '(ServerActionsRbacTest:setUpClass) Found network None available for tenant’. 

Ok, that is because of creating the shared network in devstack which merged recently. I will push the fix.

-gmann

 >  Who knows why this can happen? I have an idea, that this could happen in case of a parallel test running and one test rewrote the roles and another test didn’t find a tenant's network at same time because of the wrong roles. 
 >  
 >  [0] https://review.openstack.org/#/c/648255/ [1] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/testr_results.html.gz [2] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/controller/logs/tempest_log.txt.gz 
 >   
 >   -- Sergey Vilgelm  https://www.vilgelm.info  
 >     



From sean.mcginnis at gmx.com  Thu Apr  4 14:46:45 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 4 Apr 2019 09:46:45 -0500
Subject: [Release-job-failures][freezer] Tag of openstack/freezer-api
 failed
In-Reply-To: <20190404143526.GA16891@sm-workstation>
References: <20190404143526.GA16891@sm-workstation>
Message-ID: <20190404144644.GA17795@sm-workstation>

>
> I have proposed a patch to get freezer-api moved over to openstackdocstheme:
>
> https://review.openstack.org/650032
>
> This (or something like it) will need to be merged before we can do a
> successful release of freezer-api since release notes are generated off of the
> master branch.
>

To clarify, tagging, uploading tarballs, uploading to pypi, and all branching
was successful. We just need a patch merged fixing the release notes build in
order for the updated content to be published.

Sean


From mthode at mthode.org  Thu Apr  4 14:50:16 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 09:50:16 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
Message-ID: <20190404145016.uh6bsofqcftccjlp@mthode.org>

On 19-04-04 08:32:56, Alex Schultz wrote:
> On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org> wrote:
> >
> > On 19-04-04 01:20:18, Eric K wrote:
> > > Requesting exception to remove a requirement to resolve a packaging issue.
> > >
> > > The package is needed only for an experimental feature, but causes
> > > packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
> > > require manual install to enable the experimental feature.
> > >
> > > https://review.openstack.org/#/c/649772/
> > >
> >
> > I imagine psycopg2 is one of many dependencies that are not fully
> > compliant with our upper-constraints (and probably a bunch of projects
> > global-constraints).  Is it possible to lower the version required (be
> > compatible with 2.6 or whatever is in centos)?  The requirements project
> > itself sets no lower bound for psycopg2.
> >
> 
> Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
> optional it would be nice for it not to be included by default. We hit
> the issue in puppet-congress so we disabled out actual test jobs[0]
> because congress currently doesn't work on ubuntu[1] and was broken on
> centos[2] by this new requirement.
> 
> [0] https://review.openstack.org/#/c/649439/
> [1] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubuntu-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
> [2] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-centos-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
> 

extra_requires may work for you (makes postgres support optional)
https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies

not sur eif pbr supports it though.

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/4ef151eb/attachment.sig>

From cboylan at sapwetik.org  Thu Apr  4 15:22:33 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 04 Apr 2019 11:22:33 -0400
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <20190404145016.uh6bsofqcftccjlp@mthode.org>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
Message-ID: <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>

On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
> On 19-04-04 08:32:56, Alex Schultz wrote:
> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org> wrote:
> > >
> > > On 19-04-04 01:20:18, Eric K wrote:
> > > > Requesting exception to remove a requirement to resolve a packaging issue.
> > > >
> > > > The package is needed only for an experimental feature, but causes
> > > > packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
> > > > require manual install to enable the experimental feature.
> > > >
> > > > https://review.openstack.org/#/c/649772/
> > > >
> > >
> > > I imagine psycopg2 is one of many dependencies that are not fully
> > > compliant with our upper-constraints (and probably a bunch of projects
> > > global-constraints).  Is it possible to lower the version required (be
> > > compatible with 2.6 or whatever is in centos)?  The requirements project
> > > itself sets no lower bound for psycopg2.
> > >
> > 
> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
> > optional it would be nice for it not to be included by default. We hit
> > the issue in puppet-congress so we disabled out actual test jobs[0]
> > because congress currently doesn't work on ubuntu[1] and was broken on
> > centos[2] by this new requirement.
> > 
> > [0] https://review.openstack.org/#/c/649439/
> > [1] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubuntu-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
> > [2] http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-centos-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
> > 
> 
> extra_requires may work for you (makes postgres support optional)
> https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies
> 
> not sur eif pbr supports it though.

PBR should support it. Here is an example from swiftclient installing keystoneclient as an extra [3].

[3] https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup.cfg#n36


From openstack at nemebean.com  Thu Apr  4 15:23:45 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Thu, 4 Apr 2019 10:23:45 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <20190404135410.ph2o55jej57binmx@mthode.org>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
Message-ID: <a2e96580-59d8-32fd-e13a-7cde69ca30e4@nemebean.com>



On 4/4/19 8:54 AM, Matthew Thode wrote:
> On 19-04-04 01:20:18, Eric K wrote:
>> Requesting exception to remove a requirement to resolve a packaging issue.
>>
>> The package is needed only for an experimental feature, but causes
>> packaging issue on RHEL/CentOS 7. Propose to remove from requirements and
>> require manual install to enable the experimental feature.
>>
>> https://review.openstack.org/#/c/649772/
>>
> 
> I imagine psycopg2 is one of many dependencies that are not fully
> compliant with our upper-constraints (and probably a bunch of projects
> global-constraints).  Is it possible to lower the version required (be
> compatible with 2.6 or whatever is in centos)?  The requirements project
> itself sets no lower bound for psycopg2.
> 

Note that if your tests actually install psycopg2 you won't be able to 
use lower than 2.7 anymore. Bionic includes postgresql 10, which causes 
psycopg2 < 2.7 installation to fail.

See https://bugs.launchpad.net/oslo.db/+bug/1821400


From mriedemos at gmail.com  Thu Apr  4 16:02:11 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 4 Apr 2019 11:02:11 -0500
Subject: Help with kernel panic on cirros image boot process.
In-Reply-To: <CAE2bT_25e1DSrczFKy1ovz+R9qV-OJjribmW6xbi21--eYrOSQ@mail.gmail.com>
References: <CAE2bT_25e1DSrczFKy1ovz+R9qV-OJjribmW6xbi21--eYrOSQ@mail.gmail.com>
Message-ID: <b849fa07-3904-716a-08fe-6505be561063@gmail.com>

On 4/4/2019 8:18 AM, Jorge Luiz Correa wrote:
> I'm having kernel panic randomically with cirros image. Sometimes the 
> instances boots, sometimes not.

We have the same issue in the upstream CI system with the cirros 0.3.5 
image:

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

Have you tried using the 0.4.0 image?

-- 

Thanks,

Matt


From gmann at ghanshyammann.com  Thu Apr  4 16:03:48 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 04 Apr 2019 11:03:48 -0500
Subject: [qa][patrole] get_tenant_network found None
In-Reply-To: <169e8d0bc98.b5c1eb5d78051.7217687696537549233@ghanshyammann.com>
References: <478c2524-be5b-45ea-989c-7c5d659bfc30@Spark>
 <83dcbb8b-40a2-4558-8a8d-e72ab188f08d@Spark>
 <169e8d0bc98.b5c1eb5d78051.7217687696537549233@ghanshyammann.com>
Message-ID: <169e9178e01.c22cd45080609.1668889994487390494@ghanshyammann.com>

---- On Thu, 04 Apr 2019 09:46:27 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > ---- On Thu, 04 Apr 2019 08:57:06 -0500 Sergey Vilgelm <sergey at vilgelm.info> wrote ---- 
 >  >  Hello,  
 >  >  There is an issue with get_tenant_network function in the Patrole tests. Zuul failed on patch set [0] due to 'Multiple possible networks found, use a Network ID to be more specific’[1]. Tempest logs[2] contain an message: '(ServerActionsRbacTest:setUpClass) Found network None available for tenant’.  
 >  
 > Ok, that is because of creating the shared network in devstack which merged recently. I will push the fix. 

This should fix the issue. patrole was not creating the network for used credential which is what Tempest use for
creating the server.

- https://review.openstack.org/#/c/650059/

-gmann

 >  
 > -gmann 
 >  
 >  >  Who knows why this can happen? I have an idea, that this could happen in case of a parallel test running and one test rewrote the roles and another test didn’t find a tenant's network at same time because of the wrong roles.  
 >  >   
 >  >  [0] https://review.openstack.org/#/c/648255/ [1] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/testr_results.html.gz [2] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/controller/logs/tempest_log.txt.gz  
 >  >    
 >  >   -- Sergey Vilgelm  https://www.vilgelm.info   
 >  > 
 >



From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 15:28:55 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 15:28:55 +0000
Subject: SFC delete port chain failed
In-Reply-To: <CAA1DRz=K+FjEY2R3+eDxoFDG=MrT5VR7eE34gkOrB3inT1Un_g@mail.gmail.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAA1DRz=K+FjEY2R3+eDxoFDG=MrT5VR7eE34gkOrB3inT1Un_g@mail.gmail.com>
Message-ID: <AM6PR06MB58795EDFC1CF8AEAF4007BABDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Pham,

I am able to create the port chain now. However, I cannot see it running.
My scenario is simple with 3 VMs:  VM1---<net1>--VM2--<net2>--VM3 (Please note: it is not working with single network as well)

I followed the following steps:
openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p1vm1
openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p2vm2
openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p1vm2
openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p2vm3

openstack server create --nic port-id=net1p1vm1 --image cloudUb16 --flavor m1.large vm1
openstack server create --nic port-id=net1p2vm2 --nic port-id=net2p1vm2 --image cloudUb16 --flavor m1.large vm2
openstack server create --nic port-id=net2p2vm3 --image cloudUb16 --flavor m1.large vm3

openstack sfc port pair create --ingress net1p1vm1 --egress net1p1vm1 PoP1
openstack sfc port pair create --ingress net1p2vm2 --egress net2p1vm2 PoP2
openstack sfc port pair create --ingress net2p2vm3 --egress net2p2vm3 PoP3

openstack sfc port pair group create --port-pair PoP1 PPGp1
openstack sfc port pair group create --port-pair PoP2 PPGp2
openstack sfc port pair group create --port-pair PoP3 PPGp3

openstack sfc flow classifier create --protocol icmp --ethertype IPv4 --source-ip-prefix 10.10.10.6/32 --destination-ip-prefix 20.20.20.9/32 --logical-source-port net1p1vm1 --logical-destination-port net2p2vm3 FCx

openstack sfc port chain create --flow-classifier FCx --port-pair-group PPGp1 --port-pair-group PPGp2 --port-pair-group PPGp3 PChain

sudo ovs-ofctl dump-flows br-int
cookie=0x4ae16a9e2f1a7bee, duration=101217.953s, table=0, n_packets=268367, n_bytes=445608419, priority=3,in_port="int-br-provider",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:2,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=1415.837s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=1000 actions=mod_vlan_vid:9,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=1215.812s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=500 actions=mod_vlan_vid:10,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=101218.540s, table=0, n_packets=0, n_bytes=0, priority=2,in_port="int-br-pr6e8b65" actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.531s, table=0, n_packets=19, n_bytes=1634, priority=2,in_port="int-br-provider" actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=0, n_packets=1532, n_bytes=106439, priority=0 actions=resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=101218.592s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.590s, table=24, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=60, n_packets=402197, n_bytes=455450343, priority=3 actions=NORMAL

I cannot see any relevant flow entries and the port chain is not working.

Kind Regards,
Navdeep

From: Sa Pham <saphi070 at gmail.com>
Sent: 04 April 2019 15:40
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: openstack at lists.openstack.org
Subject: Re: SFC delete port chain failed

What is the version of Openstack and networking-sfc you are running?

On Thu, Apr 4, 2019 at 11:38 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
In addition to the following logs, I have attached the logs I captured while creating the port chain.

From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>>
Sent: 04 April 2019 12:06
To: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Subject: SFC delete port chain failed

Dear All,

I am facing errors while creating/deleting the SF Chain:

2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.

Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.

Kind Regards,
Navdeep



--
Sa Pham Dang
Master Student - Soongsil University
Kakaotalk: sapd95
Skype: great_bn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/981e0f1e/attachment-0001.html>

From saphi070 at gmail.com  Thu Apr  4 15:39:19 2019
From: saphi070 at gmail.com (Sa Pham)
Date: Fri, 5 Apr 2019 00:39:19 +0900
Subject: SFC delete port chain failed
In-Reply-To: <AM6PR06MB58795EDFC1CF8AEAF4007BABDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAA1DRz=K+FjEY2R3+eDxoFDG=MrT5VR7eE34gkOrB3inT1Un_g@mail.gmail.com>
 <AM6PR06MB58795EDFC1CF8AEAF4007BABDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <6B9E1736-43E3-4776-A6B1-B8661167F295@gmail.com>

As your list of flows in br-int bridge. I don’t see any flow relevant sfc. So maybe your openvswitch-agent can not load sfc extension sucessful. 
Please check log of ovs-first. If right, there is a message like “ loaded extensions [‘sfc’]”. 
If the list extensions above is None. So the extension is not loaded. 

Sa Pham Dang
Cloud RnD Team - VCCLOUD
Phone: 0986849582
Skype: great_bn

> On Apr 5, 2019, at 12:28 AM, Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
> 
> Hi Pham,
> 
> I am able to create the port chain now. However, I cannot see it running.
> My scenario is simple with 3 VMs:  VM1---<net1>--VM2--<net2>--VM3 (Please note: it is not working with single network as well)
>  
> I followed the following steps:
> openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p1vm1
> openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p2vm2
> openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p1vm2
> openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p2vm3
>  
> openstack server create --nic port-id=net1p1vm1 --image cloudUb16 --flavor m1.large vm1
> openstack server create --nic port-id=net1p2vm2 --nic port-id=net2p1vm2 --image cloudUb16 --flavor m1.large vm2
> openstack server create --nic port-id=net2p2vm3 --image cloudUb16 --flavor m1.large vm3
>  
> openstack sfc port pair create --ingress net1p1vm1 --egress net1p1vm1 PoP1
> openstack sfc port pair create --ingress net1p2vm2 --egress net2p1vm2 PoP2
> openstack sfc port pair create --ingress net2p2vm3 --egress net2p2vm3 PoP3
>  
> openstack sfc port pair group create --port-pair PoP1 PPGp1
> openstack sfc port pair group create --port-pair PoP2 PPGp2
> openstack sfc port pair group create --port-pair PoP3 PPGp3
>  
> openstack sfc flow classifier create --protocol icmp --ethertype IPv4 --source-ip-prefix 10.10.10.6/32 --destination-ip-prefix 20.20.20.9/32 --logical-source-port net1p1vm1 --logical-destination-port net2p2vm3 FCx
>  
> openstack sfc port chain create --flow-classifier FCx --port-pair-group PPGp1 --port-pair-group PPGp2 --port-pair-group PPGp3 PChain
>  
> sudo ovs-ofctl dump-flows br-int
> cookie=0x4ae16a9e2f1a7bee, duration=101217.953s, table=0, n_packets=268367, n_bytes=445608419, priority=3,in_port="int-br-provider",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:2,resubmit(,60)
> cookie=0x4ae16a9e2f1a7bee, duration=1415.837s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=1000 actions=mod_vlan_vid:9,resubmit(,60)
> cookie=0x4ae16a9e2f1a7bee, duration=1215.812s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=500 actions=mod_vlan_vid:10,resubmit(,60)
> cookie=0x4ae16a9e2f1a7bee, duration=101218.540s, table=0, n_packets=0, n_bytes=0, priority=2,in_port="int-br-pr6e8b65" actions=drop
> cookie=0x4ae16a9e2f1a7bee, duration=101218.531s, table=0, n_packets=19, n_bytes=1634, priority=2,in_port="int-br-provider" actions=drop
> cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=0, n_packets=1532, n_bytes=106439, priority=0 actions=resubmit(,60)
> cookie=0x4ae16a9e2f1a7bee, duration=101218.592s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
> cookie=0x4ae16a9e2f1a7bee, duration=101218.590s, table=24, n_packets=0, n_bytes=0, priority=0 actions=drop
> cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=60, n_packets=402197, n_bytes=455450343, priority=3 actions=NORMAL
>  
> I cannot see any relevant flow entries and the port chain is not working.
>  
> Kind Regards,
> Navdeep
>  
> From: Sa Pham <saphi070 at gmail.com> 
> Sent: 04 April 2019 15:40
> To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> Cc: openstack at lists.openstack.org
> Subject: Re: SFC delete port chain failed
>  
> What is the version of Openstack and networking-sfc you are running?
>  
> On Thu, Apr 4, 2019 at 11:38 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> wrote:
> In addition to the following logs, I have attached the logs I captured while creating the port chain.
>  
> From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk> 
> Sent: 04 April 2019 12:06
> To: openstack at lists.openstack.org
> Subject: SFC delete port chain failed
>  
> Dear All,
>  
> I am facing errors while creating/deleting the SF Chain:
>  
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
> 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
> 2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
> 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
> 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.
>  
> Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.
>  
> Kind Regards,
> Navdeep
>  
> 
>  
> --
> Sa Pham Dang
> Master Student - Soongsil University
> Kakaotalk: sapd95
> Skype: great_bn
>  
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/6562eed2/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Thu Apr  4 16:04:32 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Thu, 4 Apr 2019 16:04:32 +0000
Subject: SFC delete port chain failed
In-Reply-To: <6B9E1736-43E3-4776-A6B1-B8661167F295@gmail.com>
References: <AM6PR06MB5879D2073CF268FD42D92B84DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <AM6PR06MB587907999039DD2C935FEC64DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAA1DRz=K+FjEY2R3+eDxoFDG=MrT5VR7eE34gkOrB3inT1Un_g@mail.gmail.com>
 <AM6PR06MB58795EDFC1CF8AEAF4007BABDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <6B9E1736-43E3-4776-A6B1-B8661167F295@gmail.com>
Message-ID: <AM6PR06MB5879955095A0E6403EA8DBC2DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Pham,

Thank you very much for your input. I reconfigured the sfc. Now I can see some relevant rules:
cookie=0x25de27143412205d, duration=469.415s, table=0, n_packets=0, n_bytes=0, priority=20,mpls actions=resubmit(,10)
cookie=0x25de27143412205d, duration=469.415s, table=0, n_packets=0, n_bytes=0, priority=20,dl_type=0x894f actions=resubmit(,10)
cookie=0xe2af088ad3bf3e57, duration=460.861s, table=0, n_packets=0, n_bytes=0, priority=10,icmp6,in_port="qvo6ed27e26-ef",icmp_type=136 actions=resubmit(,24)
cookie=0xe2af088ad3bf3e57, duration=460.860s, table=0, n_packets=393, n_bytes=16506, priority=10,arp,in_port="qvo6ed27e26-ef" actions=resubmit(,24)
cookie=0xe2af088ad3bf3e57, duration=469.852s, table=0, n_packets=0, n_bytes=0, priority=2,in_port="int-br-pr6e8b65" actions=drop
cookie=0xe2af088ad3bf3e57, duration=469.840s, table=0, n_packets=19, n_bytes=1634, priority=2,in_port="int-br-provider" actions=drop
cookie=0xe2af088ad3bf3e57, duration=460.862s, table=0, n_packets=3, n_bytes=363, priority=9,in_port="qvo6ed27e26-ef" actions=resubmit(,25)
cookie=0xe2af088ad3bf3e57, duration=468.184s, table=0, n_packets=274729, n_bytes=446095473, priority=3,in_port="int-br-provider",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:2,resubmit(,60)
cookie=0xe2af088ad3bf3e57, duration=468.162s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=1000 actions=mod_vlan_vid:9,resubmit(,60)
cookie=0xe2af088ad3bf3e57, duration=466.034s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=500 actions=mod_vlan_vid:10,resubmit(,60)
cookie=0xe2af088ad3bf3e57, duration=469.913s, table=0, n_packets=7156, n_bytes=411114, priority=0 actions=resubmit(,60)
cookie=0x25de27143412205d, duration=469.414s, table=10, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0xe2af088ad3bf3e57, duration=469.914s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0xe2af088ad3bf3e57, duration=460.861s, table=24, n_packets=0, n_bytes=0, priority=2,icmp6,in_port="qvo6ed27e26-ef",icmp_type=136,nd_target=fe80::f816:3eff:fe52:ae55 actions=resubmit(,60)
cookie=0xe2af088ad3bf3e57, duration=460.860s, table=24, n_packets=1, n_bytes=42, priority=2,arp,in_port="qvo6ed27e26-ef",arp_spa=192.168.40.54 actions=resubmit(,25)
cookie=0xe2af088ad3bf3e57, duration=469.912s, table=24, n_packets=1725, n_bytes=72450, priority=0 actions=drop
cookie=0xe2af088ad3bf3e57, duration=460.863s, table=25, n_packets=2, n_bytes=132, priority=2,in_port="qvo6ed27e26-ef",dl_src=fa:16:3e:52:ae:55 actions=resubmit(,60)
cookie=0xe2af088ad3bf3e57, duration=469.912s, table=60, n_packets=415070, n_bytes=456323487, priority=3 actions=NORMAL

But my port chain creation is failing:

2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager [req-28f411bd-9bd3-40cd-849b-2e0cbeac7976 b4bed449030e4826a8208f94055eda59 c64c5db060ed4a428688f6e14a4c4375 - default default] 'NoneT
ype' object has no attribute '__getitem__': TypeError: 'NoneType' object has no attribute '__getitem__'
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/base.py", line 58, in create_port_chain_postcommit
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     self.create_port_chain(context)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 875, in create_port_chain
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     path_nodes = self._create_portchain_path(context, port_chain, True)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 333, in _create_portchain_pat
h
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     fwd_path)
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 1622, in _validate_chain
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager     subnet2 = self._get_subnet_by_port(pd1['ingress'])
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager TypeError: 'NoneType' object has no attribute '__getitem__'
2019-04-04 16:58:39.521 3705 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 16:58:39.522 3705 ERROR networking_sfc.services.sfc.driver_manager [req-28f411bd-9bd3-40cd-849b-2e0cbeac7976 b4bed449030e4826a8208f94055eda59 c64c5db060ed4a428688f6e14a4c4375 - default default] SFC dr
iver 'ovs' failed in create_port_chain_postcommit
2019-04-04 16:58:39.522 3705 ERROR networking_sfc.services.sfc.plugin [req-28f411bd-9bd3-40cd-849b-2e0cbeac7976 b4bed449030e4826a8208f94055eda59 c64c5db060ed4a428688f6e14a4c4375 - default default] create_port_ch
ain_postcommit failed.: SfcDriverError: create_port_chain_postcommit failed.

Any ideas, how can I solve this.

Kind Regards,
Navdeep
From: Sa Pham <saphi070 at gmail.com>
Sent: 04 April 2019 16:39
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: openstack at lists.openstack.org
Subject: Re: SFC delete port chain failed

As your list of flows in br-int bridge. I don’t see any flow relevant sfc. So maybe your openvswitch-agent can not load sfc extension sucessful.
Please check log of ovs-first. If right, there is a message like “ loaded extensions [‘sfc’]”.
If the list extensions above is None. So the extension is not loaded.

Sa Pham Dang
Cloud RnD Team - VCCLOUD
Phone: 0986849582
Skype: great_bn

On Apr 5, 2019, at 12:28 AM, Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Hi Pham,

I am able to create the port chain now. However, I cannot see it running.
My scenario is simple with 3 VMs:  VM1---<net1>--VM2--<net2>--VM3 (Please note: it is not working with single network as well)

I followed the following steps:
openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p1vm1
openstack port create --no-security-group --disable-port-security --network sfcnet1 net1p2vm2
openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p1vm2
openstack port create --no-security-group --disable-port-security --network sfcnet2 net2p2vm3

openstack server create --nic port-id=net1p1vm1 --image cloudUb16 --flavor m1.large vm1
openstack server create --nic port-id=net1p2vm2 --nic port-id=net2p1vm2 --image cloudUb16 --flavor m1.large vm2
openstack server create --nic port-id=net2p2vm3 --image cloudUb16 --flavor m1.large vm3

openstack sfc port pair create --ingress net1p1vm1 --egress net1p1vm1 PoP1
openstack sfc port pair create --ingress net1p2vm2 --egress net2p1vm2 PoP2
openstack sfc port pair create --ingress net2p2vm3 --egress net2p2vm3 PoP3

openstack sfc port pair group create --port-pair PoP1 PPGp1
openstack sfc port pair group create --port-pair PoP2 PPGp2
openstack sfc port pair group create --port-pair PoP3 PPGp3

openstack sfc flow classifier create --protocol icmp --ethertype IPv4 --source-ip-prefix 10.10.10.6/32 --destination-ip-prefix 20.20.20.9/32 --logical-source-port net1p1vm1 --logical-destination-port net2p2vm3 FCx

openstack sfc port chain create --flow-classifier FCx --port-pair-group PPGp1 --port-pair-group PPGp2 --port-pair-group PPGp3 PChain

sudo ovs-ofctl dump-flows br-int
cookie=0x4ae16a9e2f1a7bee, duration=101217.953s, table=0, n_packets=268367, n_bytes=445608419, priority=3,in_port="int-br-provider",vlan_tci=0x0000/0x1fff actions=mod_vlan_vid:2,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=1415.837s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=1000 actions=mod_vlan_vid:9,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=1215.812s, table=0, n_packets=0, n_bytes=0, priority=3,in_port="int-br-pr6e8b65",dl_vlan=500 actions=mod_vlan_vid:10,resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=101218.540s, table=0, n_packets=0, n_bytes=0, priority=2,in_port="int-br-pr6e8b65" actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.531s, table=0, n_packets=19, n_bytes=1634, priority=2,in_port="int-br-provider" actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=0, n_packets=1532, n_bytes=106439, priority=0 actions=resubmit(,60)
cookie=0x4ae16a9e2f1a7bee, duration=101218.592s, table=23, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.590s, table=24, n_packets=0, n_bytes=0, priority=0 actions=drop
cookie=0x4ae16a9e2f1a7bee, duration=101218.591s, table=60, n_packets=402197, n_bytes=455450343, priority=3 actions=NORMAL

I cannot see any relevant flow entries and the port chain is not working.

Kind Regards,
Navdeep

From: Sa Pham <saphi070 at gmail.com<mailto:saphi070 at gmail.com>>
Sent: 04 April 2019 15:40
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>>
Cc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Subject: Re: SFC delete port chain failed

What is the version of Openstack and networking-sfc you are running?

On Thu, Apr 4, 2019 at 11:38 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
In addition to the following logs, I have attached the logs I captured while creating the port chain.

From: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>>
Sent: 04 April 2019 12:06
To: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Subject: SFC delete port chain failed

Dear All,

I am facing errors while creating/deleting the SF Chain:

2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last):
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     getattr(driver.obj, method_name)(context)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_portchain_path(context, port_chain)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     port_chain['flow_classifiers']
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     context, node, port, pc_corr, fc_ids)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._delete_agent_fdb_entries(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     pop_ports = self._get_remote_pop_ports(context, flow_rule)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     return method(*args, **kwargs)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     next_hop['net_uuid'])
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager   File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager     query = context.session.query(models_v2.Port)
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session'
2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager
2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last):
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin     method=method_name
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin
2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed.
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last):
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     result = method(request=request, **args)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return self._delete(request, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     setattr(e, '_RETRY_EXCEEDED', True)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     ectxt.value = e.inner_exc
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return f(*dup_args, **dup_kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     obj_deleter(request.context, id, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     return method(*args, **kwargs)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     portchain_id)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.force_reraise()
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     six.reraise(self.type_, self.value, self.tb)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self.driver_manager.delete_port_chain(pc_context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     self._call_drivers("delete_port_chain", context)
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource   File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource     method=method_name
2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed.

Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue.

Kind Regards,
Navdeep



--
Sa Pham Dang
Master Student - Soongsil University
Kakaotalk: sapd95
Skype: great_bn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/698e182c/attachment-0001.html>

From openstack at nemebean.com  Thu Apr  4 16:11:23 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Thu, 4 Apr 2019 11:11:23 -0500
Subject: [oslo] No meeting next week
Message-ID: <1d979e71-1c67-6d25-b2e8-9977079a0a01@nemebean.com>

I forgot to mention it in the meeting this week, but I'll be on PTO next 
week (the 8th to the 12th) so there won't be a meeting. Unless someone 
else wants to run it, of course. I'll be back the following week and 
we'll get back to our regular schedule for a couple of weeks and then it 
will be Summit/PTG.

I'm going to try to take a look at the oslo.service sighup patch before 
I leave, but if there's anything else pressing let me know ASAP.

Thanks.

-Ben


From sergey at vilgelm.info  Thu Apr  4 16:31:04 2019
From: sergey at vilgelm.info (Sergey Vilgelm)
Date: Thu, 4 Apr 2019 11:31:04 -0500
Subject: [qa][patrole] get_tenant_network found None
In-Reply-To: <169e9178e01.c22cd45080609.1668889994487390494@ghanshyammann.com>
References: <478c2524-be5b-45ea-989c-7c5d659bfc30@Spark>
 <83dcbb8b-40a2-4558-8a8d-e72ab188f08d@Spark>
 <169e8d0bc98.b5c1eb5d78051.7217687696537549233@ghanshyammann.com>
 <169e9178e01.c22cd45080609.1668889994487390494@ghanshyammann.com>
Message-ID: <bebd9905-053f-4bb6-b5b1-aa208c54082b@Spark>

Thanks

--
Sergey Vilgelm
https://www.vilgelm.info

On Apr 4, 2019, 11:03 AM -0500, Ghanshyam Mann <gmann at ghanshyammann.com>, wrote:
> ---- On Thu, 04 Apr 2019 09:46:27 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
> > ---- On Thu, 04 Apr 2019 08:57:06 -0500 Sergey Vilgelm <sergey at vilgelm.info> wrote ----
> > > Hello,
> > > There is an issue with get_tenant_network function in the Patrole tests. Zuul failed on patch set [0] due to 'Multiple possible networks found, use a Network ID to be more specific’[1]. Tempest logs[2] contain an message: '(ServerActionsRbacTest:setUpClass) Found network None available for tenant’.
> >
> > Ok, that is because of creating the shared network in devstack which merged recently. I will push the fix.
>
> This should fix the issue. patrole was not creating the network for used credential which is what Tempest use for
> creating the server.
>
> - https://review.openstack.org/#/c/650059/
>
> -gmann
>
> >
> > -gmann
> >
> > > Who knows why this can happen? I have an idea, that this could happen in case of a parallel test running and one test rewrote the roles and another test didn’t find a tenant's network at same time because of the wrong roles.
> > >
> > > [0] https://review.openstack.org/#/c/648255/ [1] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/testr_results.html.gz [2] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/controller/logs/tempest_log.txt.gz
> > >
> > > -- Sergey Vilgelm https://www.vilgelm.info
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/b11f9bcc/attachment.html>

From correajl at gmail.com  Thu Apr  4 16:43:37 2019
From: correajl at gmail.com (Jorge Luiz Correa)
Date: Thu, 4 Apr 2019 13:43:37 -0300
Subject: Help with kernel panic on cirros image boot process.
In-Reply-To: <mailman.295006.1554393834.1564.openstack-discuss@lists.openstack.org>
References: <mailman.295006.1554393834.1564.openstack-discuss@lists.openstack.org>
Message-ID: <CAE2bT_3iHQwLOM6jzG3i9+u-XNG5bnLz8EGMP_1LOa6nPDf-Sg@mail.gmail.com>

> We have the same issue in the upstream CI system with the cirros 0.3.5
> image:
>
> http://status.openstack.org/elastic-recheck/#1737039
>
> Have you tried using the 0.4.0 image?

Yes, I'm using cirros-0.4.0-x86_64-disk.img. Same problem with
randomly kernel panic on boot.

Thanks.


From sean.mcginnis at gmx.com  Thu Apr  4 17:04:11 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 4 Apr 2019 12:04:11 -0500
Subject: [release] Release countdown for week R-0, April 8-12
Message-ID: <20190404170411.GA12602@sm-workstation>

This is the final countdown email for the Stein development cycle. Thanks to
everyone involved in the Stein release!

Development Focus
-----------------

Teams attending the PTG should be preparing for those discussions and capturing
information in the etherpads:

    https://wiki.openstack.org/wiki/PTG/Train/Etherpads

General Information
-------------------

The release team plans on doing the final Stein release on 10 April. We will
re-tag the last commit used for the final RC using the final version number.

If you have not already done so, now would be a good time to take a look at the
Train schedule and start planning team activities:

    https://releases.openstack.org/train/schedule.html

Actions
---------

PTLs and release liaisons should watch for the final release patch from the
release team. While not required, we would appreciate having an ack from each
team before we approve it on the 10th.

Upcoming Deadlines & Dates
--------------------------

Final RC deadline: April 1
Final Stein release: April 10

--
Sean McGinnis (smcginnis)



From ekcs.openstack at gmail.com  Thu Apr  4 18:11:04 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 10:11:04 -0800
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
Message-ID: <D8CB8574.C3A2A%ekcs.openstack@gmail.com>

On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:

>On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
>> On 19-04-04 08:32:56, Alex Schultz wrote:
>> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
>>wrote:
>> > >
>> > > On 19-04-04 01:20:18, Eric K wrote:
>> > > > Requesting exception to remove a requirement to resolve a
>>packaging issue.
>> > > >
>> > > > The package is needed only for an experimental feature, but causes
>> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
>>requirements and
>> > > > require manual install to enable the experimental feature.
>> > > >
>> > > > https://review.openstack.org/#/c/649772/
>> > > >
>> > >
>> > > I imagine psycopg2 is one of many dependencies that are not fully
>> > > compliant with our upper-constraints (and probably a bunch of
>>projects
>> > > global-constraints).  Is it possible to lower the version required
>>(be
>> > > compatible with 2.6 or whatever is in centos)?  The requirements
>>project
>> > > itself sets no lower bound for psycopg2.
>> > >
>> > 
>> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
>> > optional it would be nice for it not to be included by default. We hit
>> > the issue in puppet-congress so we disabled out actual test jobs[0]
>> > because congress currently doesn't work on ubuntu[1] and was broken on
>> > centos[2] by this new requirement.
>> > 
>> > [0] https://review.openstack.org/#/c/649439/
>> > [1] 
>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubunt
>>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
>> > [2] 
>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-cento
>>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
>> > 
>> 
>> extra_requires may work for you (makes postgres support optional)
>> 
>>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-ext
>>ras-optional-features-with-their-own-dependencies
>> 
>> not sur eif pbr supports it though.
>
>PBR should support it. Here is an example from swiftclient installing
>keystoneclient as an extra [3].
>
>[3] 
>https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup.cfg
>#n36
>
Thank you all!


Unfortunately the code relies on the psycopg2.sql module for query
composition, which is only available on 2.7 and up. I'm also working on a
future patch to remove the use of the psycopg2.sql module and also lower
the psycopg2 version required, but I'm thinking considering the stein
deadline a straightforward removal of psycopg2 can make sense.

I have fixed the unit test failure I overlooked and everything should be
passing now [4]

And thank you for the extra_requires suggestion. It would probably take me
a little while and a few tries to get it right. Again considering the
deadline I'd rather just go with the current patch [4] if it's acceptable.
Since the feature that requires psycopg2 is experimental I think requiring
manual install of psycopg2 is ok.

Alternatively, if it seems better to delay Congress final RC or wait to
fix this issue in X.0.1 we can do that too.

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




From mthode at mthode.org  Thu Apr  4 17:17:34 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 12:17:34 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
 <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
Message-ID: <20190404171734.c3u6zbzhinze4w4b@mthode.org>

On 19-04-04 10:11:04, Eric K wrote:
> On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:
> 
> >On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
> >> On 19-04-04 08:32:56, Alex Schultz wrote:
> >> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
> >>wrote:
> >> > >
> >> > > On 19-04-04 01:20:18, Eric K wrote:
> >> > > > Requesting exception to remove a requirement to resolve a
> >>packaging issue.
> >> > > >
> >> > > > The package is needed only for an experimental feature, but causes
> >> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
> >>requirements and
> >> > > > require manual install to enable the experimental feature.
> >> > > >
> >> > > > https://review.openstack.org/#/c/649772/
> >> > > >
> >> > >
> >> > > I imagine psycopg2 is one of many dependencies that are not fully
> >> > > compliant with our upper-constraints (and probably a bunch of
> >>projects
> >> > > global-constraints).  Is it possible to lower the version required
> >>(be
> >> > > compatible with 2.6 or whatever is in centos)?  The requirements
> >>project
> >> > > itself sets no lower bound for psycopg2.
> >> > >
> >> > 
> >> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
> >> > optional it would be nice for it not to be included by default. We hit
> >> > the issue in puppet-congress so we disabled out actual test jobs[0]
> >> > because congress currently doesn't work on ubuntu[1] and was broken on
> >> > centos[2] by this new requirement.
> >> > 
> >> > [0] https://review.openstack.org/#/c/649439/
> >> > [1] 
> >>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubunt
> >>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
> >> > [2] 
> >>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-cento
> >>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
> >> > 
> >> 
> >> extra_requires may work for you (makes postgres support optional)
> >> 
> >>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-ext
> >>ras-optional-features-with-their-own-dependencies
> >> 
> >> not sur eif pbr supports it though.
> >
> >PBR should support it. Here is an example from swiftclient installing
> >keystoneclient as an extra [3].
> >
> >[3] 
> >https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup.cfg
> >#n36
> >
> Thank you all!
> 
> 
> Unfortunately the code relies on the psycopg2.sql module for query
> composition, which is only available on 2.7 and up. I'm also working on a
> future patch to remove the use of the psycopg2.sql module and also lower
> the psycopg2 version required, but I'm thinking considering the stein
> deadline a straightforward removal of psycopg2 can make sense.
> 
> I have fixed the unit test failure I overlooked and everything should be
> passing now [4]
> 
> And thank you for the extra_requires suggestion. It would probably take me
> a little while and a few tries to get it right. Again considering the
> deadline I'd rather just go with the current patch [4] if it's acceptable.
> Since the feature that requires psycopg2 is experimental I think requiring
> manual install of psycopg2 is ok.
> 
> Alternatively, if it seems better to delay Congress final RC or wait to
> fix this issue in X.0.1 we can do that too.
> 
> [4] https://review.openstack.org/#/c/649772/
> 

The problem is that you are still requiring postgres support via some
code path, so that means that it's required, either statically or via
extra requires.  I don't think removing it is an appropriate solution.

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/d38ffed8/attachment-0001.sig>

From ekcs.openstack at gmail.com  Thu Apr  4 18:30:45 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 10:30:45 -0800
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <20190404171734.c3u6zbzhinze4w4b@mthode.org>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
 <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
 <20190404171734.c3u6zbzhinze4w4b@mthode.org>
Message-ID: <D8CB8C61.C3A5B%ekcs.openstack@gmail.com>



On 4/4/19, 9:17 AM, "Matthew Thode" <mthode at mthode.org> wrote:

>On 19-04-04 10:11:04, Eric K wrote:
>> On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:
>> 
>> >On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
>> >> On 19-04-04 08:32:56, Alex Schultz wrote:
>> >> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
>> >>wrote:
>> >> > >
>> >> > > On 19-04-04 01:20:18, Eric K wrote:
>> >> > > > Requesting exception to remove a requirement to resolve a
>> >>packaging issue.
>> >> > > >
>> >> > > > The package is needed only for an experimental feature, but
>>causes
>> >> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
>> >>requirements and
>> >> > > > require manual install to enable the experimental feature.
>> >> > > >
>> >> > > > https://review.openstack.org/#/c/649772/
>> >> > > >
>> >> > >
>> >> > > I imagine psycopg2 is one of many dependencies that are not fully
>> >> > > compliant with our upper-constraints (and probably a bunch of
>> >>projects
>> >> > > global-constraints).  Is it possible to lower the version
>>required
>> >>(be
>> >> > > compatible with 2.6 or whatever is in centos)?  The requirements
>> >>project
>> >> > > itself sets no lower bound for psycopg2.
>> >> > >
>> >> > 
>> >> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
>> >> > optional it would be nice for it not to be included by default. We
>>hit
>> >> > the issue in puppet-congress so we disabled out actual test jobs[0]
>> >> > because congress currently doesn't work on ubuntu[1] and was
>>broken on
>> >> > centos[2] by this new requirement.
>> >> > 
>> >> > [0] https://review.openstack.org/#/c/649439/
>> >> > [1] 
>> 
>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubu
>>>>nt
>> >>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
>> >> > [2] 
>> 
>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-cen
>>>>to
>> >>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
>> >> > 
>> >> 
>> >> extra_requires may work for you (makes postgres support optional)
>> >> 
>> 
>>>>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-e
>>>>xt
>> >>ras-optional-features-with-their-own-dependencies
>> >> 
>> >> not sur eif pbr supports it though.
>> >
>> >PBR should support it. Here is an example from swiftclient installing
>> >keystoneclient as an extra [3].
>> >
>> >[3] 
>> 
>>>https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup.c
>>>fg
>> >#n36
>> >
>> Thank you all!
>> 
>> 
>> Unfortunately the code relies on the psycopg2.sql module for query
>> composition, which is only available on 2.7 and up. I'm also working on
>>a
>> future patch to remove the use of the psycopg2.sql module and also lower
>> the psycopg2 version required, but I'm thinking considering the stein
>> deadline a straightforward removal of psycopg2 can make sense.
>> 
>> I have fixed the unit test failure I overlooked and everything should be
>> passing now [4]
>> 
>> And thank you for the extra_requires suggestion. It would probably take
>>me
>> a little while and a few tries to get it right. Again considering the
>> deadline I'd rather just go with the current patch [4] if it's
>>acceptable.
>> Since the feature that requires psycopg2 is experimental I think
>>requiring
>> manual install of psycopg2 is ok.
>> 
>> Alternatively, if it seems better to delay Congress final RC or wait to
>> fix this issue in X.0.1 we can do that too.
>> 
>> [4] https://review.openstack.org/#/c/649772/
>> 
>
>The problem is that you are still requiring postgres support via some
>code path, so that means that it's required, either statically or via
>extra requires.  I don't think removing it is an appropriate solution.
>
>-- 
>Matthew Thode
I see. psycopg2 is required only if the experimental feature (json
ingester) is explicitly enabled via feature flag in conf file. Otherwise
there is no import.

But if that's not okay, I'll do an alternative approach.




From mthode at mthode.org  Thu Apr  4 17:37:56 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 12:37:56 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <D8CB8C61.C3A5B%ekcs.openstack@gmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
 <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
 <20190404171734.c3u6zbzhinze4w4b@mthode.org>
 <D8CB8C61.C3A5B%ekcs.openstack@gmail.com>
Message-ID: <20190404173756.ahr5d3olfgwkfmnj@mthode.org>

On 19-04-04 10:30:45, Eric K wrote:
> 
> 
> On 4/4/19, 9:17 AM, "Matthew Thode" <mthode at mthode.org> wrote:
> 
> >On 19-04-04 10:11:04, Eric K wrote:
> >> On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:
> >> 
> >> >On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
> >> >> On 19-04-04 08:32:56, Alex Schultz wrote:
> >> >> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
> >> >>wrote:
> >> >> > >
> >> >> > > On 19-04-04 01:20:18, Eric K wrote:
> >> >> > > > Requesting exception to remove a requirement to resolve a
> >> >>packaging issue.
> >> >> > > >
> >> >> > > > The package is needed only for an experimental feature, but
> >>causes
> >> >> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
> >> >>requirements and
> >> >> > > > require manual install to enable the experimental feature.
> >> >> > > >
> >> >> > > > https://review.openstack.org/#/c/649772/
> >> >> > > >
> >> >> > >
> >> >> > > I imagine psycopg2 is one of many dependencies that are not fully
> >> >> > > compliant with our upper-constraints (and probably a bunch of
> >> >>projects
> >> >> > > global-constraints).  Is it possible to lower the version
> >>required
> >> >>(be
> >> >> > > compatible with 2.6 or whatever is in centos)?  The requirements
> >> >>project
> >> >> > > itself sets no lower bound for psycopg2.
> >> >> > >
> >> >> > 
> >> >> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if it's
> >> >> > optional it would be nice for it not to be included by default. We
> >>hit
> >> >> > the issue in puppet-congress so we disabled out actual test jobs[0]
> >> >> > because congress currently doesn't work on ubuntu[1] and was
> >>broken on
> >> >> > centos[2] by this new requirement.
> >> >> > 
> >> >> > [0] https://review.openstack.org/#/c/649439/
> >> >> > [1] 
> >> 
> >>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-ubu
> >>>>nt
> >> >>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
> >> >> > [2] 
> >> 
> >>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-cen
> >>>>to
> >> >>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
> >> >> > 
> >> >> 
> >> >> extra_requires may work for you (makes postgres support optional)
> >> >> 
> >> 
> >>>>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-e
> >>>>xt
> >> >>ras-optional-features-with-their-own-dependencies
> >> >> 
> >> >> not sur eif pbr supports it though.
> >> >
> >> >PBR should support it. Here is an example from swiftclient installing
> >> >keystoneclient as an extra [3].
> >> >
> >> >[3] 
> >> 
> >>>https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup.c
> >>>fg
> >> >#n36
> >> >
> >> Thank you all!
> >> 
> >> 
> >> Unfortunately the code relies on the psycopg2.sql module for query
> >> composition, which is only available on 2.7 and up. I'm also working on
> >>a
> >> future patch to remove the use of the psycopg2.sql module and also lower
> >> the psycopg2 version required, but I'm thinking considering the stein
> >> deadline a straightforward removal of psycopg2 can make sense.
> >> 
> >> I have fixed the unit test failure I overlooked and everything should be
> >> passing now [4]
> >> 
> >> And thank you for the extra_requires suggestion. It would probably take
> >>me
> >> a little while and a few tries to get it right. Again considering the
> >> deadline I'd rather just go with the current patch [4] if it's
> >>acceptable.
> >> Since the feature that requires psycopg2 is experimental I think
> >>requiring
> >> manual install of psycopg2 is ok.
> >> 
> >> Alternatively, if it seems better to delay Congress final RC or wait to
> >> fix this issue in X.0.1 we can do that too.
> >> 
> >> [4] https://review.openstack.org/#/c/649772/
> >> 
> >
> >The problem is that you are still requiring postgres support via some
> >code path, so that means that it's required, either statically or via
> >extra requires.  I don't think removing it is an appropriate solution.
> >
> >-- 
> >Matthew Thode
> I see. psycopg2 is required only if the experimental feature (json
> ingester) is explicitly enabled via feature flag in conf file. Otherwise
> there is no import.
> 
> But if that's not okay, I'll do an alternative approach.
> 

What happens when someone enables that experimental feature without
having psycopg2 installed because it was not required / in the
requirements file?

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/89d7cc43/attachment.sig>

From no-reply at openstack.org  Thu Apr  4 18:47:05 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 18:47:05 -0000
Subject: horizon 15.0.0.0rc2 (stein)
Message-ID: <mailman.510.1554403626.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for horizon for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/horizon/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/horizon/log/?h=stable/stein

Release notes for horizon can be found at:

    https://docs.openstack.org/releasenotes/horizon/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/horizon/+bugs

and tag it *stein-rc-potential* to bring it to the horizon
release crew's attention.



From no-reply at openstack.org  Thu Apr  4 18:53:26 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 18:53:26 -0000
Subject: magnum 8.0.0.0rc2 (stein)
Message-ID: <mailman.511.1554404018.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for magnum for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/magnum/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/magnum/log/?h=stable/stein

Release notes for magnum can be found at:

    https://docs.openstack.org/releasenotes/magnum/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/magnum/+bugs

and tag it *stein-rc-potential* to bring it to the magnum
release crew's attention.



From mriedemos at gmail.com  Thu Apr  4 18:55:54 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 4 Apr 2019 13:55:54 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
Message-ID: <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>

On 4/4/2019 5:28 AM, Lingxian Kong wrote:
> 
> I'm current Trove PTL, could you please add myself to trove-stable-maint 
> so that I could merge those patches[1][2][3] for stable/stein?
> 
> [1] https://review.openstack.org/#/c/645647/
> [2] https://review.openstack.org/#/c/645646/
> [3] https://review.openstack.org/#/c/645648/

I've approved the first two, the last one is on master.

-- 

Thanks,

Matt


From no-reply at openstack.org  Thu Apr  4 18:56:19 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 18:56:19 -0000
Subject: murano 7.0.0.0rc2 (stein)
Message-ID: <mailman.512.1554404206.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for murano for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/murano/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/murano/log/?h=stable/stein

Release notes for murano can be found at:

    https://docs.openstack.org/releasenotes/murano/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/murano/+bugs

and tag it *stein-rc-potential* to bring it to the murano
release crew's attention.



From no-reply at openstack.org  Thu Apr  4 18:58:59 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 18:58:59 -0000
Subject: mistral-extra 8.0.0.0rc2 (stein)
Message-ID: <mailman.513.1554404340.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for mistral-extra for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/mistral-extra/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/mistral-extra/log/?h=stable/stein

Release notes for mistral-extra can be found at:

    https://docs.openstack.org/releasenotes/mistral-extra/





From no-reply at openstack.org  Thu Apr  4 18:59:50 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 18:59:50 -0000
Subject: mistral 8.0.0.0rc2 (stein)
Message-ID: <mailman.514.1554404449.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for mistral for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/mistral/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/mistral/log/?h=stable/stein

Release notes for mistral can be found at:

    https://docs.openstack.org/releasenotes/mistral/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/mistral/+bugs

and tag it *stein-rc-potential* to bring it to the mistral
release crew's attention.



From ekcs.openstack at gmail.com  Thu Apr  4 20:02:03 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 12:02:03 -0800
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <20190404173756.ahr5d3olfgwkfmnj@mthode.org>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
 <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
 <20190404171734.c3u6zbzhinze4w4b@mthode.org>
 <D8CB8C61.C3A5B%ekcs.openstack@gmail.com>
 <20190404173756.ahr5d3olfgwkfmnj@mthode.org>
Message-ID: <D8CBA1A2.C3A7C%ekcs.openstack@gmail.com>



On 4/4/19, 9:37 AM, "Matthew Thode" <mthode at mthode.org> wrote:

>On 19-04-04 10:30:45, Eric K wrote:
>> 
>> 
>> On 4/4/19, 9:17 AM, "Matthew Thode" <mthode at mthode.org> wrote:
>> 
>> >On 19-04-04 10:11:04, Eric K wrote:
>> >> On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:
>> >> 
>> >> >On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
>> >> >> On 19-04-04 08:32:56, Alex Schultz wrote:
>> >> >> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
>> >> >>wrote:
>> >> >> > >
>> >> >> > > On 19-04-04 01:20:18, Eric K wrote:
>> >> >> > > > Requesting exception to remove a requirement to resolve a
>> >> >>packaging issue.
>> >> >> > > >
>> >> >> > > > The package is needed only for an experimental feature, but
>> >>causes
>> >> >> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
>> >> >>requirements and
>> >> >> > > > require manual install to enable the experimental feature.
>> >> >> > > >
>> >> >> > > > https://review.openstack.org/#/c/649772/
>> >> >> > > >
>> >> >> > >
>> >> >> > > I imagine psycopg2 is one of many dependencies that are not
>>fully
>> >> >> > > compliant with our upper-constraints (and probably a bunch of
>> >> >>projects
>> >> >> > > global-constraints).  Is it possible to lower the version
>> >>required
>> >> >>(be
>> >> >> > > compatible with 2.6 or whatever is in centos)?  The
>>requirements
>> >> >>project
>> >> >> > > itself sets no lower bound for psycopg2.
>> >> >> > >
>> >> >> > 
>> >> >> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if
>>it's
>> >> >> > optional it would be nice for it not to be included by default.
>>We
>> >>hit
>> >> >> > the issue in puppet-congress so we disabled out actual test
>>jobs[0]
>> >> >> > because congress currently doesn't work on ubuntu[1] and was
>> >>broken on
>> >> >> > centos[2] by this new requirement.
>> >> >> > 
>> >> >> > [0] https://review.openstack.org/#/c/649439/
>> >> >> > [1] 
>> >> 
>> 
>>>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-u
>>>>>>bu
>> >>>>nt
>> >> >>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
>> >> >> > [2] 
>> >> 
>> 
>>>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-c
>>>>>>en
>> >>>>to
>> >> >>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
>> >> >> > 
>> >> >> 
>> >> >> extra_requires may work for you (makes postgres support optional)
>> >> >> 
>> >> 
>> 
>>>>>>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring
>>>>>>-e
>> >>>>xt
>> >> >>ras-optional-features-with-their-own-dependencies
>> >> >> 
>> >> >> not sur eif pbr supports it though.
>> >> >
>> >> >PBR should support it. Here is an example from swiftclient
>>installing
>> >> >keystoneclient as an extra [3].
>> >> >
>> >> >[3] 
>> >> 
>> 
>>>>>https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup
>>>>>.c
>> >>>fg
>> >> >#n36
>> >> >
>> >> Thank you all!
>> >> 
>> >> 
>> >> Unfortunately the code relies on the psycopg2.sql module for query
>> >> composition, which is only available on 2.7 and up. I'm also working
>>on
>> >>a
>> >> future patch to remove the use of the psycopg2.sql module and also
>>lower
>> >> the psycopg2 version required, but I'm thinking considering the stein
>> >> deadline a straightforward removal of psycopg2 can make sense.
>> >> 
>> >> I have fixed the unit test failure I overlooked and everything
>>should be
>> >> passing now [4]
>> >> 
>> >> And thank you for the extra_requires suggestion. It would probably
>>take
>> >>me
>> >> a little while and a few tries to get it right. Again considering the
>> >> deadline I'd rather just go with the current patch [4] if it's
>> >>acceptable.
>> >> Since the feature that requires psycopg2 is experimental I think
>> >>requiring
>> >> manual install of psycopg2 is ok.
>> >> 
>> >> Alternatively, if it seems better to delay Congress final RC or wait
>>to
>> >> fix this issue in X.0.1 we can do that too.
>> >> 
>> >> [4] https://review.openstack.org/#/c/649772/
>> >> 
>> >
>> >The problem is that you are still requiring postgres support via some
>> >code path, so that means that it's required, either statically or via
>> >extra requires.  I don't think removing it is an appropriate solution.
>> >
>> >-- 
>> >Matthew Thode
>> I see. psycopg2 is required only if the experimental feature (json
>> ingester) is explicitly enabled via feature flag in conf file. Otherwise
>> there is no import.
>> 
>> But if that's not okay, I'll do an alternative approach.
>> 
>
>What happens when someone enables that experimental feature without
>having psycopg2 installed because it was not required / in the
>requirements file?
>
>-- 
>Matthew Thode

I assume that was rhetorical =)
Clearly in that case the experimental feature would not work (import
errors in log).

I also submitted an alternative patch [5] which lowers the requirement to
psycopg2>=2.5.1 but does not remove it completely.

[5] https://review.openstack.org/#/c/650100/




From no-reply at openstack.org  Thu Apr  4 19:02:33 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 19:02:33 -0000
Subject: mistral-dashboard 8.0.0.0rc2 (stein)
Message-ID: <mailman.515.1554404554.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for mistral-dashboard for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/mistral-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/mistral-dashboard/log/?h=stable/stein

Release notes for mistral-dashboard can be found at:

    https://docs.openstack.org/releasenotes/mistral-dashboard/





From no-reply at openstack.org  Thu Apr  4 19:13:30 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Thu, 04 Apr 2019 19:13:30 -0000
Subject: openstack-heat 12.0.0.0rc2 (stein)
Message-ID: <mailman.517.1554405211.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for openstack-heat for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/heat/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/heat/log/?h=stable/stein

Release notes for openstack-heat can be found at:

    https://docs.openstack.org/releasenotes/heat/

If you find an issue that could be considered release-critical, please
file it at:

    https://storyboard.openstack.org/#!/project/989

and tag it *stein-rc-potential* to bring it to the openstack-heat
release crew's attention.



From fungi at yuggoth.org  Thu Apr  4 20:08:05 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 4 Apr 2019 20:08:05 +0000
Subject: [all][tc] Feedback on Kata Containers and Zuul pilot projects
In-Reply-To: <20190326160701.th6kyrt5vvthty66@yuggoth.org>
References: <20190318184233.do4a7nydrflb5bmy@yuggoth.org>
 <20190326160701.th6kyrt5vvthty66@yuggoth.org>
Message-ID: <20190404200805.dmvemtzihyxfsh6i@yuggoth.org>

Thanks again to all those who provided feedback. Mohammed has passed
our summaries along to the board here:

http://lists.openstack.org/pipermail/foundation/2019-April/002747.html
http://lists.openstack.org/pipermail/foundation/2019-April/002748.html

-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/1db221b8/attachment.sig>

From gmann at ghanshyammann.com  Thu Apr  4 20:14:16 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 04 Apr 2019 15:14:16 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>
Message-ID: <169e9fcdb1a.e15f559b88571.1212271737893105500@ghanshyammann.com>

 ---- On Thu, 04 Apr 2019 13:55:54 -0500 Matt Riedemann <mriedemos at gmail.com> wrote ----
 > On 4/4/2019 5:28 AM, Lingxian Kong wrote: 
 > >  
 > > I'm current Trove PTL, could you please add myself to trove-stable-maint  
 > > so that I could merge those patches[1][2][3] for stable/stein? 
 > >  
 > > [1] https://review.openstack.org/#/c/645647/ 
 > > [2] https://review.openstack.org/#/c/645646/ 
 > > [3] https://review.openstack.org/#/c/645648/ 
 >  
 > I've approved the first two, the last one is on master. 

Thanks, matt, there are more stable patches stuck on trove side [1]
and lxkong current PTL does not have +2 authority. Can we add him as
trove-stable-maint maintainer?

[1]
https://review.openstack.org/#/c/649744/
https://review.openstack.org/#/c/649745/
https://review.openstack.org/#/c/648884/

-gmann

 >  
 > --  
 >  
 > Thanks, 
 >  
 > Matt 
 >  
 > 



From sean.mcginnis at gmx.com  Thu Apr  4 20:15:57 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 4 Apr 2019 15:15:57 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended Maintenance
 phase
Message-ID: <20190404201557.GA6952@sm-workstation>

Hey everyone,

Thought I should get this out there to make sure folks are aware.

We are actually overdue for Pike to have entered extended maintenance.
According to the stable policy, that should happen 18 months after the release
[0]. That means we should have made the switch in February, if my math is
right.

We will need to work through the details to actually put that in effect, but
for now I wanted to remind teams that we do not do releases after a stable
branch enters this phase. So this is a call for action for any teams that have
been backporting fixes that time is short to get a final release out while you
can.

The release dates for each cycle can be found on the releases site [1].

Thanks!
Sean

[0] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[1] https://releases.openstack.org/


From anlin.kong at gmail.com  Thu Apr  4 20:19:17 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Fri, 5 Apr 2019 09:19:17 +1300
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>
Message-ID: <CALjNAZ1Fb+pFFNf5hC4+SRa+1eqUT+dWhX-iwPZJwYZ_LFRbyQ@mail.gmail.com>

Thanks Matt, and two more please, they are aiming at fixing the CI issue
for job migration to Ubuntu Bionic. After merged, I will rebase this one
https://review.openstack.org/#/c/648884/ from Ghanshyam

https://review.openstack.org/#/c/649744/
<https://review.openstack.org/#/c/649745/>
https://review.openstack.org/#/c/649745/

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Fri, Apr 5, 2019 at 7:59 AM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/4/2019 5:28 AM, Lingxian Kong wrote:
> >
> > I'm current Trove PTL, could you please add myself to trove-stable-maint
> > so that I could merge those patches[1][2][3] for stable/stein?
> >
> > [1] https://review.openstack.org/#/c/645647/
> > [2] https://review.openstack.org/#/c/645646/
> > [3] https://review.openstack.org/#/c/645648/
>
> I've approved the first two, the last one is on master.
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/71915c2e/attachment-0001.html>

From openstack at fried.cc  Thu Apr  4 20:39:47 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 4 Apr 2019 15:39:47 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
Message-ID: <a61cd229-59e2-b1c1-4cb7-f20727c83e6d@fried.cc>

Nova-

Having had positive responses on this thread and in today's nova meeting
[1], we're going to move forward with this.

I've started an etherpad [2] outlining the process, which boils down to:

Authors: If you want - and are ready for - feedback on your spec, add it
to the list.
Reviewers: Review specs from the list.
Authors & Reviewers: Be available/responsive on IRC and/or gerrit.

Please let me know if you have any questions or concerns.

See you Tuesday!

-efried

[1]
http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-04-04-14.00.log.html#l-82
[2] https://etherpad.openstack.org/p/nova-spec-review-day


From mnaser at vexxhost.com  Thu Apr  4 21:08:27 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 4 Apr 2019 17:08:27 -0400
Subject: [TC] PTG Lunch Talks
In-Reply-To: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
Message-ID: <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>

Dear TC members,

I'd like to push this up your inboxes.  It would be good for us to at
least give a yes (I'm inclined to say yes) and come up with important
things for the community to know, perhaps similar to Denver.

Thanks,
Mohammed

On Thu, Mar 28, 2019 at 8:19 PM Kendall Nelson <kennelson11 at gmail.com> wrote:
>
> Hello!
>
> I think you all have already started to discuss this, but if you haven't, here's the lowdown: You can have 15 min or 30 min on Thursday (we will also have lightning talks from the othe projects attending the PTG after you complete your time) and basically however much time you want on Saturday during lunch (keeping in mind that a lot of people are planning to leave Friday night). Friday is going to be the feedback session so there's not time available lunch that day.
>
> tldr; Do you want 15min or 30 min on Thursday? :)
>
>
> -Kendall Nelson
>
>
>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From ekcs.openstack at gmail.com  Thu Apr  4 22:30:51 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 14:30:51 -0800
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
Message-ID: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>

Requesting exception to lower a requirement to resolve a packaging issue.

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




From mthode at mthode.org  Thu Apr  4 21:47:34 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 16:47:34 -0500
Subject: [requirements][FFE][congress] remove psycopg2>=2.7
In-Reply-To: <D8CBA1A2.C3A7C%ekcs.openstack@gmail.com>
References: <D8CB0C52.C39D0%ekcs.openstack@gmail.com>
 <20190404135410.ph2o55jej57binmx@mthode.org>
 <CAFsb3b6LdcrbBbCWQ1hdS9bmiwM9iqiwaWsd94qrHY+L93VpuA@mail.gmail.com>
 <20190404145016.uh6bsofqcftccjlp@mthode.org>
 <41108edb-9a6e-44f6-a784-02a96c133e29@www.fastmail.com>
 <D8CB8574.C3A2A%ekcs.openstack@gmail.com>
 <20190404171734.c3u6zbzhinze4w4b@mthode.org>
 <D8CB8C61.C3A5B%ekcs.openstack@gmail.com>
 <20190404173756.ahr5d3olfgwkfmnj@mthode.org>
 <D8CBA1A2.C3A7C%ekcs.openstack@gmail.com>
Message-ID: <20190404214734.6eprmtuiz6yppk54@mthode.org>

On 19-04-04 12:02:03, Eric K wrote:
> 
> 
> On 4/4/19, 9:37 AM, "Matthew Thode" <mthode at mthode.org> wrote:
> 
> >On 19-04-04 10:30:45, Eric K wrote:
> >> 
> >> 
> >> On 4/4/19, 9:17 AM, "Matthew Thode" <mthode at mthode.org> wrote:
> >> 
> >> >On 19-04-04 10:11:04, Eric K wrote:
> >> >> On 4/4/19, 7:22 AM, "Clark Boylan" <cboylan at sapwetik.org> wrote:
> >> >> 
> >> >> >On Thu, Apr 4, 2019, at 7:50 AM, Matthew Thode wrote:
> >> >> >> On 19-04-04 08:32:56, Alex Schultz wrote:
> >> >> >> > On Thu, Apr 4, 2019 at 7:58 AM Matthew Thode <mthode at mthode.org>
> >> >> >>wrote:
> >> >> >> > >
> >> >> >> > > On 19-04-04 01:20:18, Eric K wrote:
> >> >> >> > > > Requesting exception to remove a requirement to resolve a
> >> >> >>packaging issue.
> >> >> >> > > >
> >> >> >> > > > The package is needed only for an experimental feature, but
> >> >>causes
> >> >> >> > > > packaging issue on RHEL/CentOS 7. Propose to remove from
> >> >> >>requirements and
> >> >> >> > > > require manual install to enable the experimental feature.
> >> >> >> > > >
> >> >> >> > > > https://review.openstack.org/#/c/649772/
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > > I imagine psycopg2 is one of many dependencies that are not
> >>fully
> >> >> >> > > compliant with our upper-constraints (and probably a bunch of
> >> >> >>projects
> >> >> >> > > global-constraints).  Is it possible to lower the version
> >> >>required
> >> >> >>(be
> >> >> >> > > compatible with 2.6 or whatever is in centos)?  The
> >>requirements
> >> >> >>project
> >> >> >> > > itself sets no lower bound for psycopg2.
> >> >> >> > >
> >> >> >> > 
> >> >> >> > Centos7 has 2.5. I had asked about getting 2.7 in RDO but if
> >>it's
> >> >> >> > optional it would be nice for it not to be included by default.
> >>We
> >> >>hit
> >> >> >> > the issue in puppet-congress so we disabled out actual test
> >>jobs[0]
> >> >> >> > because congress currently doesn't work on ubuntu[1] and was
> >> >>broken on
> >> >> >> > centos[2] by this new requirement.
> >> >> >> > 
> >> >> >> > [0] https://review.openstack.org/#/c/649439/
> >> >> >> > [1] 
> >> >> 
> >> 
> >>>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-u
> >>>>>>bu
> >> >>>>nt
> >> >> >>u-bionic/2cfe5a4/job-output.txt.gz#_2019-04-02_10_48_17_614150
> >> >> >> > [2] 
> >> >> 
> >> 
> >>>>>>http://logs.openstack.org/33/647333/1/check/puppet-openstack-beaker-c
> >>>>>>en
> >> >>>>to
> >> >> >>s-7/c10fb99/logs/syslog.txt.gz#_Apr_02_10_47_47
> >> >> >> > 
> >> >> >> 
> >> >> >> extra_requires may work for you (makes postgres support optional)
> >> >> >> 
> >> >> 
> >> 
> >>>>>>https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring
> >>>>>>-e
> >> >>>>xt
> >> >> >>ras-optional-features-with-their-own-dependencies
> >> >> >> 
> >> >> >> not sur eif pbr supports it though.
> >> >> >
> >> >> >PBR should support it. Here is an example from swiftclient
> >>installing
> >> >> >keystoneclient as an extra [3].
> >> >> >
> >> >> >[3] 
> >> >> 
> >> 
> >>>>>https://git.openstack.org/cgit/openstack/python-swiftclient/tree/setup
> >>>>>.c
> >> >>>fg
> >> >> >#n36
> >> >> >
> >> >> Thank you all!
> >> >> 
> >> >> 
> >> >> Unfortunately the code relies on the psycopg2.sql module for query
> >> >> composition, which is only available on 2.7 and up. I'm also working
> >>on
> >> >>a
> >> >> future patch to remove the use of the psycopg2.sql module and also
> >>lower
> >> >> the psycopg2 version required, but I'm thinking considering the stein
> >> >> deadline a straightforward removal of psycopg2 can make sense.
> >> >> 
> >> >> I have fixed the unit test failure I overlooked and everything
> >>should be
> >> >> passing now [4]
> >> >> 
> >> >> And thank you for the extra_requires suggestion. It would probably
> >>take
> >> >>me
> >> >> a little while and a few tries to get it right. Again considering the
> >> >> deadline I'd rather just go with the current patch [4] if it's
> >> >>acceptable.
> >> >> Since the feature that requires psycopg2 is experimental I think
> >> >>requiring
> >> >> manual install of psycopg2 is ok.
> >> >> 
> >> >> Alternatively, if it seems better to delay Congress final RC or wait
> >>to
> >> >> fix this issue in X.0.1 we can do that too.
> >> >> 
> >> >> [4] https://review.openstack.org/#/c/649772/
> >> >> 
> >> >
> >> >The problem is that you are still requiring postgres support via some
> >> >code path, so that means that it's required, either statically or via
> >> >extra requires.  I don't think removing it is an appropriate solution.
> >> >
> >> >-- 
> >> >Matthew Thode
> >> I see. psycopg2 is required only if the experimental feature (json
> >> ingester) is explicitly enabled via feature flag in conf file. Otherwise
> >> there is no import.
> >> 
> >> But if that's not okay, I'll do an alternative approach.
> >> 
> >
> >What happens when someone enables that experimental feature without
> >having psycopg2 installed because it was not required / in the
> >requirements file?
> >
> >-- 
> >Matthew Thode
> 
> I assume that was rhetorical =)
> Clearly in that case the experimental feature would not work (import
> errors in log).
> 
> I also submitted an alternative patch [5] which lowers the requirement to
> psycopg2>=2.5.1 but does not remove it completely.
> 
> [5] https://review.openstack.org/#/c/650100/
> 

that one looks much better :D

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/ead1298f/attachment.sig>

From mthode at mthode.org  Thu Apr  4 21:51:00 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 16:51:00 -0500
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
Message-ID: <20190404215100.q423citnpfjuiro3@mthode.org>

On 19-04-04 14:30:51, Eric K wrote:
> Requesting exception to lower a requirement to resolve a packaging issue.
> 
> https://review.openstack.org/#/c/650100/
> 

This is more of a stable question, it's late in the cycle but it sounds
possibly needed.  I think this is fine technically, but not sure about
it policy wise.  To me it sounds more of CentOS's problem than
Openstack's (to be a bit brash).  Added the stable tag to the thread.

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/67e42ccd/attachment.sig>

From mriedemos at gmail.com  Thu Apr  4 21:53:26 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 4 Apr 2019 16:53:26 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <169e9fcdb1a.e15f559b88571.1212271737893105500@ghanshyammann.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <6f5fe950-b7c7-5fed-a549-380db169261f@gmail.com>
 <169e9fcdb1a.e15f559b88571.1212271737893105500@ghanshyammann.com>
Message-ID: <9d934941-b5bd-8854-cb32-a870e3f6bb47@gmail.com>

On 4/4/2019 3:14 PM, Ghanshyam Mann wrote:
> https://review.openstack.org/#/c/649744/
> https://review.openstack.org/#/c/649745/

These are approved.

> https://review.openstack.org/#/c/648884/

I rebased this into a series so ping me to approve when it's passing CI.

-- 

Thanks,

Matt


From mthode at mthode.org  Thu Apr  4 21:55:43 2019
From: mthode at mthode.org (Matthew Thode)
Date: Thu, 4 Apr 2019 16:55:43 -0500
Subject: [stable][requirements][FFE][congress] lower psycopg2 requirement
 to 2.5.1
In-Reply-To: <20190404215100.q423citnpfjuiro3@mthode.org>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
Message-ID: <20190404215543.tm573hgpy7zmf4wn@mthode.org>

On 19-04-04 16:51:00, Matthew Thode wrote:
> On 19-04-04 14:30:51, Eric K wrote:
> > Requesting exception to lower a requirement to resolve a packaging issue.
> > 
> > https://review.openstack.org/#/c/650100/
> > 
> 
> This is more of a stable question, it's late in the cycle but it sounds
> possibly needed.  I think this is fine technically, but not sure about
> it policy wise.  To me it sounds more of CentOS's problem than
> Openstack's (to be a bit brash).  Added the stable tag to the thread.
> 

Adding stable tag

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/f11a116e/attachment-0001.sig>

From ekcs.openstack at gmail.com  Thu Apr  4 23:20:12 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Thu, 04 Apr 2019 15:20:12 -0800
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <20190404215100.q423citnpfjuiro3@mthode.org>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
Message-ID: <D8CBD0AE.C3B1F%ekcs.openstack@gmail.com>

On 4/4/19, 1:51 PM, "Matthew Thode" <mthode at mthode.org> wrote:

>On 19-04-04 14:30:51, Eric K wrote:
>> Requesting exception to lower a requirement to resolve a packaging
>>issue.
>> 
>> https://review.openstack.org/#/c/650100/
>> 
>
>This is more of a stable question, it's late in the cycle but it sounds
>possibly needed.  I think this is fine technically, but not sure about
>it policy wise.  To me it sounds more of CentOS's problem than
>Openstack's (to be a bit brash).  Added the stable tag to the thread.
>
>-- 
>Matthew Thode

Thanks Matthew. I'm not so worried about stability because even if it
breaks
Something it affects only a new (Stein) experimental feature no one is
relying on.




From doug at doughellmann.com  Thu Apr  4 23:59:22 2019
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 4 Apr 2019 19:59:22 -0400
Subject: [TC] PTG Lunch Talks
In-Reply-To: <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
 <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
Message-ID: <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>

I’d love to hear from teams about major work they have planned for Train. 

Doug

> On Apr 4, 2019, at 5:08 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
> 
> Dear TC members,
> 
> I'd like to push this up your inboxes.  It would be good for us to at
> least give a yes (I'm inclined to say yes) and come up with important
> things for the community to know, perhaps similar to Denver.
> 
> Thanks,
> Mohammed
> 
>> On Thu, Mar 28, 2019 at 8:19 PM Kendall Nelson <kennelson11 at gmail.com> wrote:
>> 
>> Hello!
>> 
>> I think you all have already started to discuss this, but if you haven't, here's the lowdown: You can have 15 min or 30 min on Thursday (we will also have lightning talks from the othe projects attending the PTG after you complete your time) and basically however much time you want on Saturday during lunch (keeping in mind that a lot of people are planning to leave Friday night). Friday is going to be the feedback session so there's not time available lunch that day.
>> 
>> tldr; Do you want 15min or 30 min on Thursday? :)
>> 
>> 
>> -Kendall Nelson
>> 
>> 
>> 
> 
> 
> -- 
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com
> 



From mriedemos at gmail.com  Fri Apr  5 00:35:43 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 4 Apr 2019 19:35:43 -0500
Subject: [nova] Down cell testing with devstack
Message-ID: <24f336d2-dca7-d208-fab6-d8a5eb1ab1e7@gmail.com>

Just an FYI but I've posted a docs patch with a testing guide for 
recreating a down-cell environment with a simple devstack setup:

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

I had done this awhile back and had it on my todo list to make sure this 
was documented for the next time I need to do some manual testing with
down cells.

-- 

Thanks,

Matt


From manuel.sb at garvan.org.au  Fri Apr  5 00:52:17 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Fri, 5 Apr 2019 00:52:17 +0000
Subject: Openstack attaching same pci device to 2 different vms?
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>

Dear Openstack community,

I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device.

I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them:

[centos at test-nvme-small ~]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda     253:0    0   10G  0 disk
└─vda1  253:1    0   10G  0 part /
nvme0n1 259:0    0  1.8T  0 disk

[centos at test-nvme-small-2 ~]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda     253:0    0   10G  0 disk
└─vda1  253:1    0   10G  0 part /
nvme0n1 259:0    0  1.8T  0 disk

So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file from virsh which can be found below (I am only putting the information between the disks section but happy to attach the hole file if needed):


Device/disk configuration for instance-00000094

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/>
      <backingStore type='file' index='1'>
        <format type='raw'/>
        <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>



Device/disk configuration for instance-00000093

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/>
      <backingStore type='file' index='1'>
        <format type='raw'/>
        <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>


Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms is 0000:00:04.0


Questions:

Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml file?
Am I right assuming that the same disk is attached to both vms? If yes, how can that happen?

Thank you very much
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/df834ed5/attachment-0001.html>

From hongbin034 at gmail.com  Fri Apr  5 00:55:43 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Thu, 4 Apr 2019 20:55:43 -0400
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
 <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>

Navdeep,

Would you provide the following as well:

* The output of "pip freeze"
* The log of zun-compute (sudo journalctl -u zun-compute > zun-compute.log)

Best regards,
Hongbin

On Thu, Apr 4, 2019 at 9:21 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Hi Hongbin,
>
> Thank you for your reply.
> Following are the log errors I am getting:
>
> LogFile:
> 2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019
> 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
>
> 2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-]
> Received JSON data {u'Address': u'10.68.48.137', u'Options':
> {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'},
> u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for
> /IpamDriver.RequestAddress ipam_request_address
> /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
>
> 2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected
> error happened: Requested ip address {'subnet_id':
> u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'}
> already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip
> address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
> Journald:
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent
> call last):
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in
> full_dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv =
> self.dispatch_request()
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in
> dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     return
> self.view_functions[rule.endpoint](**req.view_args)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 1740, in ipam_request_address
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port,
> fixed_ip, req_mac_address)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 542, in _update_existing_port
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException:
> Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
>
>
> Kind Regards,
>
> Navdeep
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190404/dbe3ad0c/attachment.html>

From mnaser at vexxhost.com  Fri Apr  5 01:13:20 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 4 Apr 2019 21:13:20 -0400
Subject: Openstack attaching same pci device to 2 different vms?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <CAEs876gm=PJgzUYuM0rqyuazQZpCcJ27+jguNOyrLAmzdq8=Cg@mail.gmail.com>

On Thu, Apr 4, 2019 at 8:55 PM Manuel Sopena Ballesteros
<manuel.sb at garvan.org.au> wrote:
>
> Dear Openstack community,
>
>
>
> I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device.
>
>
>
> I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them:
>
>
>
> [centos at test-nvme-small ~]$ lsblk
>
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>
> vda     253:0    0   10G  0 disk
>
> └─vda1  253:1    0   10G  0 part /
>
> nvme0n1 259:0    0  1.8T  0 disk
>
>
>
> [centos at test-nvme-small-2 ~]$ lsblk
>
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>
> vda     253:0    0   10G  0 disk
>
> └─vda1  253:1    0   10G  0 part /
>
> nvme0n1 259:0    0  1.8T  0 disk
>
>
>
> So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file from virsh which can be found below (I am only putting the information between the disks section but happy to attach the hole file if needed):
>
>
>
>
>
> Device/disk configuration for instance-00000094
>
>
>
>     <disk type='file' device='disk'>
>
>       <driver name='qemu' type='qcow2' cache='none'/>
>
>       <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/>
>
>       <backingStore type='file' index='1'>
>
>         <format type='raw'/>
>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>
>         <backingStore/>
>
>       </backingStore>
>
>       <target dev='vda' bus='virtio'/>
>
>       <alias name='virtio-disk0'/>
>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>
>     </disk>
>
>
>
>
>
>
>
> Device/disk configuration for instance-00000093
>
>
>
>     <disk type='file' device='disk'>
>
>       <driver name='qemu' type='qcow2' cache='none'/>
>
>       <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/>
>
>       <backingStore type='file' index='1'>
>
>         <format type='raw'/>
>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>
>         <backingStore/>
>
>       </backingStore>
>
>       <target dev='vda' bus='virtio'/>
>
>       <alias name='virtio-disk0'/>
>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>
>     </disk>
>
>
>
>
>
> Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms is 0000:00:04.0
>
>
>
>
>
> Questions:
>
>
>
> Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml file?

I don't think so.  I'm not the best at answering this.

> Am I right assuming that the same disk is attached to both vms? If yes, how can that happen?

That's the root device, that's not the PCI passthrough device

>
>
> Thank you very much
>
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From no-reply at openstack.org  Fri Apr  5 01:51:00 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Fri, 05 Apr 2019 01:51:00 -0000
Subject: nova 19.0.0.0rc2 (stein)
Message-ID: <mailman.519.1554429099.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for nova for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/nova/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/nova/log/?h=stable/stein

Release notes for nova can be found at:

    https://docs.openstack.org/releasenotes/nova/

If you find an issue that could be considered release-critical, please
file it at:

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

and tag it *stein-rc-potential* to bring it to the nova
release crew's attention.



From gsteinmuller at vexxhost.com  Fri Apr  5 03:07:43 2019
From: gsteinmuller at vexxhost.com (=?UTF-8?Q?Guilherme_Steinm=C3=BCller?=)
Date: Fri, 5 Apr 2019 00:07:43 -0300
Subject: [openstack-ansible] Retirement of unused OpenStack Ansible roles
Message-ID: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>

Hello all,

We have been discussing about some of our roles that are not maintained for
a while, some of them are not even integrated with our main repository. In
order to the team to focus on performance and stability of the roles that
has been actively used, we are discussing about retiring the unused ones.

The roles are the following:

    openstack-ansible-os_monasca
    openstack-ansible-os_monasca-agent
    openstack-ansible-os_zaqar
    openstack-ansible-os_watcher
    openstack-ansible-os_almanach
    openstack-ansible-os_molteniron
    openstack-ansible-os_searchlight

We would love to help if someone wants to pick one or some of them to keep
our variety of roles.  If we don't hear back, we'll retire those roles out
of OpenStack Ansible.

Thank you
Guilherme Steinmüller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/5720fe04/attachment.html>

From manuel.sb at garvan.org.au  Fri Apr  5 03:52:06 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Fri, 5 Apr 2019 03:52:06 +0000
Subject: Openstack attaching same pci device to 2 different vms?
In-Reply-To: <CAEs876gm=PJgzUYuM0rqyuazQZpCcJ27+jguNOyrLAmzdq8=Cg@mail.gmail.com>
References: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>
 <CAEs876gm=PJgzUYuM0rqyuazQZpCcJ27+jguNOyrLAmzdq8=Cg@mail.gmail.com>
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E89DD65@MXDB1.ad.garvan.unsw.edu.au>

Ok,

Yes sorry, my bad, I got confused because I was looking in the wrong section.

I believe the right place to look for the pass-through pci devices is under hostdev section

    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
      </source>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </hostdev>

Thank you for your help Mohammed

Manuel

-----Original Message-----
From: Mohammed Naser [mailto:mnaser at vexxhost.com]
Sent: Friday, April 5, 2019 12:13 PM
To: Manuel Sopena Ballesteros
Cc: openstack at lists.openstack.org
Subject: Re: Openstack attaching same pci device to 2 different vms?

On Thu, Apr 4, 2019 at 8:55 PM Manuel Sopena Ballesteros
<manuel.sb at garvan.org.au> wrote:
>
> Dear Openstack community,
>
>
>
> I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device.
>
>
>
> I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them:
>
>
>
> [centos at test-nvme-small ~]$ lsblk
>
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>
> vda     253:0    0   10G  0 disk
>
> └─vda1  253:1    0   10G  0 part /
>
> nvme0n1 259:0    0  1.8T  0 disk
>
>
>
> [centos at test-nvme-small-2 ~]$ lsblk
>
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
>
> vda     253:0    0   10G  0 disk
>
> └─vda1  253:1    0   10G  0 part /
>
> nvme0n1 259:0    0  1.8T  0 disk
>
>
>
> So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file from virsh which can be found below (I am only putting the information between the disks section but happy to attach the hole file if needed):
>
>
>
>
>
> Device/disk configuration for instance-00000094
>
>
>
>     <disk type='file' device='disk'>
>
>       <driver name='qemu' type='qcow2' cache='none'/>
>
>       <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/>
>
>       <backingStore type='file' index='1'>
>
>         <format type='raw'/>
>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>
>         <backingStore/>
>
>       </backingStore>
>
>       <target dev='vda' bus='virtio'/>
>
>       <alias name='virtio-disk0'/>
>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>
>     </disk>
>
>
>
>
>
>
>
> Device/disk configuration for instance-00000093
>
>
>
>     <disk type='file' device='disk'>
>
>       <driver name='qemu' type='qcow2' cache='none'/>
>
>       <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/>
>
>       <backingStore type='file' index='1'>
>
>         <format type='raw'/>
>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>
>         <backingStore/>
>
>       </backingStore>
>
>       <target dev='vda' bus='virtio'/>
>
>       <alias name='virtio-disk0'/>
>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>
>     </disk>
>
>
>
>
>
> Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms is 0000:00:04.0
>
>
>
>
>
> Questions:
>
>
>
> Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml file?

I don't think so.  I'm not the best at answering this.

> Am I right assuming that the same disk is attached to both vms? If yes, how can that happen?

That's the root device, that's not the PCI passthrough device

>
>
> Thank you very much
>
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.



--
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

From melwittt at gmail.com  Fri Apr  5 06:05:50 2019
From: melwittt at gmail.com (melanie witt)
Date: Thu, 4 Apr 2019 23:05:50 -0700
Subject: [nova][dev] Fixing eventlet monkey patching in Nova
In-Reply-To: <2e85a67d5aace8b4f4a58fb66ac5d6de09f88af5.camel@redhat.com>
References: <CAEkQeheLcMRnX+8tjNtkP+89wLBH1pgdSAjvuy8q8hdos1E32g@mail.gmail.com>
 <351a7db3-08e9-0a19-8ef1-b59eab8f9a59@nemebean.com>
 <alpine.OSX.2.21.1903151842520.10832@cdent-a01.vmware.com>
 <9bf0e8ed-c05b-6fde-f952-fdbe61f22e34@gmail.com>
 <47360fca029d7cc012d98a7d00fee9aabad3a4db.camel@redhat.com>
 <085101b6-9a69-98ad-72b4-da92c45746de@inaugust.com>
 <5f4a9dd1-feb6-6c05-8aaf-864a7a5c1a04@nemebean.com>
 <ba26b8c02ed1fc124d5b665ceadb3a883b64a47c.camel@redhat.com>
 <CAEd1pt55CbzAGqTq2DhKd4DXPmdMgAWU7R-XZB4tC-OSPhEwXg@mail.gmail.com>
 <b719df6c088986aeaa079e1cb8efe875e9305f4e.camel@redhat.com>
 <17fa0e75-91bc-103e-b6ad-bc70446fff98@inaugust.com>
 <2e85a67d5aace8b4f4a58fb66ac5d6de09f88af5.camel@redhat.com>
Message-ID: <1bea9064-e9bc-3c2b-5b29-c639705b9c01@gmail.com>

On Wed, 20 Mar 2019 07:39:20 +0000, Sean Mooney <smooney at redhat.com> wrote:
> On Wed, 2019-03-20 at 02:22 +0000, Monty Taylor wrote:
>>> we could proably add the concurrent.futures executor interface to privsep if we wanted its only 3 function after all
>>> https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor
>>> but since there is a python 2.7 backport we may be better served just using it.
>>
>> It's also worth pointing out the futurist library, which is part of oslo:
>>
>> https://opendev.org/openstack/futurist
>>
>> It's similar to (and uses) concurrent.futures - except it also has a
>> bunch of different backend impls - so you can have tasks run in threads,
>> or it can use eventlet, or processes - or work synchronously.
> 
> thanks i was looking for this.
> i was aware that oslo.messaging to name buy one lib supported
> a configurable executor.
> 
> i had expected to find those executos in oslo.concurancy but
> looking a futurist it makes sense.
> 
> i see the executors defiend in https://opendev.org/openstack/futurist/src/branch/master/futurist/_futures.py
> do indeed derive form the concurent future executor abstract base class.
> 
> the map function is in the executor base class is internally in terms of the submit function so the futuist
> executors are compatiable with the standard lib varients from python3.
> 
> i wonder if it would make sense to crete an optional dependency on privsep from futurist and add a privsep executor?
> 
> pivoting back to melenie's original question regarding what alternative we have for nova we could change
> our explict use of eventlets to the GreenThreadPoolExecutor
> https://opendev.org/openstack/futurist/src/branch/master/futurist/_futures.py#L322
> this would still require and use eventlets under the hood so the perfromace would be the same as our current explict
> use of the eventlet event loop but would allow us to change the eventloop via config the same way oslo.messaging
> allows changing for the eventlet executor to the threading executor.
> 
> if we removed all explcit use of eventlet this way we could then start looking at our implit use of eventlets which
> is largely for db acess, rest api calls to other services and some virt dirver specific calls.
> 
> anyway i had assumed that revisiting dropping eventlets form services would be a U conversation at the earliest
> but if we swap to using the futurist executors for the multi cell scater gather list operation we could stop
> monkeypatching under wsgi again and instead use the ThreadPoolExecutor or ProcessPoolExecutor in that case.
> when running the api without wsgi we can revert to the GreenThreadPoolExecutor.

Thanks for all this info. I've taken a hack at replacing direct eventlet 
use with futurist.GreenThreadPoolExecutor in scatter_gather_cells as a 
first step:

https://review.openstack.org/650172

-melanie

>>
>>> privsep is effectivly just a ThreadPoolExecutor that layers on the privlage escalation/descalation logic
>>> via either fork and drop privalages or sudo + rootwrap/privsep helper to gain privileges
> 
> 






From thierry at openstack.org  Fri Apr  5 07:38:04 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 5 Apr 2019 09:38:04 +0200
Subject: [TC] PTG Lunch Talks
In-Reply-To: <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
 <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
 <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>
Message-ID: <6f749db9-5a0e-2f2c-0d09-83d01de56b1a@openstack.org>

Doug Hellmann wrote:
> I’d love to hear from teams about major work they have planned for Train.

Also introducing Train goals would be nice.

-- 
Thierry


From amoralej at redhat.com  Fri Apr  5 07:54:56 2019
From: amoralej at redhat.com (Alfredo Moralejo Alonso)
Date: Fri, 5 Apr 2019 09:54:56 +0200
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <20190404215100.q423citnpfjuiro3@mthode.org>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
Message-ID: <CACrbaxjeqqFX03F9z31_ZAQREUkLZEVrfJiw-UsvHwkqMtdieA@mail.gmail.com>

On Thu, Apr 4, 2019 at 11:51 PM Matthew Thode <mthode at mthode.org> wrote:

> On 19-04-04 14:30:51, Eric K wrote:
> > Requesting exception to lower a requirement to resolve a packaging issue.
> >
> > https://review.openstack.org/#/c/650100/
> >
>
> This is more of a stable question, it's late in the cycle but it sounds
> possibly needed.  I think this is fine technically, but not sure about
> it policy wise.  To me it sounds more of CentOS's problem than
> Openstack's (to be a bit brash).  Added the stable tag to the thread.
>
>
To clarify this topic, the approach in RDO is not to provide newer versions
of packages which are included in CentOS base repos as it may affect other
packages included in the distro *unless is required*. This means we update
dependencies included in CentOS for issues actually reported by users or
detected by CI but not proactively to match what is in upper-constraints.

In the original implementation of the new feature in Congress this was the
case (it was breaking CI jobs) so i started the process to update it in RDO
in https://review.rdoproject.org/r/#/c/19929/ . According to the feedback
from Eric, this is needed just for a experimental feature so i think that
doing the import conditional or changing the implementation as done in
https://review.openstack.org/#/c/650100/ is good. Anyway, let us know if
the update of psycopg2 is needed and i will revive it.




> --
> Matthew Thode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/bb1c6805/attachment.html>

From no-reply at openstack.org  Fri Apr  5 08:20:52 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Fri, 05 Apr 2019 08:20:52 -0000
Subject: openstack-congress 9.0.0.0rc2 (stein)
Message-ID: <mailman.520.1554452459.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for openstack-congress for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/congress/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/congress/log/?h=stable/stein

Release notes for openstack-congress can be found at:

    https://docs.openstack.org/releasenotes/congress/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/congress/+bugs

and tag it *stein-rc-potential* to bring it to the openstack-congress
release crew's attention.



From no-reply at openstack.org  Fri Apr  5 08:22:12 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Fri, 05 Apr 2019 08:22:12 -0000
Subject: octavia 4.0.0.0rc2 (stein)
Message-ID: <mailman.521.1554452532.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for octavia for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/octavia/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein

Release notes for octavia can be found at:

    https://docs.openstack.org/releasenotes/octavia/

If you find an issue that could be considered release-critical, please
file it at:

    https://storyboard.openstack.org/#!/project/908

and tag it *stein-rc-potential* to bring it to the octavia
release crew's attention.



From smooney at redhat.com  Fri Apr  5 09:59:50 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 10:59:50 +0100
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <D8CBD0AE.C3B1F%ekcs.openstack@gmail.com>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
 <D8CBD0AE.C3B1F%ekcs.openstack@gmail.com>
Message-ID: <9dbad6413f5018608ad312663edd5687b537aaca.camel@redhat.com>

On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
> On 4/4/19, 1:51 PM, "Matthew Thode" <mthode at mthode.org> wrote:
> 
> > On 19-04-04 14:30:51, Eric K wrote:
> > > Requesting exception to lower a requirement to resolve a packaging
> > > issue.
> > > 
> > > https://review.openstack.org/#/c/650100/
> > > 
> > 
> > This is more of a stable question, it's late in the cycle but it sounds
> > possibly needed.  I think this is fine technically, but not sure about
> > it policy wise.  To me it sounds more of CentOS's problem than
> > Openstack's (to be a bit brash).  Added the stable tag to the thread.
> > 
> > -- 
> > Matthew Thode
> 
> Thanks Matthew. I'm not so worried about stability because even if it
> breaks
> Something it affects only a new (Stein) experimental feature no one is
> relying on.
congresses lower constraints job
https://github.com/openstack/congress/blob/master/tox.ini#L103-L108

is broken the same way as novas was because of the install command that is used
https://github.com/openstack/congress/blob/master/tox.ini#L9

so https://review.openstack.org/#/c/650100/
sets the lower constatit to something that is invalid for the gate job
which runs on ubuntu. if you look at the output of the job
http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/13666ba/tox/lower-constraints-1.log

we can see its using psycopg2
Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt (line
81))
  Downloading 
http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa3323de46a5cc2745aeb4c9db11352ca905d3a15c53b6a816/psycopg2-2.7.7-cp36-cp36m-manylinux1_x86_64.whl
 (2.7MB)

it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job cannot be
fixed.

pep-0508 defines a set of markers we can use for packageing
https://www.python.org/dev/peps/pep-0508/

the only marker that i know of that contains the disto name is "platform_version"

we should be able to do something like

psycopg2==2.5.1; platform_version~=CENTOS
psycopg2==2.7;

but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build the
centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions is
not relevent unless i have missed something.
> 
> 
> 



From smooney at redhat.com  Fri Apr  5 10:12:08 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 11:12:08 +0100
Subject: Openstack attaching same pci device to 2 different vms?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E89DA0F@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <140212d46299a2c698a6aaa645f52ce9c24e0299.camel@redhat.com>

On Fri, 2019-04-05 at 00:52 +0000, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
> 
> I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device.
> 
> I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them:
> 
> [centos at test-nvme-small ~]$ lsblk
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> vda     253:0    0   10G  0 disk
> └─vda1  253:1    0   10G  0 part /
> nvme0n1 259:0    0  1.8T  0 disk
> 
> [centos at test-nvme-small-2 ~]$ lsblk
> NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> vda     253:0    0   10G  0 disk
> └─vda1  253:1    0   10G  0 part /
> nvme0n1 259:0    0  1.8T  0 disk
> 
> So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file
> from virsh which can be found below (I am only putting the information between the disks section but happy to attach
> the hole file if needed):
> 
> 
> Device/disk configuration for instance-00000094
> 
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/>
>       <backingStore type='file' index='1'>
>         <format type='raw'/>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>         <backingStore/>
>       </backingStore>
>       <target dev='vda' bus='virtio'/>
>       <alias name='virtio-disk0'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>     </disk>
> 
> 
> 
> Device/disk configuration for instance-00000093
> 
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2' cache='none'/>
>       <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/>
>       <backingStore type='file' index='1'>
>         <format type='raw'/>
>         <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
>         <backingStore/>
>       </backingStore>
>       <target dev='vda' bus='virtio'/>
>       <alias name='virtio-disk0'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
>     </disk>

can you provide the full xmls
these diss are not the nvme disk
this is the info for the root disk wihc is a qcow 2 file on you host.
when you are passing the pci devices form the host they will show up in the libvirt xml
as a hostdev element.
it will look something like this

<devices>
  <hostdev mode='subsystem' type='pci' managed='yes'>
    <source>
      <address domain='0x0000' bus='0x06' slot='0x02' function='0x0'/>
    </source>
  </hostdev>
</devices>

in this case teh address in the source element will be the host pci address of the nvme device
you may also have other fields like a second guest address element which will be outside the source element
> 
> 
> Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms
> is 0000:00:04.0
no this is the  pci address where the virtio disk (your root disk) will be presented to the guest.
> 
> 
> Questions:
> 
> Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml
> file?
technically its sored in the nova db in the pci_devices table but i would much perfer operators to look at the xmls
first before touching the db.

> Am I right assuming that the same disk is attached to both vms?
no luclly that is not whats happening. if it was all maner of things would be broken :)
>  If yes, how can that happen?
> 
> Thank you very much
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.



From sombrafam at gmail.com  Fri Apr  5 11:03:05 2019
From: sombrafam at gmail.com (Erlon Cruz)
Date: Fri, 5 Apr 2019 08:03:05 -0300
Subject: [cinder] Cinder Volume Active/Active Support
In-Reply-To: <20190329093214.54hljbc437hgz2l7@localhost>
References: <0454b513-4bea-b82d-c8be-d496f60022c3@noris.gr>
 <188bd950-4234-f238-4af5-3993dc33e4a5@nemebean.com>
 <20190328154444.GA3429@sm-workstation>
 <20190329093214.54hljbc437hgz2l7@localhost>
Message-ID: <CAF+Cadta2NYVqT-EacLxOnQsF3LQQvJHXzQmXVnw26DvmqZi0g@mail.gmail.com>

@Gorka, do you have what you have from the framework library available
somewhere?

Em sex, 29 de mar de 2019 às 06:35, Gorka Eguileor <geguileo at redhat.com>
escreveu:

> On 28/03, Sean McGinnis wrote:
> > On Thu, Mar 28, 2019 at 08:56:25AM -0500, Ben Nemec wrote:
> > > Fixed the cinder tag so this should show up for people who filter on
> it.
> > >
> > > On 3/28/19 3:18 AM, vkalaitzis wrote:
> > > > I would like to ask if cinder-volume supports active/active setups.
> > > > I found that there was a blueprint for adding support (
> https://blueprints.launchpad.net/cinder/+spec/cinder-volume-active-active-support
> ),
> > > > but as far as I am concerned, no official documentation of such
> feature
> > > > exists so far.
> > >
> > > My understanding is that Cinder does support active-active
> configuration
> > > now, but someone from the Cinder team will have to provide details.
> > >
> >
> > The support is merged in Cinder for active/active, but the hold up now
> has been
> > getting Cinder driver maintainers to certify their drivers and storage
> devices
> > will work correctly when running in that configuration.
> >
> > I seem to recall some work being done with the Ceph/RBD driver, but I
> don't
> > believe anything has merged for any drivers to enable that.
> >
>
> Hi,
>
> The RBD driver can be deployed in Active-Active [1] and there is work
> underway for Triple-O to support Active-Active deployments, but there
> has not been exhaustive testing to confirm there are no issues with the
> current state of the feature and with the driver itself under these
> conditions.
>
> Like Sean says, the hold up is caused by testing and validation.  We
> would need a deterministic mechanism to model and run failure test
> cases.  Without it we won't know if the tests are passing because the
> failure happened when the code was in a happy place.
>
> We could also run some kind of chaos monkey, but then we would need to
> be able to determine what the expected state of the system is, based on
> where the code was when the monkey hit it.
>
> For this purpose, a couple of year back, I started working on a testing
> framework that would allow us to inject predefined actions, replace
> methods return codes, generate side effects, and even inject arbitrary
> code into a running Cinder deployment.  The API request included the
> testing action as well as the normal request made to Cinder, in the
> testing action we also defined where in the code and in which service it
> should be run.  I vaguely remember the injection mechanism also allowed
> calls to be changed from async to sync in order to be able to return
> data to inspect internal service states.
>
> Unfortunately, a change in priorities made me drop this work on the
> early PoC stages, and I don't know when I'll be able to get back to it.
>
> Cheers,
> Gorka.
>
>
>
>
> [1]:
> https://opendev.org/openstack/cinder/src/branch/master/cinder/volume/drivers/rbd.py#L218
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/e2837608/attachment.html>

From ionut at fleio.com  Fri Apr  5 11:44:15 2019
From: ionut at fleio.com (Ionut Biru)
Date: Fri, 5 Apr 2019 14:44:15 +0300
Subject: fqdn magnum instances
Message-ID: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>

Hello,

I was wondering if there is a way to set up the domain for template to use
in order to have a FQDN hostname for all the vms that are part from the
cluster
Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i
want something like  k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net

I'm trying to resolve this:

helm install stable/wordpress
Error: forwarding ports: error upgrading connection: error dialing backend:
dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on 8.8.8.8:53: no
such host
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/337cf561/attachment.html>

From bharat at stackhpc.com  Fri Apr  5 11:52:42 2019
From: bharat at stackhpc.com (Bharat Kunwar)
Date: Fri, 5 Apr 2019 12:52:42 +0100
Subject: fqdn magnum instances
In-Reply-To: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
Message-ID: <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>

Where are you running this command?

> On 5 Apr 2019, at 12:44, Ionut Biru <ionut at fleio.com> wrote:
> 
> Hello,
> 
> I was wondering if there is a way to set up the domain for template to use in order to have a FQDN hostname for all the vms that are part from the cluster
> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i want something like  k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net <http://k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net/>
> 
> I'm trying to resolve this:
> 
> helm install stable/wordpress
> Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on 8.8.8.8:53 <http://8.8.8.8:53/>: no such host

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/ad1050b0/attachment.html>

From ionut at fleio.com  Fri Apr  5 12:06:57 2019
From: ionut at fleio.com (Ionut Biru)
Date: Fri, 5 Apr 2019 15:06:57 +0300
Subject: fqdn magnum instances
In-Reply-To: <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
 <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>
Message-ID: <CALE96NBFCVHhXPRiRMOiaaB-Gfhf3bOkWjjCTgFf2+iXECk+sw@mail.gmail.com>

Hello,

>From my computer, after exporting the config using:
openstack coe cluster config id.

I'm using helm from my computer because coreos master doesn't have this
utility or even  kubectl.



On Fri, Apr 5, 2019 at 2:52 PM Bharat Kunwar <bharat at stackhpc.com> wrote:

> Where are you running this command?
>
> On 5 Apr 2019, at 12:44, Ionut Biru <ionut at fleio.com> wrote:
>
> Hello,
>
> I was wondering if there is a way to set up the domain for template to use
> in order to have a FQDN hostname for all the vms that are part from the
> cluster
> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i
> want something like
> k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net
>
> I'm trying to resolve this:
>
> helm install stable/wordpress
> Error: forwarding ports: error upgrading connection: error dialing
> backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on
> 8.8.8.8:53: no such host
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/c7774dde/attachment.html>

From bharat at stackhpc.com  Fri Apr  5 12:08:23 2019
From: bharat at stackhpc.com (Bharat Kunwar)
Date: Fri, 5 Apr 2019 13:08:23 +0100
Subject: fqdn magnum instances
In-Reply-To: <CALE96NBFCVHhXPRiRMOiaaB-Gfhf3bOkWjjCTgFf2+iXECk+sw@mail.gmail.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
 <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>
 <CALE96NBFCVHhXPRiRMOiaaB-Gfhf3bOkWjjCTgFf2+iXECk+sw@mail.gmail.com>
Message-ID: <FE644DAF-4F88-48F6-981A-7304A9C05ABB@stackhpc.com>

Can you even deploy a POD?

> On 5 Apr 2019, at 13:06, Ionut Biru <ionut at fleio.com> wrote:
> 
> Hello,
> 
> From my computer, after exporting the config using: 
> openstack coe cluster config id.
> 
> I'm using helm from my computer because coreos master doesn't have this utility or even  kubectl.
> 
> 
> 
> On Fri, Apr 5, 2019 at 2:52 PM Bharat Kunwar <bharat at stackhpc.com <mailto:bharat at stackhpc.com>> wrote:
> Where are you running this command?
> 
>> On 5 Apr 2019, at 12:44, Ionut Biru <ionut at fleio.com <mailto:ionut at fleio.com>> wrote:
>> 
>> Hello,
>> 
>> I was wondering if there is a way to set up the domain for template to use in order to have a FQDN hostname for all the vms that are part from the cluster
>> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i want something like  k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net <http://k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net/>
>> 
>> I'm trying to resolve this:
>> 
>> helm install stable/wordpress
>> Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on 8.8.8.8:53 <http://8.8.8.8:53/>: no such host
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/2bc11db9/attachment-0001.html>

From florian.engelmann at everyware.ch  Fri Apr  5 12:29:00 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Fri, 5 Apr 2019 14:29:00 +0200
Subject: [nova] retire a flavor
In-Reply-To: <ac730819a9ea080e2c7d0fb1ff57b630eb59c76e.camel@redhat.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
 <ac730819a9ea080e2c7d0fb1ff57b630eb59c76e.camel@redhat.com>
Message-ID: <d1def15e-c4fd-6476-a629-9b76bb636f3a@everyware.ch>

>> I think we need some method to retire images and flavors.
> well it depend on what you mean by retire.
> my definition of retire means it still exist but is no longer
> requestable for new instances. idealy if you retire something from
> service it should be possible to reinstate it again even if that is unlikely.
> 

That's also my definition of retire. It still exists but no new instance 
can choose it and is no more listed for normal (member) users. And I 
agree - re-enable should be possible.

> but yes we shoudl have a documented procedure to "retire" a flavor  or image in the
> admin guide somewhere but we also need to define what that means first and that might
> change form deployment to deployment at least in some cases.
> 

Yes but if the database schema is already prepared to disable (=retire?) 
a flavor we should implement this in the API first and then document it?

> 
>>
>> All the best,
>> Florian
>>
>> Am 3/31/19 um 11:57 AM schrieb Sean Mooney:
>>> On Fri, 2019-03-29 at 11:25 -0500, Eric Fried wrote:
>>>> Florian-
>>>>
>>>> You can definitely delete a flavor [1].
>>>>
>>>> Don't worry about it affecting existing instances that were created with
>>>> that flavor: nova stores a copy of the flavor with the instance itself
>>>> so the information is preserved.
>>>>
>>>> Thanks for the question!
>>>
>>> the other option if you want to keep the flavor but not make it usable by
>>> new instances in general is to use the os-flavor-access api.
>>> https://developer.openstack.org/api-ref/compute/?expanded=#flavors-access-flavors-os-flavor-access
>>> This allows you to make a flavor private and control what project can use it.
>>>
>>>
>>> unfortunetly we seam to have almost no documentation for this however that is what the --project argument
>>> to openstack flavor set is used to contol.
>>> https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/flavor.html#flavor-set
>>> e.g. openstack flavor set --project <my admin/hidden project> <flavor i want to retire>
>>>
>>> this will allow you to retire the flavor more selectively.
>>> so if you have a important customer that needs a little more time to move to your new flavor offerings
>>> you can similarly add them to the now private flavor to aide there transition before you actually delete it.
>>>
>>> as efried said you can delete the flavor without issue so if you are not worred about it breaking
>>> ci or other automation and can simply remove the flavor that hsould be safe to do so.
>>>>
>>>> -efried
>>>>
>>>> [1]
>>>> https://docs.openstack.org/nova/latest/admin/flavors.html#delete-a-flavor
>>>>
>>>> On 3/29/19 10:43 AM, Florian Engelmann wrote:
>>>>> Hi,
>>>>>
>>>>> I would like to retire old flavors we don't want to be use any more. I
>>>>> guess deleting is the wrong way to retire flavors? I was not able to
>>>>> find any documentation about how the life-cycle of a flavor works.
>>>>>
>>>>> Any help is very welcome.
>>>>>
>>>>> All the best,
>>>>> Florian
>>>>
>>>>
>>>
>>>
>>
>>
> 

-- 

EveryWare AG
Florian Engelmann
Senior UNIX Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: mailto:florian.engelmann at everyware.ch
web: http://www.everyware.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/3c9abdf7/attachment.bin>

From florian.engelmann at everyware.ch  Fri Apr  5 12:30:02 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Fri, 5 Apr 2019 14:30:02 +0200
Subject: [nova] retire a flavor
In-Reply-To: <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
 <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>
Message-ID: <0da89995-bcc8-b9fd-d727-32877a7db781@everyware.ch>

>>
>> I think we need some method to retire images and flavors.
> 
> Agreed, please report a nova bug for retiring a flavor.
> 
> As for retiring an image, I already pointed out there is a story for that:
> 
> https://storyboard.openstack.org/#!/story/2004892
> 
> But that's not really a nova bug.

I will create a bug report. I think it is a important feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/22625e28/attachment.bin>

From ionut at fleio.com  Fri Apr  5 12:30:19 2019
From: ionut at fleio.com (Ionut Biru)
Date: Fri, 5 Apr 2019 15:30:19 +0300
Subject: fqdn magnum instances
In-Reply-To: <FE644DAF-4F88-48F6-981A-7304A9C05ABB@stackhpc.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
 <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>
 <CALE96NBFCVHhXPRiRMOiaaB-Gfhf3bOkWjjCTgFf2+iXECk+sw@mail.gmail.com>
 <FE644DAF-4F88-48F6-981A-7304A9C05ABB@stackhpc.com>
Message-ID: <CALE96NBNSoXwLGqAuRcqB9iDdghfR7V-s9CjZpJq2nOSQO9URg@mail.gmail.com>

Hello,

Yes, I can. That's why I think I need the names to have a FQDN.

»» kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
pod/init-demo created
»» kubectl get pod init-demo
NAME        READY   STATUS            RESTARTS   AGE
init-demo   0/1     PodInitializing   0          9s
»» kubectl get pod init-demo
NAME        READY   STATUS            RESTARTS   AGE
init-demo   0/1     PodInitializing   0          12s
»» kubectl get pod init-demo
NAME        READY   STATUS    RESTARTS   AGE
init-demo   1/1     Running   0          20s
»» kubectl exec -it init-demo -- /bin/bash
Error from server: error dialing backend: dial tcp: lookup
k8s-cluster-coreos-uddxvspsxcon-minion-0 on 8.8.8.8:53: no such host


On Fri, Apr 5, 2019 at 3:08 PM Bharat Kunwar <bharat at stackhpc.com> wrote:

> Can you even deploy a POD?
>
> On 5 Apr 2019, at 13:06, Ionut Biru <ionut at fleio.com> wrote:
>
> Hello,
>
> From my computer, after exporting the config using:
> openstack coe cluster config id.
>
> I'm using helm from my computer because coreos master doesn't have this
> utility or even  kubectl.
>
>
>
> On Fri, Apr 5, 2019 at 2:52 PM Bharat Kunwar <bharat at stackhpc.com> wrote:
>
>> Where are you running this command?
>>
>> On 5 Apr 2019, at 12:44, Ionut Biru <ionut at fleio.com> wrote:
>>
>> Hello,
>>
>> I was wondering if there is a way to set up the domain for template to
>> use in order to have a FQDN hostname for all the vms that are part from the
>> cluster
>> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i
>> want something like
>> k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net
>>
>> I'm trying to resolve this:
>>
>> helm install stable/wordpress
>> Error: forwarding ports: error upgrading connection: error dialing
>> backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on
>> 8.8.8.8:53: no such host
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/d2cfaf40/attachment-0001.html>

From cdent+os at anticdent.org  Fri Apr  5 12:30:34 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Fri, 5 Apr 2019 13:30:34 +0100 (BST)
Subject: [placement] update 19-13
Message-ID: <alpine.OSX.2.21.1904051330040.47286@cdent-a01.vmware.com>


HTML: https://anticdent.org/placement-update-19-13.html

Placement update 19-13 is brought to you by the letters P and U.

# Most Important

The [Virtual
Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004225.html)
starts next week. Watch out for emails to start different threads
throughout the week. Also next week there will be a Nova pre-PTG
[spec
review](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4484).
Plenty of the pending work touches on placement.

In the meantime here are a couple of etherpads for the PTG:

* <https://etherpad.openstack.org/p/placement-ptg-train>
* <https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement>

# What's Changed

* There were some lingering docs and log fixes so we released an RC
   3 of Placement. That candidate will become 1.0.0 on April 10th.

* Microversion 1.32, for [forbidden
   aggregates](https://docs.openstack.org/placement/latest/placement-api-microversion-history.html#support-forbidden-aggregates)
   merged.

* We've decided it would be nice to a) release os-traits and
   os-resource-classes in an independent fashion and, b) make them
   available to both placement and nova as tox-siblings. We'll do (a)
   once release time settles. For (b) the strategy is still a bit up
   in the air. There's some [email
   discussion](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004424.html).

# Specs/Features

* Two traits related specs have been re-proposed to Train, following
   the [new
   process](https://docs.openstack.org/placement/latest/contributor/contributing.html#new-features).

     * <https://review.openstack.org/649992>
       Spec: support any trait in allocation candidates

     * <https://review.openstack.org/649368>
       Spec: support mixing required traits with any traits

* As before, the spec for [request group
   mapping](https://review.openstack.org/597601) will need to be
   revisited.

# Bugs

* StoryBoard stories in [the placement
   group](https://storyboard.openstack.org/#!/project_group/placement): 6.
   0 are
   [untagged](https://storyboard.openstack.org/#!/worklist/580).

* Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 13.
   -1.

* [In progress placement bugs](https://goo.gl/vzGGDQ) 5. -2.

Once Stein has settled, we'll figure out a good time to have a bug
cleanup and consolidation.

# osc-placement

osc-placement is currently behind by 14 microversions. +1 since last
week.

Pending changes:

* [support for 1.19](https://review.openstack.org/#/c/641094/)
* [support for 1.21](https://review.openstack.org/#/c/641123/)
* [aggregate allocation ratio
   tool](https://review.openstack.org/#/c/640898/)
* [stack to fix docs and
   classifiers](https://review.openstack.org/650093)

# Main Themes

Be thinking about what you'd like the main themes to be. Put them on
the [PTG
etherpad](https://etherpad.openstack.org/p/placement-ptg-train).

# Other Placement

* <https://review.openstack.org/#/c/645255/>
   This is a start at unit tests for the PlacementFixture. It is
   proving a bit "fun" to get right, as there are many layers
   involved. Making sure seemingly unrelated changes in placement
   don't break the nova gate is important. Besides these unit tests,
   there's discussion on the PTG etherpad of running the nova
   functional tests, or a subset thereof, in placement's check run.

     On the one hand this is a pain and messy, but on the other
     consider what we're enabling: Functional tests that use the real
     functionality of an external service (real data, real web
     requests), not stubs or fakes.

* <https://review.openstack.org/641404>
   Use ``code`` role in api-ref titles

* <https://review.openstack.org/649618>
   Removing some unused code.

# Other Service Users

New discoveries are added to the end. Merged stuff is removed.

Since last week 2 removals (by merge), 7 new discoveries.

* <https://review.openstack.org/552924>
   Nova: Spec: Proposes NUMA topology with RPs

* <https://review.openstack.org/622893>
   Nova: Spec: Virtual persistent memory libvirt driver
   implementation

* <https://review.openstack.org/641899>
   Nova: Check compute_node existence in when nova-compute reports
   info to placement

* <https://review.openstack.org/601596>
   Nova: spec: support virtual persistent memory

* <https://review.openstack.org/#/q/topic:bug/1790204>
   Workaround doubling allocations on resize

* <https://review.openstack.org/555081>
   Nova: Spec: Standardize CPU resource tracking

* <https://review.openstack.org/646029>
   Nova: Spec: Use in_tree getting allocation candidates

* <https://review.openstack.org/645316>
   Nova: Pre-filter hosts based on multiattach volume support

* <https://review.openstack.org/606199>
   Ironic: A fresh way of looking at step retrieval

* <https://review.openstack.org/647396>
   Nova: Add flavor to requested_resources in RequestSpec

* <https://review.openstack.org/633204>
   Blazar: Retry on inventory update conflict

* <https://review.openstack.org/640080>
   Nova: Use aggregate_add_host in nova-manage

* <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement>
   Nova: count quota usage from placement

* <https://review.openstack.org/#/q/topic:bug/1819923>
   Nova: nova-manage: heal port allocations

* <https://review.openstack.org/624335>
   puppet-tripleo: Initial extraction of the Placement service from Nova

* <https://review.openstack.org/#/q/topic:bug/1821824>
   Nova: bug fix prevent forbidden traits from working as expected

* <https://review.openstack.org/648665>
   Nova: Spec for a new nova virt driver to manage an RSD

* <https://review.openstack.org/#/c/642067/>
   Helm: Allow more generic overrides for nova placement-api

* <https://review.openstack.org/647578>
   Nova: add spec for image metadata prefiltering

* <https://review.openstack.org/609960>
   Support filtering of allocation_candidates by forbidden aggregates

* <https://review.openstack.org/#/q/topic:bp/use-placement-in-tree>
   Enable in_tree allocation candidates from the nova side

* <https://review.openstack.org/650143>
   openstack-ansible: Remove deprecated scheduler filters

* <https://review.openstack.org/625284>
   Cyborg: Initially readme for nova pilot

* <https://review.openstack.org/629142>
   Tempest: Add QoS policies and minimum bandwidth rule client

* <https://review.openstack.org/641994>
   Nova-spec: Re-approve AMD SEV support for Train

* <https://review.openstack.org/648687>
   Nova-spec: Add PENDING vm state

# End

Latency is the mind-killer.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From smooney at redhat.com  Fri Apr  5 12:45:34 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 13:45:34 +0100
Subject: [nova] retire a flavor
In-Reply-To: <0da89995-bcc8-b9fd-d727-32877a7db781@everyware.ch>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
 <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>
 <0da89995-bcc8-b9fd-d727-32877a7db781@everyware.ch>
Message-ID: <bf296f8a606cc6979ea9438aa0ea4f54803b54e6.camel@redhat.com>

On Fri, 2019-04-05 at 14:30 +0200, Florian Engelmann wrote:
> > > 
> > > I think we need some method to retire images and flavors.
> > 
> > Agreed, please report a nova bug for retiring a flavor.
> > 
> > As for retiring an image, I already pointed out there is a story for that:
> > 
> > https://storyboard.openstack.org/#!/story/2004892
> > 
> > But that's not really a nova bug.
> 
> I will create a bug report. I think it is a important feature.
its an api change so it will reuquire a nova spec.
can you file a blueprint instead and then we can write up a small spec
for this later.



From ionut at fleio.com  Fri Apr  5 13:11:12 2019
From: ionut at fleio.com (Ionut Biru)
Date: Fri, 5 Apr 2019 16:11:12 +0300
Subject: fqdn magnum instances
In-Reply-To: <CALE96NBNSoXwLGqAuRcqB9iDdghfR7V-s9CjZpJq2nOSQO9URg@mail.gmail.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
 <932D42A7-B820-4BF2-A08A-799918AF894E@stackhpc.com>
 <CALE96NBFCVHhXPRiRMOiaaB-Gfhf3bOkWjjCTgFf2+iXECk+sw@mail.gmail.com>
 <FE644DAF-4F88-48F6-981A-7304A9C05ABB@stackhpc.com>
 <CALE96NBNSoXwLGqAuRcqB9iDdghfR7V-s9CjZpJq2nOSQO9URg@mail.gmail.com>
Message-ID: <CALE96NDkPK8bN1-2ebzwWNdV3eEUg+2AfbzT1tdFrisfoKMJAw@mail.gmail.com>

It's interesting. With Fedora-atomic, it's working fine but not with coreos
current.

I'll try to work around using fedora-atomic.

On Fri, Apr 5, 2019 at 3:30 PM Ionut Biru <ionut at fleio.com> wrote:

> Hello,
>
> Yes, I can. That's why I think I need the names to have a FQDN.
>
> »» kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml
> pod/init-demo created
> »» kubectl get pod init-demo
> NAME        READY   STATUS            RESTARTS   AGE
> init-demo   0/1     PodInitializing   0          9s
> »» kubectl get pod init-demo
> NAME        READY   STATUS            RESTARTS   AGE
> init-demo   0/1     PodInitializing   0          12s
> »» kubectl get pod init-demo
> NAME        READY   STATUS    RESTARTS   AGE
> init-demo   1/1     Running   0          20s
> »» kubectl exec -it init-demo -- /bin/bash
> Error from server: error dialing backend: dial tcp: lookup
> k8s-cluster-coreos-uddxvspsxcon-minion-0 on 8.8.8.8:53: no such host
>
>
> On Fri, Apr 5, 2019 at 3:08 PM Bharat Kunwar <bharat at stackhpc.com> wrote:
>
>> Can you even deploy a POD?
>>
>> On 5 Apr 2019, at 13:06, Ionut Biru <ionut at fleio.com> wrote:
>>
>> Hello,
>>
>> From my computer, after exporting the config using:
>> openstack coe cluster config id.
>>
>> I'm using helm from my computer because coreos master doesn't have this
>> utility or even  kubectl.
>>
>>
>>
>> On Fri, Apr 5, 2019 at 2:52 PM Bharat Kunwar <bharat at stackhpc.com> wrote:
>>
>>> Where are you running this command?
>>>
>>> On 5 Apr 2019, at 12:44, Ionut Biru <ionut at fleio.com> wrote:
>>>
>>> Hello,
>>>
>>> I was wondering if there is a way to set up the domain for template to
>>> use in order to have a FQDN hostname for all the vms that are part from the
>>> cluster
>>> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but i
>>> want something like
>>> k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net
>>>
>>> I'm trying to resolve this:
>>>
>>> helm install stable/wordpress
>>> Error: forwarding ports: error upgrading connection: error dialing
>>> backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on
>>> 8.8.8.8:53: no such host
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/dc400c6e/attachment.html>

From gr at ham.ie  Fri Apr  5 13:33:37 2019
From: gr at ham.ie (Graham Hayes)
Date: Fri, 5 Apr 2019 14:33:37 +0100
Subject: [nova] retire a flavor
In-Reply-To: <bddf77f3-f61c-a262-20a8-e9c1de2cb4ed@gmail.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <CALaZjRH07fHY-jw+J+VjvDc84ssk4pYxtOG5Lp6SdMphEURBkw@mail.gmail.com>
 <bddf77f3-f61c-a262-20a8-e9c1de2cb4ed@gmail.com>
Message-ID: <2d19e5f4-bd94-ef86-67d4-8058ef741b7f@ham.ie>

On 01/04/2019 17:48, Matt Riedemann wrote:

> Now if you created a server or resized a server with a given flavor, and
> then modified that flavors extra_specs, that won't be reflected back in
> the persisted RequestSpec, but it's probably not a great idea in general
> to modify extra_specs on public flavors which are already being used.
> 

There is a use case for this - if you have heterogeneous compute
environment (e.g. some nodes are set up for pinning, some for standard
overcommit, some for one to one (no over commit, but not pinned)), and
you make a mistake - being able to change the flavor makes fixing the
resultant mess a lot easier - especially if you can update the
RequestSpec to match the new flavor.

Without this (or doing DB surgery), the end result is potentially
resizing all the VMs in a region, which is not always possible (SR-IOV
or really large VMs that can't really be shutdown).

This is generally for provisioning suites that hardcode flavor IDs and
names into deployment templates, but unfortunately there quite a few of
them that still do this, even in newer versions.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/af5abc75/attachment-0001.sig>

From openstack at nemebean.com  Fri Apr  5 13:37:56 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Fri, 5 Apr 2019 08:37:56 -0500
Subject: [keystone][horizon] Integration with GuardianKey
In-Reply-To: <CAFjP4XRvfEBoHitgq1M-HObfOWkb06RkRm2MqhWapVi7bOOL1A@mail.gmail.com>
References: <CAFjP4XRvfEBoHitgq1M-HObfOWkb06RkRm2MqhWapVi7bOOL1A@mail.gmail.com>
Message-ID: <00dbbd1b-b7da-0153-1d4f-e463903c9246@nemebean.com>

Tagging with relevant projects for visibility.

On 3/30/19 3:54 PM, Paulo Angelo wrote:
> Hi all,
> 
> 
> We are trying to integrate OpenStack (Horizon or Keystone) with 
> GuardianKey. However, we have doubts related to the best way to do this 
> and the best point in the code for this integration.
> 
> 
> GuardianKey is a solution to protect systems against authentication 
> attacks. It uses Machine Learning and analyses the user's behavior, 
> threat intelligence and psychometrics (or behavioral biometrics). The 
> protected system (in the concrete case, OpenStack admin interface) must 
> send an event via REST for the GuardianKey on each login attempt. More 
> info at https://guardiankey.io <https://guardiankey.io>.
> 
> The best way to integrate would be on having a hook in the procedure 
> that process the user credentials submission in OpenStack (the script 
> that receives the POST), something such as:
> 
> 
> if(<POST IN AUTH FORM>) {
> 
>   boolean loginFailed =  checkLogin();
> 
>   GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed);
> 
>   boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> 
>   if(GuardianKeyValidation){
> 
>      // Allow access
> 
>   } else {
> 
>      // Deny access
> 
>   }
> 
> }
> 
> 
> Where is the best place to create this integration? Horizon or Keystone? 
> Is there a way to create a hook for this purpose? Should we create an 
> extension?
> 
> 
> Any help is welcome.
> 
> 
> Thank you in advance.
> 
> 
> Best regards,
> 
> 
> Paulo Angelo


From gr at ham.ie  Fri Apr  5 13:40:10 2019
From: gr at ham.ie (Graham Hayes)
Date: Fri, 5 Apr 2019 14:40:10 +0100
Subject: [TC] PTG Lunch Talks
In-Reply-To: <6f749db9-5a0e-2f2c-0d09-83d01de56b1a@openstack.org>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
 <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
 <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>
 <6f749db9-5a0e-2f2c-0d09-83d01de56b1a@openstack.org>
Message-ID: <45fdf02e-a771-bfb8-c95c-b89bce319f57@ham.ie>

On 05/04/2019 08:38, Thierry Carrez wrote:
> Doug Hellmann wrote:
>> I’d love to hear from teams about major work they have planned for Train.
> 
> Also introducing Train goals would be nice.
> 

I think introducing the goals on the Thursday is a good idea - try
and get them out there as much as possible.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/8efcd309/attachment.sig>

From no-reply at openstack.org  Fri Apr  5 14:05:05 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Fri, 05 Apr 2019 14:05:05 -0000
Subject: kolla 8.0.0.0rc1 (stein)
Message-ID: <mailman.523.1554473106.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for kolla for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/kolla/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/kolla/log/?h=stable/stein

Release notes for kolla can be found at:

    https://docs.openstack.org/releasenotes/kolla/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/kolla/+bugs

and tag it *stein-rc-potential* to bring it to the kolla
release crew's attention.



From no-reply at openstack.org  Fri Apr  5 14:12:17 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Fri, 05 Apr 2019 14:12:17 -0000
Subject: kolla-ansible 8.0.0.0rc1 (stein)
Message-ID: <mailman.524.1554473538.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for kolla-ansible for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/kolla-ansible/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/stein

Release notes for kolla-ansible can be found at:

    https://docs.openstack.org/releasenotes/kolla-ansible/

If you find an issue that could be considered release-critical, please
file it at:

    https://bugs.launchpad.net/kolla-ansible/+bugs

and tag it *stein-rc-potential* to bring it to the kolla-ansible
release crew's attention.



From navdeep.uniyal at bristol.ac.uk  Fri Apr  5 08:27:13 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Fri, 5 Apr 2019 08:27:13 +0000
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
 <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>
Message-ID: <AM6PR06MB587900371D996EC881C5281FDE510@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear Hongbin,

Attached are the logs of both the commands.

Thank you,
Regards,
Navdeep

From: Hongbin Lu <hongbin034 at gmail.com>
Sent: 05 April 2019 01:56
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: openstack at lists.openstack.org
Subject: Re: [Zun] Address already belongs to a bound Neutron port Error

Navdeep,

Would you provide the following as well:

* The output of "pip freeze"
* The log of zun-compute (sudo journalctl -u zun-compute > zun-compute.log)

Best regards,
Hongbin

On Thu, Apr 4, 2019 at 9:21 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Hi Hongbin,

Thank you for your reply.
Following are the log errors I am getting:
LogFile:
2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-] Received JSON data {u'Address': u'10.68.48.137', u'Options': {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'}, u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for /IpamDriver.RequestAddress ipam_request_address /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected error happened: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0

Journald:
Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent call last):
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv = self.dispatch_request()
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     return self.view_functions[rule.endpoint](**req.view_args)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 1740, in ipam_request_address
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port, fixed_ip, req_mac_address)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 542, in _update_existing_port
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0


Kind Regards,
Navdeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/50f5cb77/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zun-compute.log
Type: application/octet-stream
Size: 508347 bytes
Desc: zun-compute.log
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/50f5cb77/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pip-freeze.txt
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/50f5cb77/attachment-0001.txt>

From sfinucan at redhat.com  Fri Apr  5 15:26:22 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Fri, 05 Apr 2019 16:26:22 +0100
Subject: [nova] XenProject and XenServer CIs not running
Message-ID: <94a10eecea0faa692f0dc28a17e6f2a12ed39f78.camel@redhat.com>

I've proposed a patch to remove the 'devstack/tempest-dsvm-tempest-xen-
rc' from nova [1]. Matt Riedemann pointed out that this may have been
used by the XenProject or XenServer CIs. However, it appears that these
CIs are not currently running and haven't been in the past 7 days [2].
Could anyone advise if this is a temporary glitch or if the CIs are
offline for the foreseeable future? Similarly, could anyone say if that
file is safe to remove and, if not, what's using it?

Thanks,
Stephen


[1] https://review.openstack.org/650018
[2] http://ciwatch.mmedvede.net/project?project=nova&time=7+days



From sean.mcginnis at gmx.com  Fri Apr  5 16:21:21 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 5 Apr 2019 11:21:21 -0500
Subject: [PTL][release] Final releases for Stein proposed
Message-ID: <20190405162120.GA14461@sm-workstation>

Greetings!

With yesterday's final RC deadline past, I have now proposed a patch for the
final releases for all cycle-with-rc projects for Stein.

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

We would love to have all PTLs provide a +1 on that patch. While not strictly
necessary, it is great to see everyone's acknowledgement of the patch. Plus you
will all get included in the metedata for the final tag, so it makes a great
record.

Thanks!
Sean


From mnaser at vexxhost.com  Fri Apr  5 17:13:00 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Fri, 5 Apr 2019 13:13:00 -0400
Subject: [TC] PTG Lunch Talks
In-Reply-To: <45fdf02e-a771-bfb8-c95c-b89bce319f57@ham.ie>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
 <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
 <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>
 <6f749db9-5a0e-2f2c-0d09-83d01de56b1a@openstack.org>
 <45fdf02e-a771-bfb8-c95c-b89bce319f57@ham.ie>
Message-ID: <CAEs876ghLwKHkg6tCv7YoarcZGWpVZbgVJKGQz+pWFiwxWn3vg@mail.gmail.com>

On Fri, Apr 5, 2019 at 9:43 AM Graham Hayes <gr at ham.ie> wrote:
>
> On 05/04/2019 08:38, Thierry Carrez wrote:
> > Doug Hellmann wrote:
> >> I’d love to hear from teams about major work they have planned for Train.
> >
> > Also introducing Train goals would be nice.
> >
>
> I think introducing the goals on the Thursday is a good idea - try
> and get them out there as much as possible.
>

Indeed, that means we also need to work on flushing out those goals
as soon as possible to have something ready to be presented.

I think the answer here is "Yes".  We might probably do a recap of
last cycle, a bit of words for the upcoming one and talking about
the project goals.

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From smooney at redhat.com  Fri Apr  5 17:31:04 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 18:31:04 +0100
Subject: [nova] retire a flavor
In-Reply-To: <2d19e5f4-bd94-ef86-67d4-8058ef741b7f@ham.ie>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <CALaZjRH07fHY-jw+J+VjvDc84ssk4pYxtOG5Lp6SdMphEURBkw@mail.gmail.com>
 <bddf77f3-f61c-a262-20a8-e9c1de2cb4ed@gmail.com>
 <2d19e5f4-bd94-ef86-67d4-8058ef741b7f@ham.ie>
Message-ID: <5bedab1cc8825de1983278897ef82a3d47ce83a0.camel@redhat.com>

On Fri, 2019-04-05 at 14:33 +0100, Graham Hayes wrote:
> On 01/04/2019 17:48, Matt Riedemann wrote:
> 
> > Now if you created a server or resized a server with a given flavor, and
> > then modified that flavors extra_specs, that won't be reflected back in
> > the persisted RequestSpec, but it's probably not a great idea in general
> > to modify extra_specs on public flavors which are already being used.
> > 
> 
> There is a use case for this - if you have heterogeneous compute
> environment (e.g. some nodes are set up for pinning, some for standard
> overcommit, some for one to one (no over commit, but not pinned)), and
> you make a mistake - being able to change the flavor makes fixing the
> resultant mess a lot easier - especially if you can update the
> RequestSpec to match the new flavor.
there is a problem statemnt certenly
whether that problemstatyme is a valid usecase we shoudl supprot is another matter.

one way to adders this use casue is via flavor validation to prevent you
creating an invalid flavor in the first place.

it is generally not safe to update a flavor on a runnign instance as
that update may invalidate the current placment of the vm or change the comptue context
that is created by change resource usage or even hypervior type depending on the way the
flavor was updated.

i think this problem statement is valid but i dont think its the same as i have a falvor
and i want to retrie it form use.
> 
> Without this (or doing DB surgery), the end result is potentially
> resizing all the VMs in a region, which is not always possible (SR-IOV
> or really large VMs that can't really be shutdown).
> 
> This is generally for provisioning suites that hardcode flavor IDs and
> names into deployment templates, but unfortunately there quite a few of
> them that still do this, even in newer versions.

yes but in the case of a typo or mistake like this the only option that is vaild for existing
is a resize. if the typo was in the extraspecs you can updated them currently however
if i could change that without breaking the world i would much prefer if extra_specs were
imutable as the other flavor atribute are. that will never happen so ill move on but
to update the embded flavor whenever we update the flavor in the api db would effectvly
require us to live with instance that are invalidly placed (you added a constraitn that forced
would have force the sellection of a differnet host aggraget) , have invalide state 
( e.g. you added a numa topology to the flavor or pinning) or would require use to live or cold
migrate the instace to make them comply with the new flavor.

i think that would make thing worse then our currnet state.
we allow operator to change extra_specs because it does make correcting mistakes simpler
but we advise againt it in general as there are sharp edges and there is not simple way
mitigate that.



From colleen at gazlene.net  Fri Apr  5 17:50:06 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 05 Apr 2019 13:50:06 -0400
Subject: [keystone][horizon] Integration with GuardianKey
In-Reply-To: <00dbbd1b-b7da-0153-1d4f-e463903c9246@nemebean.com>
References: <CAFjP4XRvfEBoHitgq1M-HObfOWkb06RkRm2MqhWapVi7bOOL1A@mail.gmail.com>
 <00dbbd1b-b7da-0153-1d4f-e463903c9246@nemebean.com>
Message-ID: <c3c04325-65a5-4aac-812f-59fe0045c332@www.fastmail.com>

On Fri, Apr 5, 2019, at 06:38, Ben Nemec wrote:
> Tagging with relevant projects for visibility.
> 
> On 3/30/19 3:54 PM, Paulo Angelo wrote:
> > Hi all,
> > 
> > 
> > We are trying to integrate OpenStack (Horizon or Keystone) with 
> > GuardianKey. However, we have doubts related to the best way to do this 
> > and the best point in the code for this integration.
> > 
> > 
> > GuardianKey is a solution to protect systems against authentication 
> > attacks. It uses Machine Learning and analyses the user's behavior, 
> > threat intelligence and psychometrics (or behavioral biometrics). The 
> > protected system (in the concrete case, OpenStack admin interface) must 
> > send an event via REST for the GuardianKey on each login attempt. More 
> > info at https://guardiankey.io <https://guardiankey.io>.
> > 
> > The best way to integrate would be on having a hook in the procedure 
> > that process the user credentials submission in OpenStack (the script 
> > that receives the POST), something such as:
> > 
> > 
> > if(<POST IN AUTH FORM>) {
> > 
> >   boolean loginFailed =  checkLogin();
> > 
> >   GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed);
> > 
> >   boolean GuardianKeyValidation = checkGuardianKeyViaREST(event);
> > 
> >   if(GuardianKeyValidation){
> > 
> >      // Allow access
> > 
> >   } else {
> > 
> >      // Deny access
> > 
> >   }
> > 
> > }
> > 
> > 
> > Where is the best place to create this integration? Horizon or Keystone? 
> > Is there a way to create a hook for this purpose? Should we create an 
> > extension?

Keystone would be the best place for this. Horizon is only one way a user can log in to OpenStack, so hooking into Horizon would not cover your attack vector. Keystone has a built-in auditing system specifically for this, using CADF notifications to emit events when a user logs in:

https://docs.openstack.org/keystone/latest/admin/event_notifications.html

All you need to do is create a consumer for those notifications.

Colleen

> > 
> > 
> > Any help is welcome.
> > 
> > 
> > Thank you in advance.
> > 
> > 
> > Best regards,
> > 
> > 
> > Paulo Angelo
> 
>


From mriedemos at gmail.com  Fri Apr  5 18:01:12 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 5 Apr 2019 13:01:12 -0500
Subject: [nova] retire a flavor
In-Reply-To: <bf296f8a606cc6979ea9438aa0ea4f54803b54e6.camel@redhat.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
 <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>
 <0da89995-bcc8-b9fd-d727-32877a7db781@everyware.ch>
 <bf296f8a606cc6979ea9438aa0ea4f54803b54e6.camel@redhat.com>
Message-ID: <1b6c62b0-ee1e-7c6b-878a-39ddf837f9a6@gmail.com>

On 4/5/2019 7:45 AM, Sean Mooney wrote:
> its an api change so it will reuquire a nova spec.
> can you file a blueprint instead and then we can write up a small spec
> for this later.

What are we talking about specifically? We have a method for retiring 
flavors, you can make them private or delete them. I wasn't suggesting 
we should add the ability to change the flavor.disabled value in the API 
which would require a spec. I was asking Florian to report a nova bug 
about the lack of documentation for how to retire a flavor, that's all.

-- 

Thanks,

Matt


From hongbin034 at gmail.com  Fri Apr  5 18:01:10 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Fri, 5 Apr 2019 14:01:10 -0400
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <AM6PR06MB587900371D996EC881C5281FDE510@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
 <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>
 <AM6PR06MB587900371D996EC881C5281FDE510@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+RmnPfUuadbM+j4VKLcPjuTdH2B8zYLRyprLt=R08Ur7w@mail.gmail.com>

According to the pip freeze output, you have installed newer version of
zun, not the rocky version, and you are using rocky version of kuryr
libnetwork, which explained why you have this error. Would you look into
this issue further? Let us know if anything we can help.

On Fri., Apr. 5, 2019, 4:27 a.m. Navdeep Uniyal <
navdeep.uniyal at bristol.ac.uk> wrote:

> Dear Hongbin,
>
> Attached are the logs of both the commands.
>
> Thank you,
> Regards,
>
> Navdeep
>
>
>
> *From:* Hongbin Lu <hongbin034 at gmail.com>
> *Sent:* 05 April 2019 01:56
> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error
>
>
>
> Navdeep,
>
>
>
> Would you provide the following as well:
>
>
>
> * The output of "pip freeze"
>
> * The log of zun-compute (sudo journalctl -u zun-compute >
> zun-compute.log)
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> On Thu, Apr 4, 2019 at 9:21 AM Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
> Hi Hongbin,
>
> Thank you for your reply.
> Following are the log errors I am getting:
>
> LogFile:
> 2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019
> 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
>
> 2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-]
> Received JSON data {u'Address': u'10.68.48.137', u'Options':
> {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'},
> u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for
> /IpamDriver.RequestAddress ipam_request_address
> /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
>
> 2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected
> error happened: Requested ip address {'subnet_id':
> u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'}
> already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip
> address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
> Journald:
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent
> call last):
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in
> full_dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv =
> self.dispatch_request()
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in
> dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     return
> self.view_functions[rule.endpoint](**req.view_args)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 1740, in ipam_request_address
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port,
> fixed_ip, req_mac_address)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 542, in _update_existing_port
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException:
> Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
>
>
> Kind Regards,
>
> Navdeep
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/716be965/attachment-0001.html>

From openstack at fried.cc  Fri Apr  5 18:23:57 2019
From: openstack at fried.cc (Eric Fried)
Date: Fri, 5 Apr 2019 13:23:57 -0500
Subject: [nova] Train Runways Etherpad Is Live!
Message-ID: <94b6aad2-fe3a-3214-cc39-b29dc0192b82@fried.cc>

Nova contributors and reviewers-

I have seeded the runways etherpad for Train [1] (by copying from the
Stein version [2]).

As of this writing, I see six approved Train blueprints [3]. If you own
one of these, and your code is ready, please register it in the Queue
section of the etherpad and alert us in #openstack-nova.

Thanks,
efried

[1] https://etherpad.openstack.org/p/nova-runways-train
[2] https://etherpad.openstack.org/p/nova-runways-stein
[3] https://blueprints.launchpad.net/nova/train


From smooney at redhat.com  Fri Apr  5 19:15:25 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 20:15:25 +0100
Subject: [nova] retire a flavor
In-Reply-To: <1b6c62b0-ee1e-7c6b-878a-39ddf837f9a6@gmail.com>
References: <f3b56e58-631c-0c04-c7e8-0ff063263999@everyware.ch>
 <d813a39b-c635-a0d6-ecb9-10b231da1e2c@fried.cc>
 <fcfd8261623674e05efbbb7a7466c22aed81597d.camel@redhat.com>
 <33137296-6ae3-3f6d-43bf-35b3d52e1a6a@everyware.ch>
 <9ec4da4a-e2d0-4241-29e7-1c87551acb10@gmail.com>
 <0da89995-bcc8-b9fd-d727-32877a7db781@everyware.ch>
 <bf296f8a606cc6979ea9438aa0ea4f54803b54e6.camel@redhat.com>
 <1b6c62b0-ee1e-7c6b-878a-39ddf837f9a6@gmail.com>
Message-ID: <4c099b68df3e55f235bbc34fe8f2b86650c9b1b6.camel@redhat.com>

On Fri, 2019-04-05 at 13:01 -0500, Matt Riedemann wrote:
> On 4/5/2019 7:45 AM, Sean Mooney wrote:
> > its an api change so it will reuquire a nova spec.
> > can you file a blueprint instead and then we can write up a small spec
> > for this later.
> 
> What are we talking about specifically? We have a method for retiring 
> flavors, you can make them private or delete them. I wasn't suggesting 
> we should add the ability to change the flavor.disabled value in the API 
> which would require a spec. I was asking Florian to report a nova bug 
> about the lack of documentation for how to retire a flavor, that's all.
ya i think that makes sense. we shoudl have a bug for the documention gap.

the blueprint reply was to http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004624.html
my assertion that there should be a blueprint and not a bug was because that would be an api change.
although i might have replied to the wrong email.
florain sent 2 emails back to back

i think the existing mechanism we have are likely sufficient provided we document how to use
them so a bug as you suggested will be enough.
> 



From ekcs.openstack at gmail.com  Fri Apr  5 19:27:53 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Fri, 5 Apr 2019 12:27:53 -0700
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <9dbad6413f5018608ad312663edd5687b537aaca.camel@redhat.com>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
 <D8CBD0AE.C3B1F%ekcs.openstack@gmail.com>
 <9dbad6413f5018608ad312663edd5687b537aaca.camel@redhat.com>
Message-ID: <CAOakLUPmkCd6MXE604aMX8-ZpdAhmymYhHbMkG6QNkQ+OmZBNA@mail.gmail.com>

On Fri, Apr 5, 2019 at 2:59 AM Sean Mooney <smooney at redhat.com> wrote:
>
> On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
> > On 4/4/19, 1:51 PM, "Matthew Thode" <mthode at mthode.org> wrote:
> >
> > > On 19-04-04 14:30:51, Eric K wrote:
> > > > Requesting exception to lower a requirement to resolve a packaging
> > > > issue.
> > > >
> > > > https://review.openstack.org/#/c/650100/
> > > >
> > >
> > > This is more of a stable question, it's late in the cycle but it sounds
> > > possibly needed.  I think this is fine technically, but not sure about
> > > it policy wise.  To me it sounds more of CentOS's problem than
> > > Openstack's (to be a bit brash).  Added the stable tag to the thread.
> > >
> > > --
> > > Matthew Thode
> >
> > Thanks Matthew. I'm not so worried about stability because even if it
> > breaks
> > Something it affects only a new (Stein) experimental feature no one is
> > relying on.
> congresses lower constraints job
> https://github.com/openstack/congress/blob/master/tox.ini#L103-L108
>
> is broken the same way as novas was because of the install command that is used
> https://github.com/openstack/congress/blob/master/tox.ini#L9
>
> so https://review.openstack.org/#/c/650100/
> sets the lower constatit to something that is invalid for the gate job
> which runs on ubuntu. if you look at the output of the job
> http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/13666ba/tox/lower-constraints-1.log
>
> we can see its using psycopg2
> Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt (line
> 81))
>   Downloading
> http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa3323de46a5cc2745aeb4c9db11352ca905d3a15c53b6a816/psycopg2-2.7.7-cp36-cp36m-manylinux1_x86_64.whl
>  (2.7MB)
>
> it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job cannot be
> fixed.
>
> pep-0508 defines a set of markers we can use for packageing
> https://www.python.org/dev/peps/pep-0508/
>
> the only marker that i know of that contains the disto name is "platform_version"
>
> we should be able to do something like
>
> psycopg2==2.5.1; platform_version~=CENTOS
> psycopg2==2.7;
>
> but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build the
> centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions is
> not relevent unless i have missed something.
> >
> >
> >
Thank you, Sean. Sorry I'm ignorant re: the lower constraints job.
Where can we look-up what the valid lower-constraints are?

Specifically, I looked at another earlier patch without the change to
psycopg2 version (lower constraint 2.7) but there also it installed
2.7.7.
http://logs.openstack.org/63/649763/4/check/openstack-tox-lower-constraints/8eb07bd/tox/lower-constraints-1.log
https://review.openstack.org/#/c/649763/

Does that mean psycopg2==2.7 is also invalid?


From colleen at gazlene.net  Fri Apr  5 19:32:34 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 05 Apr 2019 15:32:34 -0400
Subject: [dev][keystone] Keystone Team Update - Week of 1 April 2019
Message-ID: <d1a8cee7-c9dd-4da0-91fb-dc7a6fc50703@www.fastmail.com>

# Keystone Team Update - Week of 1 April 2019

## News

### RC2 and Stein Release

We landed everything we had planned for RC2 and released it this week[1]. The final release is scheduled for next week[2].

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004526.html
[2] https://review.openstack.org/650362

### Train Planning

In advance of the PTG, I've started prepping keystone specs we already know we want to work on in Train[3] and started the Train Roadmap Trello board[4]. Please take a look at both to refresh your memory on what we had planned but didn't finish in past cycles so that we can discuss what to keep and what to scrap for this cycle. We should also talk about our specs backlog[5] and prune it if there are specs that are no longer relevant.

[3] https://review.openstack.org/650126
[4] https://trello.com/b/ClKW9C8x/keystone-train-roadmap
[5] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/

### PTG Planning

I've proposed a rough agenda for the PTG[6]. Since our schedule doesn't start until Thursday afternoon, we won't formally meet Thursday morning but we will have time to meet with the QA team and Edge groups who are having sessions at that time. Thursday afternoon we will meet and recap the Forum sessions and decide if we want to change the agenda schedule meetings with other teams.

[6] https://etherpad.openstack.org/p/keystone-train-ptg

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 18 changes this week, which included everything we had planned for RC2.

## Changes that need Attention

Search query: https://bit.ly/2tymTje

There are 40 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots.

## Bugs

This week we opened 1 new bug and closed 2.

Bugs opened (1) 
Bug #1823258 (keystone:Undecided) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1823258 

Bugs fixed (2) 
Bug #1808859 (keystone:High) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1808859 
Bug #1801873 (keystone:Medium) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1801873

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

The final release for Stein was proposed today[7] and the actual release will take place next week.

[7] https://review.openstack.org/650362

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter


From gmann at ghanshyammann.com  Fri Apr  5 19:54:16 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 05 Apr 2019 14:54:16 -0500
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing migration
 to Bionic (Ubuntu LTS 18.04)
Message-ID: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>

Hello Everyone,

We have all patches merged now for legacy job migration to bionic. 

All the legacy and zuulv3 native jobs are running on Bionic in stable/stein onwards. This means we
have completed our stein testing runtime[1] in OpenStack as a whole.

Thanks a lot to all of the teams for such nice coordination. 

Summary:
- Started this migration very late in stein (in Dec 2018)
- FInished migration in 2 part. 1. zuulv3 native job migration, 2. legacy jobs migration.
- networking-midonet bionic jobs are n-v as it is not yet ready on bionic.
- ~50 patches merged to migrate the gate jobs
- ~ 60 DNM testing patches done before migration happens
- We managed no big gate break for any project. Except for Cinder which was for 1 day I think.

Ref:
- https://review.openstack.org/#/q/(topic:legacy-job-bionic+OR+topic:legacy-job-bionic-done) 
- https://review.openstack.org/#/q/topic:devstack-bionic
- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004268.html
- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003598.html
- https://etherpad.openstack.org/p/legacy-job-bionic
- http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837.html 
- https://etherpad.openstack.org/p/devstack-bionic


[1] https://governance.openstack.org/tc/reference/runtimes/stein.html

 -gmann



From mriedemos at gmail.com  Fri Apr  5 20:26:36 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 5 Apr 2019 15:26:36 -0500
Subject: [nova] XenProject and XenServer CIs not running
In-Reply-To: <94a10eecea0faa692f0dc28a17e6f2a12ed39f78.camel@redhat.com>
References: <94a10eecea0faa692f0dc28a17e6f2a12ed39f78.camel@redhat.com>
Message-ID: <aefae417-b120-1556-124e-b11df3326c83@gmail.com>

On 4/5/2019 10:26 AM, Stephen Finucane wrote:
> I've proposed a patch to remove the 'devstack/tempest-dsvm-tempest-xen-
> rc' from nova [1]. Matt Riedemann pointed out that this may have been
> used by the XenProject or XenServer CIs. However, it appears that these
> CIs are not currently running and haven't been in the past 7 days [2].
> Could anyone advise if this is a temporary glitch or if the CIs are
> offline for the foreseeable future? Similarly, could anyone say if that
> file is safe to remove and, if not, what's using it?
> 
> Thanks,
> Stephen
> 
> 
> [1]https://review.openstack.org/650018
> [2]http://ciwatch.mmedvede.net/project?project=nova&time=7+days

+openstack-ci at xenproject.org

-- 

Thanks,

Matt


From smooney at redhat.com  Fri Apr  5 21:27:09 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 22:27:09 +0100
Subject: [requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
In-Reply-To: <CAOakLUPmkCd6MXE604aMX8-ZpdAhmymYhHbMkG6QNkQ+OmZBNA@mail.gmail.com>
References: <D8CBC59B.C3B04%ekcs.openstack@gmail.com>
 <20190404215100.q423citnpfjuiro3@mthode.org>
 <D8CBD0AE.C3B1F%ekcs.openstack@gmail.com>
 <9dbad6413f5018608ad312663edd5687b537aaca.camel@redhat.com>
 <CAOakLUPmkCd6MXE604aMX8-ZpdAhmymYhHbMkG6QNkQ+OmZBNA@mail.gmail.com>
Message-ID: <4fc8b87f458c2691057332698feb4bcb5ebf8a15.camel@redhat.com>

On Fri, 2019-04-05 at 12:27 -0700, Eric K wrote:
> On Fri, Apr 5, 2019 at 2:59 AM Sean Mooney <smooney at redhat.com> wrote:
> > 
> > On Thu, 2019-04-04 at 15:20 -0800, Eric K wrote:
> > > On 4/4/19, 1:51 PM, "Matthew Thode" <mthode at mthode.org> wrote:
> > > 
> > > > On 19-04-04 14:30:51, Eric K wrote:
> > > > > Requesting exception to lower a requirement to resolve a packaging
> > > > > issue.
> > > > > 
> > > > > https://review.openstack.org/#/c/650100/
> > > > > 
> > > > 
> > > > This is more of a stable question, it's late in the cycle but it sounds
> > > > possibly needed.  I think this is fine technically, but not sure about
> > > > it policy wise.  To me it sounds more of CentOS's problem than
> > > > Openstack's (to be a bit brash).  Added the stable tag to the thread.
> > > > 
> > > > --
> > > > Matthew Thode
> > > 
> > > Thanks Matthew. I'm not so worried about stability because even if it
> > > breaks
> > > Something it affects only a new (Stein) experimental feature no one is
> > > relying on.
> > 
> > congresses lower constraints job
> > https://github.com/openstack/congress/blob/master/tox.ini#L103-L108
> > 
> > is broken the same way as novas was because of the install command that is used
> > https://github.com/openstack/congress/blob/master/tox.ini#L9
> > 
> > so https://review.openstack.org/#/c/650100/
> > sets the lower constatit to something that is invalid for the gate job
> > which runs on ubuntu. if you look at the output of the job
> > http://logs.openstack.org/00/650100/1/check/openstack-tox-lower-constraints/13666ba/tox/lower-constraints-1.log
> > 
> > we can see its using psycopg2
> > Collecting psycopg2===2.7.7 (from -c /home/zuul/src/git.openstack.org/openstack/requirements/upper-constraints.txt
> > (line
> > 81))
> >   Downloading
> > 
http://mirror.ord.rax.openstack.org/pypifiles/packages/37/25/53e8398975aa3323de46a5cc2745aeb4c9db11352ca905d3a15c53b6a816/psycopg2-2.7.7-cp36-cp36m-manylinux1_x86_64.whl
> >  (2.7MB)
> > 
> > it is technically true that psycopg2==2.5.1 will work on centos but until this is restored to 2.7 the gate job
> > cannot be
> > fixed.
> > 
> > pep-0508 defines a set of markers we can use for packageing
> > https://www.python.org/dev/peps/pep-0508/
> > 
> > the only marker that i know of that contains the disto name is "platform_version"
> > 
> > we should be able to do something like
> > 
> > psycopg2==2.5.1; platform_version~=CENTOS
> > psycopg2==2.7;
> > 
> > but i dont think we should be breaking one distor to fix another when the lower constatint.txt wont be used to build
> > the
> > centos packages anyway lower-constiatns will only be used when installing from pip in which case the distro versions
> > is
> > not relevent unless i have missed something.
> > > 
> > > 
> > > 
> 
> Thank you, Sean. Sorry I'm ignorant re: the lower constraints job.
> Where can we look-up what the valid lower-constraints are?
> 
> Specifically, I looked at another earlier patch without the change to
> psycopg2 version (lower constraint 2.7) but there also it installed
> 2.7.7.
> http://logs.openstack.org/63/649763/4/check/openstack-tox-lower-constraints/8eb07bd/tox/lower-constraints-1.log
> https://review.openstack.org/#/c/649763/
> 
> Does that mean psycopg2==2.7 is also invalid?
that is a good question. i belive 2.7 shoudl work however when i fixed the lower-constraints evn
in https://review.openstack.org/#/c/650441/ i got test failures related to psycopg2 locally.
the lower constraints tox env and therefor the gate job has been broken since it was created
so you cannot trust any of the lower constraints are correct until we test with them.

i have also used docker to try and run the test under centos
basically by running
sudo docker run --rm -itu root  -v $(pwd):/data centos/python-36-centos7 bash
then pip installing tox and runnign the lower-constraints job
tox -e lower-constraints -r -v

it also fails on centos but for differnt reasons then i was seeign with a ubunut based host.

> 



From anlin.kong at gmail.com  Fri Apr  5 21:39:41 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Sat, 6 Apr 2019 10:39:41 +1300
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing
 migration to Bionic (Ubuntu LTS 18.04)
In-Reply-To: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
References: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
Message-ID: <CALjNAZ2F6FB_7ntcSh9-OyDxrSppBAgtxQF9zkPd89GfpJ_oQQ@mail.gmail.com>

Thanks for driving this Ghanshyam

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Sat, Apr 6, 2019 at 8:57 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> Hello Everyone,
>
> We have all patches merged now for legacy job migration to bionic.
>
> All the legacy and zuulv3 native jobs are running on Bionic in
> stable/stein onwards. This means we
> have completed our stein testing runtime[1] in OpenStack as a whole.
>
> Thanks a lot to all of the teams for such nice coordination.
>
> Summary:
> - Started this migration very late in stein (in Dec 2018)
> - FInished migration in 2 part. 1. zuulv3 native job migration, 2. legacy
> jobs migration.
> - networking-midonet bionic jobs are n-v as it is not yet ready on bionic.
> - ~50 patches merged to migrate the gate jobs
> - ~ 60 DNM testing patches done before migration happens
> - We managed no big gate break for any project. Except for Cinder which
> was for 1 day I think.
>
> Ref:
> -
> https://review.openstack.org/#/q/(topic:legacy-job-bionic+OR+topic:legacy-job-bionic-done)
> - https://review.openstack.org/#/q/topic:devstack-bionic
> -
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004268.html
> -
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003598.html
> - https://etherpad.openstack.org/p/legacy-job-bionic
> -
> http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837.html
> - https://etherpad.openstack.org/p/devstack-bionic
>
>
> [1] https://governance.openstack.org/tc/reference/runtimes/stein.html
>
>  -gmann
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/d332d7ba/attachment.html>

From zigo at debian.org  Fri Apr  5 22:06:34 2019
From: zigo at debian.org (Thomas Goirand)
Date: Sat, 6 Apr 2019 00:06:34 +0200
Subject: [all] Removing privacy breaches in doc
Message-ID: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>

Hi,

In may docs, I can see stuff like this, especially in README.rst:

.. image:: http://governance.openstack.org/badges/something.svg
    :target: http://governance.openstack.org/reference/tags/index.html

I'd like to let everyone know that, from a package maintainer
perspective, and considering that we do package your Sphinx doc in
distros, this is an annoyance. Indeed, I do feel like I must patch it
out and remove the external source.

The reason is, as a Debian user, I do not expect my browser to do
external queries to a website when I'm browsing a local documentation.
This one is on openstack.org, it's mildly ok-ish, though, I'm removing
the image still. There's other more annoying stuff (think: travis,
github, and other spies which we don't control).

So, it'd be nice if these images with external resources were completely
avoided in OpenStack docs. Either by simply not putting such useless
image, replacing it by text only, or by embedding the image itself in
the doc (or in openstackdocstheme? I suspect that's not what people
want, they want it to be displayed in github... so embedding would be
the only solution).

Cheers,

Thomas Goirand (zigo)


From mriedemos at gmail.com  Fri Apr  5 22:15:36 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 5 Apr 2019 17:15:36 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended Maintenance
 phase
In-Reply-To: <20190404201557.GA6952@sm-workstation>
References: <20190404201557.GA6952@sm-workstation>
Message-ID: <ad6511bb-27c7-7b3a-183e-13b3a441ed05@gmail.com>

On 4/4/2019 3:15 PM, Sean McGinnis wrote:
> We are actually overdue for Pike to have entered extended maintenance.
> According to the stable policy, that should happen 18 months after the release
> [0]. That means we should have made the switch in February, if my math is
> right.
> 
> We will need to work through the details to actually put that in effect, but
> for now I wanted to remind teams that we do not do releases after a stable
> branch enters this phase. So this is a call for action for any teams that have
> been backporting fixes that time is short to get a final release out while you
> can.

For nova at least we have some stable/pike backports that are held up on 
getting fixes merged on newer branches even up through stable/stein so 
I've been waiting on stable/stein to open up after the GA (next week?) 
before making another review push.

-- 

Thanks,

Matt


From miguel at mlavalle.com  Fri Apr  5 22:21:33 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Fri, 5 Apr 2019 17:21:33 -0500
Subject: [telemetry] how does one can participate in the telemetry planning
 for train?
Message-ID: <CAEzGLDi4FWa4GzCumUXZz92RD3wBSKY7JvU6=LpbDXW5RyJFFQ@mail.gmail.com>

Hi Telemetry Team,

Some of my co-workers are interested in participating in the up-coming
telemetry planning for Train (
https://etherpad.openstack.org/p/telemetry-train). How can we get the url
of the Google hangout?

Best regards

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/63337b22/attachment.html>

From smooney at redhat.com  Fri Apr  5 22:35:38 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 05 Apr 2019 23:35:38 +0100
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
Message-ID: <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>

On Sat, 2019-04-06 at 00:06 +0200, Thomas Goirand wrote:
> Hi,
> 
> In may docs, I can see stuff like this, especially in README.rst:
> 
> .. image:: http://governance.openstack.org/badges/something.svg
>     :target: http://governance.openstack.org/reference/tags/index.html
> 
> I'd like to let everyone know that, from a package maintainer
> perspective, and considering that we do package your Sphinx doc in
> distros, this is an annoyance. Indeed, I do feel like I must patch it
> out and remove the external source.
> 
> The reason is, as a Debian user, I do not expect my browser to do
> external queries to a website when I'm browsing a local documentation.
> This one is on openstack.org, it's mildly ok-ish, though, I'm removing
> the image still. There's other more annoying stuff (think: travis,
> github, and other spies which we don't control).
> 
> So, it'd be nice if these images with external resources were completely
> avoided in OpenStack docs. Either by simply not putting such useless
> image, replacing it by text only, or by embedding the image itself in
> the doc (or in openstackdocstheme? I suspect that's not what people
> want, they want it to be displayed in github... so embedding would be
> the only solution).
am we could do this but they do not exist to spy on people.
the are there to let people know that a project is maintained and follows
different aspect of the governace policys.
such as is it vulnerablity managed or suppors-upgrades.

i undersand the concern but the reason we follow the current linking approch instead
of embeding is allow them to be centrally managed in a singel repo.

perhaps we can figure out how to automtically staticaly embed them some how so that
when sphinx build executes it embdes a local copy in the html?

i dont think these image are useless as they do provide relevent info to users of
the respecitve project although ill admit i had assumed these tags actully were not
a singel image but were added one by one.

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 



From zigo at debian.org  Fri Apr  5 23:14:45 2019
From: zigo at debian.org (Thomas Goirand)
Date: Sat, 6 Apr 2019 01:14:45 +0200
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
Message-ID: <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>

On 4/6/19 12:35 AM, Sean Mooney wrote:
> perhaps we can figure out how to automtically staticaly embed them some how so that
> when sphinx build executes it embdes a local copy in the html?

That'd be nice indeed.

> i dont think these image are useless as they do provide relevent info to users of
> the respecitve project

I agree, and that's also why it bothers me each time I patch them out.

Cheers,

Thomas Goirand (zigo)

P.S: No need to Cc me, I'm subscribed! :)


From bcafarel at redhat.com  Fri Apr  5 23:18:00 2019
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Sat, 6 Apr 2019 01:18:00 +0200
Subject: [PTL][release][stable] Pike transitioning to Extended Maintenance
 phase
In-Reply-To: <20190404201557.GA6952@sm-workstation>
References: <20190404201557.GA6952@sm-workstation>
Message-ID: <CABHdKwroqM0N99VNVfqqY1cJevz3jTCoC0x3edLDRyu0mJN9=Q@mail.gmail.com>

On Thu, 4 Apr 2019 at 22:17, Sean McGinnis <sean.mcginnis at gmx.com> wrote:

> Hey everyone,
>
> Thought I should get this out there to make sure folks are aware.
>
> We are actually overdue for Pike to have entered extended maintenance.
> According to the stable policy, that should happen 18 months after the
> release
> [0]. That means we should have made the switch in February, if my math is
> right.
>
> We will need to work through the details to actually put that in effect,
> but
> for now I wanted to remind teams that we do not do releases after a stable
> branch enters this phase. So this is a call for action for any teams that
> have
> been backporting fixes that time is short to get a final release out while
> you
> can.
>

For neutron, we have quite a few fixes queued in for a final release (and a
few in gates right now), I will check with team next week to get that
release out.


-- 
Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/27c0424f/attachment.html>

From giorgis at acmac.uoc.gr  Fri Apr  5 23:32:26 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Sat, 06 Apr 2019 02:32:26 +0300
Subject: [ec2api] SSL Problem
Message-ID: <52ea671f7351334e37258b27d0c2ed24@acmac.uoc.gr>

 Dear all,

 I am trying to setup ec2-api with SSL support on Rocky and no matter 
 what I do I am getting the following error in the logs 
 (/var/log/messages)

 ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure 
 (_ssl.c:1822)

 and in the end

 ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did 
 not return a certificate (_ssl.c:1822)

 The full trace can be found here: https://pastebin.com/iPHXudag (where 
 I have hidden the hostname)

 What I have done is that in "ec2api.conf" I have set the ca_file, 
 cert_file and key_file pointing to the same files that Openstack's 
 Dashboard is using which can be accessed without a problem.

 Afterwards I have restarted all ec2 services meaning both the 
 "openstack-ec2-api-metadata.service" and "openstack-ec2-api.service".
 
 Using openssl cli and trying to connect to port 8788 I am seeing 
 somewhere in the middle the error:
 SSL_connect:SSLv3 write client key exchange A write to 0x26c3e30 
 [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in 
 SSLv3 write finished A
 SSL_connect:error in SSLv3 write finished A
 write:errno=32

 The same openssl cli for port 443 (dashboard) works out of the box 
 without a problem

 Obviously the cert is not served properly but cannot figure out why...

 Needless to say that I have tripled checked for any spelling mistakes, 
 permissions etc. but I am open to suggestions.

 I have set ec2api to "Debug" mode but there isn't anything useful in 
 the logs and in fact is not writing anything except a line like the one 
 below when trying to access it:

 2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-] (211954) 
 accepted ('xxx.xxx.xxx.xxx', 60154) server 
 /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883

 Can someone shed some light please?

 If there is anything that you would like me to share with you like the 
 openssl CLI's output or the ec2api.log please let me know.

 Best regards,

 G.


From chris at openstack.org  Sat Apr  6 01:03:58 2019
From: chris at openstack.org (Chris Hoge)
Date: Fri, 5 Apr 2019 20:03:58 -0500
Subject: [zun][k8s][tc] OpenStack Zun become the official provider for
 Virtual Kubelet
In-Reply-To: <CAFNUc+RpsCUP=jxLgkFq4kvq5fysz6+qxns2aKMSuDwrU5SLMg@mail.gmail.com>
References: <CAFNUc+RFD=CneStwa6cwUv10P5a6g7rO82gEkaTtjr9P2kTXGg@mail.gmail.com>
 <CAEs876giQq0f=UuyhTjtmeKeHDNvyZxc531p5Rg-Ba1vL2s4_w@mail.gmail.com>
 <CAFNUc+RpsCUP=jxLgkFq4kvq5fysz6+qxns2aKMSuDwrU5SLMg@mail.gmail.com>
Message-ID: <6CF3F14C-35CC-480B-9FFB-871850981D65@openstack.org>

Can we have Zun added to the official list of providers?

https://github.com/virtual-kubelet/virtual-kubelet/blob/master/website/data/providers.yaml

This will display Zun amongst the other providers on the Virtual Kubelet home page.

https://virtual-kubelet.io/

Congratulations and great work!

> On Mar 29, 2019, at 5:17 PM, Hongbin Lu <hongbin034 at gmail.com> wrote:
> 
> 
> 
>> On Thu, Mar 28, 2019 at 10:25 PM Mohammed Naser <mnaser at vexxhost.com> wrote:
>> On Thu, Mar 28, 2019 at 10:09 PM Hongbin Lu <hongbin034 at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I have a good news to share. Right now, Zun is officially accepted [1] as OpenStack provider for Virtual Kubelet.
>> >
>> > A brief introduce. Virtual Kubelet is a CNCF sandbox project that allows cloud providers to implement Kubelet equivalent functionality. Existing providers of Virtual Kubelet are AWS Fargate, Azure Container Instance, etc.
>> >
>> > I think it is quite important for OpenStack to have a provider implementation in Virtual Kubelet, which basically makes OpenStack align with what other proprietary cloud providers in this territory.
>> 
>> I agree with this, congrats on the work!
>> 
>> look forward to see this deployed somewhere on our clouds, I think
>> getting Kata integrated with Zun (or something like firecracker) is
>> key for the success of this in a multi tenant environment
> 
> Agree.
> 
> Actually, we have people who were using Zun with Kata in before. Based on what they reported [1], they were able to get Kata working with Zun.
> 
> Technically speaking, Zun is runtime agnostic, so any container runtime (i.e. Kata, runc) should work properly with Zun as long as it can be properly integrated with Docker Engine. If anyone tries Kata with Zun and finds something wrong, please feel free to report a bug: https://bugs.launchpad.net/zun .
> 
> I would definitely encourage Zun team to work closely with Kata team to improve the integration between them.
> 
> [1] https://github.com/kata-containers/runtime/issues/48#issuecomment-379364439
>  
>> 
>> > OpenStack Zun team is committed to enhance and maintain this provider and offer a great k8s integration experience for our users.
>> >
>> > Please feel free to reach out the Zun team if there is any inquiries.
>> >
>> > [1] https://github.com/virtual-kubelet/virtual-kubelet/pull/239
>> >
>> > Best regards,
>> > Hongbin
>> 
>> 
>> 
>> -- 
>> Mohammed Naser — vexxhost
>> -----------------------------------------------------
>> D. 514-316-8872
>> D. 800-910-1726 ext. 200
>> E. mnaser at vexxhost.com
>> W. http://vexxhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/20aae44b/attachment.html>

From mriedemos at gmail.com  Sat Apr  6 01:21:57 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 5 Apr 2019 20:21:57 -0500
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing
 migration to Bionic (Ubuntu LTS 18.04)
In-Reply-To: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
References: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
Message-ID: <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>

On 4/5/2019 2:54 PM, Ghanshyam Mann wrote:
> Thanks a lot to all of the teams for such nice coordination.

I haven't been reading all of the emails but I know you've been really 
busy with this, and it's a thankless job, so I wanted to say thanks for 
working on it for the rest of the community. :)

-- 

Thanks,

Matt


From lbragstad at gmail.com  Sat Apr  6 03:09:37 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Fri, 5 Apr 2019 22:09:37 -0500
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing
 migration to Bionic (Ubuntu LTS 18.04)
In-Reply-To: <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
References: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
 <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
Message-ID: <56b2716f-d5af-d39c-5ada-becd73586b4e@gmail.com>



On 4/5/19 8:21 PM, Matt Riedemann wrote:
> On 4/5/2019 2:54 PM, Ghanshyam Mann wrote:
>> Thanks a lot to all of the teams for such nice coordination.
>
> I haven't been reading all of the emails but I know you've been really
> busy with this, and it's a thankless job, so I wanted to say thanks
> for working on it for the rest of the community. :)

++

I couldn't agree more. Thank you, Ghanshyam.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190405/85701d8f/attachment.sig>

From massimo.sgaravatto at gmail.com  Sat Apr  6 06:52:14 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Sat, 6 Apr 2019 08:52:14 +0200
Subject: [ec2api] SSL Problem
In-Reply-To: <52ea671f7351334e37258b27d0c2ed24@acmac.uoc.gr>
References: <52ea671f7351334e37258b27d0c2ed24@acmac.uoc.gr>
Message-ID: <CALaZjRFrVV5kyG_SLKw0_T07rQtHAgDXzsH3yU98EXd_eNqjVw@mail.gmail.com>

My OpenStack ec2 configuration is a real mess, but ec2 is working with SSL.
I have the following settings concerning SSL:


[DEFAULT]
ssl_ca_file = <cert-file>

[keystone_authtoken]
cafile = <cert-file>

[metadata]
auth_ca_cert = <cert-file>

Very likely they aren't all needed ...



On Sat, Apr 6, 2019 at 1:37 AM Georgios Dimitrakakis <giorgis at acmac.uoc.gr>
wrote:

>  Dear all,
>
>  I am trying to setup ec2-api with SSL support on Rocky and no matter
>  what I do I am getting the following error in the logs
>  (/var/log/messages)
>
>  ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure
>  (_ssl.c:1822)
>
>  and in the end
>
>  ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did
>  not return a certificate (_ssl.c:1822)
>
>  The full trace can be found here: https://pastebin.com/iPHXudag (where
>  I have hidden the hostname)
>
>  What I have done is that in "ec2api.conf" I have set the ca_file,
>  cert_file and key_file pointing to the same files that Openstack's
>  Dashboard is using which can be accessed without a problem.
>
>  Afterwards I have restarted all ec2 services meaning both the
>  "openstack-ec2-api-metadata.service" and "openstack-ec2-api.service".
>
>  Using openssl cli and trying to connect to port 8788 I am seeing
>  somewhere in the middle the error:
>  SSL_connect:SSLv3 write client key exchange A write to 0x26c3e30
>  [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in
>  SSLv3 write finished A
>  SSL_connect:error in SSLv3 write finished A
>  write:errno=32
>
>  The same openssl cli for port 443 (dashboard) works out of the box
>  without a problem
>
>  Obviously the cert is not served properly but cannot figure out why...
>
>  Needless to say that I have tripled checked for any spelling mistakes,
>  permissions etc. but I am open to suggestions.
>
>  I have set ec2api to "Debug" mode but there isn't anything useful in
>  the logs and in fact is not writing anything except a line like the one
>  below when trying to access it:
>
>  2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-] (211954)
>  accepted ('xxx.xxx.xxx.xxx', 60154) server
>  /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883
>
>  Can someone shed some light please?
>
>  If there is anything that you would like me to share with you like the
>  openssl CLI's output or the ec2api.log please let me know.
>
>  Best regards,
>
>  G.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/6f2ed360/attachment.html>

From massimo.sgaravatto at gmail.com  Sat Apr  6 07:04:28 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Sat, 6 Apr 2019 09:04:28 +0200
Subject: [ec2api] SSL Problem
In-Reply-To: <CALaZjRFrVV5kyG_SLKw0_T07rQtHAgDXzsH3yU98EXd_eNqjVw@mail.gmail.com>
References: <52ea671f7351334e37258b27d0c2ed24@acmac.uoc.gr>
 <CALaZjRFrVV5kyG_SLKw0_T07rQtHAgDXzsH3yU98EXd_eNqjVw@mail.gmail.com>
Message-ID: <CALaZjREizrQBMh2TKAfro2UdaD1O_nDK0z-j1jaGLBhJSKPSpw@mail.gmail.com>

But in our setup SSL termination is implemented on a HAproxy node ...

On Sat, Apr 6, 2019 at 8:52 AM Massimo Sgaravatto <
massimo.sgaravatto at gmail.com> wrote:

> My OpenStack ec2 configuration is a real mess, but ec2 is working with
> SSL. I have the following settings concerning SSL:
>
>
> [DEFAULT]
> ssl_ca_file = <cert-file>
>
> [keystone_authtoken]
> cafile = <cert-file>
>
> [metadata]
> auth_ca_cert = <cert-file>
>
> Very likely they aren't all needed ...
>
>
>
> On Sat, Apr 6, 2019 at 1:37 AM Georgios Dimitrakakis <giorgis at acmac.uoc.gr>
> wrote:
>
>>  Dear all,
>>
>>  I am trying to setup ec2-api with SSL support on Rocky and no matter
>>  what I do I am getting the following error in the logs
>>  (/var/log/messages)
>>
>>  ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure
>>  (_ssl.c:1822)
>>
>>  and in the end
>>
>>  ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did
>>  not return a certificate (_ssl.c:1822)
>>
>>  The full trace can be found here: https://pastebin.com/iPHXudag (where
>>  I have hidden the hostname)
>>
>>  What I have done is that in "ec2api.conf" I have set the ca_file,
>>  cert_file and key_file pointing to the same files that Openstack's
>>  Dashboard is using which can be accessed without a problem.
>>
>>  Afterwards I have restarted all ec2 services meaning both the
>>  "openstack-ec2-api-metadata.service" and "openstack-ec2-api.service".
>>
>>  Using openssl cli and trying to connect to port 8788 I am seeing
>>  somewhere in the middle the error:
>>  SSL_connect:SSLv3 write client key exchange A write to 0x26c3e30
>>  [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in
>>  SSLv3 write finished A
>>  SSL_connect:error in SSLv3 write finished A
>>  write:errno=32
>>
>>  The same openssl cli for port 443 (dashboard) works out of the box
>>  without a problem
>>
>>  Obviously the cert is not served properly but cannot figure out why...
>>
>>  Needless to say that I have tripled checked for any spelling mistakes,
>>  permissions etc. but I am open to suggestions.
>>
>>  I have set ec2api to "Debug" mode but there isn't anything useful in
>>  the logs and in fact is not writing anything except a line like the one
>>  below when trying to access it:
>>
>>  2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-] (211954)
>>  accepted ('xxx.xxx.xxx.xxx', 60154) server
>>  /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883
>>
>>  Can someone shed some light please?
>>
>>  If there is anything that you would like me to share with you like the
>>  openssl CLI's output or the ec2api.log please let me know.
>>
>>  Best regards,
>>
>>  G.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/799569c9/attachment.html>

From skaplons at redhat.com  Sat Apr  6 07:37:33 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Sat, 6 Apr 2019 09:37:33 +0200
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing
 migration to Bionic (Ubuntu LTS 18.04)
In-Reply-To: <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
References: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
 <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
Message-ID: <572D681D-FD11-43C1-B9A2-492BB57D120C@redhat.com>

Hi,

> Wiadomość napisana przez Matt Riedemann <mriedemos at gmail.com> w dniu 06.04.2019, o godz. 03:21:
> 
> On 4/5/2019 2:54 PM, Ghanshyam Mann wrote:
>> Thanks a lot to all of the teams for such nice coordination.
> 
> I haven't been reading all of the emails but I know you've been really busy with this, and it's a thankless job, so I wanted to say thanks for working on it for the rest of the community. :)

Exactly. Thanks a lot for driving this.

> 
> -- 
> 
> Thanks,
> 
> Matt
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From sean.mcginnis at gmx.com  Sat Apr  6 09:10:08 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Sat, 6 Apr 2019 04:10:08 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended
 Maintenance phase
In-Reply-To: <ad6511bb-27c7-7b3a-183e-13b3a441ed05@gmail.com>
References: <20190404201557.GA6952@sm-workstation>
 <ad6511bb-27c7-7b3a-183e-13b3a441ed05@gmail.com>
Message-ID: <20190406091008.GA26772@sm-workstation>

On Fri, Apr 05, 2019 at 05:15:36PM -0500, Matt Riedemann wrote:
> On 4/4/2019 3:15 PM, Sean McGinnis wrote:
> > We are actually overdue for Pike to have entered extended maintenance.
> > According to the stable policy, that should happen 18 months after the release
> > [0]. That means we should have made the switch in February, if my math is
> > right.
> >
> > We will need to work through the details to actually put that in effect, but
> > for now I wanted to remind teams that we do not do releases after a stable
> > branch enters this phase. So this is a call for action for any teams that have
> > been backporting fixes that time is short to get a final release out while you
> > can.
>
> For nova at least we have some stable/pike backports that are held up on
> getting fixes merged on newer branches even up through stable/stein so I've
> been waiting on stable/stein to open up after the GA (next week?) before
> making another review push.
>

Backports can happen already to stable/stein. We just would not be able to do a
stable release off of there until next week - April 11 to be precise.



From no-reply at openstack.org  Sat Apr  6 09:52:10 2019
From: no-reply at openstack.org (no-reply at openstack.org)
Date: Sat, 06 Apr 2019 09:52:10 -0000
Subject: octavia 4.0.0.0rc3 (stein)
Message-ID: <mailman.525.1554544331.1561.openstack-discuss@lists.openstack.org>


Hello everyone,

A new release candidate for octavia for the end of the Stein
cycle is available!  You can find the source code tarball at:

    https://tarballs.openstack.org/octavia/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Stein release. You are therefore strongly encouraged
to test and validate this tarball!

Alternatively, you can directly test the stable/stein release
branch at:

    https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein

Release notes for octavia can be found at:

    https://docs.openstack.org/releasenotes/octavia/

If you find an issue that could be considered release-critical, please
file it at:

    https://storyboard.openstack.org/#!/project/908

and tag it *stein-rc-potential* to bring it to the octavia
release crew's attention.



From giorgis at acmac.uoc.gr  Sat Apr  6 12:29:31 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Sat, 06 Apr 2019 15:29:31 +0300
Subject: [ec2api] SSL Problem
In-Reply-To: <CALaZjREizrQBMh2TKAfro2UdaD1O_nDK0z-j1jaGLBhJSKPSpw@mail.gmail.com>
References: <52ea671f7351334e37258b27d0c2ed24@acmac.uoc.gr>
 <CALaZjRFrVV5kyG_SLKw0_T07rQtHAgDXzsH3yU98EXd_eNqjVw@mail.gmail.com>
 <CALaZjREizrQBMh2TKAfro2UdaD1O_nDK0z-j1jaGLBhJSKPSpw@mail.gmail.com>
Message-ID: <e05071564d5d2a95170a28f17421fc99@acmac.uoc.gr>

 Your setup is different than mine since the SSL termination is taking 
 place on HAproxy, so not really EC2 affected.

 Thankfully I have found out the solution.

 In ec2api.conf there is a parameter called "ssl_ca_file" which as 
 described in its explanation is used to verify connecting clients.
 My misunderstanding, probably because of what is required in general 
 and because I didn't read it carefully, was that this will be used for 
 the intermediate certificate when obviously this is not the case.

 So I had to leave this option to "None" (as its default) and fill only 
 the "ssl_cert_file" and "ssl_key_file" parameters. The intermediate 
 certificate has to be bundled (included) though in the "ssl_cert_file" 
 for "awscli" to work.

 To sum up one has to create a "ssl_cert_file" from both his/hers 
 "Signed Certificate" and "Intermediate Certificate".
 Use this in the "ssl_cert_file" parameter and set in the "ssl_key_file" 
 parameter the respective key.
 Leave the "ssl_ca_file" empty and this solves the problem.

 Hope someone finds the above useful.
 I only wish I had read more carefully from the beginning the 
 "ssl_ca_file" description...

 Best regards,

 G.



> But in our setup SSL termination is implemented on a HAproxy node ...
>
> On Sat, Apr 6, 2019 at 8:52 AM Massimo Sgaravatto  wrote:
>
>> My OpenStack ec2 configuration is a real mess, but ec2 is working
>> with SSL. I have the following settings concerning SSL:
>>
>> [DEFAULT]
>> ssl_ca_file =
>>
>> [keystone_authtoken]
>> cafile =
>>
>> [metadata]
>>
>> auth_ca_cert =
>>
>> Very likely they arent all needed ...
>>
>> On Sat, Apr 6, 2019 at 1:37 AM Georgios Dimitrakakis wrote:
>>
>>>  Dear all,
>>>
>>>  I am trying to setup ec2-api with SSL support on Rocky and no
>>> matter
>>>  what I do I am getting the following error in the logs
>>>  (/var/log/messages)
>>>
>>>  ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake
>>> failure
>>>  (_ssl.c:1822)
>>>
>>>  and in the end
>>>
>>>  ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE]
>>> peer did
>>>  not return a certificate (_ssl.c:1822)
>>>
>>>  The full trace can be found here: https://pastebin.com/iPHXudag
>>> [1] (where
>>>  I have hidden the hostname)
>>>
>>>  What I have done is that in "ec2api.conf" I have set the
>>> ca_file,
>>>  cert_file and key_file pointing to the same files that
>>> Openstacks
>>>  Dashboard is using which can be accessed without a problem.
>>>
>>>  Afterwards I have restarted all ec2 services meaning both the
>>>  "openstack-ec2-api-metadata.service" and
>>> "openstack-ec2-api.service".
>>>
>>>  Using openssl cli and trying to connect to port 8788 I am
>>> seeing
>>>  somewhere in the middle the error:
>>>  SSL_connect:SSLv3 write client key exchange A write to
>>> 0x26c3e30
>>>  [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF))
>>> SSL_connect:error in
>>>  SSLv3 write finished A
>>>  SSL_connect:error in SSLv3 write finished A
>>>  write:errno=32
>>>
>>>  The same openssl cli for port 443 (dashboard) works out of the
>>> box
>>>  without a problem
>>>
>>>  Obviously the cert is not served properly but cannot figure out
>>> why...
>>>
>>>  Needless to say that I have tripled checked for any spelling
>>> mistakes,
>>>  permissions etc. but I am open to suggestions.
>>>
>>>  I have set ec2api to "Debug" mode but there isnt anything
>>> useful in
>>>  the logs and in fact is not writing anything except a line like
>>> the one
>>>  below when trying to access it:
>>>
>>>  2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-]
>>> (211954)
>>>  accepted (xxx.xxx.xxx.xxx, 60154) server
>>>  /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883
>>>
>>>  Can someone shed some light please?
>>>
>>>  If there is anything that you would like me to share with you
>>> like the
>>>  openssl CLIs output or the ec2api.log please let me know.
>>>
>>>  Best regards,
>>>
>>>  G.
>
>
> Links:
> ------
> [1] https://pastebin.com/iPHXudag
> [2] mailto:giorgis at acmac.uoc.gr
> [3] mailto:massimo.sgaravatto at gmail.com


From jaypipes at gmail.com  Sat Apr  6 12:59:05 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sat, 6 Apr 2019 08:59:05 -0400
Subject: [tc][ptl][all] Completion Report: OpenStack gate testing
 migration to Bionic (Ubuntu LTS 18.04)
In-Reply-To: <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
References: <169ef10e8a2.ff046173116979.4436505998648350743@ghanshyammann.com>
 <f4fd2b30-7095-98ec-fc6b-2b4af8ef64a9@gmail.com>
Message-ID: <3735118e-47d0-9120-b506-e99cc05cc767@gmail.com>

04/05/2019 09:21 PM, Matt Riedemann wrote:
> On 4/5/2019 2:54 PM, Ghanshyam Mann wrote:
>> Thanks a lot to all of the teams for such nice coordination.
> 
> I haven't been reading all of the emails but I know you've been really 
> busy with this, and it's a thankless job, so I wanted to say thanks for 
> working on it for the rest of the community. :)

Agreed completely. Thank you very much, Ghanshyam!
-jay


From fungi at yuggoth.org  Sat Apr  6 13:12:50 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sat, 6 Apr 2019 13:12:50 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
 <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>
Message-ID: <20190406131250.i5p3dcptlywv3hsz@yuggoth.org>

On 2019-04-06 01:14:45 +0200 (+0200), Thomas Goirand wrote:
> On 4/6/19 12:35 AM, Sean Mooney wrote:
> > perhaps we can figure out how to automtically staticaly embed
> > them some how so that when sphinx build executes it embdes a
> > local copy in the html?
> 
> That'd be nice indeed.
[...]

Well, except then they'd presumably be downloading those images
during the build process, which is similarly problematic, unless the
images can also be packaged in Debian and used as a build-dep.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/d4eeab3b/attachment.sig>

From mordred at inaugust.com  Sat Apr  6 16:16:58 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Sat, 6 Apr 2019 16:16:58 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
Message-ID: <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>



On 4/5/19 10:06 PM, Thomas Goirand wrote:
> Hi,
> 
> In may docs, I can see stuff like this, especially in README.rst:
> 
> .. image:: http://governance.openstack.org/badges/something.svg
>      :target: http://governance.openstack.org/reference/tags/index.html
> 
> I'd like to let everyone know that, from a package maintainer
> perspective, and considering that we do package your Sphinx doc in
> distros, this is an annoyance. Indeed, I do feel like I must patch it
> out and remove the external source.
> 
> The reason is, as a Debian user, I do not expect my browser to do
> external queries to a website when I'm browsing a local documentation.
> This one is on openstack.org, it's mildly ok-ish, though, I'm removing
> the image still. There's other more annoying stuff (think: travis,
> github, and other spies which we don't control).

FWIW - it would be exceptually strange for OpenStack projects to include 
travis or github badges in documentation since we don't use those 
services. Which is to say - for things that aren't governance badges, 
I'd be curious to learn about and erradicate such things.

> So, it'd be nice if these images with external resources were completely
> avoided in OpenStack docs. Either by simply not putting such useless
> image, replacing it by text only, or by embedding the image itself in
> the doc (or in openstackdocstheme? I suspect that's not what people
> want, they want it to be displayed in github... so embedding would be
> the only solution).

opendev.org will now show these too - so I believe they are 'desirable' 
in README files.

Perhaps instead of trying to get rid of them or make things extra harder 
for folks - we could consider ending the practice of doing a sphinx 
include of the README.rst content in the docs. Perhaps we can find a 
good pattern for having a README with badge types of things that 
includes actual content from the docs? I'm not sure how well include 
paths work in the opendev RST renderer - but might be worth exploring. 
Then we could have clean docs and badged READMEs.

Or?


From hongbin034 at gmail.com  Sat Apr  6 19:30:32 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Sat, 6 Apr 2019 15:30:32 -0400
Subject: [zun][k8s][tc] OpenStack Zun become the official provider for
 Virtual Kubelet
In-Reply-To: <6CF3F14C-35CC-480B-9FFB-871850981D65@openstack.org>
References: <CAFNUc+RFD=CneStwa6cwUv10P5a6g7rO82gEkaTtjr9P2kTXGg@mail.gmail.com>
 <CAEs876giQq0f=UuyhTjtmeKeHDNvyZxc531p5Rg-Ba1vL2s4_w@mail.gmail.com>
 <CAFNUc+RpsCUP=jxLgkFq4kvq5fysz6+qxns2aKMSuDwrU5SLMg@mail.gmail.com>
 <6CF3F14C-35CC-480B-9FFB-871850981D65@openstack.org>
Message-ID: <CAFNUc+T-9M5geU56o0XeZ6RWMzSPfZwYXMvJjP7N8dCahH+LUA@mail.gmail.com>

Thanks for pointing that out. I have submitted a PR for that:
https://github.com/virtual-kubelet/virtual-kubelet/pull/570

Best regards,
Hongbin

On Fri, Apr 5, 2019 at 9:04 PM Chris Hoge <chris at openstack.org> wrote:

> Can we have Zun added to the official list of providers?
>
>
> https://github.com/virtual-kubelet/virtual-kubelet/blob/master/website/data/providers.yaml
>
> This will display Zun amongst the other providers on the Virtual Kubelet
> home page.
>
> https://virtual-kubelet.io/
>
> Congratulations and great work!
>
> On Mar 29, 2019, at 5:17 PM, Hongbin Lu <hongbin034 at gmail.com> wrote:
>
>
>
> On Thu, Mar 28, 2019 at 10:25 PM Mohammed Naser <mnaser at vexxhost.com>
> wrote:
>
>> On Thu, Mar 28, 2019 at 10:09 PM Hongbin Lu <hongbin034 at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I have a good news to share. Right now, Zun is officially accepted [1]
>> as OpenStack provider for Virtual Kubelet.
>> >
>> > A brief introduce. Virtual Kubelet is a CNCF sandbox project that
>> allows cloud providers to implement Kubelet equivalent functionality.
>> Existing providers of Virtual Kubelet are AWS Fargate, Azure Container
>> Instance, etc.
>> >
>> > I think it is quite important for OpenStack to have a provider
>> implementation in Virtual Kubelet, which basically makes OpenStack align
>> with what other proprietary cloud providers in this territory.
>>
>> I agree with this, congrats on the work!
>>
>> look forward to see this deployed somewhere on our clouds, I think
>> getting Kata integrated with Zun (or something like firecracker) is
>> key for the success of this in a multi tenant environment
>>
>
> Agree.
>
> Actually, we have people who were using Zun with Kata in before. Based on
> what they reported [1], they were able to get Kata working with Zun.
>
> Technically speaking, Zun is runtime agnostic, so any container runtime
> (i.e. Kata, runc) should work properly with Zun as long as it can be
> properly integrated with Docker Engine. If anyone tries Kata with Zun and
> finds something wrong, please feel free to report a bug:
> https://bugs.launchpad.net/zun .
>
> I would definitely encourage Zun team to work closely with Kata team to
> improve the integration between them.
>
> [1]
> https://github.com/kata-containers/runtime/issues/48#issuecomment-379364439
>
>
>>
>> > OpenStack Zun team is committed to enhance and maintain this provider
>> and offer a great k8s integration experience for our users.
>> >
>> > Please feel free to reach out the Zun team if there is any inquiries.
>> >
>> > [1] https://github.com/virtual-kubelet/virtual-kubelet/pull/239
>> >
>> > Best regards,
>> > Hongbin
>>
>>
>>
>> --
>> Mohammed Naser — vexxhost
>> -----------------------------------------------------
>> D. 514-316-8872
>> D. 800-910-1726 ext. 200
>> E. mnaser at vexxhost.com
>> W. http://vexxhost.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/3546228e/attachment-0001.html>

From mriedemos at gmail.com  Sat Apr  6 19:52:52 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Sat, 6 Apr 2019 14:52:52 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended Maintenance
 phase
In-Reply-To: <20190406091008.GA26772@sm-workstation>
References: <20190404201557.GA6952@sm-workstation>
 <ad6511bb-27c7-7b3a-183e-13b3a441ed05@gmail.com>
 <20190406091008.GA26772@sm-workstation>
Message-ID: <2cd9c88c-5c6c-ee42-b8ea-658484b4426b@gmail.com>

On 4/6/2019 4:10 AM, Sean McGinnis wrote:
> Backports can happen already to stable/stein. We just would not be able to do a
> stable release off of there until next week - April 11 to be precise.

Yeah and we've been doing backports but holding them until the stein GA 
- is it safe to assume we're past any last minute RC issues for stein 
and can start merging stable/stein backports to go into the first 
stable/stein release?

-- 

Thanks,

Matt


From zigo at debian.org  Sat Apr  6 22:01:58 2019
From: zigo at debian.org (Thomas Goirand)
Date: Sun, 7 Apr 2019 00:01:58 +0200
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <20190406131250.i5p3dcptlywv3hsz@yuggoth.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
 <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>
 <20190406131250.i5p3dcptlywv3hsz@yuggoth.org>
Message-ID: <89869bab-44e9-5d12-545d-e615d77b2a7e@debian.org>

On 4/6/19 3:12 PM, Jeremy Stanley wrote:
> On 2019-04-06 01:14:45 +0200 (+0200), Thomas Goirand wrote:
>> On 4/6/19 12:35 AM, Sean Mooney wrote:
>>> perhaps we can figure out how to automtically staticaly embed
>>> them some how so that when sphinx build executes it embdes a
>>> local copy in the html?
>>
>> That'd be nice indeed.
> [...]
> 
> Well, except then they'd presumably be downloading those images
> during the build process, which is similarly problematic, unless the
> images can also be packaged in Debian and used as a build-dep.

Why not having them in openstackdocstheme (or similar)?

Cheers,

Thomas Goirand (zigo)


From navdeep.uniyal at bristol.ac.uk  Sat Apr  6 23:09:30 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Sat, 6 Apr 2019 23:09:30 +0000
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <CAFNUc+RmnPfUuadbM+j4VKLcPjuTdH2B8zYLRyprLt=R08Ur7w@mail.gmail.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
 <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>
 <AM6PR06MB587900371D996EC881C5281FDE510@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RmnPfUuadbM+j4VKLcPjuTdH2B8zYLRyprLt=R08Ur7w@mail.gmail.com>
Message-ID: <AM6PR06MB58799936F6E4043F49A5114ADE520@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear Hongbin,

Thank you for your help and support (highly appreciate it). I am able to resolve the issue as you correctly mentioned, it was due to the version mismatch. I am able to run containers now.

May I ask you to please point me to the right direction for the horizon and heat integration with zun -Rocky (if available).


Kind Regards,
Navdeep

From: Hongbin Lu <hongbin034 at gmail.com>
Sent: 05 April 2019 19:01
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: Openstack <openstack at lists.openstack.org>
Subject: Re: [Zun] Address already belongs to a bound Neutron port Error

According to the pip freeze output, you have installed newer version of zun, not the rocky version, and you are using rocky version of kuryr libnetwork, which explained why you have this error. Would you look into this issue further? Let us know if anything we can help.

On Fri., Apr. 5, 2019, 4:27 a.m. Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Dear Hongbin,

Attached are the logs of both the commands.

Thank you,
Regards,
Navdeep

From: Hongbin Lu <hongbin034 at gmail.com<mailto:hongbin034 at gmail.com>>
Sent: 05 April 2019 01:56
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>>
Cc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Subject: Re: [Zun] Address already belongs to a bound Neutron port Error

Navdeep,

Would you provide the following as well:

* The output of "pip freeze"
* The log of zun-compute (sudo journalctl -u zun-compute > zun-compute.log)

Best regards,
Hongbin

On Thu, Apr 4, 2019 at 9:21 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Hi Hongbin,

Thank you for your reply.
Following are the log errors I am getting:
LogFile:
2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-] Received JSON data {u'Address': u'10.68.48.137', u'Options': {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'}, u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for /IpamDriver.RequestAddress ipam_request_address /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected error happened: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0

Journald:
Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent call last):
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in full_dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv = self.dispatch_request()
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in dispatch_request
Apr 04 13:16:35 bedminster kuryr-server[42324]:     return self.view_functions[rule.endpoint](**req.view_args)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 1740, in ipam_request_address
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port, fixed_ip, req_mac_address)
Apr 04 13:16:35 bedminster kuryr-server[42324]:   File "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py", line 542, in _update_existing_port
Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port: 045ff1a5-d20c-4299-9ffd-9c676af398b0


Kind Regards,
Navdeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/76e2961e/attachment-0001.html>

From fungi at yuggoth.org  Sat Apr  6 23:45:00 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sat, 6 Apr 2019 23:45:00 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <89869bab-44e9-5d12-545d-e615d77b2a7e@debian.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
 <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>
 <20190406131250.i5p3dcptlywv3hsz@yuggoth.org>
 <89869bab-44e9-5d12-545d-e615d77b2a7e@debian.org>
Message-ID: <20190406234459.iyt3lmwayulb5gud@yuggoth.org>

On 2019-04-07 00:01:58 +0200 (+0200), Thomas Goirand wrote:
[...]
> Why not having them in openstackdocstheme (or similar)?

Right now the images are compiled based on data stored in the
openstack/governance repository, so it would probably be simplest if
they were packaged separately (otherwise that data would still need
to be pulled into another codebase somehow).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/ad0ab5a8/attachment.sig>

From hongbin034 at gmail.com  Sun Apr  7 01:05:25 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Sat, 6 Apr 2019 21:05:25 -0400
Subject: [Zun] Address already belongs to a bound Neutron port Error
In-Reply-To: <AM6PR06MB58799936F6E4043F49A5114ADE520@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879CEACD80AC7F614B150D4DE570@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Sp5ZCaH-fMC2tsaMbey-kuVmFpDZ-Vu6uBd6t2WWFLcA@mail.gmail.com>
 <AM6PR06MB5879F82606B1B7F13E3B7F0DDE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RWn8+a+p6aeCeLATLSN9syQZc_KfnbwFkgERdCfGDzCA@mail.gmail.com>
 <AM6PR06MB587987116A5B2A41EF49B9B4DE500@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+TXx0UdJnJRT9Sk5uD-OWFUwJNH8VuKwcQekx00RREwHA@mail.gmail.com>
 <AM6PR06MB587900371D996EC881C5281FDE510@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+RmnPfUuadbM+j4VKLcPjuTdH2B8zYLRyprLt=R08Ur7w@mail.gmail.com>
 <AM6PR06MB58799936F6E4043F49A5114ADE520@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+TX2TLwKBiyk7u2qUDtD40qb6-6MLmoMqb1hq1gp1sKbA@mail.gmail.com>

On Sat, Apr 6, 2019 at 7:09 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Dear Hongbin,
>
> Thank you for your help and support (highly appreciate it). I am able to
> resolve the issue as you correctly mentioned, it was due to the version
> mismatch. I am able to run containers now.
>
> May I ask you to please point me to the right direction for the horizon
> and heat integration with zun -Rocky (if available).
>

For Horizon, here is the document:
https://github.com/openstack/zun-ui#manual-installation . Basically, you
need to install Horizon and enable the Zun dashboard plugin. For Heat, Zun
resources are built-in so you will have it out of the box.


>
>
>
> Kind Regards,
>
> Navdeep
>
>
>
> *From:* Hongbin Lu <hongbin034 at gmail.com>
> *Sent:* 05 April 2019 19:01
> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Cc:* Openstack <openstack at lists.openstack.org>
> *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error
>
>
>
> According to the pip freeze output, you have installed newer version of
> zun, not the rocky version, and you are using rocky version of kuryr
> libnetwork, which explained why you have this error. Would you look into
> this issue further? Let us know if anything we can help.
>
>
>
> On Fri., Apr. 5, 2019, 4:27 a.m. Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
> Dear Hongbin,
>
> Attached are the logs of both the commands.
>
> Thank you,
> Regards,
>
> Navdeep
>
>
>
> *From:* Hongbin Lu <hongbin034 at gmail.com>
> *Sent:* 05 April 2019 01:56
> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error
>
>
>
> Navdeep,
>
>
>
> Would you provide the following as well:
>
>
>
> * The output of "pip freeze"
>
> * The log of zun-compute (sudo journalctl -u zun-compute >
> zun-compute.log)
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> On Thu, Apr 4, 2019 at 9:21 AM Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
> Hi Hongbin,
>
> Thank you for your reply.
> Following are the log errors I am getting:
>
> LogFile:
> 2019-04-04 12:59:04.718 42324 INFO werkzeug [-] 127.0.0.1 - - [04/Apr/2019
> 12:59:04] "POST /IpamDriver.RequestAddress HTTP/1.1" 500 -
>
> 2019-04-04 13:16:34.652 42324 DEBUG kuryr_libnetwork.controllers [-]
> Received JSON data {u'Address': u'10.68.48.137', u'Options':
> {u'com.docker.network.endpoint.macaddress': u'fa:16:3e:20:9d:2c'},
> u'PoolID': u'b130d090-9b7f-4c68-9f45-775a18bbb649'} for
> /IpamDriver.RequestAddress ipam_request_address
> /usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py:1646
>
> 2019-04-04 13:16:35.113 42324 ERROR kuryr_libnetwork.utils [-] Unexpected
> error happened: Requested ip address {'subnet_id':
> u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.137'}
> already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0: AddressInUseException: Requested ip
> address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
> Journald:
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: Traceback (most recent
> call last):
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1813, in
> full_dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     rv =
> self.dispatch_request()
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/lib/python2.7/dist-packages/flask/app.py", line 1799, in
> dispatch_request
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     return
> self.view_functions[rule.endpoint](**req.view_args)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 1740, in ipam_request_address
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port,
> fixed_ip, req_mac_address)
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:   File
> "/usr/local/lib/python2.7/dist-packages/kuryr_libnetwork/controllers.py",
> line 542, in _update_existing_port
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]:     existing_port['id']))
>
> Apr 04 13:16:35 bedminster kuryr-server[42324]: AddressInUseException:
> Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc',
> 'ip_address': u'10.68.48.137'} already belongs to a bound Neutron port:
> 045ff1a5-d20c-4299-9ffd-9c676af398b0
>
>
>
>
>
> Kind Regards,
>
> Navdeep
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190406/88a8dffb/attachment.html>

From ianyrchoi at gmail.com  Sun Apr  7 04:11:51 2019
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Sun, 7 Apr 2019 13:11:51 +0900
Subject: [OpenStack-I18n] Questions about Stein Dashboard UI translations
In-Reply-To: <CALhU9tmyKzHyhHHEu6D1X3u0g-sz1ez-KyX3TT1EwfXmp46zCQ@mail.gmail.com>
References: <CADv2yUaD58sRc7ex6N3=OFFV9D9hKFT7rty_5dNS9Md_zoddTw@mail.gmail.com>
 <bdc3ac06a59fddd2d5e9200413d30e9b@arcor.de>
 <CALhU9tmyKzHyhHHEu6D1X3u0g-sz1ez-KyX3TT1EwfXmp46zCQ@mail.gmail.com>
Message-ID: <6b33942b-c206-b044-e441-ee69a16a5f75@gmail.com>

"Team activities with release" are described in 
https://docs.openstack.org/i18n/latest/release_management.html ,
but let me first try to clarify more on I18n team activites with stable 
versions in Zanata regarding project release activities.

Generally, there are two main reasons creating and maintaining stable 
versions in Zanata:

1. Hard StringFreezes with RC1, RC2, and so on
  : checking translation is much better using stable versions(with 
translation checksite, ideally)
  : That's why creating stable versions in Zanata is encouraged when 
there is first stable-xx branch in project repositories

2. Maintaining translation bugs on stable branches
  : There might be translation bugs on released artifacts - tranlation 
bugs can be fixed by editing stable versions in Zanata, syncing with 
project repos, and releasing new artifacts on target stable branches.
  : Usually, after final real stable artifacts are announced, then 
translations on stable versions from the first part are merged into 
master version for the next release.

For the first part, Ideally, it would be excellent if there are enough 
translation demand, stable version creation activities in Zanata, 
translation activites on stable versions,
communications via I18n-release cross project liaison, and review 
activities through translation checksite, and those are interactive 
together.
If not, then I think I18n team needs to minimize the targets for such 
purpose or think differently how I18n team reacts with final new stable 
version creation.

For the second part, the glad news I wanna share is that now all stable 
versions in Zanata now have content.
More details are described in below:

- Now projects mentioned in 
http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003382.html 
should have "stable-stein" versions in Zanata
   : except "sahara-plugin-*" since there is no translated resource even 
on master version -> I wanna set that those will be synced only for 
master repos.

- Some stable document versions including "keystone, octavia-dashboard, 
trove, watcher" projects were already filled translations from master 
(thanks a lot, Andreas and/or Frank!),
   but a few of them still had releasenotes documents, which need to be 
deleted on stable versions: "murano-dashboard, solum-dashboard, swift, 
trove-dashboard, zaqar, zaqar-ui, zun-ui".

- One zh-CN translator did translations from empty content stable-stein 
version for ironic-ui project. Since the content were actually the same 
as master branch,
   I deleted stable-stein version on ironic-ui project, re-created 
stable-version by copying from master version, and removed releasenotes 
document on stable-stein version.

- Strangely, there are no releasenotes document on master version for 
karbor-dashboard and neutron-lbaas-dashboard projects - need to be 
investigated further.


As Train PTL, I will identify how much translations were for Stein 
release and try to find better ways how I18n team can work well 
regarding new release activites which will happen after around 6 months.


With many thanks,

/Ian

Akihiro Motoki wrote on 4/5/2019 1:35 AM:
> I see no content for stable-stein version for example in 
> neutron-fwaas-dashboard [1].
> What should we do?
> I am really confused with the process around stable-stein cut....
>
> [1] 
> https://translate.openstack.org/project/view/neutron-fwaas-dashboard?dswid=1855
>
> On Mon, Apr 1, 2019 at 7:21 PM Frank Kloeker <eumel at arcor.de 
> <mailto:eumel at arcor.de>> wrote:
>
>     Good morning,
>
>     last week I was on a business trip and just wondering about ML
>     activities. But for sure, we have release weeks and thanks for
>     raising
>     up that topic.
>     Based on Ian's work I just cleaned up the Stein Dashboard with stable
>     branches as available [1]. So it's more clear what translators
>     have to
>     do, I mean translate stable branch instead of master. There is no
>     clear
>     handover between project teams when a stable branch is available, so
>     this needs to investigate by Zanata admin/PTL, or the failed job
>     list on
>     [2]. A lot of good jobs are already running on [3]
>     Further I investigted Ian's creation of empty versions in Zanata
>     and I
>     would say that won't work well, because that are post jobs and not
>     periodic jobs in Zuul. So if now merge on stable branch will
>     happen, the
>     po files won't sync to Zanata. Or it will take days, like in [4].
>     On the
>     other hand, someone will translate things targeting in that release,
>     then it's required to copy the stable version from master as usually.
>     I know, this takes some time and work, but at the moment there is no
>     improvement because Zanata developement is already gone and the
>     feature
>     set on API is at it is.
>
>     Regarding the second question for Horizon on translation check
>     site it
>     might be a question for the Horizon team. From my experience with
>     language settings it depends mostly on your browser settings. So
>     I'm not
>     sure if it's really a bug.
>
>     kind regards
>
>     Frank
>
>
>     [1]
>     https://translate.openstack.org/version-group/view/Stein-dashboard-translation
>     [2]
>     http://zuul.openstack.org/builds?job_name=upstream-translation-update&job_name=propose-translation-update&result=Failure
>     [3]
>     http://zuul.openstack.org/builds?job_name=upstream-translation-update&branch=stable%2Fstein
>     [4]
>     http://zuul.openstack.org/builds?job_name=upstream-translation-update&project=openstack%2Fdesignate-dashboard
>
>
>
>
>     Am 2019-03-27 03:21, schrieb Yuko Katabami:
>     > Hi Frank and all,
>     >
>     > I have a couple of questions about Horizon UI translation.
>     > Hope you can help me.
>     >
>     > 1. Is stable-stein version going to be created soon in Zanata? I
>     > noticed that the projects in github already have the new branch.
>     >
>     > 2. With Octavia Dashboard, I am not able to see Japanese
>     translations
>     > in Horizon even though it is 100% completed in master. I can see
>     that
>     > po files are imported properly:
>     >
>     https://github.com/openstack/octavia-dashboard/tree/master/octavia_dashboard/locale/ja/LC_MESSAGES
>     > Is there anything I need to do to be able to see it in my
>     environment?
>     >
>     > Many thanks in advance.
>     >
>     > Yuko
>     > _______________________________________________
>     > OpenStack-I18n mailing list
>     > OpenStack-I18n at lists.openstack.org
>     <mailto:OpenStack-I18n at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
>
>     _______________________________________________
>     OpenStack-I18n mailing list
>     OpenStack-I18n at lists.openstack.org
>     <mailto:OpenStack-I18n at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
>
> _______________________________________________
> OpenStack-I18n mailing list
> OpenStack-I18n at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n




From mnaser at vexxhost.com  Sun Apr  7 21:35:06 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Sun, 7 Apr 2019 17:35:06 -0400
Subject: [glance][interop] standardized image "name" ?
Message-ID: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>

Hi everyone,

Something that I've been dealing with is the fact that regardless of
what cloud you're using, the naming structure is very much different.
While we aim to be interoperable, if I want to "boot an Debian Stretch
server", the image name will probably be different all over the
places.

Is there some sort of way we can eliminate this by implementing a
standard naming convention which would allow us to use the same images
across all systems?

I'm just opening the idea for discussion, I'd love to hear what others
think about this.

Mohammed

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From feilong at catalyst.net.nz  Sun Apr  7 21:43:54 2019
From: feilong at catalyst.net.nz (Feilong Wang)
Date: Mon, 8 Apr 2019 09:43:54 +1200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
Message-ID: <fd04e244-66cc-e1c5-5f21-e1d4592df094@catalyst.net.nz>

We're using the name convention like this:

ubuntu-18.04-x86_64

ubuntu-minimal-16.04-x86_64

debian-9-x86_64

<OS>-<Version>-<Arch>


On 8/04/19 9:35 AM, Mohammed Naser wrote:
> Hi everyone,
>
> Something that I've been dealing with is the fact that regardless of
> what cloud you're using, the naming structure is very much different.
> While we aim to be interoperable, if I want to "boot an Debian Stretch
> server", the image name will probably be different all over the
> places.
>
> Is there some sort of way we can eliminate this by implementing a
> standard naming convention which would allow us to use the same images
> across all systems?
>
> I'm just opening the idea for discussion, I'd love to hear what others
> think about this.
>
> Mohammed
>
-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 



From feilong at catalyst.net.nz  Sun Apr  7 21:58:33 2019
From: feilong at catalyst.net.nz (Feilong Wang)
Date: Mon, 8 Apr 2019 09:58:33 +1200
Subject: [Magnum] How to use docker CLI against a Magnum-managed
 Kubernetes cluster
In-Reply-To: <CAP-MmQ+hwqrmMXuVnz-nssE+HLLeB_nmJMZ_m6S=6VVW8wsicg@mail.gmail.com>
References: <CAP-MmQ+hwqrmMXuVnz-nssE+HLLeB_nmJMZ_m6S=6VVW8wsicg@mail.gmail.com>
Message-ID: <1f1ebdf3-59e4-4fd5-7af5-2859708ebde9@catalyst.net.nz>

Hi Namrata,

It would be nice if you can provide more details about your environment
and your requirements.

So what's your coe? K8s or swarm? And can you get your certs correctly
and interact with your coe?


On 5/04/19 3:11 AM, Namrata Sitlani wrote:
> Hello,
>
> I am trying to use docker CLI against a Magnum-managed Kubernetes
> cluster so as to interact with its Docker registry.
>
> I followed the steps as explained in
> https://docs.openstack.org/magnum/rocky/user/#interfacing-with-a-secure-cluster
> but magnum does not setup docker on tcp port so it cannot be accessed
> outside the minion node(where docker is running).
>
> I appreciate any help guiding how to use docker CLI.
>
> Thanks
> Namrata Sitlani

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 



From feilong at catalyst.net.nz  Sun Apr  7 22:04:00 2019
From: feilong at catalyst.net.nz (Feilong Wang)
Date: Mon, 8 Apr 2019 10:04:00 +1200
Subject: fqdn magnum instances
In-Reply-To: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
Message-ID: <0303f73b-dc60-e9fb-77b0-0d5610880bd2@catalyst.net.nz>

Hi Ionut,

That's an interesting topic. I'm not sure if you can setup a FQDN
hostname with current design that the hostname is generated by Heat.

On 6/04/19 12:44 AM, Ionut Biru wrote:
> Hello,
>
> I was wondering if there is a way to set up the domain for template to
> use in order to have a FQDN hostname for all the vms that are part
> from the cluster
> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but
> i want something like 
> k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net
> <http://k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net>
>
> I'm trying to resolve this:
>
> helm install stable/wordpress
> Error: forwarding ports: error upgrading connection: error dialing
> backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on
> 8.8.8.8:53 <http://8.8.8.8:53>: no such host

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/6b83681a/attachment.html>

From ruijing.guo at intel.com  Mon Apr  8 00:42:46 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Mon, 8 Apr 2019 00:42:46 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>

I like Sean's idea. Can we create jobs based on nested KVM & customized OS?
If CI is stable enough, we can move non-voting to voting.
 

-----Original Message-----
From: Jeremy Stanley [mailto:fungi at yuggoth.org] 
Sent: Sunday, March 31, 2019 8:43 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [CI] nested virtualization support in OpenStack CI

On 2019-03-31 11:03:34 +0100 (+0100), Sean Mooney wrote:
[...]
> so on the stablity of nested virt jobs in general i think we should 
> try to enable nested virt but perhaps make the jobs non voting in 
> check and excluded nested jobs from gate. that way we get some testing 
> for things we cant other wise test but if we hit kenel bugs its a non 
> voting jobs so if it fails it wont break the zuul jobs.

Well, having these jobs non-voting means you aren't relying on them to protect you from merging changes which might break nested virtualization or fail to work with it. But that aside, to even have a guarantee it would be available at all we'd need a separate node label for all our images which is restricted to providers where we can expect it. For example, I've heard that doing nested virt acceleration for KVM guests in our Xen-based providers is a long way from being possible.
--
Jeremy Stanley


From aaronzhu1121 at gmail.com  Mon Apr  8 00:50:09 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Mon, 8 Apr 2019 08:50:09 +0800
Subject: [telemetry] Telemetry for Train
In-Reply-To: <20190404061722.GA3766@hilbert.berg.ol>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
 <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
 <20190404061722.GA3766@hilbert.berg.ol>
Message-ID: <CAN2nDNtHFT5ksC3moaXCJ+NJH43KZievoK0w7R4SiEbtX5Aidw@mail.gmail.com>

I also think IRC is the best choice, since the meeting time is in the
working hours, and don't have microphone and video in office PC.


Thanks,
Rong Zhu

Matthias Runge <mrunge at redhat.com>于2019年4月4日 周四22:21写道：

> On Thu, Apr 04, 2019 at 09:02:49AM +0800, Rong Zhu wrote:
> > >
> > > Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
> > > <https://jitsi.org/> should work? Let me know.
>
>
> > >> Meeting time is really good for us. But shall we change the meeting
> > >> channel just in the IRC channel? You may know we, from China, can't
> visit
> > >> Google.
>
> > >>> I've sent out the google calendar invitation to those who voted. If
> you
> > >>> want to join the meeting and help Telemetry out, drop me an email by
> this
> > >>> Saturday.
> > >>>
> > >>> Also, look at the etherpad:
> > >>> https://etherpad.openstack.org/p/telemetry-train
>
> Hi,
>
> thank you for setting this up! For the first meeting, having a video
> chat would probably be good, but I'd second the request for using IRC.
>
> Matthias
> --
> Matthias Runge <mrunge at matthias-runge.de>
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/213e56ce/attachment-0001.html>

From dangtrinhnt at gmail.com  Mon Apr  8 02:30:22 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Mon, 8 Apr 2019 11:30:22 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CAN2nDNtHFT5ksC3moaXCJ+NJH43KZievoK0w7R4SiEbtX5Aidw@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
 <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
 <20190404061722.GA3766@hilbert.berg.ol>
 <CAN2nDNtHFT5ksC3moaXCJ+NJH43KZievoK0w7R4SiEbtX5Aidw@mail.gmail.com>
Message-ID: <CADJ6S4Fhbgs6VnJPBwYQ-F55eNJ2uNStfhbbc7fD2m0Rb3ReUg@mail.gmail.com>

Okie, that should be fine. Let's do it over IRC #openstack-telemetry

I will update the calendar invitation.

Thanks.

On Mon, Apr 8, 2019 at 9:52 AM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> I also think IRC is the best choice, since the meeting time is in the
> working hours, and don't have microphone and video in office PC.
>
>
> Thanks,
> Rong Zhu
>
> Matthias Runge <mrunge at redhat.com>于2019年4月4日 周四22:21写道：
>
>> On Thu, Apr 04, 2019 at 09:02:49AM +0800, Rong Zhu wrote:
>> > >
>> > > Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
>> > > <https://jitsi.org/> should work? Let me know.
>>
>>
>> > >> Meeting time is really good for us. But shall we change the meeting
>> > >> channel just in the IRC channel? You may know we, from China, can't
>> visit
>> > >> Google.
>>
>> > >>> I've sent out the google calendar invitation to those who voted. If
>> you
>> > >>> want to join the meeting and help Telemetry out, drop me an email
>> by this
>> > >>> Saturday.
>> > >>>
>> > >>> Also, look at the etherpad:
>> > >>> https://etherpad.openstack.org/p/telemetry-train
>>
>> Hi,
>>
>> thank you for setting this up! For the first meeting, having a video
>> chat would probably be good, but I'd second the request for using IRC.
>>
>> Matthias
>> --
>> Matthias Runge <mrunge at matthias-runge.de>
>>
>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/77d98dab/attachment.html>

From dangtrinhnt at gmail.com  Mon Apr  8 02:41:34 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Mon, 8 Apr 2019 11:41:34 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4Fhbgs6VnJPBwYQ-F55eNJ2uNStfhbbc7fD2m0Rb3ReUg@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
 <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
 <20190404061722.GA3766@hilbert.berg.ol>
 <CAN2nDNtHFT5ksC3moaXCJ+NJH43KZievoK0w7R4SiEbtX5Aidw@mail.gmail.com>
 <CADJ6S4Fhbgs6VnJPBwYQ-F55eNJ2uNStfhbbc7fD2m0Rb3ReUg@mail.gmail.com>
Message-ID: <CADJ6S4EvogMYONYny9c0yfmSzAi6NXKj8hMs=VV2Ek=DVQLgmg@mail.gmail.com>

Invitation sent! Talk (chat) to you soon.

On Mon, Apr 8, 2019 at 11:30 AM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Okie, that should be fine. Let's do it over IRC #openstack-telemetry
>
> I will update the calendar invitation.
>
> Thanks.
>
> On Mon, Apr 8, 2019 at 9:52 AM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>
>> I also think IRC is the best choice, since the meeting time is in the
>> working hours, and don't have microphone and video in office PC.
>>
>>
>> Thanks,
>> Rong Zhu
>>
>> Matthias Runge <mrunge at redhat.com>于2019年4月4日 周四22:21写道：
>>
>>> On Thu, Apr 04, 2019 at 09:02:49AM +0800, Rong Zhu wrote:
>>> > >
>>> > > Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
>>> > > <https://jitsi.org/> should work? Let me know.
>>>
>>>
>>> > >> Meeting time is really good for us. But shall we change the meeting
>>> > >> channel just in the IRC channel? You may know we, from China, can't
>>> visit
>>> > >> Google.
>>>
>>> > >>> I've sent out the google calendar invitation to those who voted.
>>> If you
>>> > >>> want to join the meeting and help Telemetry out, drop me an email
>>> by this
>>> > >>> Saturday.
>>> > >>>
>>> > >>> Also, look at the etherpad:
>>> > >>> https://etherpad.openstack.org/p/telemetry-train
>>>
>>> Hi,
>>>
>>> thank you for setting this up! For the first meeting, having a video
>>> chat would probably be good, but I'd second the request for using IRC.
>>>
>>> Matthias
>>> --
>>> Matthias Runge <mrunge at matthias-runge.de>
>>>
>>> --
>> Thanks,
>> Rong Zhu
>>
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/4f0d8084/attachment.html>

From dangtrinhnt at gmail.com  Mon Apr  8 02:48:45 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Mon, 8 Apr 2019 11:48:45 +0900
Subject: [searchlight] Team meeting today at 13:30 UTC
Message-ID: <CADJ6S4GeWu7HNNFSm-zhNqd7X1Fiut-FFq+HUiwOqSx=m64wYg@mail.gmail.com>

Hi team,

We will have the team meeting today at 13:30 UTC on #openstack-searchlight
IRC channel. Please look at the meeting agenda at
https://etherpad.openstack.org/p/search-team-meeting-agenda

Yours,

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/a7da97c2/attachment.html>

From mvoelker at vmware.com  Mon Apr  8 03:39:51 2019
From: mvoelker at vmware.com (Mark Voelker)
Date: Mon, 8 Apr 2019 03:39:51 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
Message-ID: <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>

I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with.  Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical.  Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.

At Your Service,

Mark T. Voelker



> On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
> 
> Hi everyone,
> 
> Something that I've been dealing with is the fact that regardless of
> what cloud you're using, the naming structure is very much different.
> While we aim to be interoperable, if I want to "boot an Debian Stretch
> server", the image name will probably be different all over the
> places.
> 
> Is there some sort of way we can eliminate this by implementing a
> standard naming convention which would allow us to use the same images
> across all systems?
> 
> I'm just opening the idea for discussion, I'd love to hear what others
> think about this.
> 
> Mohammed
> 
> -- 
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&amp;data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&amp;sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&amp;reserved=0
> 


From manuel.sb at garvan.org.au  Mon Apr  8 05:45:24 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Mon, 8 Apr 2019 05:45:24 +0000
Subject: resize a vm to a flavor with pci-passthrough
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>

Dear Openstack community,

I have 1 physical node with x4 nvidia nv100 running 1 fat vm. Additionally I am adding a nvme drive into that host and I would like to attach the nvme drive to the vm. Ideally I prefer to avoid data migration and redeploy the software.

My problem is that I don't have another host with gpus so I am guessing that the vm can't be migrated. Am I right assuming this?

So far I thought about 2 possibilities but I don't know whether they would work:

Option 1: crate a new flavor with the pci device pass-through and resize existing vm (I hope the new vm with the new flavor will have the nvme attached).
Option 2: convert ephemeral virtual disk into a bootable volume. Destroy vm. Create new vm with the new volume as a boot device.

Which option would be preferred? Is there any other think I can do?

Thank you very much

Manuel


NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/6190d37b/attachment.html>

From Tim.Bell at cern.ch  Mon Apr  8 06:14:50 2019
From: Tim.Bell at cern.ch (Tim Bell)
Date: Mon, 8 Apr 2019 06:14:50 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
Message-ID: <AA627BA7-CCD2-4FD4-93F5-87C4AFBEDBB2@cern.ch>

You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query

e.g. os_distro=centos, os_version=7 and sort by upload date

Tim

-----Original Message-----
From: Mark Voelker <mvoelker at vmware.com>
Date: Monday, 8 April 2019 at 05:45
To: Mohammed Naser <mnaser at vexxhost.com>
Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [glance][interop] standardized image "name" ?

    I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with.  Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical.  Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
    
    At Your Service,
    
    Mark T. Voelker
    
    
    
    > On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
    > 
    > Hi everyone,
    > 
    > Something that I've been dealing with is the fact that regardless of
    > what cloud you're using, the naming structure is very much different.
    > While we aim to be interoperable, if I want to "boot an Debian Stretch
    > server", the image name will probably be different all over the
    > places.
    > 
    > Is there some sort of way we can eliminate this by implementing a
    > standard naming convention which would allow us to use the same images
    > across all systems?
    > 
    > I'm just opening the idea for discussion, I'd love to hear what others
    > think about this.
    > 
    > Mohammed
    > 
    > -- 
    > Mohammed Naser — vexxhost
    > -----------------------------------------------------
    > D. 514-316-8872
    > D. 800-910-1726 ext. 200
    > E. mnaser at vexxhost.com
    > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&amp;data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&amp;sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&amp;reserved=0
    > 
    
    


From marcin.juszkiewicz at linaro.org  Mon Apr  8 06:37:14 2019
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Mon, 8 Apr 2019 08:37:14 +0200
Subject: resize a vm to a flavor with pci-passthrough
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <6d85495d-010e-55c1-8d72-f51edc923562@linaro.org>

W dniu 08.04.2019 o 07:45, Manuel Sopena Ballesteros pisze:
> Dear Openstack community,
> 
> I have 1 physical node with x4 nvidia nv100 running 1 fat vm. 
> Additionally I am adding a nvme drive into that host and I would
> like to attach the nvme drive to the vm. Ideally I prefer to avoid
> data migration and redeploy the software.
> 
> My problem is that I don't have another host with gpus so I am 
> guessing that the vm can't be migrated. Am I right assuming this?
> 
> So far I thought about 2 possibilities but I don't know whether they 
> would work:
> 
> Option 1: crate a new flavor with the pci device pass-through and 
> resize existing vm (I hope the new vm with the new flavor will have 
> the nvme attached).
>
> Option 2: convert ephemeral virtual disk into a bootable volume.
> Destroy vm. Create new vm with the new volume as a boot device.

> Which option would be preferred? Is there any other think I can do?

Attach NVME to VM and migrate system in VM?


From tony at bakeyournoodle.com  Mon Apr  8 07:13:22 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 8 Apr 2019 17:13:22 +1000
Subject: [releaseteam] Changing the meeting time.
Message-ID: <20190408071321.GA7047@thor.bakeyournoodle.com>

Hello all,
    Now that the world has completed it's biannual calendar confusion
dance, and Stein is pretty darn close to being released.  I'd like to
move the release team meeting to a time I can attend[1]

It's going to be hard to find a time that works for the whole team given
out 'follow the sun' support model.

IIUC we have[2]:
 * Australia
 * Europe
 * US East     
 * US Central
 * US West

Which means someone (or some people) are going to be inconvenienced.

If needed, we could do 2 meetings one for AU+EU and then another for
AU+US but I'd much rather have a single meeting to keep everyone on the
same page.

I've created a doodle poll: https://doodle.com/poll/xxa46wrndefyi6dk

I picked Thursday as the day of the week for the poll but if if needed
we can mov it to another day.

Yours Tony.

[1] The current meeting time is 0200 for me.
[2] https://www.worldtimebuddy.com/?pl=1&lid=21,312,5,8&h=21
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/d11c68c9/attachment.sig>

From tony at bakeyournoodle.com  Mon Apr  8 07:31:52 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 8 Apr 2019 17:31:52 +1000
Subject: [PTL][release][stable] Pike transitioning to Extended
 Maintenance phase
In-Reply-To: <20190404201557.GA6952@sm-workstation>
References: <20190404201557.GA6952@sm-workstation>
Message-ID: <20190408073151.GB7047@thor.bakeyournoodle.com>

On Thu, Apr 04, 2019 at 03:15:57PM -0500, Sean McGinnis wrote:
> Hey everyone,
> 
> Thought I should get this out there to make sure folks are aware.
> 
> We are actually overdue for Pike to have entered extended maintenance.
> According to the stable policy, that should happen 18 months after the release
> [0]. That means we should have made the switch in February, if my math is
> right.
> 
> We will need to work through the details to actually put that in effect, but
> for now I wanted to remind teams that we do not do releases after a stable
> branch enters this phase. So this is a call for action for any teams that have
> been backporting fixes that time is short to get a final release out while you
> can.
> 
> The release dates for each cycle can be found on the releases site [1].

Thanks Sean!

How about this to catch us up:

1. This week I'll propose one change per team[1] to create a release
   from the current HEAD for stable/pike and tag that as pike-em
2. Just like with other procedural releases teams are free to +/-1 /
   suggest fixes.
3. We merge any that have PTL/Liaison +1 as we get the approvals
4. Any that aren't explicitly -1'd by April 22nd get merged that week
5. Others get discussed at the Summit/PTG.
6. We release the remainders during the week of May 6th
7. May 13th we formally transition pike to EM


Yours Tony.

[1] This will be a generally helpful tool to write anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/19a6634a/attachment-0001.sig>

From thierry at openstack.org  Mon Apr  8 08:16:49 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 8 Apr 2019 10:16:49 +0200
Subject: [TC] PTG Lunch Talks
In-Reply-To: <CAEs876ghLwKHkg6tCv7YoarcZGWpVZbgVJKGQz+pWFiwxWn3vg@mail.gmail.com>
References: <CAJ6yrQhnMsbGKzBs9sQX2C_Er_qbhses6dyJa9fTU445odwMAw@mail.gmail.com>
 <CAEs876hu5n0QAi3EhBFPJ2n+uGehpdt+-mYOXGyG+Nh3CerMHw@mail.gmail.com>
 <50728A96-942C-436C-AA74-3ADE5637CFE7@doughellmann.com>
 <6f749db9-5a0e-2f2c-0d09-83d01de56b1a@openstack.org>
 <45fdf02e-a771-bfb8-c95c-b89bce319f57@ham.ie>
 <CAEs876ghLwKHkg6tCv7YoarcZGWpVZbgVJKGQz+pWFiwxWn3vg@mail.gmail.com>
Message-ID: <f2b5ca2c-e6ad-1a6d-cda6-5ce65a601e2b@openstack.org>

Mohammed Naser wrote:
> On Fri, Apr 5, 2019 at 9:43 AM Graham Hayes <gr at ham.ie> wrote:
>>
>> On 05/04/2019 08:38, Thierry Carrez wrote:
>>> Doug Hellmann wrote:
>>>> I’d love to hear from teams about major work they have planned for Train.
>>>
>>> Also introducing Train goals would be nice.
>>>
>>
>> I think introducing the goals on the Thursday is a good idea - try
>> and get them out there as much as possible.
>>
> 
> Indeed, that means we also need to work on flushing out those goals
> as soon as possible to have something ready to be presented.
> 
> I think the answer here is "Yes".  We might probably do a recap of
> last cycle, a bit of words for the upcoming one and talking about
> the project goals.

OK, I think we can fit that in 15-20 minutes ? Trying to make sure we 
have time to cover other teams and not start too early.

-- 
Thierry Carrez (ttx)


From mark at stackhpc.com  Mon Apr  8 08:21:42 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 8 Apr 2019 08:21:42 +0000
Subject: [release][kayobe] Release job failures
Message-ID: <CAFHSqWoMHVZz4pQSdLkaWMUKVbSKfc-wyh3Map0bWg-Hbcvkdg@mail.gmail.com>

Hi,

We've had a few release job failures in Kayobe [1]. I created some new tags
on stable branches last week, and the release jobs failed with the
following:

Unable to freeze job graph: Unable to modify final job <Job
trigger-readthedocs-webhook branches: None source:
opendev/base-jobs/zuul.yaml at master#112> attribute
variables={'rtd_webhook_id': '74820', 'rtd_project_name':
'kayobe-release-notes'} with variant <Job trigger-readthedocs-webhook
branches: None source: openstack/kayobe/zuul.d/project.yaml at master#2>

It's not clear from the email which branch, tag or job this affects. The
message above references our readthedocs job which aims to publish release
notes, although I can't see the expected releases on tarballs.o.o or PyPI.

The RTD release note Zuul job is defined here [2], is it causing a problem?
We also use the docs-on-readthedocs template to update our docs.

[1]
http://lists.openstack.org/pipermail/release-job-failures/2019-April/001117.html
[2]
https://github.com/openstack/kayobe/blob/44430a42421a7c59807a58cbbd67f90a154fd30a/zuul.d/project.yaml#L46

Thanks,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/ffe6b491/attachment.html>

From kchamart at redhat.com  Mon Apr  8 08:36:28 2019
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Mon, 8 Apr 2019 10:36:28 +0200
Subject: Call For Proposals: KVM Forum =?utf-8?Q?20?=
 =?utf-8?Q?19_=2830-Oct_to_01-Nov_=E2=80=93?= Lyon, France)
Message-ID: <20190408083628.GD28897@paraplu>

================================================================
KVM Forum 2019: Call For Participation
October 30-November 1, 2019 - Lyon Convention Center - Lyon, France

(All submissions must be received before June 15, 2019 at 23:59 PST)
=================================================================

KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux
virtualization technology, and plan for the challenges ahead.
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2019.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining Open Source Summit in Lyon,
France. Selected talks from KVM Forum will be presented on
Wednesday October 30 to the full audience of the Open Source Summit.
Also, attendees of KVM Forum will have access to all of the talks from
Open Source Summit on Wednesday.

https://events.linuxfoundation.org/events/kvm-forum-2019/program/call-for-proposals/

Suggested topics:
* Scaling, latency optimizations, performance tuning, real-time guests
* Hardening and security
* New features
* Testing

KVM and the Linux kernel:
* Nested virtualization
* Resource management (CPU, I/O, memory) and scheduling
* VFIO: IOMMU, SR-IOV, virtual GPU, etc.
* Networking: Open vSwitch, XDP, etc.
* virtio and vhost
* Architecture ports and new processor features

QEMU:
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Graphics, desktop virtualization and virtual GPU
* New storage features
* High availability, live migration and fault tolerance
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, U-Boot, etc.

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: Ceph, Gluster, SPDK, etc.
* Network Function Virtualization: DPDK, OPNFV, OVN, etc.
* Provisioning


========================
SUBMITTING YOUR PROPOSAL
========================

Abstracts due: June 15, 2019

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes.

Submit your proposal here:
https://events.linuxfoundation.org/events/kvm-forum-2019/program/call-for-proposals/
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by August 12, 2019.

Speakers will receive a complimentary pass for the event. In case
your submission has multiple presenters, only the primary speaker for a
proposal will receive a complimentary event pass. For panel discussions, all
panelists will receive a complimentary event pass.


TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.


END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.


HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2019_BOF

Let people you think who might be interested know about your BOF, and
encourage them to add their names to the wiki page as well. Please add
your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request full
biographies if a panel is accepted.


==============
HOTEL / TRAVEL
==============

This year's event will take place at the Lyon Conference Center.
For information on hotels close to the conference, please visit
https://events.linuxfoundation.org/events/kvm-forum-2019/attend/venue-travel/.
Information on conference hotel blocks will be available later in
Spring 2019.


=================
DATES TO REMEMBER
=================

Submission deadline: Saturday, June 15 at 23:59 PST
Notification: Monday, August 12
Schedule announced: Friday, August 16
Slides due date: Wednesday, October 23
Event dates: Wednesday, October 30 - Friday, November 1

Thank you for your interest in KVM. We're looking forward to your
submissions and seeing you at the KVM Forum 2019 in October!

For questions and comments, please contact the KVM Forum 2019 Program
Committee at: kvm-forum-2019-pc at redhat.com

-- 
/kashyap


From igortiunov at gmail.com  Mon Apr  8 09:04:11 2019
From: igortiunov at gmail.com (=?utf-8?B?0JjQs9C+0YDRjCDQotC40YPQvdC+0LI=?=)
Date: Mon, 8 Apr 2019 12:04:11 +0300
Subject: [sdk][ansible][inventory] Server-side filtering capability for nova
 API
Message-ID: <FEDFAF89-F7E7-4D45-B38C-23BBB31308DB@gmail.com>

Hi. 
I saw that there some work regarding filtering in the inventory module. Also, I looked at how it will be used in future versions of ansible (os_server_facts module).

I am worried about client-side nature of this filtering. The large deployments can have thousands of vms in one openstack project and such an environment can be very dynamic (vms are created/deleted frequently). The inventory collection can be done from multiple ansible management nodes and all these facts can lead to significant performance impact not only on the client side but on the server side also - a large amount of data will be requested from nova api servers.
I want to propose the usage of server-side filtering capability for nova API:

https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers

These filters are used at database level and will add a significant performance boost during inventory collection.
I want to propose the usage of filters in ansible openstack inventory plugin but first, such filters should be implemented in openstacksdk level.
I suggest splitting filters into two parts - the api_filters and metadata_filters. The api_filters will be used for server-side filtering and metadata_filters for client-side filtering.
I have created the snippet with prototype code. There a _split_filters method and related changes for list_hosts and search_hosts methods:

https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629

What do you think?

From bcafarel at redhat.com  Mon Apr  8 09:54:18 2019
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Mon, 8 Apr 2019 11:54:18 +0200
Subject: [neutron] Bug deputy report (week starting on 2019-04-01)
Message-ID: <CABHdKwrCyq6wRaHZ=bOWK7eOvFvAnnRzOnw4dzPj31AdGn0TBw@mail.gmail.com>

Hello Neutrinos,

I was the bug deputy for April Fools' week. All Critical/High bugs already
have fixes merged, except https://review.openstack.org/#/c/650599/ (close
to merge)

Both Medium bugs would benefit from a second look (details below)

A few invalid bugs, filled on LP while they should now be created on
StoryBoard. This includes neutron-lbaas (
https://storyboard.openstack.org/#!/project/openstack/neutron-lbaas) and
os-ken (https://storyboard.openstack.org/#!/project/openstack/os-ken not
sure why it does not appear when searching for os-ken)

Proposed RFE:
* [RFE] L3 - netfilter Contrack Helper Support -
https://bugs.launchpad.net/neutron/+bug/1823633
  Suggested in L3 meeting

Critical:
* ml2 create_port_bulk produces incompatible port context to drivers -
https://bugs.launchpad.net/networking-midonet/+bug/1822999
  Midonet tests failing after bulk ports optimization merged
  Fixed with: https://review.openstack.org/#/c/649615
<https://review.openstack.org/#/c/649615/3> and
https://review.openstack.org/649623 as added check
* test_update_provider_net_unsupported failure -
https://bugs.launchpad.net/networking-midonet/+bug/1823294
  Another Midonet gate failure caused by
https://review.openstack.org/#/c/648522/
  Proposed fix: https://review.openstack.org/#/c/650599/
* neutron-fullstack fails on stable/rocky at ovs compilation -
https://bugs.launchpad.net/neutron/+bug/1823155
  Latest Xenial kernels break OVS compilation for fullstack tests
  Fixed with newer OVS snapshot: https://review.openstack.org/#/c/650022/

High:
* Neutron-keepalived-state-change fails to check initial router state -
https://bugs.launchpad.net/neutron/+bug/1823038
  New functional failure as a result of bug #1818614
  Fixed with: https://review.openstack.org/#/c/649991/ backports in progress
* Specify FROM clause to join from in
test_floatingip_via_router_interface_returns_201 -
https://bugs.launchpad.net/neutron/+bug/1823059
  Blocking upper-constraints update
  Fix merged: https://review.openstack.org/#/c/649681

Medium:
* Bulk IPv6 subnet create error -
https://bugs.launchpad.net/neutron/+bug/1822582
  "RuntimeError: Method <function update_port at 0x7fde0e9280c8> cannot be
called within a transaction."
  Has a reproducer
* neutron-keepalived-state-change doesnt reap zombies if rootwrap-daemon is
used - https://bugs.launchpad.net/neutron/+bug/1822591
  Reproduced on current, and need additional eyes/opinion here: were there
sudo zombies appearing before? (when the child process gets killed)

Low:
* [VPNaaS]: Skip check process status for HA backup routers -
https://bugs.launchpad.net/neutron/+bug/1822921
  In progress
* create of segment range for vlan network type fails with error 500 -
https://bugs.launchpad.net/neutron/+bug/1823297
  Proposed fix: https://review.openstack.org/650245
* ha router sometime goes in standby mode in all controllers -
https://bugs.launchpad.net/neutron/+bug/1823314
  Rare race condition when creating HA routers, in progress

Invalid:
* "delete l7 rule" Parameter Passing Error -
https://bugs.launchpad.net/bugs/1822960
* "lbaas delete l7 rule & policy" could leave dirty data -
https://bugs.launchpad.net/bugs/1822968
  2 neutron-lbaas bugs filled, I pointed author to storyboard
* Error in os_kenbgp import in tests -
https://bugs.launchpad.net/neutron/+bug/1822649
  To move to storyboard
  Probably caused in mass rename, one filename does not match the module
name in imports
  Proposed fix: https://review.openstack.org/#/c/649140/

Incomplete:
* legacy router namespaces absence or error run exec -
https://bugs.launchpad.net/neutron/+bug/1823023
  ip netns commands failing on an OSA deployment, out of scope for neutron
for now

Regards,
--
Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/cae2f908/attachment-0001.html>

From anlin.kong at gmail.com  Mon Apr  8 09:59:32 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Mon, 8 Apr 2019 21:59:32 +1200
Subject: [trove] trove guest agent image building improvement
Message-ID: <CALjNAZ0PvPjOKJNoJz-=u7sXDBLYKsUNOGO-6V46qzJOttAjBA@mail.gmail.com>

Hi team,

I've proposed a patch https://review.openstack.org/#/c/650608/ for the
image building improvement. The most significant change is introducing one
more param `dev_mode` to the command so that users could choose to build
image for non-dev environment.

BTW, I've also submitted some other patches for CI improvement which need
your review as well.

Any suggestion or feedback are welcomed.

---
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/058eea6f/attachment.html>

From gr at ham.ie  Mon Apr  8 10:10:11 2019
From: gr at ham.ie (Graham Hayes)
Date: Mon, 8 Apr 2019 11:10:11 +0100
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <AA627BA7-CCD2-4FD4-93F5-87C4AFBEDBB2@cern.ch>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <AA627BA7-CCD2-4FD4-93F5-87C4AFBEDBB2@cern.ch>
Message-ID: <86ff9927-1c24-f001-9527-fb87e24319f4@ham.ie>

On 08/04/2019 07:14, Tim Bell wrote:
> You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
> 
> e.g. os_distro=centos, os_version=7 and sort by upload date
> 
> Tim

I like the idea of it being discoverable, not defined by using the name
- it fits better in my head with the way we are doing interop and allows
current clouds to not have to change name formats (which could break
other users).

> 
> -----Original Message-----
> From: Mark Voelker <mvoelker at vmware.com>
> Date: Monday, 8 April 2019 at 05:45
> To: Mohammed Naser <mnaser at vexxhost.com>
> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
> Subject: Re: [glance][interop] standardized image "name" ?
> 
>     I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with.  Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical.  Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
>     
>     At Your Service,
>     
>     Mark T. Voelker
>     
>     
>     
>     > On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
>     > 
>     > Hi everyone,
>     > 
>     > Something that I've been dealing with is the fact that regardless of
>     > what cloud you're using, the naming structure is very much different.
>     > While we aim to be interoperable, if I want to "boot an Debian Stretch
>     > server", the image name will probably be different all over the
>     > places.
>     > 
>     > Is there some sort of way we can eliminate this by implementing a
>     > standard naming convention which would allow us to use the same images
>     > across all systems?
>     > 
>     > I'm just opening the idea for discussion, I'd love to hear what others
>     > think about this.
>     > 
>     > Mohammed
>     > 
>     > -- 
>     > Mohammed Naser — vexxhost
>     > -----------------------------------------------------
>     > D. 514-316-8872
>     > D. 800-910-1726 ext. 200
>     > E. mnaser at vexxhost.com
>     > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&amp;data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&amp;sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&amp;reserved=0
>     > 
>     
>     
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/4f363ec0/attachment.sig>

From gr at ham.ie  Mon Apr  8 10:15:28 2019
From: gr at ham.ie (Graham Hayes)
Date: Mon, 8 Apr 2019 11:15:28 +0100
Subject: fqdn magnum instances
In-Reply-To: <0303f73b-dc60-e9fb-77b0-0d5610880bd2@catalyst.net.nz>
References: <CALE96NAFKvev5nfBdAaUEen0BnYvESF5q1d_hrCd1Ce1U4caMg@mail.gmail.com>
 <0303f73b-dc60-e9fb-77b0-0d5610880bd2@catalyst.net.nz>
Message-ID: <bd40e766-dc76-e7ad-6f25-3a7b5aa06ea6@ham.ie>

On 07/04/2019 23:04, Feilong Wang wrote:
> Hi Ionut,
> 
> That's an interesting topic. I'm not sure if you can setup a FQDN
> hostname with current design that the hostname is generated by Heat.

Heat has Designate resources availible, so it could be as simple as
adding a OS::Designate::RecordSet resource, with the heat generated
name.

Let me know if there is interest in this, and I can have a look at
adding it.

- Graham

> On 6/04/19 12:44 AM, Ionut Biru wrote:
>> Hello,
>>
>> I was wondering if there is a way to set up the domain for template to
>> use in order to have a FQDN hostname for all the vms that are part
>> from the cluster
>> Currently the name is:  k8s-cluster-coreos-somerandomtext-minion-0 but
>> i want something like 
>> k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net
>> <http://k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net>
>>
>> I'm trying to resolve this:
>>
>> helm install stable/wordpress
>> Error: forwarding ports: error upgrading connection: error dialing
>> backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on
>> 8.8.8.8:53 <http://8.8.8.8:53>: no such host
> 
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --------------------------------------------------------------------------
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flwang at catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -------------------------------------------------------------------------- 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/a8d8f3b8/attachment.sig>

From amansi26 at in.ibm.com  Mon Apr  8 10:20:55 2019
From: amansi26 at in.ibm.com (Aman Kumar Sinha26)
Date: Mon, 8 Apr 2019 10:20:55 +0000
Subject: Nodepool not able to register node to jenkins.
Message-ID: <OFBC20EF03.08273D58-ON002583D6.00358FD6-002583D6.0038D8D8@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/ffd2d5f7/attachment-0001.html>

From mordred at inaugust.com  Mon Apr  8 10:22:21 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Mon, 8 Apr 2019 10:22:21 +0000
Subject: [sdk][ansible][inventory] Server-side filtering capability for
 nova API
In-Reply-To: <FEDFAF89-F7E7-4D45-B38C-23BBB31308DB@gmail.com>
References: <FEDFAF89-F7E7-4D45-B38C-23BBB31308DB@gmail.com>
Message-ID: <180f3b37-b00f-1050-df73-558fe731d7f4@inaugust.com>



On 4/8/19 9:04 AM, Игорь Тиунов wrote:
> Hi.
> I saw that there some work regarding filtering in the inventory module. Also, I looked at how it will be used in future versions of ansible (os_server_facts module).
> 
> I am worried about client-side nature of this filtering. The large deployments can have thousands of vms in one openstack project and such an environment can be very dynamic (vms are created/deleted frequently). The inventory collection can be done from multiple ansible management nodes and all these facts can lead to significant performance impact not only on the client side but on the server side also - a large amount of data will be requested from nova api servers.
> I want to propose the usage of server-side filtering capability for nova API:
> 
> https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers
> 
> These filters are used at database level and will add a significant performance boost during inventory collection.
> I want to propose the usage of filters in ansible openstack inventory plugin but first, such filters should be implemented in openstacksdk level.
> I suggest splitting filters into two parts - the api_filters and metadata_filters. The api_filters will be used for server-side filtering and metadata_filters for client-side filtering.
> I have created the snippet with prototype code. There a _split_filters method and related changes for list_hosts and search_hosts methods:
> 
> https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629
> 
> What do you think?

Generally speaking, I think it's a good idea. However, there's a few 
things to be aware of that make this a little more complex. Namely - in 
addition to fire-and-forget programs like the os_ modules or the ansible 
inventory code, we also support users with long lives that do high 
volume interactions, such as nodepool. Unfortunately, in terms of 
efficiency, these two use cases want opposite things.

For the short-term programs, as you mention, we want to maximize use of 
server-side filters. We also want to do things like use GET 
/servers/{id}. For the long-lived high-volume programs, we want to 
support a mode that combines caching and batching - rather than making 
1000 queries to the server a second each with their own server-side 
filter conditions, it's more efficient to make one call every 5 seconds, 
cache the result, and do client-side filtering.

We're currently good at the second use case and less good at the first.

We took a step towards being better at the first use case with the 
use_direct_get parameter. Use direct get tells openstacksk to use direct 
GET /servers/{id} type calls rather than filtering a full list locally 
when a single resource is wanted by id.

We need to fix this for get_server for reasons 
https://review.openstack.org/#/c/540389/.

We should also update the logic for the default value to set 
use_direct_get=True if caching is enabled, and set it to false if it 
isn't - that way normal people don't have to care.

We should almost CERTAINLY start setting this parameter to True in all 
of the ansible modules and inventory (I think the cases in which we want 
use_direct_get=False for ansible are VERY explicit - it involves having 
caching enabled to use external caching like redis - and I think in 
those cases we can expect a user to set the flag explicitly in config)

So I think what we should potentially do here is expand on that config 
flag and have it pushdown server-side filters. In fact, if you read the 
value of that in your _split_filters method, then split filters could 
either return things in api_filters or not. Then we can take the idea 
and push it down into the underlying code so that inventory is just 
calling search_severs ... or something. I'm sure we'll need to figure 
out some details once we get in to it.

One additional thing that will make this slightly more complex - but 
also I believe might allow us to do a few hard patches and get a LOT of 
benefit across the SDK.

Right now we have the 'cloud' layer which used to be the shade library, 
and we have the 'resource' layer which came from the openstacksdk 
library. They share almost nothing, other than the connection object and 
some Adapters, but we're working to change that. One of the next things
on the list is to get the 'cloud' layer to be built on top of the 
'resource' layer for server interactions. We're already using the sdk 
layer for servers: https://review.openstack.org/#/c/530770 (although as 
mentioned use_direct_get needs fixed) ...

What I think would be BEST would be if we taught 
openstack.resource.Resource about use_direct_get - and then put your 
_split_filters logic in there (although I believe the equiv logic is 
already there, so it might just be a matter of harnessing it.

I think we can certainly start with inventory - as well as changing the 
default for use_direct_get in the inventory module and in 
lib/ansible/module_utils/openstak.py.

Monty


From smooney at redhat.com  Mon Apr  8 10:24:56 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 08 Apr 2019 11:24:56 +0100
Subject: resize a vm to a flavor with pci-passthrough
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <f2577eda069cf3c3256635ce340a57a878a6e245.camel@redhat.com>

On Mon, 2019-04-08 at 05:45 +0000, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
> 
> I have 1 physical node with x4 nvidia nv100 running 1 fat vm. Additionally I am adding a nvme drive into that host and
> I would like to attach the nvme drive to the vm. Ideally I prefer to avoid data migration and redeploy the software.
> 
> My problem is that I don't have another host with gpus so I am guessing that the vm can't be migrated. Am I right
> assuming this?
we do have a config option to allow same host resize however in your case it likely still wont work.

when we do a resize to a new flavor we need to temporaily claim both the existing resouce for the currnt flavor and the
new resouces for the target flavor. so unless you have 8 gpus on that system it will fail.
you could try shelving the vm. resizing and unshelving. but really there is no good option here.

> 
> So far I thought about 2 possibilities but I don't know whether they would work:
> 
> Option 1: crate a new flavor with the pci device pass-through and resize existing vm (I hope the new vm with the new
> flavor will have the nvme attached).
if you have enough space for the new flavor then yes that should work.
> Option 2: convert ephemeral virtual disk into a bootable volume. Destroy vm. Create new vm with the new volume as a
> boot device.
if all the data you want to keep is in the root disk then a snapshot will work but this would evffectivly be the
same as the shelve resize unselve workflow i suggested above. if you have addtional ephemeral disk beyond the
root disk then you should backup all the data to a cinder volume manually first. then recreate the vm and attach those
volumes. 
> 
> Which option would be preferred? Is there any other think I can do?
> 
> Thank you very much
> 
> Manuel
> 
> 
> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.



From mordred at inaugust.com  Mon Apr  8 10:41:48 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Mon, 8 Apr 2019 10:41:48 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <86ff9927-1c24-f001-9527-fb87e24319f4@ham.ie>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <AA627BA7-CCD2-4FD4-93F5-87C4AFBEDBB2@cern.ch>
 <86ff9927-1c24-f001-9527-fb87e24319f4@ham.ie>
Message-ID: <14c3657b-d8ba-96cf-0eaa-239f5ad6c4bc@inaugust.com>



On 4/8/19 10:10 AM, Graham Hayes wrote:
> On 08/04/2019 07:14, Tim Bell wrote:
>> You could use the standard image properties (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html) to find the image using a query
>>
>> e.g. os_distro=centos, os_version=7 and sort by upload date
>>
>> Tim
> 
> I like the idea of it being discoverable, not defined by using the name
> - it fits better in my head with the way we are doing interop and allows
> current clouds to not have to change name formats (which could break
> other users).

I would love it if we could provide guidance - or maybe even somehow get 
this in to RefStack or something - that clouds *should* provide that 
metadata.

At the same time, needing to search for an image (and a flavor) on the 
cloud makes this:

   openstack server boot --image=<image> --flavor=<flavor> foo

a bit harder. Perhaps we could add some parameters ... like:

   openstack server boot --image-os=debian --image-version=7

And it would use the latest image matching those or fail if the 
properties arent' defined on that cloud.

>>
>> -----Original Message-----
>> From: Mark Voelker <mvoelker at vmware.com>
>> Date: Monday, 8 April 2019 at 05:45
>> To: Mohammed Naser <mnaser at vexxhost.com>
>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
>> Subject: Re: [glance][interop] standardized image "name" ?
>>
>>      I don’t think I have a perfect answer here, but just to add fodder to the discussion: it’s often been suggested in the past that one way of dealing with this is to simply ensure that you can bring your image to any cloud you work with.  Thus, rather than relying on an image to be named the same across the clouds you deal with, you can simply provide it yourself on those clouds so you know it’s identical.  Many of the caveats to this approach should be fairly obvious (footprint, duplication, quotas, format conversion, etc), but for some workflows it provides the sorts of useful guarantees an end user may want.
>>      
>>      At Your Service,
>>      
>>      Mark T. Voelker
>>      
>>      
>>      
>>      > On Apr 7, 2019, at 5:35 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
>>      >
>>      > Hi everyone,
>>      >
>>      > Something that I've been dealing with is the fact that regardless of
>>      > what cloud you're using, the naming structure is very much different.
>>      > While we aim to be interoperable, if I want to "boot an Debian Stretch
>>      > server", the image name will probably be different all over the
>>      > places.
>>      >
>>      > Is there some sort of way we can eliminate this by implementing a
>>      > standard naming convention which would allow us to use the same images
>>      > across all systems?
>>      >
>>      > I'm just opening the idea for discussion, I'd love to hear what others
>>      > think about this.
>>      >
>>      > Mohammed
>>      >
>>      > --
>>      > Mohammed Naser — vexxhost
>>      > -----------------------------------------------------
>>      > D. 514-316-8872
>>      > D. 800-910-1726 ext. 200
>>      > E. mnaser at vexxhost.com
>>      > W. https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvexxhost.com&amp;data=02%7C01%7Cmvoelker%40vmware.com%7C35dc7472fc9b465af68908d6bba19d77%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636902700146796905&amp;sdata=ek0QPuY4h0Bvso6dk3c%2BPWovZ4suu89a9Rv0Z1VliIY%3D&amp;reserved=0
>>      >
>>      
>>      
>>
> 
> 


From ifatafekn at gmail.com  Mon Apr  8 10:54:30 2019
From: ifatafekn at gmail.com (Ifat Afek)
Date: Mon, 8 Apr 2019 13:54:30 +0300
Subject: [Vitrage] Find solution on integrate vitrage to current monitor
In-Reply-To: <1923699737.906723.1554346789954.JavaMail.zimbra@viettel.com.vn>
References: <1135240140.823214.1554345841979.JavaMail.zimbra@viettel.com.vn>
 <1923699737.906723.1554346789954.JavaMail.zimbra@viettel.com.vn>
Message-ID: <CALxdkcxJnCsOom_=E8RdEbcKMewGC69ueUHThw4Ho6+cBhb2PQ@mail.gmail.com>

Hi,

If I understand correctly, InfluxDB is used for storing metrics, but it
does not handle the logic of when to raise an alarm, so integrating with it
will not help you. I'm not familiar with any tool that "converts" InfluxDB
metrics to alarms that are sent to Vitrage.

I think that the only way to integrate your alarms is to write a new
datasource for Kapacitor, since this specific monitor is not supported yet
in Vitrage. You can find details on how to write a new datasource here [1].

[1]
https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html

Best regards,
Ifat

On Thu, Apr 4, 2019 at 6:00 AM <hoanq13 at viettel.com.vn> wrote:

> Hi,
>
> I sent this mail for finding solution when integrate  vitrage to my
> current monitor system.
> I my system we use Tick stack monitor: with telegraf is collector metric,
> influxdb for storing metric, and kapacitor for alarming.
> It been work for a long while, all our monitor data in influxdb. I'm
> wondering  have any tool can read influxdb, create alarm so vitrage can get
> input alarm from it?.
> Or any ideal you can recommend me on integrate vitrage to my system?
>
> p/s: i was think about write datasource driver kapacitor can alarm
> vitrage, but it take time, and I'm not good at codding.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/22fcd785/attachment.html>

From sean.mcginnis at gmx.com  Mon Apr  8 11:25:15 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 06:25:15 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended
 Maintenance phase
In-Reply-To: <2cd9c88c-5c6c-ee42-b8ea-658484b4426b@gmail.com>
References: <20190404201557.GA6952@sm-workstation>
 <ad6511bb-27c7-7b3a-183e-13b3a441ed05@gmail.com>
 <20190406091008.GA26772@sm-workstation>
 <2cd9c88c-5c6c-ee42-b8ea-658484b4426b@gmail.com>
Message-ID: <20190408112514.GA29851@sm-xps>

On Sat, Apr 06, 2019 at 02:52:52PM -0500, Matt Riedemann wrote:
> On 4/6/2019 4:10 AM, Sean McGinnis wrote:
> > Backports can happen already to stable/stein. We just would not be able to do a
> > stable release off of there until next week - April 11 to be precise.
>
> Yeah and we've been doing backports but holding them until the stein GA - is
> it safe to assume we're past any last minute RC issues for stein and can
> start merging stable/stein backports to go into the first stable/stein
> release?
>

That is a good point, and one I almost followed up to my orginal comment about.
You are correct, the main reason teams may want to hold of on backporting
anything at this point would be on the off chance that there is a very critical
bug found before the final release. Only backporting that critical fix makes it
a lot easier than needing to pick up a bunch of not quite so critical changes.

The final RC deadline was last Thursday, but we did end up with a couple
projects that found bugs important enough to make an exception.

Final release happens this Wednesday. I would say it's probably safe now to
backport, but I suppose until that final release is complete, there is some
risk that something could still happen.

So lesson for the future for all of us - it probably is better to be
conservative like Nova has been and not actually start backporting fixes to the
current stable branch until it really has been released and entered that full
stable branch state.

Great point!

Sean


From sean.mcginnis at gmx.com  Mon Apr  8 11:28:44 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 06:28:44 -0500
Subject: [PTL][release][stable] Pike transitioning to Extended
 Maintenance phase
In-Reply-To: <20190408073151.GB7047@thor.bakeyournoodle.com>
References: <20190404201557.GA6952@sm-workstation>
 <20190408073151.GB7047@thor.bakeyournoodle.com>
Message-ID: <20190408112844.GB29851@sm-xps>

> > According to the stable policy, that should happen 18 months after the release
> > [0]. That means we should have made the switch in February, if my math is
> > right.
> >
> > We will need to work through the details to actually put that in effect, but
> > for now I wanted to remind teams that we do not do releases after a stable
> > branch enters this phase. So this is a call for action for any teams that have
> > been backporting fixes that time is short to get a final release out while you
> > can.
> >
> > The release dates for each cycle can be found on the releases site [1].
>
> Thanks Sean!
>
> How about this to catch us up:
>
> 1. This week I'll propose one change per team[1] to create a release
>    from the current HEAD for stable/pike and tag that as pike-em
> 2. Just like with other procedural releases teams are free to +/-1 /
>    suggest fixes.
> 3. We merge any that have PTL/Liaison +1 as we get the approvals
> 4. Any that aren't explicitly -1'd by April 22nd get merged that week
> 5. Others get discussed at the Summit/PTG.
> 6. We release the remainders during the week of May 6th
> 7. May 13th we formally transition pike to EM
>
>
> Yours Tony.

That sounds like a good plan to me, thanks Tony!

This should give teams some time after the stein work settles down to do any
final backports they think are important before that final release and
transition to EM.

I wonder if we should just make that the general policy that we will wait a few
weeks after the current series final release so there is a window where teams
don't need to be worrying both about current work and stable backport work. At
least once things get back to aligning on six month windows.

Sean


From sean.mcginnis at gmx.com  Mon Apr  8 11:33:35 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 06:33:35 -0500
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
Message-ID: <20190408113335.GC29851@sm-xps>

>
> Perhaps we can find a good pattern for
> having a README with badge types of things that includes actual content from
> the docs?

One concern to keep in mind if you start looking down this path is that most
projects use their README by default as their package long-description. That
means that when uploading a package to PyPi, it will use the content of the
README as the description that is shown for that package.

The rendering on PyPi, and the validation that they do that will reject the
package upload if it has README syntax errors, is not aware of any Sphinx
extensions we use in our normal docs, so pulling in other documentation into
the README could potentially cause release issues.

Sean


From sean.mcginnis at gmx.com  Mon Apr  8 11:41:00 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 06:41:00 -0500
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <20190408071321.GA7047@thor.bakeyournoodle.com>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
Message-ID: <20190408114100.GD29851@sm-xps>

>
> If needed, we could do 2 meetings one for AU+EU and then another for
> AU+US but I'd much rather have a single meeting to keep everyone on the
> same page.

I agree, I think just having one meeting is going to be best, even though it
will certainly make things a little more challenging for some.

>
> I've created a doodle poll: https://doodle.com/poll/xxa46wrndefyi6dk
>
> I picked Thursday as the day of the week for the poll but if if needed
> we can mov it to another day.
>

++ Thursday's have worked really well for me. We typically would try to get the
release countdown sent on Thursday's to make sure folks see it before leaving
for the weekend. So that along with Thursday's being the usual deadline days,
it's been a good checkpoint to make sure we have things covered.

> Yours Tony.
>
> [1] The current meeting time is 0200 for me.
> [2] https://www.worldtimebuddy.com/?pl=1&lid=21,312,5,8&h=21




From sean.mcginnis at gmx.com  Mon Apr  8 11:43:12 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 06:43:12 -0500
Subject: [release][kayobe] Release job failures
In-Reply-To: <CAFHSqWoMHVZz4pQSdLkaWMUKVbSKfc-wyh3Map0bWg-Hbcvkdg@mail.gmail.com>
References: <CAFHSqWoMHVZz4pQSdLkaWMUKVbSKfc-wyh3Map0bWg-Hbcvkdg@mail.gmail.com>
Message-ID: <20190408114311.GE29851@sm-xps>

On Mon, Apr 08, 2019 at 08:21:42AM +0000, Mark Goddard wrote:
> Hi,
>
> We've had a few release job failures in Kayobe [1]. I created some new tags
> on stable branches last week, and the release jobs failed with the
> following:
>
> Unable to freeze job graph: Unable to modify final job <Job
> trigger-readthedocs-webhook branches: None source:
> opendev/base-jobs/zuul.yaml at master#112> attribute
> variables={'rtd_webhook_id': '74820', 'rtd_project_name':
> 'kayobe-release-notes'} with variant <Job trigger-readthedocs-webhook
> branches: None source: openstack/kayobe/zuul.d/project.yaml at master#2>
>

You may need to check with some of the infra folks, but I think "Unable to
freeze job graph" errors are typically a sign of a problem with the zuul job
configuration. Something like a job being referenced for a queue that doesn't
actually have a definition anywhere or something along those lines.

> It's not clear from the email which branch, tag or job this affects. The
> message above references our readthedocs job which aims to publish release
> notes, although I can't see the expected releases on tarballs.o.o or PyPI.
>
> The RTD release note Zuul job is defined here [2], is it causing a problem?
> We also use the docs-on-readthedocs template to update our docs.
>
> [1]
> http://lists.openstack.org/pipermail/release-job-failures/2019-April/001117.html
> [2]
> https://github.com/openstack/kayobe/blob/44430a42421a7c59807a58cbbd67f90a154fd30a/zuul.d/project.yaml#L46
>
> Thanks,
> Mark


From frickler at offenerstapel.de  Mon Apr  8 11:52:49 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Mon, 08 Apr 2019 11:52:49 +0000
Subject: [chef][stable] Chef OpenStack retiring stable branches
Message-ID: <1554724369.4997.23.camel@offenerstapel.de>

The Chef OpenStack project still has a set of repos with stable/newton
branches, however those have been announced as EOL for more than a year
[0], but we missed to actually close them down. I plan to do so in a
couple of days unless there is some justified objection. See [1] for a
list of the affected repositories and the commit hashes that are
targeted to receive the "newton-eol" tag.
    
The situation with the stable/ocata branches is similar, but while we
did announce them as EOL in [0], too, the date mentioned there seems
wrong. Also, there seems to be some confusion about the situation for
the global OpenStack project, which doesn't seem to have retired
stable/ocata for any project yet. Still, we don't have any open patches
for stable/ocata, we don't have a working CI for it, and there also
isn't anyone using it known to me. So please respond if there is a
reason to keep the stable/ocata branches in their current state,
otherwise I'd start the process to tag them as EOL, too.

Jens

[0] https://docs.openstack.org/openstack-chef/queens/install/genealogy.
html#releases-summary
[1] https://review.openstack.org/649945
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/6957dd87/attachment.sig>

From frickler at offenerstapel.de  Mon Apr  8 11:56:05 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Mon, 08 Apr 2019 11:56:05 +0000
Subject: [chef] Renaming the Chef OpenStack project
Message-ID: <1554724565.4997.26.camel@offenerstapel.de>

In order to clean up some inconsistencies in project naming I have
submitted a request to the TC to update the name of the Chef OpenStack
project to "openstack-chef"[0]. The reasoning for this is twofold:

    a) It brings the name into line with other deployment projects
       like "OpenStack Ansible" and "OpenStack Charms". 
    b) In addition there are sometimes drawbacks when there is an
       embedded space in the name, so I opted for the hyphenated 
       version. Together with lowercasing everything this also has the 
       effect to match:
            - The name of our central repository
            - The name of our IRC channel
            - Our project name on Launchpad

Please let me know whether you agree with this change or if there are
any objections.
    
[0] https://review.openstack.org/648356
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/bbb2461b/attachment.sig>

From fungi at yuggoth.org  Mon Apr  8 12:21:17 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 12:21:17 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
Message-ID: <20190408122116.74lyls3tkudzbye2@yuggoth.org>

On 2019-04-08 00:42:46 +0000 (+0000), Guo, Ruijing wrote:
> I like Sean's idea. Can we create jobs based on nested KVM &
> customized OS? If CI is stable enough, we can move non-voting to
> voting.
[...]

There's nothing stopping you (or anyone) from creating such a CI
system to augment reporting on how specific workloads fair with
certain nested virt implementations.

The OpenDev CI system on the other hand is made of a heterogenous
mix of donations from a variety of service providers with various
configurations, and even some of those which advertise via CPU flags
that they offer nested virt acceleration don't provide a stable
implementation of it. There are already projects opportunistically
testing with nested virtualization support turned on in their jobs
to varying degrees of success, so it would be good to find out what
problems their recent experiences reveal. It's also very much the
case that even if it's working for a job today, it can start
crashing jobs randomly tomorrow when a kernel version changes on
guests or on hosts or we add another service provider into the mix.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/24ab72fb/attachment.sig>

From ruijing.guo at intel.com  Mon Apr  8 12:26:05 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Mon, 8 Apr 2019 12:26:05 +0000
Subject: [networking-ovn] nested virtualization in ovn ci
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C5564A@SHSMSX104.ccr.corp.intel.com>

Hi,

Does networking-ovn CI support nested virtualization? does it use OpenStack Infra?
Do you have plan to add OVSDPDK in networking-ovn CI?

I saw cpu flag vmx in 1) and didn't see vmx in 2). Why that?

1) http://logs.openstack.org/10/637510/2/check/networking-ovn-tempest-dsvm-ovs-master/5a0bf7c/logs/devstack-gate-setup-host.txt.gz
2) http://logs.openstack.org/65/643565/1/check/networking-ovn-tempest-dsvm-ovs-master/ff9d112/logs/devstack-gate-setup-host.txt.gz

Thanks,
-Ruijing


From doug at doughellmann.com  Mon Apr  8 12:29:12 2019
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 08 Apr 2019 08:29:12 -0400
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <20190406234459.iyt3lmwayulb5gud@yuggoth.org>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <04c7bd02c1897b42181407ac6b6e579f52b60795.camel@redhat.com>
 <2c54a81d-aee2-92e0-b026-7cd4987afcd0@debian.org>
 <20190406131250.i5p3dcptlywv3hsz@yuggoth.org>
 <89869bab-44e9-5d12-545d-e615d77b2a7e@debian.org>
 <20190406234459.iyt3lmwayulb5gud@yuggoth.org>
Message-ID: <m2sgus8yuf.fsf@doughellmann.com>

Jeremy Stanley <fungi at yuggoth.org> writes:

> On 2019-04-07 00:01:58 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> Why not having them in openstackdocstheme (or similar)?
>
> Right now the images are compiled based on data stored in the
> openstack/governance repository, so it would probably be simplest if
> they were packaged separately (otherwise that data would still need
> to be pulled into another codebase somehow).
> -- 
> Jeremy Stanley

We release the governance repo as a library [1] so that some of the release
tools can use the API to consume the data. We could bundle the images
into that library and have the theme use it.

BUT, that would make the images depend on the point-in-time of that
governance library release, and the tags do tend to change.

It would be better to, as Monty suggested, restructure the documentation
so that dynamic components aren't needed for the regular docs. One way
we could enforce that is by removing the settings that ignore references
to "nonlocal images", which we have in the sphinx config files for a few
projects [2]. This would ensure that only images checked into git (or
built from other artifacts that are) could be included in the docs we
build through sphinx.

[1] https://pypi.org/project/openstack-governance/
[2] http://codesearch.openstack.org/?q=image.nonlocal_uri&i=nope&files=&repos=

-- 
Doug


From fungi at yuggoth.org  Mon Apr  8 12:32:55 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 12:32:55 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
Message-ID: <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>

On 2019-04-08 03:39:51 +0000 (+0000), Mark Voelker wrote:
> I don’t think I have a perfect answer here, but just to add fodder
> to the discussion: it’s often been suggested in the past that one
> way of dealing with this is to simply ensure that you can bring
> your image to any cloud you work with.  Thus, rather than relying
> on an image to be named the same across the clouds you deal with,
> you can simply provide it yourself on those clouds so you know
> it’s identical.  Many of the caveats to this approach should be
> fairly obvious (footprint, duplication, quotas, format conversion,
> etc), but for some workflows it provides the sorts of useful
> guarantees an end user may want.
[...]

The other problem this works around is that, even if providers offer
similar images under the same names or via the same image property
metadata, there's no guarantee that what's on the images is
identical (same versions of the same set of packages preinstalled
with the same initial configurations, same root filesystem
formatting and parameters, et cetera). I too just upload identical
images to different providers, even for my personal use, so that I
have some increased assurance of parity for the instances I boot
there.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/ade0c12c/attachment.sig>

From cdent+os at anticdent.org  Mon Apr  8 12:48:51 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 13:48:51 +0100 (BST)
Subject: [placement] Virtual Pre-PTG
In-Reply-To: <alpine.OSX.2.21.1903251535420.32545@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1903251535420.32545@cdent-a01.vmware.com>
Message-ID: <alpine.OSX.2.11.1904081341530.9091@seed.local>

On Mon, 25 Mar 2019, Chris Dent wrote:

> I've committed to orchestrating and then summarizing several
> conversations through a series of email threads based on the topics
> we choose.
>
> To do that, we need to make sure that the etherpads [2,3] reflect the
> important topics a few weeks before the PTG, so we can have enough
> time to talk.
>
> I propose we start the process the week of the 8th, giving us 3
> weeks of discussion prior to the PTG, with the caveat that the week
> of the 22nd my availability will be limited. Between now and then
> make sure you topics get on the etherpads, along with as much
> additional info as you would normally put there. Don't fret if you
> think of something after the 8th, just put it on the etherpad as
> normal, and we'll figure it out.

I'm going to get this started later today using the "series of email
threads" mentioned above. I'll give them '[placement]' and '[ptg]'
and base them off whatever seems relavant from the two etherpads
[2,3]. As before, feel free to continue adding to the etherpads.

Also, note that I've framed in a retrospective etherpad [4] because
that's often useful. I've put some guidance on there, but to repeat
some of it:

* try to be blameless (in the sense of a devopsy blameless
   post-mortem)
* you don't need to restrict yourself to Stein
* avoid, at least for now, entering solution space: let's look retro
   first

> [2] https://etherpad.openstack.org/p/placement-ptg-train
> [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
[4] https://etherpad.openstack.org/p/placement-ptg-train-retrospective

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From mordred at inaugust.com  Mon Apr  8 14:07:01 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Mon, 8 Apr 2019 14:07:01 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <20190408113335.GC29851@sm-xps>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
Message-ID: <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>



On 4/8/19 11:33 AM, Sean McGinnis wrote:
>>
>> Perhaps we can find a good pattern for
>> having a README with badge types of things that includes actual content from
>> the docs?
> 
> One concern to keep in mind if you start looking down this path is that most
> projects use their README by default as their package long-description. That
> means that when uploading a package to PyPi, it will use the content of the
> README as the description that is shown for that package.
> 
> The rendering on PyPi, and the validation that they do that will reject the
> package upload if it has README syntax errors, is not aware of any Sphinx
> extensions we use in our normal docs, so pulling in other documentation into
> the README could potentially cause release issues.

Good point. Maybe we should just stop including README content in sphinx 
docs, and not do anything additional that's more complex?


From cboylan at sapwetik.org  Mon Apr  8 14:06:48 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Apr 2019 10:06:48 -0400
Subject: Nodepool not able to register node to jenkins.
In-Reply-To: <OFBC20EF03.08273D58-ON002583D6.00358FD6-002583D6.0038D8D8@notes.na.collabserv.com>
References: <OFBC20EF03.08273D58-ON002583D6.00358FD6-002583D6.0038D8D8@notes.na.collabserv.com>
Message-ID: <a6d5f165-0b5f-4145-8eb7-5cd89561aa89@www.fastmail.com>

On Mon, Apr 8, 2019, at 3:21 AM, Aman Kumar Sinha26 wrote:
> Hi OpenStack Community,
> I am facing a nodepool issue with an error message of 'TypeError: not 
> all arguments converted during string formatting',
> we tried to debug this error with a reference of [1] but found no luck 
> over there.
> We are using nodepool version 0.3.0 and jenkins 2.46.1, due to some 
> dependency we cannot upgrade the nodepool now.

Are you able to nodepool upgrade to 0.5.0? This was the last release that supported zuulv2 and Jenkins. It removed the myjenkins.py library shim though and relies only on the jenkins library which may help.

The other thing to check is whether or not you are setting values in the config for items like "labels" that are not valid strings.

> I am not sure is there anything that got updated recently in 
> openstack-infra that breaks our CI.
> FYI, we have run the install_puppet.sh and install_module.sh from[2] as 
> part of our CI setup recently.
> Please have a look at the logs[4][5], we have urllib3 already installed 
> on the system [3], as in [4] you will see no mudule urllib3.
> [1]http://lists.openstack.org/pipermail/openstack-infra/2017-June/005466.html
> [2]https://github.com/openstack-infra/system-config
> [3]http://paste.openstack.org/show/748995/
> [4]http://paste.openstack.org/show/748993/
> [5]http://paste.openstack.org/show/748994/
> 
> Thanks & Regards,
> Aman
>


From fungi at yuggoth.org  Mon Apr  8 14:11:51 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 14:11:51 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
Message-ID: <20190408141151.axi5wzuoqyewnyy5@yuggoth.org>

On 2019-04-08 14:07:01 +0000 (+0000), Monty Taylor wrote:
[...]
> Good point. Maybe we should just stop including README content in
> sphinx docs, and not do anything additional that's more complex?

I must admit, I find the simplicity of this solution extremely
compelling.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/44616017/attachment.sig>

From cdent+os at anticdent.org  Mon Apr  8 14:25:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 15:25:07 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
Message-ID: <alpine.OSX.2.11.1904081452240.9091@seed.local>


>From the etherpad [1]:

* do we need this?
* what is it?
* who is going to drive it?

As as I recall, allocation partitioning (distinct from
resource provider partitioning) is a way of declaring that a set of
allocations below to a specific service. This is useful as a way,
for example, of counting instances spawned via nova. Right now it is
possible to count vcpus, ram and disk but if something besides nova
is making allocations using those resource classes how do we
distinguish?

Of course it's important to also ask "should we distinguish?". If
there's a concept of unified limits does it matter whether a VCPU is
consume by _this_ nova or something else if they are consumed by the
same user?

This functionality is closely tied to resource provider
partitioning. In a complex placement scenario, where placement is
managing multiple instance spawning tools, in multiple cloud-like
things, it seems like both would be needed.

The ongoing work to implement quota counting in placement [2] has a
workaround for instances not being counted in placement, but the
"more than one nova per placement" limitation has to be documented.

How urgent is this? Is there anyone available to do the work this
cycle? How damaging is it to punt to U? What details are missing in
the above description?

[1] https://etherpad.openstack.org/p/placement-ptg-train
[2] https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Mon Apr  8 14:25:12 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 15:25:12 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
Message-ID: <alpine.OSX.2.11.1904081436290.9091@seed.local>


>From the etherpad [1]:

* do we need this?
* what is it?
* who is going to drive it?

As as I recall, resource provider partitioning (distinct from
allocation partitioning) is a way of declaring that a set of
resource providers are in a thing. This would allow, for example,
one placement to service multiple OpenStack clouds or for a
placement to be a part of a single pane of glass system in a FOG or
edge setup.

This was mentioned during Stein nova discussions [2] but since then
I've not personally heard a lot of discussion on this topic so it's
unclear if it is a pressing issue. Do we want to be build it so they
come, or wait until they come and then build it?

The discussion at [2] mentions the possibility of an
'openstack-shard' header (instead of query parameter) that would be
sent with any request to placement.

There is, however, no substantive discussion on the internal
implementation. Options:

* Do nothing (see above)
* Internally manipulate aggregates (all these resource providers
   below to shard X).
* Add a 1:1 or 1:N relation between an RP and a shard uuid in the
   DB.
* Use a trait! [3]

But before we get into implementation details we should discuss the
use cases for this (if any), the need to do it (if any), and the
people who will do it (if any). All three of those are thin at
this point.

[1] https://etherpad.openstack.org/p/placement-ptg-train
[2] around lines 243 on https://etherpad.openstack.org/p/nova-ptg-stein
     where both types (allocation/rp) of partitioning are discussed.
[3] Not for the trait strict constructionists.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Mon Apr  8 15:43:11 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 16:43:11 +0100 (BST)
Subject: [placement][ptg] code refactoring constraints and goals
Message-ID: <alpine.OSX.2.11.1904081618310.9091@seed.local>


>From the etherpad [1]

* We got a lot of value out of the ovo-ectomy and de-list. We're now
   at a stage where there is plenty more that could be done, but the
   choices are more subject to personal preference.

     * How (and should) we further split and shrink objects/resource_provider.py


We got a lot of value out of the big refactoring the removed OVO and
split objects/resource_provider.py into smaller files. It's also a
stated goal that we should continue refactoring and continuously
revisit existing code.

However, we started to stumble because we had some disagreements on
how to proceed. We should resolve those disagreements so we can
proceed (he said, obviously).

Questions that have come up (plus other ones I can think off the top
of my head):

* Is it worth reordering methods to some kind of arbitrary ordering?

* If a method or module is "long" (by some definition) does that
   make it bad?

* Where is the balance between backport hurting churn and keeping
   the mix fresh?

* Should there be a more cleanly defined boundary between the
   methods that marshal data (the top-level methods in objects/*.py)
   and those that talk to the persistence layer (also in
   objects/*.py)?

     * Do we need to define (better) or document the layers/boundaries
       in the system?

* How can we encourage a similar refactor/revisit-often attitude to
   the docs?

There are plenty of other refactoring related thoughts too. Have at.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From rico.lin.guanyu at gmail.com  Mon Apr  8 15:52:22 2019
From: rico.lin.guanyu at gmail.com (Rico Lin)
Date: Mon, 8 Apr 2019 23:52:22 +0800
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform from
 project to SIG
Message-ID: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>

Dear PowerVMStackers and Winstackers members

(This idea is from Thierry, so I'm just helping to trigger discussion here.)

We now have most of Working Groups migrate to SIGs, so it's
governance under both TCs and UCs. And to further look through, there are
some projects are potential SIG meterial.
PowerVMStackers and Winstackers are two identical targets. They all
required cross-project works to achieve their mission and kind of *special
interest* (One for PowerVM, and one for Windows support across OpenStack).

There are two questions I would hope team members from both teams can help
to answer.


   1. Is the mission for your project completed?
   2. Is the team still active?
   3. Any concerns or objections on moving from project to SIG?

If we agree to change from project to SIG, I expect most of the tools will
stay the way it is. The only thing for the first step should just change
your project definition from project to SIG (like from PowerVMStackers
to PowerVM SIG). So it will not cause the team any effort for sure.


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/a05cb724/attachment.html>

From cdent+os at anticdent.org  Mon Apr  8 16:03:52 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 17:03:52 +0100 (BST)
Subject: [placement][ptg] JSON payload for GET /a_c
Message-ID: <alpine.OSX.2.11.1904081645350.9091@seed.local>


>From the etherpad [1]

* would make things like "resource provider affinity" above easier.
   much easier. and let us express granular-ness less awkwardly, and
   let us add new and richer group_policy concepts (which is
   basically the affinity thing).

     * Brought up briefly in the above spec at
       https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst at 184

As clients making GET /allocation_candidates queries desire to
express more and more complexity [2], query parameters start to feel
cumbersome. At various times people have suggest that a JSON body
might be easier to manage. The first time was during the discussion
that resulted in the creation of the allocation_candidates resource.

My personal feeling on this is that if we have a way to satisfy a
use case without changing the API, even if it is cumbersome, we
should write in that mode first and then decide if adding the other
way is appropriate. This isn't simply because of some over-adherence
to YAGNI, but because we need to deliver on some of placement's
promise sooner than later and there don't seem to be a lot of people
around.

There may, however, be plenty of reasons that not everyone knows for
why this needs to happen. If so, please share them. Only once we
know those reasons should we start considering formats. What do we
need to express (and why do we need to express it) that we can't
express now?

[1] https://etherpad.openstack.org/p/placement-ptg-train

[2] https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst at 608

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cboylan at sapwetik.org  Mon Apr  8 16:04:25 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Apr 2019 12:04:25 -0400
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <20190408122116.74lyls3tkudzbye2@yuggoth.org>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
Message-ID: <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>

On Mon, Apr 8, 2019, at 5:21 AM, Jeremy Stanley wrote:
> On 2019-04-08 00:42:46 +0000 (+0000), Guo, Ruijing wrote:
> > I like Sean's idea. Can we create jobs based on nested KVM &
> > customized OS? If CI is stable enough, we can move non-voting to
> > voting.
> [...]
> 
> There's nothing stopping you (or anyone) from creating such a CI
> system to augment reporting on how specific workloads fair with
> certain nested virt implementations.
> 
> The OpenDev CI system on the other hand is made of a heterogenous
> mix of donations from a variety of service providers with various
> configurations, and even some of those which advertise via CPU flags
> that they offer nested virt acceleration don't provide a stable
> implementation of it. There are already projects opportunistically
> testing with nested virtualization support turned on in their jobs
> to varying degrees of success, so it would be good to find out what
> problems their recent experiences reveal. It's also very much the
> case that even if it's working for a job today, it can start
> crashing jobs randomly tomorrow when a kernel version changes on
> guests or on hosts or we add another service provider into the mix.

Right one of the biggest concerns we have is the lack of observed stability with nested virt. This isn't a theoretical concern. In the not too distant past Tripleo jobs running on CentOS were crashing the "middle" VM and no one noticed until I started looking into job failures. The fix for that required a base hypervisor kernel update which is not something we control.

That said understanding requirements here (which was asked for earlier in the thread, but I don't see a response) is useful when trying to figure out the best way to approach these situations. It is possible there are other reasonable avenues that could be taken.

Clark


From thierry at openstack.org  Mon Apr  8 16:04:39 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 8 Apr 2019 18:04:39 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
Message-ID: <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>

Rico Lin wrote:
> We now have most of Working Groups migrate to SIGs, so it's 
> governance under both TCs and UCs. And to further look through, there 
> are some projects are potential SIG meterial.
> PowerVMStackers and Winstackers are two identical targets. They all 
> required cross-project works to achieve their mission and kind of 
> *special interest* (One for PowerVM, and one for Windows support across 
> OpenStack).

Yes, I think it would make a lot of sense...

What defines those groups is not the software bits that they produce, 
but their overall goals (getting OpenStack to run on Windows, supporting 
PowerVM technology in OpenStack). The repositories that they maintain is 
just a means toward this larger end, and a lot of their work is actually 
done within existing repositories from other project teams.

The SIG model seems therefore a better fit than the "Project team" model 
which is more centered around a specific component and/or a set of 
repositories.

-- 
Thierry Carrez (ttx)


From fungi at yuggoth.org  Mon Apr  8 16:11:17 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 16:11:17 +0000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
Message-ID: <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>

On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote:
[...]
> What defines those groups is not the software bits that they
> produce, but their overall goals (getting OpenStack to run on
> Windows, supporting PowerVM technology in OpenStack). The
> repositories that they maintain is just a means toward this larger
> end, and a lot of their work is actually done within existing
> repositories from other project teams.
[...]

This brings up an interesting question, though. The contributors to
those Winstackers and PowerVMstackers repositories today are able to
vote in technical committee elections. Should we consider an
amendment to the charter to include contributors to SIG-owned
repositories in the TC electorate?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/e1be8272/attachment.sig>

From openstack at fried.cc  Mon Apr  8 16:13:38 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 8 Apr 2019 11:13:38 -0500
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.11.1904081436290.9091@seed.local>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
Message-ID: <48c52006-b859-1542-1587-a311c25b9d7f@fried.cc>

Does this have anything to do with the topic of separate projects owning
different resource providers in the same tree? Where "owning" indicates
responsibility for creation, positioning (i.e. where in the tree, who's
the parent), and inventory management, but *not* allocations.

This was in the context of e.g. neutron owning bandwidth RPs, or cyborg
owning FPGA RPs.

In Denver (possibly twice) we talked about the various actors actually
needing to know this. I don't remember exactly why - was it only so that
each actor knows not to stomp on providers it doesn't own? And is that a
problem that needs a solution other than each actor just knowing which
providers it's responsible for and leaving anything else alone?

If this is unrelated to the subject, please kill this subthread.

efried


From cdent+os at anticdent.org  Mon Apr  8 16:16:37 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 17:16:37 +0100 (BST)
Subject: [placement][ptg] Enabling other projects to continue with placement
 or get started
Message-ID: <alpine.OSX.2.11.1904081713160.9091@seed.local>


>From the etherpad [1]

* blazar
* cinder
* cyborg
* ironic
* neutron

Who else?

This is a bit of a catch-many topic. Despite being birthed in Nova,
Placement is designed to be useful to lots of different services.

There's already some time defined at the PTG to talk about the
interaction of Ironic, Blazar, and Placement.

What are the issues with that?

What are the issues other services are experiencing with Placement?
Preventing people from using Placement?

What services are using Placement and the team doesn't know about
it?


[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Mon Apr  8 16:20:01 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 17:20:01 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <48c52006-b859-1542-1587-a311c25b9d7f@fried.cc>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <48c52006-b859-1542-1587-a311c25b9d7f@fried.cc>
Message-ID: <alpine.OSX.2.11.1904081717580.9091@seed.local>

On Mon, 8 Apr 2019, Eric Fried wrote:

> Does this have anything to do with the topic of separate projects owning
> different resource providers in the same tree? Where "owning" indicates
> responsibility for creation, positioning (i.e. where in the tree, who's
> the parent), and inventory management, but *not* allocations.

This is different: Multiple clouds, one placement.

However, what you describe is probably a thing that warrants discussion.
If you agree, stick it on the etherpad with these two paragraphs and
I'll come around to it, eventually, in this process.

> This was in the context of e.g. neutron owning bandwidth RPs, or cyborg
> owning FPGA RPs.
>
> In Denver (possibly twice) we talked about the various actors actually
> needing to know this. I don't remember exactly why - was it only so that
> each actor knows not to stomp on providers it doesn't own? And is that a
> problem that needs a solution other than each actor just knowing which
> providers it's responsible for and leaving anything else alone?

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Mon Apr  8 16:37:00 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 17:37:00 +0100 (BST)
Subject: [placement][ptg] Keeping osc-placement healthy
Message-ID: <alpine.OSX.2.11.1904081734490.9091@seed.local>



>From the etherpad [1]:

* It is behind (in microversions) and sometimes hard to remember

* It's functional tests require a working devstack, which is a bit meh
     * Maybe something like https://vcrpy.readthedocs.io/en/latest/
       could help (reasonable given microversions)

* (edleafe) It might be useful to have an osc-placement lead (czar?
   princess? mayor?) who can devote some of their time to this and
   help coordinate others. I might be able to rustle up some cycles.

Not much to add to the above. What additional ideas to people have.
Who (in addition to Ed) has some time to care about osc-placement?
What do people think of vcrpy? What else?


[1] https://etherpad.openstack.org/p/placement-ptg-train


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From gr at ham.ie  Mon Apr  8 16:42:12 2019
From: gr at ham.ie (Graham Hayes)
Date: Mon, 8 Apr 2019 17:42:12 +0100
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
 <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>
Message-ID: <cfa6617c-c619-63e1-b84a-8ce0ccb09695@ham.ie>

On 08/04/2019 17:11, Jeremy Stanley wrote:
> On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> What defines those groups is not the software bits that they
>> produce, but their overall goals (getting OpenStack to run on
>> Windows, supporting PowerVM technology in OpenStack). The
>> repositories that they maintain is just a means toward this larger
>> end, and a lot of their work is actually done within existing
>> repositories from other project teams.
> [...]
> 
> This brings up an interesting question, though. The contributors to
> those Winstackers and PowerVMstackers repositories today are able to
> vote in technical committee elections. Should we consider an
> amendment to the charter to include contributors to SIG-owned
> repositories in the TC electorate?
> 

100% yes.

E.G. - Someone who contributes to the api-sig repos is as deserving of a
vote for the TC as someone who commits to designate / glance / nova
neutron.

(I used api-sig as an example, as I think pretty much anyone who has
committed there already had a vote due to other openstack commits, but
if we are going to move into a situation where we would remove peoples
ability to vote we should adjust our processes to avoid it).

- Graham


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/8007b58d/attachment.sig>

From cdent+os at anticdent.org  Mon Apr  8 16:42:45 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 17:42:45 +0100 (BST)
Subject: [placement][ptg] Gate health management
Message-ID: <alpine.OSX.2.11.1904081740220.9091@seed.local>


>From the etherpad [1]:

* We have to run grenade and tempest. They are both very very slow
   and very unreliable (compared to the other tests). That's a pain.
   How do we help fix it?
     * Profile where time is spent setting up devstack?
     * Figure out where the slowest tests are which aren't marked
       slow: http://status.openstack.org/elastic-recheck/#1783405
     * Figure out which (non-interop) tests in tempest could be split
       out to per-project repos or tempest plugins, i.e. if there are
       compute API tests which don't rely on other services or a
       hypervisor, and are just API/DB, they could be dealt with in
       nova functional tests instead.
     * Similarly: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000868.html

The main thing to add here: We can come up with strategies on how to
fix it, but how can we assure that there is time/energy/people to do
that work?

[1] https://etherpad.openstack.org/p/placement-ptg-train
-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From mriedemos at gmail.com  Mon Apr  8 16:57:51 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 8 Apr 2019 11:57:51 -0500
Subject: [placement][ptg] Gate health management
In-Reply-To: <alpine.OSX.2.11.1904081740220.9091@seed.local>
References: <alpine.OSX.2.11.1904081740220.9091@seed.local>
Message-ID: <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>

On 4/8/2019 11:42 AM, Chris Dent wrote:
>      * Figure out where the slowest tests are which aren't marked
>        slow: http://status.openstack.org/elastic-recheck/#1783405

I tried something related to this last week to run the tempest-full* 
scenario tests with 2 workers concurrently rather than serially:

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

But looking at the stackviz output on that it doesn't seem to have 
worked at all, the scenario tests running at the end appear to still be 
running in serial. I don't know if that is a bug in *testr* or what - 
maybe mtreinish knows.

-- 

Thanks,

Matt


From mvanwinkle at salesforce.com  Mon Apr  8 17:02:22 2019
From: mvanwinkle at salesforce.com (Matt Van Winkle)
Date: Mon, 8 Apr 2019 12:02:22 -0500
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <cfa6617c-c619-63e1-b84a-8ce0ccb09695@ham.ie>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
 <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>
 <cfa6617c-c619-63e1-b84a-8ce0ccb09695@ham.ie>
Message-ID: <CA+eV8ih6z7ROW=SjnGjX8=xYSD5pxJuu+HqaEiHnvBY9vTaDKQ@mail.gmail.com>

On Mon, Apr 8, 2019 at 11:46 AM Graham Hayes <gr at ham.ie> wrote:

> On 08/04/2019 17:11, Jeremy Stanley wrote:
> > On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> What defines those groups is not the software bits that they
> >> produce, but their overall goals (getting OpenStack to run on
> >> Windows, supporting PowerVM technology in OpenStack). The
> >> repositories that they maintain is just a means toward this larger
> >> end, and a lot of their work is actually done within existing
> >> repositories from other project teams.
> > [...]
> >
> > This brings up an interesting question, though. The contributors to
> > those Winstackers and PowerVMstackers repositories today are able to
> > vote in technical committee elections. Should we consider an
> > amendment to the charter to include contributors to SIG-owned
> > repositories in the TC electorate?
> >
>
> 100% yes.
>
> E.G. - Someone who contributes to the api-sig repos is as deserving of a
> vote for the TC as someone who commits to designate / glance / nova
> neutron.
>
> (I used api-sig as an example, as I think pretty much anyone who has
> committed there already had a vote due to other openstack commits, but
> if we are going to move into a situation where we would remove peoples
> ability to vote we should adjust our processes to avoid it).
>
> - Graham
>
>
>
FWIW - we have also tried to include SIG activity as criteria for AUC
status and voting in the UC election.

VW

-- 
Matt Van Winkle
Senior Manager, Software Engineering | Salesforce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/7529ca10/attachment-0001.html>

From cboylan at sapwetik.org  Mon Apr  8 17:03:50 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Apr 2019 13:03:50 -0400
Subject: [placement][ptg] Gate health management
In-Reply-To: <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>
References: <alpine.OSX.2.11.1904081740220.9091@seed.local>
 <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>
Message-ID: <1ed9e94f-4a6b-48e3-99f8-70d69e2bb614@www.fastmail.com>



On Mon, Apr 8, 2019, at 9:58 AM, Matt Riedemann wrote:
> On 4/8/2019 11:42 AM, Chris Dent wrote:
> >      * Figure out where the slowest tests are which aren't marked
> >        slow: http://status.openstack.org/elastic-recheck/#1783405
> 
> I tried something related to this last week to run the tempest-full* 
> scenario tests with 2 workers concurrently rather than serially:
> 
> https://review.openstack.org/#/c/650300/
> 
> But looking at the stackviz output on that it doesn't seem to have 
> worked at all, the scenario tests running at the end appear to still be 
> running in serial. I don't know if that is a bug in *testr* or what - 
> maybe mtreinish knows.

I might not be looking in the right place but the logs [0] seem to show the scenario tests running with 4 workers at the end of the job. I do know that tempest aggregates jobs by class in a worker which does mean if you get a bunch of slower classes (by test runtime) in a single worker that one worker will spend more time running. This does seem to have happened with the first tox tempest run in that job. Worker zero ran for an additional 15 minutes after the other three workers had completed.

[0] http://logs.openstack.org/00/650300/1/check/tempest-full/1edb016/job-output.txt.gz#_2019-04-05_16_01_12_702732


From openstack at fried.cc  Mon Apr  8 17:05:00 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 8 Apr 2019 12:05:00 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <alpine.OSX.2.11.1904081618310.9091@seed.local>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
Message-ID: <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>



On 4/8/19 10:43 AM, Chris Dent wrote:
>     * How (and should) we further split and shrink
> objects/resource_provider.py

To be specific here:

objects/resource_provider.py is currently ~2KLOC. That's not *horrible*
(see below), and if it really didn't lend itself to being further
subdivided, I would say we shouldn't force it just for the sake of
making that number smaller.

However, IMO, this file logically deals with several things:

* Resource provider inventory/capacity/usage
* Resource provider membership in aggregates
* Traits on resource providers
* Creating, updating, and deleting resource providers
* Finding resource providers in various ways

If you look at the structure of the file (in its current order - see
below) these groupings are pretty clear.

Note the presence of "resource provider" in each bullet above. We
already have separate modules for dealing with e.g. CRUD of traits in
their own right. Though the mapping isn't 1:1 with the above list.

So we have the following options, I think:

(1) Do nothing. Leave objects/resource_provider.py as is.
(2) Move X-related stuff into the base X.py module, so like move things
related to "Traits on resource providers" into objects/trait.py. This
level of shuffle would probably entail things like creating a new module
for aggregate.py
(3) Split the above into separate modules while preserving their
resource_provider-ness. From the perspective of code consuming the
modules, this would look like:

from placement.objects import resource_provider as rp_crud
from placement.objects.resource_provider import trait as rp_trait
from placement.objects.resource_provider import search as rp_search
from placement.objects import trait
...
# Do CRUD-y stuff with resource providers
rp = rp_crud.ResourceProvider(...)
rp.create()
# Do trait stuff
t = trait.Trait(...)
t.create()
# Do trait-y stuff with resource providers
rp_trait.add_traits_to_provider(rp, [t])
# Do search-y stuff with resource providers
rp_search.get_all_by_filters(...)

To me, this is nice and intuitive.

The issue is the module hierarchy. As written above, it would entail
putting the CRUD-y stuff into objects/resource_provider/__init__.py,
which some folks don't like.

I suppose we could have objects/resource_provider/crud.py, but that
doesn't match the pattern for other things like objects/trait.py

Discuss.

> * Is it worth reordering methods to some kind of arbitrary ordering?

My preference on this: keep related methods/classes/etc. near each other
in the file.

Pros:
* Intuitive.
* Increases the probability that, when I'm looking at a method that
calls another method, both methods will fit on my screen at the same
time. (Workaround: multiple editor windows to the same file.)

Cons:
* Sometimes there's no sensible grouping, which makes this hard to
define and therefore hard to follow (and hard to enforce, if that's a
thing we want to do).
* Ability to know exactly where to look to find something. (Workaround:
Use a real IDE, where you can do a project-wide search for a symbol,
hotkey from a symbol's use to its definition, etc. Also you can choose
to view a module's skeleton in its real order *or* alphabetically.)

> * If a method or module is "long" (by some definition) does that
>   make it bad?

Not to the point where we should do something like implement sonar.
Having had experience with that, it just ain't worth the hassle.
However, there is such a thing as too long. Certain nova libvirt modules
come to mind. For those of us who do choose to use real IDEs, these can
take a long time to process (in-band syntax checking, symbol correlation
highlighting, git blame, etc.). I'm going to go out on a limb and say we
should strive really hard never to have a module in the 5-digit LOCs.
And it would be really nice to stay under 2KLOC, but only if it doesn't
feel forced.

> * Where is the balance between backport hurting churn and keeping
>   the mix fresh?

I'm not sure "fresh" is the heaviest hitter on the plus side. Making the
code organized and crisp and usable (from a developer standpoint) and
maintainable is the main thing to me.

On the minus side, in addition to backport pain, there's the difficulty
tracking down the change that did a thing. Run git blame today and it
looks like Chris wrote virtually the whole thing in a small number of
massive monolithic chunks. You have to use bisect or similar to track
something down. To me, this is the biggest pain point.

So I think we should strive to get to a point where the code structure
is "good enough" and then stop doing huge refactors. That way, as we
move forward, changes will accumulate on that base and things will look
more "normal" history-wise.

> * Should there be a more cleanly defined boundary between the
>   methods that marshal data (the top-level methods in objects/*.py)
>   and those that talk to the persistence layer (also in
>   objects/*.py)?
> 
>     * Do we need to define (better) or document the layers/boundaries
>       in the system?

Sure, if we can find a fairly clean split. I don't have this enough in
my head to volunteer to do it, but I'll review it if someone else does :)

> * How can we encourage a similar refactor/revisit-often attitude to
>   the docs?

Fostering the culture that way, as we're doing. Bringing it up
periodically. Having a "doc sweep day" where members of the/a (sub)team
volunteer to each read a chunk of doc/code thoroughly?

efried


From mriedemos at gmail.com  Mon Apr  8 17:05:59 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 8 Apr 2019 12:05:59 -0500
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <alpine.OSX.2.11.1904081734490.9091@seed.local>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
Message-ID: <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>

On 4/8/2019 11:37 AM, Chris Dent wrote:
> * It is behind (in microversions) and sometimes hard to remember

Part of this is on the core team IMO. For nova compute API microversion 
changes we also require a corresponding change in python-novaclient 
since the client is capped at the microversion it supports, and that is 
used when doing version negotiation with the server to determine the 
default version to use for the CLI (which is a different behavior from 
openstack CLI which just defaults to 2.1 for everything).

Anyway, the point is, we/I haven't considered a nova blueprint which 
adds a microversion as complete until the python-novaclient change is 
also merged.

osc-placement has sort of missed this because of an out of sight / out 
of mind kind of situation. With StoryBoard tracking placement features 
we could definitely track something like the server side work in 
placement itself as a task and the osc-placement related change as 
another task, so the overall story isn't complete until both parts are 
done (or the CLI task is invalidated for whatever reason - not all 
microversions require CLI changes).

Anyway, from a project management standpoint, it always helped me to 
know which nova blueprints weren't done yet because they still needed 
the CLI changes and then follow up on those.

> 
> * It's functional tests require a working devstack, which is a bit meh

I'm not familiar with vcrpy but a simple improvement if we're worried 
about the time it takes to spin up devstack for these functional jobs is 
simply trim down the list of enabled services in the devstack run. By 
default devstack is running with most everything [1] - for these tests 
we should be able to just enable keystone and placement. Granted I think 
devstack-gate modifies ENABLED_SERVICES a bit but you get the idea: we 
don't need glance/cinder/nova/neutron/etcd/tempest/horizon enabled in 
devstack for osc-placement functional tests.

[1] 
https://github.com/openstack-dev/devstack/blob/a6e4e42fb3461b61e91ae63477462a3c3a8fe73b/stackrc#L64

-- 

Thanks,

Matt


From sean.mcginnis at gmx.com  Mon Apr  8 17:13:22 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 12:13:22 -0500
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
Message-ID: <20190408171321.GA2767@sm-workstation>

> >
> > The rendering on PyPi, and the validation that they do that will reject the
> > package upload if it has README syntax errors, is not aware of any Sphinx
> > extensions we use in our normal docs, so pulling in other documentation into
> > the README could potentially cause release issues.
>
> Good point. Maybe we should just stop including README content in sphinx
> docs, and not do anything additional that's more complex?

That would be my preference. :)


From fungi at yuggoth.org  Mon Apr  8 17:29:27 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 17:29:27 +0000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <CA+eV8ih6z7ROW=SjnGjX8=xYSD5pxJuu+HqaEiHnvBY9vTaDKQ@mail.gmail.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
 <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>
 <cfa6617c-c619-63e1-b84a-8ce0ccb09695@ham.ie>
 <CA+eV8ih6z7ROW=SjnGjX8=xYSD5pxJuu+HqaEiHnvBY9vTaDKQ@mail.gmail.com>
Message-ID: <20190408172927.emf2wjhcvnh52zxq@yuggoth.org>

On 2019-04-08 12:02:22 -0500 (-0500), Matt Van Winkle wrote:
[...]
> FWIW - we have also tried to include SIG activity as criteria for
> AUC status and voting in the UC election.

Yes, I thought about mentioning that as well. I see the two as a
great potential combination: allowing contributors to SIG
repositories could give the right to vote in both TC and UC
elections due to the broader scope of the work in which they are
involved.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/a986a744/attachment.sig>

From dtantsur at redhat.com  Mon Apr  8 17:40:00 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 8 Apr 2019 19:40:00 +0200
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
Message-ID: <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>

On 4/8/19 4:07 PM, Monty Taylor wrote:
> 
> 
> On 4/8/19 11:33 AM, Sean McGinnis wrote:
>>>
>>> Perhaps we can find a good pattern for
>>> having a README with badge types of things that includes actual content from
>>> the docs?
>>
>> One concern to keep in mind if you start looking down this path is that most
>> projects use their README by default as their package long-description. That
>> means that when uploading a package to PyPi, it will use the content of the
>> README as the description that is shown for that package.
>>
>> The rendering on PyPi, and the validation that they do that will reject the
>> package upload if it has README syntax errors, is not aware of any Sphinx
>> extensions we use in our normal docs, so pulling in other documentation into
>> the README could potentially cause release issues.
> 
> Good point. Maybe we should just stop including README content in sphinx docs, 
> and not do anything additional that's more complex?
> 

Honestly, this means copy-paste and that one of the copies will probably get 
outdated.


From smooney at redhat.com  Mon Apr  8 17:58:33 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 08 Apr 2019 18:58:33 +0100
Subject: [placement][ptg] JSON payload for GET /a_c
In-Reply-To: <alpine.OSX.2.11.1904081645350.9091@seed.local>
References: <alpine.OSX.2.11.1904081645350.9091@seed.local>
Message-ID: <9e1b48ade60417f8e7681635cbae1e8e3cc9f247.camel@redhat.com>

On Mon, 2019-04-08 at 17:03 +0100, Chris Dent wrote:
> From the etherpad [1]
> 
> * would make things like "resource provider affinity" above easier.
>    much easier. and let us express granular-ness less awkwardly, and
>    let us add new and richer group_policy concepts (which is
>    basically the affinity thing).
> 
>      * Brought up briefly in the above spec at
>        
> https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst at 184
> 
> As clients making GET /allocation_candidates queries desire to
> express more and more complexity [2], query parameters start to feel
> cumbersome. At various times people have suggest that a JSON body
> might be easier to manage. The first time was during the discussion
> that resulted in the creation of the allocation_candidates resource.
> 
> My personal feeling on this is that if we have a way to satisfy a
> use case without changing the API, even if it is cumbersome, we
> should write in that mode first and then decide if adding the other
> way is appropriate. This isn't simply because of some over-adherence
> to YAGNI, but because we need to deliver on some of placement's
> promise sooner than later and there don't seem to be a lot of people
> around.
for what its worth i think haveing a richer way to express queries
to the allcoation candiates enpoint beyond a query sting.

technically i belive its not standards compliant to have a get
request contain a body. some implemeention allow it but
if you use a body in a get request i belive it causes issue with loadblancer/
proxy servers so if we do support a query in a body it will have to be a post or put
depending on how we choose to model it.

the main usecase i have for an extention to allocation candiates is to facilitate
specifying the releationship between numbered request groups.

this is requried for numa affiniy but its not the only usecase or requirement.

> 
> There may, however, be plenty of reasons that not everyone knows for
> why this needs to happen. If so, please share them. Only once we
> know those reasons should we start considering formats. What do we
> need to express (and why do we need to express it) that we can't
> express now?
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 
> [2] https://review.openstack.org/#/c/555081/22/specs/train/approved/cpu-resources.rst at 608
> 
> -- 
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent



From sean.mcginnis at gmx.com  Mon Apr  8 18:13:37 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 8 Apr 2019 13:13:37 -0500
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
Message-ID: <20190408181337.GA4622@sm-workstation>

> > >
> > > The rendering on PyPi, and the validation that they do that will reject the
> > > package upload if it has README syntax errors, is not aware of any Sphinx
> > > extensions we use in our normal docs, so pulling in other documentation into
> > > the README could potentially cause release issues.
> >
> > Good point. Maybe we should just stop including README content in sphinx
> > docs, and not do anything additional that's more complex?
> >
>
> Honestly, this means copy-paste and that one of the copies will probably get
> outdated.
>

What is in the README that is needed in the documentation? For me, those have
always been entirely different audiences and therefore different content.

Maybe it just needs a different perspective for these project from how they've
used them so far?


From mtreinish at kortar.org  Mon Apr  8 18:28:53 2019
From: mtreinish at kortar.org (Matthew Treinish)
Date: Mon, 8 Apr 2019 14:28:53 -0400
Subject: [placement][ptg] Gate health management
In-Reply-To: <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>
References: <alpine.OSX.2.11.1904081740220.9091@seed.local>
 <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>
Message-ID: <20190408182853.GA19945@sinanju.localdomain>

On Mon, Apr 08, 2019 at 11:57:51AM -0500, Matt Riedemann wrote:
> On 4/8/2019 11:42 AM, Chris Dent wrote:
> >      * Figure out where the slowest tests are which aren't marked
> >        slow: http://status.openstack.org/elastic-recheck/#1783405
> 
> I tried something related to this last week to run the tempest-full*
> scenario tests with 2 workers concurrently rather than serially:
> 
> https://review.openstack.org/#/c/650300/
> 
> But looking at the stackviz output on that it doesn't seem to have worked at
> all, the scenario tests running at the end appear to still be running in
> serial. I don't know if that is a bug in *testr* or what - maybe mtreinish
> knows.
> 

This was a concious decision made to reduce the load during the scenario tests.
The scenario tests are run serially after all the other tests are run in
parallel. [1] The volume tests in particular were stressing the test
environments a lot ~2yrs ago so this was done to mitigate that. There are
more details in the commit message making the change:

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

(FWIW I mildly disagreed with this direction, but not enough to block it)


As for how best to determine this. We actually aggregate all the data already
in the subunit2sql db. openstack-health does provide a slowest job list
aggregated over time per job using this data:

http://status.openstack.org/openstack-health/#/job/tempest-full-py3

You just change the sort column to "Mean Runtime". I think there is a bug
in the rolling average function there because those numbers look wrong, but
it should be relative numbers.

I also had this old script on my laptop [2] which I used to get a list of
tests ordered by average speed (over the last 300 runs) filtered for those
which took > 10 seconds. I ran this just now and generated this list:

http://paste.openstack.org/show/749016/

The script is easily modifiable to change job or number of runs.
(I also think I've shared a version of it on ML before)

-Matt Treinish

[1] https://github.com/openstack/tempest/blob/master/tox.ini#L107-L109
[2] http://paste.openstack.org/show/749015/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/efd548ee/attachment.sig>

From cdent+os at anticdent.org  Mon Apr  8 18:37:33 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 19:37:33 +0100 (BST)
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
Message-ID: <alpine.OSX.2.21.1904081932190.88564@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Eric Fried wrote:

>> * Where is the balance between backport hurting churn and keeping
>>   the mix fresh?
>
> I'm not sure "fresh" is the heaviest hitter on the plus side. Making the
> code organized and crisp and usable (from a developer standpoint) and
> maintainable is the main thing to me.

Will come back to the rest of the message (summary: lgtm)  another
time, but I wanted to clarify "fresh": In my experience, the
community that surrounds code is better in a variety of ways when
_all_ the code managed by that community is visited regularly. One
of the easiest and most rewarding ways to do that visiting is to be
intentional about doing regular refactoring. Again, in my experience,
this process keeps everybody (old and new) up to date on what's
going on and regularly finds bugs, typos and inefficiencies in the
code and misapprehensions in the community.

All of which probably equates to "organized and crisp and usable"
but is more explicit about the mechanics that get it there and the
people surrounding it.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Mon Apr  8 18:44:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 8 Apr 2019 19:44:07 +0100 (BST)
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
 <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
Message-ID: <alpine.OSX.2.21.1904081937400.88564@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Matt Riedemann wrote:

> osc-placement has sort of missed this because of an out of sight / out of 
> mind kind of situation. With StoryBoard tracking placement features we could 
> definitely track something like the server side work in placement itself as a 
> task and the osc-placement related change as another task, so the overall 
> story isn't complete until both parts are done (or the CLI task is 
> invalidated for whatever reason - not all microversions require CLI changes).

Yeah, I think we can probably help this situation if we follow the
process I've started describing in
https://docs.openstack.org/placement/latest/contributor/contributing.html#new-features
where it says "Work items that are described in a spec should be
reflected as tasks created on the originating story. Update the
story with additional tasks as they are discovered."

We should make sure that any osc-placement obligations are one of
those tasks (and that should probably be a bullet in those docs).

>> * It's functional tests require a working devstack, which is a bit meh
>
> I'm not familiar with vcrpy but a simple improvement if we're worried about 
> the time it takes to spin up devstack for these functional jobs is simply 
> trim down the list of enabled services in the devstack run. By default 
> devstack is running with most everything [1] - for these tests we should be 
> able to just enable keystone and placement.

Yes, that's probably a good idea to speed up the gate side of
things, but what I'm hoping we could figure out is a way to make it so
on the dev side of things we don't need a running devstack for the
test -> fix iterative cycle. The majority of the actually useful
tests in osc-placement are integration tests (but labeled
functional) and thus rather costly to run for the sake of
development. vcrpy or requests-mock could potentially help us create real
functional tests.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From kennelson11 at gmail.com  Mon Apr  8 18:51:35 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 8 Apr 2019 11:51:35 -0700
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <20190408071321.GA7047@thor.bakeyournoodle.com>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
Message-ID: <CAJ6yrQg=BLGZ5scU7r2zHXC4uoMWF9J-o4T9T+7wUQ1qUiinyw@mail.gmail.com>

On Mon, Apr 8, 2019 at 12:14 AM Tony Breeds <tony at bakeyournoodle.com> wrote:

> Hello all,
>     Now that the world has completed it's biannual calendar confusion
> dance, and Stein is pretty darn close to being released.  I'd like to
> move the release team meeting to a time I can attend[1]
>
> It's going to be hard to find a time that works for the whole team given
> out 'follow the sun' support model.
>
> IIUC we have[2]:
>  * Australia
>  * Europe
>  * US East
>  * US Central
>  * US West
>
> Which means someone (or some people) are going to be inconvenienced.
>
> If needed, we could do 2 meetings one for AU+EU and then another for
> AU+US but I'd much rather have a single meeting to keep everyone on the
> same page.
>
> I've created a doodle poll: https://doodle.com/poll/xxa46wrndefyi6dk
>
> I picked Thursday as the day of the week for the poll but if if needed
> we can mov it to another day.
>
>
Thursday for you maybe. The times mostly show on Wednesday for US + EU
people. Which is fine for me, just wanted to point that out in case we were
trying to keep it closer to the end of the week.

Maybe we will be even more on top of things now with our PTL living in the
future.


> Yours Tony.
>
> [1] The current meeting time is 0200 for me.
> [2] https://www.worldtimebuddy.com/?pl=1&lid=21,312,5,8&h=21


-Kendall (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/78cbda8c/attachment-0001.html>

From ed at leafe.com  Mon Apr  8 19:20:39 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 8 Apr 2019 14:20:39 -0500
Subject: [placement][ptg] JSON payload for GET /a_c
In-Reply-To: <9e1b48ade60417f8e7681635cbae1e8e3cc9f247.camel@redhat.com>
References: <alpine.OSX.2.11.1904081645350.9091@seed.local>
 <9e1b48ade60417f8e7681635cbae1e8e3cc9f247.camel@redhat.com>
Message-ID: <64BC4203-4223-447D-B303-E6041A2678DC@leafe.com>

On Apr 8, 2019, at 12:58 PM, Sean Mooney <smooney at redhat.com> wrote:
> 
> technically i belive its not standards compliant to have a get
> request contain a body. some implemeention allow it but
> if you use a body in a get request i belive it causes issue with loadblancer/
> proxy servers so if we do support a query in a body it will have to be a post or put
> depending on how we choose to model it.

GET *can* have a body, but it is not required to be honored. Query strings don’t have a specified length limitation, but different clients and servers may impose such a limit. It is generally considered that query strings longer than 2K characters should be avoided, so if the query is so complex as to surpass that limit, we may need to move to using a body to hold all that information.

I don’t put much weight into the elegance argument. These queries are going to be programmatically generated, and creating parts of a query string is really no more or less elegant than creating parts of a a JSON blob.

-- Ed Leafe







From openstack at fried.cc  Mon Apr  8 20:32:11 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 8 Apr 2019 15:32:11 -0500
Subject: [placement][ptg] JSON payload for GET /a_c
In-Reply-To: <64BC4203-4223-447D-B303-E6041A2678DC@leafe.com>
References: <alpine.OSX.2.11.1904081645350.9091@seed.local>
 <9e1b48ade60417f8e7681635cbae1e8e3cc9f247.camel@redhat.com>
 <64BC4203-4223-447D-B303-E6041A2678DC@leafe.com>
Message-ID: <8d66209b-3d45-495f-f319-6e7aa8c9f783@fried.cc>

> I don’t put much weight into the elegance argument. These queries are going to be programmatically generated, and creating parts of a query string is really no more or less elegant than creating parts of a a JSON blob.

Except debuggability.

It's hard enough today deciphering the multiple internal delimiters in a
GET /a_c querystring.

Start generating even more complex querystrings, we'll end up encoding
punctuation (effectively urlencode(jsonblob)) and it'll be totally
unreadable in the logs.

efried


From mriedemos at gmail.com  Mon Apr  8 20:33:13 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 8 Apr 2019 15:33:13 -0500
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <alpine.OSX.2.21.1904081937400.88564@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
 <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
 <alpine.OSX.2.21.1904081937400.88564@cdent-a01.vmware.com>
Message-ID: <b8d4c567-fed1-62b1-969a-3997e691f3d1@gmail.com>

On 4/8/2019 1:44 PM, Chris Dent wrote:
> Yes, that's probably a good idea to speed up the gate side of
> things, but what I'm hoping we could figure out is a way to make it so
> on the dev side of things we don't need a running devstack for the
> test -> fix iterative cycle. The majority of the actually useful
> tests in osc-placement are integration tests (but labeled
> functional) and thus rather costly to run for the sake of
> development. vcrpy or requests-mock could potentially help us create real
> functional tests.

Hmm, what about using the PlacementFixture in the osc-placement 
functional tests? Nova's already doing that successfully for nova's 
functional tests.

-- 

Thanks,

Matt


From openstack at fried.cc  Mon Apr  8 21:34:03 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 8 Apr 2019 16:34:03 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <a61cd229-59e2-b1c1-4cb7-f20727c83e6d@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
 <a61cd229-59e2-b1c1-4cb7-f20727c83e6d@fried.cc>
Message-ID: <06acb1df-828f-02ff-41ee-eda0301ac196@fried.cc>

Nova-

Reminder: spec review day (number one) happens Tuesday, April 9th.

For some of us, this is "tomorrow". For some, it's mere hours away.

https://etherpad.openstack.org/p/nova-spec-review-day

Thanks,
efried
.


From stig.openstack at telfer.org  Mon Apr  8 22:05:40 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Mon, 8 Apr 2019 23:05:40 +0100
Subject: [scientific-sig][ironic] Gathering datapoints - Ironic integration
 with data centre inventory management
Message-ID: <E63E8AD6-6DFE-4940-848B-1A5C90D9D8C2@telfer.org>

Hi All -

Following some recent discussion with our friends at CERN, they are interested in gathering data, use cases and opinions about how Ironic could integrate with external DCIM tools.  The idea is that Ironic’s essential node data could be enriched by being cross-referenced with lifecycle data, location, etc (and perhaps vice versa).

We would like to bring some operator experience and Scientific SIG users tend to care for a broad base of hardware outside of their OpenStack estate.  I might argue that Scientific SIG users stand to gain much from external integrations like this.

Let’s put it on the agenda for this week’s IRC meeting (Wednesday 1100 UTC) and I hope people will come along with wish lists and constructive ideas that might be good input to help the CERN team gauge what good options might be.

Cheers,
Stig



From mriedemos at gmail.com  Mon Apr  8 22:10:48 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 8 Apr 2019 17:10:48 -0500
Subject: [placement][ptg] Gate health management
In-Reply-To: <20190408182853.GA19945@sinanju.localdomain>
References: <alpine.OSX.2.11.1904081740220.9091@seed.local>
 <f4970042-975e-6c51-a6a9-8e054dba6f86@gmail.com>
 <20190408182853.GA19945@sinanju.localdomain>
Message-ID: <b330b03b-fa61-cec0-58d7-b4e3810ca387@gmail.com>

On 4/8/2019 1:28 PM, Matthew Treinish wrote:
> As for how best to determine this. We actually aggregate all the data already
> in the subunit2sql db. openstack-health does provide a slowest job list
> aggregated over time per job using this data:
> 
> http://status.openstack.org/openstack-health/#/job/tempest-full-py3
> 
> You just change the sort column to "Mean Runtime". I think there is a bug
> in the rolling average function there because those numbers look wrong, but
> it should be relative numbers.
> 
> I also had this old script on my laptop [2] which I used to get a list of
> tests ordered by average speed (over the last 300 runs) filtered for those
> which took > 10 seconds. I ran this just now and generated this list:
> 
> http://paste.openstack.org/show/749016/
> 
> The script is easily modifiable to change job or number of runs.
> (I also think I've shared a version of it on ML before)

The reason I started going down this route of trying to compromise 
between scenario tests being run serially vs full concurrency (4 workers 
in our gate) and choosing 2 workers was because we could definitely mark 
more tests as slow, but the tempest-slow* job is already setup to 
timeout at 3 hours (compared to 2 hours for tempest-full) and at some 
point we can only mark so many tests as slow before the tempest-slow job 
itself starts timing out, and I don't really want to wait 3+ hours for a 
job to timeout. I put more alternatives in the commit message here:

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

I think part of what we need to do is start ripping tests out of the 
main tempest repo and putting them into per-project plugins especially 
if they don't involve multiple services and are not interop tests 
(thinking cinder-backup tests for sure). I think enabling SSH validation 
by default also increased the overall job times quite a bit but that's 
totally anecdotal at this point.

-- 

Thanks,

Matt


From dtroyer at gmail.com  Mon Apr  8 22:29:11 2019
From: dtroyer at gmail.com (Dean Troyer)
Date: Mon, 8 Apr 2019 17:29:11 -0500
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <alpine.OSX.2.11.1904081734490.9091@seed.local>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
Message-ID: <CAOJFoEvboOUuPPAYAkQwyWShDvOdx=QJ-T83kZGs5oQ4sdXw_A@mail.gmail.com>

On Mon, Apr 8, 2019 at 11:38 AM Chris Dent <cdent+os at anticdent.org> wrote:
> * It's functional tests require a working devstack, which is a bit meh
>      * Maybe something like https://vcrpy.readthedocs.io/en/latest/
>        could help (reasonable given microversions)

I don't have much personal experience with it but Keystone uses
betamax[0] in at least keystoneauth for recording/testing REST
interactions.  I recall Jamie talking about it, not sure who knows the
most about it these days...

dt

[0] https://github.com/betamaxpy/betamax

-- 
Dean Troyer
dtroyer at gmail.com


From juliaashleykreger at gmail.com  Mon Apr  8 22:31:45 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 8 Apr 2019 15:31:45 -0700
Subject: [PTG][nova][neutron][cyborg][placement][ironic][cinder]
 Cross-project PTG planning
In-Reply-To: <23fba8f4-efe5-e94e-aa1f-81b0324e214f@redhat.com>
References: <ebe52a7c-b793-77c9-778a-105616ad5e6b@fried.cc>
 <23fba8f4-efe5-e94e-aa1f-81b0324e214f@redhat.com>
Message-ID: <CAF7gwdgschnagCZGAwfB8p--X2hD8kygpGJwa2C5U9P0+wxooQ@mail.gmail.com>

In discussing with efried, the nova<->ironic cross project session
will be time boxed. If there are any pressing OR blocking items, they
should be put on the etherpad for discussion. The actual order of
discussion will be most pressing to least pressing if time permits.

Thanks,

-Julia

On Fri, Mar 22, 2019 at 7:43 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> Hi,
>
> On 3/20/19 4:55 PM, Eric Fried wrote:
> > All-
> >
> > Starting to plan for Denver, I'd like to get a feel for cross-project
> > sessions involving Nova. I made a pass through the Nova etherpad [1] and
> > started extracting the bits that were obvious cross-project topics with
> > Neutron [2], Cyborg [3], and Placement [4]. In a couple of places where
> > I wasn't sure I left `XPROJ?`.
> >
> > We usually also have cross-project sessions with Cinder and Ironic. I
> > saw no obvious topics with which to seed those etherpads yet, but please
> > do so as they arise. Similarly, if other project teams have topics to
> > discuss with Nova, please create an etherpad and link it from the bottom
> > of [1] and the wiki [5].
>
> I've put some ideas for a potential nova-ironic discussion:
> https://etherpad.openstack.org/p/ptg-train-xproj-nova-ironic
>
> >
> > Looking at the room schedule [6], how do folks feel about earmarking
> > Friday morning for cross-project sessions? As the etherpads fill up
> > we'll hopefully get a better idea of how much time to schedule for each.
> > And doing it relatively early gives us time to prioritize spillover for
> > Saturday if that becomes necessary.
>
> Friday morning sounds great to me.
>
> Dmitry
>
> >
> > <what is going on in Eric's head?>
> > Why granular etherpads? I'm hoping it will be more manageable than the
> > enormous monolithic etherpad we usually end up with. We often tend to
> > split out some pieces on the fly anyway; just trying to anticipate the
> > need. Besides, granular is my middle name.
> > </what>
> >
> > Thanks,
> > efried
> >
> > [1] https://etherpad.openstack.org/p/nova-ptg-train
> > [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron
> > [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg
> > [4] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
> > [5] https://wiki.openstack.org/wiki/PTG/Train/Etherpads
> > [6]
> > https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff7-8f34073852ca.png?embedded=og
> >
>
>


From ruijing.guo at intel.com  Mon Apr  8 22:50:14 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Mon, 8 Apr 2019 22:50:14 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <20190408122116.74lyls3tkudzbye2@yuggoth.org>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C5598B@SHSMSX104.ccr.corp.intel.com>

Thanks, Jeremy. Could you pls guide me how to create job based on nested KVM and customized OS?

-----Original Message-----
From: Jeremy Stanley [mailto:fungi at yuggoth.org] 
Sent: Monday, April 8, 2019 8:21 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: [CI] nested virtualization support in OpenStack CI

On 2019-04-08 00:42:46 +0000 (+0000), Guo, Ruijing wrote:
> I like Sean's idea. Can we create jobs based on nested KVM & 
> customized OS? If CI is stable enough, we can move non-voting to 
> voting.
[...]

There's nothing stopping you (or anyone) from creating such a CI system to augment reporting on how specific workloads fair with certain nested virt implementations.

The OpenDev CI system on the other hand is made of a heterogenous mix of donations from a variety of service providers with various configurations, and even some of those which advertise via CPU flags that they offer nested virt acceleration don't provide a stable implementation of it. There are already projects opportunistically testing with nested virtualization support turned on in their jobs to varying degrees of success, so it would be good to find out what problems their recent experiences reveal. It's also very much the case that even if it's working for a job today, it can start crashing jobs randomly tomorrow when a kernel version changes on guests or on hosts or we add another service provider into the mix.
--
Jeremy Stanley


From ruijing.guo at intel.com  Mon Apr  8 22:54:33 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Mon, 8 Apr 2019 22:54:33 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>

Hi, Clark

I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested virtualization.

Thanks,
-Ruijing

-----Original Message-----
From: Clark Boylan [mailto:cboylan at sapwetik.org] 
Sent: Tuesday, April 9, 2019 12:04 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [CI] nested virtualization support in OpenStack CI

On Mon, Apr 8, 2019, at 5:21 AM, Jeremy Stanley wrote:
> On 2019-04-08 00:42:46 +0000 (+0000), Guo, Ruijing wrote:
> > I like Sean's idea. Can we create jobs based on nested KVM & 
> > customized OS? If CI is stable enough, we can move non-voting to 
> > voting.
> [...]
> 
> There's nothing stopping you (or anyone) from creating such a CI 
> system to augment reporting on how specific workloads fair with 
> certain nested virt implementations.
> 
> The OpenDev CI system on the other hand is made of a heterogenous mix 
> of donations from a variety of service providers with various 
> configurations, and even some of those which advertise via CPU flags 
> that they offer nested virt acceleration don't provide a stable 
> implementation of it. There are already projects opportunistically 
> testing with nested virtualization support turned on in their jobs to 
> varying degrees of success, so it would be good to find out what 
> problems their recent experiences reveal. It's also very much the case 
> that even if it's working for a job today, it can start crashing jobs 
> randomly tomorrow when a kernel version changes on guests or on hosts 
> or we add another service provider into the mix.

Right one of the biggest concerns we have is the lack of observed stability with nested virt. This isn't a theoretical concern. In the not too distant past Tripleo jobs running on CentOS were crashing the "middle" VM and no one noticed until I started looking into job failures. The fix for that required a base hypervisor kernel update which is not something we control.

That said understanding requirements here (which was asked for earlier in the thread, but I don't see a response) is useful when trying to figure out the best way to approach these situations. It is possible there are other reasonable avenues that could be taken.

Clark



From edmondsw at us.ibm.com  Mon Apr  8 23:01:44 2019
From: edmondsw at us.ibm.com (William M Edmonds - edmondsw@us.ibm.com)
Date: Mon, 8 Apr 2019 23:01:44 +0000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
Message-ID: <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>


Rico Lin wrote:
> Dear PowerVMStackers and Winstackers members
> 
> (This idea is from Thierry, so I'm just helping to trigger discussion here.)
> 
> We now have most of Working Groups migrate to SIGs, so it's 
> governance under both TCs and UCs. And to further look through, there 
> are some projects are potential SIG meterial.
> PowerVMStackers and Winstackers are two identical targets. They all 
> required cross-project works to achieve their mission and kind of 
> *special interest* (One for PowerVM, and one for Windows support across 
> OpenStack). 

That's great, but these aren't working groups, and never were, and don't really function like working groups or SIGs, so I don't think that really applies here.

> There are two questions I would hope team members from both teams can 
> help to answer.
>
> 1. Is the mission for your project completed?

No

> 2. Is the team still active?

Yes

> 3. Any concerns or objections on moving from project to SIG?

Lots...

I can see why, at a quick glance, one might think that PowerVMStackers is like a special interest group. The name would certainly imply that. But that's out of historical necessity rather than what's proper. It's really not much like a SIG in what it does.

The three projects that PowerVMStackers contains (nova-powervm, networking-powervm, and ceilometer-powervm) are drivers/agents for nova, neutron, and ceilometer. They should ideally be under the umbrella of those projects, as other drivers/agents are, rather than split out as a PowerVMStackers project or SIG. But sadly, that is not the case due to historical reasons (primarily, the nova cores would not allow the nova powervm driver to be developed within nova like the drivers for Hyper-V, VMware, etc. so we had to create nova-powervm separately to do that development). I assure you that I've never liked that false dichotomy, but it was not our choice. The right thing to do here is to get them under those umbrellas, not to convert PowerVMStackers to a SIG. They need to be developed and managed just like any other OpenStack project producing code... not a SIG.

So we've been working on getting nova-powervm merged into nova to get it under that umbrella. But to do that we have been asked to port functions in piece by piece, which is an arduous process that will take a while yet. So like it or not, I think we're stuck with PowerVMStackers for a while... unless you can convince the nova cores to move nova-powervm under their umbrella (and neutron/ceilometer, but I think that would far less of an issue). They could still use have separate core groups, with some nova/neutron/ceilometer cores joining the *-powervm-cores groups. The ceilometer-powervm project used to be under the ceilometer umbrella before PowerVMStackers was created, and yet had a separate core list. And I think something similar was done with placement separating out of nova. This is a somewhat similar situation, but in reverse... merging into nova rather than separating from it.

Once the driver/agent code is under the nova/neutron/ceilometer umbrellas, then yes, I would 100% agree that there should be a PowerVM SIG driving changes into code under the nova, neutron, and ceilometer umbrellas. But until that happens...



From fungi at yuggoth.org  Mon Apr  8 23:04:21 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Apr 2019 23:04:21 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <2EE296D083DF2940BF4EBB91D39BB89F40C5598B@SHSMSX104.ccr.corp.intel.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C5598B@SHSMSX104.ccr.corp.intel.com>
Message-ID: <20190408230421.6dtpsznb22ri36px@yuggoth.org>

On 2019-04-08 22:50:14 +0000 (+0000), Guo, Ruijing wrote:
> Thanks, Jeremy. Could you pls guide me how to create job based on
> nested KVM and customized OS?
[...]

The message to which you're replying (context elided once again
because you keep top-posting) suggested you could do so if you build
your own CI system.

That aside, as I mentioned some projects (I believe Octavia is one?)
turn on nested virtualization support in their jobs if they see the
system on which they're running advertises support for it. We don't
expressly disable use of nested virtualization in the OpenDev CI
system, it's actually DevStack which does so in jobs which use it,
and that behavior can presumably be overridden.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/5d40f18f/attachment.sig>

From cboylan at sapwetik.org  Mon Apr  8 23:05:20 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Apr 2019 19:05:20 -0400
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
Message-ID: <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>



On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> Hi, Clark
> 
> I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> virtualization.
> 

Can you describe this requirement in a bit more detail? Looking at docs it appears you need to have large pages. Maybe a "picture" will help too:

  Workload VM
  (cirros or similar small VM running under
   emulation or virtualized if nested virt is enabled)
       |
      V
  OpenStack Infra Test Node ("middle VM")
    This is where ovsdpdk runs right? And this requires large pages?
       |
      V
  Hypervisor (managed by our cloud providers)

Are we not able to do large pages with emulated workload VMs? Also can we do large pages on the Workload VM if the Infra Test Node isn't configured for them? If the infra test node isn't configured for them do we also need support for large pages from the Hypervisor?

If we can do large pages with emulated workload VMs and the hypervisor isn't required to support that we should be able to configure large pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of these things won't work.
In any case specific details on what is required and where it is required will be useful.

Clark


From ruijing.guo at intel.com  Mon Apr  8 23:35:00 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Mon, 8 Apr 2019 23:35:00 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C55A00@SHSMSX104.ccr.corp.intel.com>

Hi, Clark


  Workload VM
  (cirros or similar small VM running), (don't need large page, memory might be 512M)
       |
      V
  OpenStack Infra Test Node ("middle VM"), (run ovsdpdk here and need 2M huge pages,  total memory might be 2G) 
       |
      V
  Hypervisor (need to enable nested KVM, don't need large pages)







Thanks,
-Ruijing

-----Original Message-----
From: Clark Boylan [mailto:cboylan at sapwetik.org] 
Sent: Tuesday, April 9, 2019 7:05 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [CI] nested virtualization support in OpenStack CI



On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> Hi, Clark
> 
> I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> virtualization.
> 

Can you describe this requirement in a bit more detail? Looking at docs it appears you need to have large pages. Maybe a "picture" will help too:

  Workload VM
  (cirros or similar small VM running under
   emulation or virtualized if nested virt is enabled)
       |
      V
  OpenStack Infra Test Node ("middle VM")
    This is where ovsdpdk runs right? And this requires large pages?
       |
      V
  Hypervisor (managed by our cloud providers)

Are we not able to do large pages with emulated workload VMs? Also can we do large pages on the Workload VM if the Infra Test Node isn't configured for them? If the infra test node isn't configured for them do we also need support for large pages from the Hypervisor?

If we can do large pages with emulated workload VMs and the hypervisor isn't required to support that we should be able to configure large pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of these things won't work.
In any case specific details on what is required and where it is required will be useful.

Clark



From dimtheo at auvious.com  Tue Apr  9 00:39:26 2019
From: dimtheo at auvious.com (Dimitris Theoharis)
Date: Tue, 9 Apr 2019 03:39:26 +0300
Subject: openstack-ansible AIO error : os_swift : Get md5sum of local
 builder files
Message-ID: <etPan.5cabe9c3.2848f001.9e5@airmail.rr>

Hello 

I have been trying to add SWIFT in AIO for some testing but i always get the error i will post below. I have tried Ubuntu bionic and Centos 7 and git cloned 18.1.4 , 18.1.6 , 19.0.0.0rc2 , master
all versions give me the same error about SWIFT . 
As i understand the error may be an ansible bug but not quite sure . 
the bootstrap-ansible installs version 2.7.9

this is the error:

TASK [os_swift : Verify md5sum of builder files] *******************************************************************************************************************************************************************************************************************************
skipping: [aio1] => (item=aio1)
fatal: [aio1]: FAILED! => {"msg": "The conditional check 'hostvars[item]['builder_md5sum'] != md5sum.stdout' failed. The error was: error while evaluating conditional (hostvars[item]['builder_md5sum'] != md5sum.stdout): 'ansible.vars.hostvars.HostVarsVars object' has no attribute 'builder_md5sum'\n\nThe error appears to have been in '/etc/ansible/roles/os_swift/tasks/swift_rings_post_distribution_check.yml': line 24, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# As this is post sync all should match and not be empty\n- name: Verify md5sum of builder files\n  ^ here\n"}



here is a very detailed error log 


https://pastebin.com/7B2wgac4


any tips ? thanks






		
Dimitris Theoharis
DevOps Engineer    
 
w:  auvious.com   e:  dimtheo at auvious.com                            
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/77c2b943/attachment.html>

From tony at bakeyournoodle.com  Tue Apr  9 01:03:04 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 9 Apr 2019 11:03:04 +1000
Subject: [chef][stable] Chef OpenStack retiring stable branches
In-Reply-To: <1554724369.4997.23.camel@offenerstapel.de>
References: <1554724369.4997.23.camel@offenerstapel.de>
Message-ID: <20190409010303.GC7047@thor.bakeyournoodle.com>

On Mon, Apr 08, 2019 at 11:52:49AM +0000, Jens Harbott wrote:
> The Chef OpenStack project still has a set of repos with stable/newton
> branches, however those have been announced as EOL for more than a year
> [0], but we missed to actually close them down. I plan to do so in a
> couple of days unless there is some justified objection. See [1] for a
> list of the affected repositories and the commit hashes that are
> targeted to receive the "newton-eol" tag.

That all looks okay to me.

I'm not certain how to fix up the review in openstack/releases but I
*think* as we're EOL'ing the branch we should just omit that from the
change.

> The situation with the stable/ocata branches is similar, but while we
> did announce them as EOL in [0], too, the date mentioned there seems
> wrong.

Yeah that date is a little wrong you went EOL 4 days after release :P

>        Also, there seems to be some confusion about the situation for
> the global OpenStack project, which doesn't seem to have retired
> stable/ocata for any project yet.

Ocata went into Extended Maintenance a while back but we're just now
working out that we didn't complete the full process.  Once Sean's work
in [1] is merged we should have a consistent view of the state for
Ocata.[0]

>                                   Still, we don't have any open patches
> for stable/ocata, we don't have a working CI for it, and there also
> isn't anyone using it known to me. So please respond if there is a
> reason to keep the stable/ocata branches in their current state,
> otherwise I'd start the process to tag them as EOL, too.

I think you're okay to EOL them but I suspect that it'd be good to wait
until the dust settles on the Stein release, and the Ocata/Pike
transition to EM.  Which more or less means the week after summit.

Would that work for you?


Yours Tony.

[0] Which seems to NOT include openstack-chef ?
[1] https://review.openstack.org/#/q/status:open+project:openstack/releases+branch:master+topic:eol-em
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/6cecc6ee/attachment.sig>

From syd.logan at broadcom.com  Tue Apr  9 01:42:56 2019
From: syd.logan at broadcom.com (Syd Logan)
Date: Mon, 8 Apr 2019 18:42:56 -0700
Subject: CLOS networking support best practice?
Message-ID: <CACmumLgfR11o7ApThJpaM84_tpgpAOPugDJ6nRXX5fBt+ywrgg@mail.gmail.com>

Hi,

Over the past few weeks I've experimented with neutron in search of an
"ah-ha!" moment at which point I've discovered how to best to use OpenStack
neutron to implement a large datacenter CLOS network that supports
bi-directional traffic between tenants and the external network(s).

While the exploration has been quite educational (and fun), I'm still not
there, and looking for suggested compass heading(s) towards best
practice(s) as of 2019. Back in 2015, a blog post
http://www.dorm.org/blog/openstack-architecture-at-go-daddy-part-2-neutron/
suggests a certain amount of heavy lifing was needed to support GoDaddy's
leaf-spine, but I'm hoping by now things might be supported a bit more "out
of the box". If not, what is best approach, and what is missing that needs
contribution in order to make it complete?

TIA and Best,

syd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/cd37e55f/attachment.html>

From anlin.kong at gmail.com  Tue Apr  9 01:49:09 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Tue, 9 Apr 2019 13:49:09 +1200
Subject: [trove] Propose changes of the core team
Message-ID: <CALjNAZ1j7UoncFDcd7gmO5L0DwTg=sP23y+o-x9kw2Ov-WhPNA@mail.gmail.com>

Hi team,

According to the community recommended criteria when removing cores[1] and
the recent 3 months review statistics[2][3], as Trove PTL of the Train dev
cycle, I propose the following change to the team:

Members to remove from core team:
Luke Browning
Maciej Jozefczyk
Manoj Kumar
Nikhil Manchanda
Samuel Matzek
Yao Wang
Zhao Chao
jian.song
zhanggang

Thanks for all of your contributions to Trove, you are all welcomed to come
back to the team anytime when the situation changes.

All Trove core members, please respond with your comments and objections.

[1]
https://docs.openstack.org/project-team-guide/ptl.html#criteria-when-removing-new-cores
[2] https://www.stackalytics.com/report/contribution/trove/180
[3] https://www.stackalytics.com/report/contribution/python-troveclient/180

---
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/82bc381a/attachment-0001.html>

From mnaser at vexxhost.com  Tue Apr  9 02:51:47 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Mon, 8 Apr 2019 22:51:47 -0400
Subject: [nova] indices on shadow-able fields
Message-ID: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>

Hi everyone.

In continuing with the trend of interesting database issues, I've
found the following interesting thing.  It looks like we don't have
indices for all of our tables that can be large on the deleted field.
I think it would be beneficial *especially* for cases when the
archiving code runs.

The big ones that are huge users in terms of rows without index are
`instance_system_metadata` and `instance_extra`.
`instance_action_events` and `instance_actions` don't have any either.

I believe without this, it results in doing a full table scan during
the clean up which can become pretty resource intensive.

I'll defer to the Nova team on the best practice about this (or if
this is even a bug), but I just wanted to bring the attention to this
as I've had mild success trying to tame a large database and
leveraging the archive DB tooling.

Thanks,
Mohammed

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From dangtrinhnt at gmail.com  Tue Apr  9 05:51:03 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 9 Apr 2019 14:51:03 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4EvogMYONYny9c0yfmSzAi6NXKj8hMs=VV2Ek=DVQLgmg@mail.gmail.com>
References: <CADJ6S4FtZNKF2y2mOanLm9AvujNtnwBy7FXbOzLrHiEAWqD_HQ@mail.gmail.com>
 <CALjNAZ2kygVgbERrvU-WPw5Mk5nHSgAoAV3o_DMv1z5R-etchw@mail.gmail.com>
 <CADJ6S4G_2sCKtjNGjqrZbj0zjkn7ZJjVgngKXuiQg5WZLuN6BA@mail.gmail.com>
 <20190403064440.GA3615@hilbert.berg.ol>
 <CADJ6S4EJd45OSCfPudK3jg0-gZiVn0w2TVb5P04om-kGfw0L7w@mail.gmail.com>
 <CADJ6S4GXV7BiK2eqz07tTb6Vo+3jYCB4wN8W02E6=50ok1ZYgw@mail.gmail.com>
 <CAN2nDNvfH=9Pnj9YQ-M3E2R-Sg6=-nHVFjYWtb6j9CMG=D3LSg@mail.gmail.com>
 <CADJ6S4GUEDBbx65RyWMtjsOBXpDLknjxojWyuV8ft2j7=A6m1Q@mail.gmail.com>
 <CAN2nDNtuHx-mjgs0+epgNk=APVvRUkkgcZB2NNWwF+wC1AWvRw@mail.gmail.com>
 <20190404061722.GA3766@hilbert.berg.ol>
 <CAN2nDNtHFT5ksC3moaXCJ+NJH43KZievoK0w7R4SiEbtX5Aidw@mail.gmail.com>
 <CADJ6S4Fhbgs6VnJPBwYQ-F55eNJ2uNStfhbbc7fD2m0Rb3ReUg@mail.gmail.com>
 <CADJ6S4EvogMYONYny9c0yfmSzAi6NXKj8hMs=VV2Ek=DVQLgmg@mail.gmail.com>
Message-ID: <CADJ6S4FvSLhDje3ERFZ-d6GEFRUOesGbzq5wNNxHEj4mgjjL_A@mail.gmail.com>

10m to the meeting :)

On Mon, Apr 8, 2019 at 11:41 AM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Invitation sent! Talk (chat) to you soon.
>
> On Mon, Apr 8, 2019 at 11:30 AM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Okie, that should be fine. Let's do it over IRC #openstack-telemetry
>>
>> I will update the calendar invitation.
>>
>> Thanks.
>>
>> On Mon, Apr 8, 2019 at 9:52 AM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>>
>>> I also think IRC is the best choice, since the meeting time is in the
>>> working hours, and don't have microphone and video in office PC.
>>>
>>>
>>> Thanks,
>>> Rong Zhu
>>>
>>> Matthias Runge <mrunge at redhat.com>于2019年4月4日 周四22:21写道：
>>>
>>>> On Thu, Apr 04, 2019 at 09:02:49AM +0800, Rong Zhu wrote:
>>>> > >
>>>> > > Let me look for other options. Maybe Zoom <https://zoom.us>/Jitsi
>>>> > > <https://jitsi.org/> should work? Let me know.
>>>>
>>>>
>>>> > >> Meeting time is really good for us. But shall we change the meeting
>>>> > >> channel just in the IRC channel? You may know we, from China,
>>>> can't visit
>>>> > >> Google.
>>>>
>>>> > >>> I've sent out the google calendar invitation to those who voted.
>>>> If you
>>>> > >>> want to join the meeting and help Telemetry out, drop me an email
>>>> by this
>>>> > >>> Saturday.
>>>> > >>>
>>>> > >>> Also, look at the etherpad:
>>>> > >>> https://etherpad.openstack.org/p/telemetry-train
>>>>
>>>> Hi,
>>>>
>>>> thank you for setting this up! For the first meeting, having a video
>>>> chat would probably be good, but I'd second the request for using IRC.
>>>>
>>>> Matthias
>>>> --
>>>> Matthias Runge <mrunge at matthias-runge.de>
>>>>
>>>> --
>>> Thanks,
>>> Rong Zhu
>>>
>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/07cd4f41/attachment.html>

From tony at bakeyournoodle.com  Tue Apr  9 06:02:30 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 9 Apr 2019 16:02:30 +1000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
Message-ID: <20190409060229.GD7047@thor.bakeyournoodle.com>

On Mon, Apr 08, 2019 at 11:01:44PM +0000, William M Edmonds - edmondsw at us.ibm.com wrote:
> 
> Rico Lin wrote:
> > Dear PowerVMStackers and Winstackers members
> > 
> > (This idea is from Thierry, so I'm just helping to trigger discussion here.)
> > 
> > We now have most of Working Groups migrate to SIGs, so it's 
> > governance under both TCs and UCs. And to further look through, there 
> > are some projects are potential SIG meterial.
> > PowerVMStackers and Winstackers are two identical targets. They all 
> > required cross-project works to achieve their mission and kind of 
> > *special interest* (One for PowerVM, and one for Windows support across 
> > OpenStack). 
> 
> That's great, but these aren't working groups, and never were, and
> don't really function like working groups or SIGs, so I don't think
> that really applies here.

I think we're mixing a couple of ideas here.

PowerVMStackers is very much a Special interest group, it has a common
thread that crosses project boundaries.

This has *nothing* to do with code migration or core lists etc.

> > There are two questions I would hope team members from both teams can 
> > help to answer.
> >
> > 1. Is the mission for your project completed?
> 
> No
> 
> > 2. Is the team still active?
> 
> Yes
> 
> > 3. Any concerns or objections on moving from project to SIG?
> 
> Lots...
> 
> I can see why, at a quick glance, one might think that PowerVMStackers is like a special interest group. The name would certainly imply that. But that's out of historical necessity rather than what's proper. It's really not much like a SIG in what it does.
> 
> The three projects that PowerVMStackers contains (nova-powervm,
> networking-powervm, and ceilometer-powervm) are drivers/agents for
> nova, neutron, and ceilometer. They should ideally be under the
> umbrella of those projects, as other drivers/agents are, rather than
> split out as a PowerVMStackers project or SIG. But sadly, that is not
> the case due to historical reasons (primarily, the nova cores would
> not allow the nova powervm driver to be developed within nova like the
> drivers for Hyper-V, VMware, etc. so we had to create nova-powervm
> separately to do that development).

This is slightly misleading, from the conversations I was present for
the nova core team didn't want the powervm driver merged into the nova
repo until it was ready.  At no point, that I recall, was keeping the
nova-powervm code in it's own repo (as today) but under the governance
of the nova PTL.

That isn't the proposal.  Migration to a SIG would basically mean:

a. Moving PowerVMStackers from [1] to [2]
b. PowerVMSTackers SIG chair (*cough* PTL *cough*) would have to write a
   small update for the annual report

There are a couple of things you miss out on (by default):

1. (ATM) contributions to SIG repos aren't part of the electorate for TC
   This wouldn't be hard to fix, and is already being discussed.
2. SIGs don't by default get space at PTGs or 'project update' type
   sessions at the forum.  To the best of my knowledge this hasn't been
   used to date.

And that's where *this* proposal ends anything else is speculation
about things we could *also* do.

> separately to do that development). I assure you that I've never liked
> that false dichotomy, but it was not our choice. The right thing to do
> here is to get them under those umbrellas,

Yes!

>                                          , not to convert
> PowerVMStackers to a SIG. They need to be developed and managed just
> like any other OpenStack project producing code... not a SIG.

Kinda of.  I think the right thing to do is both!


Full disclosure, when PowerVMStackers was created I was strongly, and
still am, in favour of the 3 repos being goverened by the appropriate
team, and the people interested in developing that banding together hold
meetings and set direction you don't need to be a project team to do
that.

> So we've been working on getting nova-powervm merged into nova to get
> it under that umbrella. But to do that we have been asked to port
> functions in piece by piece, which is an arduous process that will
> take a while yet. So like it or not, I think we're stuck with
> PowerVMStackers for a while... unless you can convince the nova cores
> to move nova-powervm under their umbrella (and neutron/ceilometer, but
> I think that would far less of an issue).

Being part of the Nova project wont alter how the code migrates from
openstack/nova-powervm -> openstack/nova but I agree that it should
happen  (/me looks sideways the current nova PTL ;P)

>                                           They could still use have
> separate core groups, with some nova/neutron/ceilometer cores joining
> the *-powervm-cores groups.

Yup!  Clearly not my call but I agree with you.

>                             The ceilometer-powervm project used to be
> under the ceilometer umbrella before PowerVMStackers was created, and
> yet had a separate core list.

Yup and I argued that changing that was a regression at the time.

>                               And I think something similar was done
> with placement separating out of nova. This is a somewhat similar
> situation, but in reverse... merging into nova rather than separating
> from it.

Well that's quite different placement is the most recent 'extraction'
from nova but there have been many others.

 
> Once the driver/agent code is under the nova/neutron/ceilometer
> umbrellas, then yes, I would 100% agree that there should be a PowerVM
> SIG driving changes into code under the nova, neutron, and ceilometer
> umbrellas. But until that happens...

Yup *if* the code was under the team governance at some point
the nova-powervm repo and the code in nova/virt/powervm would be such
that nova-powervm could be retired and all further development would
happen in nova.

Yours Tony.

[1] https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2901-L2928
[2] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/1f3b3e1e/attachment.sig>

From tony at bakeyournoodle.com  Tue Apr  9 06:09:33 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 9 Apr 2019 16:09:33 +1000
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <CAJ6yrQg=BLGZ5scU7r2zHXC4uoMWF9J-o4T9T+7wUQ1qUiinyw@mail.gmail.com>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
 <CAJ6yrQg=BLGZ5scU7r2zHXC4uoMWF9J-o4T9T+7wUQ1qUiinyw@mail.gmail.com>
Message-ID: <20190409060932.GE7047@thor.bakeyournoodle.com>

On Mon, Apr 08, 2019 at 11:51:35AM -0700, Kendall Nelson wrote:

> Thursday for you maybe. The times mostly show on Wednesday for US + EU
> people. Which is fine for me, just wanted to point that out in case we were
> trying to keep it closer to the end of the week.

Gah timezones are hard.  I did want to keep it in Thursday at least for
EU.  Thursday for the US is my Friday which doesn't give me much time to
do much before have a weekend
 
> Maybe we will be even more on top of things now with our PTL living in the
> future.

I really miss my replicator when I travel back in time. ;P

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/a8495854/attachment-0001.sig>

From tony at bakeyournoodle.com  Tue Apr  9 06:19:48 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Tue, 9 Apr 2019 16:19:48 +1000
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <20190408114100.GD29851@sm-xps>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
 <20190408114100.GD29851@sm-xps>
Message-ID: <20190409061948.GF7047@thor.bakeyournoodle.com>

On Mon, Apr 08, 2019 at 06:41:00AM -0500, Sean McGinnis wrote:
> >
> > If needed, we could do 2 meetings one for AU+EU and then another for
> > AU+US but I'd much rather have a single meeting to keep everyone on the
> > same page.
> 
> I agree, I think just having one meeting is going to be best, even though it
> will certainly make things a little more challenging for some.

Even if I did 0400-0500 for me that's 2000 for Thierry which isn't great
for him :/

> > I've created a doodle poll: https://doodle.com/poll/xxa46wrndefyi6dk
> >
> > I picked Thursday as the day of the week for the poll but if if needed
> > we can mov it to another day.
> >
> 
> ++ Thursday's have worked really well for me. We typically would try to get the
> release countdown sent on Thursday's to make sure folks see it before leaving
> for the weekend. So that along with Thursday's being the usual deadline days,
> it's been a good checkpoint to make sure we have things covered.

Yup I like that.   It's a shame I messed up the poll.
 
Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/a776dfc9/attachment.sig>

From b.zurkowski at samsung.com  Tue Apr  9 07:22:09 2019
From: b.zurkowski at samsung.com (Bartosz Zurkowski)
Date: Tue, 09 Apr 2019 08:22:09 +0100
Subject: [trove] Propose changes of the core team
In-Reply-To: <CALjNAZ1j7UoncFDcd7gmO5L0DwTg=sP23y+o-x9kw2Ov-WhPNA@mail.gmail.com>
References: <CALjNAZ1j7UoncFDcd7gmO5L0DwTg=sP23y+o-x9kw2Ov-WhPNA@mail.gmail.com>
 <CGME20190409015603epcas1p47290987f0caaf04df032bff0dc0151a2@eucms1p2>
Message-ID: <20190409072209eucms1p2d83fbc7dc73f8c487e6f06ca03ba8940@eucms1p2>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/9f20a152/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13168 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/9f20a152/attachment-0001.gif>

From akjayaku at cisco.com  Tue Apr  9 08:21:26 2019
From: akjayaku at cisco.com (Akhil Jayakumar (akjayaku))
Date: Tue, 9 Apr 2019 08:21:26 +0000
Subject: How to protect plain-text passwords in local.conf
Message-ID: <92E25B0C-C20F-45CC-8F96-8607F0C309EE@cisco.com>

Hi Folks,

Is there a way we can encrypt passwords in local.conf?

If so could you please point me to the reference?

Thanks,
Akhil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/b6bf30ed/attachment.html>

From thierry at openstack.org  Tue Apr  9 10:04:12 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 9 Apr 2019 12:04:12 +0200
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <20190409061948.GF7047@thor.bakeyournoodle.com>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
 <20190408114100.GD29851@sm-xps>
 <20190409061948.GF7047@thor.bakeyournoodle.com>
Message-ID: <7a9a2519-6e2c-31ad-6a7f-7e01d74048d7@openstack.org>

Tony Breeds wrote:
> On Mon, Apr 08, 2019 at 06:41:00AM -0500, Sean McGinnis wrote:
>>>
>>> If needed, we could do 2 meetings one for AU+EU and then another for
>>> AU+US but I'd much rather have a single meeting to keep everyone on the
>>> same page.
>>
>> I agree, I think just having one meeting is going to be best, even though it
>> will certainly make things a little more challenging for some.
> 
> Even if I did 0400-0500 for me that's 2000 for Thierry which isn't great
> for him :/

Obviously nothing works for everyone.

looking at the Doodle it looks like 1900utc is the time that works best 
(of all the times that work for Tony). It's not superawesome though (5am 
for Tony, 9pm for JP and me).

Alternate solution would be to rotate between EU/Au and US/Au times and 
only have Tony as the common denominator.

-- 
Thierry Carrez (ttx)


From thierry at openstack.org  Tue Apr  9 11:00:33 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 9 Apr 2019 13:00:33 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190408172927.emf2wjhcvnh52zxq@yuggoth.org>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <856d7b89-69f1-c56d-e086-d0188c4a4fa8@openstack.org>
 <20190408161117.yffmxzj5dpe6es7j@yuggoth.org>
 <cfa6617c-c619-63e1-b84a-8ce0ccb09695@ham.ie>
 <CA+eV8ih6z7ROW=SjnGjX8=xYSD5pxJuu+HqaEiHnvBY9vTaDKQ@mail.gmail.com>
 <20190408172927.emf2wjhcvnh52zxq@yuggoth.org>
Message-ID: <bd8546d6-6da8-06b1-97c6-b704a45beae8@openstack.org>

Jeremy Stanley wrote:
> On 2019-04-08 12:02:22 -0500 (-0500), Matt Van Winkle wrote:
> [...]
>> FWIW - we have also tried to include SIG activity as criteria for
>> AUC status and voting in the UC election.
> 
> Yes, I thought about mentioning that as well. I see the two as a
> great potential combination: allowing contributors to SIG
> repositories could give the right to vote in both TC and UC
> elections due to the broader scope of the work in which they are
> involved.

I thought that was already the case :) When we set up SIGs originally 
with Melvin the intent definitely was that contributing to a SIG would 
give you both ATC and AUC voting rights. We may have skipped a step when 
we implemented them...

So if it's not the case already we should definitely make it so.

-- 
Thierry Carrez (ttx)


From cdent+os at anticdent.org  Tue Apr  9 11:00:36 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 12:00:36 +0100 (BST)
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <b8d4c567-fed1-62b1-969a-3997e691f3d1@gmail.com>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
 <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
 <alpine.OSX.2.21.1904081937400.88564@cdent-a01.vmware.com>
 <b8d4c567-fed1-62b1-969a-3997e691f3d1@gmail.com>
Message-ID: <alpine.OSX.2.21.1904091151530.93787@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Matt Riedemann wrote:

> On 4/8/2019 1:44 PM, Chris Dent wrote:
>> Yes, that's probably a good idea to speed up the gate side of
>> things, but what I'm hoping we could figure out is a way to make it so
>> on the dev side of things we don't need a running devstack for the
>> test -> fix iterative cycle. The majority of the actually useful
>> tests in osc-placement are integration tests (but labeled
>> functional) and thus rather costly to run for the sake of
>> development. vcrpy or requests-mock could potentially help us create real
>> functional tests.
>
> Hmm, what about using the PlacementFixture in the osc-placement functional 
> tests? Nova's already doing that successfully for nova's functional tests.

Yeah, that's probably the most gain with least effort solution. I
had it in my head that I wanted the tests to be with fixed/static
API responses, but with PlacementFixture being as no-big-deal as it
is, it is probably easier to use that.

I'll make a story [1], annotate the ptg etherpad, and we can call this
sub-thread a big win.

[1] https://storyboard.openstack.org/#!/story/2005411

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From thierry at openstack.org  Tue Apr  9 11:04:56 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 9 Apr 2019 13:04:56 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190409060229.GD7047@thor.bakeyournoodle.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
Message-ID: <f0f1260e-f75e-02b5-8a0c-5b10f2b63862@openstack.org>

Tony Breeds wrote:
> [...]
> This is slightly misleading, from the conversations I was present for
> the nova core team didn't want the powervm driver merged into the nova
> repo until it was ready.  At no point, that I recall, was keeping the
> nova-powervm code in it's own repo (as today) but under the governance
> of the nova PTL.
> 
> That isn't the proposal.  Migration to a SIG would basically mean:
> 
> a. Moving PowerVMStackers from [1] to [2]
> b. PowerVMSTackers SIG chair (*cough* PTL *cough*) would have to write a
>     small update for the annual report
> 
> There are a couple of things you miss out on (by default):
> 
> 1. (ATM) contributions to SIG repos aren't part of the electorate for TC
>     This wouldn't be hard to fix, and is already being discussed.
> 2. SIGs don't by default get space at PTGs or 'project update' type
>     sessions at the forum.  To the best of my knowledge this hasn't been
>     used to date.

Actually SIGs get proposed space at PTGs, exactly like project teams do.

-- 
Thierry Carrez (ttx)


From jaypipes at gmail.com  Tue Apr  9 11:16:47 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 9 Apr 2019 07:16:47 -0400
Subject: resize a vm to a flavor with pci-passthrough
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <40105c6b-6db9-5342-0ff0-5da1292a332f@gmail.com>

On 04/08/2019 01:45 AM, Manuel Sopena Ballesteros wrote:
> Dear Openstack community,
> 
> I have 1 physical node with x4 nvidia nv100 running 1 fat vm. 
> Additionally I am adding a nvme drive into that host and I would like to 
> attach the nvme drive to the vm. Ideally I prefer to avoid data 
> migration and redeploy the software.
> 
> My problem is that I don’t have another host with gpus so I am guessing 
> that the vm can’t be migrated. Am I right assuming this?
> 
> So far I thought about 2 possibilities but I don’t know whether they 
> would work:
> 
> Option 1: crate a new flavor with the pci device pass-through and resize 
> existing vm (I hope the new vm with the new flavor will have the nvme 
> attached).
> 
> Option 2: convert ephemeral virtual disk into a bootable volume. Destroy 
> vm. Create new vm with the new volume as a boot device.
> 
> Which option would be preferred? Is there any other think I can do?

Put your application data in a different location than your application 
configuration and operating system. Save that application state in a 
separate Cinder volume. You can then attach and detach the application 
state to a (much smaller) root disk image that just contains the 
operating system and installed application binaries.

Once you've done the above, then you won't need to fret about 
"avoid(ing) migration and redeploy the software".

Put the effort in up front to do this application state separation and 
your life will be much, much easier.

Best,
-jay


From thierry at openstack.org  Tue Apr  9 11:25:05 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 9 Apr 2019 13:25:05 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
Message-ID: <4b7a8de3-f1f1-dc25-590b-03bd3bd0bd9f@openstack.org>

William M Edmonds - edmondsw at us.ibm.com wrote:
> [...]
>> 3. Any concerns or objections on moving from project to SIG?
> 
> Lots...
> 
> I can see why, at a quick glance, one might think that PowerVMStackers is like a special interest group. The name would certainly imply that. But that's out of historical necessity rather than what's proper. It's really not much like a SIG in what it does.
> 
> The three projects that PowerVMStackers contains (nova-powervm, networking-powervm, and ceilometer-powervm) are drivers/agents for nova, neutron, and ceilometer. They should ideally be under the umbrella of those projects, as other drivers/agents are, rather than split out as a PowerVMStackers project or SIG. But sadly, that is not the case due to historical reasons (primarily, the nova cores would not allow the nova powervm driver to be developed within nova like the drivers for Hyper-V, VMware, etc. so we had to create nova-powervm separately to do that development). I assure you that I've never liked that false dichotomy, but it was not our choice. The right thing to do here is to get them under those umbrellas, not to convert PowerVMStackers to a SIG. They need to be developed and managed just like any other OpenStack project producing code... not a SIG.

SIGs can produce code. The difference with project teams is that our 
project teams are organized around a specific component (Nova, Swift...) 
or a horizontal software development function that applies to all those 
components (QA, Documentation, release management, common libraries...)

Once you frame it like that, you can spot a few outliers in the current 
project team list: things that are neither centered around a specific 
component nor a horizontal function: PowerVMStackers and Winstackers.

That said, I understand your objection. Establishing PowerVMStackers as 
a SIG clearly sends the message that caring about PowerVM is a special 
interest and not everyone's interest. It makes it less likely that the 
*-powervm repository/features ever get merged into their respective 
projects. And if this merging is right around the corner, I agree that 
setting up a PowerVM SIG is counterproductive.

So I guess the real question is, is PowerVM support a mainline feature 
that just happens to be temporarily maintained under a specific team for 
weird organizational reasons ? Or is it considered not to be mainline 
material (a bit like Windows support), and therefore the people that 
care about that feature should maintain code to support that 
indefinitely on the side ?

If it's the former, and there is a clear plan to get all that 
functionality up in their respective teams in a near future, then I 
agree a SIG won't really help. If the latter though, I really think that 
a SIG is a much better way to represent what is happening there, and 
would give the "PowerVM support" SIG extra visibility.

My impression is that it's been 4 years now that those repositories 
exist separately from Nova, Neutron and Ceilometer and nobody seems in a 
hurry to merge that functionality there... which is why I assumed the 
latter.

-- 
Thierry Carrez (ttx)


From cdent+os at anticdent.org  Tue Apr  9 11:43:55 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 12:43:55 +0100 (BST)
Subject: [placement][nova][ptg] Protecting driver-provided traits
Message-ID: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>


>From the etherpad [0]:

* We might want to tighten up what the RP traits API allows as per https://pasteboard.co/I3iqqNm.jpg
* although maybe this is better covered in a nova session?
     * If the mechanism is changing how nova-compute reports and
       manipulates traits, then yeah, nova. But if for some reason
       there is a need to change the actual API [1], placement; but I
       would hope that all avenues not involving changing the API
       were first disposed as either not possible, or really really
       terrible.

This came up as part of the work on compute capabilities as traits [2]
and questions about who owns what traits and how to manage them so
that unexpected trait clobbering or trait addition happens.

This is (hopefully) mostly a thing on the nova-compute side of the
equation (when managing inventory), so hopefully someone with more
insight into that situation can drive this thread. What needs to
happen here?


[0] https://etherpad.openstack.org/p/placement-ptg-train

[1] There are degrees of change in the API. Adding a query parameter
is much less of a big deal than adding or changing an attribute in a
request or response body. Adding another method to a URI, while a
big deal in some cases, is much less of a big deal than adding an
entirely new URI.

[2] https://review.openstack.org/#/c/538498/k

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Tue Apr  9 11:56:15 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 12:56:15 +0100 (BST)
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
Message-ID: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>


The etherpad [1] doesn't have any additional notes besides the topic
but the general questions are:

* Do people want to do baremetal reservations with some combination
   of Ironic, Placement and Blazar, now or ever?

* What about Ironic and Placement, sans-Nova?

* If so, what would need to happen to make those things possible?

Based on my observations at the recent OpenInfra Days UK, I'd say
there's definitely an underserved need for this kind of
functionality. From the Placement side of things I would guess
there's little that would need to be done; it's more a matter of
getting other pieces and parts getting data in and out of Placement.

Discuss...

[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Tue Apr  9 12:13:18 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 13:13:18 +0100 (BST)
Subject: [placement][ptg] Containers/dockerfiles
Message-ID: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>


>From etherpad [1]:

* Some talk in the past of moving https://github.com/cdent/placedock
   into placement but not sure
* Another option is [to] trigger container build with each merge

I wrote this one, so I guess I should expand on it a bit. Basically,
placedock is a Dockerfile for placement that strives to be small but
configurable. The same repo also contains instructions (and YAML)
for using the container in kubernetes, and provides a helm chart
that uses the generated image.

Each of those three things is done in a way where many of the
choices are made for you in favor of being light and simple. In
things like Kolla, openstack-helm, and other containerizing setups
some of those choices are left as options, making the build and run
infrastructure more complex. The result with placedock is a tiny
service that scales horizontally really well.

In the past there's been talk of including some of that stuff in the
placement repo itself as a sort of "hey look, here's one way to do
it". If we did that, which stuff?

Another suggestion has been to use a web-hook or similar from zuul
to trigger an image build (either at docker hub or some other
registry) post-merge.

Or we can let things go as they are (I manually build new images
every now and again, which triggers automatic placecat [2] testing).

The reason this comes back up is because I'm somewhat concerned that
the "seriously, this is really simple" aspect of Placement gets lost
and there's probably plenty of useful info in this kind of stuff. If
we make it owned by more than just me, that might help spread the
learning.

Thoughts?k

[1] https://etherpad.openstack.org/p/placement-ptg-train

[2] https://github.com/cdent/placecat


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Tue Apr  9 12:36:13 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 13:36:13 +0100 (BST)
Subject: [placement][nova][ptg] resource provider affinity
Message-ID: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>


Spec: https://review.openstack.org/650476

>From the commit message:

     To support NUMA and similar concepts, this proposes the ability
     to request resources from different providers nested under a
     common subtree (below the root provider).

There's much in the feature described by the spec and the surrounding
context that is frequently a source of contention in the placement
group, so working through this spec is probably going to require
some robust discussion. Doing most of that before the PTG will help
make sure we're not going in circles in person.k

Some of the areas of potential contention:

* Adequate for limited but maybe not all use case solutions
* Strict trait constructionism
* Evolving the complexity of placement solely for the satisfaction
   of hardware representation in Nova
* Inventory-less resource providers
* Developing new features in placement before existing features are
   fully used in client services
* Others?

I list this not because they are deal breakers or the only thing
that matters, but because they have presented stumbling blocks in
the past and we may as well work to address them (or make an
agreement to punt them until later) otherwise there will be
lingering dread.

And, beyond all that squishy stuff, there is the necessary
discussion over the solution described in the spec. There are
several alternatives listed in the spec, and a few more in the
comments. We'd like to figure out the best solution that can
actually be done in a reasonable amount of time, not the best
solution in the absolute.

Discuss!

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From fungi at yuggoth.org  Tue Apr  9 12:42:11 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 9 Apr 2019 12:42:11 +0000
Subject: [oslo][security-sig] How to protect plain-text passwords in local.conf
In-Reply-To: <92E25B0C-C20F-45CC-8F96-8607F0C309EE@cisco.com>
References: <92E25B0C-C20F-45CC-8F96-8607F0C309EE@cisco.com>
Message-ID: <20190409124210.3axy2ch3becwu34e@yuggoth.org>

On 2019-04-09 08:21:26 +0000 (+0000), Akhil Jayakumar (akjayaku) wrote:
> Is there a way we can encrypt passwords in local.conf?
> 
> If so could you please point me to the reference?

[I've tagged the Oslo team and Security SIG in the subject of my
reply to bring this to the attention of those audiences as well.]

The problem with actually encrypting shared secrets in the
configuration directly is that whatever reads that config needs
access to the corresponding decryption key, so you haven't solved
the problem only created a new secret you also need to encrypt...
and it's turtles all the way down from there.

The oslo.config module supports pointing at external configuration
sources through the use of backend drivers[1]. One such optional
driver is castellan[2] which is designed for (among other things)
retrieving values from secure data storage applications like
Barbican and Vault. The original specification[3] for this
implementation in the Queens release a year ago describes the use
case fairly well, as does this poster presentation[4] from
EuroPython last year. Hope this helps!

[1] https://docs.openstack.org/oslo.config/latest/reference/drivers.html
[2] https://docs.openstack.org/castellan/latest/
[3] https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
[4] https://ep2018.europython.eu/media/conference/slides/mastering-applicationservice-configuration.pdf
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/6ac5cc85/attachment.sig>

From cdent+os at anticdent.org  Tue Apr  9 12:45:54 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 13:45:54 +0100 (BST)
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
Message-ID: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>


>From the etherpad [1]

* Or at least measure more things?

Perfload has proven a useful (non-voting) test job for discovering
when things are not behaving well under high writes and for having a
rough understanding the performance of GET /allocation_candidates

In a world of copious time we'd have more of this kind of
measurement. Should we investigate Rally? It used to be the tool of
choice for this kind of thing once upon a time. Is it still that
time?

Or should we continue using more focused and smaller setups, like
perfload? If so, what should they be?

Or is this something to worry about some other time?


[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From rfolco at redhat.com  Tue Apr  9 12:51:56 2019
From: rfolco at redhat.com (Rafael Folco)
Date: Tue, 9 Apr 2019 09:51:56 -0300
Subject: [tripleo] CI Community Meeting time changed
Message-ID: <CAOr2xH4qjBc1PNuN-rbKyvvDShWT+-F75QanJ-sWHkkYQXHjXA@mail.gmail.com>

The CI Community Meeting (office open hours) has been moved to 13:30 UTC
(30 minutes before the TripleO meeting).

*MEETING TIME: Every Tuesday at 13:30 UTC* in
https://bluejeans.com/4113567798.
Agenda: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

--rfolco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/b12c59f2/attachment.html>

From jaypipes at gmail.com  Tue Apr  9 12:58:26 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 9 Apr 2019 08:58:26 -0400
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.11.1904081452240.9091@seed.local>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
Message-ID: <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>

On 04/08/2019 10:25 AM, Chris Dent wrote:
> 
>  From the etherpad [1]:
> 
> * do we need this?
> * what is it?
> * who is going to drive it?
> 
> As as I recall, allocation partitioning (distinct from
> resource provider partitioning) is a way of declaring that a set of
> allocations below to a specific service. This is useful as a way,
> for example, of counting instances spawned via nova. Right now it is
> possible to count vcpus, ram and disk but if something besides nova
> is making allocations using those resource classes how do we
> distinguish?

This is more "consumer type" than anything else. In order to satisfy 
usage requests for certain classes of quota (really, just "num 
instances"), we need to know which consumers in the consumers table are 
"Nova instances" and which are not.

Obviously, all consumers are currently Nova instances in placement since 
(AFAIK) no other services have begun using placement to store allocations.

And because placement doesn't have such concepts as "local deleted" or 
"soft deleted allocations" we could actually accurately count the number 
of instances using a single simple query:

  SELECT COUNT(DISTINCT a.consumer_id)
  FROM allocations AS a
  JOIN consumers AS c
  ON a.consumer_id = c.id
  WHERE c.project_id = $PROJECT_ID
  AND c.type_id = $NOVA_INSTANCE_TYPE_ID;

> Of course it's important to also ask "should we distinguish?". If
> there's a concept of unified limits does it matter whether a VCPU is
> consume by _this_ nova or something else if they are consumed by the
> same user?

So this is referring to resource provider partition (source partition), 
not consumer type. For the problem of detecting whether an instance is 
in *this* Nova or another Nova deployment that uses the same placement 
service, we need a source partition identifier in the resource_providers 
table.

Also keep in mind that Keystone's unified limits are still divisible by 
*region*, which would serve as a natural source partition identifier I 
suppose.

> This functionality is closely tied to resource provider
> partitioning. In a complex placement scenario, where placement is
> managing multiple instance spawning tools, in multiple cloud-like
> things, it seems like both would be needed.

Yes, this. In order to get the number of Nova instances in a specific 
deployment of Nova (or region), the above query would instead look like 
this:

  SELECT COUNT(DISTINCT a.consumer_id)
  FROM allocations AS a
  JOIN consumers AS c
  ON a.consumer_id = c.id
  JOIN resource_providers AS rp
  ON a.resource_provider_id
  WHERE c.project_id = $PROJECT_ID
  AND c.type_id = $NOVA_INSTANCE_TYPE_ID
  AND rp.source_partition_id = $NOVA_REGION_ID;

> The ongoing work to implement quota counting in placement [2] has a
> workaround for instances not being counted in placement, but the
> "more than one nova per placement" limitation has to be documented.
> 
> How urgent is this? Is there anyone available to do the work this
> cycle? How damaging is it to punt to U? What details are missing in
> the above description?

Not sure of the answers to this question. As with most features like 
this, 95% of the work seems to end up being in the upgrade path and not 
adding the feature itself. For both the consumer type and source 
partition identification, the upgrade path would entail setting default 
consumer type for all existing consumers and source partition 
identifiers for all existing resource providers.

Best,
-jay

> [1] https://etherpad.openstack.org/p/placement-ptg-train
> [2] 
> https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement
> 


From cdent+os at anticdent.org  Tue Apr  9 13:00:36 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 14:00:36 +0100 (BST)
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
Message-ID: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>


>From the etherpad [1]:

* Last PTG for Stein, we decided the following policies and have done so in Stein

     A) Aggregate on root spans whole tree for ``members_of=``
        requests in 'GET /allocation_candidates'
     B) This spanning policy doesn't apply to granular requests
        ``members_of<N>=`` or to requests in 'GET /resource_providers'
     C) This change is a bug fix without microversion

   However, I now feel the policy B is weird. Consider a case where
   only granular requests are used in the request. If operator puts
   aggA on root, aggA applies the child or not depends on cases how
   you created the request. That's very difficult for operators to
   debug...

This is from Tetsuro, so perhaps he can add some additional info,
but basically I think what's being requested here is some discussion
on whether changing B is warranted.

[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From smooney at redhat.com  Tue Apr  9 13:04:40 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 09 Apr 2019 14:04:40 +0100
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
Message-ID: <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>

On Mon, 2019-04-08 at 19:05 -0400, Clark Boylan wrote:
> 
> On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> > Hi, Clark
> > 
> > I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> > virtualization.
> > 
> 
> Can you describe this requirement in a bit more detail? Looking at docs it appears you need to have large pages. Maybe
> a "picture" will help too:
> 
>   Workload VM
>   (cirros or similar small VM running under
>    emulation or virtualized if nested virt is enabled)
>        |
>       V
>   OpenStack Infra Test Node ("middle VM")
>     This is where ovsdpdk runs right? And this requires large pages?
so ovs-dpdk requires hugepage memeory to be allocated to fucntion but that
by its self does not require nested virt. nova on the other hand does require
kvm to allow vms to be spawned with hugepages because not enabled partial cpu
pinning when hugepages are enabled and qemu does not support per cpu cpu pinning without kvm or the mttcg
backend. 

in the special case of ovs-dpdk i have been meaning to test an alternitive way for deploying with ovs-dpdk
but to date i have not had time. about 2 years ago i had a memeber of my team extend libvirt to allow
the creation of qemu guests with file backed memory. about a year ago redhat extended nova to support that.
it should technically be possibel to run ovs-dpdk with hugepages and the cirros guests with file backed
memory to do testing without nested virt.

related to this i finished setting up my own personal ci to do limited ovs-dpdk and numa/nfv testing with nested virt.
https://review.openstack.org/#/c/650573/
tempest-dpdk https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-dpdk/fec9044/
tempest-pinning https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-pinning/1939971/

i am planning to exprement to see if i can run some of those nested virt jobs upstream or via openlab in the furutre.

it shoudl be possible to test with ovn too but i have not tried that pesonally yet
the job definitions currently live in https://review.seanmooney.info/plugins/gitiles/test/+/master so perhaps that ill
server as a starting point for people wanting to create similar jobs 

the networking-ovs-dpdk devstack plugin compiles and deploys ovs-dpdk form source which also installs
but does not configure or start ovn since its part of the ovs repo.

with some tweeks to the networking-ovn plugin it would probably be simple enough to use both plugins to provide the 
desired versions of ovn,ovs and dpdk.

with all that said the intel nvf ci was created to test ovs-dpdk integration with openstack and also some other
nfv features like cpu pinning. https://wiki.openstack.org/w/index.php?title=ThirdPartySystems/Intel_NFV_CI
this ci was also intended to test odl and ovn with ovs dpdk at somepoint in the future
alther that never happend. i woudl suggest reaching out to   <timothy.gresham at intel.com>, <openstack-nfv-ci at intel.com>
to see if it could be extended to do ovn testing in the absence of upstream support.

>        |
>       V
>   Hypervisor (managed by our cloud providers)
> 
> Are we not able to do large pages with emulated workload VMs? Also can we do large pages on the Workload VM if the
> Infra Test Node isn't configured for them? If the infra test node isn't configured for them do we also need support
> for large pages from the Hypervisor?
> 
> If we can do large pages with emulated workload VMs and the hypervisor isn't required to support that we should be
> able to configure large pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of
> these things won't work.
> In any case specific details on what is required and where it is required will be useful.
> 
> Clark
> 



From cdent+os at anticdent.org  Tue Apr  9 13:04:48 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 14:04:48 +0100 (BST)
Subject: [placement][ptg] Envisioning other technologies
Message-ID: <alpine.OSX.2.21.1904091401170.93787@cdent-a01.vmware.com>


>From the etherpad [1]:

("My" in here is edleafe)

* The more we get into the complexities of modeling nested
   providers, the more it seems to me that we are not using the best
   technology for this task. My brief experiments with graph
   databases last year showed a great deal of promise, but the whole
   extraction process pushed that to the side.

* Perhaps we might try some parallel development, where resources
   are modeled in both relational and graph DBs. Then we might be
   able to compare the different solutions to complex queries on the
   same data sets.

This is an invitation to discuss other potentially useful
technologies, the relative cost of exploring them, and benefits we
might get from that exploration (even if we don't end up using the
other tech).

And anything else anyone else wants to add.

[1] https://etherpad.openstack.org/p/placement-ptg-train


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From smooney at redhat.com  Tue Apr  9 13:07:59 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 09 Apr 2019 14:07:59 +0100
Subject: resize a vm to a flavor with pci-passthrough
In-Reply-To: <40105c6b-6db9-5342-0ff0-5da1292a332f@gmail.com>
References: <9D8A2486E35F0941A60430473E29F15B017E8A0A68@MXDB1.ad.garvan.unsw.edu.au>
 <40105c6b-6db9-5342-0ff0-5da1292a332f@gmail.com>
Message-ID: <bfcdf48248a3e95c63d469423c3c617973e56b17.camel@redhat.com>

On Tue, 2019-04-09 at 07:16 -0400, Jay Pipes wrote:
> On 04/08/2019 01:45 AM, Manuel Sopena Ballesteros wrote:
> > Dear Openstack community,
> > 
> > I have 1 physical node with x4 nvidia nv100 running 1 fat vm. 
> > Additionally I am adding a nvme drive into that host and I would like to 
> > attach the nvme drive to the vm. Ideally I prefer to avoid data 
> > migration and redeploy the software.
> > 
> > My problem is that I don’t have another host with gpus so I am guessing 
> > that the vm can’t be migrated. Am I right assuming this?
> > 
> > So far I thought about 2 possibilities but I don’t know whether they 
> > would work:
> > 
> > Option 1: crate a new flavor with the pci device pass-through and resize 
> > existing vm (I hope the new vm with the new flavor will have the nvme 
> > attached).
> > 
> > Option 2: convert ephemeral virtual disk into a bootable volume. Destroy 
> > vm. Create new vm with the new volume as a boot device.
> > 
> > Which option would be preferred? Is there any other think I can do?
> 
> Put your application data in a different location than your application 
> configuration and operating system. Save that application state in a 
> separate Cinder volume. You can then attach and detach the application 
> state to a (much smaller) root disk image that just contains the 
> operating system and installed application binaries.
> 
> Once you've done the above, then you won't need to fret about 
> "avoid(ing) migration and redeploy the software".
> 
> Put the effort in up front to do this application state separation and 
> your life will be much, much easier.
+1 this should always be your first step i think when runing any applicaiton in a cloud
env.

i used to even do this for my dev vms where i woudl put /opt/stack on a cinder voluems so that if i
ever need to rebuild the vm i just remounted it and have my devstack env ready to go.
> 
> Best,
> -jay
> 



From jaypipes at gmail.com  Tue Apr  9 13:14:54 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 9 Apr 2019 09:14:54 -0400
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.11.1904081436290.9091@seed.local>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
Message-ID: <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>

On 04/08/2019 10:25 AM, Chris Dent wrote:
> 
>  From the etherpad [1]:
> 
> * do we need this?
> * what is it?
> * who is going to drive it?
> 
> As as I recall, resource provider partitioning (distinct from
> allocation partitioning) is a way of declaring that a set of
> resource providers are in a thing. This would allow, for example,
> one placement to service multiple OpenStack clouds or for a
> placement to be a part of a single pane of glass system in a FOG or
> edge setup.
> 
> This was mentioned during Stein nova discussions [2] but since then
> I've not personally heard a lot of discussion on this topic so it's
> unclear if it is a pressing issue. Do we want to be build it so they
> come, or wait until they come and then build it?
> 
> The discussion at [2] mentions the possibility of an
> 'openstack-shard' header (instead of query parameter) that would be
> sent with any request to placement.
> 
> There is, however, no substantive discussion on the internal
> implementation. Options:
> 
> * Do nothing (see above)
> * Internally manipulate aggregates (all these resource providers
>    below to shard X).

The problem with this implementation is that resource providers can 
belong to zero or multiple aggregates, of course. And a "shard" or 
"source partition" is clearly something that a provider only belongs to 
*one of* and *must* belong to only one.

> * Add a 1:1 or 1:N relation between an RP and a shard uuid in the
>    DB.

1:1 is the only thing that makes sense to me. Therefore, it should be a 
field on the resource_providers table (source_id or partition_id or 
whatever).

> * Use a trait! [3]

Same problem as aggregates. A provider can have zero or more traits, 
therefore we would run into the same unholy mess that we currently have 
in Nova aggregate metadata for "availability zones": we need a bunch of 
hack code to make sure that nobody associates a compute service with 
multiple aggregates *if* those aggregates have different 
availability_zone metadata keys.

Yuck. This is why getting the data model right is so important... and 
why bolting on attributes to the wrong entity or cramming relational 
data into a JSON blob always ends up biting us in the long run.

> But before we get into implementation details we should discuss the
> use cases for this (if any), the need to do it (if any), and the
> people who will do it (if any). All three of those are thin at
> this point.

Mentioned in the other thread on consumer types (what you are calling 
allocation partitioning for some reason), but the best *current* use 
case for these partitions/types is in solving the quota usage 
calculations in an efficient manner using the placement data model.

Best,
-jay

> [1] https://etherpad.openstack.org/p/placement-ptg-train
> [2] around lines 243 on https://etherpad.openstack.org/p/nova-ptg-stein
>      where both types (allocation/rp) of partitioning are discussed.
> [3] Not for the trait strict constructionists.
> 


From ed at leafe.com  Tue Apr  9 13:16:26 2019
From: ed at leafe.com (Ed Leafe)
Date: Tue, 9 Apr 2019 08:16:26 -0500
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
In-Reply-To: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
Message-ID: <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>

On Apr 9, 2019, at 7:45 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> In a world of copious time we'd have more of this kind of
> measurement. Should we investigate Rally? It used to be the tool of
> choice for this kind of thing once upon a time. Is it still that
> time?
> 
> Or should we continue using more focused and smaller setups, like
> perfload? If so, what should they be?
> 
> Or is this something to worry about some other time?

As we do not have “copious time”, I think that this is not something we need right now. We do have a check in place in case something goes wrong, so I think our attention can best be directed elsewhere for now.

-- Ed Leafe







From moguimar at redhat.com  Tue Apr  9 13:17:31 2019
From: moguimar at redhat.com (Moises Guimaraes de Medeiros)
Date: Tue, 9 Apr 2019 15:17:31 +0200
Subject: [oslo][security-sig] How to protect plain-text passwords in
 local.conf
In-Reply-To: <20190409124210.3axy2ch3becwu34e@yuggoth.org>
References: <92E25B0C-C20F-45CC-8F96-8607F0C309EE@cisco.com>
 <20190409124210.3axy2ch3becwu34e@yuggoth.org>
Message-ID: <CAG_6SUDFAM0dgBzSGs3jBTPVhPntHuK03DUFAPHNv7SJJ51OtQ@mail.gmail.com>

Hi Akhil,

Right now oslo.config is capable of loading configuration values from files
(default), environment variables (env driver), command line arguments
(default), remote files (remote_file driver) and castellan (castellan
driver).

This gives you enough flexibility to come up with a hardening strategy
according to the use case. If you have any questions on how to use each
driver I'd be glad to answer as I wrote most of them.

Best regards,
Moisés Guimarães

Em ter, 9 de abr de 2019 às 14:43, Jeremy Stanley <fungi at yuggoth.org>
escreveu:

> On 2019-04-09 08:21:26 +0000 (+0000), Akhil Jayakumar (akjayaku) wrote:
> > Is there a way we can encrypt passwords in local.conf?
> >
> > If so could you please point me to the reference?
>
> [I've tagged the Oslo team and Security SIG in the subject of my
> reply to bring this to the attention of those audiences as well.]
>
> The problem with actually encrypting shared secrets in the
> configuration directly is that whatever reads that config needs
> access to the corresponding decryption key, so you haven't solved
> the problem only created a new secret you also need to encrypt...
> and it's turtles all the way down from there.
>
> The oslo.config module supports pointing at external configuration
> sources through the use of backend drivers[1]. One such optional
> driver is castellan[2] which is designed for (among other things)
> retrieving values from secure data storage applications like
> Barbican and Vault. The original specification[3] for this
> implementation in the Queens release a year ago describes the use
> case fairly well, as does this poster presentation[4] from
> EuroPython last year. Hope this helps!
>
> [1] https://docs.openstack.org/oslo.config/latest/reference/drivers.html
> [2] https://docs.openstack.org/castellan/latest/
> [3]
> https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html
> [4]
> https://ep2018.europython.eu/media/conference/slides/mastering-applicationservice-configuration.pdf
> --
> Jeremy Stanley
>


-- 
Thanks,
Moisés Guimarães
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/3d393181/attachment-0001.html>

From edmondsw at us.ibm.com  Tue Apr  9 13:18:00 2019
From: edmondsw at us.ibm.com (William M Edmonds - edmondsw@us.ibm.com)
Date: Tue, 9 Apr 2019 13:18:00 +0000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <4b7a8de3-f1f1-dc25-590b-03bd3bd0bd9f@openstack.org>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <4b7a8de3-f1f1-dc25-590b-03bd3bd0bd9f@openstack.org>
Message-ID: <BAE730FF-81FA-4C10-9663-A772539768F3@us.ibm.com>


On 4/9/19, 7:26 AM, "Thierry Carrez" <thierry at openstack.org> wrote:
> SIGs can produce code. The difference with project teams is that our 
> project teams are organized around a specific component (Nova, Swift...) 
> or a horizontal software development function that applies to all those 
> components (QA, Documentation, release management, common libraries...)

Honest question, what SIGs produce code in repos that they own/maintain separate from nova, etc.? Point me to those repos so we can talk examples? My understanding of SIGs is that they're primarily focused on requirements gathering and communication for their area of interest and then trying to drive corresponding changes into code that is actually owned/maintained by other teams like nova. I don't know of any SIG producing anything like what is produced/maintained by PowerVMStackers. Scrolling through the list of current SIGs [1], none of them sound like they're writing a lot of code that they own/maintain. Writing code that goes into nova, etc. sure, but not that they own/maintain independently. Maybe I'm just uninformed?

Note: More PowerVMStackers requirements come from nova than from any PowerVM stakeholder, just keeping up with changes that nova implements.

> Once you frame it like that, you can spot a few outliers in the current 
> project team list: things that are neither centered around a specific 
> component nor a horizontal function: PowerVMStackers and Winstackers.

I definitely understand/agree that PowerVMStackers is an outlier here. And I would never have wanted things this way. PowerVMStackers absolutely _should_ be a SIG (as I said in my previous note) but only if a) the drivers/agents that it currently contains are properly rehomed under nova, neutron, and ceilometer. Then PowerVMStackers could be like other SIGs, collecting requirements from folks interested in Power and implementing those requirements in nova, etc. Or b) I'm wrong about SIGs (or we can modify them to address the issues) per the questions above.

> That said, I understand your objection. Establishing PowerVMStackers as 
> a SIG clearly sends the message that caring about PowerVM is a special 
> interest and not everyone's interest. It makes it less likely that the 
> *-powervm repository/features ever get merged into their respective 
> projects. And if this merging is right around the corner, I agree that 
> setting up a PowerVM SIG is counterproductive.

That's not my objection at all, at least not the special interest part. The "less likely" part is definitely a concern, but honestly I hadn't even thought of that until you pointed it out.

> So I guess the real question is, is PowerVM support a mainline feature 
> that just happens to be temporarily maintained under a specific team for 
> weird organizational reasons ? Or is it considered not to be mainline 
> material (a bit like Windows support), and therefore the people that 
> care about that feature should maintain code to support that 
> indefinitely on the side ?

I don't see why PowerVM support should be any less mainline than the Hyper-V and VMware drivers that currently fall under the nova umbrella. We have far more users than both of those drivers combined, a strong history of community involvement, etc. So yeah, I'd say mainline if those are considered mainline.

> If it's the former, and there is a clear plan to get all that 
> functionality up in their respective teams in a near future, then I 
> agree a SIG won't really help. If the latter though, I really think that 
> a SIG is a much better way to represent what is happening there, and 
> would give the "PowerVM support" SIG extra visibility.
> 
> My impression is that it's been 4 years now that those repositories 
> exist separately from Nova, Neutron and Ceilometer and nobody seems in a 
> hurry to merge that functionality there... which is why I assumed the 
> latter.

The nova cores didn't let us _start_ merging it until last year. :) And as I said, that's an arduous process. We've been asked to port one function at a time and take it through the normal rigorous review process. I understand why, and I'm not saying I disagree, but I want to be clear that that kind of migration is going to take a while.

But I want to be clear... I don't think everything would have to move into the nova git repo to be under the compute project umbrella. We could hasten that along by just moving nova-powervm from PowerVMStackers to Compute, like os-vif and python-novaclient. And then similar with networking-powervm and ceilometer-powerm under Networking and Telemetry, respectively.

[1] https://governance.openstack.org/sigs/


From jaypipes at gmail.com  Tue Apr  9 13:33:20 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 9 Apr 2019 09:33:20 -0400
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
In-Reply-To: <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>
References: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
 <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>
Message-ID: <bf5380e3-402b-7808-74e6-2e70bd73b938@gmail.com>

On 04/09/2019 09:16 AM, Ed Leafe wrote:
> On Apr 9, 2019, at 7:45 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>>
>> In a world of copious time we'd have more of this kind of
>> measurement. Should we investigate Rally? It used to be the tool of
>> choice for this kind of thing once upon a time. Is it still that
>> time?
>>
>> Or should we continue using more focused and smaller setups, like
>> perfload? If so, what should they be?
>>
>> Or is this something to worry about some other time?
> 
> As we do not have “copious time”, I think that this is not something we need right now. We do have a check in place in case something goes wrong, so I think our attention can best be directed elsewhere for now.

Agree with Ed. :)

-jay


From kchamart at redhat.com  Tue Apr  9 13:41:37 2019
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 9 Apr 2019 15:41:37 +0200
Subject: [nova] "future" specs and blueprints
In-Reply-To: <20190402144149.ls57ybt5n4celdxy@yuggoth.org>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <20190402105651.GB28897@paraplu>
 <20190402144149.ls57ybt5n4celdxy@yuggoth.org>
Message-ID: <20190409134137.GE28897@paraplu>

On Tue, Apr 02, 2019 at 02:41:49PM +0000, Jeremy Stanley wrote:
> On 2019-04-02 12:56:51 +0200 (+0200), Kashyap Chamarthy wrote:
> [...]
> > So yes, having this `specs/backlog/approved` does have a benefit (even
> > if it is 'marginal') than "leaving things as unmerged in Gerrit", where
> > every spec is a bland Gerrit URL, and their HTML renderings will have
> > gotten purged.
> [...]
> 
> If the draft rendering has expired and you don't feel like
> generating one locally with tox (or even just by calling
> sphinx-build directly), you can also leave a "recheck" comment on
> the change and come back later.

Ah, thanks for the tip.  I keep forgetting that.  (Still, it's
inconvenient, as it breaks URLs. But it's not a show-stopper.)



-- 
/kashyap


From thierry at openstack.org  Tue Apr  9 13:44:41 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 9 Apr 2019 15:44:41 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <BAE730FF-81FA-4C10-9663-A772539768F3@us.ibm.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <4b7a8de3-f1f1-dc25-590b-03bd3bd0bd9f@openstack.org>
 <BAE730FF-81FA-4C10-9663-A772539768F3@us.ibm.com>
Message-ID: <5ff88a79-8038-67b9-2824-1cfbda5bd6de@openstack.org>

William M Edmonds - edmondsw at us.ibm.com wrote:
> 
> On 4/9/19, 7:26 AM, "Thierry Carrez" <thierry at openstack.org> wrote:
>> SIGs can produce code. The difference with project teams is that our
>> project teams are organized around a specific component (Nova, Swift...)
>> or a horizontal software development function that applies to all those
>> components (QA, Documentation, release management, common libraries...)
> 
> Honest question, what SIGs produce code in repos that they own/maintain separate from nova, etc.? Point me to those repos so we can talk examples? My understanding of SIGs is that they're primarily focused on requirements gathering and communication for their area of interest and then trying to drive corresponding changes into code that is actually owned/maintained by other teams like nova. I don't know of any SIG producing anything like what is produced/maintained by PowerVMStackers. Scrolling through the list of current SIGs [1], none of them sound like they're writing a lot of code that they own/maintain. Writing code that goes into nova, etc. sure, but not that they own/maintain independently. Maybe I'm just uninformed?

You can find the reference list of repositories attached to SIGs at:

https://git.openstack.org/cgit/openstack/governance/tree/reference/sigs-repos.yaml

Most of those maintain documentation repos (and land their code into 
existing repositories). Only the Security SIG currently maintains code 
repos.

-- 
Thierry


From dtroyer at gmail.com  Tue Apr  9 13:51:49 2019
From: dtroyer at gmail.com (Dean Troyer)
Date: Tue, 9 Apr 2019 08:51:49 -0500
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
 <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>
Message-ID: <CAOJFoEspZiVSzf-Dd9re=RQw5xQEgr5dU4A--xPxj5raZuV0wQ@mail.gmail.com>

On Tue, Apr 9, 2019 at 8:05 AM Sean Mooney <smooney at redhat.com> wrote:
> with all that said the intel nvf ci was created to test ovs-dpdk integration with openstack and also some other
> nfv features like cpu pinning. https://wiki.openstack.org/w/index.php?title=ThirdPartySystems/Intel_NFV_CI
> this ci was also intended to test odl and ovn with ovs dpdk at somepoint in the future
> alther that never happend. i woudl suggest reaching out to   <timothy.gresham at intel.com>, <openstack-nfv-ci at intel.com>
> to see if it could be extended to do ovn testing in the absence of upstream support.

The Intel 3rd Party CI has been rebuilt from the ground-up using Zuul
v3 and the rest of the tooling we all know and love, it is currently
in the sort of final internal review where we can not predict the
timing, hence my reluctance to make promises of being ready by X date,
but it is "soon".  These are among the test cases we intend to
resurrect, first priority being the testing the old CI setups had been
doing.

dt

-- 
Dean Troyer
dtroyer at gmail.com


From smooney at redhat.com  Tue Apr  9 13:55:21 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 09 Apr 2019 14:55:21 +0100
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
In-Reply-To: <bf5380e3-402b-7808-74e6-2e70bd73b938@gmail.com>
References: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
 <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>
 <bf5380e3-402b-7808-74e6-2e70bd73b938@gmail.com>
Message-ID: <6806ae976a91c5f47629daded10727193941a10e.camel@redhat.com>

On Tue, 2019-04-09 at 09:33 -0400, Jay Pipes wrote:
> On 04/09/2019 09:16 AM, Ed Leafe wrote:
> > On Apr 9, 2019, at 7:45 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> > > 
> > > In a world of copious time we'd have more of this kind of
> > > measurement. Should we investigate Rally? It used to be the tool of
> > > choice for this kind of thing once upon a time. Is it still that
> > > time?
> > > 
> > > Or should we continue using more focused and smaller setups, like
> > > perfload? If so, what should they be?
> > > 
> > > Or is this something to worry about some other time?
> > 
> > As we do not have “copious time”, I think that this is not something we need right now. We do have a check in place
> > in case something goes wrong, so I think our attention can best be directed elsewhere for now.
> 
> Agree with Ed. :)
if there was a placement specific tempest plugin woudl that not enmable rally to work automatically.
im wondering if the gabbi tempest plugin coudl be used to execute the placeim api test via rally with
some tweeking to the relevent config files?

> 
> -jay
> 



From cdent+os at anticdent.org  Tue Apr  9 14:02:43 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 15:02:43 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
Message-ID: <alpine.OSX.2.21.1904091445250.93787@cdent-a01.vmware.com>

On Tue, 9 Apr 2019, Jay Pipes wrote:
> On 04/08/2019 10:25 AM, Chris Dent wrote:

First, I'm trying to integrate several different mental models here,
which is probably why my terminology is a bit confused. There are
similar but not concurrent models from Dan, Jay, Mel, and Matt (that
I can recall) that we'll want to synchronized before we get too much
further on this.

> This is more "consumer type" than anything else. In order to satisfy usage 
> requests for certain classes of quota (really, just "num instances"), we need 
> to know which consumers in the consumers table are "Nova instances" and which 
> are not.

This is one of the mental models: Identify a consumer as having a type: "this
is a nova (any nova) instance". "consumer type", perhaps.

That's slightly different from another one of the mental models
which is: Identify a consumer as having a source: "this is from
service X (which happens to be a nova)". "consumer source", perhaps.

In the latter, at least some comments have involved there being
multiples services (of the same _type_) in the same OpenStack. I
don't know that this is a thing, yet, but it presumed to be
something that is possible, so not something we want to prevent in
the data model.

>> Of course it's important to also ask "should we distinguish?". If
>> there's a concept of unified limits does it matter whether a VCPU is
>> consume by _this_ nova or something else if they are consumed by the
>> same user?
>
> So this is referring to resource provider partition (source partition), not 
> consumer type. For the problem of detecting whether an instance is in *this* 
> Nova or another Nova deployment that uses the same placement service, we need 
> a source partition identifier in the resource_providers table.

That's not what I was trying to get at with my comment. What I was
wonder was:

If there exists a quota for VCPU does it matter how those VCPU are
being consumed in the entire quota domain? Does it matter if the
consumption is via nova or some other compute provisioning tool?

I'll try to address the multiple mental models for resource provider
partitioning in the other thread. Identify and resolving the
differences in mental models prior to the PTG is one of the main
reasons for having these threads, so huge success so far.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Tue Apr  9 14:14:35 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 15:14:35 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
Message-ID: <alpine.OSX.2.21.1904091502510.93787@cdent-a01.vmware.com>


For those following along, probably useful to also see my response on
the allocation partitioning thread (which may be misnamed):

http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004800.html

more within...

On Tue, 9 Apr 2019, Jay Pipes wrote:

>> * Internally manipulate aggregates (all these resource providers
>>    below to shard X).

oops, belong

> The problem with this implementation is that resource providers can belong to 
> zero or multiple aggregates, of course. And a "shard" or "source partition" 
> is clearly something that a provider only belongs to *one of* and *must* 
> belong to only one.

I agree that aggregates may be a bad choice because of the option to
belong to zero but we could control that above the db level if we
cared to. Not making a vote for aggregates here, just pointing out
that we have the power to do what we want, and aggregates provide an
existing grouping model. And these are groups.

Do we want to enforce that any resource provider only belongs to one
partition? If so, why? By calling them shards or partitions, then
sure, that cardinality makes sense, but what happens when some
bright bulb decides there is a monster inter-galactic storage
service that can serve multiple clouds, transparently [1]? Do we
want the data model to prevent that?

>> * Add a 1:1 or 1:N relation between an RP and a shard uuid in the
>>    DB.
>
> 1:1 is the only thing that makes sense to me. Therefore, it should be a field 
> on the resource_providers table (source_id or partition_id or whatever).

See above.

>> But before we get into implementation details we should discuss the
>> use cases for this (if any), the need to do it (if any), and the
>> people who will do it (if any). All three of those are thin at
>> this point.
>
> Mentioned in the other thread on consumer types (what you are calling 
> allocation partitioning for some reason), but the best *current* use case for 
> these partitions/types is in solving the quota usage calculations in an 
> efficient manner using the placement data model.

As with the allocation partitioning thread, the mental models that I'm
trying to integrate here also similar but not coincident:

* A placement service that manages resources in multiple things,
   some of them happen to be disjoint OpenStack clounds.

* A single placement in a multi-region OpenStack.

* Others I can't remember right this minute but hope will come out
   in further conversation.


[1] by way of quantum entanglement, you see...

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From anyrude10 at gmail.com  Mon Apr  8 11:04:49 2019
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Mon, 8 Apr 2019 16:34:49 +0530
Subject: [Magnum] x509: certificate signed by unknown authority
Message-ID: <CAKxkTi255j0nfvNhrkPKw2TDh7492+8kjRn-Y3evYxbWa_-30Q@mail.gmail.com>

Hi Team,

I have deployed K8s cluster using Magnum Openstack Rocky Release.
I have one master node and one slave node in my cluster.
But when I try to create a POD on master node using the command

*kubectl run nginx --image=nginx*

My Container remains in ContainerCreating State.
When I debugged into the issue, I found the below error

*Warning  FailedCreatePodSandBox  59s (x24 over 32m)  kubelet,
kubernetes-cluster-w6csm5uqyspz-minion-0  Failed create pod sandbox: rpc
error: code = Unknown desc = failed pulling image
"gcr.io/google_containers/pause:3.0
<http://gcr.io/google_containers/pause:3.0>": x509: certificate signed by
unknown authority*

However, in */etc/sysconfig/docker* file,
I have disabled the gcr.io repository.

OPTIONS='--insecure-registry="gcr.io,googleapis.com" --selinux-enabled '

The docker is successfully pulling the *gcr.io/google_containers/pause:3.0
<http://gcr.io/google_containers/pause:3.0> image,* BUT kubernetes is
neither able to use local repository nor able to pull the image.

Can someone please help me in resolving the *x509: certificate signed by
unknown authority issue?*

Regards
Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/64bfd034/attachment.html>

From anyrude10 at gmail.com  Mon Apr  8 11:05:53 2019
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Mon, 8 Apr 2019 16:35:53 +0530
Subject: Fwd: [Magnum] x509: certificate signed by unknown authority
In-Reply-To: <CAKxkTi255j0nfvNhrkPKw2TDh7492+8kjRn-Y3evYxbWa_-30Q@mail.gmail.com>
References: <CAKxkTi255j0nfvNhrkPKw2TDh7492+8kjRn-Y3evYxbWa_-30Q@mail.gmail.com>
Message-ID: <CAKxkTi3ubjWh=5m2fevAnJt3J3LARJeiX28yY+iWWObnQnview@mail.gmail.com>

Hi Team,

I have deployed K8s cluster using Magnum Openstack Rocky Release.
I have one master node and one slave node in my cluster.
But when I try to create a POD on master node using the command

*kubectl run nginx --image=nginx*

My Container remains in ContainerCreating State.
When I debugged into the issue, I found the below error

*Warning  FailedCreatePodSandBox  59s (x24 over 32m)  kubelet,
kubernetes-cluster-w6csm5uqyspz-minion-0  Failed create pod sandbox: rpc
error: code = Unknown desc = failed pulling image
"gcr.io/google_containers/pause:3.0
<http://gcr.io/google_containers/pause:3.0>": x509: certificate signed by
unknown authority*

However, in */etc/sysconfig/docker* file,
I have disabled the gcr.io repository.

OPTIONS='--insecure-registry="gcr.io,googleapis.com" --selinux-enabled '

The docker is successfully pulling the *gcr.io/google_containers/pause:3.0
<http://gcr.io/google_containers/pause:3.0> image,* BUT kubernetes is
neither able to use local repository nor able to pull the image.

Can someone please help me in resolving the *x509: certificate signed by
unknown authority issue?*

Regards
Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190408/b72d9d37/attachment.html>

From sahid.ferdjaoui at canonical.com  Tue Apr  9 15:34:52 2019
From: sahid.ferdjaoui at canonical.com (Sahid Orentino Ferdjaoui)
Date: Tue, 9 Apr 2019 17:34:52 +0200
Subject: [nova] indices on shadow-able fields
In-Reply-To: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
References: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
Message-ID: <20190409153452.GA16521@canonical>

On Mon, Apr 08, 2019 at 10:51:47PM -0400, Mohammed Naser wrote:
> Hi everyone.
> 
> In continuing with the trend of interesting database issues, I've
> found the following interesting thing.  It looks like we don't have
> indices for all of our tables that can be large on the deleted field.
> I think it would be beneficial *especially* for cases when the
> archiving code runs.
> 
> The big ones that are huge users in terms of rows without index are
> `instance_system_metadata` and `instance_extra`.
> `instance_action_events` and `instance_actions` don't have any either.
> 
> I believe without this, it results in doing a full table scan during
> the clean up which can become pretty resource intensive.
> 
> I'll defer to the Nova team on the best practice about this (or if
> this is even a bug), but I just wanted to bring the attention to this
> as I've had mild success trying to tame a large database and
> leveraging the archive DB tooling.

I don't think we query shadow tables or it's when we want to purge
them, so basically that is going to be based on datetime.  I may be
wrong but adding an index for a datetime field may not be so
interesting since the index is going to be quite large because of the
hours, minutes, seconds. That needs to be verified the database may
provides feature to index datetime using date only. If so I guess you
raised a good point, if not, indexing such fields is not going to help
and probably going to consum more resources.

s.

> Thanks,
> Mohammed
> 
> -- 
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com


From gagehugo at gmail.com  Tue Apr  9 15:50:05 2019
From: gagehugo at gmail.com (Gage Hugo)
Date: Tue, 9 Apr 2019 10:50:05 -0500
Subject: [OSSA-2019-002] Unable to install new flows on compute nodes when
 having broken security group rules (CVE-2019-10876)
Message-ID: <CAE4Awf80gnyGtaV-LYwjX0n_aE7WJqHEe0dd9KN66uN1LQv=9g@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

===========================================================================================
OSSA-2019-002: Overlapping security group rules prevents compute node
network configuration
===========================================================================================

:Date: April 08, 2019
:CVE: CVE-2019-10876


Affects
~~~~~~~
- - Neutron: >=11.0.0 <11.0.7, >=12.0.0 <12.0.6, >=13.0.0 <13.0.3


Description
~~~~~~~~~~~
Diko Parvanov (Canonical) reported a vulnerability in neutron-
openvswitch-agent security group rules. By creating two security
groups with separate/overlapping port ranges, an authenticated user
may prevent neutron from being able to configure networks on any
compute nodes where those security groups are present. All neutron
deployments utilizing neutron-openvswitch-agent are affected.


Patches
~~~~~~~
- - https://review.openstack.org/648102 (Pike)
- - https://review.openstack.org/648004 (Queens)
- - https://review.openstack.org/648003 (Rocky)
- - https://review.openstack.org/648002 (Stein)
- - https://review.openstack.org/640252 (Train)


Credits
~~~~~~~
- - Diko Parvanov from Canonical (CVE-2019-10876)


References
~~~~~~~~~~
- - https://launchpad.net/bugs/1813007
- - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10876
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAlysvccACgkQ56j9K3b+
vREj3BAAvVBLfJT/cOyk2VjXjvlNKBWs1uokNE5PwzT0M2kvEW42zG78JpJj9EyJ
ONQMCiuclWJ6XcBLBhDG2MHzl31Rqnfhi1UxQoUPwZYtgTcokLa4NaGCQUMrRwpq
vigC8zWA9SiIQBHp4b/HE1ZA0GCKgK5CS2OuqmQH25/AzIDqwZZ7ljstRMh28VDd
PnorJwifeKq1uUL1AGRWmDUvfYaqzTbMxNlUcrXt2Iy50VLxdokmD+PtZMLvb7lq
UcpJ7R/er6HipNDE42hNzQAgEoPBNJ3hwEiLU64ZPCxSCMeKos5d2yAPNwLUYwdm
lVYJQtW1GkNDLvY37pHOFzFCK2XhjKQB29iZjz5ipC9EKs1HLnxCfJfvIS+bK3Bt
c3R0frUOOiDPeP+so1edl1f0eZJlhzV3SlFsLfLfFa1BYTxj6uuQdSaPaOTCGaLN
4TLAtysGl+USvXirOH+F/vuz9P0LOlL4f86/gwNY9Asb27MmKZFtUhQLux/k34Xg
gwSFtWTKqLJWrZjlGL/9irh6PiS6myrPCxsYh8XXOpVHSw5D353NrZ3hapvUthA6
BoArm9XxRlwzgu8JwXpEAc9FXRg3jUcwMrSYc5yZF4mw95+sfdHKVhoI6LuxBkYd
dA0aqbB/QkuFSanDZ+Z634LCkfbk/2Eo3HgjsrPUdvg2z2zLwfk=
=53iD
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/5738c1fc/attachment-0001.html>

From pierre at stackhpc.com  Tue Apr  9 15:50:34 2019
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 9 Apr 2019 16:50:34 +0100
Subject: [blazar] Scheduling a new Blazar IRC meeting for the Americas
Message-ID: <CA+ny2swohYqrNHfzOt-pDTBYSsrJ0nS1pfw3oOgm15CZ-XvzQg@mail.gmail.com>

Hello,

Contributors to the Blazar project are currently mostly from Europe or
Asia. Our weekly IRC meeting at 0900 UTC is a good match for this
group.

To foster more contributions, I would like to schedule another IRC
meeting in the morning for American timezones, probably every two
weeks to start with.
I am thinking of proposing 1600 UTC on either Monday, Tuesday, or
Thursday, which doesn't appear to conflict with closely related
projects (Nova, Placement, Ironic).

If there is anyone who would like to join but cannot make this time,
or has a preference on which day, please let me know.
I will wait for a few days before requesting a meeting slot.

Thanks,
Pierre


From jasonanderson at uchicago.edu  Tue Apr  9 15:57:33 2019
From: jasonanderson at uchicago.edu (Jason Anderson)
Date: Tue, 9 Apr 2019 15:57:33 +0000
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
In-Reply-To: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
Message-ID: <BYAPR11MB3175254D461CDAC35BCEC07ECA2D0@BYAPR11MB3175.namprd11.prod.outlook.com>

Hi Chris,

I wanted to chime in as somebody who operates an environment where users make advanced reservations for bare metal nodes (we have ~500 in total) via Blazar, which are provisioned by Ironic. The way this used to work (pre-Stein) was that Blazar would create host aggregates in Nova associated with a reservation ID, and then a special Blazar scheduler filter in Nova would narrow the list of hosts to only the ones tied to a reservation ID (specified as a scheduler hint, I believe.) This worked well enough but ran a bit against the grain of how Nova was designed and we often experience issues with large launches due to Nova's design, whereby one design assumption is that there is significant headroom available, and thus retries are a sane and practical mechanism to step around provision failures. In our use-case, trying to provision 50 nodes against an aggregate with 50 hosts results in many provisioning errors because Nova isn't doing inventory management and will try to launch 2 bare metal instances on one host. Correct me if I'm wrong, but I think the Placement API addresses this better.

Anyways, there was a lot of work[1] done in Stein to change the approach for one aspect of Blazar reservations: instance reservations (VMs). With the new approach, which uses the Placement API, a custom resource class is created to represent the reservation. I believe it is the intent of the Blazar core team to implement this for host reservations, whereby a user reserves an entire compute host; this is particularly relevant for Ironic.

Advanced reservations are a thorny problem especially when you are dealing with more complex use-cases. To be honest the division of responsibility between Blazar, Nova, and Placement is still not clear to me. So, more conversation between these working groups, which you are trying to facilitate, feels like a good idea.

I'm a bit of an OpenStack newbie still, so I'm still working on wrapping my head around all the pieces and how they ideally fit together, so some of this may be nonsense, and that would be why.

Cheers,
/Jason

Chameleon Cloud
https://www.chameleoncloud.org/


[1]: https://review.openstack.org/#/q/topic:bp/placement-api
________________________________
From: Chris Dent <cdent+os at anticdent.org>
Sent: Tuesday, April 9, 2019 06:56
To: OpenStack-discuss at lists.openstack.org
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations" with ironic+blazar


The etherpad [1] doesn't have any additional notes besides the topic
but the general questions are:

* Do people want to do baremetal reservations with some combination
   of Ironic, Placement and Blazar, now or ever?

* What about Ironic and Placement, sans-Nova?

* If so, what would need to happen to make those things possible?

Based on my observations at the recent OpenInfra Days UK, I'd say
there's definitely an underserved need for this kind of
functionality. From the Placement side of things I would guess
there's little that would need to be done; it's more a matter of
getting other pieces and parts getting data in and out of Placement.

Discuss...

[1] https://etherpad.openstack.org/p/placement-ptg-train

--
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/61fcfca2/attachment.html>

From mriedemos at gmail.com  Tue Apr  9 16:00:39 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 9 Apr 2019 11:00:39 -0500
Subject: [nova] indices on shadow-able fields
In-Reply-To: <20190409153452.GA16521@canonical>
References: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
 <20190409153452.GA16521@canonical>
Message-ID: <99fbc0fa-a0be-907e-722c-4e2f8b0ff27d@gmail.com>

On 4/9/2019 10:34 AM, Sahid Orentino Ferdjaoui wrote:
> I don't think we query shadow tables or it's when we want to purge
> them, so basically that is going to be based on datetime.  I may be
> wrong but adding an index for a datetime field may not be so
> interesting since the index is going to be quite large because of the
> hours, minutes, seconds. That needs to be verified the database may
> provides feature to index datetime using date only. If so I guess you
> raised a good point, if not, indexing such fields is not going to help
> and probably going to consum more resources.

I don't think he's talking about querying the shadow tables but the 
queries made on (soft) deleted records in the normal tables to figure 
out what to populate / move into the shadow tables, e.g.:

https://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/db/sqlalchemy/api.py#L5523

Which says:

- for all soft deleted instances
- find me all of their soft deleted actions
- and for those actions, soft delete all of the events for each action

There was a question in IRC yesterday if the instance_action_events 
table had an index on action_id because of this query:

https://github.com/openstack/nova/blob/d42a007425d9adb691134137e1e0b7dda356df62/nova/db/sqlalchemy/api.py#L5535

And Jay said there was because of the ForeignKeyConstraint on that 
column. There isn't an index on action_id/deleted though, but I'm not 
seeing where that is being used here.

-- 

Thanks,

Matt


From mriedemos at gmail.com  Tue Apr  9 16:06:10 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 9 Apr 2019 11:06:10 -0500
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <alpine.OSX.2.21.1904091151530.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
 <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
 <alpine.OSX.2.21.1904081937400.88564@cdent-a01.vmware.com>
 <b8d4c567-fed1-62b1-969a-3997e691f3d1@gmail.com>
 <alpine.OSX.2.21.1904091151530.93787@cdent-a01.vmware.com>
Message-ID: <987baf90-5a59-15c2-9e7a-f2c3034dd0f5@gmail.com>

On 4/9/2019 6:00 AM, Chris Dent wrote:
> I'll make a story [1], annotate the ptg etherpad, and we can call this
> sub-thread a big win.
> 
> [1] https://storyboard.openstack.org/#!/story/2005411

\o/

-- 

Thanks,

Matt


From sfinucan at redhat.com  Tue Apr  9 16:43:08 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Tue, 09 Apr 2019 17:43:08 +0100
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
Message-ID: <208faae2029b6e67bdd3d8556778960a40d3113b.camel@redhat.com>

On Mon, 2019-04-08 at 19:40 +0200, Dmitry Tantsur wrote:
> On 4/8/19 4:07 PM, Monty Taylor wrote:
> > 
> > On 4/8/19 11:33 AM, Sean McGinnis wrote:
> > > > Perhaps we can find a good pattern for
> > > > having a README with badge types of things that includes actual content from
> > > > the docs?
> > > 
> > > One concern to keep in mind if you start looking down this path is that most
> > > projects use their README by default as their package long-description. That
> > > means that when uploading a package to PyPi, it will use the content of the
> > > README as the description that is shown for that package.
> > > 
> > > The rendering on PyPi, and the validation that they do that will reject the
> > > package upload if it has README syntax errors, is not aware of any Sphinx
> > > extensions we use in our normal docs, so pulling in other documentation into
> > > the README could potentially cause release issues.
> > 
> > Good point. Maybe we should just stop including README content in sphinx docs, 
> > and not do anything additional that's more complex?
> > 
> 
> Honestly, this means copy-paste and that one of the copies will probably get 
> outdated.

You could do a partial include.

  .. include:: ../../README.rst
     :start-line: N

though I, like Sean, would question the wisdom of this since the README
does have a different focus group

Stephen



From dtantsur at redhat.com  Tue Apr  9 16:46:59 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 9 Apr 2019 18:46:59 +0200
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <20190408181337.GA4622@sm-workstation>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
 <20190408181337.GA4622@sm-workstation>
Message-ID: <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>

On 4/8/19 8:13 PM, Sean McGinnis wrote:
>>>>
>>>> The rendering on PyPi, and the validation that they do that will reject the
>>>> package upload if it has README syntax errors, is not aware of any Sphinx
>>>> extensions we use in our normal docs, so pulling in other documentation into
>>>> the README could potentially cause release issues.
>>>
>>> Good point. Maybe we should just stop including README content in sphinx
>>> docs, and not do anything additional that's more complex?
>>>
>>
>> Honestly, this means copy-paste and that one of the copies will probably get
>> outdated.
>>
> 
> What is in the README that is needed in the documentation? For me, those have
> always been entirely different audiences and therefore different content.

I don't think it's any different. Both README and the index page serve as an 
introduction to the project. The same people will land at one of them, depending 
if they come from github/gitea or from docs.o.o

> 
> Maybe it just needs a different perspective for these project from how they've
> used them so far?
> 



From dtantsur at redhat.com  Tue Apr  9 16:48:49 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 9 Apr 2019 18:48:49 +0200
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
In-Reply-To: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
Message-ID: <7c73651f-d878-a784-ae84-79486919bc24@redhat.com>

On 4/9/19 1:56 PM, Chris Dent wrote:
> 
> The etherpad [1] doesn't have any additional notes besides the topic
> but the general questions are:
> 
> * Do people want to do baremetal reservations with some combination
>    of Ironic, Placement and Blazar, now or ever?

There was at least one person at the Berlin Ops meetup who wanted this.

> 
> * What about Ironic and Placement, sans-Nova?

I suspect we'll see more people realizing that Placement != Nova. I think for 
now people still assume it.

> 
> * If so, what would need to happen to make those things possible?
> 
> Based on my observations at the recent OpenInfra Days UK, I'd say
> there's definitely an underserved need for this kind of
> functionality. From the Placement side of things I would guess
> there's little that would need to be done; it's more a matter of
> getting other pieces and parts getting data in and out of Placement.
> 
> Discuss...
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 



From fungi at yuggoth.org  Tue Apr  9 16:51:26 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 9 Apr 2019 16:51:26 +0000
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
 <20190408181337.GA4622@sm-workstation>
 <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
Message-ID: <20190409165126.syfxk5qhqklbulvh@yuggoth.org>

On 2019-04-09 18:46:59 +0200 (+0200), Dmitry Tantsur wrote:
[...]
> I don't think it's any different. Both README and the index page
> serve as an introduction to the project. The same people will land
> at one of them, depending if they come from github/gitea or from
> docs.o.o
[...]

We typically embed them in Python package descriptions too, so it's
a question of whether there's significant overlap between the people
starting from source browsers and PyPI, or starting from published
documentation.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/31296b15/attachment.sig>

From dtantsur at redhat.com  Tue Apr  9 16:51:27 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 9 Apr 2019 18:51:27 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <alpine.OSX.2.11.1904081713160.9091@seed.local>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
Message-ID: <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>

On 4/8/19 6:16 PM, Chris Dent wrote:
> 
>  From the etherpad [1]
> 
> * blazar
> * cinder
> * cyborg
> * ironic
> * neutron
> 
> Who else?
> 
> This is a bit of a catch-many topic. Despite being birthed in Nova,
> Placement is designed to be useful to lots of different services.
> 
> There's already some time defined at the PTG to talk about the
> interaction of Ironic, Blazar, and Placement.
> 
> What are the issues with that?

 From ironic perspective there is no issue, but there is a critical question to 
decide: when Ironic+Placement is used, which of them acts as the final 
authority? If Ironic, then we need to teach Placement to talk to its Allocation 
API when allocating a bare metal node. If Placement, then we need to support 
Allocation API talking to Placement. I suspect the latter is saner, but I'd like 
to hear more opinions.

In both cases we'll need something that syncs nodes from Ironic to Placement 
when there is no Compute to do it.

> 
> What are the issues other services are experiencing with Placement?
> Preventing people from using Placement?
> 
> What services are using Placement and the team doesn't know about
> it?
> 
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 



From cdent+os at anticdent.org  Tue Apr  9 17:08:14 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 18:08:14 +0100 (BST)
Subject: [placement][ptg] Placement Over The Parapet
Message-ID: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>


>From the etherpad [1]:

* What's going on in the rest of the world:
     * where placement can help
     * that can help placement

It's a whole big world out there, people doing all sorts of things
that maybe look a bit like what placement does. What can we learn
from them? What can they learn from us? In what ways can we expand
placement world dominance and improve its ecosystem diversity?

We are often so busy in the depths of OpenStack that it is hard to
remain aware of what is out there. What is?

For example, would there be any purpose in experimenting with
plugging placement into the pluggable scheduling concept in k8s? Is
that totally crazy or intriguing?

I don't know because it's hard to make the time, but it would be
valuable to know.

[1] https://etherpad.openstack.org/p/placement-ptg-train


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From jaypipes at gmail.com  Tue Apr  9 17:20:06 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 9 Apr 2019 13:20:06 -0400
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
Message-ID: <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>

On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
> On 4/8/19 6:16 PM, Chris Dent wrote:
>>
>>  From the etherpad [1]
>>
>> * blazar
>> * cinder
>> * cyborg
>> * ironic
>> * neutron
>>
>> Who else?
>>
>> This is a bit of a catch-many topic. Despite being birthed in Nova,
>> Placement is designed to be useful to lots of different services.
>>
>> There's already some time defined at the PTG to talk about the
>> interaction of Ironic, Blazar, and Placement.
>>
>> What are the issues with that?
> 
>  From ironic perspective there is no issue, but there is a critical 
> question to decide: when Ironic+Placement is used, which of them acts as 
> the final authority? If Ironic, then we need to teach Placement to talk 
> to its Allocation API when allocating a bare metal node. If Placement, 
> then we need to support Allocation API talking to Placement. I suspect 
> the latter is saner, but I'd like to hear more opinions.

Ironic (scheduler?) would request candidates from the placement service 
using the GET /allocation_candidates API. Ironic (scheduler?) would then 
claim the resources on a provider (a baremetal node) by calling the POST 
/allocations API.

> In both cases we'll need something that syncs nodes from Ironic to 
> Placement when there is no Compute to do it.

Yep, this is absolutely correct. My advice: don't bother copying any 
code from the nova-compute resource tracker. It's horrible.

Best,
-jay

>> What are the issues other services are experiencing with Placement?
>> Preventing people from using Placement?
>>
>> What services are using Placement and the team doesn't know about
>> it?
>>
>>
>> [1] https://etherpad.openstack.org/p/placement-ptg-train
>>
> 
> 


From cdent+os at anticdent.org  Tue Apr  9 17:22:46 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 18:22:46 +0100 (BST)
Subject: [placement][nova][ptg] Resourceless trait filters
Message-ID: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>


>From the etherpad [1] (the cross project one):

* This came up with the effort to add a multiattach capability
   filter, at https://review.openstack.org/#/c/645316/1/nova/compute/api.py at 1098

* The problem: we want to be able to request allocation candidates
   filtered by a trait that exists on the root provider; but

     * (a) the root provider may provide no resources (eventually -
       e.g. CPU/mem in NUMA providers, shared disk); and/or

         * (My brain hurts from the concept for a provider that
           provides nothing. Perhaps it provides something we aren't
           remembering to count?)

     * (b) we are using only numbered groups and would have to guess
       where to stuff the `required` - again probably based on
       looking for the VCPU/mem resources, which, as above, may wind
       up not on the root provider.

This, basically, is how/when do we deal with resource providers that
have traits but have no classes of inventory of their own (all of it
is on their descendants). The "My brain hurts" comment above is
mine.

The discussion on the review above (good backgrounder for this
thread) had little to do with the immediate need of the proposed
feature. It was a concern about how things will work in the future.
So there are two salient questions (and presumably plenty of other
sidebars):

* How should it work?
* What is the timeline for when it needs to work?

[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From kennelson11 at gmail.com  Tue Apr  9 17:34:29 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 9 Apr 2019 10:34:29 -0700
Subject: [PTL][SIG][WG] PTG Team Photos
In-Reply-To: <CAJ6yrQin4fz-=M2wnygEiPyZe5J0XRrikd4Ppnyx45JfVyQLcA@mail.gmail.com>
References: <CAJ6yrQin4fz-=M2wnygEiPyZe5J0XRrikd4Ppnyx45JfVyQLcA@mail.gmail.com>
Message-ID: <CAJ6yrQgCCtXBBooYHz_J-QPRx9r=Kop-A8saJWqz9aZzQToPFA@mail.gmail.com>

Wanted to bring this to the top of people's inboxes for those interested.

Totally optional, just wanted to make sure everyone saw this :)

-Kendall (diablo_rojo)

On Thu, Mar 28, 2019 at 5:02 PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello!
>
> If your team is attending the PTG and is interested in having a team photo
> taken, here is the signup[1]! There are slots Thursday and Friday from
> 10:00 AM to 4:30 PM.
>
> The location is TBD but will likely be close to where registration will
> be. I'll send an email out the day before with a reminder of your time slot
> and an exact location.
>
> -Kendall (diablo_rojo)
>
> [1]
> https://docs.google.com/spreadsheets/d/1DgsRHVWW2YLv7ewfX0M21zWJRf4wUfPG4ff2V5XtaMg/edit?usp=sharing
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/0720a217/attachment.html>

From cdent+os at anticdent.org  Tue Apr  9 17:46:23 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 9 Apr 2019 18:46:23 +0100 (BST)
Subject: [placement][nova][ptg] Resource provider - request group mapping
Message-ID: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>



This is about this spec [1] "Resource provider - request group
mapping in allocation candidate" which didn't get approved in Stein
and will need to find its appropriate home (in placement) at some
point. This topic is from the cross project etherpad [2].

The questions associated with this are of two forms:

* How should the data be presented in the allocation candidates
   response?

* How best to capture the pending discussion on a nova spec as is
   moved to becoming a placement spec.

There's quite a lot of useful information on the spec, including
multiple alternatives and reasons why those alternatives are good or
not good.

This is one those API changes where we need to be careful to be
general and within the existing grammar of placement and not simply
evolving reactively to increased complexity in Nova. Obviously
Placement needs to be evolve in response to Nova, but carefully.

What might be useful is for people who feel some ownership for the
various proposed structures to discuss their merits, here. Or go the
other way: If there are some structures you dislike, why?


[1] https://review.openstack.org/#/c/597601/
[2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From ssbarnea at redhat.com  Tue Apr  9 18:06:00 2019
From: ssbarnea at redhat.com (Sorin Sbarnea)
Date: Tue, 9 Apr 2019 19:06:00 +0100
Subject: [tripleo] removal of mixed release config files used in upgrades
Message-ID: <740A72AE-0842-4A27-91D1-B41DE504117C@redhat.com>

Hi!

As part of the release config cleanup/sanitization we have a change for removal of mixed release files 
https://review.openstack.org/#/c/650913/ <https://review.openstack.org/#/c/650913/>

		D	config/release/master-undercloud-ocata-overcloud.yml	
		D	config/release/ocata-undercloud-newton-overcloud.yml		
		D	config/release/queens-undercloud-newton-overcloud.yml			
		D	config/release/tripleo-ci/CentOS-7/master-undercloud-queens-overcloud.yml		
		D	config/release/tripleo-ci/CentOS-7/master-undercloud-rocky-overcloud.yml			
		D	config/release/tripleo-ci/CentOS-7/pike-undercloud-ocata-overcloud.yml				
		D	config/release/tripleo-ci/CentOS-7/queens-undercloud-newton-overcloud.yml		
		D	config/release/tripleo-ci/CentOS-7/queens-undercloud-pike-overcloud.yml			
		D	config/release/tripleo-ci/CentOS-7/rocky-undercloud-queens-overcloud.yml


AFAIK, emit releases script changes removed the need for having these mixed files, so it should be safe to remove them. 


Feel free to add your comments on that change as we would like to avoid breaking a job that may be still needing them -- we tried to identify jobs using them, even on queens and rocky branches but so far we did not find any job still using these files (the upgrade ones are using standard release files and emit releases).

PS. The reason for removal of these files is that we are trying to add some validation of the release config files, and those were found as containing some invalid data.

Thanks
Sorin Sbarnea

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/04f9f489/attachment.html>

From mordred at inaugust.com  Tue Apr  9 19:37:52 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Tue, 9 Apr 2019 19:37:52 +0000
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
Message-ID: <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>



On 4/9/19 12:13 PM, Chris Dent wrote:
> 
>  From etherpad [1]:
> 
> * Some talk in the past of moving https://github.com/cdent/placedock
>    into placement but not sure
> * Another option is [to] trigger container build with each merge
> 
> I wrote this one, so I guess I should expand on it a bit. Basically,
> placedock is a Dockerfile for placement that strives to be small but
> configurable. The same repo also contains instructions (and YAML)
> for using the container in kubernetes, and provides a helm chart
> that uses the generated image.
> 
> Each of those three things is done in a way where many of the
> choices are made for you in favor of being light and simple. In
> things like Kolla, openstack-helm, and other containerizing setups
> some of those choices are left as options, making the build and run
> infrastructure more complex. The result with placedock is a tiny
> service that scales horizontally really well.
> 
> In the past there's been talk of including some of that stuff in the
> placement repo itself as a sort of "hey look, here's one way to do
> it". If we did that, which stuff?
> 
> Another suggestion has been to use a web-hook or similar from zuul
> to trigger an image build (either at docker hub or some other
> registry) post-merge.

We actually have some pretty awesome new container building jobs in Zuul 
now - I'd recommend using them. One of the things they can do is build 
your container image to be used in a gate job, and then when the patch 
for the gate job merges, publish and tag the actual container image used 
in the gate.

This also works with depends-on, so if you have container images that 
consume layers from other container images or are built on top of them, 
all the right things happen.

I'd be happy to help you get that set up in placement.

> Or we can let things go as they are (I manually build new images
> every now and again, which triggers automatic placecat [2] testing).

One of the neat things with depends-on and containers is that it's done 
via registry config, so jobs _consuming_ images don't have to know that 
they're consuming speculative future images. This means you could have 
your placecat job run in the placement container build gate job against 
the speculative container state and things shoud Just Work.

> The reason this comes back up is because I'm somewhat concerned that
> the "seriously, this is really simple" aspect of Placement gets lost
> and there's probably plenty of useful info in this kind of stuff. If
> we make it owned by more than just me, that might help spread the
> learning.
> 
> Thoughts?k
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 
> [2] https://github.com/cdent/placecat
> 
> 


From mriedemos at gmail.com  Tue Apr  9 20:40:35 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 9 Apr 2019 15:40:35 -0500
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
 <e2db1ac2-f3d4-34c9-9f19-9b9eb3cb65f0@gmail.com>
Message-ID: <56ae7ba6-1361-742a-9aff-0ed37955ae4c@gmail.com>

On 4/8/2019 12:05 PM, Matt Riedemann wrote:
> Granted I think devstack-gate modifies ENABLED_SERVICES a bit but you 
> get the idea: we don't need 
> glance/cinder/nova/neutron/etcd/tempest/horizon enabled in devstack for 
> osc-placement functional tests.

I did this and it works:

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

It doesn't save a lot of time (looks like about 5 minutes or so on a 30 
minute job) but it's cheap and easy until the PlacementFixture idea is 
worked on.

-- 

Thanks,

Matt


From cboylan at sapwetik.org  Tue Apr  9 21:07:16 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 09 Apr 2019 17:07:16 -0400
Subject: =?UTF-8?Q?Upgrading_the_lists.(openstack|airshipit|starlingx|zuul-ci).or?=
 =?UTF-8?Q?g_server_Friday_April_12?=
Message-ID: <179ca814-356a-46ee-ae13-a4e320a1dba4@www.fastmail.com>

It is that time of the Ubuntu LTS cycle again and we need to upgrade our mailman mailing list server. We'd like to do that this Friday, April 12. We expect the upgrade to begin at about 17:00UTC and result in a 30-45 minute outage. The reason for the extended outage is that we will be upgrading the server in place to preserve its mail reputation.

Thankfully email is a persistent system and your clients should queue up email sent until the server is back up again and accepting smtp connections. This means the outage shouldn't be very noticeable.

Finally, for list admins, there are new DMARC moderation action settings. We ask that you don't change these settings and instead work with us if you need to address DMARC problems. Our current preference is that we pass email through unmodified so that the signatures still validate.

Thank you all for your patience and feel free to ask us questions,
Clark


From openstack at fried.cc  Tue Apr  9 22:01:31 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 9 Apr 2019 17:01:31 -0500
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190409060229.GD7047@thor.bakeyournoodle.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
Message-ID: <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>

Okay, I'll bite.

>> So we've been working on getting nova-powervm merged into nova to get
>> it under that umbrella. But to do that we have been asked to port
>> functions in piece by piece, which is an arduous process that will
>> take a while yet. So like it or not, I think we're stuck with
>> PowerVMStackers for a while... unless you can convince the nova cores
>> to move nova-powervm under their umbrella (and neutron/ceilometer, but
>> I think that would far less of an issue).
> 
> Being part of the Nova project wont alter how the code migrates from
> openstack/nova-powervm -> openstack/nova but I agree that it should
> happen  (/me looks sideways the current nova PTL ;P)

I would be supportive of the continuation of the effort to move
nova-powervm into nova proper. Now, I happen to know from firsthand
experience that the code is excellent - certainly way prettier than a
lot of the legacy gorp in the libvirt driver. Nevertheless, whether by
switching governance or porting the code into the nova project, it would
be irresponsible of the nova team to assume ownership without thorough
review. I don't think anyone is arguing with that, including Matthew:

> We've been asked to port one function at a time and take it through
> the normal rigorous review process. I understand why, and I'm not
> saying I disagree

That said, the effort needs to be driven by PowerVM. The nova team is
not so abundantly staffed as to be able to go out volunteering for stuff
like this just because it would be nice. PowerVM did not propose any
ports in the stein cycle, and I haven't seen anything for train yet
either. I understand the team is being "restructured"; I assume the
cadence will resume once the dust settles.

In the meantime, while there is still a significant gap between the
in-tree and out-of-tree versions, it definitely makes sense for the
*-powervm projects to have their own core team(s) and PTL.

Beyond that (I may get in trouble for saying this) I care not a whit
whether it's called a project or a SIG or a club or a cabal.

efried
.


From sunku.ranganath at intel.com  Tue Apr  9 22:29:10 2019
From: sunku.ranganath at intel.com (Ranganath, Sunku)
Date: Tue, 9 Apr 2019 22:29:10 +0000
Subject: [telemetry] Telemetry for Train
Message-ID: <E9F2D0F6562EE141BE3F92E1EFFDD921ED8ABEF1@ORSMSX121.amr.corp.intel.com>

Hi Trinh,

I work in cloud telemetry area. Followed through the mailing list, IRC chat and the etherpad.

I see most folks participating are from Asia or EU.
Is there a way that these meetings could be conducted in USA friendly time zone? Possibly have it biweekly in alternating time zones.

Thanks for taking this up.

Thanks,
Sunku Ranganath

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/d19d8edf/attachment.html>

From dangtrinhnt at gmail.com  Tue Apr  9 22:58:32 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 07:58:32 +0900
Subject: [telemetry] Telemetry for Train
In-Reply-To: <E9F2D0F6562EE141BE3F92E1EFFDD921ED8ABEF1@ORSMSX121.amr.corp.intel.com>
References: <E9F2D0F6562EE141BE3F92E1EFFDD921ED8ABEF1@ORSMSX121.amr.corp.intel.com>
Message-ID: <CADJ6S4GB+gvYUaoAshejqy5+CPySUTPorg4KDU09eUAct1FgOA@mail.gmail.com>

Hi Sunku,

Absolutely, I will create a poll about meeting time later today.

Thanks,

On Wed, Apr 10, 2019 at 7:31 AM Ranganath, Sunku <sunku.ranganath at intel.com>
wrote:

> Hi Trinh,
>
>
>
> I work in cloud telemetry area. Followed through the mailing list, IRC
> chat and the etherpad.
>
>
>
> I see most folks participating are from Asia or EU.
>
> Is there a way that these meetings could be conducted in USA friendly time
> zone? Possibly have it biweekly in alternating time zones.
>
>
>
> Thanks for taking this up.
>
>
>
> Thanks,
>
> Sunku Ranganath
>
>
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/00d44e34/attachment.html>

From kennelson11 at gmail.com  Tue Apr  9 23:14:50 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 9 Apr 2019 16:14:50 -0700
Subject: [PTG][Forum] Wikis for Collecting Etherpads
Message-ID: <CAJ6yrQgC1L5gWbA00Fes3o6KX6ZDTFwDsPvD4Wc9cvBjAx-GbQ@mail.gmail.com>

Hello Everyone!

Since we are creeping closer and closer to the Summit + PTG, I'm
circulating these wikis so we can collect all the etherpads being
started/filled.

Forum etherpads[1]
PTG etherpads[2]

-Kendall Nelson (diablo_rojo)

[1]https://wiki.openstack.org/wiki/Forum/Denver2019
[2]https://wiki.openstack.org/wiki/PTG/Train/Etherpads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/ab02bffb/attachment.html>

From sunku.ranganath at intel.com  Tue Apr  9 23:54:51 2019
From: sunku.ranganath at intel.com (Ranganath, Sunku)
Date: Tue, 9 Apr 2019 23:54:51 +0000
Subject: [telemetry] Telemetry for Train
In-Reply-To: <CADJ6S4GB+gvYUaoAshejqy5+CPySUTPorg4KDU09eUAct1FgOA@mail.gmail.com>
References: <E9F2D0F6562EE141BE3F92E1EFFDD921ED8ABEF1@ORSMSX121.amr.corp.intel.com>
 <CADJ6S4GB+gvYUaoAshejqy5+CPySUTPorg4KDU09eUAct1FgOA@mail.gmail.com>
Message-ID: <E9F2D0F6562EE141BE3F92E1EFFDD921ED8AC1C1@ORSMSX121.amr.corp.intel.com>

That’s great, thanks Trinh.


Thanks,
Sunku Ranganath

From: Trinh Nguyen [mailto:dangtrinhnt at gmail.com]
Sent: Tuesday, April 9, 2019 3:59 PM
To: Ranganath, Sunku <sunku.ranganath at intel.com>
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [telemetry] Telemetry for Train

Hi Sunku,

Absolutely, I will create a poll about meeting time later today.

Thanks,

On Wed, Apr 10, 2019 at 7:31 AM Ranganath, Sunku <sunku.ranganath at intel.com<mailto:sunku.ranganath at intel.com>> wrote:
Hi Trinh,

I work in cloud telemetry area. Followed through the mailing list, IRC chat and the etherpad.

I see most folks participating are from Asia or EU.
Is there a way that these meetings could be conducted in USA friendly time zone? Possibly have it biweekly in alternating time zones.

Thanks for taking this up.

Thanks,
Sunku Ranganath



--
Trinh Nguyen
www.edlab.xyz<https://www.edlab.xyz>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/14bca610/attachment-0001.html>

From anlin.kong at gmail.com  Wed Apr 10 00:13:52 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Wed, 10 Apr 2019 12:13:52 +1200
Subject: [trove] Trove CI and review
Message-ID: <CALjNAZ0FmodL955ZU+W3g0XKnG7AOJ+y+xk+5QFNf=O8B_7w6g@mail.gmail.com>

Hi team,

You may have noticed that after we migrating the trove CI job to Ubuntu
Bionic, there are some non-voting jobs keep failing because of some
inconsistency issues or incompatible installations inside the guest agent
image.

I have been working on the fix, but would appreciate if any of you could
offer some help, especially if you care about the database types relating
to those failed jobs.

Additionally, as the team core reviewers, please keep review, or at least
leave some comment on the patches showing that you are interested but don't
have time at the moment. Be aware of that, given the current situation of
review activities in the project, it's acceptable for only one core
reviewer to merge patches, especially those trivial ones such as CI fixes,
documentation, etc.

Thanks!

---
Lingxian Kong
Catalyst Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/d1b8315f/attachment.html>

From tony at bakeyournoodle.com  Wed Apr 10 00:37:04 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 10 Apr 2019 10:37:04 +1000
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
Message-ID: <20190410003703.GG7047@thor.bakeyournoodle.com>

On Thu, Apr 04, 2019 at 11:28:48PM +1300, Lingxian Kong wrote:
> Hi Stable Maintenance Core team,
> 
> I'm current Trove PTL, could you please add myself to trove-stable-maint so
> that I could merge those patches[1][2][3] for stable/stein?

Being PTL doesn't give you automatic rights to the stable branches as the
requirements there are different.  I'm really happy to start mentoring
you on the stable policy and have you review stables patches then after
3months(ish) we can add you to the stable group assuming everything
looks good.

As an added bonus I expect we're mostly in the same TZ ;P

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/80a900b3/attachment.sig>

From kennelson11 at gmail.com  Wed Apr 10 00:38:10 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 9 Apr 2019 17:38:10 -0700
Subject: [First Contact] New Meeting time!
Message-ID: <CAJ6yrQgyCnkBfF77=Bv+PqRjAuKu_TxpdNTVgqxAi_wsK-vSqg@mail.gmail.com>

Hello!

Probably should have sent this sooner, but better late than never?

Our first meeting at the new time is today in about a half hour at 1:00 UTC
in the #openstack-upstream-institute channel.

Hope to see you there!

-Kendall Nelson (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/f42125a3/attachment.html>

From tony at bakeyournoodle.com  Wed Apr 10 00:43:12 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 10 Apr 2019 10:43:12 +1000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
Message-ID: <20190410004311.GH7047@thor.bakeyournoodle.com>

On Tue, Apr 09, 2019 at 05:01:31PM -0500, Eric Fried wrote:
> Okay, I'll bite.

Not bite ... add your sought after opinio ;P

<SNIP>
 
> I would be supportive of the continuation of the effort to move
> nova-powervm into nova proper. Now, I happen to know from firsthand
> experience that the code is excellent - certainly way prettier than a
> lot of the legacy gorp in the libvirt driver. Nevertheless, whether by
> switching governance or porting the code into the nova project, it would
> be irresponsible of the nova team to assume ownership without thorough
> review. I don't think anyone is arguing with that, including Matthew:

Switching governance doesn't require the core-team to change and the
point at which nova-core takes over from nova-powervm-core is when the
code moves into openstack/nova.

<SNIP>

> In the meantime, while there is still a significant gap between the
> in-tree and out-of-tree versions, it definitely makes sense for the
> *-powervm projects to have their own core team(s) and PTL.

core-team sure, but what is it that a PTL does/can do that a SIG chair
can't?

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/3fa6fcab/attachment.sig>

From anlin.kong at gmail.com  Wed Apr 10 00:54:03 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Wed, 10 Apr 2019 12:54:03 +1200
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <20190410003703.GG7047@thor.bakeyournoodle.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
Message-ID: <CALjNAZ22ia4xtTcCqusTEiGyPB_yr0-NQbCfeZm+_3J9oYKw0A@mail.gmail.com>

Hi Tony,

Thanks for the explanation of the stable branch policy, and very good to
know we are in the similar TZ (guess you locate in Aus).

It's not a hard requirement for me to become one of the stable branch core
reviewers, the original demand was to merge Trove stable/stein patches in
order to finish the community runtime requirement for Stein dev cycle.

The patches were all sorted out thanks to Matt, so all good for now.

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Wed, Apr 10, 2019 at 12:37 PM Tony Breeds <tony at bakeyournoodle.com>
wrote:

> On Thu, Apr 04, 2019 at 11:28:48PM +1300, Lingxian Kong wrote:
> > Hi Stable Maintenance Core team,
> >
> > I'm current Trove PTL, could you please add myself to trove-stable-maint
> so
> > that I could merge those patches[1][2][3] for stable/stein?
>
> Being PTL doesn't give you automatic rights to the stable branches as the
> requirements there are different.  I'm really happy to start mentoring
> you on the stable policy and have you review stables patches then after
> 3months(ish) we can add you to the stable group assuming everything
> looks good.
>
> As an added bonus I expect we're mostly in the same TZ ;P
>
> Yours Tony.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/02b08145/attachment.html>

From ruijing.guo at intel.com  Wed Apr 10 01:24:16 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Wed, 10 Apr 2019 01:24:16 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
 <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C5611A@SHSMSX104.ccr.corp.intel.com>

Right. I am planning to add ovsdpdk in networking-ovn like networking-ovn-tempest-dsvm-ovs-master. We can leverage networking-ovsdpdk to build ovsdpdk packages.

The only issue is that qemu without kvm can be crash in vhostuser interface. So I want to have nested virtualization.


-----Original Message-----
From: Sean Mooney [mailto:smooney at redhat.com] 
Sent: Tuesday, April 9, 2019 9:05 PM
To: Clark Boylan <cboylan at sapwetik.org>; openstack-discuss at lists.openstack.org; Guo, Ruijing <ruijing.guo at intel.com>
Subject: Re: [CI] nested virtualization support in OpenStack CI

On Mon, 2019-04-08 at 19:05 -0400, Clark Boylan wrote:
> 
> On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> > Hi, Clark
> > 
> > I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> > virtualization.
> > 
> 
> Can you describe this requirement in a bit more detail? Looking at 
> docs it appears you need to have large pages. Maybe a "picture" will help too:
> 
>   Workload VM
>   (cirros or similar small VM running under
>    emulation or virtualized if nested virt is enabled)
>        |
>       V
>   OpenStack Infra Test Node ("middle VM")
>     This is where ovsdpdk runs right? And this requires large pages?
so ovs-dpdk requires hugepage memeory to be allocated to fucntion but that by its self does not require nested virt. nova on the other hand does require kvm to allow vms to be spawned with hugepages because not enabled partial cpu pinning when hugepages are enabled and qemu does not support per cpu cpu pinning without kvm or the mttcg backend. 

in the special case of ovs-dpdk i have been meaning to test an alternitive way for deploying with ovs-dpdk but to date i have not had time. about 2 years ago i had a memeber of my team extend libvirt to allow the creation of qemu guests with file backed memory. about a year ago redhat extended nova to support that.
it should technically be possibel to run ovs-dpdk with hugepages and the cirros guests with file backed memory to do testing without nested virt.

related to this i finished setting up my own personal ci to do limited ovs-dpdk and numa/nfv testing with nested virt.
https://review.openstack.org/#/c/650573/
tempest-dpdk https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-dpdk/fec9044/
tempest-pinning https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-pinning/1939971/

i am planning to exprement to see if i can run some of those nested virt jobs upstream or via openlab in the furutre.

it shoudl be possible to test with ovn too but i have not tried that pesonally yet the job definitions currently live in https://review.seanmooney.info/plugins/gitiles/test/+/master so perhaps that ill server as a starting point for people wanting to create similar jobs 

the networking-ovs-dpdk devstack plugin compiles and deploys ovs-dpdk form source which also installs but does not configure or start ovn since its part of the ovs repo.

with some tweeks to the networking-ovn plugin it would probably be simple enough to use both plugins to provide the desired versions of ovn,ovs and dpdk.

with all that said the intel nvf ci was created to test ovs-dpdk integration with openstack and also some other nfv features like cpu pinning. https://wiki.openstack.org/w/index.php?title=ThirdPartySystems/Intel_NFV_CI
this ci was also intended to test odl and ovn with ovs dpdk at somepoint in the future
alther that never happend. i woudl suggest reaching out to   <timothy.gresham at intel.com>, <openstack-nfv-ci at intel.com>
to see if it could be extended to do ovn testing in the absence of upstream support.

>        |
>       V
>   Hypervisor (managed by our cloud providers)
> 
> Are we not able to do large pages with emulated workload VMs? Also can 
> we do large pages on the Workload VM if the Infra Test Node isn't 
> configured for them? If the infra test node isn't configured for them do we also need support for large pages from the Hypervisor?
> 
> If we can do large pages with emulated workload VMs and the hypervisor 
> isn't required to support that we should be able to configure large 
> pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of these things won't work.
> In any case specific details on what is required and where it is required will be useful.
> 
> Clark
> 


From li.canwei2 at zte.com.cn  Wed Apr 10 02:18:51 2019
From: li.canwei2 at zte.com.cn (li.canwei2 at zte.com.cn)
Date: Wed, 10 Apr 2019 10:18:51 +0800 (CST)
Subject: =?UTF-8?B?W1dhdGNoZXJdIFRlYW0gbWVldGluZw==?=
Message-ID: <201904101018517396575@zte.com.cn>

Hi ,

We will have the team meeting today at 08:00 UTC on #openstack-meeting-alt IRC channel. 

The meeting agenda at https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda#04.2F10.2F2019




Thanks,


Canwei Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/63b7bb93/attachment.html>

From openstack at fried.cc  Wed Apr 10 02:22:43 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 9 Apr 2019 21:22:43 -0500
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190410004311.GH7047@thor.bakeyournoodle.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <20190410004311.GH7047@thor.bakeyournoodle.com>
Message-ID: <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>


> core-team sure, but what is it that a PTL does/can do that a SIG chair
> can't?

Ack patches in other repositories like release, governance, etc.? But yeah, no reason a SIG chair couldn't also do those things, as long as the vote is recognized the same way.

E


From yamamoto at midokura.com  Wed Apr 10 02:35:41 2019
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Wed, 10 Apr 2019 11:35:41 +0900
Subject: [taas] stein
Message-ID: <CAH=wFzTTLBksv5oaCOAUDWHN3Ge3=unUrC4vb89MgAe-BCWVhw@mail.gmail.com>

hi,

i'll branch and release it sooner or later.
probably in this week, or maybe the next one.

wrt dashboard, i'm not sure if the repo is in a ready-to-release state.
have anyone tested it recently?


From tony at bakeyournoodle.com  Wed Apr 10 06:35:54 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 10 Apr 2019 16:35:54 +1000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <20190410004311.GH7047@thor.bakeyournoodle.com>
 <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>
Message-ID: <20190410063554.GJ7047@thor.bakeyournoodle.com>

On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
 
> > core-team sure, but what is it that a PTL does/can do that a SIG chair
> > can't?
> 
> Ack patches in other repositories like release, governance, etc.? But
> yeah, no reason a SIG chair couldn't also do those things, as long as
> the vote is recognized the same way.

I can't speak to the TC but I think that a SIG chair would basically be
a Liaison in the releases repo and we already know how to handle that.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/d117637c/attachment.sig>

From dangtrinhnt at gmail.com  Wed Apr 10 06:46:29 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 15:46:29 +0900
Subject: [telemetry] Update cores team and team lead recruitment
Message-ID: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>

Hi team,

As you may know, existing core members of Telemetry cannot work on the
projects anymore. So, I would like to set up a new core team for Telemetry
projects in the Train cycle. At the moment, only Lixian Kong and I have the
core privileges over Ceilometer, AODH, and Panko projects. I expect to have
1 more core reviewer to help maintain Telemetry. So *please send us your
proposal if you're interested*.

This is the current structure of Telemetry:

   - AODH: Lixian Kong is the team lead
   - Ceilometer and Panko: myself. This is just tempory until we can find
   someone that has enough experience and willing to take the role.

As discussed in yesterday meeting [1], you may argue that having
experience does not necessarily qualify for code contributions but with the
current situation, I would propose "*the willing to help*" as the number 1
criteria. We will move forward with it and fix processes when we see issues.

Thank all the people that want to keep Telemetry alive.

Yours,

[1] https://etherpad.openstack.org/p/telemetry-train

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/b18872cf/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr 10 06:50:08 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 15:50:08 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <1554302085.4997.19.camel@offenerstapel.de>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
Message-ID: <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>

Hi Jens,

I just see I'm not in the list of these following groups on gerrit:

ceilometer-release
aodh-release
panko-release

Could you please add me to those as well?

Many thanks,

On Wed, Apr 3, 2019 at 11:37 PM Jens Harbott <frickler at offenerstapel.de>
wrote:

> On Wed, 2019-04-03 at 10:52 +0900, Trinh Nguyen wrote:
> > Dear TC,
> >
> > As I am the new PTL for Telemetry in Train [1] and the current cores
> > seem
> > inactive, I would like to ask the TC team to grant myself <
> > dangtrinhnt at gmail.com> and Lingxian Kong <anlin.kong at gmail.com> to
> > the core
> > team of these Telemetry managed projects:
> >
> > + ceilometer
> > + aodh
> > + panko
> >
> > Next step for me is to re-organize core members and meetings.
> >
> > Many thanks,
> >
> > [1] https://review.openstack.org/#/c/645122/
>
> On behalf of the openstack-infra team I have added you to the
> corresponding groups in gerrit, you should be able to handle all
> further adjustments now by yourself. If you need further assistance,
> the easiest way will be to come visit us in the #openstack-infra IRC
> channel on Freenode.
>
> Jens
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/ee733a7d/attachment.html>

From tony at bakeyournoodle.com  Wed Apr 10 06:53:21 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 10 Apr 2019 16:53:21 +1000
Subject: [releaseteam] Changing the meeting time.
In-Reply-To: <7a9a2519-6e2c-31ad-6a7f-7e01d74048d7@openstack.org>
References: <20190408071321.GA7047@thor.bakeyournoodle.com>
 <20190408114100.GD29851@sm-xps>
 <20190409061948.GF7047@thor.bakeyournoodle.com>
 <7a9a2519-6e2c-31ad-6a7f-7e01d74048d7@openstack.org>
Message-ID: <20190410065320.GK7047@thor.bakeyournoodle.com>

On Tue, Apr 09, 2019 at 12:04:12PM +0200, Thierry Carrez wrote:
 
> Obviously nothing works for everyone.
> 
> looking at the Doodle it looks like 1900utc is the time that works best (of
> all the times that work for Tony). It's not superawesome though (5am for
> Tony, 9pm for JP and me).

I can do 5am if y'all can do 2100.
 
> Alternate solution would be to rotate between EU/Au and US/Au times and only
> have Tony as the common denominator.

We could do that but I'd rather get up a little early once a week and
get the whole team together.

I've proposed: https://review.openstack.org/651443 to make this happen
from *next* week

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/2c36555a/attachment-0001.sig>

From dangtrinhnt at gmail.com  Wed Apr 10 07:13:59 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:13:59 +0900
Subject: [telemetry] Vote for team meeting datetime
Message-ID: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>

Hi team,

There're many things we need to discuss for the Train cycle so I propose we
have a bi-weekly meeting and the first one would be on May 2 (next two
weeks will be the vacation of most of the people). Please cast your vote
for an appropriate time:

https://doodle.com/poll/8akawam8yk38q2hh

Yours,

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/c1a0c132/attachment.html>

From aaronzhu1121 at gmail.com  Wed Apr 10 07:14:34 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Wed, 10 Apr 2019 15:14:34 +0800
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
Message-ID: <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>

Hi,

I would like to introduce Shaoman Zhang, He is the team leader of our
company's(ZTE) ceilometer team, He is experienced in performance statistics
and very proficient in ceilometer.
We would happen to support telemetry community and I think Shaoman Zhang
can be the core member of the telemetry projects.
Shaoman also have some commits and reviews in ceilometer[0], although there
are not too much, but it can prove something.

Thanks for your consideration.


On Wed, Apr 10, 2019 at 2:49 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> As you may know, existing core members of Telemetry cannot work on the
> projects anymore. So, I would like to set up a new core team for Telemetry
> projects in the Train cycle. At the moment, only Lixian Kong and I have the
> core privileges over Ceilometer, AODH, and Panko projects. I expect to have
> 1 more core reviewer to help maintain Telemetry. So *please send us your
> proposal if you're interested*.
>
> This is the current structure of Telemetry:
>
>    - AODH: Lixian Kong is the team lead
>    - Ceilometer and Panko: myself. This is just tempory until we can find
>    someone that has enough experience and willing to take the role.
>
> As discussed in yesterday meeting [1], you may argue that having
> experience does not necessarily qualify for code contributions but with the
> current situation, I would propose "*the willing to help*" as the number
> 1 criteria. We will move forward with it and fix processes when we see
> issues.
>
> Thank all the people that want to keep Telemetry alive.
>
> Yours,
>
> [1] https://etherpad.openstack.org/p/telemetry-train
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/d9a99e65/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr 10 07:14:46 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:14:46 +0900
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
Message-ID: <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>

P/S: deadline will be 23:00 April 17, 2019.

On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> There're many things we need to discuss for the Train cycle so I propose
> we have a bi-weekly meeting and the first one would be on May 2 (next two
> weeks will be the vacation of most of the people). Please cast your vote
> for an appropriate time:
>
> https://doodle.com/poll/8akawam8yk38q2hh
>
> Yours,
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/9e3d8614/attachment.html>

From aaronzhu1121 at gmail.com  Wed Apr 10 07:36:03 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Wed, 10 Apr 2019 15:36:03 +0800
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
 <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
Message-ID: <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>

May 2nd is the day after the summit ends, so I think many of the people are
on the road.
Shall we choice another day?

Thanks,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月10日 周三15:17写道：

> P/S: deadline will be 23:00 April 17, 2019.
>
> On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Hi team,
>>
>> There're many things we need to discuss for the Train cycle so I propose
>> we have a bi-weekly meeting and the first one would be on May 2 (next two
>> weeks will be the vacation of most of the people). Please cast your vote
>> for an appropriate time:
>>
>> https://doodle.com/poll/8akawam8yk38q2hh
>>
>> Yours,
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/f8c776f9/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr 10 07:37:23 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:37:23 +0900
Subject: [telemetry][panko][ceilometer][aodh][zuul] Replace telemetry-tox-py37
 with openstack-python37-jobs
Message-ID: <CADJ6S4FOqMcf6mFqGEroNnQVYhJSQk4QTWi-mhZfwKRPcaVuWw@mail.gmail.com>

Hi team,

I would love to replace telemetry-tox-py37 with openstack-python37-jobs
since the only main difference is the nodeset [1]. If you know any reason
to keep it that way, please let me know.

Yours,

[1] https://github.com/openstack/ceilometer/blob/master/.zuul.yaml#L47

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/5e76fc72/attachment-0001.html>

From dangtrinhnt at gmail.com  Wed Apr 10 07:37:52 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:37:52 +0900
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
 <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
 <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>
Message-ID: <CADJ6S4GoRPrAttgX9_ccwo2geBtiqzrCPsG128jadUasvsZvcg@mail.gmail.com>

Oops, totally forgot. Will update the poll. Thanks.

On Wed, Apr 10, 2019 at 4:36 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> May 2nd is the day after the summit ends, so I think many of the people
> are on the road.
> Shall we choice another day?
>
> Thanks,
> Rong Zhu
>
> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月10日 周三15:17写道：
>
>> P/S: deadline will be 23:00 April 17, 2019.
>>
>> On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>> wrote:
>>
>>> Hi team,
>>>
>>> There're many things we need to discuss for the Train cycle so I propose
>>> we have a bi-weekly meeting and the first one would be on May 2 (next two
>>> weeks will be the vacation of most of the people). Please cast your vote
>>> for an appropriate time:
>>>
>>> https://doodle.com/poll/8akawam8yk38q2hh
>>>
>>> Yours,
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/cb8f4c29/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr 10 07:40:10 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:40:10 +0900
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CADJ6S4GoRPrAttgX9_ccwo2geBtiqzrCPsG128jadUasvsZvcg@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
 <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
 <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>
 <CADJ6S4GoRPrAttgX9_ccwo2geBtiqzrCPsG128jadUasvsZvcg@mail.gmail.com>
Message-ID: <CADJ6S4HCKxTyxyLntmN=JKvs781Hx3wED+RKg8Awz21FX+jGDA@mail.gmail.com>

Done. First team bi-weekly meeting will be on May 9 :)

On Wed, Apr 10, 2019 at 4:37 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Oops, totally forgot. Will update the poll. Thanks.
>
> On Wed, Apr 10, 2019 at 4:36 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>
>> May 2nd is the day after the summit ends, so I think many of the people
>> are on the road.
>> Shall we choice another day?
>>
>> Thanks,
>> Rong Zhu
>>
>> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月10日 周三15:17写道：
>>
>>> P/S: deadline will be 23:00 April 17, 2019.
>>>
>>> On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>>> wrote:
>>>
>>>> Hi team,
>>>>
>>>> There're many things we need to discuss for the Train cycle so I
>>>> propose we have a bi-weekly meeting and the first one would be on May 2
>>>> (next two weeks will be the vacation of most of the people). Please cast
>>>> your vote for an appropriate time:
>>>>
>>>> https://doodle.com/poll/8akawam8yk38q2hh
>>>>
>>>> Yours,
>>>>
>>>> --
>>>> *Trinh Nguyen*
>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>
>>>>
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>> --
>> Thanks,
>> Rong Zhu
>>
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/03147356/attachment.html>

From dangtrinhnt at gmail.com  Wed Apr 10 07:45:48 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:45:48 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <668a2359-3641-931c-8c37-cdcaec6c377f@suse.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
 <668a2359-3641-931c-8c37-cdcaec6c377f@suse.com>
Message-ID: <CADJ6S4FUCnLdh7XfmhCpUTSBCJ4Aa3yEdNRvkeD2sfySpZ3WpQ@mail.gmail.com>

Thanks. Got it.

On Wed, Apr 10, 2019 at 4:44 PM Andreas Jaeger <aj at suse.com> wrote:

> On 10/04/2019 08.50, Trinh Nguyen wrote:
> > Hi Jens,
> >
> > I just see I'm not in the list of these following groups on gerrit:
> >
> > ceilometer-release
> > aodh-release
> > panko-release
> >
> > Could you please add me to those as well?
>
> You don't need to be - releases are done via the releases repo.
>
> Those groups are completely unused currently,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>    GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
>        HRB 21284 (AG Nürnberg)
>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/423f8f04/attachment.html>

From aj at suse.com  Wed Apr 10 07:48:47 2019
From: aj at suse.com (Andreas Jaeger)
Date: Wed, 10 Apr 2019 09:48:47 +0200
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
Message-ID: <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>

On 10/04/2019 08.50, Trinh Nguyen wrote:
> Hi Jens,
> 
> I just see I'm not in the list of these following groups on gerrit:
> 
> ceilometer-release
> aodh-release
> panko-release
> 
> Could you please add me to those as well?

You don't need to be - releases are done via the releases repo.

Those groups are completely unused currently,

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


From dangtrinhnt at gmail.com  Wed Apr 10 07:59:38 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 16:59:38 +0900
Subject: [telemetry][gnocchi] Gnocchi alternatives
Message-ID: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>

Hi team,

Yesterday, we talk about Gnocchi and how it is embedded in many parts of
Telemetry these days [1]. Since we many things in Ceilometer have been
replaced by Gnocchi which is an external project, we need the project to be
sustainable at some point. I'm not sure about that since the Gnocchi's
cores change jobs recently (?). So, I continue here the discussion on
whether or not to find alternatives for Gnocchi. People have suggested:

   - Prometheus: we then can get rid of AODH and use Prometheus's Alert
   Manager
   - InfluxDB (part of Monasca): and because many parts of Monasca can do
   what Ceilometer/AODH doing we can possibly replace Telemetry completely (?)

Correct me if I'm missing something.

All ideas are welcomed.

Yours,

[1] https://etherpad.openstack.org/p/telemetry-train
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2019-04-09.log.html#t2019-04-09T06:36:15

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/65915bb0/attachment.html>

From mark at stackhpc.com  Wed Apr 10 08:22:52 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 10 Apr 2019 08:22:52 +0000
Subject: [telemetry][gnocchi] Gnocchi alternatives
In-Reply-To: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>
References: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>
Message-ID: <CAFHSqWqSWU_b6g8bBp1wC5hF38SPaxfP7SKybQhOOQzGq88k8Q@mail.gmail.com>

On Wed, 10 Apr 2019 at 09:00, Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> Yesterday, we talk about Gnocchi and how it is embedded in many parts of
> Telemetry these days [1]. Since we many things in Ceilometer have been
> replaced by Gnocchi which is an external project, we need the project to be
> sustainable at some point. I'm not sure about that since the Gnocchi's
> cores change jobs recently (?). So, I continue here the discussion on
> whether or not to find alternatives for Gnocchi. People have suggested:
>
>    - Prometheus: we then can get rid of AODH and use Prometheus's Alert
>    Manager
>    - InfluxDB (part of Monasca): and because many parts of Monasca can do
>    what Ceilometer/AODH doing we can possibly replace Telemetry completely (?)
>
>
It would be great to see the community focus on one monitoring solution,
and it does seem at this point that monasca has a more stable contributor
base. We've added support in kolla for deploying monasca, which will
hopefully remove a barrier to entry. What would be required for users of
Telemetry to switch to monasca? A compatibility API?


> Correct me if I'm missing something.
>
> All ideas are welcomed.
>
> Yours,
>
> [1] https://etherpad.openstack.org/p/telemetry-train
> [2]
> http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2019-04-09.log.html#t2019-04-09T06:36:15
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/c863634e/attachment.html>

From stig.openstack at telfer.org  Wed Apr 10 08:26:58 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Wed, 10 Apr 2019 09:26:58 +0100
Subject: [scientific-sig] Meeting today, 1100UTC: Ironic and external DCIM,
 Denver preparation
Message-ID: <70692B17-228C-41CF-8DDB-80F114EB93DB@telfer.org>

Hi All -

We have a Scientific SIG IRC meeting today at 1100 UTC in channel #openstack-meeting.  Everyone is welcome.

Today’s agenda is here:

https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_10th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_10th_2019>

The plan is to cover some recent discussions on improving integration of Ironic with external data centre inventory management systems.  Plus, we have some CFPs for ISC 2019 and plenty to plan for the Denver summit besides.

Cheers,
Stig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/0d5f1dad/attachment.html>

From thierry at openstack.org  Wed Apr 10 08:41:31 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 10 Apr 2019 10:41:31 +0200
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190410063554.GJ7047@thor.bakeyournoodle.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <20190410004311.GH7047@thor.bakeyournoodle.com>
 <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>
 <20190410063554.GJ7047@thor.bakeyournoodle.com>
Message-ID: <5cdd3173-5d6e-038d-669e-3d4a353509f0@openstack.org>

Tony Breeds wrote:
> On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
>   
>>> core-team sure, but what is it that a PTL does/can do that a SIG chair
>>> can't?
>>
>> Ack patches in other repositories like release, governance, etc.? But
>> yeah, no reason a SIG chair couldn't also do those things, as long as
>> the vote is recognized the same way.
> 
> I can't speak to the TC but I think that a SIG chair would basically be
> a Liaison in the releases repo and we already know how to handle that.

So.. switching to my release management hat... that actually brings up 
an interesting point, and a good reason to keep PowerVMStackers and 
Winstackers the same.

Project teams basically produce "OpenStack" the software release, while 
SIGs work to make "OpenStack" more relevant for specific cases. While 
SIGs can produce code and can own git repositories, we currently have no 
SIG that owns *deliverables* being made part of the regular OpenStack 
release.

The release team only tracks project teams, and it's simpler if it stays 
that way. It's also a really good delineation as to what is project team 
territory and what is SIG territory.

Both PowerVMStackers or WinStackers currently produce deliverables that 
are released under a cycle-based model and are included in the final 
"OpenStack" release. Switching those teams to become SIGs would have an 
additional consequence: it would remove those deliverables from the 
"OpenStack" release.

So unless those teams actually want that, or the TC decides to do that, 
I don't think we should switch those teams to SIGs.

-- 
Thierry Carrez (ttx)


From anlin.kong at gmail.com  Wed Apr 10 09:06:46 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Wed, 10 Apr 2019 21:06:46 +1200
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
Message-ID: <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>

On Wed, Apr 10, 2019 at 7:19 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Hi,
>
> I would like to introduce Shaoman Zhang, He is the team leader of our
> company's(ZTE) ceilometer team, He is experienced in performance statistics
> and very proficient in ceilometer.
> We would happen to support telemetry community and I think Shaoman Zhang
> can be the core member of the telemetry projects.
> Shaoman also have some commits and reviews in ceilometer[0], although
> there are not too much, but it can prove something.
>
> Thanks for your consideration.
>

It'd be better if he could propose himself.

---
Cheers,
Lingxian Kong
Catalyst Cloud

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/23035c1e/attachment.html>

From li.canwei2 at zte.com.cn  Wed Apr 10 09:18:04 2019
From: li.canwei2 at zte.com.cn (li.canwei2 at zte.com.cn)
Date: Wed, 10 Apr 2019 17:18:04 +0800 (CST)
Subject: =?UTF-8?B?W1dhdGNoZXJdIFByb3Bvc2luZyBjaGVua2VyIGFuZCBEYW50YWxpb24gZm9yIGNvcmU=?=
Message-ID: <201904101718043731546@zte.com.cn>

Hi,


Now Watcher need more active core reviewers, I'd like to propose adding chenker and Dantalion to core team.

They all did a great contribution during the last six months [1].




[1]: https://www.stackalytics.com/report/contribution/watcher-group/90 




Thanks!

Canwei Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/0122f725/attachment-0001.html>

From tony at bakeyournoodle.com  Wed Apr 10 09:21:09 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 10 Apr 2019 19:21:09 +1000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <5cdd3173-5d6e-038d-669e-3d4a353509f0@openstack.org>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <20190410004311.GH7047@thor.bakeyournoodle.com>
 <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>
 <20190410063554.GJ7047@thor.bakeyournoodle.com>
 <5cdd3173-5d6e-038d-669e-3d4a353509f0@openstack.org>
Message-ID: <20190410092108.GL7047@thor.bakeyournoodle.com>

On Wed, Apr 10, 2019 at 10:41:31AM +0200, Thierry Carrez wrote:
> Tony Breeds wrote:
> > On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
> > > > core-team sure, but what is it that a PTL does/can do that a SIG chair
> > > > can't?
> > > 
> > > Ack patches in other repositories like release, governance, etc.? But
> > > yeah, no reason a SIG chair couldn't also do those things, as long as
> > > the vote is recognized the same way.
> > 
> > I can't speak to the TC but I think that a SIG chair would basically be
> > a Liaison in the releases repo and we already know how to handle that.
> 
> So.. switching to my release management hat... that actually brings up an
> interesting point, and a good reason to keep PowerVMStackers and Winstackers
> the same.
> 
> Project teams basically produce "OpenStack" the software release, while SIGs
> work to make "OpenStack" more relevant for specific cases. While SIGs can
> produce code and can own git repositories, we currently have no SIG that
> owns *deliverables* being made part of the regular OpenStack release.
> 
> The release team only tracks project teams, and it's simpler if it stays
> that way. It's also a really good delineation as to what is project team
> territory and what is SIG territory.
> 
> Both PowerVMStackers or WinStackers currently produce deliverables that are
> released under a cycle-based model and are included in the final "OpenStack"
> release. Switching those teams to become SIGs would have an additional
> consequence: it would remove those deliverables from the "OpenStack"
> release.

Only *if* those repos don't get 'adopted' by another project.

In the hypothetical example we're looking at:
openstack/nova-powervm would come under the governance of nova (and
therefore still have all the 'rights' of a project) (same with Telemetry
and Neutron).  The SIG would be there to maintain consistency across the
3 project teams.

I feel like that's a better outcome but it isn't the actual proposal
we started discussing and I kinda de-railed the conversation ... sorry.

> So unless those teams actually want that, or the TC decides to do that, I
> don't think we should switch those teams to SIGs.

So the original proposal which would be a straight transition doesn't
work for this reason which is good to know

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/b7ba774b/attachment.sig>

From balazs.gibizer at ericsson.com  Wed Apr 10 09:24:07 2019
From: balazs.gibizer at ericsson.com (=?utf-8?B?QmFsw6F6cyBHaWJpemVy?=)
Date: Wed, 10 Apr 2019 09:24:07 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
Message-ID: <1554888244.14045.10@smtp.office365.com>



On Tue, Apr 9, 2019 at 7:22 PM, Chris Dent <cdent+os at anticdent.org> 
wrote:
> 
> From the etherpad [1] (the cross project one):
> 
> * This came up with the effort to add a multiattach capability
>   filter, at 
> https://review.openstack.org/#/c/645316/1/nova/compute/api.py at 1098

Just for completness. In the above linked example, requesting the trait 
was the problem. It was requested in a separate numbered request group 
that had no requested resources. Today that is invalid in the placement 
a_c API.

> 
> * The problem: we want to be able to request allocation candidates
>   filtered by a trait that exists on the root provider; but
> 
>     * (a) the root provider may provide no resources (eventually -
>       e.g. CPU/mem in NUMA providers, shared disk); and/or
> 
>         * (My brain hurts from the concept for a provider that
>           provides nothing. Perhaps it provides something we aren't
>           remembering to count?)

Since providers can be nested a provider can be a strucutral element in 
a nested tree without providing resources. This happens in the 
bandwidth case where the agent RPs are there to connect the device RPs 
to neutron agents. It is bit like a resource provider partitioning 
scheme as well as RP ownership definition implemented by nested 
subtrees. To avoid the trait on an empty RP problem in this case all 
the traits are added to the device RPs even if some of the traits 
(CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP. I'm 
currently happy with the resulting RP tree and trait handling in the 
bandwidth model.

> 
>     * (b) we are using only numbered groups and would have to guess
>       where to stuff the `required` - again probably based on
>       looking for the VCPU/mem resources, which, as above, may wind
>       up not on the root provider.
> 
> This, basically, is how/when do we deal with resource providers that
> have traits but have no classes of inventory of their own (all of it
> is on their descendants). The "My brain hurts" comment above is
> mine.

I think the possible solution to move the trait down to the RP that 
provides the resources that has a capability described by the trait 
could be a simple solution that does not require placement changes.

> 
> The discussion on the review above (good backgrounder for this
> thread) had little to do with the immediate need of the proposed
> feature. It was a concern about how things will work in the future.
> So there are two salient questions (and presumably plenty of other
> sidebars):
> 
> * How should it work?
> * What is the timeline for when it needs to work?

I think this work should be driven by a specific need, like the NUMA 
modelling in placement by nova. What is the timeline of NUMA modelling 
in placement?

Cheers,
gibi

> 
> [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
> 
> 
> --
> Chris Dent                       ٩◔̯◔۶           
> https://anticdent.org/
> freenode: cdent                                         tw: @anticdent


From aaronzhu1121 at gmail.com  Wed Apr 10 09:33:40 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Wed, 10 Apr 2019 17:33:40 +0800
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
 <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>
Message-ID: <CAN2nDNsPLSif6hDiSr1AD_Rxn9X7aAQdKKg8Y_+ZEg+ybaOPeQ@mail.gmail.com>

Oh, you are right, Since I have already sent it this time, he will not
repeat send. Next he will reply himself.


Regards,
Rong Zhu



Lingxian Kong <anlin.kong at gmail.com>于2019年4月10日 周三17:07写道：

> On Wed, Apr 10, 2019 at 7:19 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>
>> Hi,
>>
>> I would like to introduce Shaoman Zhang, He is the team leader of our
>> company's(ZTE) ceilometer team, He is experienced in performance statistics
>> and very proficient in ceilometer.
>> We would happen to support telemetry community and I think Shaoman Zhang
>> can be the core member of the telemetry projects.
>> Shaoman also have some commits and reviews in ceilometer[0], although
>> there are not too much, but it can prove something.
>>
>> Thanks for your consideration.
>>
>
> It'd be better if he could propose himself.
>
> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud
>
>> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/fda8afaf/attachment.html>

From balazs.gibizer at ericsson.com  Wed Apr 10 09:36:43 2019
From: balazs.gibizer at ericsson.com (=?utf-8?B?QmFsw6F6cyBHaWJpemVy?=)
Date: Wed, 10 Apr 2019 09:36:43 +0000
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
Message-ID: <1554889000.14045.11@smtp.office365.com>



On Tue, Apr 9, 2019 at 7:46 PM, Chris Dent <cdent+os at anticdent.org> 
wrote:
> 
> 
> This is about this spec [1] "Resource provider - request group
> mapping in allocation candidate" which didn't get approved in Stein
> and will need to find its appropriate home (in placement) at some
> point. This topic is from the cross project etherpad [2].

It is on my TODO list to create a story for it in placement and move 
the spec to the placement repo. I don't know when I will reach this 
item on my list, sorry.

> 
> The questions associated with this are of two forms:
> 
> * How should the data be presented in the allocation candidates
>   response?
> 
> * How best to capture the pending discussion on a nova spec as is
>   moved to becoming a placement spec.

When I move the spec I can add the open questions from the nova spec 
review to the placement spec directly to help continuity. Is that OK?

> 
> There's quite a lot of useful information on the spec, including
> multiple alternatives and reasons why those alternatives are good or
> not good.
> 
> This is one those API changes where we need to be careful to be
> general and within the existing grammar of placement and not simply
> evolving reactively to increased complexity in Nova. Obviously
> Placement needs to be evolve in response to Nova, but carefully.

Pinging Cyborg folks. Does Cyborg needs something similar? If yes then 
we can have at least two users of such API.

> 
> What might be useful is for people who feel some ownership for the
> various proposed structures to discuss their merits, here. Or go the
> other way: If there are some structures you dislike, why?

I can own the first alternative in the spec [3].
> 
> 
> [1] https://review.openstack.org/#/c/597601/
> [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement

[3] 
https://review.openstack.org/#/c/597601/1/specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst at 323

Cheers,
gibi

> 
> 
> --
> Chris Dent                       ٩◔̯◔۶           
> https://anticdent.org/
> freenode: cdent                                         tw: @anticdent


From jaypipes at gmail.com  Wed Apr 10 09:41:29 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 05:41:29 -0400
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.21.1904091445250.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <alpine.OSX.2.21.1904091445250.93787@cdent-a01.vmware.com>
Message-ID: <63b000c3-9237-0c57-65a3-5c028d609875@gmail.com>

On 04/09/2019 10:02 AM, Chris Dent wrote:
> On Tue, 9 Apr 2019, Jay Pipes wrote:
>> So this is referring to resource provider partition (source 
>> partition), not consumer type. For the problem of detecting whether an 
>> instance is in *this* Nova or another Nova deployment that uses the 
>> same placement service, we need a source partition identifier in the 
>> resource_providers table.
> 
> That's not what I was trying to get at with my comment. What I was
> wonder was:
> 
> If there exists a quota for VCPU does it matter how those VCPU are
> being consumed in the entire quota domain? Does it matter if the
> consumption is via nova or some other compute provisioning tool?

Ah, yes, I see now.

I suppose what you're trying to determine is whether there is a viable 
use case for answering the question "given a single 'source partition' 
-- say, "my compute cloud region A" -- show me the usage of VCPU 
resources in my 'nova' compute hosts and my 'non-nova' compute hosts".

I'm just not sure there's a viable use case there.

Best,
-jay


From dtantsur at redhat.com  Wed Apr 10 09:47:56 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 10 Apr 2019 11:47:56 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
Message-ID: <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>

On 4/9/19 7:20 PM, Jay Pipes wrote:
> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>> On 4/8/19 6:16 PM, Chris Dent wrote:
>>>
>>>  From the etherpad [1]
>>>
>>> * blazar
>>> * cinder
>>> * cyborg
>>> * ironic
>>> * neutron
>>>
>>> Who else?
>>>
>>> This is a bit of a catch-many topic. Despite being birthed in Nova,
>>> Placement is designed to be useful to lots of different services.
>>>
>>> There's already some time defined at the PTG to talk about the
>>> interaction of Ironic, Blazar, and Placement.
>>>
>>> What are the issues with that?
>>
>>  From ironic perspective there is no issue, but there is a critical question 
>> to decide: when Ironic+Placement is used, which of them acts as the final 
>> authority? If Ironic, then we need to teach Placement to talk to its 
>> Allocation API when allocating a bare metal node. If Placement, then we need 
>> to support Allocation API talking to Placement. I suspect the latter is saner, 
>> but I'd like to hear more opinions.
> 
> Ironic (scheduler?) would request candidates from the placement service using 
> the GET /allocation_candidates API. Ironic (scheduler?) would then claim the 
> resources on a provider (a baremetal node) by calling the POST /allocations API.

Okay, this matches my expectation.

My concern will be with Blazar and reservations. If reservations happen through 
Placement only, how will ironic know about them? I guess we need to teach Blazar 
to talk to Ironic, which in turn will talk to Placement.

> 
>> In both cases we'll need something that syncs nodes from Ironic to Placement 
>> when there is no Compute to do it.
> 
> Yep, this is absolutely correct. My advice: don't bother copying any code from 
> the nova-compute resource tracker. It's horrible.

Noted :)

> 
> Best,
> -jay
> 
>>> What are the issues other services are experiencing with Placement?
>>> Preventing people from using Placement?
>>>
>>> What services are using Placement and the team doesn't know about
>>> it?
>>>
>>>
>>> [1] https://etherpad.openstack.org/p/placement-ptg-train
>>>
>>
>>
> 



From swamireddy at gmail.com  Wed Apr 10 10:05:06 2019
From: swamireddy at gmail.com (M Ranga Swami Reddy)
Date: Wed, 10 Apr 2019 15:35:06 +0530
Subject: Test
Message-ID: <CANA9Uk7dPoiWzfLUKM3y0FBFHAnrhXQW001+14ag1ZHrTb_Nhw@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/d1212341/attachment.html>

From jaypipes at gmail.com  Wed Apr 10 10:05:37 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 06:05:37 -0400
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.21.1904091502510.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <alpine.OSX.2.21.1904091502510.93787@cdent-a01.vmware.com>
Message-ID: <e1cd0776-77cf-14a2-81dd-b6c750ffa553@gmail.com>

On 04/09/2019 10:14 AM, Chris Dent wrote:
> On Tue, 9 Apr 2019, Jay Pipes wrote:
>> The problem with this implementation is that resource providers can 
>> belong to zero or multiple aggregates, of course. And a "shard" or 
>> "source partition" is clearly something that a provider only belongs 
>> to *one of* and *must* belong to only one.
> 
> I agree that aggregates may be a bad choice because of the option to
> belong to zero but we could control that above the db level if we
> cared to. 

We currently control this in Nova above the DB level, as I mentioned in 
my original reply about how hacky aggregate -> availability zone 
handling is.

I'd prefer less hacky approaches in placement, if possible.

> Not making a vote for aggregates here, just pointing out that we have
> the power to do what we want, and aggregates provide an existing
> grouping model. And these are groups.

I don't view these as groups, though. Groups are many to many 
relationships. A thing can be in many groups. A group has many things.

But in the case of a shard or partition, it's really a one to one thing 
in my opinion.

> Do we want to enforce that any resource provider only belongs to one
> partition? If so, why? By calling them shards or partitions, then
> sure, that cardinality makes sense, but what happens when some
> bright bulb decides there is a monster inter-galactic storage
> service that can serve multiple clouds, transparently [1]? Do we
> want the data model to prevent that
I'd prefer to have the data model express the explicit nature of a 1:1 
relationship. It's simpler and easier to reason about.

There's a reason we said that for hierarchical resource providers, there 
can be only one parent provider, much to Mr. Mooney's dismay.

Sure, we can try to bend our minds to support quantum entanglement and 
an alternative universe where there is no spoon. But if we do that, 
we'll end up with... well, with no spoon.

And I like spoons. They are useful scoopers of both liquid and 
semi-solid materials. Attempting to enjoy a nice soup with a fork tends 
to spoil the experience.

Best,
-jay

> [1] by way of quantum entanglement, you see...



From cdent+os at anticdent.org  Wed Apr 10 10:11:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 11:11:07 +0100 (BST)
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
Message-ID: <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>

On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
> On 4/9/19 7:20 PM, Jay Pipes wrote:
>> Ironic (scheduler?) would request candidates from the placement service 
>> using the GET /allocation_candidates API. Ironic (scheduler?) would then 
>> claim the resources on a provider (a baremetal node) by calling the POST 
>> /allocations API.
>
> Okay, this matches my expectation.

One of the reasons I wrote my etcd-compute [1] compute thing was to
demo how simple the inventory writing, candidate selection
(scheduling), allocation writing can be if a) assume that placement
is where the truth lives, b) represent everything that matters in
the scheduling decisions in placement, c) only care about stuff that
really matters (so (b) can be straightforward).

It does what Jay describes in his paragraph above and that is
pretty much the basic model for using placement.

(Except, to be pedantic, for a single consumer the PUT
/allocations/{consumer_uuid} API would be the normal one for
"claiming". POST is for manipulating multiple allocations in one
(atomic) request.)j

> My concern will be with Blazar and reservations. If reservations happen 
> through Placement only, how will ironic know about them? I guess we need to 
> teach Blazar to talk to Ironic, which in turn will talk to Placement.

One option would be that Blazar talks to placement, making some
stuff resources unavailable. Ironic doesn't specifically need to
know that they are unavailable, it is would rather be the case they
are not present in scheduling results.

[1] https://github.com/cdent/etcd-compute

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From jaypipes at gmail.com  Wed Apr 10 10:14:06 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 06:14:06 -0400
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
Message-ID: <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>

On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
> On 4/9/19 7:20 PM, Jay Pipes wrote:
>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>>>  From ironic perspective there is no issue, but there is a critical 
>>> question to decide: when Ironic+Placement is used, which of them acts 
>>> as the final authority? If Ironic, then we need to teach Placement to 
>>> talk to its Allocation API when allocating a bare metal node. If 
>>> Placement, then we need to support Allocation API talking to 
>>> Placement. I suspect the latter is saner, but I'd like to hear more 
>>> opinions.
>>
>> Ironic (scheduler?) would request candidates from the placement 
>> service using the GET /allocation_candidates API. Ironic (scheduler?) 
>> would then claim the resources on a provider (a baremetal node) by 
>> calling the POST /allocations API.
> 
> Okay, this matches my expectation.
> 
> My concern will be with Blazar and reservations. If reservations happen 
> through Placement only, how will ironic know about them? I guess we need 
> to teach Blazar to talk to Ironic, which in turn will talk to Placement.

Hmm. So, here's the problem: placement has no concept of time. [1]

Placement only knows about one period of time: now. Placement doesn't 
have any concept of an allocation or an inventory existing at some point 
in the future or in the past.

Therefore, Blazar must unfortunately keep all of the temporal state 
about reservations in its own data store. So, Ironic would actually have 
to talk to Blazar to create a reservation of some amount of resources 
and Blazar will need to call Placement to manage the state of resource 
inventory and allocations over time; as reservations are activated, 
Blazar will either create or swap allocation records in Placement to 
consume the Ironic resources for a tenant that made the reservation.

Best,
-jay

[1] this was a mistake for which I take full responsibility.


From cdent+os at anticdent.org  Wed Apr 10 10:23:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 11:23:07 +0100 (BST)
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
Message-ID: <alpine.OSX.2.21.1904101114310.10085@cdent-a01.vmware.com>

On Tue, 9 Apr 2019, Monty Taylor wrote:

> I'd be happy to help you get that set up in placement.

Thanks, if we decide to follow through on this that would be
awesome. And thanks for all the info which I will integrate back
into the summaries when the time comes.

Part of the question surrounding this is whether we want to take on
the responsibility of "owning" container concepts within placement
itself. Unless we wrap it in a bunch of "example" and "there's more
than one way to do it" warnings people have demonstrated a tendency
to take things as gospel (look at the damage some of the ways
devstack managed web services spread around the OpenStack world).

While I'm fairly confident that my little container works well for
me, I'm hoping we can reach some consensus on whether we, the
placement team, want to own such a thing.

I'm tending towards thinking that we should because the potential
educational value outweighs the vague concerns I'm not really able
to enumerate (but the last paragraph below captures, a bit).

As a mostly greenfield development, Placement doesn't have a lot of
legacy weight so it tends to be able to demo:

* good microversion handling
* good http dispatch
* good WSGI app hosting techniques
* minimal config
* good mini-container hygiene

and probably some other things too. There are probably some useful
techniques to pick up there.

On the other hand, there was probably a time when Nova thought it
has some good techniques to pick up and then everyone copied them
and now there is regret. So it might be better that people look for
examples outside of OpenStack, not within, where things tend to move
slowly.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Wed Apr 10 10:31:06 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 11:31:06 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <e1cd0776-77cf-14a2-81dd-b6c750ffa553@gmail.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <alpine.OSX.2.21.1904091502510.93787@cdent-a01.vmware.com>
 <e1cd0776-77cf-14a2-81dd-b6c750ffa553@gmail.com>
Message-ID: <alpine.OSX.2.21.1904101125270.10085@cdent-a01.vmware.com>

On Wed, 10 Apr 2019, Jay Pipes wrote:

> I'd prefer to have the data model express the explicit nature of a 1:1 
> relationship. It's simpler and easier to reason about.

FTR: I'm perfectly fine with that and in fact pretty much prefer it.
I agree it keeps things simpler and saner. I bring it up at this
stage of the conversation because this is the point where we want to
get all the ideas and options on the table and draw out people who
might have unique and illuminating perspectives.

Doing these conversations in email in advance of the PTG gives us
some license to cough out all the wild hairs so they don't tangle us
up later. If we discover a golden fleece, that's cool too.

/me tangles his metaphors

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From sfinucan at redhat.com  Wed Apr 10 10:45:39 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Wed, 10 Apr 2019 11:45:39 +0100
Subject: [all][docs] season of docs
In-Reply-To: <LO2P123MB2223E78261CF1BDB3A6DABF48C420@LO2P123MB2223.GBRP123.PROD.OUTLOOK.COM>
References: <CAEs876gB6gB1O-RiK84jAydwR84cjcVRLd97edNNXt=nQXYYQA@mail.gmail.com>
 <CAJ6yrQgKBtb_nQKF+qh8Jwu4X6dAXi6pgmJpCjbtwu9bku46qw@mail.gmail.com>
 <faff00744292f54426e85b187d6c7a4975568910.camel@redhat.com>
 <CAJ6yrQhGOxF7umhP1Z4Hur0777ChB2dLXApRLVikCTXy76SRpw@mail.gmail.com>
 <LO2P123MB2223E78261CF1BDB3A6DABF48C420@LO2P123MB2223.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <671844ee600c7a5d99359b18c9c840c782e4cc67.camel@redhat.com>

[Top posting]
Petr (Kovar) has kindly put me in touch with folks within Red Hat who
have worked on this in the past for other projects. They're able to
help with getting the submission out the door and have pointed to
Gnome's submission as a good example of what we need to do here:
https://wiki.gnome.org/Outreach/SeasonofDocs
Based of that, I guess the next steps are figuring out what projects
need the most help and putting together a list of ideas that we can
submit.
I can only really speak for nova and oslo. For nova, I'd like to see us
better align with the documentation style used in Django, which is
described in the below article:
https://jacobian.org/2009/nov/10/what-to-write/
The documentation structure we use doesn't allow us to map to this
directly but I do think there are some easy gains to be made:
 * More clearly delineate between admin-facing (/admin) and user-facing 
(/user) docs
 * Expand the how-to docs we have to better explain common user and
admin operations, such as rebooting instances, rebuilding, attaching
interfaces, etc.

On top of that, there are some general cleanup things that need to
happen and just haven't.
 * [Technical] Audit our reference guide, which explains concepts like
cells v2, to see if these make sense to someone who's not in the
trenches
 * Generally examine the structure of the docs to see how easy it is to
find stuff (fwiw, I struggle to find things without Google so this is
probably a bad sign)

For oslo, I think our issue is less about documentation and more about
marketing (very few people outside of OpenStack know that reno is a
thing, for example, or that oslo.config exists and is as powerful as it
is) so there's nothing I'd really submit here. I'm willing to debate
that though, if someone disagrees.
Does anyone else have anything they'd like to get help with? If so,
please let me know (here or on IRC) and we can feed that into the
process.
Stephen
On Thu, 2019-03-21 at 10:07 +0000, Alexandra Settle wrote:
> 
> 
> On 21/03/2019 01:58, Kendall Nelson wrote:
> 
> 
> > We've only been selected on time previously I think? The
> > application process was pretty involved from what I recall. I will
> > dig around and see if I can find anything from our last application
> > and send it over if I discover anything. 
> > 
> > 
> > 
> > Happy to try to help with the application too if you want an extra
> > set of eyes/hands.
> > 
> > 
> > 
> 
> Ditto. I love these applications and Outreachy was really successful!
> (well, sorta, long story)
> 
> 
> > 
> > 
> > 
> > 
> > -Kendall (diablo_rojo)
> > 
> > 
> > 
> > 
> > 
> > 
> > On Wed, Mar 20, 2019 at 2:51 AM Stephen Finucane <
> > sfinucan at redhat.com> wrote:
> > 
> > 
> > > On Tue, 2019-03-12 at 14:42 -0700, Kendall Nelson wrote:
> > > > I think it would be a great idea if we can find someone to be
> > > > our coordinator. In the past when I've helped out with the
> > > > Google Summer of Code, the application has been a fair bit of
> > > > work, but maybe this one is different? I haven't looked yet.
> > > >  I can try to help support whoever wants to coordinate this,
> > > > but I don't have time to be the primary point of contact. 
> > > > 
> > > > 
> > > > 
> > > > -Kendall (diablo_rojo)
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > This sounds like something the docs team (and me specifically)
> > > could take point on. I'm happy to look into what's required and
> > > reach out to people as necessary. Is there anything documented
> > > regarding the previous Summer of Code applications though?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Stephen
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > On Mon, Mar 11, 2019 at 9:30 AM Mohammed Naser <
> > > > mnaser at vexxhost.com> wrote:
> > > > 
> > > > 
> > > > > Hi there:
> > > > > 
> > > > > 
> > > > > 
> > > > > It seems like Google has come up with a new somewhat-GSoC-
> > > > > like idea
> > > > > 
> > > > > but focused on documentation.  I think it could be a good
> > > > > opportunity
> > > > > 
> > > > > for the documentation team (or any specific team actually,
> > > > > coordinated
> > > > > 
> > > > > with docs) to be part of this.
> > > > > 
> > > > > 
> > > > > 
> > > > > https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html
> > > > > 
> > > > > 
> > > > > 
> > > > > I'm not sure if the team has the amount of resources, but it
> > > > > seems
> > > > > 
> > > > > they should be able to apply to this.  Does this seem like
> > > > > something
> > > > > 
> > > > > that might help the team more (or perhaps a specific project,
> > > > > 
> > > > > coordinating with the docs team) to apply for this?
> > > > > 
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Mohammed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/e3ff667c/attachment.html>

From jaypipes at gmail.com  Wed Apr 10 10:54:44 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 06:54:44 -0400
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
Message-ID: <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>

On 04/08/2019 01:05 PM, Eric Fried wrote:
> On 4/8/19 10:43 AM, Chris Dent wrote:
>>      * How (and should) we further split and shrink
>> objects/resource_provider.py
> 
> To be specific here:
> 
> objects/resource_provider.py is currently ~2KLOC. That's not *horrible*
> (see below), and if it really didn't lend itself to being further
> subdivided, I would say we shouldn't force it just for the sake of
> making that number smaller.
> 
> However, IMO, this file logically deals with several things:
> 
> * Resource provider inventory/capacity/usage
> * Resource provider membership in aggregates
> * Traits on resource providers
> * Creating, updating, and deleting resource providers
> * Finding resource providers in various ways
> 
> If you look at the structure of the file (in its current order - see
> below) these groupings are pretty clear.
> 
> Note the presence of "resource provider" in each bullet above. We
> already have separate modules for dealing with e.g. CRUD of traits in
> their own right. Though the mapping isn't 1:1 with the above list.
> 
> So we have the following options, I think:
> 
> (1) Do nothing. Leave objects/resource_provider.py as is.
> (2) Move X-related stuff into the base X.py module, so like move things
> related to "Traits on resource providers" into objects/trait.py. This
> level of shuffle would probably entail things like creating a new module
> for aggregate.py
> (3) Split the above into separate modules while preserving their
> resource_provider-ness. From the perspective of code consuming the
> modules, this would look like:
> 
> from placement.objects import resource_provider as rp_crud
> from placement.objects.resource_provider import trait as rp_trait
> from placement.objects.resource_provider import search as rp_search
> from placement.objects import trait
> ...
> # Do CRUD-y stuff with resource providers
> rp = rp_crud.ResourceProvider(...)
> rp.create()
> # Do trait stuff
> t = trait.Trait(...)
> t.create()
> # Do trait-y stuff with resource providers
> rp_trait.add_traits_to_provider(rp, [t])
> # Do search-y stuff with resource providers
> rp_search.get_all_by_filters(...)
> 
> To me, this is nice and intuitive.

Meh :) I actually think option 1 (Do nothing) is best here. We went 
through a bunch of churn for the (excellent) refactoring for OVO-ectomy 
and splitting the resource_provider.py file out into the other related 
object/*.py files.

I don't really see a huge value in further splitting the resource 
provider functions out into separate modules with a 
/placement/objects/resource_provider/ module. I actually think this 
version of the above code is more readable:

from placement.objects import resource_provider
from placement.objects import trait
...
# Do CRUD-y stuff with resource providers
rp = resource_provider.ResourceProvider(...)
rp.create()
# Do trait stuff
t = trait.Trait(...)
t.create()
# Do trait-y stuff with resource providers
rp.add_traits([t])
# Do search-y stuff with resource providers
resource_provider.get_all_by_filters(...)

Note that the "add_traits()" is a method on the ResourceProvider object 
in the above. I think this is more readable for create/update/delete 
operations. For read operations, I prefer a consistently-named set of 
get_by_XXX and get_all_by_XXX methods in module-level scope as opposed 
to @classmethods on an object.
>> * Is it worth reordering methods to some kind of arbitrary ordering?
> 
> My preference on this: keep related methods/classes/etc. near each other
> in the file.
> 
> Pros:
> * Intuitive.
> * Increases the probability that, when I'm looking at a method that
> calls another method, both methods will fit on my screen at the same
> time. (Workaround: multiple editor windows to the same file.)
> 
> Cons:
> * Sometimes there's no sensible grouping, which makes this hard to
> define and therefore hard to follow (and hard to enforce, if that's a
> thing we want to do).
> * Ability to know exactly where to look to find something. (Workaround:
> Use a real IDE, where you can do a project-wide search for a symbol,
> hotkey from a symbol's use to its definition, etc. Also you can choose
> to view a module's skeleton in its real order *or* alphabetically.)

My preference is to have related methods grouped together as well, but I 
don't consider this a priority work item.

>> * If a method or module is "long" (by some definition) does that
>>    make it bad?
> 
> Not to the point where we should do something like implement sonar.
> Having had experience with that, it just ain't worth the hassle.
> However, there is such a thing as too long. Certain nova libvirt modules
> come to mind. For those of us who do choose to use real IDEs, these can
> take a long time to process (in-band syntax checking, symbol correlation
> highlighting, git blame, etc.). I'm going to go out on a limb and say we
> should strive really hard never to have a module in the 5-digit LOCs.
> And it would be really nice to stay under 2KLOC, but only if it doesn't
> feel forced.

Agreed.

>> * Where is the balance between backport hurting churn and keeping
>>    the mix fresh?
> 
> I'm not sure "fresh" is the heaviest hitter on the plus side. Making the
> code organized and crisp and usable (from a developer standpoint) and
> maintainable is the main thing to me.
> 
> On the minus side, in addition to backport pain, there's the difficulty
> tracking down the change that did a thing. Run git blame today and it
> looks like Chris wrote virtually the whole thing in a small number of
> massive monolithic chunks. You have to use bisect or similar to track
> something down. To me, this is the biggest pain point.
> 
> So I think we should strive to get to a point where the code structure
> is "good enough" and then stop doing huge refactors. That way, as we
> move forward, changes will accumulate on that base and things will look
> more "normal" history-wise.

Agreed.

>> * Should there be a more cleanly defined boundary between the
>>    methods that marshal data (the top-level methods in objects/*.py)
>>    and those that talk to the persistence layer (also in
>>    objects/*.py)?
>>
>>      * Do we need to define (better) or document the layers/boundaries
>>        in the system?
> 
> Sure, if we can find a fairly clean split. I don't have this enough in
> my head to volunteer to do it, but I'll review it if someone else does :)

See above. My preference is to have create/update/delete operations be 
normal object methods and get operations be module-level functions with 
consistent names. No @classmethods or @staticmethods would be my preference.

Best,
-jay


From dtantsur at redhat.com  Wed Apr 10 11:03:43 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 10 Apr 2019 13:03:43 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
Message-ID: <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>

On 4/10/19 12:11 PM, Chris Dent wrote:
> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
>> On 4/9/19 7:20 PM, Jay Pipes wrote:
>>> Ironic (scheduler?) would request candidates from the placement service using 
>>> the GET /allocation_candidates API. Ironic (scheduler?) would then claim the 
>>> resources on a provider (a baremetal node) by calling the POST /allocations API.
>>
>> Okay, this matches my expectation.
> 
> One of the reasons I wrote my etcd-compute [1] compute thing was to
> demo how simple the inventory writing, candidate selection
> (scheduling), allocation writing can be if a) assume that placement
> is where the truth lives, b) represent everything that matters in
> the scheduling decisions in placement, c) only care about stuff that
> really matters (so (b) can be straightforward).
> 
> It does what Jay describes in his paragraph above and that is
> pretty much the basic model for using placement.
> 
> (Except, to be pedantic, for a single consumer the PUT
> /allocations/{consumer_uuid} API would be the normal one for
> "claiming". POST is for manipulating multiple allocations in one
> (atomic) request.)j
> 
>> My concern will be with Blazar and reservations. If reservations happen 
>> through Placement only, how will ironic know about them? I guess we need to 
>> teach Blazar to talk to Ironic, which in turn will talk to Placement.
> 
> One option would be that Blazar talks to placement, making some
> stuff resources unavailable. Ironic doesn't specifically need to
> know that they are unavailable, it is would rather be the case they
> are not present in scheduling results.

We would rather have ironic aware that some nodes are reserved for internal 
bookkeeping.

> 
> [1] https://github.com/cdent/etcd-compute
> 



From anlin.kong at gmail.com  Wed Apr 10 11:05:46 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Wed, 10 Apr 2019 23:05:46 +1200
Subject: [telemetry][gnocchi] Gnocchi alternatives
In-Reply-To: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>
References: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>
Message-ID: <CALjNAZ1++e8WoyAo77rNUgpe9ctYmHUfjfbi7hut7PbaaapJyg@mail.gmail.com>

Personally, I can see there are several criteria for the replacement
project(s) of Ceilometer/Aodh:

- Provide consistent API experience with other openstack services.
- Integrate with Keystone
- Have ALL the metrics of core services that Ceilometer is collecting
nowadays.
- Alarm API
- Including all the feature-parity functionalities of current
evaluators/notifiers Aodh already provides.
- Last but not least, easy to integrate with other OpenStack services

Only the projects that have all the answers "YES" is to be considered as an
option.

Gnocchi is another story, it provides storage(by leveraging storage
backends) function, aggregation function and user-facing API, there is no
hard dependency between Gnocchi and Ceilometer, it could be replaced only
if the alternative is what we expected.

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Wed, Apr 10, 2019 at 8:04 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> Yesterday, we talk about Gnocchi and how it is embedded in many parts of
> Telemetry these days [1]. Since we many things in Ceilometer have been
> replaced by Gnocchi which is an external project, we need the project to be
> sustainable at some point. I'm not sure about that since the Gnocchi's
> cores change jobs recently (?). So, I continue here the discussion on
> whether or not to find alternatives for Gnocchi. People have suggested:
>
>    - Prometheus: we then can get rid of AODH and use Prometheus's Alert
>    Manager
>    - InfluxDB (part of Monasca): and because many parts of Monasca can do
>    what Ceilometer/AODH doing we can possibly replace Telemetry completely (?)
>
> Correct me if I'm missing something.
>
> All ideas are welcomed.
>
> Yours,
>
> [1] https://etherpad.openstack.org/p/telemetry-train
> [2]
> http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2019-04-09.log.html#t2019-04-09T06:36:15
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/9f709ea9/attachment.html>

From cdent+os at anticdent.org  Wed Apr 10 11:08:31 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 12:08:31 +0100 (BST)
Subject: [placement][nova][ptg] Use in_tree getting allocation candidates
Message-ID: <alpine.OSX.2.21.1904101200170.10085@cdent-a01.vmware.com>


>From the (cross-project) etherpad [1]:

-=-=-
* Spec: https://review.openstack.org/#/c/646029/

* Branch: https://review.openstack.org/#/q/topic:bp/use-placement-in-tree

* -> This spec and branch proposes to translate [user specified
   host/node] into [compute node uuid] internally in nova before asking
   to placement

* Discussion point: What to do when an operator specifies only
   "forced_host" in VM creation with --availability-zone and multiple
   nodes are found in the DB

     1. We use this optimization only when 1 node is found in the nova side DB. Skip this optimization otherwise.

     2. We use this optimization whenever possible passing every found compute node uuids.

     3. We use this optimization when smaller amount than N node are found in the nova side DB. Skip this optimization otherwise.
         3-1. appropriate N value (or the "default" N value) in terms of <REST query string length> and <DB query with IN clause>

     4. Others?

* Note: Option 2 and 3 needs a change in placement side REST API to accept multiple uuids in the `in_tree` query

     * Spec: https://review.openstack.org/#/c/651113/
-=-=-

>From a placement perspective the main discussion point here is the
placement side spec at [2] which is relatively straightforward and
low impact: making an existing query parameter more expressive
while keeping existing response format. There's some questions (on
the spec) about the details of the syntax. There's also a concern
about query string length but that's discussed above.


[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
[2] https://review.openstack.org/#/c/651113/

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dtantsur at redhat.com  Wed Apr 10 11:11:04 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 10 Apr 2019 13:11:04 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
Message-ID: <c0cea172-de48-71c6-83e4-e28486e484f2@redhat.com>

On 4/10/19 12:14 PM, Jay Pipes wrote:
> On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
>> On 4/9/19 7:20 PM, Jay Pipes wrote:
>>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>>>>  From ironic perspective there is no issue, but there is a critical question 
>>>> to decide: when Ironic+Placement is used, which of them acts as the final 
>>>> authority? If Ironic, then we need to teach Placement to talk to its 
>>>> Allocation API when allocating a bare metal node. If Placement, then we need 
>>>> to support Allocation API talking to Placement. I suspect the latter is 
>>>> saner, but I'd like to hear more opinions.
>>>
>>> Ironic (scheduler?) would request candidates from the placement service using 
>>> the GET /allocation_candidates API. Ironic (scheduler?) would then claim the 
>>> resources on a provider (a baremetal node) by calling the POST /allocations API.
>>
>> Okay, this matches my expectation.
>>
>> My concern will be with Blazar and reservations. If reservations happen 
>> through Placement only, how will ironic know about them? I guess we need to 
>> teach Blazar to talk to Ironic, which in turn will talk to Placement.
> 
> Hmm. So, here's the problem: placement has no concept of time. [1]
> 
> Placement only knows about one period of time: now. Placement doesn't have any 
> concept of an allocation or an inventory existing at some point in the future or 
> in the past.
> 
> Therefore, Blazar must unfortunately keep all of the temporal state about 
> reservations in its own data store. So, Ironic would actually have to talk to 
> Blazar to create a reservation of some amount of resources and Blazar will need 
> to call Placement to manage the state of resource inventory and allocations over 
> time; as reservations are activated, Blazar will either create or swap 
> allocation records in Placement to consume the Ironic resources for a tenant 
> that made the reservation.

I imagined it a bit differently. I assumed that
1. a user (operator?) talks to Blazar to create a bare metal node reservation.
1.1. some kind of quota is checked? does Blazar have any notion of quota?
2. Blazar talks to Ironic to create an allocation (yes, we also call it 
allocation, feel free to blame me)
3. Ironic gets a reservation from Placement and updates its internal records
4. Ironic returns an allocation to Blazar
5. Blazar returns a reservation to a user

And when a reservation in Blazar expires or is returned:
6. Blazar talks to Ironic to undeploy the node
6.1. Ironic deletes its allocation automatically
6.2. And thus notifies Placement to remove its allocation

Am I missing something?

> 
> Best,
> -jay
> 
> [1] this was a mistake for which I take full responsibility.
> 



From fungi at yuggoth.org  Wed Apr 10 11:17:39 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 10 Apr 2019 11:17:39 +0000
Subject: [all][docs][security-sig] season of docs
In-Reply-To: <671844ee600c7a5d99359b18c9c840c782e4cc67.camel@redhat.com>
References: <CAEs876gB6gB1O-RiK84jAydwR84cjcVRLd97edNNXt=nQXYYQA@mail.gmail.com>
 <CAJ6yrQgKBtb_nQKF+qh8Jwu4X6dAXi6pgmJpCjbtwu9bku46qw@mail.gmail.com>
 <faff00744292f54426e85b187d6c7a4975568910.camel@redhat.com>
 <CAJ6yrQhGOxF7umhP1Z4Hur0777ChB2dLXApRLVikCTXy76SRpw@mail.gmail.com>
 <LO2P123MB2223E78261CF1BDB3A6DABF48C420@LO2P123MB2223.GBRP123.PROD.OUTLOOK.COM>
 <671844ee600c7a5d99359b18c9c840c782e4cc67.camel@redhat.com>
Message-ID: <20190410111739.2kpscre5kcmfybw6@yuggoth.org>

On 2019-04-10 11:45:39 +0100 (+0100), Stephen Finucane wrote:
[...]
> I guess the next steps are figuring out what projects need the
> most help and putting together a list of ideas that we can submit.
> I can only really speak for nova and oslo.
[...]

In the last Security SIG meeting we discussed (in the context of the
TC's "help wanted" list) how most of the help we need is
documentation related.

We need Security Analysis documents for a lot of projects, and
reviewers for many of the ones already proposed too:

https://docs.openstack.org/security-analysis/latest/
https://review.openstack.org/#/q/project:openstack/security-analysis+is:open
https://opendev.org/openstack/security-analysis/

The Security Guide doesn’t seem to have been updated since Pike, so
it’s a good 1.5 years behind. Having someone step through what's
there and confirm or refresh it for Stein would be awesome:

https://docs.openstack.org/security-guide/
https://opendev.org/openstack/security-doc/

The documentation we have on secure coding practices is fairly light
and could do with more content:

https://security.openstack.org/#secure-development-guidelines

We could also use help with writing security notes and triaging the
outstanding OSSN backlog:

https://wiki.openstack.org/wiki/Security_Notes
https://wiki.openstack.org/wiki/Security/Security_Note_Process
https://bugs.launchpad.net/ossn

Much of the above likely requires folks with at least some
information security background or interest, but it's a really great
place to improve the overall security posture of OpenStack across
the board.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/0383ee32/attachment.sig>

From cdent+os at anticdent.org  Wed Apr 10 11:25:31 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 12:25:31 +0100 (BST)
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
 <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>
Message-ID: <alpine.OSX.2.21.1904101224540.10085@cdent-a01.vmware.com>

On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
> We would rather have ironic aware that some nodes are reserved for internal 
> bookkeeping.

Could you query placement for that "bookkeeping"? That's what
placement does.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dtantsur at redhat.com  Wed Apr 10 11:31:55 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 10 Apr 2019 13:31:55 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <alpine.OSX.2.21.1904101224540.10085@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
 <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>
 <alpine.OSX.2.21.1904101224540.10085@cdent-a01.vmware.com>
Message-ID: <0ef646d1-abaf-e820-6260-d8a6decdb1e7@redhat.com>

On 4/10/19 1:25 PM, Chris Dent wrote:
> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
>> We would rather have ironic aware that some nodes are reserved for internal 
>> bookkeeping.
> 
> Could you query placement for that "bookkeeping"? That's what
> placement does.
> 

It means replacing a short database query with a call to a remote resource with 
all the associated performance and reliability penalties. Also if someone 
creates an allocation in Placement directly, we won't have an associated ironic 
allocation, which is fine, but may be confusing for users. E.g. they see a free 
node in ironic, but it's actually occupied in Placement.


From chkumar246 at gmail.com  Wed Apr 10 11:35:43 2019
From: chkumar246 at gmail.com (Chandan kumar)
Date: Wed, 10 Apr 2019 17:05:43 +0530
Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update
 XVIII - Apr 10, 2019
Message-ID: <CAMzQOdmHF2ok=PiN4o=ywpY=fNB8B_zpLWA9z_TyHjXvrjSTAw@mail.gmail.com>

Hello,

Here is the 17th update (Apr 03 to Apr 09, 2019) on collaboration
on os_tempest[1] role between TripleO and OpenStack-Ansible projects.

Highlights of the week:
* os_tempest doc build job was broken and bug
  in generate test-list file task are got fixed
* we have added tempest_services var to automatically enable
  tempest_service_available_{project_name} var.
* os_tempest got support of debian distro.
* We have added required os_tempest vars in tripleo CI in order to
  port periodic rdo third party job to os_tempest.

Thanks to Arx for tempest_test_whitelist featureset overrides,
mnaser for adding debian support and fixing doc job builds across
OSA, jrosser, odyssey4me, noonedeadpunk for helping on tempest_services
patch.

Things got merged:
os_tempest
* docs: drop sphinxmark - https://review.openstack.org/649859
* Fix Generate test-list file task - https://review.openstack.org/649604
* debian: add support - https://review.openstack.org/650499
* tempest_services var for setting tempest_service_available_{} -
https://review.openstack.org/649577

tripleo
* Add tempest_test_whitelist to allowed_override -
https://review.openstack.org/#/c/648110/
* Remove the tempest_test_whitelist from playbook -
https://review.openstack.org/#/c/648111/
* tempest_services var for setting tempest_service_available_{} -
https://review.openstack.org/649577
* Include vars of tempest_services and concurrency in fs override -
https://review.openstack.org/649553

Things in Progress:
os_tempest:
* os_tempest user guide: https://review.openstack.org/#/c/644570/
* Switch to import_task in os_tempest - https://review.openstack.org/650054

tripleo
* Update Standalone Periodic jobs in Master to use OS_TEMPEST -
https://tree.taiga.io/project/tripleo-ci-board/us/972

What is coming?
* We are working on porting standalone periodic jobs to os_tempest on RDO side
* FInishing Doc user guide

Here is the 17th update [2]. Have queries, Feel free to ping us on
#tripleo or #openstack-ansible channel.

Links:
[1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest
[2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004492.html

Thanks,

Chandan Kumar


From cdent+os at anticdent.org  Wed Apr 10 11:51:17 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 12:51:17 +0100 (BST)
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <0ef646d1-abaf-e820-6260-d8a6decdb1e7@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
 <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>
 <alpine.OSX.2.21.1904101224540.10085@cdent-a01.vmware.com>
 <0ef646d1-abaf-e820-6260-d8a6decdb1e7@redhat.com>
Message-ID: <alpine.OSX.2.21.1904101236520.12309@cdent-a01.vmware.com>

On Wed, 10 Apr 2019, Dmitry Tantsur wrote:

> On 4/10/19 1:25 PM, Chris Dent wrote:
>> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
>>> We would rather have ironic aware that some nodes are reserved for 
>>> internal bookkeeping.
>> 
>> Could you query placement for that "bookkeeping"? That's what
>> placement does.
>> 
>
> It means replacing a short database query with a call to a remote resource 
> with all the associated performance and reliability penalties. Also if 
> someone creates an allocation in Placement directly, we won't have an 
> associated ironic allocation, which is fine, but may be confusing for users. 
> E.g. they see a free node in ironic, but it's actually occupied in Placement.

This gets at some of the general concepts of "how best to use
placement" which are still emerging and evolving and one of the
reasons why I think these threads are useful: We can spend some time
reflecting on that kind of big topic without feeling like it is
wasting precious PTG time.

>From what I've been able to discern with the various ways I've used
placement, it works most easily and effectively when you allow it to
be the single source of truth for inventory and use of that
inventory [1]. This suggests that if you want to optionally use
placement with ironic, then having placement be a one of several
possible backends to the ironic bookkeeping system might be worth
considering.

That said, I'm not sure placement is expensive or risky enough to
not just use (solely) it. Yes, it is another http service and
database but it is super lightweight; easy to install, scale and
manage. If the http service is multi-homed, then there are pretty
much the same network partitioning issues (for talking to the
database) with or without a placement. You could easily choose to
co-locate the placement service (web and database) on the same
host(s) as Ironic.

Note, I'm not trying to twist your arm anything here, just present
options. I recognize that achieving a standalone ironic and then
going and adding a placement to it feels like a step backwards. It
might help to think of placement as a library that happens to be
packaged as an HTTP microservice.

[1] Which, if you're going to have N less than many sources of
truth, it may as well be _one_ to avoid synchronization problems.
Before placement came along I thought (and sometimes still do) that
having a thing which _represents_ a view of the truth (about
inventory) as placement does is overkill if it is possible for
things themselves to represent their own truth, and be event/pubsub
driven about their willingness to accept a workload (instead of
being told by some authority).

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Wed Apr 10 12:04:11 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 13:04:11 +0100 (BST)
Subject: [placement][nova][ptg] Testing PlacementFixture effectively
Message-ID: <alpine.OSX.2.21.1904101257450.12309@cdent-a01.vmware.com>


>From the cross project etherpad [1]

-=-=-

* We've had two instances where nova functional tests have failed
   from what seems like an unrelated change in placement, but turns
   out to be something that impacts the behavior of the
   PlacementFixture, from placement, used by nova. Would be good to
   decide on a way to make this safer without having to run the
   entire nova functional test suite (and the functional suite of
   every other project that eventually uses the Fixture) on every
   placement change. Maybe a subset somehow? Or some other kind of
   magic? Another option may be what we've been doing: fixing
   problems as they come up. That might be OK.

     * https://bugs.launchpad.net/nova/+bug/1818560

     * https://bugs.launchpad.net/nova/+bug/1821092

* (gibi): Currently placement patches trigger grenade-py3 and
   tempest-full-py3 and both jobs takes around an hour to run. The
   nova-tox-functional test runs in about 20 minutes. So triggering
   nova-tox-functional for placement patches does not increase the
   length of the CI feedback loop.

     * True but the total cpu cost of testing a single placement
       patch is a thing we need to keep in mind. Zuul resources are
       scarce. It's not just how long we have to wait, but how long
       everyone has to wait for all patches. (Not saying we shouldn't
       do it, just that we need to consider that impact.) (gibi): I
       agree that overall cpu cost is a factor here.

     * [efried] ++ I think this is a solid idea, at least until we
       implement the next bullet.

* (gibi): Both above bug could be detected with some test on the
   placement side using the PlacementFixture in a way nova is using
   that fixture. It might not be easy to gather all the relevat usage
   patterns.

     * [efried] Agree with this. We don't have any testing of
       PlacementFixture in placement itself (until the below)

* [efried] Started simple unit testing here https://review.openstack.org/#/c/645255/

     * This probably doesn't do us much good wrt preventing weird
       gatebusters like the above.

-=-=-

This is generally agreed to be an issue we need to address and there
are ideas for how to fix it, so the things to resolve here are:

* Tuning the ideas to the best combination.
* Figuring out who is going to do it.

[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Wed Apr 10 12:14:13 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 13:14:13 +0100 (BST)
Subject: [placement][nova][ptg] Shared resource providers for shared disk on
 compute hosts 
Message-ID: <alpine.OSX.2.21.1904101304550.12309@cdent-a01.vmware.com>


This topic is from the cross project etherpad [1]

There's a spec in progress for this: https://review.openstack.org/#/c/650188/

It does a pretty good job of explaining some of the corner cases. We
need to make sure we have a good awareness of all the corners
because when we try to do (or even think about) this feature we
discover a problem that derails the work.

Which is unfortunate because supporting shared disk is one of the
principles on which placement was sold. All the necessary
functionality is already there in placement, so making it work is
mostly on the nova side, a lot of it in nova-compute. Much of the
challenge is associated with dealing with move operations.

A question I posed on the spec is whether it is possible to make
this happen without having to rely on additional config. It seems
like something where it would be super nice (but perhaps not
possible) for a virtdriver to be able to turn on and manage itself.

So the discussion surrounding this topic is perhaps around:

* teasing out the dark corners as much as possible so we don't
   stumble again

* nailing the issues with moves

* exploring the options for making it as hands-free as possible


[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From yedhusastri at gmail.com  Wed Apr 10 12:20:09 2019
From: yedhusastri at gmail.com (Yedhu Sastri)
Date: Wed, 10 Apr 2019 14:20:09 +0200
Subject: RuntimeError: OVS transaction timed out - After minor upgrade
Message-ID: <CANX8mtJrWQGAiwGa=y19put+gst9WcW_Ya_9aGUAGC4C2abEng@mail.gmail.com>

Dear All,

We did a minor upgrade on our OpenStack environment Newton HA cluster from
14.2.12 to 14.2.16 using the following link.

https://docs.openstack.org/openstack-ansible/newton/upgrade-guide/minor-upgrade.html

The upgrade was successful and we tested creation of VM's and it was also
successful we were able to ssh into the VM's.

Then we rebooted the controllers one by one. But after that we can create
the VM's but it is not getting IP from dhcp agent.

In the openvswitch-agent.log we are getting 'OVS transaction timeout'. Any
help is much appreciated.

2019-04-09 17:25:29.063 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
net_uuid None not managed by VLAN manager
2019-04-09 17:25:29.088 3504 INFO neutron.agent.common.ovs_lib
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
04275c8a-2d12-477b-b435-f6483d418e93 not present in bridge br-int
2019-04-09 17:25:29.089 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
net_uuid None not managed by VLAN manager
2019-04-09 17:25:29.198 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
net_uuid None not managed by VLAN manager
2019-04-09 17:25:29.228 3504 INFO neutron.agent.common.ovs_lib
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
5c25b580-9dcb-4930-a2fe-9cab951114dd not present in bridge br-int
2019-04-09 17:25:29.228 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
net_uuid None not managed by VLAN manager
2019-04-09 17:25:29.229 3504 INFO neutron.agent.securitygroups_rpc
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Remove device filter
for [u'63cb0c6a-6e82-41a8-ad46-511ee84579ad',
u'9764e98a-bb32-4d37-9460-5a546f351e5a',
u'2c075f29-156c-4787-b40f-434c437164e4',
u'f00de46f-301a-4789-add1-a8239ee6c859',
u'e26c1806-8041-4ce2-aea0-74ca469add67',
u'9fa17447-d25d-441b-9983-b81e43c6e6d2',
u'3ef24ce6-19b5-47c8-9510-767e64d33e9f',
u'c2d37add-65a0-4fc9-914c-2382af70b1ca',
u'a8b7c7aa-a5d0-47b3-a944-7b6c4428eda8',
u'bf6f7608-0573-43f7-822a-878d7708d985',
u'046670cd-77dd-4ce8-bb4b-f1489264375b',
u'b7aefa18-d768-47a8-bb5f-6b1e838deaeb',
u'04275c8a-2d12-477b-b435-f6483d418e93',
u'124eb5e6-2b8a-44a9-aa8b-f6d9bc87f13f',
u'5c25b580-9dcb-4930-a2fe-9cab951114dd']
2019-04-09 17:27:09.740 3504 INFO neutron.agent.securitygroups_rpc
[req-5984df4b-c30f-403c-8e87-86c4ccf50a9f - - - - -] Provider rule updated
2019-04-09 17:27:41.961 3504 INFO neutron.agent.securitygroups_rpc
[req-67c36a44-f778-48f0-b7ae-0a5244ff95c1 - - - - -] Provider rule updated
2019-04-09 17:28:28.334 3504 INFO neutron.agent.securitygroups_rpc
[req-aeffc24f-a354-412e-b458-950c1d4b52ef - - - - -] Provider rule updated
2019-04-09 17:28:46.276 3504 INFO neutron.agent.securitygroups_rpc
[req-2dd51325-40c4-4ff0-a384-bccbe3ca0bfc - - - - -] Provider rule updated
2019-04-09 17:28:46.278 3504 INFO neutron.agent.securitygroups_rpc
[req-6d48bfd9-0230-4a82-a477-d9e4171db519 - - - - -] Provider rule updated
2019-04-09 17:30:32.695 3504 INFO neutron.agent.securitygroups_rpc
[req-01b9b7a8-84a4-42cc-aebb-db846eb2b8f0 - - - - -] Provider rule updated
2019-04-09 17:30:54.288 3504 INFO neutron.agent.securitygroups_rpc
[req-de1755bd-0e21-4b75-9fde-db422ee9a79a - - - - -] Provider rule updated
2019-04-09 17:32:12.377 3504 INFO neutron.agent.securitygroups_rpc
[req-26bc4547-edb7-4092-b4f4-6465c29dfbe4 - - - - -] Provider rule updated
2019-04-09 17:32:21.444 3504 WARNING
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Device
0d535260-dd98-4027-a2ba-4c5412d4eab0 not defined on plugin or binding failed
2019-04-09 17:32:21.461 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
d3baa557-a367-4a6d-8d58-7183df4243a6 updated. Details: {u'profile': {},
u'network_qos_policy_id': None, u'qos_policy_id': None,
u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
u'680c9bdd-9cea-4059-8c8c-2928dd0ee48f', u'segmentation_id': 65606,
u'device_owner': u'network:router_ha_interface', u'physical_network': None,
u'mac_address': u'fa:16:3e:b3:9a:60', u'device':
u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'port_security_enabled': False,
u'port_id': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'fixed_ips':
[{u'subnet_id': u'5b49f8e5-991d-4ecd-a584-df605063aecb', u'ip_address':
u'169.254.192.9'}], u'network_type': u'vxlan'}
2019-04-09 17:32:21.461 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 1 as local
vlan for net-id=680c9bdd-9cea-4059-8c8c-2928dd0ee48f
2019-04-09 17:32:35.477 3504 INFO oslo_messaging._drivers.amqpdriver [-] No
calling threads waiting for msg_id : a9314d944ff8486abf909d4cc271f9a0
2019-04-09 17:32:39.016 3504 INFO neutron.agent.securitygroups_rpc
[req-51453b2c-b454-45bd-b7f8-c78560437016 - - - - -] Provider rule updated
2019-04-09 17:32:54.141 3504 ERROR
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Switch connection
timeout
2019-04-09 17:32:57.964 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Bridge br-tun changed
its datapath-ID from 6a740a5da349 to 00006a740a5da349
2019-04-09 17:32:58.015 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
0d8dc3c9-c115-45f8-bbb2-cc715b7c1079 updated. Details: {u'profile': {},
u'network_qos_policy_id': None, u'qos_policy_id': None,
u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
u'device_owner': u'network:router_gateway', u'physical_network':
u'outbound1', u'mac_address': u'fa:16:3e:aa:d7:56', u'device':
u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'port_security_enabled': False,
u'port_id': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'fixed_ips':
[{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
u'10.97.179.34'}], u'network_type': u'vlan'}
2019-04-09 17:32:58.016 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 2 as local
vlan for net-id=4ffb2c28-f9f1-4a25-82a0-df7f7a002434
2019-04-09 17:32:58.030 3504 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
1239fa6c-265a-4f16-ab00-c86fe40545d9 updated. Details: {u'profile': {},
u'network_qos_policy_id': None, u'qos_policy_id': None,
u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
u'device_owner': u'network:router_gateway', u'physical_network':
u'outbound1', u'mac_address': u'fa:16:3e:4d:73:46', u'device':
u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'port_security_enabled': False,
u'port_id': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'fixed_ips':
[{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
u'10.97.179.99'}], u'network_type': u'vlan'}
2019-04-09 17:33:13.289 3504 ERROR neutron.agent.ovsdb.impl_idl
[req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Traceback (most recent
call last):
  File
"/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/native/connection.py",
line 117, in run
    txn.results.put(txn.do_commit())
  File
"/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py",
line 91, in do_commit
    raise RuntimeError(_("OVS transaction timed out"))
RuntimeError: OVS transaction timed out



-- 

With kind regards,
Yedhu Sastri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/f58b223e/attachment-0001.html>

From smooney at redhat.com  Wed Apr 10 12:26:53 2019
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 10 Apr 2019 13:26:53 +0100
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
 <20190408181337.GA4622@sm-workstation>
 <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
Message-ID: <4b7558f486e31f7ad741ee1ac81df7982cc0aa29.camel@redhat.com>

On Tue, 2019-04-09 at 18:46 +0200, Dmitry Tantsur wrote:
> On 4/8/19 8:13 PM, Sean McGinnis wrote:
> > > > > 
> > > > > The rendering on PyPi, and the validation that they do that will reject the
> > > > > package upload if it has README syntax errors, is not aware of any Sphinx
> > > > > extensions we use in our normal docs, so pulling in other documentation into
> > > > > the README could potentially cause release issues.
> > > > 
> > > > Good point. Maybe we should just stop including README content in sphinx
> > > > docs, and not do anything additional that's more complex?
> > > > 
> > > 
> > > Honestly, this means copy-paste and that one of the copies will probably get
> > > outdated.
> > > 
> > 
> > What is in the README that is needed in the documentation? For me, those have
> > always been entirely different audiences and therefore different content.
> 
> I don't think it's any different. Both README and the index page serve as an 
> introduction to the project. The same people will land at one of them, depending 
> if they come from github/gitea or from docs.o.o
you assume that devs read docs.o.o
i personally much prefer reading the rst then the renderd html content
so i think they do have slight different auidence in that respect even if they have
the same contet.

i could happily live in a world wehre docs.o.o was not a thing but if the RSTs ever
got to a point where they were not readable without sphinx due to tomany uses
of include then that woudl be an issue for me.
> 
> > 
> > Maybe it just needs a different perspective for these project from how they've
> > used them so far?
> > 
> 
> 



From cdent+os at anticdent.org  Wed Apr 10 12:32:09 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 13:32:09 +0100 (BST)
Subject: [placement][nova][ptg] NUMA Topology with placement
Message-ID: <alpine.OSX.2.21.1904101318250.12309@cdent-a01.vmware.com>


>From the cross-project etherpad [1]

* Spec: https://review.openstack.org/#/c/552924/

This is probably the biggest topic, in the sense that modeling NUMA
in placement and how we do that has a big impact across a large
number of other pending features, including several specs that state
things like "this would be different if we had NUMA in placement".

Similarly, if we do have NUMA in placement, we also end up with
questions about and requirements with:

* json payload for getting allocation candidates:
   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004724.html

* increased complexity in protecting driver provided traits
   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004779.html

* resource provider - request group mapping
   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004819.html

* resource providers with traits but no resources
   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004817.html

* resource provider (subtree) affinity
   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004782.html

And there's probably cascades over to dedicated cpus, cpu
capabilities, network bandwidth mgt, etc etc.

>From the placement perspective, the problem isn't representing the
NUMA info in placement, it's getting candidates back out in a useful
fashion once they are in there, so the resources can be claimed. It
would be useful if someone could make explicit and enumerate:

* What (if any) ways in which the current handling of nested
   providers does not support _writing_ NUMA-related info to placement.

* What (we know there are some) ways the current handling of allocation
   candidates and the underlying database queries do not support
   effective use of NUMA info once it is in placement.

Thanks.

[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From smooney at redhat.com  Wed Apr 10 12:37:50 2019
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 10 Apr 2019 13:37:50 +0100
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <2EE296D083DF2940BF4EBB91D39BB89F40C5611A@SHSMSX104.ccr.corp.intel.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
 <ec20d262d2db32c31d8157e496a87029af08e3cc.camel@redhat.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C5611A@SHSMSX104.ccr.corp.intel.com>
Message-ID: <cc4aefc58ff2a670bab10f258ec8e955eb8f7d77.camel@redhat.com>

On Wed, 2019-04-10 at 01:24 +0000, Guo, Ruijing wrote:
> Right. I am planning to add ovsdpdk in networking-ovn like networking-ovn-tempest-dsvm-ovs-master. We can leverage
> networking-ovsdpdk to build ovsdpdk packages.
> 
> The only issue is that qemu without kvm can be crash in vhostuser interface. So I want to have nested virtualization.
well dpdk only need preallocated mapped shared file descirptor backed memoery.
as i siad i belive you can use the nova file_backed memory feature to achive that but i have not tested it.
im also tinking of filing a nova spec to enable the qemu mttcg backend which woudl allow us to do testing
with hugepages and cpu pinning.

ovs-dpdk does not need kvm and nested virt.
the only requirement on nested virt come form how nova does hugepage supprot.

> 
> 
> -----Original Message-----
> From: Sean Mooney [mailto:smooney at redhat.com] 
> Sent: Tuesday, April 9, 2019 9:05 PM
> To: Clark Boylan <cboylan at sapwetik.org>; openstack-discuss at lists.openstack.org; Guo, Ruijing <ruijing.guo at intel.com>
> Subject: Re: [CI] nested virtualization support in OpenStack CI
> 
> On Mon, 2019-04-08 at 19:05 -0400, Clark Boylan wrote:
> > 
> > On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> > > Hi, Clark
> > > 
> > > I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> > > virtualization.
> > > 
> > 
> > Can you describe this requirement in a bit more detail? Looking at 
> > docs it appears you need to have large pages. Maybe a "picture" will help too:
> > 
> >   Workload VM
> >   (cirros or similar small VM running under
> >    emulation or virtualized if nested virt is enabled)
> >        |
> >       V
> >   OpenStack Infra Test Node ("middle VM")
> >     This is where ovsdpdk runs right? And this requires large pages?
> 
> so ovs-dpdk requires hugepage memeory to be allocated to fucntion but that by its self does not require nested virt.
> nova on the other hand does require kvm to allow vms to be spawned with hugepages because not enabled partial cpu
> pinning when hugepages are enabled and qemu does not support per cpu cpu pinning without kvm or the mttcg backend. 
> 
> in the special case of ovs-dpdk i have been meaning to test an alternitive way for deploying with ovs-dpdk but to date
> i have not had time. about 2 years ago i had a memeber of my team extend libvirt to allow the creation of qemu guests
> with file backed memory. about a year ago redhat extended nova to support that.
> it should technically be possibel to run ovs-dpdk with hugepages and the cirros guests with file backed memory to do
> testing without nested virt.
> 
> related to this i finished setting up my own personal ci to do limited ovs-dpdk and numa/nfv testing with nested virt.
> https://review.openstack.org/#/c/650573/
> tempest-dpdk https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-dpdk/fec9044/
> tempest-pinning https://logs.seanmooney.info/73/650573/1/seans-nfv-ci/tempest-pinning/1939971/
> 
> i am planning to exprement to see if i can run some of those nested virt jobs upstream or via openlab in the furutre.
> 
> it shoudl be possible to test with ovn too but i have not tried that pesonally yet the job definitions currently live
> in https://review.seanmooney.info/plugins/gitiles/test/+/master so perhaps that ill server as a starting point for
> people wanting to create similar jobs 
> 
> the networking-ovs-dpdk devstack plugin compiles and deploys ovs-dpdk form source which also installs but does not
> configure or start ovn since its part of the ovs repo.
> 
> with some tweeks to the networking-ovn plugin it would probably be simple enough to use both plugins to provide the
> desired versions of ovn,ovs and dpdk.
> 
> with all that said the intel nvf ci was created to test ovs-dpdk integration with openstack and also some other nfv
> features like cpu pinning. https://wiki.openstack.org/w/index.php?title=ThirdPartySystems/Intel_NFV_CI
> this ci was also intended to test odl and ovn with ovs dpdk at somepoint in the future
> alther that never happend. i woudl suggest reaching out to   <timothy.gresham at intel.com>, <openstack-nfv-ci at intel.com>
> to see if it could be extended to do ovn testing in the absence of upstream support.
> 
> >        |
> >       V
> >   Hypervisor (managed by our cloud providers)
> > 
> > Are we not able to do large pages with emulated workload VMs? Also can 
> > we do large pages on the Workload VM if the Infra Test Node isn't 
> > configured for them? If the infra test node isn't configured for them do we also need support for large pages from
> > the Hypervisor?
> > 
> > If we can do large pages with emulated workload VMs and the hypervisor 
> > isn't required to support that we should be able to configure large 
> > pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of these things won't work.
> > In any case specific details on what is required and where it is required will be useful.
> > 
> > Clark
> > 
> 
> 



From cdent+os at anticdent.org  Wed Apr 10 12:39:38 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 10 Apr 2019 13:39:38 +0100 (BST)
Subject: [placement] Virtual Pre-PTG
In-Reply-To: <alpine.OSX.2.11.1904081341530.9091@seed.local>
References: <alpine.OSX.2.21.1903251535420.32545@cdent-a01.vmware.com>
 <alpine.OSX.2.11.1904081341530.9091@seed.local>
Message-ID: <alpine.OSX.2.21.1904101333410.12309@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Chris Dent wrote:
> On Mon, 25 Mar 2019, Chris Dent wrote:
>> I propose we start the process the week of the 8th, giving us 3
>> weeks of discussion prior to the PTG, with the caveat that the week
>> of the 22nd my availability will be limited. Between now and then
>> make sure you topics get on the etherpads, along with as much
>> additional info as you would normally put there. Don't fret if you
>> think of something after the 8th, just put it on the etherpad as
>> normal, and we'll figure it out.
>
> I'm going to get this started later today using the "series of email
> threads" mentioned above. I'll give them '[placement]' and '[ptg]'
> and base them off whatever seems relavant from the two etherpads
> [2,3]. As before, feel free to continue adding to the etherpads.

I've started threads for everything from [2,3] that seemed relevant.
For each topic where I started a thread, I changed the top-level
topic to bold and made the next line a link to the archive of the
first email in the thread.

The discussion should continue through next week. As topics reach a
natural conclusion I'll summarize back to the etherpad. Anything
that seems fully done I'll move to another part of the etherpad. The
point with that is so that by the time the PTG comes around we're
only paying attention to stuff we got stuck on during this
email-based discussion.

As ever, if you remember a topic that hasn't already come up, please
add it to one of the etherpads.

Also, so it is clear, these discussions are for everyone. You don't
need to be a regular placement contributor or user to participate.
If you have something to say, we want to hear it.

And a reminder: There's a retrospective etherpad taking shape at [4].

Thanks

[2] https://etherpad.openstack.org/p/placement-ptg-train
[3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
[4] https://etherpad.openstack.org/p/placement-ptg-train-retrospective

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dtantsur at redhat.com  Wed Apr 10 12:42:26 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 10 Apr 2019 14:42:26 +0200
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <4b7558f486e31f7ad741ee1ac81df7982cc0aa29.camel@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
 <20190408181337.GA4622@sm-workstation>
 <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
 <4b7558f486e31f7ad741ee1ac81df7982cc0aa29.camel@redhat.com>
Message-ID: <8456b65a-ad2f-4dfe-a134-587fa8d01f59@redhat.com>

On 4/10/19 2:26 PM, Sean Mooney wrote:
> On Tue, 2019-04-09 at 18:46 +0200, Dmitry Tantsur wrote:
>> On 4/8/19 8:13 PM, Sean McGinnis wrote:
>>>>>>
>>>>>> The rendering on PyPi, and the validation that they do that will reject the
>>>>>> package upload if it has README syntax errors, is not aware of any Sphinx
>>>>>> extensions we use in our normal docs, so pulling in other documentation into
>>>>>> the README could potentially cause release issues.
>>>>>
>>>>> Good point. Maybe we should just stop including README content in sphinx
>>>>> docs, and not do anything additional that's more complex?
>>>>>
>>>>
>>>> Honestly, this means copy-paste and that one of the copies will probably get
>>>> outdated.
>>>>
>>>
>>> What is in the README that is needed in the documentation? For me, those have
>>> always been entirely different audiences and therefore different content.
>>
>> I don't think it's any different. Both README and the index page serve as an
>> introduction to the project. The same people will land at one of them, depending
>> if they come from github/gitea or from docs.o.o
> you assume that devs read docs.o.o

Well, I personally do read them all the time..

> i personally much prefer reading the rst then the renderd html content
> so i think they do have slight different auidence in that respect even if they have
> the same contet.

I think the audience will see whatever the search engine will lead them to. 
https://duckduckgo.com/?q=openstack+nova gives me 1. docs.o.o, 2. wiki, 3. 
github. Chances are very high I would check the docs rather then the source code 
first.

> 
> i could happily live in a world wehre docs.o.o was not a thing but if the RSTs ever
> got to a point where they were not readable without sphinx due to tomany uses
> of include then that woudl be an issue for me.
>>
>>>
>>> Maybe it just needs a different perspective for these project from how they've
>>> used them so far?
>>>
>>
>>
> 



From edmondsw at us.ibm.com  Wed Apr 10 12:59:20 2019
From: edmondsw at us.ibm.com (William M Edmonds - edmondsw@us.ibm.com)
Date: Wed, 10 Apr 2019 12:59:20 +0000
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <20190410092108.GL7047@thor.bakeyournoodle.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <20190410004311.GH7047@thor.bakeyournoodle.com>
 <4BCFE1D8-BE51-43B1-8D37-69B757166C85@fried.cc>
 <20190410063554.GJ7047@thor.bakeyournoodle.com>
 <5cdd3173-5d6e-038d-669e-3d4a353509f0@openstack.org>
 <20190410092108.GL7047@thor.bakeyournoodle.com>
Message-ID: <87CA4FD5-5C11-4160-90EB-E07A7EF8C1D7@us.ibm.com>


On 4/10/19, 5:24 AM, "Tony Breeds" <tony at bakeyournoodle.com> wrote:
> On Wed, Apr 10, 2019 at 10:41:31AM +0200, Thierry Carrez wrote:
> > Tony Breeds wrote:
> > > On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
> > > > > core-team sure, but what is it that a PTL does/can do that a SIG chair
> > > > > can't?
> > > > 
> > > > Ack patches in other repositories like release, governance, etc.? But
> > > > yeah, no reason a SIG chair couldn't also do those things, as long as
> > > > the vote is recognized the same way.
> > > 
> > > I can't speak to the TC but I think that a SIG chair would basically be
> > > a Liaison in the releases repo and we already know how to handle that.
> > 
> > So.. switching to my release management hat... that actually brings up an
> > interesting point, and a good reason to keep PowerVMStackers and Winstackers
> > the same.
> > 
> > Project teams basically produce "OpenStack" the software release, while SIGs
> > work to make "OpenStack" more relevant for specific cases. While SIGs can
> > produce code and can own git repositories, we currently have no SIG that
> > owns *deliverables* being made part of the regular OpenStack release.
> > 
> > The release team only tracks project teams, and it's simpler if it stays
> > that way. It's also a really good delineation as to what is project team
> > territory and what is SIG territory.
> > 
> > Both PowerVMStackers or WinStackers currently produce deliverables that are
> > released under a cycle-based model and are included in the final "OpenStack"
> > release. Switching those teams to become SIGs would have an additional
> > consequence: it would remove those deliverables from the "OpenStack"
> > release.
>
> Only *if* those repos don't get 'adopted' by another project.
> 
> In the hypothetical example we're looking at:
> openstack/nova-powervm would come under the governance of nova (and
> therefore still have all the 'rights' of a project) (same with Telemetry
> and Neutron).  The SIG would be there to maintain consistency across the
> 3 project teams.
> 
> I feel like that's a better outcome but it isn't the actual proposal
> we started discussing and I kinda de-railed the conversation ... sorry.
> 
> > So unless those teams actually want that, or the TC decides to do that, I
> > don't think we should switch those teams to SIGs.
> 
> So the original proposal which would be a straight transition doesn't
> work for this reason which is good to know

Now we're tracking. This (both Thierry's and Tony's emails here) is what I was trying to say. Sorry I wasn't clearer, but you got there anyway... Thanks.


From smooney at redhat.com  Wed Apr 10 13:07:57 2019
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 10 Apr 2019 14:07:57 +0100
Subject: [all] Removing privacy breaches in doc
In-Reply-To: <8456b65a-ad2f-4dfe-a134-587fa8d01f59@redhat.com>
References: <7d808ac8-ccbd-8246-c7a7-678220a48514@debian.org>
 <0aea4056-a707-6d7a-9325-67233c009eaf@inaugust.com>
 <20190408113335.GC29851@sm-xps>
 <e2d24c18-b64c-8873-1c60-0460be389725@inaugust.com>
 <cd52149e-d4dd-b84c-ffd7-017f37050b2c@redhat.com>
 <20190408181337.GA4622@sm-workstation>
 <c3841955-2c35-952d-2054-4fcb3c2e2312@redhat.com>
 <4b7558f486e31f7ad741ee1ac81df7982cc0aa29.camel@redhat.com>
 <8456b65a-ad2f-4dfe-a134-587fa8d01f59@redhat.com>
Message-ID: <2f193b285627c9eb576650aa30b57d623836c07f.camel@redhat.com>

On Wed, 2019-04-10 at 14:42 +0200, Dmitry Tantsur wrote:
> On 4/10/19 2:26 PM, Sean Mooney wrote:
> > On Tue, 2019-04-09 at 18:46 +0200, Dmitry Tantsur wrote:
> > > On 4/8/19 8:13 PM, Sean McGinnis wrote:
> > > > > > > 
> > > > > > > The rendering on PyPi, and the validation that they do that will reject the
> > > > > > > package upload if it has README syntax errors, is not aware of any Sphinx
> > > > > > > extensions we use in our normal docs, so pulling in other documentation into
> > > > > > > the README could potentially cause release issues.
> > > > > > 
> > > > > > Good point. Maybe we should just stop including README content in sphinx
> > > > > > docs, and not do anything additional that's more complex?
> > > > > > 
> > > > > 
> > > > > Honestly, this means copy-paste and that one of the copies will probably get
> > > > > outdated.
> > > > > 
> > > > 
> > > > What is in the README that is needed in the documentation? For me, those have
> > > > always been entirely different audiences and therefore different content.
> > > 
> > > I don't think it's any different. Both README and the index page serve as an
> > > introduction to the project. The same people will land at one of them, depending
> > > if they come from github/gitea or from docs.o.o
> > 
> > you assume that devs read docs.o.o
> 
> Well, I personally do read them all the time..
> 
> > i personally much prefer reading the rst then the renderd html content
> > so i think they do have slight different auidence in that respect even if they have
> > the same contet.
> 
> I think the audience will see whatever the search engine will lead them to. 
> https://duckduckgo.com/?q=openstack+nova gives me 1. docs.o.o, 2. wiki, 3. 
> github. Chances are very high I would check the docs rather then the source code 
> first.
perhaps but my search engine for doc is 
a.) grep ~/repo/openstack/nova
b.) github.com/<org>/<project>
c.) codesearch.openstack.org

that is not ture of all the docs i use
https://developer.openstack.org/api-ref/compute/
and the ohter api refs i almost exclcively view online
and i use https://docs.openstack.org/nova/latest/configuration/config.html
a reasonable amount but even then if will often check the source code.
ince we centralised all the config opts and move the documention into the code
https://github.com/openstack/nova/tree/master/nova/conf is jsut as fast

im not saying docs.o.o is not useful i do use it but the only source of docs i have
never used in distor or pypi packages.

anyway this is a little off topic the privacy concerns are obviosly vlaid in some respect
and i think we can like fine a path forward that suties everyone.

personlay i would not include any content in from the docs in the readme and instead just provide links
to the relevent sections.

for example i think the nova readme is is good as it is https://github.com/openstack/nova/blob/master/README.rst
but i also get that you might not want to embed non local images.

i persoall woudl expect most people to read the readme either via gitub/pypi
or with nano/vim/emac/<beloved editor of choice> localy. i would not expect peopel to read a rendered
html form of the readme outside of github/pypi/gitea

> 
> > 
> > i could happily live in a world wehre docs.o.o was not a thing but if the RSTs ever
> > got to a point where they were not readable without sphinx due to tomany uses
> > of include then that woudl be an issue for me.
> > > 
> > > > 
> > > > Maybe it just needs a different perspective for these project from how they've
> > > > used them so far?
> > > > 
> > > 
> > > 
> 
> 



From openstack at fried.cc  Wed Apr 10 13:38:57 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 08:38:57 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <1554888244.14045.10@smtp.office365.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
Message-ID: <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>

> Since providers can be nested a provider can be a strucutral element in 
> a nested tree without providing resources.

This.

I wouldn't get too hung up on "a resource provider that doesn't provide
resources". "Resource provider" is just a name of a thing. It doesn't
(can't) exhaustively define what the thing is and does.

> To avoid the trait on an empty RP problem in this case all 
> the traits are added to the device RPs even if some of the traits 
> (CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP.

Noting that I have at best a cursory understanding of all things
network, this seems okay to me; I can get my brain around a "network
device" having a "VNIC type" trait. However...

> I think the possible solution to move the trait down to the RP that 
> provides the resources that has a capability described by the trait

In Matt's patch, the traits represent capabilities of the virt driver. I
*suppose* you could argue to attach traits like
COMPUTE_NET_ATTACH_INTERFACE to providers of network resources, or
COMPUTE_VOLUME_EXTEND to providers of disk resources (even those are
pretty awkward). But where would you put COMPUTE_TRUSTED_CERTS? And
let's please not contrive non-resource resources to satisfy
architectural purity.

> I think this work should be driven by a specific need, like the NUMA 
> modelling in placement by nova. What is the timeline of NUMA modelling 
> in placement?

Proposes NUMA topology with RPs: https://review.openstack.org/552924
Proposes NUMA affinity for vGPUs: https://review.openstack.org/650963
Spec: Allocation Candidates: Subtree Affinity:
https://review.openstack.org/650476

and a bunch of the other specs in flight are affected by NUMA modeling.

We've been building up to this for years. If it doesn't happen in Train,
it'll happen in U. While I agree we shouldn't solve a problem until it's
a problem, I also don't want to another situation like reshaper, where
suddenly at the end of the cycle we realize/remember this nontrivial
thing we need to handle.

efried
.


From sean.mcginnis at gmx.com  Wed Apr 10 14:10:15 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 10 Apr 2019 09:10:15 -0500
Subject: [masakari][Release-job-failures] Tag of openstack/masakari failed
Message-ID: <20190410141015.GA20373@sm-workstation>

There were a couple of release note publish failures today for the masakari and
masakari-monitors repos. They were due to these repos still using oslosphinx in
their docs and releasenotes jobs.

With the release of Sphinx 2.0 last week, oslosphinx no longer compatible. All
projects should now be using openstackdocstheme and there are no plans to
update oslosphinx to work with the new Sphinx version.

The following will need to be merged to get these jobs working again.

openstack/masakari

    https://review.openstack.org/651516

openstack/masakari-monitors

    https://review.openstack.org/651518


Thanks!
Sean

----- Forwarded message from zuul at openstack.org -----

Date: Wed, 10 Apr 2019 12:20:14 +0000
From: zuul at openstack.org
To: release-job-failures at lists.openstack.org
Subject: [Release-job-failures] Tag of openstack/masakari failed
Reply-To: openstack-discuss at lists.openstack.org

Build failed.

- publish-openstack-releasenotes-python3 http://logs.openstack.org/31/3191a411fb823913ddfed43e9c44d4e163992ebb/tag/publish-openstack-releasenotes-python3/66005d9/ : FAILURE in 4m 38s

_______________________________________________
Release-job-failures mailing list
Release-job-failures at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

----- End forwarded message -----


From tobias.rydberg at citynetwork.eu  Wed Apr 10 14:17:22 2019
From: tobias.rydberg at citynetwork.eu (Tobias Rydberg)
Date: Wed, 10 Apr 2019 16:17:22 +0200
Subject: [Openstack-sigs][publiccloud-wg] Reminder weekly meeting Public Cloud
 WG
Message-ID: <6fb6919a-ab11-14bd-68bd-1151eca2f026@citynetwork.eu>

Hi everyone,

Time for a new meeting for the Public Cloud WG - tomorrow (11th) 1400 
UTC in #openstack-publiccloud! Agenda can be found below and at 
https://etherpad.openstack.org/p/publiccloud-wg

Agenda
1. Expose WGs and SIGs
2. Migrating to SIG
3. Planning Summit and PTG
- Meeting room at the PTG - Thursday morning
- Update status / content in https://launchpad.net/openstack-publiccloud-wg
- Select most important
4. Other topics

Talk to you tomorrow!

Cheers,
Tobias

-- 
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED



From dangtrinhnt at gmail.com  Wed Apr 10 14:21:43 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Wed, 10 Apr 2019 23:21:43 +0900
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CAN2nDNsPLSif6hDiSr1AD_Rxn9X7aAQdKKg8Y_+ZEg+ybaOPeQ@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
 <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>
 <CAN2nDNsPLSif6hDiSr1AD_Rxn9X7aAQdKKg8Y_+ZEg+ybaOPeQ@mail.gmail.com>
Message-ID: <CADJ6S4F5QgRYKFT=Jm3=wFDnLiLCX6Bkp2axc3uPuwhWpsVTbg@mail.gmail.com>

Hi Rong Zhu and team,

I would expect the person would be more active on the mailing or IRC for
better communication. Since my timezone and yours is only 1h apart, there's
no problem I guess.

Yours,


On Wed, Apr 10, 2019 at 6:36 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Oh, you are right, Since I have already sent it this time, he will not
> repeat send. Next he will reply himself.
>
>
> Regards,
> Rong Zhu
>
>
>
> Lingxian Kong <anlin.kong at gmail.com>于2019年4月10日 周三17:07写道：
>
>> On Wed, Apr 10, 2019 at 7:19 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to introduce Shaoman Zhang, He is the team leader of our
>>> company's(ZTE) ceilometer team, He is experienced in performance statistics
>>> and very proficient in ceilometer.
>>> We would happen to support telemetry community and I think Shaoman Zhang
>>> can be the core member of the telemetry projects.
>>> Shaoman also have some commits and reviews in ceilometer[0], although
>>> there are not too much, but it can prove something.
>>>
>>> Thanks for your consideration.
>>>
>>
>> It'd be better if he could propose himself.
>>
>> ---
>> Cheers,
>> Lingxian Kong
>> Catalyst Cloud
>>
>>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/cac084cc/attachment.html>

From openstack at fried.cc  Wed Apr 10 14:31:13 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 09:31:13 -0500
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <1554889000.14045.11@smtp.office365.com>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
Message-ID: <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>

> It is on my TODO list to create a story for it in placement and move 
> the spec to the placement repo. I don't know when I will reach this 
> item on my list, sorry.

I was getting ready to volunteer (again) to help move the ball on this
because it's really important that we get this done.

But then I started thinking, is it really? The workarounds we have in
the client-side code right now are pretty sucky, but they work. The
effort of $subject is an optimization and suck-reducer, but is it
crucial? Probably not. Though I would like to hear from Cyborg before we
decide we can live without it for Train.

> When I move the spec I can add the open questions from the nova spec 
> review to the placement spec directly to help continuity. Is that OK?

WFM.

> Pinging Cyborg folks. Does Cyborg needs something similar?

I know for sure this is a yes (somewhere around [6]?), but I won't be
able to express the details as well as Sundar.

> I can own the first alternative in the spec [3].

I'll champion the one I described in the third comment at [4], where we
add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
because it's per "allocations" rather than per "allocations.$rp". That
said, both of these options:

- Provide the same information: which request groups got satisfied by
which providers [5].
- Violate the "black box" principle and require one side or the other to
work around it (either client removes or placement ignores the new key
on PUT /allocations). As I said further down in [4], I don't care about
that. (Ed?)
- Maintain the existing levels of hierarchy for the existing elements,
which Chris explained was important (see bottom five comments at [4]).
- Don't require correlation by list index, which was the only thing I
was a hard -1 on.

So if anyone has a strong preference for [3], I'm not going to fight hard.

efried

> [3] 
> https://review.openstack.org/#/c/597601/1/specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst at 323
[4]
https://review.openstack.org/#/c/597601/1/specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst at 447
[5] Note that they also both *don't* provide information about which
*resource* satisfied which request group. E.g. this spec doesn't help us
with the "multiple disks" problem:
resources1=DISK_GB:50&resources2=DISK_GB:25&group_policy=none may result
in one RP providing DISK_GB:75, request_groups=[resources1,resources2].
I'm assuming we don't care (yet).
[6] https://review.openstack.org/#/c/631244/


From openstack at fried.cc  Wed Apr 10 14:42:15 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 09:42:15 -0500
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.21.1904101125270.10085@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <alpine.OSX.2.21.1904091502510.93787@cdent-a01.vmware.com>
 <e1cd0776-77cf-14a2-81dd-b6c750ffa553@gmail.com>
 <alpine.OSX.2.21.1904101125270.10085@cdent-a01.vmware.com>
Message-ID: <497235e3-de6d-0b12-6921-ef241538f508@fried.cc>

I don't really have my brain around the motivators and use cases for
this topic, but at a surface level, I thought this deserved to be
crystallized:

>> I'd prefer to have the data model express the explicit nature of a 1:1
>> relationship. It's simpler and easier to reason about.

We already have ways (plural deliberate) to express non-1:1
relationships. If there's a use case that gets easier with a 1:1
mechanism, let's make one. If quantum things happen, and 1:1 is no good,
we can always use one of the non-1:1 mechanisms. Or a spoon.

efried
.



From balazs.gibizer at ericsson.com  Wed Apr 10 14:54:03 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Wed, 10 Apr 2019 14:54:03 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
Message-ID: <1554908040.15038.0@smtp.office365.com>



On Wed, Apr 10, 2019 at 3:38 PM, Eric Fried <openstack at fried.cc> wrote:
>>  Since providers can be nested a provider can be a strucutral 
>> element in
>>  a nested tree without providing resources.
> 
> This.
> 
> I wouldn't get too hung up on "a resource provider that doesn't 
> provide
> resources". "Resource provider" is just a name of a thing. It doesn't
> (can't) exhaustively define what the thing is and does.
> 
>>  To avoid the trait on an empty RP problem in this case all
>>  the traits are added to the device RPs even if some of the traits
>>  (CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP.
> 
> Noting that I have at best a cursory understanding of all things
> network, this seems okay to me; I can get my brain around a "network
> device" having a "VNIC type" trait. However...
> 
>>  I think the possible solution to move the trait down to the RP that
>>  provides the resources that has a capability described by the trait
> 
> In Matt's patch, the traits represent capabilities of the virt 
> driver. I
> *suppose* you could argue to attach traits like
> COMPUTE_NET_ATTACH_INTERFACE to providers of network resources, or
> COMPUTE_VOLUME_EXTEND to providers of disk resources (even those are
> pretty awkward). But where would you put COMPUTE_TRUSTED_CERTS? And
> let's please not contrive non-resource resources to satisfy
> architectural purity.

Good point. I agree that the COMPUTE_TRUSTED_CERTS logically belong to
the root RP of the compute node.
So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA requires 
placement to support traits on RPs that are not providing resources. 
Will in this case VCPU and MEMORY_MB always requested in the unnumbered 
group still? Or there are cases when those resources are requested in a 
numbered group? If the alter then we have a use case to support request 
groups in a_c query that only requires a trait COMPUTE_TRUSTED_CERTS 
but does not require any resoruces.


>>  I think this work should be driven by a specific need, like the NUMA
>>  modelling in placement by nova. What is the timeline of NUMA 
>> modelling
>>  in placement?
> 
> Proposes NUMA topology with RPs: https://review.openstack.org/552924
> Proposes NUMA affinity for vGPUs: https://review.openstack.org/650963
> Spec: Allocation Candidates: Subtree Affinity:
> https://review.openstack.org/650476
> 
> and a bunch of the other specs in flight are affected by NUMA 
> modeling.
> 
> We've been building up to this for years. If it doesn't happen in 
> Train,
> it'll happen in U. While I agree we shouldn't solve a problem until 
> it's
> a problem, I also don't want to another situation like reshaper, where
> suddenly at the end of the cycle we realize/remember this nontrivial
> thing we need to handle.

I don't want to delay the developement of this feature. I would like to 
see that we implement a certain feature in placement because it is 
needed for specific use case for a specific consumer of placement. So 
if the above discovered use case (COMPUTE_TRUSTED_CERTS + NUMA) are 
valid then I have no problem adding the necessary changes to placement 
to make this use case doable in nova.

Cheers,
gibi

> 
> efried
> .
> 



From mriedemos at gmail.com  Wed Apr 10 14:55:07 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 10 Apr 2019 09:55:07 -0500
Subject: [nova] "future" specs and blueprints
In-Reply-To: <f73d0540-0274-4f11-d5bb-8f53ab6ff7c6@fried.cc>
References: <e4489e3e-28c1-a635-e383-01c383292040@fried.cc>
 <CAJCXu8c-o1LxaocAsk=GrZBb_caPTUi4pVWuv_Fy89bEqpG0nw@mail.gmail.com>
 <ddf968c5-48cc-db3d-4757-3a8ac663f213@fried.cc>
 <1553766105.28590.1@smtp.office365.com>
 <6a726943-18f9-2b7f-e83a-0855d1d53800@gmail.com>
 <m2d0ma26pi.fsf@caffeine.hv.danplanet.com>
 <f73d0540-0274-4f11-d5bb-8f53ab6ff7c6@fried.cc>
Message-ID: <039e6dfd-57c9-62f8-e245-13b453167394@gmail.com>

On 4/1/2019 1:13 PM, Eric Fried wrote:
> To that end, I have proposed a patch [1] with some tooling and
> documentation. If you do nothing else, please read the (updated) section
> on "Backlog specifications" [2] and the (new) section on "Abandoning a
> specification" [3].
> 
> I have also eaten my own dogfood and proposed patches to abandon the
> four existing backlog specs [4]. I added those specs' original authors
> and assignees as reviewers (fwiw; some are surely inactive at this point).
> 
> One of those had a Train spec that sounds eerily similar [5] so I
> suggested "move-spec" there.
> 
> There's also a Train spec the author told me was intended for "future"
> [6] so I suggested that be moved to the backlog directory.
> 
> I ask for help from nova-core to review and merge the tooling (including
> Mel's blueprint counting utility [7] which has been ready for a while)
> and the scrub patches.
> 
> Moving forward, hopefully we can make it a recurring agenda item at PTGs
> to review backlog specs and promote, defer, or abandon them as appropriate.

Just an update for other cores but I'm holding a +W on the bottom change 
in this series now [1] but will probably only wait until Friday (April 
12) before approving.

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

-- 

Thanks,

Matt


From e0ne at e0ne.info  Wed Apr 10 14:58:28 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Wed, 10 Apr 2019 17:58:28 +0300
Subject: [horizon] Proposing Vishal Manchanda (vishalmanchanda) for core
In-Reply-To: <CAGocpaGn5B+VbPc6=OF4V+mG+8V0M-i6AgoVcubnOvV7YcLbLQ@mail.gmail.com>
References: <CAGocpaGn5B+VbPc6=OF4V+mG+8V0M-i6AgoVcubnOvV7YcLbLQ@mail.gmail.com>
Message-ID: <CAGocpaGthR7-RtcZ6w3hn9JeqbOgO298Ncoxz0DOnsyN3HbRMQ@mail.gmail.com>

Hi all,

I received good feedback, so I've added Vishal Manchanda to the
horizon-core team.

Welcome to the team, Vishal!

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


On Wed, Apr 3, 2019 at 3:54 PM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> Hi everybody,
>
> I would like to propose adding vishalmanchanda to the horizon-core team.
>
> Vishal did a great contribution during the last six months both with
> commits [1]  and reviews [2],[3].
>
> He fixed a lot of bugs not only in a master branch but in stable branches
> too. Regular quality reviews during the last cycles show that he's on the
> same page with the rest of the team and understands the code base well too.
>
> If there are no objections, I'll add Vishal to the horizon-core team in a
> week.
>
> [1]
> https://review.openstack.org/#/q/owner:manchandavishal143%2540gmail.com+status:merged+project:openstack/horizon
> [2] https://www.stackalytics.com/report/contribution/horizon-group/90
> [3] https://www.stackalytics.com/report/contribution/horizon-group/180
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/620cd755/attachment.html>

From sean.mcginnis at gmx.com  Wed Apr 10 14:59:08 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 10 Apr 2019 09:59:08 -0500
Subject: OpenStack Stein is officially released!
Message-ID: <20190410145908.GC20373@sm-workstation>

The official OpenStack Stein release announcement has been sent out:

http://lists.openstack.org/pipermail/openstack-announce/2019-April/002019.html

Thanks to all who were part of making the stein series a success. Really great
to see how much the community was able to accomplish over this last cycle.

This marks the official opening of the releases repo for Train. Stein is now a
full stable branch.

Thanks!
Sean


From jasonanderson at uchicago.edu  Wed Apr 10 15:24:19 2019
From: jasonanderson at uchicago.edu (Jason Anderson)
Date: Wed, 10 Apr 2019 15:24:19 +0000
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>,
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
Message-ID: <DM6PR11MB3180EF7CAB85C01517AF49C2CA2E0@DM6PR11MB3180.namprd11.prod.outlook.com>


On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
> On 4/9/19 7:20 PM, Jay Pipes wrote:
>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>>>  From ironic perspective there is no issue, but there is a critical
>>> question to decide: when Ironic+Placement is used, which of them acts
>>> as the final authority? If Ironic, then we need to teach Placement to
>>> talk to its Allocation API when allocating a bare metal node. If
>>> Placement, then we need to support Allocation API talking to
>>> Placement. I suspect the latter is saner, but I'd like to hear more
>>> opinions.
>>
>> Ironic (scheduler?) would request candidates from the placement
>> service using the GET /allocation_candidates API. Ironic (scheduler?)
>> would then claim the resources on a provider (a baremetal node) by
>> calling the POST /allocations API.
>
> Okay, this matches my expectation.
>
> My concern will be with Blazar and reservations. If reservations happen
> through Placement only, how will ironic know about them? I guess we need
> to teach Blazar to talk to Ironic, which in turn will talk to Placement.

Hmm. So, here's the problem: placement has no concept of time. [1]

Placement only knows about one period of time: now. Placement doesn't
have any concept of an allocation or an inventory existing at some point
in the future or in the past.

Just to play devil's advocate... what about changing/adding this? What if Placement did support an inventory having different states depending on time frame requested? In my mind this would enable a more ideal division of responsibility:

  *   Placement manages the availability of resources and maintains the single source of truth for inventory at a given time.
  *   Blazar uses Placement as its default inventory backend. Blazar's main role now is business logic around quota and handling allocation/deallocation when a lease starts/ends.
     *   But, Blazar could optionally use a different inventory backend, to allow standalone use (?)
  *   Ironic uses Placement as its default inventory backend.
     *   But, Ironic could optionally also manage its own inventory, to allow standalone use (?)

To further tease out the relationships here, we should think about what makes the most sense for baremetal reservations done via Blazar. Should Blazar always go to Ironic for this, ignoring Nova entirely? Or should it go through Nova if Nova is being used? I believe Blazar still will always have to go through Nova for instance reservations at minimum.

Keep in mind that Blazar is designed to integrate with arbitrary external services; currently it has integrations with Neutron (for provisioning Floating IPs as part of a lease), and it could support any number of other resources, like bandwidth on an uplink.

Having learned more about Placement's design as a result of these threads, I'm excited about how it could make some things cleaner if it truly could handle the generic inventory management problem that advanced reservations pose.

Therefore, Blazar must unfortunately keep all of the temporal state
about reservations in its own data store. So, Ironic would actually have
to talk to Blazar to create a reservation of some amount of resources
and Blazar will need to call Placement to manage the state of resource
inventory and allocations over time; as reservations are activated,
Blazar will either create or swap allocation records in Placement to
consume the Ironic resources for a tenant that made the reservation.

Best,
-jay
​
[1] this was a mistake for which I take full responsibility.

Cheers,
/Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/08f79ef8/attachment-0001.html>

From mriedemos at gmail.com  Wed Apr 10 15:30:43 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 10 Apr 2019 10:30:43 -0500
Subject: [nova] Rebuild from cell0 limitation for personality files
Message-ID: <48566834-ccc4-fdcd-b9c0-28671d38042c@gmail.com>

I wanted to get some wider attention on what I think will be a 
limitation in the rebuild from cell0 spec [1]. The main idea in that 
spec is the user tries to create a server which fails during scheduling 
to find a host and puts the instance into ERROR state and "buries" it in 
cell0. With a new microversion, the user can attempt to rebuild the 
server from cell0 and go through scheduling again. This is part of a 
bigger effort to support pre-emptible instances where scheduling fails 
during server create, an external reaper service tries to make room by 
destroying some pre-emptible instances, and then the server gets rebuilt.

The issue I've found is that if the server was created with personality 
files using microversion 2.1, fails, and then the user goes to rebuild 
it, their personality files will be lost because (1) we don't persist 
personality files anywhere, not even the RequestSpec and (2) 
microversion 2.57 deprecated the personality files parameter from the 
rebuild API [2]. Since you'll have to use a newer microversion > 2.57 to 
rebuild from cell0, you can't specify the personality files again.

Are we OK with this? We deprecated personality files for a reason [3] so 
this is a natural extension of that deprecation saying "going forward 
you should not be using these things and if you do there could be 
limitations".

The user has an obvious recourse: delete the server and re-create it 
rather than rebuild from cell0.

I don't want to consider un-deprecating personality files in the rebuild 
API just for this new microversion to rebuild from cell0.

Another alternative is persisting personality files in the RequestSpec 
but I'm not sure how much people would support that - although it would 
fix some other known limitations with personality files, like the fact 
that if you create a server with files and then shelve offload, the 
files are gone when you unshelve. I have a similar issue with cross-cell 
resize [4].

[1] 
https://review.openstack.org/#/c/648686/1/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst at 72
[2] 
https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id52
[3] 
https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/deprecate-file-injection.html
[4] 
https://review.openstack.org/#/c/642807/3/specs/train/approved/cross-cell-resize.rst at 454

-- 

Thanks,

Matt


From openstack at fried.cc  Wed Apr 10 15:37:08 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 10:37:08 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <1554908040.15038.0@smtp.office365.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
Message-ID: <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>

> So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA requires 
> placement to support traits on RPs that are not providing resources. 
> Will in this case VCPU and MEMORY_MB always requested in the unnumbered 
> group still? Or there are cases when those resources are requested in a 
> numbered group?

That'll depend on the outcome of the various NUMA modeling discussions;
but as soon as we need to be able to request resources from more than
one NUMA node, it seems certain that we'll need to use numbered groups.

efried
.


From Kevin.Fox at pnnl.gov  Wed Apr 10 15:45:17 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Wed, 10 Apr 2019 15:45:17 +0000
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <alpine.OSX.2.21.1904101114310.10085@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>,
 <alpine.OSX.2.21.1904101114310.10085@cdent-a01.vmware.com>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C2F06C2@EX10MBOX03.pnnl.gov>

As long as its marked under /examples or something, I think the benefits outweigh the drawbacks. It allows folks that have never been exposed to some of the containerized way of thinking to bump into it and see it in action.

Your concern that examples that come from outside rather then inside is legit, but can be dealt with differently I think. You can have the example in tree, but ask folks outside OpenStack to help validate that its following best practices. Then you get the best of both worlds?

Thanks,
Kevin
________________________________________
From: Chris Dent [cdent+os at anticdent.org]
Sent: Wednesday, April 10, 2019 3:23 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [placement][ptg] Containers/dockerfiles

On Tue, 9 Apr 2019, Monty Taylor wrote:

> I'd be happy to help you get that set up in placement.

Thanks, if we decide to follow through on this that would be
awesome. And thanks for all the info which I will integrate back
into the summaries when the time comes.

Part of the question surrounding this is whether we want to take on
the responsibility of "owning" container concepts within placement
itself. Unless we wrap it in a bunch of "example" and "there's more
than one way to do it" warnings people have demonstrated a tendency
to take things as gospel (look at the damage some of the ways
devstack managed web services spread around the OpenStack world).

While I'm fairly confident that my little container works well for
me, I'm hoping we can reach some consensus on whether we, the
placement team, want to own such a thing.

I'm tending towards thinking that we should because the potential
educational value outweighs the vague concerns I'm not really able
to enumerate (but the last paragraph below captures, a bit).

As a mostly greenfield development, Placement doesn't have a lot of
legacy weight so it tends to be able to demo:

* good microversion handling
* good http dispatch
* good WSGI app hosting techniques
* minimal config
* good mini-container hygiene

and probably some other things too. There are probably some useful
techniques to pick up there.

On the other hand, there was probably a time when Nova thought it
has some good techniques to pick up and then everyone copied them
and now there is regret. So it might be better that people look for
examples outside of OpenStack, not within, where things tend to move
slowly.

--
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dms at danplanet.com  Wed Apr 10 16:07:14 2019
From: dms at danplanet.com (Dan Smith)
Date: Wed, 10 Apr 2019 09:07:14 -0700
Subject: [nova] Rebuild from cell0 limitation for personality files
In-Reply-To: <48566834-ccc4-fdcd-b9c0-28671d38042c@gmail.com> (Matt
 Riedemann's message of "Wed, 10 Apr 2019 10:30:43 -0500")
References: <48566834-ccc4-fdcd-b9c0-28671d38042c@gmail.com>
Message-ID: <m21s2926a5.fsf@caffeine.hv.danplanet.com>

> I wanted to get some wider attention on what I think will be a
> limitation in the rebuild from cell0 spec [1]. The main idea in that
> spec is the user tries to create a server which fails during
> scheduling to find a host and puts the instance into ERROR state and
> "buries" it in cell0. With a new microversion, the user can attempt to
> rebuild the server from cell0 and go through scheduling again. This is
> part of a bigger effort to support pre-emptible instances where
> scheduling fails during server create, an external reaper service
> tries to make room by destroying some pre-emptible instances, and then
> the server gets rebuilt.
>
> The issue I've found is that if the server was created with
> personality files using microversion 2.1, fails, and then the user
> goes to rebuild it, their personality files will be lost because (1)
> we don't persist personality files anywhere, not even the RequestSpec
> and (2) microversion 2.57 deprecated the personality files parameter
> from the rebuild API [2]. Since you'll have to use a newer
> microversion > 2.57 to rebuild from cell0, you can't specify the
> personality files again.
>
> Are we OK with this? We deprecated personality files for a reason [3]
> so this is a natural extension of that deprecation saying "going
> forward you should not be using these things and if you do there could
> be limitations".

This is the nature of per-request versions I think, so I'm okay with
it. It's not ideal, but there's not a whole lot that can be done about
it.

> The user has an obvious recourse: delete the server and re-create it
> rather than rebuild from cell0.
>
> I don't want to consider un-deprecating personality files in the
> rebuild API just for this new microversion to rebuild from cell0.

Definitely not.

> Another alternative is persisting personality files in the RequestSpec
> but I'm not sure how much people would support that - although it
> would fix some other known limitations with personality files, like
> the fact that if you create a server with files and then shelve
> offload, the files are gone when you unshelve. I have a similar issue
> with cross-cell resize [4].

I'd definitely prefer we not do that.

Another alternative would be to chuck something into system_metadata for
the instance that says "this was created with personality files". We
could use that for the rebuild-from-cell0 operation, or any other future
one that can't honor those files and just fail the request. "Sorry bro,
this instance was created in a way that can't support this request."

--Dan


From ed at leafe.com  Wed Apr 10 16:27:09 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 11:27:09 -0500
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
Message-ID: <AC465A65-34F5-4133-9C45-E74C6A4FEEB6@leafe.com>

On Apr 9, 2019, at 8:00 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> * Last PTG for Stein, we decided the following policies and have done so in Stein
> 
>    A) Aggregate on root spans whole tree for ``members_of=``
>       requests in 'GET /allocation_candidates'
>    B) This spanning policy doesn't apply to granular requests
>       ``members_of<N>=`` or to requests in 'GET /resource_providers'
>    C) This change is a bug fix without microversion
> 
>  However, I now feel the policy B is weird. Consider a case where
>  only granular requests are used in the request. If operator puts
>  aggA on root, aggA applies the child or not depends on cases how
>  you created the request. That's very difficult for operators to
>  debug...

It seems that a lot of the other efforts around trees have the goal of keeping trees and subtrees more integral, rather than separate pieces. Given that, it would make sense that if the root is in an aggregate, the entire tree is in the agg.

I'm trying to remember why we decided on policy B, but my brain is failing me. 


-- Ed Leafe







From thierry at openstack.org  Wed Apr 10 16:32:07 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 10 Apr 2019 18:32:07 +0200
Subject: OpenStack Stein is officially released!
In-Reply-To: <20190410145908.GC20373@sm-workstation>
References: <20190410145908.GC20373@sm-workstation>
Message-ID: <973d695f-1a23-d59a-1624-789abeef631f@openstack.org>

Sean McGinnis wrote:
> The official OpenStack Stein release announcement has been sent out:
> 
> http://lists.openstack.org/pipermail/openstack-announce/2019-April/002019.html
> 
> Thanks to all who were part of making the stein series a success. Really great
> to see how much the community was able to accomplish over this last cycle.
> 
> This marks the official opening of the releases repo for Train. Stein is now a
> full stable branch.

Congrats to everyone!

It may have felt like a calm cycle, but we still merged 155 changes per 
day on average during this cycle, which is exceptional, even compared to 
the hyped projects out there. (Thanks to Zuul for making that crazy 
velocity possible while still enforcing strict gating !)

So take a moment to step back, contemplate all you've done and celebrate.

-- 
Thierry


From ed at leafe.com  Wed Apr 10 16:46:15 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 11:46:15 -0500
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
Message-ID: <DF3E4736-AF29-49F7-A10B-567A07742710@leafe.com>

On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred at inaugust.com> wrote:
> 
>> Another suggestion has been to use a web-hook or similar from zuul
>> to trigger an image build (either at docker hub or some other
>> registry) post-merge.
> 
> We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate.

My concern is the one-offness of placedock, not that it wouldn't work. But if Zuul can support this container building step, and we ensure that placedock follows the pattern that Zuul uses, we should be good.

-- Ed Leafe







From ed at leafe.com  Wed Apr 10 16:51:50 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 11:51:50 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
Message-ID: <63118B69-94C6-41D0-9DEE-9ED331DBBD25@leafe.com>

On Apr 9, 2019, at 12:22 PM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
>        * (My brain hurts from the concept for a provider that
>          provides nothing. Perhaps it provides something we aren't
>          remembering to count?)

This was a big bone of contention back when Traits were first being discussed: they can only be applied to RPs. So if you had a single physical PCI device that provided virtual functions, and some of those VFs were, say, private net and the others were public, you had to create intermediary RPs between the PCI RP and the VFs so that you could tag those RPs with the correct trait to distinguish them.

That brain hurt is very much why I argued against this restriction back then. But it's what we ended up with, so those "virtual" RPs are with us for good. If it helps, think of them as not providing resources, but providing other resource providers. 

Does that hurt a little less?


-- Ed Leafe







From tetsuro.nakamura.bc at hco.ntt.co.jp  Wed Apr 10 09:18:06 2019
From: tetsuro.nakamura.bc at hco.ntt.co.jp (Tetsuro Nakamura)
Date: Wed, 10 Apr 2019 18:18:06 +0900
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
Message-ID: <13b84c44-1ddf-39cf-913c-acc9d7708a7e@hco.ntt.co.jp>

 >      A) Aggregate on root spans whole tree for ``members_of=``
 >         requests in 'GET /allocation_candidates'
 >      B) This spanning policy doesn't apply to granular requests
 >         ``members_of<N>=`` or to requests in 'GET /resource_providers'
 >      C) This change is a bug fix without microversion

For example, let's say two non-root NUMA RPs have the resources.

In this case, if the root compute node RP is in aggA, aggA applies to 
the NUMA nodes *IF* a user requests only 1 NUMA node via the 
non-granular request while aggA does *NOT* apply to NUMA nodes when a 
user wants for example two separate NUMA nodes using only granular requests.

Setup
-----

* Add compute1 in aggA by putting aggA on the root RP of compute1

* compute A has two NUMA nodes and each NUMA RP has 4 VCPUs

Actual
------

* GET /allocation_candidates?resources=VCPU:2&member_of=<aggA>
-> returns 2 allocation requests of each numa node of the compute1
    since placement thinks that the NUMA nodes are in aggA

* GET 
/allocation_candidates?resources1=VCPU:1&member_of1=<aggA>&resources2=VCPU:1&member_of2=<aggA>
-> returns nothing since it is granular request so placement thinks
    that the NUMA nodes are not in aggA

Expected
--------

The latter should return 1 allocation request on compute1 which contains 
one allocation to one NUMA node and the other allocation to the other 
NUMA node.

In other words, whether an RP is in the aggregate or not must NOT rely 
on how user searches it, IMO. The aggregate is not dynamic thing.

We'd like to be able to answer to the question "Is it in agg A?" simply 
without any request info.

"Is it in aggA?"
"Well, that depends on how you ask that.
  non-granularly speaking, it is in aggA,
  but granularly speaking, it is not in aggA"

...would be too difficult.

Resource provider is not a Schrödinger's cat.

On 2019/04/09 22:00, Chris Dent wrote:
> 
>> From the etherpad [1]:
> 
> * Last PTG for Stein, we decided the following policies and have done so 
> in Stein
> 
>      A) Aggregate on root spans whole tree for ``members_of=``
>         requests in 'GET /allocation_candidates'
>      B) This spanning policy doesn't apply to granular requests
>         ``members_of<N>=`` or to requests in 'GET /resource_providers'
>      C) This change is a bug fix without microversion
> 
>    However, I now feel the policy B is weird. Consider a case where
>    only granular requests are used in the request. If operator puts
>    aggA on root, aggA applies the child or not depends on cases how
>    you created the request. That's very difficult for operators to
>    debug...
> 
> This is from Tetsuro, so perhaps he can add some additional info,
> but basically I think what's being requested here is some discussion
> on whether changing B is warranted.
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 

-- 
Tetsuro Nakamura <tetsuro.nakamura.bc at hco.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan


From jlibosva at redhat.com  Wed Apr 10 12:37:34 2019
From: jlibosva at redhat.com (Jakub Libosvar)
Date: Wed, 10 Apr 2019 14:37:34 +0200
Subject: RuntimeError: OVS transaction timed out - After minor upgrade
In-Reply-To: <CANX8mtJrWQGAiwGa=y19put+gst9WcW_Ya_9aGUAGC4C2abEng@mail.gmail.com>
References: <CANX8mtJrWQGAiwGa=y19put+gst9WcW_Ya_9aGUAGC4C2abEng@mail.gmail.com>
Message-ID: <e1656593-df71-53cb-bb55-0aab7fbcf963@redhat.com>

Is your ovs-vswitchd process running on controllers? Sounds like agent
can talk to ovsdb (it was able to connect) but then times out when
waiting for response from vswitchd process.

Do these command run successfully on the problematic controller?
ovs-vsctl show
ovs-ofctl show br-int

Kuba

On 10/04/2019 14:20, Yedhu Sastri wrote:
> Dear All,
> 
> We did a minor upgrade on our OpenStack environment Newton HA cluster from
> 14.2.12 to 14.2.16 using the following link.
> 
> https://docs.openstack.org/openstack-ansible/newton/upgrade-guide/minor-upgrade.html
> 
> The upgrade was successful and we tested creation of VM's and it was also
> successful we were able to ssh into the VM's.
> 
> Then we rebooted the controllers one by one. But after that we can create
> the VM's but it is not getting IP from dhcp agent.
> 
> In the openvswitch-agent.log we are getting 'OVS transaction timeout'. Any
> help is much appreciated.
> 
> 2019-04-09 17:25:29.063 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> net_uuid None not managed by VLAN manager
> 2019-04-09 17:25:29.088 3504 INFO neutron.agent.common.ovs_lib
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> 04275c8a-2d12-477b-b435-f6483d418e93 not present in bridge br-int
> 2019-04-09 17:25:29.089 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> net_uuid None not managed by VLAN manager
> 2019-04-09 17:25:29.198 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> net_uuid None not managed by VLAN manager
> 2019-04-09 17:25:29.228 3504 INFO neutron.agent.common.ovs_lib
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> 5c25b580-9dcb-4930-a2fe-9cab951114dd not present in bridge br-int
> 2019-04-09 17:25:29.228 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> net_uuid None not managed by VLAN manager
> 2019-04-09 17:25:29.229 3504 INFO neutron.agent.securitygroups_rpc
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Remove device filter
> for [u'63cb0c6a-6e82-41a8-ad46-511ee84579ad',
> u'9764e98a-bb32-4d37-9460-5a546f351e5a',
> u'2c075f29-156c-4787-b40f-434c437164e4',
> u'f00de46f-301a-4789-add1-a8239ee6c859',
> u'e26c1806-8041-4ce2-aea0-74ca469add67',
> u'9fa17447-d25d-441b-9983-b81e43c6e6d2',
> u'3ef24ce6-19b5-47c8-9510-767e64d33e9f',
> u'c2d37add-65a0-4fc9-914c-2382af70b1ca',
> u'a8b7c7aa-a5d0-47b3-a944-7b6c4428eda8',
> u'bf6f7608-0573-43f7-822a-878d7708d985',
> u'046670cd-77dd-4ce8-bb4b-f1489264375b',
> u'b7aefa18-d768-47a8-bb5f-6b1e838deaeb',
> u'04275c8a-2d12-477b-b435-f6483d418e93',
> u'124eb5e6-2b8a-44a9-aa8b-f6d9bc87f13f',
> u'5c25b580-9dcb-4930-a2fe-9cab951114dd']
> 2019-04-09 17:27:09.740 3504 INFO neutron.agent.securitygroups_rpc
> [req-5984df4b-c30f-403c-8e87-86c4ccf50a9f - - - - -] Provider rule updated
> 2019-04-09 17:27:41.961 3504 INFO neutron.agent.securitygroups_rpc
> [req-67c36a44-f778-48f0-b7ae-0a5244ff95c1 - - - - -] Provider rule updated
> 2019-04-09 17:28:28.334 3504 INFO neutron.agent.securitygroups_rpc
> [req-aeffc24f-a354-412e-b458-950c1d4b52ef - - - - -] Provider rule updated
> 2019-04-09 17:28:46.276 3504 INFO neutron.agent.securitygroups_rpc
> [req-2dd51325-40c4-4ff0-a384-bccbe3ca0bfc - - - - -] Provider rule updated
> 2019-04-09 17:28:46.278 3504 INFO neutron.agent.securitygroups_rpc
> [req-6d48bfd9-0230-4a82-a477-d9e4171db519 - - - - -] Provider rule updated
> 2019-04-09 17:30:32.695 3504 INFO neutron.agent.securitygroups_rpc
> [req-01b9b7a8-84a4-42cc-aebb-db846eb2b8f0 - - - - -] Provider rule updated
> 2019-04-09 17:30:54.288 3504 INFO neutron.agent.securitygroups_rpc
> [req-de1755bd-0e21-4b75-9fde-db422ee9a79a - - - - -] Provider rule updated
> 2019-04-09 17:32:12.377 3504 INFO neutron.agent.securitygroups_rpc
> [req-26bc4547-edb7-4092-b4f4-6465c29dfbe4 - - - - -] Provider rule updated
> 2019-04-09 17:32:21.444 3504 WARNING
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Device
> 0d535260-dd98-4027-a2ba-4c5412d4eab0 not defined on plugin or binding failed
> 2019-04-09 17:32:21.461 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> d3baa557-a367-4a6d-8d58-7183df4243a6 updated. Details: {u'profile': {},
> u'network_qos_policy_id': None, u'qos_policy_id': None,
> u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> u'680c9bdd-9cea-4059-8c8c-2928dd0ee48f', u'segmentation_id': 65606,
> u'device_owner': u'network:router_ha_interface', u'physical_network': None,
> u'mac_address': u'fa:16:3e:b3:9a:60', u'device':
> u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'port_security_enabled': False,
> u'port_id': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'fixed_ips':
> [{u'subnet_id': u'5b49f8e5-991d-4ecd-a584-df605063aecb', u'ip_address':
> u'169.254.192.9'}], u'network_type': u'vxlan'}
> 2019-04-09 17:32:21.461 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 1 as local
> vlan for net-id=680c9bdd-9cea-4059-8c8c-2928dd0ee48f
> 2019-04-09 17:32:35.477 3504 INFO oslo_messaging._drivers.amqpdriver [-] No
> calling threads waiting for msg_id : a9314d944ff8486abf909d4cc271f9a0
> 2019-04-09 17:32:39.016 3504 INFO neutron.agent.securitygroups_rpc
> [req-51453b2c-b454-45bd-b7f8-c78560437016 - - - - -] Provider rule updated
> 2019-04-09 17:32:54.141 3504 ERROR
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Switch connection
> timeout
> 2019-04-09 17:32:57.964 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Bridge br-tun changed
> its datapath-ID from 6a740a5da349 to 00006a740a5da349
> 2019-04-09 17:32:58.015 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> 0d8dc3c9-c115-45f8-bbb2-cc715b7c1079 updated. Details: {u'profile': {},
> u'network_qos_policy_id': None, u'qos_policy_id': None,
> u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
> u'device_owner': u'network:router_gateway', u'physical_network':
> u'outbound1', u'mac_address': u'fa:16:3e:aa:d7:56', u'device':
> u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'port_security_enabled': False,
> u'port_id': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'fixed_ips':
> [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
> u'10.97.179.34'}], u'network_type': u'vlan'}
> 2019-04-09 17:32:58.016 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 2 as local
> vlan for net-id=4ffb2c28-f9f1-4a25-82a0-df7f7a002434
> 2019-04-09 17:32:58.030 3504 INFO
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> 1239fa6c-265a-4f16-ab00-c86fe40545d9 updated. Details: {u'profile': {},
> u'network_qos_policy_id': None, u'qos_policy_id': None,
> u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
> u'device_owner': u'network:router_gateway', u'physical_network':
> u'outbound1', u'mac_address': u'fa:16:3e:4d:73:46', u'device':
> u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'port_security_enabled': False,
> u'port_id': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'fixed_ips':
> [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
> u'10.97.179.99'}], u'network_type': u'vlan'}
> 2019-04-09 17:33:13.289 3504 ERROR neutron.agent.ovsdb.impl_idl
> [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Traceback (most recent
> call last):
>   File
> "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/native/connection.py",
> line 117, in run
>     txn.results.put(txn.do_commit())
>   File
> "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py",
> line 91, in do_commit
>     raise RuntimeError(_("OVS transaction timed out"))
> RuntimeError: OVS transaction timed out
> 
> 
> 



From navdeep.uniyal at bristol.ac.uk  Wed Apr 10 15:22:07 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Wed, 10 Apr 2019 15:22:07 +0000
Subject: [Zun] Heat and Horizon Support
Message-ID: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear All,

I would like to integrate my Zun deployment (OS Rocky) with Heat and Horizon.
For horizon, I used the instructions given in https://docs.openstack.org/zun-ui/rocky/install/index.html

However, while adding the files to /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled
Using : cp zun_ui/enabled/* /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled

My openstack UI is breaking down :
[cid:image001.jpg at 01D4EFB9.89E6F5B0]

Please advise.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/30614326/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 56313 bytes
Desc: image001.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/30614326/attachment-0001.jpg>

From juliaashleykreger at gmail.com  Wed Apr 10 17:38:49 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 10 Apr 2019 10:38:49 -0700
Subject: [ironic][ptg] Schedule/Team gathering
Message-ID: <CAF7gwdjhcDLzkrobA1-=0QrD5Prz_xd24M61SR8wAC69_mdXMQ@mail.gmail.com>

Greetings fellow ?Ironicans?

I've posted a new etherpad[0] based upon our discussion in the
planning etherpad[1]. Please review and if there are any scheduling
issues please let me know.

Also, we need to figure out an evening for a team gathering. I've
posted a doodle[3]. Please submit it with-in the next few days and
I'll begin looking around for someplace that might work.

Thanks everyone!

-Julia
[0]: https://etherpad.openstack.org/p/DEN-train-ironic-ptg
[1]: https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
[2]: https://doodle.com/poll/e6q5e6pm72wbiwtz


From kennelson11 at gmail.com  Wed Apr 10 19:39:44 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 10 Apr 2019 12:39:44 -0700
Subject: [PTL][SIG][WG] PTG Team Photos
In-Reply-To: <CAJ6yrQgCCtXBBooYHz_J-QPRx9r=Kop-A8saJWqz9aZzQToPFA@mail.gmail.com>
References: <CAJ6yrQin4fz-=M2wnygEiPyZe5J0XRrikd4Ppnyx45JfVyQLcA@mail.gmail.com>
 <CAJ6yrQgCCtXBBooYHz_J-QPRx9r=Kop-A8saJWqz9aZzQToPFA@mail.gmail.com>
Message-ID: <CAJ6yrQjpErGR_uGvMo4dm6qbBg=G1ydMdxN2F1Q7Q_4oShC_9Q@mail.gmail.com>

Not sure why it didn't dawn on me sooner, but I copied the data into an
ethercalc[1] to make it more friendly (albeit a little uglier) to people
all over the world.

Please use the ethercalc instead of the google sheet. Sorry I didn't think
of it in the first place!

-Kendall (diablo_rojo)

[1] https://ethercalc.openstack.org/3qd1fj5f3tt3

On Tue, Apr 9, 2019 at 10:34 AM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Wanted to bring this to the top of people's inboxes for those interested.
>
> Totally optional, just wanted to make sure everyone saw this :)
>
> -Kendall (diablo_rojo)
>
> On Thu, Mar 28, 2019 at 5:02 PM Kendall Nelson <kennelson11 at gmail.com>
> wrote:
>
>> Hello!
>>
>> If your team is attending the PTG and is interested in having a team
>> photo taken, here is the signup[1]! There are slots Thursday and Friday
>> from 10:00 AM to 4:30 PM.
>>
>> The location is TBD but will likely be close to where registration will
>> be. I'll send an email out the day before with a reminder of your time slot
>> and an exact location.
>>
>> -Kendall (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1DgsRHVWW2YLv7ewfX0M21zWJRf4wUfPG4ff2V5XtaMg/edit?usp=sharing
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/2717a5ed/attachment.html>

From ed at leafe.com  Wed Apr 10 19:50:11 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 14:50:11 -0500
Subject: [placement][ptg] Placement Over The Parapet
In-Reply-To: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
Message-ID: <5D4748AC-0311-43DA-9B4A-522E1A16C9AB@leafe.com>

On Apr 9, 2019, at 12:08 PM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> It's a whole big world out there, people doing all sorts of things
> that maybe look a bit like what placement does. What can we learn
> from them? What can they learn from us? In what ways can we expand
> placement world dominance and improve its ecosystem diversity?

I think we need to establish world dominance before we plot on how to expand it. :)

> We are often so busy in the depths of OpenStack that it is hard to
> remain aware of what is out there. What is?

I've shared this blog post [0] on the etherpad, but perhaps a wider audience might find it interesting. It caught my eye because last year in Dublin as we started to dig deeper into nested resource providers, the way things fit together reminded me of some of the things I had played around with when I looked into graph databases. I ran a series of experiments that I wrote about in my blog (series beginning with [1]), and am seriously thinking about digging deeper before we get too far down the nested rabbit hole. Even though the blog post was dealing with tracking security groups, it was reassuring to find someone else who also saw cloud resource management as being best modeled as a graph.

So maybe this response isn't what you were looking for (how can we integrate Placement into the wilds of the non-OpenStack world?), but rather how can we integrate some of the lessons of the non-OpenStack world into Placement?


[0] https://cloudbootup.com/post/cloud-management-with-prolog.html
[1] https://blog.leafe.com/hammer-and-nail/

-- Ed Leafe







From ed at leafe.com  Wed Apr 10 19:57:50 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 14:57:50 -0500
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <63b000c3-9237-0c57-65a3-5c028d609875@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <alpine.OSX.2.21.1904091445250.93787@cdent-a01.vmware.com>
 <63b000c3-9237-0c57-65a3-5c028d609875@gmail.com>
Message-ID: <94C5B11F-0090-4D0A-B7F1-4FC8D6E3E916@leafe.com>

On Apr 10, 2019, at 4:41 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> I suppose what you're trying to determine is whether there is a viable use case for answering the question "given a single 'source partition' -- say, "my compute cloud region A" -- show me the usage of VCPU resources in my 'nova' compute hosts and my 'non-nova' compute hosts".
> 
> I'm just not sure there's a viable use case there.

I was thinking more of the use case where there are several systems (novas) creating resource providers in a single placement service, and one of the novas asks for resources for an instance. We would need something equivalent to a per-nova aggregate so that placement doesn't return RPs from one of the other novas. Of course, requiring an agg to be manually set would not be practical, so some sort of automatic sharding identifier would be required.

I have no idea how to do this best, or even if this is a use case we want to be able to entertain. It might be sufficient to just say that separate systems that don't share resources should have their own placement.

-- Ed Leafe







From jeremyfreudberg at gmail.com  Wed Apr 10 20:10:33 2019
From: jeremyfreudberg at gmail.com (Jeremy Freudberg)
Date: Wed, 10 Apr 2019 16:10:33 -0400
Subject: [sahara][ptg] Preliminary poll for scheduling Sahara virtual PTG
Message-ID: <CAFntmShsrvG4ROx_vMGngbDW-AQpaL3jruedMoTVtUXhUz1mzg@mail.gmail.com>

Hello Saharans and other interested parties:

For the Train cycle our PTG will only be virtual.
I have assembled here some possible days on which to hold the virtual PTG:
https://doodle.com/poll/228ppwvqg488n3c5

We'll probably meet for about 2 hours on Bluejeans (DESPITE the poll
the showing huge chunks of time). There'll be an Etherpad and outcomes
will be logged to this mailing list too. All are welcome.

Best,
Jeremy


From Kevin.Fox at pnnl.gov  Wed Apr 10 20:11:13 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Wed, 10 Apr 2019 20:11:13 +0000
Subject: [placement][ptg] Placement Over The Parapet
In-Reply-To: <5D4748AC-0311-43DA-9B4A-522E1A16C9AB@leafe.com>
References: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>,
 <5D4748AC-0311-43DA-9B4A-522E1A16C9AB@leafe.com>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C2F0A2C@EX10MBOX03.pnnl.gov>

You might be interested in:
https://www.openpolicyagent.org/
in particular Rego (https://www.openpolicyagent.org/docs/v0.10.7/how-do-i-write-policies) Which is inspired by Datalog which is a subset of Prolog

So there are other places in the stack reevaluating older tools for use in new places. :)

Thanks,
Kevin
________________________________________
From: Ed Leafe [ed at leafe.com]
Sent: Wednesday, April 10, 2019 12:50 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: [placement][ptg] Placement Over The Parapet

On Apr 9, 2019, at 12:08 PM, Chris Dent <cdent+os at anticdent.org> wrote:
>
> It's a whole big world out there, people doing all sorts of things
> that maybe look a bit like what placement does. What can we learn
> from them? What can they learn from us? In what ways can we expand
> placement world dominance and improve its ecosystem diversity?

I think we need to establish world dominance before we plot on how to expand it. :)

> We are often so busy in the depths of OpenStack that it is hard to
> remain aware of what is out there. What is?

I've shared this blog post [0] on the etherpad, but perhaps a wider audience might find it interesting. It caught my eye because last year in Dublin as we started to dig deeper into nested resource providers, the way things fit together reminded me of some of the things I had played around with when I looked into graph databases. I ran a series of experiments that I wrote about in my blog (series beginning with [1]), and am seriously thinking about digging deeper before we get too far down the nested rabbit hole. Even though the blog post was dealing with tracking security groups, it was reassuring to find someone else who also saw cloud resource management as being best modeled as a graph.

So maybe this response isn't what you were looking for (how can we integrate Placement into the wilds of the non-OpenStack world?), but rather how can we integrate some of the lessons of the non-OpenStack world into Placement?


[0] https://cloudbootup.com/post/cloud-management-with-prolog.html
[1] https://blog.leafe.com/hammer-and-nail/

-- Ed Leafe








From juliaashleykreger at gmail.com  Wed Apr 10 20:13:03 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 10 Apr 2019 13:13:03 -0700
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
In-Reply-To: <7c73651f-d878-a784-ae84-79486919bc24@redhat.com>
References: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
 <7c73651f-d878-a784-ae84-79486919bc24@redhat.com>
Message-ID: <CAF7gwdickZGtJ_jELqX3pToiUz+P_E1a28Y6FJN8y7qox4E6Qg@mail.gmail.com>

On Tue, Apr 9, 2019 at 9:58 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> On 4/9/19 1:56 PM, Chris Dent wrote:
> >
> > The etherpad [1] doesn't have any additional notes besides the topic
> > but the general questions are:
> >
> > * Do people want to do baremetal reservations with some combination
> >    of Ironic, Placement and Blazar, now or ever?
>
> There was at least one person at the Berlin Ops meetup who wanted this.
>

Neat, I've spoken to a few US based operators that are also interested
in this. Perhaps it we should allocate some time to the topic? It is
looking like there is some time for Saturday to enable smaller groups
of contributors to have focused area specific discussions.


> >
> > * What about Ironic and Placement, sans-Nova?
>
> I suspect we'll see more people realizing that Placement != Nova. I think for
> now people still assume it.
>
> >
> > * If so, what would need to happen to make those things possible?
> >
> > Based on my observations at the recent OpenInfra Days UK, I'd say
> > there's definitely an underserved need for this kind of
> > functionality. From the Placement side of things I would guess
> > there's little that would need to be done; it's more a matter of
> > getting other pieces and parts getting data in and out of Placement.
> >
> > Discuss...
> >
> > [1] https://etherpad.openstack.org/p/placement-ptg-train
> >
>
>


From ed at leafe.com  Wed Apr 10 20:21:18 2019
From: ed at leafe.com (Ed Leafe)
Date: Wed, 10 Apr 2019 15:21:18 -0500
Subject: [placement][ptg] Placement Over The Parapet
In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C2F0A2C@EX10MBOX03.pnnl.gov>
References: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
 <5D4748AC-0311-43DA-9B4A-522E1A16C9AB@leafe.com>
 <1A3C52DFCD06494D8528644858247BF01C2F0A2C@EX10MBOX03.pnnl.gov>
Message-ID: <A3B21778-C854-4C5A-B9D2-5D54365AAF4C@leafe.com>

On Apr 10, 2019, at 3:11 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> 
> You might be interested in:
> https://www.openpolicyagent.org/
> in particular Rego (https://www.openpolicyagent.org/docs/v0.10.7/how-do-i-write-policies) Which is inspired by Datalog which is a subset of Prolog

That does seem to be an interesting approach.

> So there are other places in the stack reevaluating older tools for use in new places. :)

Oh, geez, I wasn’t hoping to start writing Prolog code!  :)


-- Ed Leafe







From jim at jimrollenhagen.com  Wed Apr 10 20:34:09 2019
From: jim at jimrollenhagen.com (Jim Rollenhagen)
Date: Wed, 10 Apr 2019 16:34:09 -0400
Subject: [all][tc] Repository renames during OpenDev migration
Message-ID: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>

Hi all,

During the migration to OpenDev, we plan to change the way we organize some
of our repositories. Before you ask, yes, there will be redirects. The TC
has made some decisions about this[0]; this email is a re-iteration of the
plan and a call for any last minute feedback.

Here's how a repository's new namespace will be decided, as it stands today:

- is the repo listed in projects.yaml[2]? If so, "openstack".
- is the repo listed in legacy.yaml[3]? If so, "openstack".
- is the repo listed in foundation-board-repos.yaml[4]? If so, "openstack".
- is the repo listed in sigs-repos.yaml[5]? If so, "openstack".
- is the repo listed in technical-committee-repos.yaml[6]? If so,
"openstack".
- is the repo listed in user-committee-repos.yaml[7]? If so, "openstack".
- has the repo owner requested a new name(space) in the transition ethercalc
  sheet[1]? If so, use that.
- anything else? A few of us from the TC will manually review the list to
make
  sure we didn't miss anything that is an official OpenStack repo. Anything
  left will be moved to another namespace[8] unless/until the owner requests
  it to be moved elsewhere.

[0]
https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficial-projects.html
[1] https://ethercalc.openstack.org/opendev-transition
[2]
https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml
[3]
https://opendev.org/openstack/governance/src/branch/master/reference/legacy.yaml
[4]
https://opendev.org/openstack/governance/src/branch/master/reference/foundation-board-repos.yaml
[5]
https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml
[6]
https://opendev.org/openstack/governance/src/branch/master/reference/technical-committee-repos.yaml
[7]
https://opendev.org/openstack/governance/src/branch/master/reference/user-committee-repos.yaml
[8] I'm not even going to name it here, lest this thread devolves into a
    discussion about this name and nothing else.

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/5b3215e7/attachment.html>

From fungi at yuggoth.org  Wed Apr 10 20:44:33 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 10 Apr 2019 20:44:33 +0000
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
Message-ID: <20190410204432.u5e24yqglas5zxnv@yuggoth.org>

On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote:
[...]
> Before you ask, yes, there will be redirects.
[...]

The redirects for git.openstack.org to opendev.org have in fact
already been available for testing for a few weeks (and this week we
added rules which should properly cover git.airshipit.org,
git.starlingx.io and git.zuul-ci.org too). If you're interested in
helping us prove them further, you can add a line like this to your
/etc/hosts file:

2001:4800:7817:103:be76:4eff:fe04:e3e3 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org

...or, if you don't have IPv6 access, like:

23.253.125.17 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org

The expectation is that any hyperlinks to old cgit URLs remain
working, as should any git operations relying on http:// or https://
URLs (we unfortunately need to drop git:// support for a couple of
reasons).

As for any namespace changes and renames which happen during the
course of the transition, the Gitea service at opendev.org handles
redirecting those transparently and we've already tested (and in one
instance fixed a corner case for) that functionality.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/1c0ab1ce/attachment.sig>

From jaypipes at gmail.com  Wed Apr 10 21:25:27 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 17:25:27 -0400
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <DF3E4736-AF29-49F7-A10B-567A07742710@leafe.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
 <DF3E4736-AF29-49F7-A10B-567A07742710@leafe.com>
Message-ID: <76c1870b-aff9-6789-1569-8175568f82e1@gmail.com>

On 04/10/2019 12:46 PM, Ed Leafe wrote:
> On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred at inaugust.com> wrote:
>>
>>> Another suggestion has been to use a web-hook or similar from zuul
>>> to trigger an image build (either at docker hub or some other
>>> registry) post-merge.
>>
>> We actually have some pretty awesome new container building jobs in Zuul now - I'd recommend using them. One of the things they can do is build your container image to be used in a gate job, and then when the patch for the gate job merges, publish and tag the actual container image used in the gate.
> 
> My concern is the one-offness of placedock, not that it wouldn't work. But if Zuul can support this container building step, and we ensure that placedock follows the pattern that Zuul uses, we should be good.

Yeah, this was my thought as well. If we can (as the placement team) can 
take and own the "recipe" for constructing the container image using the 
Zuul container-image-building playbooks, then I'm 100% on board.

Best,
-jay


From openstack at fried.cc  Wed Apr 10 21:28:12 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 16:28:12 -0500
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
Message-ID: <4b9b3a68-607e-2ee8-554f-809f89225694@fried.cc>

I feel like good progress is occurring in the

> Spec: https://review.openstack.org/650476

As of this writing, I'm backing totally off of the solution proposed
there and instead favoring one of:

Solution 1: Assume "subtree" means "exactly one tier away from the root"
and express groupings of, er, request groups as needing to come from
"the same subtree". We should *not* do this by making a queryparam whose
value contains request group numbers, for reasons explained in the
spec/comments. Any other attempt to represent groups-of-request-groups
in a querystring is (IMO) untenable, so we should cut over to accepting
the query as a JSON payload. Here's a sample of what it would look like
for, "give me proc, mem, and two different nets, all from the same NUMA
node; and disk from wherever":

 { groups: [
       { requests: [
             { resources: {DISK_GB: 10} }
         ]
       }
       { requests: [
             { resources: {VCPU: 2, MEMORY_MB: 128} }
             { resources: {VF: 1},
               required: [NET_A] },
             { resources: {VF: 1},
               required: [NET_B] },
         ],
         group_policy: subtree_affinity
       },
   ]
 }

Solution 2: Change the data model in some way TBD - your inputs here.

> Some of the areas of potential contention:
> 
> * Adequate for limited but maybe not all use case solutions

Solution 1 is actually *less* limited than the original proposal, in
that it supports the "different nets" bit of the above example. The only
limitation that remains I think is that subtrees *have* to start one
tier away from the root. And as discussed, there's no known use case
where that's a problem.

> * Strict trait constructionism

No traits, no contention.

> * Evolving the complexity of placement solely for the satisfaction
>   of hardware representation in Nova

Mm. I get that it would be nice to identify non-Nova needs for this
feature, but hopefully you're not suggesting that we should avoid doing
it if we can't find some.

> * Inventory-less resource providers

An interesting topic, but IMO not related to $subject. This will come up
as soon as we model NUMA + sharing at all. We shouldn't muddy these
waters by hashing it out here.

> * Developing new features in placement before existing features are
>   fully used in client services

Are we not pretty close on this? Are there any placement features that
don't have client uses either already implemented or proposed for Train?
Again, IMO not a thing to even consider blocking on. And also not
specific to this topic.

> I list this not because they are deal breakers or the only thing
> that matters, but because they have presented stumbling blocks in
> the past and we may as well work to address them (or make an
> agreement to punt them until later) otherwise there will be
> lingering dread.

How about we do that in a separate thread, then?

> We'd like to figure out the best solution that can
> actually be done in a reasonable amount of time, not the best
> solution in the absolute.

Yeah, so to that point, I fear analysis paralysis if we decide to go
JSON query, trying to get the schema absolutely perfect. Parity with the
existing querystring impl plus the subtree affinity feature ought to be
good enough to start with.

efried
.



From mriedemos at gmail.com  Wed Apr 10 21:29:22 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 10 Apr 2019 16:29:22 -0500
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
Message-ID: <97990ceb-896c-a89f-7f1d-43cae6186a7a@gmail.com>

On 4/10/2019 3:34 PM, Jim Rollenhagen wrote:
> [8] I'm not even going to name it here

But what happens if you say it three times into a bathroom mirror? Doing 
so at midnight is optional.

-- 

Thanks,

Matt


From jaypipes at gmail.com  Wed Apr 10 21:29:30 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 17:29:30 -0400
Subject: [nova] Rebuild from cell0 limitation for personality files
In-Reply-To: <48566834-ccc4-fdcd-b9c0-28671d38042c@gmail.com>
References: <48566834-ccc4-fdcd-b9c0-28671d38042c@gmail.com>
Message-ID: <f0473e45-39ba-25cc-913b-96cc5374ff71@gmail.com>

On 04/10/2019 11:30 AM, Matt Riedemann wrote:
> I wanted to get some wider attention on what I think will be a 
> limitation in the rebuild from cell0 spec [1]. The main idea in that 
> spec is the user tries to create a server which fails during scheduling 
> to find a host and puts the instance into ERROR state and "buries" it in 
> cell0. With a new microversion, the user can attempt to rebuild the 
> server from cell0 and go through scheduling again. This is part of a 
> bigger effort to support pre-emptible instances where scheduling fails 
> during server create, an external reaper service tries to make room by 
> destroying some pre-emptible instances, and then the server gets rebuilt.
> 
> The issue I've found is that if the server was created with personality 
> files using microversion 2.1, fails, and then the user goes to rebuild 
> it, their personality files will be lost because (1) we don't persist 
> personality files anywhere, not even the RequestSpec and (2) 
> microversion 2.57 deprecated the personality files parameter from the 
> rebuild API [2]. Since you'll have to use a newer microversion > 2.57 to 
> rebuild from cell0, you can't specify the personality files again.
> 
> Are we OK with this?

Ummm, yes. Yes, I am completely OK with this.

-jay


From jaypipes at gmail.com  Wed Apr 10 21:35:22 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 17:35:22 -0400
Subject: [placement] Virtual Pre-PTG
In-Reply-To: <alpine.OSX.2.21.1904101333410.12309@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1903251535420.32545@cdent-a01.vmware.com>
 <alpine.OSX.2.11.1904081341530.9091@seed.local>
 <alpine.OSX.2.21.1904101333410.12309@cdent-a01.vmware.com>
Message-ID: <548f26d4-4b54-5344-31e9-a402f45a6900@gmail.com>

On 04/10/2019 08:39 AM, Chris Dent wrote:
> On Mon, 8 Apr 2019, Chris Dent wrote:
>> On Mon, 25 Mar 2019, Chris Dent wrote:
>>> I propose we start the process the week of the 8th, giving us 3
>>> weeks of discussion prior to the PTG, with the caveat that the week
>>> of the 22nd my availability will be limited. Between now and then
>>> make sure you topics get on the etherpads, along with as much
>>> additional info as you would normally put there. Don't fret if you
>>> think of something after the 8th, just put it on the etherpad as
>>> normal, and we'll figure it out.
>>
>> I'm going to get this started later today using the "series of email
>> threads" mentioned above. I'll give them '[placement]' and '[ptg]'
>> and base them off whatever seems relavant from the two etherpads
>> [2,3]. As before, feel free to continue adding to the etherpads.
> 
> I've started threads for everything from [2,3] that seemed relevant.
> For each topic where I started a thread, I changed the top-level
> topic to bold and made the next line a link to the archive of the
> first email in the thread.
> 
> The discussion should continue through next week. As topics reach a
> natural conclusion I'll summarize back to the etherpad. Anything
> that seems fully done I'll move to another part of the etherpad. The
> point with that is so that by the time the PTG comes around we're
> only paying attention to stuff we got stuck on during this
> email-based discussion.
> 
> As ever, if you remember a topic that hasn't already come up, please
> add it to one of the etherpads.
> 
> Also, so it is clear, these discussions are for everyone. You don't
> need to be a regular placement contributor or user to participate.
> If you have something to say, we want to hear it.

Chris, despite my being quite exhausted from emails and spec reviews, I 
wanted to thank you for spending the time to do this. It's been very 
helpful and serves as a good way to gather feedback in writing before 
what always ends up being an exhausting PTG session-fest.

Thanks,
-jay


From emilien at redhat.com  Wed Apr 10 21:57:46 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Wed, 10 Apr 2019 17:57:46 -0400
Subject: [tripleo] Scale up/down Ansible tasks
Message-ID: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>

Hi folks,

Today I spent a bit of time on:
https://blueprints.launchpad.net/tripleo/+spec/scale-down-tasks

Which is basically adding the capability of running Ansible tasks before a
node is removed during a scale down or after a scale-up.
I'm focusing on the scale-down right now, as I know it's something people
have been waiting for (e.g. RHSM unsubscribe, Ceph OSD tear down, Nova
Compute, etc).

I need inputs from folks now, on what kind of tasks would be needed, I will
test them and make sure the interface we provide is enough. John, Olie, and
Martin in copy have maybe some ideas, please let me know some examples of
Ansible tasks that you folks want to run before a node is deleted in Ironic.

Prototype:
https://review.openstack.org/#/q/topic:bp/scale-down-tasks+(status:open+OR+status:merged)

Thanks a lot,
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/f6dfa2d2/attachment.html>

From openstack at fried.cc  Wed Apr 10 22:00:43 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 17:00:43 -0500
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
Message-ID: <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>

Today we've got the principle of "don't do that," which we've expressed
in the docs:

https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits

Trying to enforce those principles programmatically beyond what we've
already done is going to be tricky, and as long as operators behave and
read the docs (even if it's after we've marked their bug report as
Invalid with the above link), mork work than benefit.

So I'm going to vote "do nothing for now".

efried
.


From smooney at redhat.com  Wed Apr 10 22:27:54 2019
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 10 Apr 2019 23:27:54 +0100
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <20190410204432.u5e24yqglas5zxnv@yuggoth.org>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
 <20190410204432.u5e24yqglas5zxnv@yuggoth.org>
Message-ID: <eba6d2403cc8d3ef5ac8b5afcfe412b90cdd2649.camel@redhat.com>

On Wed, 2019-04-10 at 20:44 +0000, Jeremy Stanley wrote:
> On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote:
> [...]
> > Before you ask, yes, there will be redirects.
> 
> [...]
> 
> The redirects for git.openstack.org to opendev.org have in fact
> already been available for testing for a few weeks (and this week we
> added rules which should properly cover git.airshipit.org,
> git.starlingx.io and git.zuul-ci.org too). If you're interested in
> helping us prove them further, you can add a line like this to your
> /etc/hosts file:
> 
> 2001:4800:7817:103:be76:4eff:fe04:e3e3 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org
> 
> ...or, if you don't have IPv6 access, like:
> 
> 23.253.125.17 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org
so after doing this if i clone directly i get

sean at pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova
Cloning into 'nova'...
warning: redirecting to https://opendev.org/openstack/nova/
remote: Enumerating objects: 535171, done.
remote: Counting objects: 100% (535171/535171), done.
remote: Compressing objects: 100% (98416/98416), done.
remote: Total 535171 (delta 427543), reused 530320 (delta 423684)
Receiving objects: 100% (535171/535171), 150.93 MiB | 4.37 MiB/s, done.
Resolving deltas: 100% (427543/427543), done.

and if i clone via a local squid proxy i get

sean at pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova
Cloning into 'nova'...
remote: Counting objects: 535171, done.
remote: Compressing objects: 100% (259964/259964), done.
remote: Total 535171 (delta 425706), reused 365748 (delta 262136)
Receiving objects: 100% (535171/535171), 150.74 MiB | 4.80 MiB/s, done.
Resolving deltas: 100% (425706/425706), done.

so via the proxy i dont even see the redirct warning 
but it seams to work fine for me over ipv4.

https also works.

> The expectation is that any hyperlinks to old cgit URLs remain
> working, as should any git operations relying on http:// or https://
> URLs (we unfortunately need to drop git:// support for a couple of
> reasons).
for what its worth while you can use netcat or socat to tunnel thorough a sock5 proxy with
a little trickery, for peopel behind coperate proxies the http/https repos on
github were always simpler to get working.
i dont have that problem anymore but i am glad that we changed the devstack
default to https as it make getting up and running for new people simpler.
that saidsetting GIT_BASE was not exactly hard either.
> 
> As for any namespace changes and renames which happen during the
> course of the transition, the Gitea service at opendev.org handles
> redirecting those transparently and we've already tested (and in one
> instance fixed a corner case for) that functionality.



From rosmaita.fossdev at gmail.com  Wed Apr 10 22:38:47 2019
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 10 Apr 2019 18:38:47 -0400
Subject: [dev][cinder][stable-maint] final os_brick release from stable/pike
Message-ID: <d3ec70c2-b946-72b5-faf9-c661492913e4@gmail.com>

I just discovered that there was a bug in the dashboard I posted on
today's Cinder meeting agenda, and this unmerged backport to stable/pike
os_brick was left off:

https://review.openstack.org/647809

The dashboard link, https://tiny.cc/cinder-stable-pike , now points to a
correct dashboard (sorry about that, hemna!)

Current status is:
2 backports +W and currently in recheck
2 backports with only one +2
  - https://review.openstack.org/647745
  - https://review.openstack.org/647743
1 backport without negative feedback
  - https://review.openstack.org/647809

There's one review not listed on the dashboard because it has a -W from
its author, which I'm taking to mean it's not ready.  But here's the
link in case anyone wants to look: https://review.openstack.org/539359

We need to release the final pike os_brick soon, so prompt positive (or
negative) attention from stable cores to the above will be appreciated.

cheers,
brian


From openstack at fried.cc  Wed Apr 10 23:00:56 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 18:00:56 -0500
Subject: [nova] Pre-PTG spec review day(s)
In-Reply-To: <06acb1df-828f-02ff-41ee-eda0301ac196@fried.cc>
References: <7b461dbd-7fd1-28e9-742c-ed72bdb9268c@fried.cc>
 <a61cd229-59e2-b1c1-4cb7-f20727c83e6d@fried.cc>
 <06acb1df-828f-02ff-41ee-eda0301ac196@fried.cc>
Message-ID: <cdbab11b-d699-4d38-698b-4614082235be@fried.cc>

Nova-

I feel like this was a success. We didn't close on a lot of specs (okay,
it was just one [1]), but we saw a lot of activity from authors getting
their specs ready, a lot of reviews, and a lot of good discussion that
moved the ball on many issues.

So I'd like us to follow up with the second review day as suggested
originally: next Tuesday, April 16th.

I've moved the main content of the etherpad [2] into a "Log" section so
we can start the "Specs" section afresh. This ensures reviewers aren't
wasting time reexamining specs that haven't moved since last time. To
that end:

Authors: Please take the time to respond to comments and update your
specs. Then (and only then) re-add them to the Specs section of the
etherpad. Don't delete/alter the Log section, please.

Thank you very much for yesterday. One good turn deserves another [3].

efried

[1] https://review.openstack.org/638629
[2] https://etherpad.openstack.org/p/nova-spec-review-day
[3] Or, "The reward for good work is more work." :)


From openstack at fried.cc  Wed Apr 10 23:07:15 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 10 Apr 2019 18:07:15 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
Message-ID: <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>

> Meh :) I actually think option 1 (Do nothing) is best here.

I can live with that. But I also like what you suggested below, which is
not "do nothing":

> from placement.objects import resource_provider
> from placement.objects import trait
> ...
> # Do CRUD-y stuff with resource providers
> rp = resource_provider.ResourceProvider(...)
> rp.create()
> # Do trait stuff
> t = trait.Trait(...)
> t.create()
> # Do trait-y stuff with resource providers
> rp.add_traits([t])
> # Do search-y stuff with resource providers
> resource_provider.get_all_by_filters(...)
> 
> Note that the "add_traits()" is a method on the ResourceProvider object
> in the above. I think this is more readable for create/update/delete
> operations.

This suggests a change whereby we move a bunch of module-level methods
to instance methods. I actually really like that idea. So for example:

 @db_api.placement_context_manager.writer
 def _set_traits(context, rp, traits):
     ...

becomes:

 class ResourceProvider(object):
     ...
     @db_api.placement_context_manager.writer
     def _set_traits(self, traits):
         ...
         # the artist formerly known as 'rp' is now 'self'
         # and context is self._context

How do folks feel about us making this change?

efried
.


From sundar.nadathur at intel.com  Thu Apr 11 00:42:41 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Wed, 10 Apr 2019 17:42:41 -0700
Subject: [glance] Listing all images with a set of custom properties
Message-ID: <4bb9cec7-93cf-bef2-778d-106215097b05@intel.com>

I am looking for a way to programmatically get all images that have been 
associated with a set of custom properties. Ideally, I should be able to 
say 'give me all images that have key1=value1, key2=value2, etc.

Failing that, at least get all images that have the named keys key1, 
key2, etc. irrespective of their values, so I can filter for the values 
myself.

I was looking at [1], specifically [2], and came up short. Any 
recommendations?

[1] 
https://github.com/openstack/python-glanceclient/tree/master/glanceclient/v2 


[2] 
https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L86

Regards,

Sundar



From sundar.nadathur at intel.com  Thu Apr 11 01:12:21 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 11 Apr 2019 01:12:21 +0000
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
Message-ID: <1CC272501B5BC543A05DB90AA509DED52754BB82@fmsmsx122.amr.corp.intel.com>


> From: Eric Fried <openstack at fried.cc>
> Sent: Wednesday, April 10, 2019 7:31 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [placement][nova][ptg] Resource provider - request group
> mapping
 
> > Pinging Cyborg folks. Does Cyborg needs something similar?
> 
> I know for sure this is a yes (somewhere around [6]?), but I won't be able to
> express the details as well as Sundar.

Yes, Cyborg can certainly use that. Right now, the Nova patch [6] is relying on the mapping done in [7] as part of the bandwidth provider.

I saw the thread where cdent is asking if Ironic would directly invoke Placement. Just curious, are there plans for Zun to leverage Placement and resource providers for containers?

I should review the spec.

[6] https://review.openstack.org/#/c/631244/
[7] https://git.openstack.org/cgit/openstack/nova/tree/nova/objects/request_spec.py?h=refs/changes/39/616239/33#n747 

Regards,
Sundar

From johfulto at redhat.com  Wed Apr 10 22:29:19 2019
From: johfulto at redhat.com (John Fulton)
Date: Wed, 10 Apr 2019 18:29:19 -0400
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
Message-ID: <CAE66OMAGgF8UaFEk-kNFa5+BceVEzF7GvQijJyoPZTN1aiVa2w@mail.gmail.com>

On Wed, Apr 10, 2019 at 5:58 PM Emilien Macchi <emilien at redhat.com> wrote:
>
> Hi folks,
>
> Today I spent a bit of time on:
> https://blueprints.launchpad.net/tripleo/+spec/scale-down-tasks
>
> Which is basically adding the capability of running Ansible tasks before a node is removed during a scale down or after a scale-up.
> I'm focusing on the scale-down right now, as I know it's something people have been waiting for (e.g. RHSM unsubscribe, Ceph OSD tear down, Nova Compute, etc).
>
> I need inputs from folks now, on what kind of tasks would be needed, I will test them and make sure the interface we provide is enough. John, Olie, and Martin in copy have maybe some ideas, please let me know some examples of Ansible tasks that you folks want to run before a node is deleted in Ironic.

In the Ceph case ceph-ansible has playbooks to correctly handle the
scale down of different ceph services, e.g. delete a monitor [1] or
delete an OSD [2]. The process would be to generate a ceph-ansible
inventory, e.g. the same way we do when we scale up [3], and then
execute one of those playbooks with that inventory. Examples of
running these playbook are in Seb's blog [4].

This would be a great feature to have because if you don't tell the
Ceph cluster that a node is not part of it anymore, then it will want
to find it and not be happy if you just delete the node. It's better
to tell the ceph cluster not to worry about a particular node anymore
by running one of these playbooks before the node is deleted.

Thanks,
  John

[1] https://github.com/ceph/ceph-ansible/blob/master/infrastructure-playbooks/shrink-mon.yml
[2] https://github.com/ceph/ceph-ansible/blob/master/infrastructure-playbooks/shrink-osd.yml
[3] https://github.com/openstack/tripleo-heat-templates/blob/master/deployment/ceph-ansible/ceph-base.yaml#L397
[4] https://www.sebastien-han.fr/blog/2016/08/16/Ceph-ansible-can-now-shrink-your-cluster/

> Prototype: https://review.openstack.org/#/q/topic:bp/scale-down-tasks+(status:open+OR+status:merged)
>
> Thanks a lot,
> --
> Emilien Macchi


From tetsuro.nakamura.bc at hco.ntt.co.jp  Thu Apr 11 01:46:04 2019
From: tetsuro.nakamura.bc at hco.ntt.co.jp (Tetsuro Nakamura)
Date: Thu, 11 Apr 2019 10:46:04 +0900
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
In-Reply-To: <6806ae976a91c5f47629daded10727193941a10e.camel@redhat.com>
References: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
 <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>
 <bf5380e3-402b-7808-74e6-2e70bd73b938@gmail.com>
 <6806ae976a91c5f47629daded10727193941a10e.camel@redhat.com>
Message-ID: <6a189ea4-a0f1-5b22-692c-c55934619710@hco.ntt.co.jp>

I'm not sure about rally,
but I feel better if we have one more performance measurement case to 
exercise the nested/sharing handling path before we go further enabling 
more features on this like the resource provider subtree affinity spec.

The performance depends on the cloud environment, but the performance 
ratio of <nested path>/<non-nested path> could be a kind of an indicator 
which would encourage people to refactor to get more performance 
reducing that ratio.

On 2019/04/09 22:55, Sean Mooney wrote:
> On Tue, 2019-04-09 at 09:33 -0400, Jay Pipes wrote:
>> On 04/09/2019 09:16 AM, Ed Leafe wrote:
>>> On Apr 9, 2019, at 7:45 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>>>>
>>>> In a world of copious time we'd have more of this kind of
>>>> measurement. Should we investigate Rally? It used to be the tool of
>>>> choice for this kind of thing once upon a time. Is it still that
>>>> time?
>>>>
>>>> Or should we continue using more focused and smaller setups, like
>>>> perfload? If so, what should they be?
>>>>
>>>> Or is this something to worry about some other time?
>>>
>>> As we do not have “copious time”, I think that this is not something we need right now. We do have a check in place
>>> in case something goes wrong, so I think our attention can best be directed elsewhere for now.
>>
>> Agree with Ed. :)
> if there was a placement specific tempest plugin woudl that not enmable rally to work automatically.
> im wondering if the gabbi tempest plugin coudl be used to execute the placeim api test via rally with
> some tweeking to the relevent config files?
> 
>>
>> -jay
>>
> 
> 
> 

-- 
Tetsuro Nakamura <tetsuro.nakamura.bc at hco.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan


From jaypipes at gmail.com  Thu Apr 11 01:58:41 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Wed, 10 Apr 2019 21:58:41 -0400
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
Message-ID: <6a9e9284-4f37-6c60-391e-73100fbd759f@gmail.com>

On 04/10/2019 07:07 PM, Eric Fried wrote:
>> Meh :) I actually think option 1 (Do nothing) is best here.
> 
> I can live with that. But I also like what you suggested below, which is
> not "do nothing":
> 
>> from placement.objects import resource_provider
>> from placement.objects import trait
>> ...
>> # Do CRUD-y stuff with resource providers
>> rp = resource_provider.ResourceProvider(...)
>> rp.create()
>> # Do trait stuff
>> t = trait.Trait(...)
>> t.create()
>> # Do trait-y stuff with resource providers
>> rp.add_traits([t])
>> # Do search-y stuff with resource providers
>> resource_provider.get_all_by_filters(...)
>>
>> Note that the "add_traits()" is a method on the ResourceProvider object
>> in the above. I think this is more readable for create/update/delete
>> operations.
> 
> This suggests a change whereby we move a bunch of module-level methods
> to instance methods. I actually really like that idea. So for example:
> 
>   @db_api.placement_context_manager.writer
>   def _set_traits(context, rp, traits):
>       ...
> 
> becomes:
> 
>   class ResourceProvider(object):
>       ...
>       @db_api.placement_context_manager.writer
>       def _set_traits(self, traits):
>           ...
>           # the artist formerly known as 'rp' is now 'self'
>           # and context is self._context
> 
> How do folks feel about us making this change?

++

-jay


From dangtrinhnt at gmail.com  Thu Apr 11 03:36:30 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 11 Apr 2019 12:36:30 +0900
Subject: [telemetry][panko][ceilometer][aodh][zuul] Replace
 telemetry-tox-py37 with openstack-python37-jobs
In-Reply-To: <CADJ6S4FOqMcf6mFqGEroNnQVYhJSQk4QTWi-mhZfwKRPcaVuWw@mail.gmail.com>
References: <CADJ6S4FOqMcf6mFqGEroNnQVYhJSQk4QTWi-mhZfwKRPcaVuWw@mail.gmail.com>
Message-ID: <CADJ6S4GRM6WuLw8kCpEguYt=_ZEJyirPBYrkhDs_WNZfNqZNmA@mail.gmail.com>

Hi again,

I proposed the patches to remove telemetry-tox-py37. Please take some time
to review. Thanks.

[1] https://review.openstack.org/651688
[2] https://review.openstack.org/651689
[3] https://review.openstack.org/650197

Yours,


On Wed, Apr 10, 2019 at 4:37 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> I would love to replace telemetry-tox-py37 with openstack-python37-jobs
> since the only main difference is the nodeset [1]. If you know any reason
> to keep it that way, please let me know.
>
> Yours,
>
> [1] https://github.com/openstack/ceilometer/blob/master/.zuul.yaml#L47
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/fd2fafce/attachment-0001.html>

From jordan.ansell at catalyst.net.nz  Thu Apr 11 04:04:20 2019
From: jordan.ansell at catalyst.net.nz (Jordan Ansell)
Date: Thu, 11 Apr 2019 16:04:20 +1200
Subject: Unshelve in nova, cinder initialize_connection with user context
Message-ID: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>

Hello,

I have encountered what appears to be an edge-case instance shelving
situation. I have to allow access to an internal API call to enable an
"unprivileged" user to perform an instance operation.

Specifically, I have a user with a "restricted permission" role in a
project, who should only be able to start/stop/shelve/unshelve an
existing instance. With sensible roles/actions in the nova policy, they
are able to perform all actions, except /un/shelving. This should be
controlled by a nova policy, however the user is unable to unshelve
without permission to access the /cinder/ API call
"initialize_connection()
<https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initialize-volume-attachment-detail#initialize-volume-attachment>".
Without granting permission to the user, cinder rejects nova's request
with an HTTP 403 status message.

Outcomes of this situation are, curious and potentially unwanted.
Curious being the user is able to /shelve/. Which leads to a point of no
return for the user. But of particular concern is this API call exposes
the backend storage driver's connection info to users. The RBD driver,
as we use, does not even require a populated "connector" object before
it replies.

I was looking for advice/opinions on this issue, and hope someone here
can help or direct me to the right place.

My thoughts were that perhaps this is a bug or there's a configuration
issue with our nova/cinder (note, i'm using mitaka, so maybe it's fixed
upstream!).
I am unable to check whether this is just a bug in nova, due to my lack
of experience. But my rationale is nova is using the /user//'s/ context
instead of an internal nova /admin/-like context to call the cinder API.
As for configuration, I've been unable to pull up anything that seems
relevant to this issue looking through
/etc/{nova,cinder}/{nova,cinder}.conf, but maybe there's an option we've
enabled that's led to this behavior.

I'm happy to answer questions if anything is unclear. Sorry for
verbosity, vagueness or inaccuracies -- I'm very new to Openstack,
having started at zero a month ago and am using this task as a way to
learn more.

Any help is much appreciated :)
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/444d466d/attachment.html>

From duc.openstack at gmail.com  Thu Apr 11 07:03:39 2019
From: duc.openstack at gmail.com (Duc Truong)
Date: Thu, 11 Apr 2019 00:03:39 -0700
Subject: [auto scaling sig][ptg][senlin][heat]
Message-ID: <CAN81NT6NzBERyP_3DTtFds6UCeuzmvC-ZoeFrNOagL=gqjO4Zw@mail.gmail.com>

Everyone,

Since the summit and PTG are coming up, I have updated the auto scaling
SIG etherpad [1] with some topics.  Please fill in if you are planning
to participate and any other topics you would like to discuss.

Duc (dtruong)

[1] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG


From mschuppert at redhat.com  Thu Apr 11 07:22:31 2019
From: mschuppert at redhat.com (Martin Schuppert)
Date: Thu, 11 Apr 2019 09:22:31 +0200
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
Message-ID: <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>

On Wed, Apr 10, 2019 at 11:58 PM Emilien Macchi <emilien at redhat.com> wrote:

> Hi folks,
>
> Today I spent a bit of time on:
> https://blueprints.launchpad.net/tripleo/+spec/scale-down-tasks
>
> Which is basically adding the capability of running Ansible tasks before a
> node is removed during a scale down or after a scale-up.
> I'm focusing on the scale-down right now, as I know it's something people
> have been waiting for (e.g. RHSM unsubscribe, Ceph OSD tear down, Nova
> Compute, etc).
>
> I need inputs from folks now, on what kind of tasks would be needed, I
> will test them and make sure the interface we provide is enough. John,
> Olie, and Martin in copy have maybe some ideas, please let me know some
> examples of Ansible tasks that you folks want to run before a node is
> deleted in Ironic.
>

For nova/neutron it would be to disable the service/agent:

(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service set [hostname] nova-compute
--disable

(overcloud) $ openstack network agent list
(overcloud) $ openstack network agent set --disable [openvswitch-agent-id]

After service is stopped/or host delete
(overcloud) $ openstack compute service delete [service-id]
(overcloud) $ openstack network agent delete [openvswitch-agent-id]

Regards,
Martin

[1]
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/director_installation_and_usage/index#removing-compute-nodes



>
> Prototype:
> https://review.openstack.org/#/q/topic:bp/scale-down-tasks+(status:open+OR+status:merged)
>
> Thanks a lot,
> --
> Emilien Macchi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/350ea527/attachment.html>

From dangtrinhnt at gmail.com  Thu Apr 11 07:35:53 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 11 Apr 2019 16:35:53 +0900
Subject: [telemetry] Procedure for merging patches
Message-ID: <CADJ6S4HDTBxboJk4p6LYo8uOtCk1OmwSqToZHASfub7VdLTLoQ@mail.gmail.com>

Hi team,

One of the thing that has been brought up in the last meeting is what is
the process of merging a patch. So, let's try this first:

   - For small patches (e.g., change strings, fix typos, update docs): any
   core can approve for merging.
   - For a patch that implements a new feature, removes a feature, patch
   that has huge changes (in the number of changed files and loc, etc.) or any
   patch that is in doubt: we need at least 2 cores to give a +2 and then the
   PTL will merge it.

Of course, we can change the procedure when we see issues. For now, this
should be a guideline for the team.

Please feel free to comment.

Yours,

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/4a53e405/attachment.html>

From aaronzhu1121 at gmail.com  Thu Apr 11 07:46:53 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Thu, 11 Apr 2019 15:46:53 +0800
Subject: [telemetry] Procedure for merging patches
In-Reply-To: <CADJ6S4HDTBxboJk4p6LYo8uOtCk1OmwSqToZHASfub7VdLTLoQ@mail.gmail.com>
References: <CADJ6S4HDTBxboJk4p6LYo8uOtCk1OmwSqToZHASfub7VdLTLoQ@mail.gmail.com>
Message-ID: <CAN2nDNsdq92fNka9npHhogW8FEQ1z6VswFV8bgXsA2e5EyUnzA@mail.gmail.com>

Hi,

As usual, There are have +2s, then the next core can +2/A, why we need PTL
final +A?

Thanks,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月11日 周四15:39写道：

> Hi team,
>
> One of the thing that has been brought up in the last meeting is what is
> the process of merging a patch. So, let's try this first:
>
>    - For small patches (e.g., change strings, fix typos, update docs):
>    any core can approve for merging.
>    - For a patch that implements a new feature, removes a feature, patch
>    that has huge changes (in the number of changed files and loc, etc.) or any
>    patch that is in doubt: we need at least 2 cores to give a +2 and then the
>    PTL will merge it.
>
> Of course, we can change the procedure when we see issues. For now, this
> should be a guideline for the team.
>
> Please feel free to comment.
>
> Yours,
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/86e2aefe/attachment-0001.html>

From dangtrinhnt at gmail.com  Thu Apr 11 07:51:26 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 11 Apr 2019 16:51:26 +0900
Subject: [telemetry] Procedure for merging patches
In-Reply-To: <CAN2nDNsdq92fNka9npHhogW8FEQ1z6VswFV8bgXsA2e5EyUnzA@mail.gmail.com>
References: <CADJ6S4HDTBxboJk4p6LYo8uOtCk1OmwSqToZHASfub7VdLTLoQ@mail.gmail.com>
 <CAN2nDNsdq92fNka9npHhogW8FEQ1z6VswFV8bgXsA2e5EyUnzA@mail.gmail.com>
Message-ID: <CADJ6S4H1xeE-GpB6udHvm=WocssXQ8NATRc=MN+wmV5yio30BQ@mail.gmail.com>

Ok, that makes sense to me.

On Thu, Apr 11, 2019 at 4:50 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Hi,
>
> As usual, There are have +2s, then the next core can +2/A, why we need PTL
> final +A?
>
> Thanks,
> Rong Zhu
>
> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月11日 周四15:39写道：
>
>> Hi team,
>>
>> One of the thing that has been brought up in the last meeting is what is
>> the process of merging a patch. So, let's try this first:
>>
>>    - For small patches (e.g., change strings, fix typos, update docs):
>>    any core can approve for merging.
>>    - For a patch that implements a new feature, removes a feature, patch
>>    that has huge changes (in the number of changed files and loc, etc.) or any
>>    patch that is in doubt: we need at least 2 cores to give a +2 and then the
>>    PTL will merge it.
>>
>> Of course, we can change the procedure when we see issues. For now, this
>> should be a guideline for the team.
>>
>> Please feel free to comment.
>>
>> Yours,
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/72c060e2/attachment.html>

From dangtrinhnt at gmail.com  Thu Apr 11 07:53:48 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 11 Apr 2019 16:53:48 +0900
Subject: [telemetry] Procedure for merging patches
In-Reply-To: <CADJ6S4H1xeE-GpB6udHvm=WocssXQ8NATRc=MN+wmV5yio30BQ@mail.gmail.com>
References: <CADJ6S4HDTBxboJk4p6LYo8uOtCk1OmwSqToZHASfub7VdLTLoQ@mail.gmail.com>
 <CAN2nDNsdq92fNka9npHhogW8FEQ1z6VswFV8bgXsA2e5EyUnzA@mail.gmail.com>
 <CADJ6S4H1xeE-GpB6udHvm=WocssXQ8NATRc=MN+wmV5yio30BQ@mail.gmail.com>
Message-ID: <CADJ6S4FFPOnr08Jk3My0H0e-fqszowZ-yiiUi-337a6iLDJ0mg@mail.gmail.com>

I meant I totally agree with what you're saying. If a core has already put
a +2 on a patch, the next core can approve.

On Thu, Apr 11, 2019 at 4:51 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Ok, that makes sense to me.
>
> On Thu, Apr 11, 2019 at 4:50 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>
>> Hi,
>>
>> As usual, There are have +2s, then the next core can +2/A, why we need
>> PTL final +A?
>>
>> Thanks,
>> Rong Zhu
>>
>> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月11日 周四15:39写道：
>>
>>> Hi team,
>>>
>>> One of the thing that has been brought up in the last meeting is what is
>>> the process of merging a patch. So, let's try this first:
>>>
>>>    - For small patches (e.g., change strings, fix typos, update docs):
>>>    any core can approve for merging.
>>>    - For a patch that implements a new feature, removes a feature,
>>>    patch that has huge changes (in the number of changed files and loc, etc.)
>>>    or any patch that is in doubt: we need at least 2 cores to give a +2 and
>>>    then the PTL will merge it.
>>>
>>> Of course, we can change the procedure when we see issues. For now, this
>>> should be a guideline for the team.
>>>
>>> Please feel free to comment.
>>>
>>> Yours,
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>> --
>> Thanks,
>> Rong Zhu
>>
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/ea2c7c6f/attachment.html>

From igortiunov at gmail.com  Thu Apr 11 08:22:26 2019
From: igortiunov at gmail.com (=?UTF-8?B?0JjQs9C+0YDRjCDQotC40YPQvdC+0LI=?=)
Date: Thu, 11 Apr 2019 11:22:26 +0300
Subject: [sdk][ansible][inventory] Server-side filtering capability for
 nova API
In-Reply-To: <180f3b37-b00f-1050-df73-558fe731d7f4@inaugust.com>
References: <FEDFAF89-F7E7-4D45-B38C-23BBB31308DB@gmail.com>
 <180f3b37-b00f-1050-df73-558fe731d7f4@inaugust.com>
Message-ID: <CAFJOE9AA3ZWF_9gNWTWifPw9cOrqBiPmK_5eXJO9zM2wfQNS5Q@mail.gmail.com>

Hello mordred

I do not understand the need of "use_direct_get" parameter. Currently I can
do the conn.list_servers(filters={"status": "ACTIVE", "name": "srv8-"})

And I see the corresponding request on the server side:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REQ: curl -g -i -X GET "
https://openstack:8774/v2.1/40e5d3f91fb44ccaa9056252efc243a7/servers/detail?name=srv8-&status=ACTIVE"
-H "Accept: application/json" -H "User-Agent: openstacksdk/0.27.0
keystoneauth1/3.13.1 python-requests/2.21.0 CPython/3.6.5" -H
"X-Auth-Token:
{SHA256}900ab80fe15448ceec851db2c14e2993ecd9634cefb897e71573c6d9496f701d"
RESP: [200] Content-Length: 3645 Content-Type: application/json Date: Thu,
11 Apr 2019 08:15:57 GMT Openstack-Api-Version: compute 2.1 Vary:
OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id:
req-e8622002-fb1d-4deb-8bf2-609d6a4b50c9 X-Openstack-Nova-Api-Version: 2.1
RESP BODY: {"servers": <...>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-04-11 11:15:57.997 9810 INFO nova.osapi_compute.wsgi.server
[req-e8622002-fb1d-4deb-8bf2-609d6a4b50c9
bbe117ded750704ba460feaabff6190c6b07c9acabc91066878cfca0c8362f48
40e5d3f91fb44ccaa9056252efc243a7 - 95ab4645f0764ac782765cbdcc79bbff
95ab4645f0764ac782765cbdcc79bbff] 172.30.202.194 "GET
/v2.1/40e5d3f91fb44ccaa9056252efc243a7/servers/detail?name=srv8-&status=ACTIVE
HTTP/1.1" status: 200 len: 3974 time: 0.2514541

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Igor Tiunov


пн, 8 апр. 2019 г. в 13:24, Monty Taylor <mordred at inaugust.com>:

>
>
> On 4/8/19 9:04 AM, Игорь Тиунов wrote:
> > Hi.
> > I saw that there some work regarding filtering in the inventory module.
> Also, I looked at how it will be used in future versions of ansible
> (os_server_facts module).
> >
> > I am worried about client-side nature of this filtering. The large
> deployments can have thousands of vms in one openstack project and such an
> environment can be very dynamic (vms are created/deleted frequently). The
> inventory collection can be done from multiple ansible management nodes and
> all these facts can lead to significant performance impact not only on the
> client side but on the server side also - a large amount of data will be
> requested from nova api servers.
> > I want to propose the usage of server-side filtering capability for nova
> API:
> >
> >
> https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers
> >
> > These filters are used at database level and will add a significant
> performance boost during inventory collection.
> > I want to propose the usage of filters in ansible openstack inventory
> plugin but first, such filters should be implemented in openstacksdk level.
> > I suggest splitting filters into two parts - the api_filters and
> metadata_filters. The api_filters will be used for server-side filtering
> and metadata_filters for client-side filtering.
> > I have created the snippet with prototype code. There a _split_filters
> method and related changes for list_hosts and search_hosts methods:
> >
> > https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629
> >
> > What do you think?
>
> Generally speaking, I think it's a good idea. However, there's a few
> things to be aware of that make this a little more complex. Namely - in
> addition to fire-and-forget programs like the os_ modules or the ansible
> inventory code, we also support users with long lives that do high
> volume interactions, such as nodepool. Unfortunately, in terms of
> efficiency, these two use cases want opposite things.
>
> For the short-term programs, as you mention, we want to maximize use of
> server-side filters. We also want to do things like use GET
> /servers/{id}. For the long-lived high-volume programs, we want to
> support a mode that combines caching and batching - rather than making
> 1000 queries to the server a second each with their own server-side
> filter conditions, it's more efficient to make one call every 5 seconds,
> cache the result, and do client-side filtering.
>
> We're currently good at the second use case and less good at the first.
>
> We took a step towards being better at the first use case with the
> use_direct_get parameter. Use direct get tells openstacksk to use direct
> GET /servers/{id} type calls rather than filtering a full list locally
> when a single resource is wanted by id.
>
> We need to fix this for get_server for reasons
> https://review.openstack.org/#/c/540389/.
>
> We should also update the logic for the default value to set
> use_direct_get=True if caching is enabled, and set it to false if it
> isn't - that way normal people don't have to care.
>
> We should almost CERTAINLY start setting this parameter to True in all
> of the ansible modules and inventory (I think the cases in which we want
> use_direct_get=False for ansible are VERY explicit - it involves having
> caching enabled to use external caching like redis - and I think in
> those cases we can expect a user to set the flag explicitly in config)
>
> So I think what we should potentially do here is expand on that config
> flag and have it pushdown server-side filters. In fact, if you read the
> value of that in your _split_filters method, then split filters could
> either return things in api_filters or not. Then we can take the idea
> and push it down into the underlying code so that inventory is just
> calling search_severs ... or something. I'm sure we'll need to figure
> out some details once we get in to it.
>
> One additional thing that will make this slightly more complex - but
> also I believe might allow us to do a few hard patches and get a LOT of
> benefit across the SDK.
>
> Right now we have the 'cloud' layer which used to be the shade library,
> and we have the 'resource' layer which came from the openstacksdk
> library. They share almost nothing, other than the connection object and
> some Adapters, but we're working to change that. One of the next things
> on the list is to get the 'cloud' layer to be built on top of the
> 'resource' layer for server interactions. We're already using the sdk
> layer for servers: https://review.openstack.org/#/c/530770 (although as
> mentioned use_direct_get needs fixed) ...
>
> What I think would be BEST would be if we taught
> openstack.resource.Resource about use_direct_get - and then put your
> _split_filters logic in there (although I believe the equiv logic is
> already there, so it might just be a matter of harnessing it.
>
> I think we can certainly start with inventory - as well as changing the
> default for use_direct_get in the inventory module and in
> lib/ansible/module_utils/openstak.py.
>
> Monty
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/57c42ae8/attachment-0001.html>

From smooney at redhat.com  Thu Apr 11 08:24:17 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 11 Apr 2019 09:24:17 +0100
Subject: [nova][cinder][keystone]  Unshelve in nova, cinder
 initialize_connection with user context
In-Reply-To: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
References: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
Message-ID: <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>

On Thu, 2019-04-11 at 16:04 +1200, Jordan Ansell wrote:
> Hello,
> 
> I have encountered what appears to be an edge-case instance shelving
> situation. I have to allow access to an internal API call to enable an
> "unprivileged" user to perform an instance operation.
> 
> Specifically, I have a user with a "restricted permission" role in a
> project, who should only be able to start/stop/shelve/unshelve an
> existing instance. With sensible roles/actions in the nova policy, they
> are able to perform all actions, except /un/shelving. This should be
> controlled by a nova policy, however the user is unable to unshelve
> without permission to access the /cinder/ API call
> "initialize_connection()
> <
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initialize-volume-attachment-detail#initialize-volume-attachment
> >".
> Without granting permission to the user, cinder rejects nova's request
> with an HTTP 403 status message.
> 
> Outcomes of this situation are, curious and potentially unwanted.
> Curious being the user is able to /shelve/. Which leads to a point of no
> return for the user. But of particular concern is this API call exposes
> the backend storage driver's connection info to users. The RBD driver,
> as we use, does not even require a populated "connector" object before
> it replies.
> 
> I was looking for advice/opinions on this issue, and hope someone here
> can help or direct me to the right place.
> 
> My thoughts were that perhaps this is a bug or there's a configuration
> issue with our nova/cinder (note, i'm using mitaka, so maybe it's fixed
> upstream!).
> I am unable to check whether this is just a bug in nova, due to my lack
> of experience. But my rationale is nova is using the /user//'s/ context
> instead of an internal nova /admin/-like context to call the cinder API.
> As for configuration, I've been unable to pull up anything that seems
> relevant to this issue looking through
> /etc/{nova,cinder}/{nova,cinder}.conf, but maybe there's an option we've
> enabled that's led to this behavior.
this is an interesting usecase and while this is not a part of the code
i useually deal with i be live your understand is correct in that we try
intentionally to use the users auth context wehre ever possible.

nova has/can have admin credential in its config for some service like
cinder and neutron however for security reasons(primarily try to not store
admin credentials on compute nodes) we try to not use the admin credentials.


i dont know if we have a config knob you can change to modify this behavior.
always using the admin credentials would be considerd an anti patteren
but i also know that some work has been done in keystone with system tokens?
servier tokens?  something like that may facilitate this usecase in the future.

hopefuly someone more knoladgeable in this area will chime in but in no surprised
that you have encountered issues with this configuration as it is not tested in the gate.
the default rule applie if its not tested assume its broken althohgh untested feature
do work more often then you would expect.
> 
> I'm happy to answer questions if anything is unclear. Sorry for
> verbosity, vagueness or inaccuracies -- I'm very new to Openstack,
> having started at zero a month ago and am using this task as a way to
> learn more.
> 
> Any help is much appreciated :)
> Jordan



From owalsh at redhat.com  Thu Apr 11 09:17:01 2019
From: owalsh at redhat.com (Oliver Walsh)
Date: Thu, 11 Apr 2019 10:17:01 +0100
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
 <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
Message-ID: <CALv8kgFr1oKeS6YrwHKiMi0b-F-Qc3p8nVET+eNMnv-+R=QfLw@mail.gmail.com>

On Thu, 11 Apr 2019 at 08:23, Martin Schuppert <mschuppert at redhat.com>
wrote:

>
>
> On Wed, Apr 10, 2019 at 11:58 PM Emilien Macchi <emilien at redhat.com>
> wrote:
>
>> Hi folks,
>>
>> Today I spent a bit of time on:
>> https://blueprints.launchpad.net/tripleo/+spec/scale-down-tasks
>>
>> Which is basically adding the capability of running Ansible tasks before
>> a node is removed during a scale down or after a scale-up.
>> I'm focusing on the scale-down right now, as I know it's something people
>> have been waiting for (e.g. RHSM unsubscribe, Ceph OSD tear down, Nova
>> Compute, etc).
>>
>> I need inputs from folks now, on what kind of tasks would be needed, I
>> will test them and make sure the interface we provide is enough. John,
>> Olie, and Martin in copy have maybe some ideas, please let me know some
>> examples of Ansible tasks that you folks want to run before a node is
>> deleted in Ironic.
>>
>
> For nova/neutron it would be to disable the service/agent:
>
> (overcloud) $ openstack compute service list
> (overcloud) $ openstack compute service set [hostname] nova-compute
> --disable
>
> (overcloud) $ openstack network agent list
> (overcloud) $ openstack network agent set --disable [openvswitch-agent-id]
>
> After service is stopped/or host delete
> (overcloud) $ openstack compute service delete [service-id]
> (overcloud) $ openstack network agent delete [openvswitch-agent-id]
>
> Regards,
> Martin
>
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/director_installation_and_usage/index#removing-compute-nodes
>

Might be worth confirming there are no instances running on the node too.

Cheers,
Ollie



>
>
>
>>
>> Prototype:
>> https://review.openstack.org/#/q/topic:bp/scale-down-tasks+(status:open+OR+status:merged)
>>
>> Thanks a lot,
>> --
>> Emilien Macchi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/1fbcac18/attachment.html>

From witold.bedyk at suse.com  Thu Apr 11 09:36:24 2019
From: witold.bedyk at suse.com (Witek Bedyk)
Date: Thu, 11 Apr 2019 11:36:24 +0200
Subject: [telemetry][gnocchi] Gnocchi alternatives
In-Reply-To: <CALjNAZ1++e8WoyAo77rNUgpe9ctYmHUfjfbi7hut7PbaaapJyg@mail.gmail.com>
References: <CADJ6S4HyeMjS-cSD1YV6keW2ridBnQ6F1WBH6GcnGb0=PXTEtg@mail.gmail.com>
 <CALjNAZ1++e8WoyAo77rNUgpe9ctYmHUfjfbi7hut7PbaaapJyg@mail.gmail.com>
Message-ID: <d5a4eb7d-4010-c944-587e-b784d19d1c4c@suse.com>

Hello everyone,

As I read your list of criteria, most of these are fulfilled by Monasca. 
I agree with Mark that it would be better to focus on one monitoring 
project but I'm probably not the right person to say that as Monasca has 
joined OpenStack after Ceilometer.


On 4/10/19 1:05 PM, Lingxian Kong wrote:
> Personally, I can see there are several criteria for the replacement 
> project(s) of Ceilometer/Aodh:
> 
> - Provide consistent API experience with other openstack services.

Monasca API [1, 2] and client [3].

> - Integrate with Keystone

Yes

> - Have ALL the metrics of core services that Ceilometer is collecting 
> nowadays.

Any metric which Ceilometer collects can be forwarded through 
monasca-ceilometer publisher [4] to Monasca.

> - Alarm API

Yes

> - Including all the feature-parity functionalities of current 
> evaluators/notifiers Aodh already provides.

Monasca doesn't provide alerting on OpenStack event notifications yet, 
but we would like to add it.

> - Last but not least, easy to integrate with other OpenStack services

You can achieve that by using webhook notifications.

As you can see there are no big gaps and we're open to contributors who 
would like to close the existing ones.

Best greetings
Witek


[1] https://docs.openstack.org/monasca-api/latest/
[2] 
https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md
[3] https://docs.openstack.org/python-monascaclient/latest/index.html
[4] https://github.com/openstack/monasca-ceilometer


From witold.bedyk at suse.com  Thu Apr 11 10:12:43 2019
From: witold.bedyk at suse.com (Witek Bedyk)
Date: Thu, 11 Apr 2019 12:12:43 +0200
Subject: [openstack-ansible][monasca][zaqar][watcher][searchlight]
 Retirement of unused OpenStack Ansible roles
In-Reply-To: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
References: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
Message-ID: <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>

Hi Guilherme,

I've added relevant project tags to the subject.

For the Monasca roles, they should be quite up-to-date right? They've 
been updated last year. It would be great to have someone maintain them.

Cheers
Witek


On 4/5/19 5:07 AM, Guilherme Steinmüller wrote:
> Hello all,
> 
> We have been discussing about some of our roles that are not maintained 
> for a while, some of them are not even integrated with our main 
> repository. In order to the team to focus on performance and stability 
> of the roles that has been actively used, we are discussing about 
> retiring the unused ones.
> 
> The roles are the following:
> 
>      openstack-ansible-os_monasca
>      openstack-ansible-os_monasca-agent
>      openstack-ansible-os_zaqar
>      openstack-ansible-os_watcher
>      openstack-ansible-os_almanach
>      openstack-ansible-os_molteniron
>      openstack-ansible-os_searchlight
> 
> We would love to help if someone wants to pick one or some of them to 
> keep our variety of roles.  If we don't hear back, we'll retire those 
> roles out of OpenStack Ansible.
> 
> Thank you
> Guilherme Steinmüller


From cdent+os at anticdent.org  Thu Apr 11 10:21:35 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 11:21:35 +0100 (BST)
Subject: [placement] Virtual Pre-PTG
In-Reply-To: <548f26d4-4b54-5344-31e9-a402f45a6900@gmail.com>
References: <alpine.OSX.2.21.1903251535420.32545@cdent-a01.vmware.com>
 <alpine.OSX.2.11.1904081341530.9091@seed.local>
 <alpine.OSX.2.21.1904101333410.12309@cdent-a01.vmware.com>
 <548f26d4-4b54-5344-31e9-a402f45a6900@gmail.com>
Message-ID: <alpine.OSX.2.11.1904111120360.33106@seed.local>

On Wed, 10 Apr 2019, Jay Pipes wrote:

> Chris, despite my being quite exhausted from emails and spec reviews, I 
> wanted to thank you for spending the time to do this. It's been very helpful 
> and serves as a good way to gather feedback in writing before what always 
> ends up being an exhausting PTG session-fest.

You're welcome. If we do this right we can spend the time at the PTG
either in other sessions or sitting around congratulating one
another for a job well done.

That's the stretch goal: Make the PTG redundant from a placement
perspective.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dtantsur at redhat.com  Thu Apr 11 10:24:24 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 11 Apr 2019 12:24:24 +0200
Subject: [ironic][ptg] Schedule/Team gathering
In-Reply-To: <CAF7gwdjhcDLzkrobA1-=0QrD5Prz_xd24M61SR8wAC69_mdXMQ@mail.gmail.com>
References: <CAF7gwdjhcDLzkrobA1-=0QrD5Prz_xd24M61SR8wAC69_mdXMQ@mail.gmail.com>
Message-ID: <20e15025-d698-bd01-c117-f7d543f4d354@redhat.com>

On 4/10/19 7:38 PM, Julia Kreger wrote:
> Greetings fellow ?Ironicans?
> 
> I've posted a new etherpad[0] based upon our discussion in the
> planning etherpad[1]. Please review and if there are any scheduling
> issues please let me know.

I suspect Community Sustainability will take longer than planned. Otherwise 
looks great, thanks for composing it!

> 
> Also, we need to figure out an evening for a team gathering. I've
> posted a doodle[3]. Please submit it with-in the next few days and
> I'll begin looking around for someplace that might work.

Do we know when the official events will take place? I'm only aware of the 
marketplace event on Monday.

> 
> Thanks everyone!
> 
> -Julia
> [0]: https://etherpad.openstack.org/p/DEN-train-ironic-ptg
> [1]: https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
> [2]: https://doodle.com/poll/e6q5e6pm72wbiwtz
> 



From cdent+os at anticdent.org  Thu Apr 11 10:53:10 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 11:53:10 +0100 (BST)
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED52754BB82@fmsmsx122.amr.corp.intel.com>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
 <1CC272501B5BC543A05DB90AA509DED52754BB82@fmsmsx122.amr.corp.intel.com>
Message-ID: <alpine.OSX.2.11.1904111150200.33106@seed.local>

On Thu, 11 Apr 2019, Nadathur, Sundar wrote:

> I saw the thread where cdent is asking if Ironic would directly
> invoke Placement. Just curious, are there plans for Zun to
> leverage Placement and resource providers for containers?

There's been a blueprint and some code written in that direction:

* https://blueprints.launchpad.net/zun/+spec/use-placement-resource-management
* https://review.openstack.org/#/c/586960/

But I'm not sure of the status of things. Shall we have a
zun+placement thread too?

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From ionut at fleio.com  Thu Apr 11 11:14:24 2019
From: ionut at fleio.com (Ionut Biru)
Date: Thu, 11 Apr 2019 14:14:24 +0300
Subject: [magnum] kubernests cinder deploying wordpress
Message-ID: <CALE96ND6vKsHNA9vkaQCsabvS_XHq05fdb0t4B=x03DKzHLJTw@mail.gmail.com>

Hello,


I'm trying to deploy a simple wordpress installation following the
documentation from kubernets.
https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

kubernets was deployed using magnum on openstack rocky using the following
template:
https://paste.xinu.at/sRk/

Then i'm using the cinder storage class that is described in kubernets
documentation:
https://kubernetes.io/docs/concepts/storage/storage-classes/#openstack-cinder
and I also made it default.

I did the following test:
cinder volume created before hand and used in pod directly with the id, the
volume is attached and mounted correctly like is described here:
https://docs.openstack.org/magnum/latest/user/#storage

Now if I try to deploy wordpress using the first link  or other helms that
use volume claim,  the volume is created automatically by kubernets but
they are never attached or mounted to the instances.

On master I see the following error:

pv_protection_controller.go:116] PV
pvc-48fed935-5b61-11e9-9901-fa163e5ebeae failed with : Operation cannot be
fulfilled on persistentvolumes "pvc-48fed935-5b61-11e9-9901-fa163e5ebea>
the object has been modified; please apply your changes to the latest
version and try again

Is there something I miss? I'm using the wrong version of fedora-atomic?
It's the latest version available for download.

I did find that someone else had this error but not with cinder:
https://github.com/kubernetes/kubernetes/issues/72905
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/ec5ec890/attachment.html>

From cdent+os at anticdent.org  Thu Apr 11 11:38:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 12:38:07 +0100 (BST)
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
Message-ID: <alpine.OSX.2.11.1904111156530.33106@seed.local>

On Wed, 10 Apr 2019, Eric Fried wrote:

> I'll champion the one I described in the third comment at [4], where we
> add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
> because it's per "allocations" rather than per "allocations.$rp". That
> said, both of these options:
>
> - Provide the same information: which request groups got satisfied by
> which providers [5].
> - Violate the "black box" principle and require one side or the other to
> work around it (either client removes or placement ignores the new key
> on PUT /allocations). As I said further down in [4], I don't care about
> that. (Ed?)
> - Maintain the existing levels of hierarchy for the existing elements,
> which Chris explained was important (see bottom five comments at [4]).

It's true that they do not change existing paths to existing data,
but they do "invade" (as you say in your second point) existing data
structures. The cleanest solution would probably be a new top-level
key that provides the mapping information (line 426 on the spec),
but as discussed there that ends up repeating too much information
and needing ordering, because there's no independent identifier of a
single allocation_request.

So yeah, one of those will do.

A moment to riff on one the points of having these conversations in
the expanse of email:

To my internal unfettered brain the above sort-of-mess is yet more
evidence that nested is a nightmare and gosh I wish we had never
done: it, request groups, provider trees on the nova side, and pretty
much all the stuff that's in progress related to enhanced platform
awareness. It makes me squirm, see bad smells everywhere, and
facepalm multiple times per day.

I feel it is important that I get this off my chest and I encourage
anyone else who has internal voices that don't feel enitirely
appropriate go ahead and let them out as part of this pre-PTG email
process. We are much more likely in the long term to be able to get
things done in a useful fashion if we are able to honestly
flush/vent such concerns in "public" and safely.

Because a lot of this stuff is the reality that we have and a
situation that we need to solve. We can achieve the goals better by
building up a shared language of what it is. That language includes
the shit as well as the shine.

All that stuff above that I don't like at some gut level, I do like
(or at least appreciate the value of) at a more practical level.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From emilien at redhat.com  Thu Apr 11 12:20:35 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 11 Apr 2019 08:20:35 -0400
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
 <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
Message-ID: <CACu=hytKrzZMeSsw540t6GsWbdq3OrOnEECJB6AMgcvHxERQqg@mail.gmail.com>

On Thu, Apr 11, 2019 at 3:23 AM Martin Schuppert <mschuppert at redhat.com>
wrote:

> For nova/neutron it would be to disable the service/agent:
>
> (overcloud) $ openstack compute service list
> (overcloud) $ openstack compute service set [hostname] nova-compute
> --disable
>
> (overcloud) $ openstack network agent list
> (overcloud) $ openstack network agent set --disable [openvswitch-agent-id]
>
> After service is stopped/or host delete
> (overcloud) $ openstack compute service delete [service-id]
> (overcloud) $ openstack network agent delete [openvswitch-agent-id]
>

Ok so these commands would need to be executed from the Undercloud in the
mistral_container, since they do nothing on local nodes but just do CLI
against APIs.
I take note and will make sure it's possible.

Do you folks already have some playbooks doing these things or should we
start from scratch?
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/5118c81c/attachment.html>

From emilien at redhat.com  Thu Apr 11 12:22:59 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 11 Apr 2019 08:22:59 -0400
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CAE66OMAGgF8UaFEk-kNFa5+BceVEzF7GvQijJyoPZTN1aiVa2w@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
 <CAE66OMAGgF8UaFEk-kNFa5+BceVEzF7GvQijJyoPZTN1aiVa2w@mail.gmail.com>
Message-ID: <CACu=hyvbrcNwHaM-d9nhZ8VURsj+tZ1fJ_GdZTyu73AL8iGhRg@mail.gmail.com>

On Wed, Apr 10, 2019 at 6:30 PM John Fulton <johfulto at redhat.com> wrote:

> In the Ceph case ceph-ansible has playbooks to correctly handle the
> scale down of different ceph services, e.g. delete a monitor [1] or
> delete an OSD [2]. The process would be to generate a ceph-ansible
> inventory, e.g. the same way we do when we scale up [3], and then
> execute one of those playbooks with that inventory. Examples of
> running these playbook are in Seb's blog [4].
>
> This would be a great feature to have because if you don't tell the
> Ceph cluster that a node is not part of it anymore, then it will want
> to find it and not be happy if you just delete the node. It's better
> to tell the ceph cluster not to worry about a particular node anymore
> by running one of these playbooks before the node is deleted.
>

So if I'm not mistaken, these tasks need to run within the mistral_executor
on the Undercloud against a generated ceph-ansible inventory. Which means,
no tasks are run on hosts on local mode.
Let me know if I'm wrong, I'll make sure this is working fine for the scale
tasks.
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/78d43e98/attachment.html>

From cdent+os at anticdent.org  Thu Apr 11 12:24:13 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 13:24:13 +0100 (BST)
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <4b9b3a68-607e-2ee8-554f-809f89225694@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <4b9b3a68-607e-2ee8-554f-809f89225694@fried.cc>
Message-ID: <alpine.OSX.2.11.1904111303310.33106@seed.local>

On Wed, 10 Apr 2019, Eric Fried wrote:

> I feel like good progress is occurring in the
>
>> Spec: https://review.openstack.org/650476
>
> As of this writing, I'm backing totally off of the solution proposed
> there and instead favoring one of:
>
> Solution 1: Assume "subtree" means "exactly one tier away from the root"
> and express groupings of, er, request groups as needing to come from
> "the same subtree". We should *not* do this by making a queryparam whose
> value contains request group numbers, for reasons explained in the
> spec/comments. Any other attempt to represent groups-of-request-groups
> in a querystring is (IMO) untenable, so we should cut over to accepting
> the query as a JSON payload. Here's a sample of what it would look like
> for, "give me proc, mem, and two different nets, all from the same NUMA
> node; and disk from wherever":
>
> { groups: [
>       { requests: [
>             { resources: {DISK_GB: 10} }
>         ]
>       }
>       { requests: [
>             { resources: {VCPU: 2, MEMORY_MB: 128} }
>             { resources: {VF: 1},
>               required: [NET_A] },
>             { resources: {VF: 1},
>               required: [NET_B] },
>         ],
>         group_policy: subtree_affinity
>       },
>   ]
> }

For those of us not in your head, can you explain how the above is
different/better from the following pseudo-query:

      resources=DISK_GB;
      resources1=VCPU:2,MEMORY_MB:128;
      resources2=VF:1;required2=NET_A;group_policy2=subtree_rooter:resources1;
      resources3=VF:1;required2=NET_B;group_policy3=subtree_rooter:resources1

Apologies if I'm missing some details. I probably am, that's why
I'm asking. I'm intentionally ignoring your "should not do this by
making a queryparam ... group numbers" because I didn't fully
understand the explanation/reasoning in the discussion on the spec,
so I'm after additional explanation (that is, if we have to merge
request groups we still need to preserve the distinctiveness of the
groups, and if some form of a hierarchical relationship is present
we need to maintain that).

To be clear, I'm not trying to block the JSON body, I'm trying to
understand. That is: my request for an explanation of the
differences is exactly that.

>> * Evolving the complexity of placement solely for the satisfaction
>>   of hardware representation in Nova
>
> Mm. I get that it would be nice to identify non-Nova needs for this
> feature, but hopefully you're not suggesting that we should avoid doing
> it if we can't find some.

As I said on the spec at

https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst at 135

"a way that placement can work that happens to satisfy NUMA" (using
placement-related primitives) as opposed to making a solution that
is directly modeled off NUMA concepts. I'm pretty sure we're not
doing the latter, but it is a thing to be aware of while having a
wide-open conversation (which is what this is).

I'm _not_ suggesting we avoid it.

>> * Inventory-less resource providers
>
> An interesting topic, but IMO not related to $subject. This will come up
> as soon as we model NUMA + sharing at all. We shouldn't muddy these
> waters by hashing it out here.

I'm sorry to beat on this drum over and over again, but the reason
to have this pre-PTG stuff is exactly to churn up the waters and get
all the ideas out in the open so that we are thinking about the
entire system, not specific details.

>> * Developing new features in placement before existing features are
>>   fully used in client services
>
> Are we not pretty close on this? Are there any placement features that
> don't have client uses either already implemented or proposed for Train?
> Again, IMO not a thing to even consider blocking on. And also not
> specific to this topic.

It's nothing to do with blocking, it's about being aware. Strict
adherence to thread discipline is not desired in this process.
Ramble. Talk. Spitball. We have the time. Use it.

>> I list this not because they are deal breakers or the only thing
>> that matters, but because they have presented stumbling blocks in
>> the past and we may as well work to address them (or make an
>> agreement to punt them until later) otherwise there will be
>> lingering dread.
>
> How about we do that in a separate thread, then?

Why? See my two paragraphs above and my facepalming in another
thread.

>> We'd like to figure out the best solution that can
>> actually be done in a reasonable amount of time, not the best
>> solution in the absolute.
>
> Yeah, so to that point, I fear analysis paralysis if we decide to go
> JSON query, trying to get the schema absolutely perfect. Parity with the
> existing querystring impl plus the subtree affinity feature ought to be
> good enough to start with.

I suspect if we can come up a sufficient explanation for why query
params are not gonna do it (which might be relatively painless) we
might, if we give ourselves the leeway to hash it out effectively,
come up with a reasonable set of constraints for an initial version
(which we have license to evolve).

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From mschuppert at redhat.com  Thu Apr 11 12:27:40 2019
From: mschuppert at redhat.com (Martin Schuppert)
Date: Thu, 11 Apr 2019 14:27:40 +0200
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CACu=hytKrzZMeSsw540t6GsWbdq3OrOnEECJB6AMgcvHxERQqg@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
 <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
 <CACu=hytKrzZMeSsw540t6GsWbdq3OrOnEECJB6AMgcvHxERQqg@mail.gmail.com>
Message-ID: <CAOjEBNqa6-hPD4_atej7Onc==o8va=UQUL=WXTT_96bX5_mV9Q@mail.gmail.com>

On Thu, Apr 11, 2019 at 2:20 PM Emilien Macchi <emilien at redhat.com> wrote:

> On Thu, Apr 11, 2019 at 3:23 AM Martin Schuppert <mschuppert at redhat.com>
> wrote:
>
>> For nova/neutron it would be to disable the service/agent:
>>
>> (overcloud) $ openstack compute service list
>> (overcloud) $ openstack compute service set [hostname] nova-compute
>> --disable
>>
>> (overcloud) $ openstack network agent list
>> (overcloud) $ openstack network agent set --disable
>> [openvswitch-agent-id]
>>
>> After service is stopped/or host delete
>> (overcloud) $ openstack compute service delete [service-id]
>> (overcloud) $ openstack network agent delete [openvswitch-agent-id]
>>
>
> Ok so these commands would need to be executed from the Undercloud in the
> mistral_container, since they do nothing on local nodes but just do CLI
> against APIs.
> I take note and will make sure it's possible.
>
> Do you folks already have some playbooks doing these things or should we
> start from scratch?
>

No, right now those are manual tasks, but Rajesh could help on this.

Regards,
Martin



> --
> Emilien Macchi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/0e151fe6/attachment.html>

From smooney at redhat.com  Thu Apr 11 12:35:15 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 11 Apr 2019 13:35:15 +0100
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <alpine.OSX.2.11.1904111156530.33106@seed.local>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
 <alpine.OSX.2.11.1904111156530.33106@seed.local>
Message-ID: <b88719bfe208fe7455b511c91a10dcc4d79771db.camel@redhat.com>

On Thu, 2019-04-11 at 12:38 +0100, Chris Dent wrote:
> On Wed, 10 Apr 2019, Eric Fried wrote:
> 
> > I'll champion the one I described in the third comment at [4], where we
> > add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
> > because it's per "allocations" rather than per "allocations.$rp". That
> > said, both of these options:
> >
> > - Provide the same information: which request groups got satisfied by
> > which providers [5].
> > - Violate the "black box" principle and require one side or the other to
> > work around it (either client removes or placement ignores the new key
> > on PUT /allocations). As I said further down in [4], I don't care about
> > that. (Ed?)
> > - Maintain the existing levels of hierarchy for the existing elements,
> > which Chris explained was important (see bottom five comments at [4]).
> 
> It's true that they do not change existing paths to existing data,
> but they do "invade" (as you say in your second point) existing data
> structures. The cleanest solution would probably be a new top-level
> key that provides the mapping information (line 426 on the spec),
> but as discussed there that ends up repeating too much information
> and needing ordering, because there's no independent identifier of a
> single allocation_request.
> 
> So yeah, one of those will do.
> 
> A moment to riff on one the points of having these conversations in
> the expanse of email:
> 
> To my internal unfettered brain the above sort-of-mess is yet more
> evidence that nested is a nightmare and gosh I wish we had never
> done: it, request groups, provider trees on the nova side, and pretty
> much all the stuff that's in progress related to enhanced platform
> awareness. It makes me squirm, see bad smells everywhere, and
> facepalm multiple times per day.
so just want to put this out there there is an alternitve  have placemetn be numa aware.

we can track all the resources in placement and we can pass allocation_candiates/provider_summaries
to the nova filters and we can have those filter eliminate invalid alloction_candiates based on numa
or any other chritia that placement does not understand.

we can do this today without modifying placements data structure although  we woudl still have to
create nested multiple resource provders per numa node but we dont need to have a nested treee.

this has a number of pros and cons.
the main cons being that nova need to contuie have non trivial filters and we will need to have
a limited abount of info in the resouce tracker(basically list of placemente RP uuids per numa node)
another con is that some of the allocation candiate returned will be invalid so it makes using limit
tricker but we can run out of allocation candiate already today because of filters so its not really any different.

on the pros side the placmenet team coudl focus on things it deem more important such as requirement from
projectes other then nova like shared storage. another pro of this would be we can still use placement for capsity and
traits and i also think its doable in train. the flat 2 level tree we create with vgpus or bandwith RPs can be used
for a lot of other usecases like jsut tracking sriov device, persitent memeory, cache basically any resouce that
you have multiple pools of on a comptue node can be tracked with just two levels. is we alway use group_policy=none
we can figutre out on the client side if the allcoation candiate meets our other constratis.

long term i think there is value in have richer query syntax in placement but if we need to pause
that to think about it some more, i think that is an ok viewpoint to express. i would personally prefer to
have a clean way to express requrement that is maintainable and does not tie our hands going forward.
again with that said if we decised not to use placment for numa in train i hope we can pusue using the
facilities that we already have to make some progress instead and not block those efforst on "we shoudl do this with
placemetn" if we have decided not to do them in placement in train. i know alot of nova folks
wont like that as it means we have to keep some of the complexity in nova but i would at least like to have
that conversation.

> I feel it is important that I get this off my chest and I encourage
> anyone else who has internal voices that don't feel enitirely
> appropriate go ahead and let them out as part of this pre-PTG email
> process. We are much more likely in the long term to be able to get
> things done in a useful fashion if we are able to honestly
> flush/vent such concerns in "public" and safely.
> 
> Because a lot of this stuff is the reality that we have and a
> situation that we need to solve. We can achieve the goals better by
> building up a shared language of what it is. That language includes
> the shit as well as the shine.
> 
> All that stuff above that I don't like at some gut level, I do like
> (or at least appreciate the value of) at a more practical level.
> 
> -- 
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent



From cdent+os at anticdent.org  Thu Apr 11 12:37:09 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 13:37:09 +0100 (BST)
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
In-Reply-To: <CAF7gwdickZGtJ_jELqX3pToiUz+P_E1a28Y6FJN8y7qox4E6Qg@mail.gmail.com>
References: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
 <7c73651f-d878-a784-ae84-79486919bc24@redhat.com>
 <CAF7gwdickZGtJ_jELqX3pToiUz+P_E1a28Y6FJN8y7qox4E6Qg@mail.gmail.com>
Message-ID: <alpine.OSX.2.11.1904111324330.33106@seed.local>

On Wed, 10 Apr 2019, Julia Kreger wrote:
> On Tue, Apr 9, 2019 at 9:58 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> On 4/9/19 1:56 PM, Chris Dent wrote:
>>>
>>> The etherpad [1] doesn't have any additional notes besides the topic
>>> but the general questions are:
>>>
>>> * Do people want to do baremetal reservations with some combination
>>>    of Ironic, Placement and Blazar, now or ever?
>>
>> There was at least one person at the Berlin Ops meetup who wanted this.
>
> Neat, I've spoken to a few US based operators that are also interested
> in this. Perhaps it we should allocate some time to the topic? It is
> looking like there is some time for Saturday to enable smaller groups
> of contributors to have focused area specific discussions.

There are plans for Saturday morning, but we've also got this
virtual pre-ptg [1] thing going on so we can get on the same page
before then, and even get rid of some pages that we resolve.

So if people have thoughts about ironic+placement, or
ironic+blazar+placement it would be great to talk about them in
some of the email threads that have started (this one and [2]).

How about we say "start of day Saturday" is placement+ironic+blazar
in the placement room?

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004225.html
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004729.html

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Thu Apr 11 12:39:08 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 13:39:08 +0100 (BST)
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
Message-ID: <alpine.OSX.2.11.1904111338040.33106@seed.local>

On Wed, 10 Apr 2019, Eric Fried wrote:

> Today we've got the principle of "don't do that," which we've expressed
> in the docs:
>
> https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits
>
> Trying to enforce those principles programmatically beyond what we've
> already done is going to be tricky, and as long as operators behave and
> read the docs (even if it's after we've marked their bug report as
> Invalid with the above link), mork work than benefit.
>
> So I'm going to vote "do nothing for now".

I'm kinda there too, but aspiers put the stuff on the etherpad and
seemed to have some concerns, hopefully he'll join in here.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From balazs.gibizer at ericsson.com  Thu Apr 11 12:42:44 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Thu, 11 Apr 2019 12:42:44 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
Message-ID: <1554986561.23392.2@smtp.office365.com>



On Wed, Apr 10, 2019 at 5:37 PM, Eric Fried <openstack at fried.cc> wrote:
>>  So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA 
>> requires
>>  placement to support traits on RPs that are not providing resources.
>>  Will in this case VCPU and MEMORY_MB always requested in the 
>> unnumbered
>>  group still? Or there are cases when those resources are requested 
>> in a
>>  numbered group?
> 
> That'll depend on the outcome of the various NUMA modeling 
> discussions;
> but as soon as we need to be able to request resources from more than
> one NUMA node, it seems certain that we'll need to use numbered 
> groups.


Then we need two steps:
1) handle RPs that only have traits but not resources
2) allow having the numbered request groups specify only a trait 
without requesting resources.

Cheers,
gibi

> 
> efried
> .
> 



From cdent+os at anticdent.org  Thu Apr 11 12:55:20 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 13:55:20 +0100 (BST)
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
Message-ID: <alpine.OSX.2.11.1904111348350.33106@seed.local>

On Wed, 10 Apr 2019, Eric Fried wrote:

> This suggests a change whereby we move a bunch of module-level methods
> to instance methods. I actually really like that idea. So for example:
>
> @db_api.placement_context_manager.writer
> def _set_traits(context, rp, traits):
>     ...
>
> becomes:
>
> class ResourceProvider(object):
>     ...
>     @db_api.placement_context_manager.writer
>     def _set_traits(self, traits):
>         ...
>         # the artist formerly known as 'rp' is now 'self'
>         # and context is self._context
>
> How do folks feel about us making this change?

In the absence of other ideas I'm fine with this because of what I
said before: I care most that the code get visited often.

My main reservation with this suggestion is that it moves some
things in the opposite direction from what I would prefer: I'd like
to see (file-based) separation between those methods which are
`db_api.placement_context_manager` and those that are not. Or, in
other terms: sql generation in other files.

This would allow us to have what amounts to three tiers:

* web stuff
* mumble (might call it controller, but that's not quite right)
* sql stuff

which I feel provides good contextual cues and affords some
opportunities for more robust testing of the sql generation.

However, it might be more pain than it is worth as we currently have
quite a bit of set() management mixed with sql management.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Thu Apr 11 13:22:31 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 11 Apr 2019 14:22:31 +0100 (BST)
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <b88719bfe208fe7455b511c91a10dcc4d79771db.camel@redhat.com>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
 <alpine.OSX.2.11.1904111156530.33106@seed.local>
 <b88719bfe208fe7455b511c91a10dcc4d79771db.camel@redhat.com>
Message-ID: <alpine.OSX.2.11.1904111415270.33106@seed.local>

On Thu, 11 Apr 2019, Sean Mooney wrote:
> long term i think there is value in have richer query syntax in placement but if we need to pause
> that to think about it some more, i think that is an ok viewpoint to express. i would personally prefer to
> have a clean way to express requrement that is maintainable and does not tie our hands going forward.
> again with that said if we decised not to use placment for numa in train i hope we can pusue using the
> facilities that we already have to make some progress instead and not block those efforst on "we shoudl do this with
> placemetn" if we have decided not to do them in placement in train. i know alot of nova folks
> wont like that as it means we have to keep some of the complexity in nova but i would at least like to have
> that conversation.

I think the pros you present (and other have presented) are (and
have been) strong enough that doing NUMA via nested-in-placement is
the right way to go. The gist of my prior rant is not so much that I
don't like nested but that I don't like the reasons for its
existence (NUMA and other hardware awarenesses) and the costs from
those reasons. The resolve is: I have to get past that; it's what
we've got. Since that's what we've got may as well be placement that
makes it cleaner. It's good for that sort of thing.

But it also means that I will sometimes be compelled to defend the
simpler way, as at the "horrible idea" in my comment at
https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst at 182

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From jaypipes at gmail.com  Thu Apr 11 13:24:19 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Thu, 11 Apr 2019 09:24:19 -0400
Subject: [nova] indices on shadow-able fields
In-Reply-To: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
References: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
Message-ID: <17fd398f-18ef-32e1-9c72-527bb97a9661@gmail.com>

On 04/08/2019 10:51 PM, Mohammed Naser wrote:
> Hi everyone.
> 
> In continuing with the trend of interesting database issues, I've
> found the following interesting thing.  It looks like we don't have
> indices for all of our tables that can be large on the deleted field.
> I think it would be beneficial *especially* for cases when the
> archiving code runs.
> 
> The big ones that are huge users in terms of rows without index are
> `instance_system_metadata` and `instance_extra`.
> `instance_action_events` and `instance_actions` don't have any either.
> 
> I believe without this, it results in doing a full table scan during
> the clean up which can become pretty resource intensive.

All of the queries that the archive tool performs look at the deleted 
column in various tables, yes. I suppose adding an index on the deleted 
column for the largest tables you listed above would provide some relief 
given the design of the existing archive tool.

Once the archive operation is performed, however, all rows in the table 
will have a deleted column value of 0. This generally makes the deleted 
column a poor choice for placing an index, since the cardinality of the 
column will be very low. [0] However, in this case, the index would 
build up over time (between archive tool runs) and be useful during 
archiving, and less useful immediately after the archive tool runs.

In short, feel free to create indexes on the deleted column for those 
tables and let us know whether they make a substantial difference in the 
performance of the archival tool. :)

Best,
-jay

[0] https://en.wikipedia.org/wiki/Cardinality_(SQL_statements)


From mnaser at vexxhost.com  Thu Apr 11 13:30:49 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 11 Apr 2019 09:30:49 -0400
Subject: [nova] indices on shadow-able fields
In-Reply-To: <17fd398f-18ef-32e1-9c72-527bb97a9661@gmail.com>
References: <CAEs876hrtvFVsY1EtHQFak2-PW8knXhnR+JgU4bunh7he+4z-Q@mail.gmail.com>
 <17fd398f-18ef-32e1-9c72-527bb97a9661@gmail.com>
Message-ID: <CAEs876gsKJrTz4D0UumZKqBXh4X2=-TeaKTf7+n+gCYHxuhDLw@mail.gmail.com>

On Thu, Apr 11, 2019 at 9:27 AM Jay Pipes <jaypipes at gmail.com> wrote:
>
> On 04/08/2019 10:51 PM, Mohammed Naser wrote:
> > Hi everyone.
> >
> > In continuing with the trend of interesting database issues, I've
> > found the following interesting thing.  It looks like we don't have
> > indices for all of our tables that can be large on the deleted field.
> > I think it would be beneficial *especially* for cases when the
> > archiving code runs.
> >
> > The big ones that are huge users in terms of rows without index are
> > `instance_system_metadata` and `instance_extra`.
> > `instance_action_events` and `instance_actions` don't have any either.
> >
> > I believe without this, it results in doing a full table scan during
> > the clean up which can become pretty resource intensive.
>
> All of the queries that the archive tool performs look at the deleted
> column in various tables, yes. I suppose adding an index on the deleted
> column for the largest tables you listed above would provide some relief
> given the design of the existing archive tool.
>
> Once the archive operation is performed, however, all rows in the table
> will have a deleted column value of 0. This generally makes the deleted
> column a poor choice for placing an index, since the cardinality of the
> column will be very low. [0] However, in this case, the index would
> build up over time (between archive tool runs) and be useful during
> archiving, and less useful immediately after the archive tool runs.
>
> In short, feel free to create indexes on the deleted column for those
> tables and let us know whether they make a substantial difference in the
> performance of the archival tool. :)

Hi Jay,

Thanks for all the feedback, I appreciate your insight into SQL that's way
beyond my "it's slow, index is the fix?!" scope :)

I'll try to see if I can get some before/after numbers.

Thanks,
Mohammed

> Best,
> -jay
>
> [0] https://en.wikipedia.org/wiki/Cardinality_(SQL_statements)
>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From rosmaita.fossdev at gmail.com  Thu Apr 11 13:41:50 2019
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 11 Apr 2019 09:41:50 -0400
Subject: [glance] Listing all images with a set of custom properties
In-Reply-To: <4bb9cec7-93cf-bef2-778d-106215097b05@intel.com>
References: <4bb9cec7-93cf-bef2-778d-106215097b05@intel.com>
Message-ID: <d20f177c-5aa8-8125-9dad-c1a5eea5b952@gmail.com>

On 4/10/19 8:42 PM, Nadathur, Sundar wrote:
> I am looking for a way to programmatically get all images that have been
> associated with a set of custom properties. Ideally, I should be able to
> say 'give me all images that have key1=value1, key2=value2, etc.

Create a dict of the properties you are interested in, for example,

  filters = {'key1': 'value1', 'key2': 'value2'}

and then pass it as the value of the 'filters' argument to the 'list' call:

  image_list_generator = glance.list(filters=filters)

You can have both "regular" and custom image properties as keys in the
filters dict.

> Failing that, at least get all images that have the named keys key1,
> key2, etc. irrespective of their values, so I can filter for the values
> myself.

I don't think there's a way to do this, actually.  I'm pretty sure it's
not supported by the Images API.

> I was looking at [1], specifically [2], and came up short. Any
> recommendations?
> 
> [1]
> https://github.com/openstack/python-glanceclient/tree/master/glanceclient/v2
> 
> 
> [2]
> https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L86

It shows up a bit later:
https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L136

> Regards,
> 
> Sundar

cheers,
brian



From rosmaita.fossdev at gmail.com  Thu Apr 11 14:07:26 2019
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 11 Apr 2019 10:07:26 -0400
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
Message-ID: <20693c9f-7548-e55a-764a-dcbdfcc5d3b0@gmail.com>

On 4/7/19 5:35 PM, Mohammed Naser wrote:
> Hi everyone,
> 
> Something that I've been dealing with is the fact that regardless of
> what cloud you're using, the naming structure is very much different.
> While we aim to be interoperable, if I want to "boot an Debian Stretch
> server", the image name will probably be different all over the
> places.
> 
> Is there some sort of way we can eliminate this by implementing a
> standard naming convention which would allow us to use the same images
> across all systems?
> 
> I'm just opening the idea for discussion, I'd love to hear what others
> think about this.
> 
> Mohammed
> 

Sorry to be late to the discussion.  We've had Forum/PTG sessions on
this, and while everyone agrees that something needs to be done, it's
difficult to standardize on what.  The key takeaway has been to use some
combination of the common image properties (as Tim suggests).  The
upside is that these are propagated by the nova image-create action
(unless they're ruled out by the nova non_inheritable_image_properties
config), and so a user snapshot will have the os_distro and os_version
on them, so this info won't be lost by an image rename.  (The naming
scheme Fei Long describes is a clever way to get this info into the
image name, but it has the downside that it will be lost on user snapshots.)

If the current common image properties aren't sufficient, it's easy to
extend them because under the hood they're simply custom image
properties for which people have agreed on a name and (more or less)
what the value should be.  For example, a 'description' property was
added in the Stein release.

Also, just a reminder that "hidden" images were introduced in Rocky via
the 'os_hidden' image property; they allow you to make only your most
recent public images show up by default in a users' image-list calls.

cheers,
brian


From yedhusastri at gmail.com  Thu Apr 11 14:10:05 2019
From: yedhusastri at gmail.com (Yedhu Sastri)
Date: Thu, 11 Apr 2019 16:10:05 +0200
Subject: RuntimeError: OVS transaction timed out - After minor upgrade
In-Reply-To: <e1656593-df71-53cb-bb55-0aab7fbcf963@redhat.com>
References: <CANX8mtJrWQGAiwGa=y19put+gst9WcW_Ya_9aGUAGC4C2abEng@mail.gmail.com>
 <e1656593-df71-53cb-bb55-0aab7fbcf963@redhat.com>
Message-ID: <CANX8mtLNpnYQbrbecddB=eizascaU+LDcW4Rd+d1aEGeh33OLA@mail.gmail.com>

Dear All,

We were able to solve the issue. The problem was after the reboot rabbitmq
is overloaded because ceilometer started after the reboot which was in
stopped state. Due to this the controller nodes resource utilization was
very high and cpu cores maxed out. As a result we got timeouts in our
neutron and rabbitmq logs. We stopped the ceilometer components both on
controllers and compute nodes, cleaned the ceilometer queues from rabbitmq,
emptied the ovsdb and restarted the neutron components in all the
controllers. Then slowly all the tags in ports are recovered and VM's are
reachable.

On Wed, Apr 10, 2019 at 7:15 PM Jakub Libosvar <jlibosva at redhat.com> wrote:

> Is your ovs-vswitchd process running on controllers? Sounds like agent
> can talk to ovsdb (it was able to connect) but then times out when
> waiting for response from vswitchd process.
>
> Do these command run successfully on the problematic controller?
> ovs-vsctl show
> ovs-ofctl show br-int
>
> Kuba
>
> On 10/04/2019 14:20, Yedhu Sastri wrote:
> > Dear All,
> >
> > We did a minor upgrade on our OpenStack environment Newton HA cluster
> from
> > 14.2.12 to 14.2.16 using the following link.
> >
> >
> https://docs.openstack.org/openstack-ansible/newton/upgrade-guide/minor-upgrade.html
> >
> > The upgrade was successful and we tested creation of VM's and it was also
> > successful we were able to ssh into the VM's.
> >
> > Then we rebooted the controllers one by one. But after that we can create
> > the VM's but it is not getting IP from dhcp agent.
> >
> > In the openvswitch-agent.log we are getting 'OVS transaction timeout'.
> Any
> > help is much appreciated.
> >
> > 2019-04-09 17:25:29.063 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> > net_uuid None not managed by VLAN manager
> > 2019-04-09 17:25:29.088 3504 INFO neutron.agent.common.ovs_lib
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> > 04275c8a-2d12-477b-b435-f6483d418e93 not present in bridge br-int
> > 2019-04-09 17:25:29.089 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> > net_uuid None not managed by VLAN manager
> > 2019-04-09 17:25:29.198 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> > net_uuid None not managed by VLAN manager
> > 2019-04-09 17:25:29.228 3504 INFO neutron.agent.common.ovs_lib
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> > 5c25b580-9dcb-4930-a2fe-9cab951114dd not present in bridge br-int
> > 2019-04-09 17:25:29.228 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound():
> > net_uuid None not managed by VLAN manager
> > 2019-04-09 17:25:29.229 3504 INFO neutron.agent.securitygroups_rpc
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Remove device filter
> > for [u'63cb0c6a-6e82-41a8-ad46-511ee84579ad',
> > u'9764e98a-bb32-4d37-9460-5a546f351e5a',
> > u'2c075f29-156c-4787-b40f-434c437164e4',
> > u'f00de46f-301a-4789-add1-a8239ee6c859',
> > u'e26c1806-8041-4ce2-aea0-74ca469add67',
> > u'9fa17447-d25d-441b-9983-b81e43c6e6d2',
> > u'3ef24ce6-19b5-47c8-9510-767e64d33e9f',
> > u'c2d37add-65a0-4fc9-914c-2382af70b1ca',
> > u'a8b7c7aa-a5d0-47b3-a944-7b6c4428eda8',
> > u'bf6f7608-0573-43f7-822a-878d7708d985',
> > u'046670cd-77dd-4ce8-bb4b-f1489264375b',
> > u'b7aefa18-d768-47a8-bb5f-6b1e838deaeb',
> > u'04275c8a-2d12-477b-b435-f6483d418e93',
> > u'124eb5e6-2b8a-44a9-aa8b-f6d9bc87f13f',
> > u'5c25b580-9dcb-4930-a2fe-9cab951114dd']
> > 2019-04-09 17:27:09.740 3504 INFO neutron.agent.securitygroups_rpc
> > [req-5984df4b-c30f-403c-8e87-86c4ccf50a9f - - - - -] Provider rule
> updated
> > 2019-04-09 17:27:41.961 3504 INFO neutron.agent.securitygroups_rpc
> > [req-67c36a44-f778-48f0-b7ae-0a5244ff95c1 - - - - -] Provider rule
> updated
> > 2019-04-09 17:28:28.334 3504 INFO neutron.agent.securitygroups_rpc
> > [req-aeffc24f-a354-412e-b458-950c1d4b52ef - - - - -] Provider rule
> updated
> > 2019-04-09 17:28:46.276 3504 INFO neutron.agent.securitygroups_rpc
> > [req-2dd51325-40c4-4ff0-a384-bccbe3ca0bfc - - - - -] Provider rule
> updated
> > 2019-04-09 17:28:46.278 3504 INFO neutron.agent.securitygroups_rpc
> > [req-6d48bfd9-0230-4a82-a477-d9e4171db519 - - - - -] Provider rule
> updated
> > 2019-04-09 17:30:32.695 3504 INFO neutron.agent.securitygroups_rpc
> > [req-01b9b7a8-84a4-42cc-aebb-db846eb2b8f0 - - - - -] Provider rule
> updated
> > 2019-04-09 17:30:54.288 3504 INFO neutron.agent.securitygroups_rpc
> > [req-de1755bd-0e21-4b75-9fde-db422ee9a79a - - - - -] Provider rule
> updated
> > 2019-04-09 17:32:12.377 3504 INFO neutron.agent.securitygroups_rpc
> > [req-26bc4547-edb7-4092-b4f4-6465c29dfbe4 - - - - -] Provider rule
> updated
> > 2019-04-09 17:32:21.444 3504 WARNING
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Device
> > 0d535260-dd98-4027-a2ba-4c5412d4eab0 not defined on plugin or binding
> failed
> > 2019-04-09 17:32:21.461 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> > d3baa557-a367-4a6d-8d58-7183df4243a6 updated. Details: {u'profile': {},
> > u'network_qos_policy_id': None, u'qos_policy_id': None,
> > u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> > u'680c9bdd-9cea-4059-8c8c-2928dd0ee48f', u'segmentation_id': 65606,
> > u'device_owner': u'network:router_ha_interface', u'physical_network':
> None,
> > u'mac_address': u'fa:16:3e:b3:9a:60', u'device':
> > u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'port_security_enabled': False,
> > u'port_id': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'fixed_ips':
> > [{u'subnet_id': u'5b49f8e5-991d-4ecd-a584-df605063aecb', u'ip_address':
> > u'169.254.192.9'}], u'network_type': u'vxlan'}
> > 2019-04-09 17:32:21.461 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 1 as local
> > vlan for net-id=680c9bdd-9cea-4059-8c8c-2928dd0ee48f
> > 2019-04-09 17:32:35.477 3504 INFO oslo_messaging._drivers.amqpdriver [-]
> No
> > calling threads waiting for msg_id : a9314d944ff8486abf909d4cc271f9a0
> > 2019-04-09 17:32:39.016 3504 INFO neutron.agent.securitygroups_rpc
> > [req-51453b2c-b454-45bd-b7f8-c78560437016 - - - - -] Provider rule
> updated
> > 2019-04-09 17:32:54.141 3504 ERROR
> > neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Switch connection
> > timeout
> > 2019-04-09 17:32:57.964 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Bridge br-tun
> changed
> > its datapath-ID from 6a740a5da349 to 00006a740a5da349
> > 2019-04-09 17:32:58.015 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> > 0d8dc3c9-c115-45f8-bbb2-cc715b7c1079 updated. Details: {u'profile': {},
> > u'network_qos_policy_id': None, u'qos_policy_id': None,
> > u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> > u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
> > u'device_owner': u'network:router_gateway', u'physical_network':
> > u'outbound1', u'mac_address': u'fa:16:3e:aa:d7:56', u'device':
> > u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'port_security_enabled': False,
> > u'port_id': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'fixed_ips':
> > [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
> > u'10.97.179.34'}], u'network_type': u'vlan'}
> > 2019-04-09 17:32:58.016 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 2 as local
> > vlan for net-id=4ffb2c28-f9f1-4a25-82a0-df7f7a002434
> > 2019-04-09 17:32:58.030 3504 INFO
> > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port
> > 1239fa6c-265a-4f16-ab00-c86fe40545d9 updated. Details: {u'profile': {},
> > u'network_qos_policy_id': None, u'qos_policy_id': None,
> > u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id':
> > u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625,
> > u'device_owner': u'network:router_gateway', u'physical_network':
> > u'outbound1', u'mac_address': u'fa:16:3e:4d:73:46', u'device':
> > u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'port_security_enabled': False,
> > u'port_id': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'fixed_ips':
> > [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address':
> > u'10.97.179.99'}], u'network_type': u'vlan'}
> > 2019-04-09 17:33:13.289 3504 ERROR neutron.agent.ovsdb.impl_idl
> > [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Traceback (most
> recent
> > call last):
> >   File
> >
> "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/native/connection.py",
> > line 117, in run
> >     txn.results.put(txn.do_commit())
> >   File
> >
> "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py",
> > line 91, in do_commit
> >     raise RuntimeError(_("OVS transaction timed out"))
> > RuntimeError: OVS transaction timed out
> >
> >
> >
>
>
>

-- 

With kind regards,
Yedhu Sastri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/89b8867e/attachment-0001.html>

From aspiers at suse.com  Thu Apr 11 14:10:57 2019
From: aspiers at suse.com (Adam Spiers)
Date: Thu, 11 Apr 2019 15:10:57 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <alpine.OSX.2.11.1904111338040.33106@seed.local>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
Message-ID: <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>

Chris Dent <cdent+os at anticdent.org> wrote: 
>On Wed, 10 Apr 2019, Eric Fried wrote: 
>>Today we've got the principle of "don't do that," which we've expressed 
>>in the docs: 
>>
>>https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits 
>>
>>Trying to enforce those principles programmatically beyond what we've 
>>already done is going to be tricky, and as long as operators behave and 
>>read the docs (even if it's after we've marked their bug report as 
>>Invalid with the above link), mork work than benefit. 
>>
>>So I'm going to vote "do nothing for now". 
>
>I'm kinda there too, but aspiers put the stuff on the etherpad and 
>seemed to have some concerns, hopefully he'll join in here. 

Not so much concerns as just trying to make sure we don't miss an 
opportunity to discuss something in person which seemed to cause 
multiple discussions / redesigns over many months.  For example would 
it be worth considering tweaking the placement API so that only the 
driver can set/unset traits which it owns?  This would avoid the 
corner case conflict we currently have where a naughty admin messes 
around with driver traits on RPs. 

But I'm also fine with "do nothing for now", if that's the current 
consensus.  Although perhaps it would be better to at least spend 5 
minutes finding a good place in the docs to insert the Venn diagram: 

    https://pasteboard.co/I3iqqNm.jpg


From jeremyfreudberg at gmail.com  Thu Apr 11 14:20:14 2019
From: jeremyfreudberg at gmail.com (Jeremy Freudberg)
Date: Thu, 11 Apr 2019 10:20:14 -0400
Subject: [sahara][ptg] Preliminary poll for scheduling Sahara virtual PTG
In-Reply-To: <CAFntmShsrvG4ROx_vMGngbDW-AQpaL3jruedMoTVtUXhUz1mzg@mail.gmail.com>
References: <CAFntmShsrvG4ROx_vMGngbDW-AQpaL3jruedMoTVtUXhUz1mzg@mail.gmail.com>
Message-ID: <CAFntmShZYE0VkLkhSJPJ7F4Z2_9exn4wTTXutYjcOQVbjyoE8A@mail.gmail.com>

Hello again,

Availability will be instead tracked here:
https://www.when2meet.com/?7751227-lVJDN
(In case the site gets weird, the start and end time for each day
should be 13utc to 23utc)

On Wed, Apr 10, 2019 at 4:10 PM Jeremy Freudberg
<jeremyfreudberg at gmail.com> wrote:
>
> Hello Saharans and other interested parties:
>
> For the Train cycle our PTG will only be virtual.
> I have assembled here some possible days on which to hold the virtual PTG:
> https://doodle.com/poll/228ppwvqg488n3c5
>
> We'll probably meet for about 2 hours on Bluejeans (DESPITE the poll
> the showing huge chunks of time). There'll be an Etherpad and outcomes
> will be logged to this mailing list too. All are welcome.
>
> Best,
> Jeremy


From massimo.sgaravatto at gmail.com  Thu Apr 11 14:34:00 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Thu, 11 Apr 2019 16:34:00 +0200
Subject: [horizon] Cinder API version in Horizon
Message-ID: <CALaZjRG+h+FvRKtgKqdCZom0VR=LBg=GeiF4tPrNAAnZqNxuBQ@mail.gmail.com>

Hi

If Horizon uses Cinder API v3 by default since Queens ([1])], why does the
installation guide for Horizon [2] suggest to set in local_settings the v2
api for volume ?

OPENSTACK_API_VERSIONS = {
    "identity": 3,
    "image": 2,
    "volume": 2,
}


[1] https://docs.openstack.org/releasenotes/horizon/queens.html
[2] https://docs.openstack.org/horizon/rocky/install/install-rdo.html

Thanks, Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/9db94c6f/attachment.html>

From e0ne at e0ne.info  Thu Apr 11 14:47:04 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Thu, 11 Apr 2019 17:47:04 +0300
Subject: [horizon] Cinder API version in Horizon
In-Reply-To: <CALaZjRG+h+FvRKtgKqdCZom0VR=LBg=GeiF4tPrNAAnZqNxuBQ@mail.gmail.com>
References: <CALaZjRG+h+FvRKtgKqdCZom0VR=LBg=GeiF4tPrNAAnZqNxuBQ@mail.gmail.com>
Message-ID: <CAGocpaG8WgoZmw+ba9rZuopME4T-+FCdbd+HRcjBUfohz+96sw@mail.gmail.com>

Hi Massimo,

Thanks for pointing that out. I proposed a patch [3] to fix this.

[3] https://review.openstack.org/651804

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


On Thu, Apr 11, 2019 at 5:35 PM Massimo Sgaravatto <
massimo.sgaravatto at gmail.com> wrote:

> Hi
>
> If Horizon uses Cinder API v3 by default since Queens ([1])], why does the
> installation guide for Horizon [2] suggest to set in local_settings the v2
> api for volume ?
>
> OPENSTACK_API_VERSIONS = {
>     "identity": 3,
>     "image": 2,
>     "volume": 2,
> }
>
>
> [1] https://docs.openstack.org/releasenotes/horizon/queens.html
> [2] https://docs.openstack.org/horizon/rocky/install/install-rdo.html
>
> Thanks, Massimo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/b7bb625a/attachment.html>

From zbitter at redhat.com  Thu Apr 11 14:49:25 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Thu, 11 Apr 2019 10:49:25 -0400
Subject: [tricircle][heat] Tricircle or Trio2o
In-Reply-To: <CABNtRWuSCA1o8xXreH4GnxAUS+xbWcAkQ6L=Z+g2Tu6mWz7cBA@mail.gmail.com>
References: <CABNtRWuSCA1o8xXreH4GnxAUS+xbWcAkQ6L=Z+g2Tu6mWz7cBA@mail.gmail.com>
Message-ID: <1e06e46a-56f2-cebb-9dbe-a14ca62864c2@redhat.com>

On 1/08/18 12:55 PM, Andrea Franceschini wrote:
> Actually a heat multisite solution would work too, but I cannot find
> any  reference to this kind of solutions.

You can use the OS::Heat::Stack resource to create stacks in remote 
regions: 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::Stack

In Stein you can also use it to create stacks in remote clouds (note: 
requires Barbican in the local cloud, and of course Heat in the remote 
cloud). Full docs for that haven't landed yet but they're in review 
here: https://review.openstack.org/649220

cheers,
Zane.


From juliaashleykreger at gmail.com  Thu Apr 11 14:56:51 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Thu, 11 Apr 2019 07:56:51 -0700
Subject: [ironic][ptg] Schedule/Team gathering
In-Reply-To: <20e15025-d698-bd01-c117-f7d543f4d354@redhat.com>
References: <CAF7gwdjhcDLzkrobA1-=0QrD5Prz_xd24M61SR8wAC69_mdXMQ@mail.gmail.com>
 <20e15025-d698-bd01-c117-f7d543f4d354@redhat.com>
Message-ID: <CAF7gwdh9Bs_VQZ2Q4CMYsbOQSUPO0u2GHLJJXunuYNjRxMAWKQ@mail.gmail.com>

On Thu, Apr 11, 2019 at 3:34 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> On 4/10/19 7:38 PM, Julia Kreger wrote:
> > Greetings fellow ?Ironicans?
> >
> > I've posted a new etherpad[0] based upon our discussion in the
> > planning etherpad[1]. Please review and if there are any scheduling
> > issues please let me know.
>
> I suspect Community Sustainability will take longer than planned. Otherwise
> looks great, thanks for composing it!
>

That was my fear as well, but I decided to error on the side of time
boxing in a sense because we don't want to really create runaway
conversations. I think it is also going to entirely depend on the mood
and how much coffee is in the room. :)

> >
> > Also, we need to figure out an evening for a team gathering. I've
> > posted a doodle[3]. Please submit it with-in the next few days and
> > I'll begin looking around for someplace that might work.
>
> Do we know when the official events will take place? I'm only aware of the
> marketplace event on Monday.
>

I think there is something on Tuesday night, but I'm not entirely
sure. Ultimately I think we're going to have to avoid Monday/Tuesday.

> >
> > Thanks everyone!
> >
> > -Julia
> > [0]: https://etherpad.openstack.org/p/DEN-train-ironic-ptg
> > [1]: https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
> > [2]: https://doodle.com/poll/e6q5e6pm72wbiwtz
> >
>
>


From openstack at fried.cc  Thu Apr 11 14:58:24 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 09:58:24 -0500
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
Message-ID: <790e77af-b5b3-7e45-5bdc-30adcdf61c7a@fried.cc>

> be worth considering tweaking the placement API so that only the driver
> can set/unset traits which it owns?

This would entail placement tracking some kind of "owner" attribute
(ahem, metadata) on traits. Or maintaining a list of driver-owned traits
per resource provider. Or <your idea here>. And then a way to establish
a different identity/policy for the virt driver than for the admin. And
then a way for the admin to override that anyway because stuff happens.

That ^, IMO, is the "more work than benefit" I led with. Happy to be
convinced otherwise if there's a (*much*) simpler way to achieve the
desired goal.

> Although perhaps it would be better to at least spend 5
> minutes finding a good place in the docs to insert the Venn diagram:
>    https://pasteboard.co/I3iqqNm.jpg

Yes please. Bottom of [1] seems like the right place.

But for heaven's sake, don't violate my privacy [2].

efried

[1]
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits
[2]
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4651


From emilien at redhat.com  Thu Apr 11 14:59:00 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 11 Apr 2019 10:59:00 -0400
Subject: [tripleo] tripleoclient stable/stein is now branched
Message-ID: <CACu=hyt2ZN9ZAQLWsUj8fmKRixYt74Z_EJqSji_gUJR8_uGMcA@mail.gmail.com>

1) Make sure you do the backports to stable/stein as usual, when needed.

2) We'll branch the rest of TripleO projects once we know CI works fine on
this branch and once we are sure no blockers hit current master.

Thanks,
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/ff8352d0/attachment.html>

From mriedemos at gmail.com  Thu Apr 11 15:00:24 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 11 Apr 2019 10:00:24 -0500
Subject: [nova] instance breaks the affinity/anti-affinity of server group
 with force_hosts or force_nodes
In-Reply-To: <7ae304cf.7cbe.169c76b085d.Coremail.bxzhu_5355@163.com>
References: <cafaceb.89b4.1697aad1219.Coremail.bxzhu_5355@163.com>
 <6d910983-3a5d-f0de-f5bc-8248bc6cb25e@gmail.com>
 <3a66b17a.bcc1.1697c84a125.Coremail.bxzhu_5355@163.com>
 <74840989-6925-5792-670d-0cdf549bd5bd@gmail.com>
 <6692b7f6-1f5c-ee4e-5ac8-414d1b6e0617@gmail.com>
 <7ae304cf.7cbe.169c76b085d.Coremail.bxzhu_5355@163.com>
Message-ID: <f51c4682-550f-36c7-a2fd-91486a59fe0e@gmail.com>

On 3/28/2019 10:07 PM, Boxiang Zhu wrote:
> 
> BTW, as you mentioned at the early email, the az:host:node format is an 
> admin API.
> Maybe we can add a micro version for booting API to evaluate the filters 
> even with
> forced_host/forced_node. I have post a draft spec to the nova-spec[2]. 
> If anyone is
> convenient, welcome to review and give some comments. : )
> 
> 
> [1] https://docs.openstack.org/nova/latest/user/filter-scheduler.html
> [2] https://review.openstack.org/#/c/645458/

Just an update on this but I'm +2 on the proposed spec for this now. I'd 
suggest we get some more cores on board with the spec though before it's 
approved so that not just two people (me and whoever approves) are aware 
of the proposal.

-- 

Thanks,

Matt


From zbitter at redhat.com  Thu Apr 11 15:05:06 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Thu, 11 Apr 2019 11:05:06 -0400
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
Message-ID: <565c86cc-05f5-cb5c-be52-e88a8dc8be2d@redhat.com>

On 9/04/19 6:01 PM, Eric Fried wrote:
> In the meantime, while there is still a significant gap between the
> in-tree and out-of-tree versions, it definitely makes sense for the
> *-powervm projects to have their own core team(s) and PTL.

I agree with Tony that this part doesn't necessarily follow. Of course 
the repos should continue to have their own core team, and that's 
completely possible while being under Nova's governance. I'm sure that 
the release team can cope with having separate liaisons for different 
sets of repos within a projects (even though I'm sure they'd appreciate 
not having a different liaison for e.g. every repo in OpenStack ;).

It sounds like moving the PowerVM repos under Nova's governance would be 
a topic worthy of active discussion between the two projects.

cheers,
Zane.


From ed at leafe.com  Thu Apr 11 15:51:43 2019
From: ed at leafe.com (Ed Leafe)
Date: Thu, 11 Apr 2019 10:51:43 -0500
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <BAE730FF-81FA-4C10-9663-A772539768F3@us.ibm.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <4b7a8de3-f1f1-dc25-590b-03bd3bd0bd9f@openstack.org>
 <BAE730FF-81FA-4C10-9663-A772539768F3@us.ibm.com>
Message-ID: <9EA8B36C-E637-48B2-876A-A5BB246EAB10@leafe.com>

On Apr 9, 2019, at 8:18 AM, William M Edmonds - edmondsw at us.ibm.com <edmondsw at us.ibm.com> wrote:
> 
> Honest question, what SIGs produce code in repos that they own/maintain separate from nova, etc.? Point me to those repos so we can talk examples?

The API-SIG has its own repo: https://github.com/openstack/api-sig


-- Ed Leafe







From colleen at gazlene.net  Thu Apr 11 15:52:38 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Thu, 11 Apr 2019 11:52:38 -0400
Subject: =?UTF-8?Q?Re:_[nova][cinder][keystone]__Unshelve_in_nova,
 _cinder_initial?= =?UTF-8?Q?ize=5Fconnection_with_user_context?=
In-Reply-To: <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>
References: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
 <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>
Message-ID: <98b89706-8426-4ebb-9726-63aaf245b274@www.fastmail.com>

Hello,

On Thu, Apr 11, 2019, at 01:25, Sean Mooney wrote:
> On Thu, 2019-04-11 at 16:04 +1200, Jordan Ansell wrote:
> > Hello,
> > 
> > I have encountered what appears to be an edge-case instance shelving
> > situation. I have to allow access to an internal API call to enable an
> > "unprivileged" user to perform an instance operation.
> > 
> > Specifically, I have a user with a "restricted permission" role in a
> > project, who should only be able to start/stop/shelve/unshelve an
> > existing instance. With sensible roles/actions in the nova policy, they
> > are able to perform all actions, except /un/shelving. This should be
> > controlled by a nova policy, however the user is unable to unshelve
> > without permission to access the /cinder/ API call
> > "initialize_connection()
> > <
> > https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initialize-volume-attachment-detail#initialize-volume-attachment
> > >".
> > Without granting permission to the user, cinder rejects nova's request
> > with an HTTP 403 status message.
> > 
> > Outcomes of this situation are, curious and potentially unwanted.
> > Curious being the user is able to /shelve/. Which leads to a point of no
> > return for the user. But of particular concern is this API call exposes
> > the backend storage driver's connection info to users. The RBD driver,
> > as we use, does not even require a populated "connector" object before
> > it replies.
> > 
> > I was looking for advice/opinions on this issue, and hope someone here
> > can help or direct me to the right place.
> > 
> > My thoughts were that perhaps this is a bug or there's a configuration
> > issue with our nova/cinder (note, i'm using mitaka, so maybe it's fixed
> > upstream!).
> > I am unable to check whether this is just a bug in nova, due to my lack
> > of experience. But my rationale is nova is using the /user//'s/ context
> > instead of an internal nova /admin/-like context to call the cinder API.
> > As for configuration, I've been unable to pull up anything that seems
> > relevant to this issue looking through
> > /etc/{nova,cinder}/{nova,cinder}.conf, but maybe there's an option we've
> > enabled that's led to this behavior.
> this is an interesting usecase and while this is not a part of the code
> i useually deal with i be live your understand is correct in that we try
> intentionally to use the users auth context wehre ever possible.
> 
> nova has/can have admin credential in its config for some service like
> cinder and neutron however for security reasons(primarily try to not store
> admin credentials on compute nodes) we try to not use the admin credentials.
> 
> 
> i dont know if we have a config knob you can change to modify this behavior.
> always using the admin credentials would be considerd an anti patteren
> but i also know that some work has been done in keystone with system tokens?
> servier tokens?  something like that may facilitate this usecase in the future.
> 
> hopefuly someone more knoladgeable in this area will chime in but in no 
> surprised
> that you have encountered issues with this configuration as it is not 
> tested in the gate.
> the default rule applie if its not tested assume its broken althohgh 
> untested feature
> do work more often then you would expect.

Forgive my unfamiliarity with the nova and cinder APIs but it sounds like the shelve operation in nova is a purely nova-side API, while the unshelve operation calls cinder's volume-attach API if the instance had a mounted volume before it was shelved. Since the operation involves cinder, you'd have to update the cinder policy to allow this unprivileged user to perform the volume-attach action. It's not really a bug, it's just fallout from having policies managed separately for separate services.

Keystone's work with system scope[1] wouldn't really apply here, if I understand the situation correctly, because attaching a volume is an action that is specific to a resource within a project (tenant), it's not an action that affects the deployment as a whole or spans across multiple projects.

Hope this helps.

[1] https://docs.openstack.org/keystone/latest/contributor/services.html#system-scope

Colleen

> > 
> > I'm happy to answer questions if anything is unclear. Sorry for
> > verbosity, vagueness or inaccuracies -- I'm very new to Openstack,
> > having started at zero a month ago and am using this task as a way to
> > learn more.
> > 
> > Any help is much appreciated :)
> > Jordan
> 
> 
>


From ed at leafe.com  Thu Apr 11 15:54:08 2019
From: ed at leafe.com (Ed Leafe)
Date: Thu, 11 Apr 2019 10:54:08 -0500
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
Message-ID: <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>

On Apr 11, 2019, at 9:10 AM, Adam Spiers <aspiers at suse.com> wrote:
> 
> Not so much concerns as just trying to make sure we don't miss an opportunity to discuss something in person which seemed to cause multiple discussions / redesigns over many months.  For example would it be worth considering tweaking the placement API so that only the driver can set/unset traits which it owns?  This would avoid the corner case conflict we currently have where a naughty admin messes around with driver traits on RPs. 

The concept of “owning” particular traits isn’t in Placement. Rather, it is in the domain of the service that is using Placement. So any enforcement regarding which traits are acceptable has to be on the calling end, not in the Placement API.

So yeah, “do nothing”.

-- Ed Leafe







From massimo.sgaravatto at gmail.com  Thu Apr 11 16:02:27 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Thu, 11 Apr 2019 18:02:27 +0200
Subject: [horizon] Cinder API version in Horizon
In-Reply-To: <CAGocpaG8WgoZmw+ba9rZuopME4T-+FCdbd+HRcjBUfohz+96sw@mail.gmail.com>
References: <CALaZjRG+h+FvRKtgKqdCZom0VR=LBg=GeiF4tPrNAAnZqNxuBQ@mail.gmail.com>
 <CAGocpaG8WgoZmw+ba9rZuopME4T-+FCdbd+HRcjBUfohz+96sw@mail.gmail.com>
Message-ID: <CALaZjREoGr=A9SoxVSaGziBR0zY3Hogv_WRbRr07B=KRiv6s9g@mail.gmail.com>

Thanks a lot !
Cheers, Massimo

On Thu, Apr 11, 2019 at 4:47 PM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> Hi Massimo,
>
> Thanks for pointing that out. I proposed a patch [3] to fix this.
>
> [3] https://review.openstack.org/651804
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Thu, Apr 11, 2019 at 5:35 PM Massimo Sgaravatto <
> massimo.sgaravatto at gmail.com> wrote:
>
>> Hi
>>
>> If Horizon uses Cinder API v3 by default since Queens ([1])], why does
>> the installation guide for Horizon [2] suggest to set in local_settings the
>> v2 api for volume ?
>>
>> OPENSTACK_API_VERSIONS = {
>>     "identity": 3,
>>     "image": 2,
>>     "volume": 2,
>> }
>>
>>
>> [1] https://docs.openstack.org/releasenotes/horizon/queens.html
>> [2] https://docs.openstack.org/horizon/rocky/install/install-rdo.html
>>
>> Thanks, Massimo
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/1286ecfc/attachment-0001.html>

From ed at leafe.com  Thu Apr 11 16:39:32 2019
From: ed at leafe.com (Ed Leafe)
Date: Thu, 11 Apr 2019 11:39:32 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <alpine.OSX.2.11.1904111348350.33106@seed.local>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
 <alpine.OSX.2.11.1904111348350.33106@seed.local>
Message-ID: <8DA526DE-AEC1-44B9-8E39-844D8BB14A20@leafe.com>

On Apr 11, 2019, at 7:55 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> My main reservation with this suggestion is that it moves some
> things in the opposite direction from what I would prefer: I'd like
> to see (file-based) separation between those methods which are
> `db_api.placement_context_manager` and those that are not. Or, in
> other terms: sql generation in other files.
> 
> This would allow us to have what amounts to three tiers:
> 
> * web stuff
> * mumble (might call it controller, but that's not quite right)
> * sql stuff
> 
> which I feel provides good contextual cues and affords some
> opportunities for more robust testing of the sql generation.
> 
> However, it might be more pain than it is worth as we currently have
> quite a bit of set() management mixed with sql management.

For a variety of reasons, most of which would be obvious given my previous enthusiasm for exploring alternatives, I’ve proposed a story for refactoring out the DB-specific code from the rest of placement:

https://storyboard.openstack.org/#!/story/2005435

I don’t know what everyone’s preference would be for where the DB code would go: either in private methods of the original module, or in a separate DB module, so I added as the first task coming to a decision on how to make that split.


-- Ed Leafe





From gmann at ghanshyammann.com  Thu Apr 11 16:40:55 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 11 Apr 2019 11:40:55 -0500
Subject: [cinder][qa] Skipped the unstable
 test_volume_backup_create_get_detailed_list_restore_delete
Message-ID: <16a0d460a11.d360caf9257721.8043587500742427296@ghanshyammann.com>

Hello Cinder team,

Test test_volume_backup_create_get_detailed_list_restore_delete is failing very frequently now a days.
19 fails in 24 hrs / 137 fails in 10 days [1]

I have skipped this test temproarly[2]. mriedem has pointed out the failure on review and cinder
channel also, please refer that for more details. 

Feel free to propose to unskip this test once the problem is fixed. 

[1] http://status.openstack.org/elastic-recheck/#1483434
[2] https://review.openstack.org/#/c/651660/ 

-gmann



From fungi at yuggoth.org  Thu Apr 11 16:43:31 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 11 Apr 2019 16:43:31 +0000
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <eba6d2403cc8d3ef5ac8b5afcfe412b90cdd2649.camel@redhat.com>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
 <20190410204432.u5e24yqglas5zxnv@yuggoth.org>
 <eba6d2403cc8d3ef5ac8b5afcfe412b90cdd2649.camel@redhat.com>
Message-ID: <20190411164331.ehypsw3u4k5x44sy@yuggoth.org>

On 2019-04-10 23:27:54 +0100 (+0100), Sean Mooney wrote:
[...]
> so after doing this if i clone directly i get
> 
> sean at pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova
> Cloning into 'nova'...
> warning: redirecting to https://opendev.org/openstack/nova/
> remote: Enumerating objects: 535171, done.
[...]

Perfect, that's git following the redirect just like we intend.

> and if i clone via a local squid proxy i get
> 
> sean at pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova
> Cloning into 'nova'...
> remote: Counting objects: 535171, done.
[...]
> so via the proxy i dont even see the redirct warning
[...]

This is probably normal. Does squid pay attention to your /etc/hosts
entries, or is it just going directly to DNS lookups? Also possible
that it cached earlier name lookups.

Thanks for helping test it for us!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/cf8ddfd9/attachment.sig>

From mriedemos at gmail.com  Thu Apr 11 16:50:06 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 11 Apr 2019 11:50:06 -0500
Subject: Proposal to move cinder backup tests out of the integrated gate
In-Reply-To: <ddf910da-cdd9-e696-0def-e4fae85ec4fe@gmail.com>
References: <ddf910da-cdd9-e696-0def-e4fae85ec4fe@gmail.com>
Message-ID: <3f15b8bc-9b5d-005b-2507-e8ff44d323a9@gmail.com>

On 12/12/2018 2:00 PM, Matt Riedemann wrote:
> I wanted to send this separate from the latest gate status update [1] 
> since it's primarily about latent cinder bugs causing failures in the 
> gate for which no one is really investigating.
> 
> Running down our tracked gate bugs [2] there are several related to 
> cinder-backup testing:
> 
> * http://status.openstack.org/elastic-recheck/#1483434
> * http://status.openstack.org/elastic-recheck/#1745168
> * http://status.openstack.org/elastic-recheck/#1739482
> * http://status.openstack.org/elastic-recheck/#1635643
> 
> All of those bugs were reported a long time ago. I've done some 
> investigation into them (at least at the time of reporting) and some are 
> simply due to cinder-api using synchronous RPC calls to cinder-volume 
> (or cinder-backup) and that doesn't scale. This bug isn't a backup 
> issue, but it's definitely related to using RPC call rather than cast:
> 
> http://status.openstack.org/elastic-recheck/#1763712
> 
> Regarding the backup tests specifically, I don't see a reason why they 
> need to be run in the integrated gate jobs, e.g. tempest-full(-py3). 
> They don't involve other services, so in my opinion we should move the 
> backup tests to a separate job which only runs on cinder changes to 
> alleviate these latent bugs failing jobs for unrelated changes and 
> resetting the entire gate.
> 
> I would need someone from the cinder team that is more involved in 
> knowing what their job setup looks like to identify a candidate job for 
> these tests if this is something everyone can agree on doing.
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html 
> 
> [2] http://status.openstack.org/elastic-recheck/

This is an old thread but gmann recently skipping a cinder backup test 
which was failing a lot [1] prompted me to revisit this.

As such I've proposed a change [2] which will disable the cinder-backup 
service in the tempest-full job which is in the integrated-gate project 
template and run by most projects.

There is a voting job running against cinder changes named 
"cinder-tempest-dsvm-lvm-lio-barbican" which will still test the backup 
service but it's not gating - it's up to the cinder team if they want to 
make that job gating. The other thing is it doesn't look like that job runs
on glance (or swift) changes so if the cinder team is interested in 
co-gating changes between at least cinder and glance, they could add 
cinder-tempest-dsvm-lvm-lio-barbican to glance so it runs there and/or 
create a new cinder-backup job which just runs backup tests and gate on 
that in both cinder and glance.

[1] https://review.openstack.org/#/c/651660/
[2] https://review.openstack.org/#/c/651865/

-- 

Thanks,

Matt


From openstack at fried.cc  Thu Apr 11 16:54:37 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 11:54:37 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <8DA526DE-AEC1-44B9-8E39-844D8BB14A20@leafe.com>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
 <alpine.OSX.2.11.1904111348350.33106@seed.local>
 <8DA526DE-AEC1-44B9-8E39-844D8BB14A20@leafe.com>
Message-ID: <d974a35f-eb12-d605-11ca-0fb529e7affc@fried.cc>

I was actually starting to explore

>> This suggests a change whereby we move a bunch of module-level methods
>> to instance methods. I actually really like that idea. So for example:
>>
>>   @db_api.placement_context_manager.writer
>>   def _set_traits(context, rp, traits):
>>       ...
>>
>> becomes:
>>
>>   class ResourceProvider(object):
>>       ...
>>       @db_api.placement_context_manager.writer
>>       def _set_traits(self, traits):
>>           ...
>>           # the artist formerly known as 'rp' is now 'self'
>>           # and context is self._context

and

> For a variety of reasons, most of which would be obvious given my previous enthusiasm for exploring alternatives, I’ve proposed a story for refactoring out the DB-specific code from the rest of placement:
> 
> https://storyboard.openstack.org/#!/story/2005435
> 
> I don’t know what everyone’s preference would be for where the DB code would go: either in private methods of the original module, or in a separate DB module, so I added as the first task coming to a decision on how to make that split.

, planning to propose them both as parallel changes/series so we could
see how they look IRL.

In the process, I discovered a remaining @classmethod in
resource_provider.py, which I figured should be taken care of first, so
I moved it.

And then looked for other @classmethodZ, because.

And ended up with [1], which removes all @classmethodZ from the project,
in keeping with what seems to be the majority's desire.

I'm going to fork another response to this thread to report on some
stuff I discovered on the original two proposals...

efried

[1]
https://review.openstack.org/#/q/status:open+project:openstack/placement+branch:master+topic:refactor-classmethod-diaf


From smooney at redhat.com  Thu Apr 11 17:01:14 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 11 Apr 2019 18:01:14 +0100
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <20190411164331.ehypsw3u4k5x44sy@yuggoth.org>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
 <20190410204432.u5e24yqglas5zxnv@yuggoth.org>
 <eba6d2403cc8d3ef5ac8b5afcfe412b90cdd2649.camel@redhat.com>
 <20190411164331.ehypsw3u4k5x44sy@yuggoth.org>
Message-ID: <c657f40c6a2202320f03e429600790513f3dc858.camel@redhat.com>

On Thu, 2019-04-11 at 16:43 +0000, Jeremy Stanley wrote:
> On 2019-04-10 23:27:54 +0100 (+0100), Sean Mooney wrote:
> [...]
> > so after doing this if i clone directly i get
> > 
> > sean at pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova
> > Cloning into 'nova'...
> > warning: redirecting to https://opendev.org/openstack/nova/
> > remote: Enumerating objects: 535171, done.
> 
> [...]
> 
> Perfect, that's git following the redirect just like we intend.
> 
> > and if i clone via a local squid proxy i get
> > 
> > sean at pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova
> > Cloning into 'nova'...
> > remote: Counting objects: 535171, done.
> 
> [...]
> > so via the proxy i dont even see the redirct warning
> 
> [...]
> 
> This is probably normal. Does squid pay attention to your /etc/hosts
> entries, or is it just going directly to DNS lookups? Also possible
> that it cached earlier name lookups.
ah ya that makes sense.

my squid proxy is running in a docker container in k8s cluster deployed on 
a singel node openstack deployed in docker via kolla-ansible

so it is definetly not reading my local /etc/hosts form my laptop

im not sure where in that inception stack of things
i would need to change it to force it to use that ip since docker does weird things with
/etc/hosts so we proably can be ignored the squid data point.
> 
> Thanks for helping test it for us!



From mriedemos at gmail.com  Thu Apr 11 17:05:14 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 11 Apr 2019 12:05:14 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <20190410003703.GG7047@thor.bakeyournoodle.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
Message-ID: <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>

On 4/9/2019 7:37 PM, Tony Breeds wrote:
> Being PTL doesn't give you automatic rights to the stable branches as the
> requirements there are different.  I'm really happy to start mentoring
> you on the stable policy and have you review stables patches then after
> 3months(ish) we can add you to the stable group assuming everything
> looks good.

Maybe we should start a FAQ for this in the stable docs. This question 
comes up every release.

BTW, this is a good example of why PTLs aren't automatically on the 
stable team:

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

That change is extremely questionable as a backport.

-- 

Thanks,

Matt


From gmann at ghanshyammann.com  Thu Apr 11 17:05:35 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 11 Apr 2019 12:05:35 -0500
Subject: [placement][ptg] Gate health management
In-Reply-To: <alpine.OSX.2.11.1904081740220.9091@seed.local>
References: <alpine.OSX.2.11.1904081740220.9091@seed.local>
Message-ID: <16a0d5ca14b.11792c5b2264772.8360316128568603208@ghanshyammann.com>

---- On Mon, 08 Apr 2019 11:42:45 -0500 Chris Dent <cdent+os at anticdent.org> wrote ----
 >  
 > From the etherpad [1]: 
 >  
 > * We have to run grenade and tempest. They are both very very slow 
 >    and very unreliable (compared to the other tests). That's a pain. 
 >    How do we help fix it? 
 >      * Profile where time is spent setting up devstack? 
 >      * Figure out where the slowest tests are which aren't marked 
 >        slow: http://status.openstack.org/elastic-recheck/#1783405 
 >      * Figure out which (non-interop) tests in tempest could be split 
 >        out to per-project repos or tempest plugins, i.e. if there are 
 >        compute API tests which don't rely on other services or a 
 >        hypervisor, and are just API/DB, they could be dealt with in 
 >        nova functional tests instead. 
 >      * Similarly: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000868.html 
 >  
 > The main thing to add here: We can come up with strategies on how to 
 > fix it, but how can we assure that there is time/energy/people to do 
 > that work? 

Thanks Chris for bringing this up. This is the general problem faced by all projects running
tempest-full.

I have added a topic for QA PTG also to discuss the same where we can have all those projects
representative and find the best solution.

- https://etherpad.openstack.org/p/qa-train-ptg  ("How to make tempest-full stable")


-gmann

 >  
 > [1] https://etherpad.openstack.org/p/placement-ptg-train 
 > --  
 > Chris Dent                       ٩◔̯◔۶           https://anticdent.org/ 
 > freenode: cdent                                         tw: @anticdent



From openstack at fried.cc  Thu Apr 11 17:07:27 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 12:07:27 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <6a9e9284-4f37-6c60-391e-73100fbd759f@gmail.com>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
 <6a9e9284-4f37-6c60-391e-73100fbd759f@gmail.com>
Message-ID: <64ab5677-b1eb-a454-c741-d4af5e21a45d@fried.cc>

While exploring

> For a variety of reasons, most of which would be obvious given my
> previous enthusiasm for exploring alternatives, I’ve proposed a story
> for refactoring out the DB-specific code from the rest of placement:
>
> https://storyboard.openstack.org/#!/story/2005435
>
> I don’t know what everyone’s preference would be for where the DB code
> would go: either in private methods of the original module, or in a
> separate DB module, so I added as the first task coming to a decision
> on how to make that split.

, I noticed something that will make it a bit icky.

Some of the db methods (e.g. ResourceProvider._create_in_db) are true
instance methods: they read and change instance attributes. If we move
forward with the suggested refactor, we could solve this in a couple of
non-great ways:

(1) Pass `self` to the db method. This grates on me pretty bad. It
screams that the thing should be an instance method.
(2) Pass in the attributes that are needed by the method, and return the
ones that the caller needs to use to update itself. This may make for
some ugly call/return signatures.

IMO (2) is the lesser evil.

Thoughts?

efried
.


From gmann at ghanshyammann.com  Thu Apr 11 17:14:22 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 11 Apr 2019 12:14:22 -0500
Subject: Proposal to move cinder backup tests out of the integrated gate
In-Reply-To: <3f15b8bc-9b5d-005b-2507-e8ff44d323a9@gmail.com>
References: <ddf910da-cdd9-e696-0def-e4fae85ec4fe@gmail.com>
 <3f15b8bc-9b5d-005b-2507-e8ff44d323a9@gmail.com>
Message-ID: <16a0d64abaf.de26839f264958.1325899441819608935@ghanshyammann.com>

 ---- On Thu, 11 Apr 2019 11:50:06 -0500 Matt Riedemann <mriedemos at gmail.com> wrote ----
 > On 12/12/2018 2:00 PM, Matt Riedemann wrote: 
 > > I wanted to send this separate from the latest gate status update [1]  
 > > since it's primarily about latent cinder bugs causing failures in the  
 > > gate for which no one is really investigating. 
 > >  
 > > Running down our tracked gate bugs [2] there are several related to  
 > > cinder-backup testing: 
 > >  
 > > * http://status.openstack.org/elastic-recheck/#1483434 
 > > * http://status.openstack.org/elastic-recheck/#1745168 
 > > * http://status.openstack.org/elastic-recheck/#1739482 
 > > * http://status.openstack.org/elastic-recheck/#1635643 
 > >  
 > > All of those bugs were reported a long time ago. I've done some  
 > > investigation into them (at least at the time of reporting) and some are  
 > > simply due to cinder-api using synchronous RPC calls to cinder-volume  
 > > (or cinder-backup) and that doesn't scale. This bug isn't a backup  
 > > issue, but it's definitely related to using RPC call rather than cast: 
 > >  
 > > http://status.openstack.org/elastic-recheck/#1763712 
 > >  
 > > Regarding the backup tests specifically, I don't see a reason why they  
 > > need to be run in the integrated gate jobs, e.g. tempest-full(-py3).  
 > > They don't involve other services, so in my opinion we should move the  
 > > backup tests to a separate job which only runs on cinder changes to  
 > > alleviate these latent bugs failing jobs for unrelated changes and  
 > > resetting the entire gate. 
 > >  
 > > I would need someone from the cinder team that is more involved in  
 > > knowing what their job setup looks like to identify a candidate job for  
 > > these tests if this is something everyone can agree on doing. 
 > >  
 > > [1]  
 > > http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867.html  
 > >  
 > > [2] http://status.openstack.org/elastic-recheck/ 
 >  
 > This is an old thread but gmann recently skipping a cinder backup test  
 > which was failing a lot [1] prompted me to revisit this. 
 >  
 > As such I've proposed a change [2] which will disable the cinder-backup  
 > service in the tempest-full job which is in the integrated-gate project  
 > template and run by most projects. 

at end goal i agree on this but this will skip all backup tests whihc are running fine,
so let's wait till we move those tests to cindet tempest plugin or run on other integrated
job etc.

 >  
 > There is a voting job running against cinder changes named  
 > "cinder-tempest-dsvm-lvm-lio-barbican" which will still test the backup  
 > service but it's not gating - it's up to the cinder team if they want to  
 > make that job gating. The other thing is it doesn't look like that job runs 
 > on glance (or swift) changes so if the cinder team is interested in  
 > co-gating changes between at least cinder and glance, they could add  
 > cinder-tempest-dsvm-lvm-lio-barbican to glance so it runs there and/or  
 > create a new cinder-backup job which just runs backup tests and gate on  
 > that in both cinder and glance. 

Initially, I was on the side to test/run everything together but on second thought
and by seeing tempest-full unstable I agree with you to find some solution to make
integrated-gate template testing (tempest-full) more efficient and stable for each service.

neutron also face lot of test failure due to volume backup or image tests which definitely
not related to neutron and not worth to block neutron development for that.

I have added this topic in QA PTG etherpad to find the best possible solution.
- https://etherpad.openstack.org/p/qa-train-ptg 

-gmann

 >  
 > [1] https://review.openstack.org/#/c/651660/ 
 > [2] https://review.openstack.org/#/c/651865/ 
 >  
 > --  
 >  
 > Thanks, 
 >  
 > Matt 
 >  
 > 



From openstack at fried.cc  Thu Apr 11 17:28:26 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 12:28:26 -0500
Subject: [PowerVMStackers][Winstackers][uc][tc] Encourage to transform
 from project to SIG
In-Reply-To: <565c86cc-05f5-cb5c-be52-e88a8dc8be2d@redhat.com>
References: <CA+WCyyrQXLizHfdbRiwD8T-DwA3j=fRPM6bStWoJZSdcY_r5wA@mail.gmail.com>
 <1CFD1B85-F61A-4904-AFD4-B486EC99ABC1@us.ibm.com>
 <20190409060229.GD7047@thor.bakeyournoodle.com>
 <6297fe59-00b9-2af8-0d74-584d7c0aac4c@fried.cc>
 <565c86cc-05f5-cb5c-be52-e88a8dc8be2d@redhat.com>
Message-ID: <2979b353-9188-2d4b-aa97-1393c3334dae@fried.cc>

> It sounds like moving the PowerVM repos under Nova's governance would be
> a topic worthy of active discussion between the two projects.

/me discusses...

As I said previously in this thread [1], "whether by switching
governance or porting the code into the nova project, it would be
irresponsible of the nova team to assume ownership without thorough review."

And actually, it's about more than assuming ownership. Thorough review
would be prudent so the nova team has familiarity with the code.

That said, as long as *-powervm-core groups could still exist, the
PowerVM team - who are patently the experts on that code - would still
be able to integrate changes without the blessing of nova-core. (The
alternative doesn't seem tenable to me, and is in fact a problem we have
with most of the in-tree virt drivers today.)

So, forgive me for being dense, but what does that ^ gain anyone? And
what does the long-term plan for the in-tree vs. out-of-tree drivers
become in this scenario?

efried

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004824.html


From sundar.nadathur at intel.com  Thu Apr 11 17:33:48 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 11 Apr 2019 17:33:48 +0000
Subject: [glance] Listing all images with a set of custom properties
In-Reply-To: <d20f177c-5aa8-8125-9dad-c1a5eea5b952@gmail.com>
References: <4bb9cec7-93cf-bef2-778d-106215097b05@intel.com>
 <d20f177c-5aa8-8125-9dad-c1a5eea5b952@gmail.com>
Message-ID: <1CC272501B5BC543A05DB90AA509DED52754C0A3@fmsmsx122.amr.corp.intel.com>

Thanks, Brian. I'll go with that.

Regards,
Sundar

> -----Original Message-----
> From: Brian Rosmaita <rosmaita.fossdev at gmail.com>
> Sent: Thursday, April 11, 2019 6:42 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [glance] Listing all images with a set of custom properties
> 
> On 4/10/19 8:42 PM, Nadathur, Sundar wrote:
> > I am looking for a way to programmatically get all images that have
> > been associated with a set of custom properties. Ideally, I should be
> > able to say 'give me all images that have key1=value1, key2=value2, etc.
> 
> Create a dict of the properties you are interested in, for example,
> 
>   filters = {'key1': 'value1', 'key2': 'value2'}
> 
> and then pass it as the value of the 'filters' argument to the 'list' call:
> 
>   image_list_generator = glance.list(filters=filters)
> 
> You can have both "regular" and custom image properties as keys in the
> filters dict.
> 
> > Failing that, at least get all images that have the named keys key1,
> > key2, etc. irrespective of their values, so I can filter for the
> > values myself.
> 
> I don't think there's a way to do this, actually.  I'm pretty sure it's not
> supported by the Images API.
> 
> > I was looking at [1], specifically [2], and came up short. Any
> > recommendations?
> >
> > [1]
> > https://github.com/openstack/python-glanceclient/tree/master/glancecli
> > ent/v2
> >
> >
> > [2]
> > https://github.com/openstack/python-glanceclient/blob/master/glancecli
> > ent/v2/images.py#L86
> 
> It shows up a bit later:
> https://github.com/openstack/python-
> glanceclient/blob/master/glanceclient/v2/images.py#L136
> 
> > Regards,
> >
> > Sundar
> 
> cheers,
> brian
> 


From openstack at fried.cc  Thu Apr 11 17:52:09 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 12:52:09 -0500
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.11.1904111303310.33106@seed.local>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <4b9b3a68-607e-2ee8-554f-809f89225694@fried.cc>
 <alpine.OSX.2.11.1904111303310.33106@seed.local>
Message-ID: <f632dffc-5cc4-3331-5dd1-1c75d0c7331d@fried.cc>

>> { groups: [
>>       { requests: [
>>             { resources: {DISK_GB: 10} }
>>         ]
>>       }
>>       { requests: [
>>             { resources: {VCPU: 2, MEMORY_MB: 128} }
>>             { resources: {VF: 1},
>>               required: [NET_A] },
>>             { resources: {VF: 1},
>>               required: [NET_B] },
>>         ],
>>         group_policy: subtree_affinity
>>       },
>>   ]
>> }
> 
> For those of us not in your head, can you explain how the above is
> different/better from the following pseudo-query:
> 
>      resources=DISK_GB;
>      resources1=VCPU:2,MEMORY_MB:128;
>     
> resources2=VF:1;required2=NET_A;group_policy2=subtree_rooter:resources1;
>     
> resources3=VF:1;required2=NET_B;group_policy3=subtree_rooter:resources1
> 
> Apologies if I'm missing some details. I probably am, that's why
> I'm asking. I'm intentionally ignoring your "should not do this by
> making a queryparam ... group numbers" because I didn't fully
> understand the explanation/reasoning in the discussion on the spec,
> so I'm after additional explanation (that is, if we have to merge
> request groups we still need to preserve the distinctiveness of the
> groups, and if some form of a hierarchical relationship is present
> we need to maintain that).

In nova, with the bandwidth (and forthcoming accelerator) code in play,
the group numbers are generated on the fly and in pretty different
sections of the code. But you're right: whether by tracking group
numbers or otherwise, we need some way of clustering the groups
together. That's going to be tricky on the nova side regardless.

Beyond that, I just have a gut ick response to one parameter's *value*
referring to another parameter's *key*. That seems dirty/hacky to me. I
can probably get over it.

>>> * Inventory-less resource providers
>>
>> An interesting topic, but IMO not related to $subject. This will come up
>> as soon as we model NUMA + sharing at all. We shouldn't muddy these
>> waters by hashing it out here.
> 
> I'm sorry to beat on this drum over and over again, but the reason
> to have this pre-PTG stuff is exactly to churn up the waters and get
> all the ideas out in the open so that we are thinking about the
> entire system, not specific details.

Ack. Perhaps I should have said: we're already discussing it in thread
"Resourceless trait filters" [1]. So, lacking any technical connection
to the subject of this thread (true since we killed the idea of using a
trait) we might as well isolate the discussion there.

>> How about we do that in a separate thread, then?
> 
> Why? See my two paragraphs above and my facepalming in another
> thread.

I get it, I just feel like a) this topic is intricate enough in its
technical aspects, we'll have enough of a challenge reaching consensus
without digressing into philosophical tangents; and b) said
philosophical tangents are already being explored in other threads (if
they're not, we should start them). In other words, my preference would
be to keep each thread focused as narrowly as possible. Otherwise we run
the risk of losing sight of the original issue. (I literally just now
had to glance back up at the subject line to remind myself what this
thread was about.)

efried

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4817


From openstack at fried.cc  Thu Apr 11 18:01:25 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 13:01:25 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <1554986561.23392.2@smtp.office365.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
 <1554986561.23392.2@smtp.office365.com>
Message-ID: <284bb8f5-34cf-c07e-9921-3487074ffa32@fried.cc>

> Then we need two steps:
> 1) handle RPs that only have traits but not resources
> 2) allow having the numbered request groups specify only a trait 
> without requesting resources.

Nothing stops me from traiting an inventoryless provider today, right?

Do we actually need to involve numbered request groups? Does a concept
of required_in_tree=$trait_list satisfy the requirements?

efried
.


From ed at leafe.com  Thu Apr 11 18:02:12 2019
From: ed at leafe.com (Ed Leafe)
Date: Thu, 11 Apr 2019 13:02:12 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <64ab5677-b1eb-a454-c741-d4af5e21a45d@fried.cc>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
 <6a9e9284-4f37-6c60-391e-73100fbd759f@gmail.com>
 <64ab5677-b1eb-a454-c741-d4af5e21a45d@fried.cc>
Message-ID: <41BA3D9A-9386-4495-8C19-6939F8FE8465@leafe.com>

On Apr 11, 2019, at 12:07 PM, Eric Fried <openstack at fried.cc> wrote:
> 
> (1) Pass `self` to the db method. This grates on me pretty bad. It
> screams that the thing should be an instance method.

That is actually a pretty old design pattern: passing a data object, rather than a slew of parameters. Of course, it would be cleaner to keep them as instance methods, and that would be my preference. I know that you have expressed an interest in reducing the overall size of the individual modules, so this option is only valid if smaller modules is decided on as a Good Thing™, 

> (2) Pass in the attributes that are needed by the method, and return the
> ones that the caller needs to use to update itself. This may make for
> some ugly call/return signatures.

I can’t think of a more brittle approach. 

-- Ed Leafe







From mark at stackhpc.com  Thu Apr 11 18:21:13 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 11 Apr 2019 18:21:13 +0000
Subject: [stackalytics] Reported numbers seem inaccurate
Message-ID: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>

Hi,

I've heard a couple of people say they don't feel the numbers reported by
Stackalytics accurately reflect reality. I've been trying to gather a few
stats for my Kolla update session in Denver, and am finding the same. I'll
try to give some concrete examples.

Reviews for all kolla deliverables in Stein [1]. Here the company stats
don't reflect the individual stats. Also, the total reviews in the 'Kolla
Official' module does not equal the sum of the reviews of its submodules
(kolla, kolla-ansible, kolla-cli).

If I look at the contribution summary for Kolla Official in the last 90
days [2], they are actually greater than those for the last 180 days [3]!

There are also similar issues with commit metrics, and none seem to match
what I see in git.

Thanks,
Mark

[1] https://www.stackalytics.com/?metric=marks&module=kolla-group
[2] https://www.stackalytics.com/report/contribution/kolla-group/90
[3] https://www.stackalytics.com/report/contribution/kolla-group/180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/fb4da280/attachment.html>

From openstack at fried.cc  Thu Apr 11 18:22:08 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 11 Apr 2019 13:22:08 -0500
Subject: [placement][ptg] code refactoring constraints and goals
In-Reply-To: <41BA3D9A-9386-4495-8C19-6939F8FE8465@leafe.com>
References: <alpine.OSX.2.11.1904081618310.9091@seed.local>
 <6b55572b-09cb-2eec-3dee-94e24ec88edc@fried.cc>
 <eb2f81cf-fd20-433d-2e53-1cce490b6431@gmail.com>
 <5bc3f29a-f411-ea80-b3ac-f1eefb727958@fried.cc>
 <6a9e9284-4f37-6c60-391e-73100fbd759f@gmail.com>
 <64ab5677-b1eb-a454-c741-d4af5e21a45d@fried.cc>
 <41BA3D9A-9386-4495-8C19-6939F8FE8465@leafe.com>
Message-ID: <9992e7c7-b9ea-85d4-4f81-fb7523caa74e@fried.cc>

>> (1) Pass `self` to the db method. This grates on me pretty bad. It
>> screams that the thing should be an instance method.
> 
> That is actually a pretty old design pattern: passing a data object, rather than a slew of parameters. Of course, it would be cleaner to keep them as instance methods, and that would be my preference. I know that you have expressed an interest in reducing the overall size of the individual modules, so this option is only valid if smaller modules is decided on as a Good Thing™, 

Smaller modules would be nice, but I'm pretty soft on that since earlier
in this thread (though I wouldn't want resource_provider.py getting any
bigger than it is today).

I thought the motivator here was separation/isolation of the db-ish
methods into their own space.

Looking at resource_provider.py specifically, many of the existing
module-level @db_api methods today accept a ResourceProvider as a
parameter. So for the sake of consistency, we should either make those
into instance methods, or move all the existing @db_api instance methods
to the module level (be it this module or a different one).

Which I think is more or less where we started. I was ready to be happy
with the idea of moving the @db_api methods into their own space until I
saw that we would need to pass `self` around. If there's a consensus
that that's okay, I'll get over it (and maybe even do the work).

Jay, you had expressed in favor of the other suggestion (group methods
"intuitively" in the ResourceProvider class, even @db_api ones) before
we really opened up this one (move @db_api methods into their own space,
even though that means passing `self` to them). What's your preference
at this point?

efried
.



From fungi at yuggoth.org  Thu Apr 11 18:42:47 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 11 Apr 2019 18:42:47 +0000
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
Message-ID: <20190411184247.6c73pum46hedxlxf@yuggoth.org>

On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote:
[...]
> Anything left will be moved to another namespace[8] unless/until
> the owner requests it to be moved elsewhere.
[...]
> [8] I'm not even going to name it here, lest this thread devolves into a
>     discussion about this name and nothing else.

Also, in case it's not immediately clear, in combination with the
details from the GitHub section of the earlier announcement at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
the upshot is that on April 19 any repositories in the "openstack"
organization on GitHub which aren't part of the official set
described in this current thread will cease updating and be archived
soon thereafter. Their owners will need to coordinate with the
volunteer team who takes over management of the "openstack" GitHub
organization to have them un-archived and transferred to a different
organization if they want GitHub redirects to work. (I have it on
authority this is scriptable through their API and so can be batch
processed in bulk, but needs the initiator of the transfer in the
"openstack" organization to be temporarily added as an admin of the
receiving organization as well.)
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/9c5ce36f/attachment.sig>

From johnsomor at gmail.com  Thu Apr 11 20:30:43 2019
From: johnsomor at gmail.com (Michael Johnson)
Date: Thu, 11 Apr 2019 13:30:43 -0700
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
Message-ID: <CAMH0Mg+OJHmc_g38QiAf7fFYFsR-ALyLq63JfO3qhcJ-_MHiGA@mail.gmail.com>

I have also seen issues with the new Stackalytics data. At times it
showed I have contributed less lines for Stein than were in a single
patchset.

Michael

On Thu, Apr 11, 2019 at 11:21 AM Mark Goddard <mark at stackhpc.com> wrote:
>
> Hi,
>
> I've heard a couple of people say they don't feel the numbers reported by Stackalytics accurately reflect reality. I've been trying to gather a few stats for my Kolla update session in Denver, and am finding the same. I'll try to give some concrete examples.
>
> Reviews for all kolla deliverables in Stein [1]. Here the company stats don't reflect the individual stats. Also, the total reviews in the 'Kolla Official' module does not equal the sum of the reviews of its submodules (kolla, kolla-ansible, kolla-cli).
>
> If I look at the contribution summary for Kolla Official in the last 90 days [2], they are actually greater than those for the last 180 days [3]!
>
> There are also similar issues with commit metrics, and none seem to match what I see in git.
>
> Thanks,
> Mark
>
> [1] https://www.stackalytics.com/?metric=marks&module=kolla-group
> [2] https://www.stackalytics.com/report/contribution/kolla-group/90
> [3] https://www.stackalytics.com/report/contribution/kolla-group/180


From johnsomor at gmail.com  Thu Apr 11 20:37:19 2019
From: johnsomor at gmail.com (Michael Johnson)
Date: Thu, 11 Apr 2019 13:37:19 -0700
Subject: [octavia] Proposal to change the Octavia IRC meeting time.
In-Reply-To: <CAMH0Mg+Lf2wMED3pFJbZmoLonRCDMDUovEZB5WUkc9Vqntxhsw@mail.gmail.com>
References: <CAMH0Mg+Lf2wMED3pFJbZmoLonRCDMDUovEZB5WUkc9Vqntxhsw@mail.gmail.com>
Message-ID: <CAMH0MgLCvTTPin0_X_na7vvG+T1tPaHgYRwDsUpMP=BC-zu=gg@mail.gmail.com>

Thank you to everyone that voted on the Doodle.

At the weekly Octavia IRC meeting we decided on Wednesdays at 16:00
UTC as our new meeting time based on the results of the Doodle poll.

This will start next week, April 17th.

Hope to see you there!

Michael

On Wed, Apr 3, 2019 at 4:24 PM Michael Johnson <johnsomor at gmail.com> wrote:
>
> As the composition of the Octavia team has changed over time, it was
> proposed at today's meeting that we may want to change our weekly IRC
> meeting time to accommodate more participants from around the world.
>
> Seven time slots were proposed during the meeting and I have created a
> doodle poll to help us find a time that works for most of the team.
> Please note, the intent is to pick a new UTC time. Doodle attempts to
> adapt the times to your local timezone.
>
> The proposed times are Tuesday-Friday at 15:00 or 16:00 UTC. We have
> also included the current meeting time of 20:00 UTC on Wednesday.
>
> Please vote your preferences at the following Doodle poll:
>
> https://doodle.com/poll/9sxbzfhwirqiyqe8
>
> We will discuss the results at next week's regularly scheduled IRC
> meeting, Wednesday at 20:00 UTC.
>
> Please reply to this e-mail or to me directly if you have trouble with
> the poll or would like to propose additional time slots.
>
> Michael


From anlin.kong at gmail.com  Thu Apr 11 20:47:12 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Fri, 12 Apr 2019 08:47:12 +1200
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
Message-ID: <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>

Matt,

I've already replied in the patch, since you also mentioned the patch here,
i think it's necessary also reply you here.

That patch failed to get attention from other team members and the
community who are not interested in such change, as the PTL, i have to
merge it myself to not block other patches. At the same time, some users
were complaining the current trove image build approach, which could be
improved with that patch.

If self-approved is something you disagree, I'd appreciate if you could
offer some help for the review.

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Fri, Apr 12, 2019 at 5:11 AM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/9/2019 7:37 PM, Tony Breeds wrote:
> > Being PTL doesn't give you automatic rights to the stable branches as the
> > requirements there are different.  I'm really happy to start mentoring
> > you on the stable policy and have you review stables patches then after
> > 3months(ish) we can add you to the stable group assuming everything
> > looks good.
>
> Maybe we should start a FAQ for this in the stable docs. This question
> comes up every release.
>
> BTW, this is a good example of why PTLs aren't automatically on the
> stable team:
>
> https://review.openstack.org/#/c/651672/
>
> That change is extremely questionable as a backport.
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/237ab886/attachment.html>

From shakhat at gmail.com  Thu Apr 11 21:42:20 2019
From: shakhat at gmail.com (Ilya Shakhat)
Date: Fri, 12 Apr 2019 01:42:20 +0400
Subject: [osprofiler] Distributed tracing in OpenStack
Message-ID: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>

Hi,

Distributed tracing is one of must-have features when one wants to track
the full path of request going through different services and APIs. This
makes it similar to shared request-id, but with nice visualization at the
end [1]. In OpenStack the tracing can be achieved via osprofiler library.
The library was introduced 5 years ago, and back then there was no standard
approach on how to do tracing and that's why it stays aside from what has
become a mainstream. Yet there is no single standard, but the major players
are OpenTracing and OpenCensus communities. OpenTracing is represented by
Uber's Jaeger which is the default tracer from k8s world.

Issues and limitations to be fixed:
1. Compatibility. While osprofiler library supports many different storage
drivers, it has only one way of transferring trace context over the wire.
Ideally the library should be compatible with other third-party tracers and
allow traces to start in front of OpenStack APIs (e.g. in user apps) and
continue after (e.g. in storage systems, or network management tools). [2]
2. Operation mode. With osprofiler tracing is initiated by user request,
while in industrial solutions the tracing can be managed centrally via
dynamic sampling policies.
3. In-process trace propagation. Depending on execution model (threaded,
async) the ways of storing current trace context differ. OSProfiler
supports thread-local model, which recently got broken with new async
implementation in openstacksdk [3]. With OpenTracing it is possible to
select the appropriate model alongside with tracer configuration.

What's the plan:
Switching to OpenTracing could be a good option to gain compatibility with
3rd-party solutions. The actual change should go to osprofiler library, but
indirectly affects all OpenStack projects (should it be a global team goal
then?). I'm going to make a PoC of proposed change, so reviews would be
highly appreciated.

Comments, suggestions?

Thanks,
Ilya

[1] e.g.
http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-redis/7c6c14e/osprofiler-traces/trace-3e5cc660-8815-4079-86b9-778af8469d79.html.gz
[2] https://bugs.launchpad.net/osprofiler/+bug/1798565
[3] https://bugs.launchpad.net/osprofiler/+bug/1818493
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/3edad364/attachment.html>

From dmsimard at redhat.com  Thu Apr 11 21:45:25 2019
From: dmsimard at redhat.com (David Moreau Simard)
Date: Thu, 11 Apr 2019 17:45:25 -0400
Subject: [all] New Zuul job to replicate a project's git repository to a
 remote git server
Message-ID: <CAH7C+Pom2Ki7GQq_hhNLs1_NYFe_R4fE_TKucqf6hRt+d9WkNw@mail.gmail.com>

Hi,

It is now possible for projects to replicate their git repository to a
custom location by inheriting from the 'upload-git-mirror' job
provided by Zuul.
This job wraps around the 'upload-git-mirror' Ansible role that is
part of the zuul-jobs library [1].

In order to use this job, you must supply a secret in the following format:
===
- secret:
    name: <name of your secret>
    data:
      user: <ssh user of the remote git server>
      host: <address of the remote git server>
      host_key: <ssh host key of the remote git server>
      ssh_key: <private key to authenticate with the remote git server>
===

The 'host_key' parameter can be retrieved from your known_hosts file
or with a command like 'ssh-keyscan -H <host>' or 'ssh-keyscan -t rsa
<host>'.
For example, the 'host_key' when pushing to GitHub would be, on a single line:
    github.com ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

The 'ssh_key' parameter should be encrypted before being committed to
the git repository.
Zuul provides a tool for easily encrypting files such as SSH private
keys and you can find more information about it in the documentation
[2].

For example, encrypting a key for the "openstack/ara" project would
look like this:
===
zuul/tools/encrypt_secret.py --infile /home/dmsimard/.ssh/ara_git_key
--tenant openstack https://zuul.openstack.org openstack/ara
===

You would then use the secret in a job inheriting from
'upload-git-mirror' as such:
===
- job:
    name: <project>-upload-git-mirror
    parent: upload-git-mirror
    description: Mirrors openstack/<project> to neworg/<project>
    vars:
      git_mirror_repository: neworg/<project>
    secrets:
      - name: git_mirror_credentials
        secret: <name of your secret>
        pass-to-parent: true
===

Finally, the job must be set to run in your project's 'post' pipeline
which is triggered every time a new commit is merged to the
repository:
===
- project:
    check:
      jobs:
        # [...]
    gate:
      jobs:
        # [...]
    post:
      jobs:
        - <project>-upload-git-mirror
===

Note that the replication would only begin *after* the change has
merged, meaning that merging the addition of the post job would not
trigger the post job itself immediately.
The post job will only trigger the next time that a commit is merged.

[1]: https://zuul-ci.org/docs/zuul-jobs/general-roles.html#role-upload-git-mirror
[2]: https://zuul-ci.org/docs/zuul/user/encryption.html

David Moreau Simard
dmsimard = [irc, github, twitter]


From dtroyer at gmail.com  Thu Apr 11 21:53:36 2019
From: dtroyer at gmail.com (Dean Troyer)
Date: Thu, 11 Apr 2019 16:53:36 -0500
Subject: [placement][ptg] Placement Over The Parapet
In-Reply-To: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
Message-ID: <CAOJFoEs7uwh-hiCsWgs+C2ZBvRLc4cfirPhG80Orr0yPjEs36w@mail.gmail.com>

On Tue, Apr 9, 2019 at 12:09 PM Chris Dent <cdent+os at anticdent.org> wrote:
> For example, would there be any purpose in experimenting with
> plugging placement into the pluggable scheduling concept in k8s? Is
> that totally crazy or intriguing?

StarlingX has on its futures list being able to share a compute node
between k8s and Nova and it seems to me as though placement is the
heart of doing that, so totally not crazy.  I am thus far ignorant
enough about k8s as to not be able to reliably judge on technical
merits but would love to further discuss.

dt

-- 
Dean Troyer
dtroyer at gmail.com


From ken at jots.org  Thu Apr 11 22:05:15 2019
From: ken at jots.org (Ken D'Ambrosio)
Date: Thu, 11 Apr 2019 18:05:15 -0400
Subject: Pike: "Observer" or "read-only" admin access?
Message-ID: <2358baef1296b0d821e46c86fb457f96@jots.org>

Hi, all.  Beginning to roll out a newer-than-what-we-had OpenStack 
release -- likely to be Pike, "For reasons."  (Which is still *worlds* 
newer than Juno, where we are.)  And I've been asked if there's such a 
thing as an account (or ACL) that allows a user to read everything, but 
write nothing.  Googling, I see mention of such things -- but nothing 
really firm.  Does it exist?  Is it in Pike (or more recent releases)?  
If it doesn't exist, is there a graceful way to make it happen, anyway?

Thanks!

-Ken


From mnaser at vexxhost.com  Thu Apr 11 22:18:27 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 11 Apr 2019 18:18:27 -0400
Subject: [placement][ptg] Placement Over The Parapet
In-Reply-To: <CAOJFoEs7uwh-hiCsWgs+C2ZBvRLc4cfirPhG80Orr0yPjEs36w@mail.gmail.com>
References: <alpine.OSX.2.21.1904091801340.93787@cdent-a01.vmware.com>
 <CAOJFoEs7uwh-hiCsWgs+C2ZBvRLc4cfirPhG80Orr0yPjEs36w@mail.gmail.com>
Message-ID: <CAEs876hLyFvdekY9ggY18KQf52L9fBT+2BsdOeuCg4VWn=nMgA@mail.gmail.com>

On Thu, Apr 11, 2019 at 5:55 PM Dean Troyer <dtroyer at gmail.com> wrote:
>
> On Tue, Apr 9, 2019 at 12:09 PM Chris Dent <cdent+os at anticdent.org> wrote:
> > For example, would there be any purpose in experimenting with
> > plugging placement into the pluggable scheduling concept in k8s? Is
> > that totally crazy or intriguing?
>
> StarlingX has on its futures list being able to share a compute node
> between k8s and Nova and it seems to me as though placement is the
> heart of doing that, so totally not crazy.  I am thus far ignorant
> enough about k8s as to not be able to reliably judge on technical
> merits but would love to further discuss.

I think Zun could benefit from this too, to share compute resources across
different services.

> dt
>
> --
> Dean Troyer
> dtroyer at gmail.com
>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From cboylan at sapwetik.org  Thu Apr 11 22:21:14 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 11 Apr 2019 18:21:14 -0400
Subject: Migrating git repos to OpenDev
In-Reply-To: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
Message-ID: <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>

On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote:
> Hi,
> 
> As discussed in November[1], the OpenStack project infrastructure is
> being rebranded as "OpenDev" to better support a wider community of
> projects.
> 
> We are nearly ready to perform the part of this transition with the
> largest impact: moving the authoritative git repositories for existing
> projects.
> 
> In this email, I'd like to introduce the new hosting system we are
> preparing, discuss the transition, and invite projects to work with us
> on the logistics of the change.
> 
> Gerrit
> ======
> 
> Gerrit is the core of our system and it will remain so in OpenDev.  As
> part of this move, we will rename the gerrit server from
> review.openstack.org to review.opendev.org.  As part of the transition,
> we will automatically merge appropriate changes to all branches of all
> repositories updating .gitreview and Zuul configuration files.  Any
> further changes (README files, etc.) we expect to be made by individual
> project contributors.
> 
> Repository Browsing
> ===================
> 
> Currently our canonical *public* repository system is the cgit server at
> https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and
> git.zuul-ci.org).  This is a load balanced cluster of several servers
> which is designed to handle all the public git repository traffic, as it
> scales much better than Gerrit (and has a more friendly domain name).
> From a technical standpoint, it's excellent, but its usability could be
> improved.
> 
> Therefore, as part of this transition, we will replace the cgit servers
> with a new system based on Gitea.  Gitea is a complete development
> collaboration system, but it's very flexible and will allow us to
> disable components which we aren't using.  We will operate it in a
> read-only configuration where it will act as the public mirror for
> Gerrit.  The advantages it has over the current system are:
> 
> * Shorter domain name in project URLs:
>   https://git.openstack.org/openstack/nova   vs
>   https://opendev.org/openstack/nova
> * Clone and browsing URLs are the same (with cgit, the browsing URL has
>   an extra path component)
> * More visually pleasing code browsing
> * Integrated code searching
> * Ability to highlight multiple lines in links
> 
> When we perform the transition we will install redirects from
> git.openstack.org (and the other git sites) to opendev.org, and will
> maintain those redirects for the foreseeable future.  We will construct
> them so that even existing deep links to individual files in individual
> commits to cgit will redirect to the correct location on opendev.org.
> 
> This system is up and running now with a live mirror of data from
> Gerrit, and you can start testing it out today at https://opendev.org/
> 
> Please let us know if you encounter any problems.
> 
> If you would like to read more about the design of this system and the
> transition, see the infra-spec[2].
> 
> GitHub
> ======
> 
> Currently all OpenStack projects are replicated to GitHub.  We do not
> plan on changing that during the transition, however, any projects
> outside of the openstack*/ namespaces will not automatically be
> replicated to GitHub, and we do not plan on adding that in the future.
> We do, however, support projects using Zuul to run post-merge jobs to
> push updates to GitHub or any other third-party mirrors with their own
> credentials.  We will be happy to work with anyone interested in that to
> help set up jobs to do so.
> 
> We are adopting this approach so that individual projects can have more
> control over how they are represented in social media, and to give us
> more flexibility in supporting our own organizational namespaces on
> OpenDev without assuming they map directly to GitHub.
> 
> Eventually we plan on moving the OpenStack project to that system as
> well and retiring direct replication from Gerrit to GitHub completely.
> But we will defer that work until after this transition.
> 
> Logistics
> =========
> 
> We can prepare much of the system in advance (as we have for the hosting
> system on opendev.org), but the actual transition and renaming of the
> Gerrit server will need to happen at once during an outage window.  We
> need to schedule that outage and begin preparing for it.
> 
> Since all of the project git URLs are going to change (to replace
> git.openstack.org with opendev.org and review.openstack.org with
> review.opendev.org), we can additionally take the opportunity to
> reorganize projects into different organizations.
> 
> For example, during the transition we will rename Zuul, and it's
> associated projects, from the "openstack-infra" org to "zuul".  So their
> new names will be "zuul/zuul", "zuul/nodepool", etc.
> 
> This is an excellent time for the rest of the OpenStack Foundation
> pilot projects to do the same.
> 
> If the OpenStack project desires this, it would also be a good time to
> move unofficial projects out of the openstack/ namespace.
> 
> Therefore, we need your help:
> 
> Action Items
> ============
> 
> We need each of the following projects:
> 
>   * OpenStack
>   * Airship
>   * StarlingX
>   * Zuul
> 
> To nominate a single point of contact to work with us on the transition.
> It would be helpful for that person to attend the next (and possibly
> next several) openstack infra team meetings in IRC [3].  We will work
> with those people on scheduling the transition, as well as finalizing
> the list of projects which should be renamed as part of the transition.
> 
> If you manage an unofficial project and would like to take the
> opportunity to move or rename your project, please add it to this
> ethercalc[4].
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
> [2] 
> http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html
> [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting
> [4] https://ethercalc.openstack.org/opendev-transition
> 
>

We've made good progress in preparing this change and are still on track to do this Friday April 19, 2019.  Our project liasons have been drawing up lists of projects to rename during the outage. One big thing to keep in mind is unofficial OpenStack projects will no longer be in the "openstack" namespace.  They will be placed in the 'x/' namespace instead which intends to indicate no endorsement or special ownership.

One side effect of this change (as noted in Jim's earlier email) is that we will stop replicating projects that move out of the openstack namespace. Projects that wish to be replicated to Github or anywhere else they like can do so following the steps that David Moreau-Simard put together for us here [5].

This transition is likely to be a bit bumpy particularly at the start. We'll be around after the transition to help fix unexpected errors and are likely to spend a fair bit of time at the PTG improving things as well.

Finally, to be extra clear, we intend to put http redirects in place so that all your old http(s) urls continue to work.  Fungi has set this up for testing with details here [6] if you would like to ensure your urls redirect properly.

[5] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
[6] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html

Thank you for your patience and feel free to reach out with any questions you might have.

Clark


From zigo at debian.org  Thu Apr 11 22:33:40 2019
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 12 Apr 2019 00:33:40 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <14c3657b-d8ba-96cf-0eaa-239f5ad6c4bc@inaugust.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <AA627BA7-CCD2-4FD4-93F5-87C4AFBEDBB2@cern.ch>
 <86ff9927-1c24-f001-9527-fb87e24319f4@ham.ie>
 <14c3657b-d8ba-96cf-0eaa-239f5ad6c4bc@inaugust.com>
Message-ID: <57453e2f-7d4d-9003-6fdc-3ab3c7d5900e@debian.org>

On 4/8/19 12:41 PM, Monty Taylor wrote:
> 
> 
> On 4/8/19 10:10 AM, Graham Hayes wrote:
>> On 08/04/2019 07:14, Tim Bell wrote:
>>> You could use the standard image properties
>>> (https://docs.openstack.org/glance/stein/admin/useful-image-properties.html)
>>> to find the image using a query
>>>
>>> e.g. os_distro=centos, os_version=7 and sort by upload date
>>>
>>> Tim
>>
>> I like the idea of it being discoverable, not defined by using the name
>> - it fits better in my head with the way we are doing interop and allows
>> current clouds to not have to change name formats (which could break
>> other users).
> 
> I would love it if we could provide guidance - or maybe even somehow get
> this in to RefStack or something - that clouds *should* provide that
> metadata.
> 
> At the same time, needing to search for an image (and a flavor) on the
> cloud makes this:
> 
>   openstack server boot --image=<image> --flavor=<flavor> foo
> 
> a bit harder. Perhaps we could add some parameters ... like:
> 
>   openstack server boot --image-os=debian --image-version=7

Whohooo! You're still using such an old thing as Wheezy? :)

Cheers,

Thomas Goirand (zigo)


From zigo at debian.org  Thu Apr 11 22:40:03 2019
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 12 Apr 2019 00:40:03 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
Message-ID: <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>

On 4/8/19 2:32 PM, Jeremy Stanley wrote:
> On 2019-04-08 03:39:51 +0000 (+0000), Mark Voelker wrote:
>> I don’t think I have a perfect answer here, but just to add fodder
>> to the discussion: it’s often been suggested in the past that one
>> way of dealing with this is to simply ensure that you can bring
>> your image to any cloud you work with.  Thus, rather than relying
>> on an image to be named the same across the clouds you deal with,
>> you can simply provide it yourself on those clouds so you know
>> it’s identical.  Many of the caveats to this approach should be
>> fairly obvious (footprint, duplication, quotas, format conversion,
>> etc), but for some workflows it provides the sorts of useful
>> guarantees an end user may want.
> [...]
> 
> The other problem this works around is that, even if providers offer
> similar images under the same names or via the same image property
> metadata, there's no guarantee that what's on the images is
> identical (same versions of the same set of packages preinstalled
> with the same initial configurations, same root filesystem
> formatting and parameters, et cetera). I too just upload identical
> images to different providers, even for my personal use, so that I
> have some increased assurance of parity for the instances I boot
> there.
> 

The nice thing, is that Glance provides checksums. Meaning that, if you do:

openstack image show -c checksum -f value \
	debian-9.8.2-20190303-openstack-amd64.qcow2

then you can make sure that's the same MD5 than at:

http://cdimage.debian.org/cdimage/openstack/archive/9.8.2-20190303/MD5SUMS

In such case, you know your cloud provider hasn't modified the official
Debian image.

It's just a shame that Glance doesn't show MD5 and not sha512 sums by
default...

Cheers,

Thomas Goirand (zigo)


From fungi at yuggoth.org  Thu Apr 11 23:28:05 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 11 Apr 2019 23:28:05 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
Message-ID: <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>

On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
> The nice thing, is that Glance provides checksums. Meaning that,
> if you do:
> 
> openstack image show -c checksum -f value \
> debian-9.8.2-20190303-openstack-amd64.qcow2
> 
> then you can make sure that's the same MD5 than at:
> 
> http://cdimage.debian.org/cdimage/openstack/archive/9.8.2-20190303/MD5SUMS

Well, I'm frequently booting from testing/unstable snapshots so even
if providers do have them in their catalogs they don't necessarily
update them on the same schedules. Thankfully, Glance has become
fairly ubiquitous in public OpenStack providers in recent years, so
at least I can grab one snapshot and upload it to all the
projects/regions I'm using.

> In such case, you know your cloud provider hasn't modified the
> official Debian image.

Well, last I checked, Nova doesn't *actually* verify those
checksums, and even if it did the software could still be adjusted
by a malicious operator anyway. But you're right, for well-known
images it at least means there's probably been no "helpful"
modifications made by the provider to "improve" my experience in
their environment.

> It's just a shame that Glance doesn't show MD5 and not sha512 sums
> by default...

It's not really that big of a deal. As pointed out, those checksums
aren't protecting you from malicious operators (really nothing can,
short of maybe executing workloads via homomorphic encryption and
storing data with something like Tahoe-LAFS), so they're merely
informational. And MD5 is not yet so compromised that I can make a
backdoored replacement image which calculates to the same md5sum as
an official Debian image unless I've also got control of some of the
data being included in that image (and if I had that, I probably
wouldn't need to resort to orchestrating checksum collisions to
carry out my nefarious plans for World domination anyway).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/34c79202/attachment.sig>

From Kevin.Fox at pnnl.gov  Thu Apr 11 23:48:26 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Thu, 11 Apr 2019 23:48:26 +0000
Subject: [osprofiler] Distributed tracing in OpenStack
In-Reply-To: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
References: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C2F274A@EX10MBOX03.pnnl.gov>

Oh, yes please! :)

Thanks,
Kevin
________________________________
From: Ilya Shakhat [shakhat at gmail.com]
Sent: Thursday, April 11, 2019 2:42 PM
To: openstack-discuss at lists.openstack.org
Subject: [osprofiler] Distributed tracing in OpenStack

Hi,

Distributed tracing is one of must-have features when one wants to track the full path of request going through different services and APIs. This makes it similar to shared request-id, but with nice visualization at the end [1]. In OpenStack the tracing can be achieved via osprofiler library. The library was introduced 5 years ago, and back then there was no standard approach on how to do tracing and that's why it stays aside from what has become a mainstream. Yet there is no single standard, but the major players are OpenTracing and OpenCensus communities. OpenTracing is represented by Uber's Jaeger which is the default tracer from k8s world.

Issues and limitations to be fixed:
1. Compatibility. While osprofiler library supports many different storage drivers, it has only one way of transferring trace context over the wire. Ideally the library should be compatible with other third-party tracers and allow traces to start in front of OpenStack APIs (e.g. in user apps) and continue after (e.g. in storage systems, or network management tools). [2]
2. Operation mode. With osprofiler tracing is initiated by user request, while in industrial solutions the tracing can be managed centrally via dynamic sampling policies.
3. In-process trace propagation. Depending on execution model (threaded, async) the ways of storing current trace context differ. OSProfiler supports thread-local model, which recently got broken with new async implementation in openstacksdk [3]. With OpenTracing it is possible to select the appropriate model alongside with tracer configuration.

What's the plan:
Switching to OpenTracing could be a good option to gain compatibility with 3rd-party solutions. The actual change should go to osprofiler library, but indirectly affects all OpenStack projects (should it be a global team goal then?). I'm going to make a PoC of proposed change, so reviews would be highly appreciated.

Comments, suggestions?

Thanks,
Ilya

[1] e.g. http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-redis/7c6c14e/osprofiler-traces/trace-3e5cc660-8815-4079-86b9-778af8469d79.html.gz
[2] https://bugs.launchpad.net/osprofiler/+bug/1798565
[3] https://bugs.launchpad.net/osprofiler/+bug/1818493
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/6f626080/attachment.html>

From mnaser at vexxhost.com  Fri Apr 12 00:00:16 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 11 Apr 2019 20:00:16 -0400
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
Message-ID: <9845CB2C-83D6-47C0-8DE4-1548272AAEB0@vexxhost.com>



Sent from my iPhone

> On Apr 11, 2019, at 4:47 PM, Lingxian Kong <anlin.kong at gmail.com> wrote:
> 
> Matt,
> 
> I've already replied in the patch, since you also mentioned the patch here, i think it's necessary also reply you here.
> 
> That patch failed to get attention from other team members and the community who are not interested in such change, as the PTL, i have to merge it myself to not block other patches. At the same time, some users were complaining the current trove image build approach, which could be improved with that patch.
> 
> If self-approved is something you disagree, I'd appreciate if you could offer some help for the review.

Should we perhaps look into the possibility of removing Trove from following stable policy by any chance?

It’s not ideal but I feel if the projects needs to start getting overhauled and brought to a good place, we may need to do this at cost of its stability?

> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud
> 
> 
>> On Fri, Apr 12, 2019 at 5:11 AM Matt Riedemann <mriedemos at gmail.com> wrote:
>> On 4/9/2019 7:37 PM, Tony Breeds wrote:
>> > Being PTL doesn't give you automatic rights to the stable branches as the
>> > requirements there are different.  I'm really happy to start mentoring
>> > you on the stable policy and have you review stables patches then after
>> > 3months(ish) we can add you to the stable group assuming everything
>> > looks good.
>> 
>> Maybe we should start a FAQ for this in the stable docs. This question 
>> comes up every release.
>> 
>> BTW, this is a good example of why PTLs aren't automatically on the 
>> stable team:
>> 
>> https://review.openstack.org/#/c/651672/
>> 
>> That change is extremely questionable as a backport.
>> 
>> -- 
>> 
>> Thanks,
>> 
>> Matt
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/5d529c00/attachment.html>

From ruijing.guo at intel.com  Fri Apr 12 01:23:11 2019
From: ruijing.guo at intel.com (Guo, Ruijing)
Date: Fri, 12 Apr 2019 01:23:11 +0000
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
Message-ID: <2EE296D083DF2940BF4EBB91D39BB89F40C58E67@SHSMSX104.ccr.corp.intel.com>

Hi, Clark

Do you have some guide to create CI based on nested virt? We can try it and see how much gap & stable?

Thanks,
-Ruijing

-----Original Message-----
From: Clark Boylan [mailto:cboylan at sapwetik.org] 
Sent: Tuesday, April 9, 2019 7:05 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [CI] nested virtualization support in OpenStack CI



On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> Hi, Clark
> 
> I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> virtualization.
> 

Can you describe this requirement in a bit more detail? Looking at docs it appears you need to have large pages. Maybe a "picture" will help too:

  Workload VM
  (cirros or similar small VM running under
   emulation or virtualized if nested virt is enabled)
       |
      V
  OpenStack Infra Test Node ("middle VM")
    This is where ovsdpdk runs right? And this requires large pages?
       |
      V
  Hypervisor (managed by our cloud providers)

Are we not able to do large pages with emulated workload VMs? Also can we do large pages on the Workload VM if the Infra Test Node isn't configured for them? If the infra test node isn't configured for them do we also need support for large pages from the Hypervisor?

If we can do large pages with emulated workload VMs and the hypervisor isn't required to support that we should be able to configure large pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of these things won't work.
In any case specific details on what is required and where it is required will be useful.

Clark



From tony at bakeyournoodle.com  Fri Apr 12 01:55:09 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 12 Apr 2019 11:55:09 +1000
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <9845CB2C-83D6-47C0-8DE4-1548272AAEB0@vexxhost.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <9845CB2C-83D6-47C0-8DE4-1548272AAEB0@vexxhost.com>
Message-ID: <20190412015507.GO7047@thor.bakeyournoodle.com>

On Thu, Apr 11, 2019 at 08:00:16PM -0400, Mohammed Naser wrote:

> Should we perhaps look into the possibility of removing Trove from
> following stable policy by any chance?

The change in question was published and merged by a single person in 3
days on master.  It isn't a stable policy/tag thing.


Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/bc38ff34/attachment-0001.sig>

From tony at bakeyournoodle.com  Fri Apr 12 02:04:34 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 12 Apr 2019 12:04:34 +1000
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
Message-ID: <20190412020434.GP7047@thor.bakeyournoodle.com>

On Thu, Apr 11, 2019 at 12:05:14PM -0500, Matt Riedemann wrote:
> On 4/9/2019 7:37 PM, Tony Breeds wrote:
> > Being PTL doesn't give you automatic rights to the stable branches as the
> > requirements there are different.  I'm really happy to start mentoring
> > you on the stable policy and have you review stables patches then after
> > 3months(ish) we can add you to the stable group assuming everything
> > looks good.
> 
> Maybe we should start a FAQ for this in the stable docs. This question comes
> up every release.

I'm working on it.  I think this can be added to the project-teams-guide
as it'd generally applicable.
 
> BTW, this is a good example of why PTLs aren't automatically on the stable
> team:
> 
> https://review.openstack.org/#/c/651672/
> 
> That change is extremely questionable as a backport.

Agreeed.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/ad8c3259/attachment.sig>

From tony at bakeyournoodle.com  Fri Apr 12 02:09:16 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 12 Apr 2019 12:09:16 +1000
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ22ia4xtTcCqusTEiGyPB_yr0-NQbCfeZm+_3J9oYKw0A@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <CALjNAZ22ia4xtTcCqusTEiGyPB_yr0-NQbCfeZm+_3J9oYKw0A@mail.gmail.com>
Message-ID: <20190412020916.GQ7047@thor.bakeyournoodle.com>

On Wed, Apr 10, 2019 at 12:54:03PM +1200, Lingxian Kong wrote:
> Hi Tony,
> 
> Thanks for the explanation of the stable branch policy, and very good to
> know we are in the similar TZ (guess you locate in Aus).

Yup so not total overlap but some :)
 
> It's not a hard requirement for me to become one of the stable branch core
> reviewers, the original demand was to merge Trove stable/stein patches in
> order to finish the community runtime requirement for Stein dev cycle.
> 
> The patches were all sorted out thanks to Matt, so all good for now.

Cool.  As I've said before I'm happy to mentor you, which means you need
to be doing stable reviews.  It's a great idea when doign those reviews
to articulate the aspects of the stable policy you evaluated.  It
doens't need to be verbose, somethign like:

'Clean backport, closes a user visible bug, low risk' ; or
'Clean backport except where described in the conflict section.

Related to a bug  No API impact'

that sort of thing

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/a3fe2de3/attachment.sig>

From mriedemos at gmail.com  Fri Apr 12 02:14:42 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 11 Apr 2019 21:14:42 -0500
Subject: [nova][cinder][keystone] Unshelve in nova, cinder
 initialize_connection with user context
In-Reply-To: <98b89706-8426-4ebb-9726-63aaf245b274@www.fastmail.com>
References: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
 <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>
 <98b89706-8426-4ebb-9726-63aaf245b274@www.fastmail.com>
Message-ID: <bfa55204-5a19-fc69-87a9-09040cc703e9@gmail.com>

On 4/11/2019 10:52 AM, Colleen Murphy wrote:
> Forgive my unfamiliarity with the nova and cinder APIs but it sounds like the shelve operation in nova is a purely nova-side API, while the unshelve operation calls cinder's volume-attach API if the instance had a mounted volume before it was shelved. Since the operation involves cinder, you'd have to update the cinder policy to allow this unprivileged user to perform the volume-attach action. It's not really a bug, it's just fallout from having policies managed separately for separate services.

Correct, the user has to also be able to attach/detach volumes to/from 
their server since shelve/unshelve does that under the covers more or less.

The same actually happens with ports, but you have to configure nova to 
have access to neutron's port binding API which is elevated (admin or 
service user token) beyond the normal user auth.

Mitaka doesn't have configuration like that for cinder in nova, it was 
added a bit later but there is a patch being backported which you could 
also try to backport to mitaka - but it might be a bit messy (the 
keystoneauth stuff wasn't being used by nova in mitaka):

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

-- 

Thanks,

Matt


From anlin.kong at gmail.com  Fri Apr 12 02:14:40 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Fri, 12 Apr 2019 14:14:40 +1200
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <20190412015507.GO7047@thor.bakeyournoodle.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <9845CB2C-83D6-47C0-8DE4-1548272AAEB0@vexxhost.com>
 <20190412015507.GO7047@thor.bakeyournoodle.com>
Message-ID: <CALjNAZ3_jGSJ+GkeX8ZjNad2MneNRAwFO5hBq1GDQCn3TNp4Xg@mail.gmail.com>

On Fri, Apr 12, 2019 at 1:55 PM Tony Breeds <tony at bakeyournoodle.com> wrote:

> On Thu, Apr 11, 2019 at 08:00:16PM -0400, Mohammed Naser wrote:
>
> > Should we perhaps look into the possibility of removing Trove from
> > following stable policy by any chance?
>
> The change in question was published and merged by a single person in 3
> days on master.  It isn't a stable policy/tag thing.
>

So, how long do you think it's appropriate for the person who is mostly the
only one cares about the improvement before merging the patch by himself?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/23faef0c/attachment.html>

From mriedemos at gmail.com  Fri Apr 12 02:24:33 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 11 Apr 2019 21:24:33 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
Message-ID: <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>

On 4/11/2019 3:47 PM, Lingxian Kong wrote:
> 
> I've already replied in the patch, since you also mentioned the patch 
> here, i think it's necessary also reply you here.
> 
> That patch failed to get attention from other team members and the 
> community who are not interested in such change, as the PTL, i have to 
> merge it myself to not block other patches. At the same time, some users 
> were complaining the current trove image build approach, which could be 
> improved with that patch.
> 
> If self-approved is something you disagree, I'd appreciate if you could 
> offer some help for the review.

I realize Trove is in a tough spot so I'm not trying to criticize and I 
understand the frustration of waiting to get something merged that you 
or your customers need. I don't have great answers for these problems. I 
was simply trying to highlight the fact that while that patch may be 
appropriate to merge on master it may not be appropriate to merge on 
stable, so there are different rules if you're following the stable 
policy and that's why cores on master aren't necessarily cores on stable 
branches.

At the same time I'm coming from a place where we try to enforce some 
kind of standards across projects under openstack TC governance, and 
trove is in a tough spot there.

But as Mohammed pointed out, if Trove elects to *not* follow the stable 
policy then we simply have to remove the "stable:follows-policy" tag 
from governance and trove is free to backport as it pleases (I think? 
Tony can correct me).

-- 

Thanks,

Matt


From anlin.kong at gmail.com  Fri Apr 12 02:39:45 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Fri, 12 Apr 2019 14:39:45 +1200
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
Message-ID: <CALjNAZ318=UcFcNHLFW7nSh_grCw4zcsp2iUGW876L9teTiarw@mail.gmail.com>

On Fri, Apr 12, 2019 at 2:27 PM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/11/2019 3:47 PM, Lingxian Kong wrote:
> >
> > I've already replied in the patch, since you also mentioned the patch
> > here, i think it's necessary also reply you here.
> >
> > That patch failed to get attention from other team members and the
> > community who are not interested in such change, as the PTL, i have to
> > merge it myself to not block other patches. At the same time, some users
> > were complaining the current trove image build approach, which could be
> > improved with that patch.
> >
> > If self-approved is something you disagree, I'd appreciate if you could
> > offer some help for the review.
>
> I realize Trove is in a tough spot so I'm not trying to criticize and I
> understand the frustration of waiting to get something merged that you
> or your customers need. I don't have great answers for these problems. I
> was simply trying to highlight the fact that while that patch may be
> appropriate to merge on master it may not be appropriate to merge on
> stable, so there are different rules if you're following the stable
> policy and that's why cores on master aren't necessarily cores on stable
> branches.
>

Totally understand, thanks for the explanation. That's why I explained in
the above email that it's not my original requirement to become a stale
core, the first email was just a heading up to ask help for the stable
branch review.


> At the same time I'm coming from a place where we try to enforce some
> kind of standards across projects under openstack TC governance, and
> trove is in a tough spot there.
>
> But as Mohammed pointed out, if Trove elects to *not* follow the stable
> policy then we simply have to remove the "stable:follows-policy" tag
> from governance and trove is free to backport as it pleases (I think?
> Tony can correct me).
>

In the current situation, i prefer to follow the ways that people who care
about the project(I mean, Trove) and are willing to offer help to fix
things should have the permission to merge patches to stable. So, according
to
https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html#deprecation,
as Trove PTL of Train dev cycle, can I ask to remove stable:follows-policy
tag for Trove?
---
Cheers,
Lingxian Kong
Catalyst Cloud Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/a7cc0e54/attachment-0001.html>

From tony at bakeyournoodle.com  Fri Apr 12 02:47:09 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 12 Apr 2019 12:47:09 +1000
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190327125654.5bazj5hic3ilj27q@barron.net>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
Message-ID: <20190412024708.GR7047@thor.bakeyournoodle.com>

On Wed, Mar 27, 2019 at 08:56:54AM -0400, Tom Barron wrote:
> In manila we recently merged backports of a change [1] that aims
> to fix up faulty configuration option deprecations in the
> Dell-EMC VMAX driver.  The question at hand is whether (a) we
> should revert these backports on the grounds that the
> deprecations were faulty and therefore are only effective from
> Stein forwards, or whether (b) the deprecations actually worked
> and took effect back when Ocata was the development branch but
> had faults that should be corrected all the way back to Pike
> before it goes EM.

Thanks for writing this all up Tom.  I'm sorry it's taken me so long to
get to it.
 
> I think (b) is the correct answer but let's check.
> 
> On Jan 10 2017 a review [2] merged that deprecated generic
> Dell-EMC driver options in favor of model-specific options [2].
> There were two models at the time, Unity and VNX.  This change
> was in itself unproblematic.
> 
> On Jan 24 2017 a review [3] merged that introduced a third
> Dell-EMC model, VMAX.  This new code introduced VMAX specific
> options, consistent with the deprecation of the generic Dell-EMC
> options.  However it had two problems which review [1] corrects.
> When it defined the new VMAX-specific options it failed to
> indicate the corresponding old generic options via
> 'deprecated_name' [4].  Worse, the code that consumed the options
> actually looked for the old generic 'emc_interface_ports' option
> instead of the new 'vmax_ethernet_ports' option.  The only way to
> set a value for this option was to use its deprecated
> form.

So someone that is using the VMAX driver from 5.0.3 has set
emc_interface_ports in the config.  Assuming we don't revert and release
5.0.4[1], that same config file will continue to work but there will now be
a deprecation warning in the logs.

The VMAX user probably had to look at the code to workout that the
config sample was out of sync with the code?

Yours Tony.

[1] or probably 5.1.0 as a signal to operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/12da72f8/attachment.sig>

From tony at bakeyournoodle.com  Fri Apr 12 02:50:37 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 12 Apr 2019 12:50:37 +1000
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190401103544.ew26pngy2xaba62h@barron.net>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <CAKSuTPZceozexAtuJtuKH=z4SUkK00n37H_=oniJ1wpWh+18Og@mail.gmail.com>
 <20190330204021.leizflkinun32bwy@barron.net>
 <CAKSuTPYLgMTAaVjeD7bvRyoOuuY4hAqbqFg7LjQ6qSS+iXptWw@mail.gmail.com>
 <20190401103544.ew26pngy2xaba62h@barron.net>
Message-ID: <20190412025036.GS7047@thor.bakeyournoodle.com>

On Mon, Apr 01, 2019 at 06:35:44AM -0400, Tom Barron wrote:

> At the risk of stating the obvious, but for the record, this backport
> doesn't change *when* these deprecations occurred for VMAX.  They occurred
> in Stein development cycle, not during the Ocata development cycle, and the
> earliest the deprecated options could be removed is Train.

That brings up an interesting point and one which is largely tangental
to the stable backport issue but AFAICT the 'deprecated' names are still
called out as the correct way to configure the driver.  At least in the
case of the Unity diver:

https://docs.openstack.org/manila/latest/admin/emc_unity_driver.html#configurations

That could be fixed and backported to stein.  I sort of think that sets
the timer to 'U' but that certainly isn't supported by our policy and is
a project team decision.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/d8149ad1/attachment.sig>

From jordan.ansell at catalyst.net.nz  Fri Apr 12 03:12:32 2019
From: jordan.ansell at catalyst.net.nz (Jordan Ansell)
Date: Fri, 12 Apr 2019 15:12:32 +1200
Subject: [nova][cinder][keystone] Unshelve in nova, cinder
 initialize_connection with user context
In-Reply-To: <bfa55204-5a19-fc69-87a9-09040cc703e9@gmail.com>
References: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
 <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>
 <98b89706-8426-4ebb-9726-63aaf245b274@www.fastmail.com>
 <bfa55204-5a19-fc69-87a9-09040cc703e9@gmail.com>
Message-ID: <cff30b24-8465-60be-9fe0-0b56c9c1e335@catalyst.net.nz>

On 12/04/19 2:14 PM, Matt Riedemann wrote:
> On 4/11/2019 10:52 AM, Colleen Murphy wrote:
>> Forgive my unfamiliarity with the nova and cinder APIs but it sounds
>> like the shelve operation in nova is a purely nova-side API, while
>> the unshelve operation calls cinder's volume-attach API if the
>> instance had a mounted volume before it was shelved. Since the
>> operation involves cinder, you'd have to update the cinder policy to
>> allow this unprivileged user to perform the volume-attach action.
>> It's not really a bug, it's just fallout from having policies managed
>> separately for separate services.
>
> Correct, the user has to also be able to attach/detach volumes to/from
> their server since shelve/unshelve does that under the covers more or
> less.
>
> The same actually happens with ports, but you have to configure nova
> to have access to neutron's port binding API which is elevated (admin
> or service user token) beyond the normal user auth.
>
> Mitaka doesn't have configuration like that for cinder in nova, it was
> added a bit later but there is a patch being backported which you
> could also try to backport to mitaka - but it might be a bit messy
> (the keystoneauth stuff wasn't being used by nova in mitaka):
>
> https://review.openstack.org/#/c/603044/
>
Thank you for that, I'll have a look into it and see if this patch is
something we could use :)

And thanks too to Colleen and Sean for your comments earlier and link to
information about permission scope in keystone. Your comments, together
with what Matt is saying here tidies up my understanding of just what is
happening.

For now we have gone with a fix along the same vein as what Colleen
suggested, allowing the cinder os-initialize_connection action to be
performed by the restricted user.

Interesting to me is why nova (using the restricted user's context) is
able to perform the attach volume operation in full (starting a stopped
instance) but not the sub-operation of attaching a volume, just setting
up the volume connection (as with unshelving).

Also interesting is the connection information returned by the cinder
action we're discussing, as this "SAN" information of no /practical/ use
to a user and sensitive in some cases. It strengthens my belief that
something akin to the patch Matt has shared ought to be something we
consider.

Regards,
Jordan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/d8018e39/attachment.html>

From dangtrinhnt at gmail.com  Fri Apr 12 03:14:53 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Fri, 12 Apr 2019 12:14:53 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
 <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>
Message-ID: <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>

Hi Andreas,

Just one question, is openstack/ceilometermiddleware project belongs to the
Telemetry team? If that is the case, please add me to the team.

Thank you,

On Wed, Apr 10, 2019 at 4:50 PM Andreas Jaeger <aj at suse.com> wrote:

> On 10/04/2019 08.50, Trinh Nguyen wrote:
> > Hi Jens,
> >
> > I just see I'm not in the list of these following groups on gerrit:
> >
> > ceilometer-release
> > aodh-release
> > panko-release
> >
> > Could you please add me to those as well?
>
> You don't need to be - releases are done via the releases repo.
>
> Those groups are completely unused currently,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>    GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
>        HRB 21284 (AG Nürnberg)
>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/8fad8209/attachment.html>

From dangtrinhnt at gmail.com  Fri Apr 12 04:35:12 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Fri, 12 Apr 2019 13:35:12 +0900
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CADJ6S4F5QgRYKFT=Jm3=wFDnLiLCX6Bkp2axc3uPuwhWpsVTbg@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
 <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>
 <CAN2nDNsPLSif6hDiSr1AD_Rxn9X7aAQdKKg8Y_+ZEg+ybaOPeQ@mail.gmail.com>
 <CADJ6S4F5QgRYKFT=Jm3=wFDnLiLCX6Bkp2axc3uPuwhWpsVTbg@mail.gmail.com>
Message-ID: <CADJ6S4EruA54=j0H95UWaBNA36Srqq1-1a5_kB1=GJU3nKkDBw@mail.gmail.com>

I found lacking communication is one of the problems that most of the teams
need to improve in order to have a healthy community. So, if you're
nominating yourself or someone, please make sure you understand that and
being responsive on either the mailing list or IRC.

Thanks,
-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/ccf326ab/attachment-0001.html>

From aaronzhu1121 at gmail.com  Fri Apr 12 04:55:32 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Fri, 12 Apr 2019 12:55:32 +0800
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CADJ6S4EruA54=j0H95UWaBNA36Srqq1-1a5_kB1=GJU3nKkDBw@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <CAN2nDNvhkUtJ4=aA8HGVBkFAyqo+A7HVC5NB2gY8zODeceGcvQ@mail.gmail.com>
 <CALjNAZ07dM4=tZtW7V7T_TKeneoBa2xy5W2XoZSTLjtM36b5bg@mail.gmail.com>
 <CAN2nDNsPLSif6hDiSr1AD_Rxn9X7aAQdKKg8Y_+ZEg+ybaOPeQ@mail.gmail.com>
 <CADJ6S4F5QgRYKFT=Jm3=wFDnLiLCX6Bkp2axc3uPuwhWpsVTbg@mail.gmail.com>
 <CADJ6S4EruA54=j0H95UWaBNA36Srqq1-1a5_kB1=GJU3nKkDBw@mail.gmail.com>
Message-ID: <CAN2nDNt13Vq12zWA1fw8xQecycSW08W35hDrL940fh6cV+=FkQ@mail.gmail.com>

Agree with this. This is the basic requirements.

Regards,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月12日 周五12:38写道：

> I found lacking communication is one of the problems that most of the
> teams need to improve in order to have a healthy community. So, if you're
> nominating yourself or someone, please make sure you understand that and
> being responsive on either the mailing list or IRC.
>
> Thanks,
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/e9911d12/attachment.html>

From aj at suse.com  Fri Apr 12 06:45:03 2019
From: aj at suse.com (Andreas Jaeger)
Date: Fri, 12 Apr 2019 08:45:03 +0200
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
 <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>
 <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>
Message-ID: <8dcf3ce8-a1cd-c784-abc0-419610819bdd@suse.com>

On 12/04/2019 05.14, Trinh Nguyen wrote:
> Hi Andreas,
> 
> Just one question, is openstack/ceilometermiddleware project belongs to
> the Telemetry team? If that is the case, please add me to the team.
> 

Trinh,

the list of repositories belonging to Telemetry are in the governance
repo and published at:
https://governance.openstack.org/tc/reference/projects/telemetry.html

So, yes, ceilometermiddleware is part of it.

If you look at the ACLs of that repo ([1] or [2]), you see that there is
no specific group for it, it's all done with the ceilometer-core group
which you are part of.

So, nothing to do, you should have all the permission you need,
Andreas


[1]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/ceilometermiddleware.config
[2]
https://review.openstack.org/#/admin/projects/openstack/ceilometermiddleware,access
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
       HRB 21284 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



From zigo at debian.org  Fri Apr 12 07:00:31 2019
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 12 Apr 2019 09:00:31 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
Message-ID: <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>

On 4/12/19 1:28 AM, Jeremy Stanley wrote:
> On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
>> In such case, you know your cloud provider hasn't modified the
>> official Debian image.
> 
> Well, last I checked, Nova doesn't *actually* verify those
> checksums, and even if it did the software could still be adjusted
> by a malicious operator anyway.

Oh, what do you mean? I thought it had an option for that...

Cheers,

Thomas Goirand (zigo)


From hid-nakamura at vf.jp.nec.com  Fri Apr 12 08:00:15 2019
From: hid-nakamura at vf.jp.nec.com (Hidekazu Nakamura)
Date: Fri, 12 Apr 2019 08:00:15 +0000
Subject: [Watcher] Proposing chenker and Dantalion for core
In-Reply-To: <201904101718043731546@zte.com.cn>
References: <201904101718043731546@zte.com.cn>
Message-ID: <8FC2060F93794D44942D588B8B547287123F4E44@BPXM03GP.gisp.nec.co.jp>

+1

I know Watcher project needs more active core reviewers and they contributed actively in the last six months.
I hope they will review code with better quality in the Train cycle.

Thanks,
Hidekazu Nakamura


From: li.canwei2 at zte.com.cn <li.canwei2 at zte.com.cn>
Sent: Wednesday, April 10, 2019 6:18 PM
To: openstack-discuss at lists.openstack.org
Subject: [Watcher] Proposing chenker and Dantalion for core


Hi,

Now Watcher need more active core reviewers, I'd like to propose adding chenker and Dantalion to core team.

They all did a great contribution during the last six months [1].



[1]: https://www.stackalytics.com/report/contribution/watcher-group/90



Thanks!

Canwei Li















-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/5f15e88c/attachment-0001.html>

From tobias.rydberg at citynetwork.eu  Fri Apr 12 08:07:04 2019
From: tobias.rydberg at citynetwork.eu (Tobias Rydberg)
Date: Fri, 12 Apr 2019 10:07:04 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20693c9f-7548-e55a-764a-dcbdfcc5d3b0@gmail.com>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <20693c9f-7548-e55a-764a-dcbdfcc5d3b0@gmail.com>
Message-ID: <e097a76f-feaf-94c8-3a5b-8de19cf87764@citynetwork.eu>

Like this idea! This is definitely one of the pain points for public 
cloud end users trying to setup multi-cloud implementations.

A combination of the two suggestions, guidelines for naming and 
properties on the public images would be *good enough* for most of the 
end users we have as public cloud. What I understand from them is that 
they are not super interested (again, most of them) in the very detailed 
differences that might be between images of the same OS and version, and 
for the rest out there that is important for, this will still be a 
better experience for them than what we have today.

Tobias

Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

On 2019-04-11 16:07, Brian Rosmaita wrote:
> On 4/7/19 5:35 PM, Mohammed Naser wrote:
>> Hi everyone,
>>
>> Something that I've been dealing with is the fact that regardless of
>> what cloud you're using, the naming structure is very much different.
>> While we aim to be interoperable, if I want to "boot an Debian Stretch
>> server", the image name will probably be different all over the
>> places.
>>
>> Is there some sort of way we can eliminate this by implementing a
>> standard naming convention which would allow us to use the same images
>> across all systems?
>>
>> I'm just opening the idea for discussion, I'd love to hear what others
>> think about this.
>>
>> Mohammed
>>
> Sorry to be late to the discussion.  We've had Forum/PTG sessions on
> this, and while everyone agrees that something needs to be done, it's
> difficult to standardize on what.  The key takeaway has been to use some
> combination of the common image properties (as Tim suggests).  The
> upside is that these are propagated by the nova image-create action
> (unless they're ruled out by the nova non_inheritable_image_properties
> config), and so a user snapshot will have the os_distro and os_version
> on them, so this info won't be lost by an image rename.  (The naming
> scheme Fei Long describes is a clever way to get this info into the
> image name, but it has the downside that it will be lost on user snapshots.)
>
> If the current common image properties aren't sufficient, it's easy to
> extend them because under the hood they're simply custom image
> properties for which people have agreed on a name and (more or less)
> what the value should be.  For example, a 'description' property was
> added in the Stein release.
>
> Also, just a reminder that "hidden" images were introduced in Rocky via
> the 'os_hidden' image property; they allow you to make only your most
> recent public images show up by default in a users' image-list calls.
>
> cheers,
> brian
>


From frickler at offenerstapel.de  Fri Apr 12 08:29:19 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Fri, 12 Apr 2019 08:29:19 +0000
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
Message-ID: <1555057759.4997.31.camel@offenerstapel.de>

On Wed, 2019-04-10 at 16:34 -0400, Jim Rollenhagen wrote:
...
> Here's how a repository's new namespace will be decided, as it stands
> today:
> 
> - is the repo listed in projects.yaml[2]? If so, "openstack".
> - is the repo listed in legacy.yaml[3]? If so, "openstack".
> - is the repo listed in foundation-board-repos.yaml[4]? If so,
> "openstack".
> - is the repo listed in sigs-repos.yaml[5]? If so, "openstack".
> - is the repo listed in technical-committee-repos.yaml[6]? If so,
> "openstack".
> - is the repo listed in user-committee-repos.yaml[7]? If so,
> "openstack".

Is there a script already in place to generate the list of repos that
will land in "openstack" under the previous rules? I think it would be
helpful to have that list published somewhere, possibly in combination
with the list of repos that don't match, so that interested people can
easily check the status of a repo they are interested in.

Jens


From cdent+os at anticdent.org  Fri Apr 12 10:13:39 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Fri, 12 Apr 2019 11:13:39 +0100 (BST)
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
Message-ID: <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>

On Thu, 11 Apr 2019, Adam Spiers wrote:

> Ed Leafe <ed at leafe.com> wrote: 
>> The concept of “owning” particular traits isn’t in Placement. Rather, it is 
>> in the domain of the service that is using Placement. So any enforcement 
>> regarding which traits are acceptable has to be on the calling end, not in 
>> the Placement API. 
>
> That feels like a slight jump in logic to me: the API can enforce ownership 
> without being the authoritative source of truth for that ownership.  For 
> example, as I just suggested elsewhere in this thread, (static) ownership of 
> driver-provided traits could be tracked in os_traits.  Maybe that's a dumb 
> idea; I'm not sure.

It's not a dumb idea, but it's not really an idea we want to pursue.
We've made an effort to keep both os-traits and os-resource-classes
as dumb and "symbol only" as possible, minimizing code and metadata.
Indicating ownership would require metadata. Enforcing it would
require some form of code.

> Having said that ... 
>> So yeah, “do nothing”. 
>
> I'm totally fine with this too ;-)  I only raised it because when I was 
> developing the driver-owned capability traits code, people seemed somewhat 
> concerned with the possibility of admins screwing things up. If the concern 
> is minimal then I'm certainly not religious about adding extra safeguards.

Seeing as there's no huge drive for action on this topic, I've
marked this topic as decided ("do nothing") on the etherpad [1] and
we can ignore this thread henceforth.

If people have additional ideas and thoughts please feel free to
keep it alive.


[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From soulxu at gmail.com  Fri Apr 12 10:17:02 2019
From: soulxu at gmail.com (Alex Xu)
Date: Fri, 12 Apr 2019 18:17:02 +0800
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
Message-ID: <CAH7mGaubwt9c6optpgFbFQk-mhX7pJxJHL1oM2bcWNg7w-JdYQ@mail.gmail.com>

Chris Dent <cdent+os at anticdent.org> 于2019年4月10日周三 上午1:31写道：

>
> From the etherpad [1] (the cross project one):
>
> * This came up with the effort to add a multiattach capability
>    filter, at
> https://review.openstack.org/#/c/645316/1/nova/compute/api.py at 1098
>
> * The problem: we want to be able to request allocation candidates
>    filtered by a trait that exists on the root provider; but
>
>      * (a) the root provider may provide no resources (eventually -
>        e.g. CPU/mem in NUMA providers, shared disk); and/or
>
>          * (My brain hurts from the concept for a provider that
>            provides nothing. Perhaps it provides something we aren't
>            remembering to count?)
>
>      * (b) we are using only numbered groups and would have to guess
>        where to stuff the `required` - again probably based on
>        looking for the VCPU/mem resources, which, as above, may wind
>        up not on the root provider.
>

Yea, just take a look at this spec https://review.openstack.org/#/c/647578/4,
after
we have NUMA in Placement, then the VCPU/mem in the child NUMA RP, but those
traits are still in the root provider.


>
> This, basically, is how/when do we deal with resource providers that
> have traits but have no classes of inventory of their own (all of it
> is on their descendants). The "My brain hurts" comment above is
> mine.
>
> The discussion on the review above (good backgrounder for this
> thread) had little to do with the immediate need of the proposed
> feature. It was a concern about how things will work in the future.
> So there are two salient questions (and presumably plenty of other
> sidebars):
>
> * How should it work?
> * What is the timeline for when it needs to work?
>
> [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
>
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/b7838d6a/attachment.html>

From cdent+os at anticdent.org  Fri Apr 12 10:22:24 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Fri, 12 Apr 2019 11:22:24 +0100 (BST)
Subject: [placement][ptg] We like the perfload job, maybe we should rally?
In-Reply-To: <6a189ea4-a0f1-5b22-692c-c55934619710@hco.ntt.co.jp>
References: <alpine.OSX.2.21.1904091341550.93787@cdent-a01.vmware.com>
 <A13B983F-44C3-42D5-A26D-78175A5E60B9@leafe.com>
 <bf5380e3-402b-7808-74e6-2e70bd73b938@gmail.com>
 <6806ae976a91c5f47629daded10727193941a10e.camel@redhat.com>
 <6a189ea4-a0f1-5b22-692c-c55934619710@hco.ntt.co.jp>
Message-ID: <alpine.OSX.2.21.1904121115300.33229@cdent-a01.vmware.com>

On Thu, 11 Apr 2019, Tetsuro Nakamura wrote:

> I'm not sure about rally,
> but I feel better if we have one more performance measurement case to 
> exercise the nested/sharing handling path before we go further enabling more 
> features on this like the resource provider subtree affinity spec.

This is an excellent point. So I've made a story: https://storyboard.openstack.org/#!/story/2005443

I think that gives us a reasonable next action on this topic and we
don't need to go much further than that. So feel free to ignore this
topic henceforth, but if you have more to say everyone is more than
welcome to keep it going.
-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From smooney at redhat.com  Fri Apr 12 11:48:45 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 12 Apr 2019 12:48:45 +0100
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <2EE296D083DF2940BF4EBB91D39BB89F40C58E67@SHSMSX104.ccr.corp.intel.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C58E67@SHSMSX104.ccr.corp.intel.com>
Message-ID: <a08f325b79884eb8c4b568822806267a99c3dc0b.camel@redhat.com>

On Fri, 2019-04-12 at 01:23 +0000, Guo, Ruijing wrote:
> Hi, Clark
> 
> Do you have some guide to create CI based on nested virt? We can try it and see how much gap & stable?
the intel nfv ci is an example of this.

assuming you ment how do i creat a third party ci job this is the basic steps.

in my experience it more or less jsut works however the kernel that ships in ubuntu 18.04 is broken
the ubuntu 16.04 kernel works fine as does the centos 7 kernel
if you build it on ubunut install ukuu and use it to install the unpatched mainline 5.0 kernel.

the kernel in the guest is less important then getting the kernel on the host correct.

on the host you obviorly need to also enable kvm nested virt in the kernel module parmaters.
sean at cloud-5:~$ cat /sys/module/kvm_intel/parameters/nested
Y
i belive its on by default as of one of the latest kernel its definetly on by default in 5.0

i enable nested virt via the kernel command line 
sean at cloud-5:~$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-5.0.0-050000-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet intel_iommu=on iommu=pt
console=tty0 serial console=ttyS0,115200n8 hugepagesz=2M hugepages=51200 irqaffinity=0,12,24,36 kvm-intel.nested=1
nfs.enable_ino64=1 nohz_full=1-11,13-23,25-35,37-47 numa_balancing=enable rcu_nocbs=1-11,13-23,25-35,37-47 rcu_nocb_poll
vsyscall=native

the rest is the same as setting up any other ci.

if you ment is the a guide to setting up a job that used nested virt instead of how to create a nested virt ci you can
ignore the above and its reltvly trivial. you just need to set the libvirt virt dirver to kvm in you job config the
issue is on most vms upstream that will cause the build to fail as they dont have nested virt enableded on the host.

there are a small set of nodeset that do have nested virt but for now im currently exploing alternitive to nested virt
for ovsdpdk testing. i have 2 paths that i am currently looking at. first the mttcg qemu backend with libvirt 5.2 via
a fedora based job and second qemu with file based memory.

if they prove unviable ill switch my efforts back to nested virt either via openlab or reaching out to the ci providers
that currnetly provied nested virt vms to the gate and asking there permission to use there nodesets for the testing.

regards
sean

> 
> Thanks,
> -Ruijing
> 
> -----Original Message-----
> From: Clark Boylan [mailto:cboylan at sapwetik.org] 
> Sent: Tuesday, April 9, 2019 7:05 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [CI] nested virtualization support in OpenStack CI
> 
> 
> 
> On Mon, Apr 8, 2019, at 3:54 PM, Guo, Ruijing wrote:
> > Hi, Clark
> > 
> > I am trying to add ovsdpdk ci job in neutron. Ovsdpdk need nested 
> > virtualization.
> > 
> 
> Can you describe this requirement in a bit more detail? Looking at docs it appears you need to have large pages. Maybe
> a "picture" will help too:
> 
>   Workload VM
>   (cirros or similar small VM running under
>    emulation or virtualized if nested virt is enabled)
>        |
>       V
>   OpenStack Infra Test Node ("middle VM")
>     This is where ovsdpdk runs right? And this requires large pages?
>        |
>       V
>   Hypervisor (managed by our cloud providers)
> 
> Are we not able to do large pages with emulated workload VMs? Also can we do large pages on the Workload VM if the
> Infra Test Node isn't configured for them? If the infra test node isn't configured for them do we also need support
> for large pages from the Hypervisor?
> 
> If we can do large pages with emulated workload VMs and the hypervisor isn't required to support that we should be
> able to configure large pages on the Infra Test Node and boot emulated guests, but my guess is that at least one of
> these things won't work.
> In any case specific details on what is required and where it is required will be useful.
> 
> Clark
> 
> 



From aspiers at suse.com  Fri Apr 12 12:57:31 2019
From: aspiers at suse.com (Adam Spiers)
Date: Fri, 12 Apr 2019 13:57:31 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
Message-ID: <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>

Chris Dent <cdent+os at anticdent.org> wrote: 
>On Thu, 11 Apr 2019, Adam Spiers wrote: 
>
>>Ed Leafe <ed at leafe.com> wrote: 
>>>The concept of “owning” particular traits isn’t in Placement. 
>>>Rather, it is in the domain of the service that is using 
>>>Placement. So any enforcement regarding which traits are 
>>>acceptable has to be on the calling end, not in the Placement API. 
>>
>>That feels like a slight jump in logic to me: the API can enforce 
>>ownership without being the authoritative source of truth for that 
>>ownership.  For example, as I just suggested elsewhere in this 
>>thread, (static) ownership of driver-provided traits could be 
>>tracked in os_traits.  Maybe that's a dumb idea; I'm not sure. 
>
>It's not a dumb idea, but it's not really an idea we want to pursue. 
>We've made an effort to keep both os-traits and os-resource-classes 
>as dumb and "symbol only" as possible, minimizing code and metadata. 
>Indicating ownership would require metadata. 

I was thinking of something like 

    DRIVER_TRAITS = [
        ot.COMPUTE_FOO,
        ot.COMPUTE_BAR,
        ...
    ]

which seems to me more like data than metadata, and would presumably 
meet the requirement to be dumb and "symbol only". 

In fact, even without that we could just test for the COMPUTE_ prefix 
and that would cover all but one segment of the Venn diagram 

    https://pasteboard.co/I3iqqNm.jpg

i.e. the "Should be unset if set by admin (but we're not there yet)" 
bit.

>Enforcing it would require some form of code. 

Sure.  I don't understand the policy code yet, but at a wild guess it 
would need separate policies for human admins vs. nova. 

>>Having said that ... 
>>>So yeah, “do nothing”. 
>>
>>I'm totally fine with this too ;-)  I only raised it because when I 
>>was developing the driver-owned capability traits code, people 
>>seemed somewhat concerned with the possibility of admins screwing 
>>things up. If the concern is minimal then I'm certainly not 
>>religious about adding extra safeguards. 
>
>Seeing as there's no huge drive for action on this topic, I've 
>marked this topic as decided ("do nothing") on the etherpad [1] and 
>we can ignore this thread henceforth. 

Well, there's still the small matter of where to include the Venn 
diagram.  As I wrote in a previous email (which you may have not seen; 
for some reason it didn't show up in the list archives yet), the idea 
of putting it at the bottom of 

    https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits

was already rejected, otherwise it would have been there already: 

    https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523

But other than that, I'm fine with "do nothing". 


From mriedemos at gmail.com  Fri Apr 12 12:59:52 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 12 Apr 2019 07:59:52 -0500
Subject: [nova][cinder][keystone] Unshelve in nova, cinder
 initialize_connection with user context
In-Reply-To: <cff30b24-8465-60be-9fe0-0b56c9c1e335@catalyst.net.nz>
References: <749172c6-bf03-d5d8-28bf-52cfc5e258cb@catalyst.net.nz>
 <ae48218eee90f5f68fae43283b46efa960f8ac67.camel@redhat.com>
 <98b89706-8426-4ebb-9726-63aaf245b274@www.fastmail.com>
 <bfa55204-5a19-fc69-87a9-09040cc703e9@gmail.com>
 <cff30b24-8465-60be-9fe0-0b56c9c1e335@catalyst.net.nz>
Message-ID: <f69a8ab6-1b5c-1519-beba-2dcf9149927c@gmail.com>

On 4/11/2019 10:12 PM, Jordan Ansell wrote:
> Also interesting is the connection information returned by the cinder 
> action we're discussing, as this "SAN" information of no /practical/ use 
> to a user and sensitive in some cases. It strengthens my belief that 
> something akin to the patch Matt has shared ought to be something we 
> consider.

I believe the issue you're talking about is this bug:

https://bugs.launchpad.net/cinder/+bug/1736773

-- 

Thanks,

Matt


From mriedemos at gmail.com  Fri Apr 12 13:01:27 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 12 Apr 2019 08:01:27 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ318=UcFcNHLFW7nSh_grCw4zcsp2iUGW876L9teTiarw@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
 <CALjNAZ318=UcFcNHLFW7nSh_grCw4zcsp2iUGW876L9teTiarw@mail.gmail.com>
Message-ID: <39a45185-373d-096d-7e48-28778d11560a@gmail.com>

On 4/11/2019 9:39 PM, Lingxian Kong wrote:
> In the current situation, i prefer to follow the ways that people who 
> care about the project(I mean, Trove) and are willing to offer help to 
> fix things should have the permission to merge patches to stable. So, 
> according to 
> https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html#deprecation, 
> as Trove PTL of Train dev cycle, can I ask to 
> remove stable:follows-policy tag for Trove?

It would probably be best if you propose a change to the governance repo 
to remove the tag from the trove project.

-- 

Thanks,

Matt


From hoanq13 at viettel.com.vn  Thu Apr 11 09:04:14 2019
From: hoanq13 at viettel.com.vn (hoanq13 at viettel.com.vn)
Date: Thu, 11 Apr 2019 16:04:14 +0700 (ICT)
Subject: [Vitrage] Find solution on integrate vitrage to current monitor
In-Reply-To: <CALxdkcxJnCsOom_=E8RdEbcKMewGC69ueUHThw4Ho6+cBhb2PQ@mail.gmail.com>
References: <1135240140.823214.1554345841979.JavaMail.zimbra@viettel.com.vn>
 <1923699737.906723.1554346789954.JavaMail.zimbra@viettel.com.vn>
 <CALxdkcxJnCsOom_=E8RdEbcKMewGC69ueUHThw4Ho6+cBhb2PQ@mail.gmail.com>
Message-ID: <1035681035.2586188.1554973454213.JavaMail.zimbra@viettel.com.vn>

Hi, 
Now I try write new datasource kapacitor to vitrage, storyboard : https://storyboard.openstack.org/#!/story/2005428 
I will greatly appreciate with your help. 


----- Original Message -----

From: ifatafekn at gmail.com 
To: hoanq13 at viettel.com.vn, openstack-discuss at lists.openstack.org 
Sent: Monday, April 8, 2019 5:54:30 PM 
Subject: Re: [Vitrage] Find solution on integrate vitrage to current monitor 

Hi, 

If I understand correctly, InfluxDB is used for storing metrics, but it does not handle the logic of when to raise an alarm, so integrating with it will not help you. I'm not familiar with any tool that "converts" InfluxDB metrics to alarms that are sent to Vitrage. 

I think that the only way to integrate your alarms is to write a new datasource for Kapacitor, since this specific monitor is not supported yet in Vitrage. You can find details on how to write a new datasource here [1]. 

[1] https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html 

Best regards, 
Ifat 

On Thu, Apr 4, 2019 at 6:00 AM < hoanq13 at viettel.com.vn > wrote: 



Hi, 

I sent this mail for finding solution when integrate vitrage to my current monitor system. 
I my system we use Tick stack monitor: with telegraf is collector metric, influxdb for storing metric, and kapacitor for alarming. 
It been work for a long while, all our monitor data in influxdb. I'm wondering have any tool can read influxdb, create alarm so vitrage can get input alarm from it?. 
Or any ideal you can recommend me on integrate vitrage to my system? 

p/s: i was think about write datasource driver kapacitor can alarm vitrage, but it take time, and I'm not good at codding. 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/303175da/attachment-0001.html>

From aspiers at suse.com  Thu Apr 11 12:26:33 2019
From: aspiers at suse.com (Adam Spiers)
Date: Thu, 11 Apr 2019 13:26:33 +0100
Subject: [OpenStack-sigs][self-healing] help most needed for SIGs and WGs
In-Reply-To: <CA+WCyyoeiYhmL9rtvbn43nakO-dsQyTZa=PUw8YJh2RjNB+0zg@mail.gmail.com>
References: <CA+WCyyoeiYhmL9rtvbn43nakO-dsQyTZa=PUw8YJh2RjNB+0zg@mail.gmail.com>
Message-ID: <20190411122633.z3xvr6zzrh3yszpi@pacific.linksys.moosehall>

Rico Lin <rico.lin.guanyu at gmail.com> wrote: 
>Dear all SIG and WG members 
>
>I would like to ask for three favors from each group. Thank you for your 
>kindly help. 
>
>tl;dr:
>    1. As an action from [3], we will have a forum `Help most needed for 
>SIGs and WGs` [4]. And would like to ask each group kindly provide me the 
>following help most needed information, including 
>
>   - What's your team's name 

Self-healing SIG 

>   - Who's leading or active in this team 

Me and Eric Kao 

>   - What's this team recently plan or doing 

All actions are in StoryBoard: 

https://storyboard.openstack.org/#!/project/openstack/self-healing-sig 

>   - How people can join this team? 

 0. Read https://wiki.openstack.org/wiki/Self-healing_SIG

 1. Join discussions on ML / #openstack-self-healing IRC (especially
    the meetings) and at f2f events

 2. Start contributing to the StoryBoard

>   - What's your most needed help interns of actions or technical features? 

I would say https://storyboard.openstack.org/#!/story/2001439 (health 
check APIs) is in the most urgent need of help (it was already 
supposed to be a community goal for Train but we ran out of time), 
followed by 

  - Converging solutions for compute plane HA
    https://storyboard.openstack.org/#!/story/2002124

  - automated testing for HA / self-healing (BIG project)
    https://storyboard.openstack.org/#!/story/2002129


From hongbin034 at gmail.com  Fri Apr 12 02:11:23 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Thu, 11 Apr 2019 22:11:23 -0400
Subject: [Zun] Heat and Horizon Support
In-Reply-To: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+Q20BYJJNAsYbaVytWmO1xNZ+xujN0NYfjB-1HPcuDKkQ@mail.gmail.com>

Hi Navdeep,

Unfortunately, I am not quite familiar with UI. I asked our UI developer
and below is his response:

"Horizon seems to fail in rebuilding style sheet, or to fail in reloading
it from his browser.
As described in the install documentation, restarting Horizon is needed.
AFAIK, Horizon's starting script rebuilds style sheet including plugin's.
Also, reloading forcely from browser using Ctrl+F5 might help to resolve
the problem."

Hope it helps.

Best regards,
Hongbin

On Wed, Apr 10, 2019 at 1:18 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Dear All,
>
> I would like to integrate my Zun deployment (OS Rocky) with Heat and
> Horizon.
> For horizon, I used the instructions given in
> https://docs.openstack.org/zun-ui/rocky/install/index.html
>
> However, while adding the files to
> */usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>
> Using : *cp zun_ui/enabled/*
> /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>
>
>
> My openstack UI is breaking down :
>
>
>
> Please advise.
>
>
>
> Kind Regards,
>
> Navdeep
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/313cd7a3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 56313 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/313cd7a3/attachment-0001.jpg>

From aaronzhu1121 at gmail.com  Fri Apr 12 03:34:55 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Fri, 12 Apr 2019 11:34:55 +0800
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
 <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>
 <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>
Message-ID: <CAN2nDNvU7Tfdfs9QVBbXaH+-dn+htohDa7kh3gxz=-XbVh4-Ag@mail.gmail.com>

Telemetry:
ptl:
name: Trinh Nguyen
irc: dangtrinhnt
email: dangtrinhnt at gmail.com
appointed:
- train
irc-channel: openstack-telemetry
service: Telemetry service
mission: >
To reliably collect measurements of the utilization of the physical and
virtual resources comprising deployed clouds, persist these data for
subsequent retrieval and analysis, and trigger actions when defined
criteria are met.
url: https://wiki.openstack.org/wiki/Telemetry
deliverables:
aodh:
repos:
- openstack/aodh
tags:
- assert:follows-standard-deprecation
ceilometer:
repos:
- openstack/ceilometer
tags:
- assert:follows-standard-deprecation
- assert:supports-upgrade
- tc:approved-release
telemetry-specs:
release-management: none
repos:
- openstack/telemetry-specs
ceilometermiddleware:
repos:
- openstack/ceilometermiddleware
panko:
repos:
- openstack/panko
tags:
- assert:follows-standard-deprecation
python-aodhclient:
repos:
- openstack/python-aodhclient
python-pankoclient:
repos:
- openstack/python-pankoclient
telemetry-tempest-plugin:
repos:
- openstack/telemetry-tempest-plugin


Check from governance ceilometermiddleware is belongs to Telemetry team.

Regards,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月12日 周五11:17写道：

> Hi Andreas,
>
> Just one question, is openstack/ceilometermiddleware project belongs to
> the Telemetry team? If that is the case, please add me to the team.
>
> Thank you,
>
> On Wed, Apr 10, 2019 at 4:50 PM Andreas Jaeger <aj at suse.com> wrote:
>
>> On 10/04/2019 08.50, Trinh Nguyen wrote:
>> > Hi Jens,
>> >
>> > I just see I'm not in the list of these following groups on gerrit:
>> >
>> > ceilometer-release
>> > aodh-release
>> > panko-release
>> >
>> > Could you please add me to those as well?
>>
>> You don't need to be - releases are done via the releases repo.
>>
>> Those groups are completely unused currently,
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> <https://maps.google.com/?q=Maxfeldstr.+5,+90409+N%C3%BCrnberg,+Germany&entry=gmail&source=g>
>>    GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
>>        HRB 21284 (AG Nürnberg)
>>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/fd390ea7/attachment-0001.html>

From navdeep.uniyal at bristol.ac.uk  Fri Apr 12 11:02:34 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Fri, 12 Apr 2019 11:02:34 +0000
Subject: [Zun] Heat and Horizon Support
In-Reply-To: <CAFNUc+Q20BYJJNAsYbaVytWmO1xNZ+xujN0NYfjB-1HPcuDKkQ@mail.gmail.com>
References: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Q20BYJJNAsYbaVytWmO1xNZ+xujN0NYfjB-1HPcuDKkQ@mail.gmail.com>
Message-ID: <AM6PR06MB58790EA27AA1C783ACA34A04DE280@AM6PR06MB5879.eurprd06.prod.outlook.com>

Hi Hongbin,

Thank you very much again for your response and help.
I could resolve the issue with the following commands as suggested by Ivan:

cd  <path to your horizon>/
python manage.py collectstatic && python manage.py compress

Thank you again for your help.

Kind Regards,
Navdeep

From: Hongbin Lu <hongbin034 at gmail.com>
Sent: 12 April 2019 03:11
To: Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [Zun] Heat and Horizon Support

Hi Navdeep,

Unfortunately, I am not quite familiar with UI. I asked our UI developer and below is his response:

"Horizon seems to fail in rebuilding style sheet, or to fail in reloading it from his browser.
As described in the install documentation, restarting Horizon is needed. AFAIK, Horizon's starting script rebuilds style sheet including plugin's. Also, reloading forcely from browser using Ctrl+F5 might help to resolve the problem."

Hope it helps.

Best regards,
Hongbin

On Wed, Apr 10, 2019 at 1:18 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk<mailto:navdeep.uniyal at bristol.ac.uk>> wrote:
Dear All,

I would like to integrate my Zun deployment (OS Rocky) with Heat and Horizon.
For horizon, I used the instructions given in https://docs.openstack.org/zun-ui/rocky/install/index.html

However, while adding the files to /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled
Using : cp zun_ui/enabled/* /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled

My openstack UI is breaking down :
[cid:image001.jpg at 01D4F127.9BE76A00]

Please advise.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/8dc3a6ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 55995 bytes
Desc: image001.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/8dc3a6ef/attachment-0001.jpg>

From e0ne at e0ne.info  Fri Apr 12 11:55:59 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Fri, 12 Apr 2019 14:55:59 +0300
Subject: [Zun] Heat and Horizon Support
In-Reply-To: <AM6PR06MB58790EA27AA1C783ACA34A04DE280@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Q20BYJJNAsYbaVytWmO1xNZ+xujN0NYfjB-1HPcuDKkQ@mail.gmail.com>
 <AM6PR06MB58790EA27AA1C783ACA34A04DE280@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAGocpaEfiYjBfJvKdj50qk9TWD8H9bz-GwuqabFbdog0PYK=tQ@mail.gmail.com>

I created a patch [1] to fix this issue in the documentation.

[1] https://review.openstack.org/652047

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


On Fri, Apr 12, 2019 at 2:02 PM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Hi Hongbin,
>
> Thank you very much again for your response and help.
> I could resolve the issue with the following commands as suggested by Ivan:
>
> cd  <path to your horizon>/
>
> python manage.py collectstatic && python manage.py compress
>
>
>
> Thank you again for your help.
>
> Kind Regards,
> Navdeep
>
>
>
> *From:* Hongbin Lu <hongbin034 at gmail.com>
> *Sent:* 12 April 2019 03:11
> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
> *Cc:* openstack-discuss at lists.openstack.org
> *Subject:* Re: [Zun] Heat and Horizon Support
>
>
>
> Hi Navdeep,
>
>
>
> Unfortunately, I am not quite familiar with UI. I asked our UI developer
> and below is his response:
>
>
>
> "Horizon seems to fail in rebuilding style sheet, or to fail in reloading
> it from his browser.
>
> As described in the install documentation, restarting Horizon is needed.
> AFAIK, Horizon's starting script rebuilds style sheet including plugin's.
> Also, reloading forcely from browser using Ctrl+F5 might help to resolve
> the problem."
>
>
>
> Hope it helps.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> On Wed, Apr 10, 2019 at 1:18 PM Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
> Dear All,
>
> I would like to integrate my Zun deployment (OS Rocky) with Heat and
> Horizon.
> For horizon, I used the instructions given in
> https://docs.openstack.org/zun-ui/rocky/install/index.html
>
> However, while adding the files to
> */usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>
> Using : *cp zun_ui/enabled/*
> /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>
>
>
> My openstack UI is breaking down :
>
>
>
> Please advise.
>
>
>
> Kind Regards,
>
> Navdeep
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/2ee3d67f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 55995 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/2ee3d67f/attachment-0001.jpg>

From openstack at fried.cc  Fri Apr 12 13:21:33 2019
From: openstack at fried.cc (Eric Fried)
Date: Fri, 12 Apr 2019 08:21:33 -0500
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
Message-ID: <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>


> Well, there's still the small matter of where to include the Venn diagram.  As I wrote in a previous email (which you may have not seen; for some reason it didn't show up in the list archives yet),

Hm, no, didn't show up in my inbox either.

> the idea of putting it at the bottom of 
>   https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits
> 
> was already rejected, otherwise it would have been there already: 
>   https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523

Oh, I see. I get Matt's point, though I'm not sure I agree. I suppose the diagram is most useful for developers rather than admins. If there's a way we can put it somewhere permanent (that doesn't have ads) we could link it from code comments? Or find the spec that talks about this and link it from there?


E


From aditi.s at india.nec.com  Fri Apr 12 13:51:02 2019
From: aditi.s at india.nec.com (Aditi Sharma)
Date: Fri, 12 Apr 2019 13:51:02 +0000
Subject: [Watcher] Proposing chenker and Dantalion for core
In-Reply-To: <8FC2060F93794D44942D588B8B547287123F4E44@BPXM03GP.gisp.nec.co.jp>
References: <201904101718043731546@zte.com.cn>,
 <8FC2060F93794D44942D588B8B547287123F4E44@BPXM03GP.gisp.nec.co.jp>
Message-ID: <TY2PR01MB4857ECBE21733E7E285D0554B4280@TY2PR01MB4857.jpnprd01.prod.outlook.com>

+1 from me!!!!


Thanks and Regards,
Aditi

________________________________________
From: Hidekazu Nakamura <hid-nakamura at vf.jp.nec.com>
Sent: Friday, April 12, 2019 1:30:15 PM
To: li.canwei2 at zte.com.cn; openstack-discuss at lists.openstack.org
Cc: Keiichi Seki
Subject: RE: [Watcher] Proposing chenker and Dantalion for core

+1

I know Watcher project needs more active core reviewers and they contributed actively in the last six months.
I hope they will review code with better quality in the Train cycle.

Thanks,
Hidekazu Nakamura


From: li.canwei2 at zte.com.cn <li.canwei2 at zte.com.cn>
Sent: Wednesday, April 10, 2019 6:18 PM
To: openstack-discuss at lists.openstack.org
Subject: [Watcher] Proposing chenker and Dantalion for core


Hi,

Now Watcher need more active core reviewers, I'd like to propose adding chenker and Dantalion to core team.

They all did a great contribution during the last six months [1].



[1]: https://www.stackalytics.com/report/contribution/watcher-group/90



Thanks!

Canwei Li

















From tpb at dyncloud.net  Fri Apr 12 13:52:35 2019
From: tpb at dyncloud.net (Tom Barron)
Date: Fri, 12 Apr 2019 09:52:35 -0400
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190412024708.GR7047@thor.bakeyournoodle.com>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <20190412024708.GR7047@thor.bakeyournoodle.com>
Message-ID: <20190412135235.p3mwetqcja3afxsi@barron.net>

On 12/04/19 12:47 +1000, Tony Breeds wrote:
>On Wed, Mar 27, 2019 at 08:56:54AM -0400, Tom Barron wrote:
>> In manila we recently merged backports of a change [1] that aims
>> to fix up faulty configuration option deprecations in the
>> Dell-EMC VMAX driver.  The question at hand is whether (a) we
>> should revert these backports on the grounds that the
>> deprecations were faulty and therefore are only effective from
>> Stein forwards, or whether (b) the deprecations actually worked
>> and took effect back when Ocata was the development branch but
>> had faults that should be corrected all the way back to Pike
>> before it goes EM.
>
>Thanks for writing this all up Tom.  I'm sorry it's taken me so long to
>get to it.
>
>> I think (b) is the correct answer but let's check.
>>
>> On Jan 10 2017 a review [2] merged that deprecated generic
>> Dell-EMC driver options in favor of model-specific options [2].
>> There were two models at the time, Unity and VNX.  This change
>> was in itself unproblematic.
>>
>> On Jan 24 2017 a review [3] merged that introduced a third
>> Dell-EMC model, VMAX.  This new code introduced VMAX specific
>> options, consistent with the deprecation of the generic Dell-EMC
>> options.  However it had two problems which review [1] corrects.
>> When it defined the new VMAX-specific options it failed to
>> indicate the corresponding old generic options via
>> 'deprecated_name' [4].  Worse, the code that consumed the options
>> actually looked for the old generic 'emc_interface_ports' option
>> instead of the new 'vmax_ethernet_ports' option.  The only way to
>> set a value for this option was to use its deprecated
>> form.
>
>So someone that is using the VMAX driver from 5.0.3 has set
>emc_interface_ports in the config.  Assuming we don't revert and release
>5.0.4[1], that same config file will continue to work but there will now be
>a deprecation warning in the logs.
>
>The VMAX user probably had to look at the code to workout that the
>config sample was out of sync with the code?

Right, or some support person told them some magic.

>
>Yours Tony.
>
>[1] or probably 5.1.0 as a signal to operators

Agree that 5.1.0 makes sense, thanks.



From smooney at redhat.com  Fri Apr 12 13:54:46 2019
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 12 Apr 2019 14:54:46 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
Message-ID: <b9c30e65dfb45c3b0b330a8f06f407e67a54d802.camel@redhat.com>

On Fri, 2019-04-12 at 13:57 +0100, Adam Spiers wrote:
> Chris Dent <cdent+os at anticdent.org> wrote: 
> > On Thu, 11 Apr 2019, Adam Spiers wrote: 
> > 
> > > Ed Leafe <ed at leafe.com> wrote: 
> > > > The concept of “owning” particular traits isn’t in Placement. 
> > > > Rather, it is in the domain of the service that is using 
> > > > Placement. So any enforcement regarding which traits are 
> > > > acceptable has to be on the calling end, not in the Placement API. 
> > > 
> > > That feels like a slight jump in logic to me: the API can enforce 
> > > ownership without being the authoritative source of truth for that 
> > > ownership.  For example, as I just suggested elsewhere in this 
> > > thread, (static) ownership of driver-provided traits could be 
> > > tracked in os_traits.  Maybe that's a dumb idea; I'm not sure. 
> > 
> > It's not a dumb idea, but it's not really an idea we want to pursue. 
> > We've made an effort to keep both os-traits and os-resource-classes 
> > as dumb and "symbol only" as possible, minimizing code and metadata. 
> > Indicating ownership would require metadata. 
> 
> I was thinking of something like 
> 
>     DRIVER_TRAITS = [
>         ot.COMPUTE_FOO,
>         ot.COMPUTE_BAR,
>         ...
>     ]
a simple list like this seams resonable to me but im not conviced this
shoudl live in os-traits. this set would vary per driver.
the virdrivers dont just set traits that are  confied to the COMPUTE_ prefix 
and i dont think the drivers should own everything in the  hardware namespace.
https://github.com/openstack/os-traits/tree/master/os_traits/hw

> 
> which seems to me more like data than metadata, and would presumably 
> meet the requirement to be dumb and "symbol only". 
> 
> In fact, even without that we could just test for the COMPUTE_ prefix 
> and that would cover all but one segment of the Venn diagram 
so to not shoot ourselves in the foot in the future im not sure we want
to assume that everything under the compute namespace would never be added
by and by an operator.

but on the other had looking at the traits in https://github.com/openstack/os-traits/tree/master/os_traits/compute
i think all the current ones are things that likely only the virt driver would set.

if we want to enforce that restion it would be betteer to start now before we add somethign
that could be reused for a differnt usecase.
>     https://pasteboard.co/I3iqqNm.jpg
> 
> i.e. the "Should be unset if set by admin (but we're not there yet)" 
> bit.
> 
> > Enforcing it would require some form of code. 
> 
> Sure.  I don't understand the policy code yet, but at a wild guess it 
> would need separate policies for human admins vs. nova. 
> 
> > > Having said that ... 
> > > > So yeah, “do nothing”. 
> > > 
> > > I'm totally fine with this too ;-)  I only raised it because when I 
> > > was developing the driver-owned capability traits code, people 
> > > seemed somewhat concerned with the possibility of admins screwing 
> > > things up. If the concern is minimal then I'm certainly not 
> > > religious about adding extra safeguards. 
> > 
> > Seeing as there's no huge drive for action on this topic, I've 
> > marked this topic as decided ("do nothing") on the etherpad [1] and 
> > we can ignore this thread henceforth. 
> 
> Well, there's still the small matter of where to include the Venn 
> diagram.  As I wrote in a previous email (which you may have not seen; 
> for some reason it didn't show up in the list archives yet), the idea 
> of putting it at the bottom of 
> 
>     https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits
> 
> was already rejected, otherwise it would have been there already: 
> 
>     https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523
> 
> But other than that, I'm fine with "do nothing". 
> 



From tpb at dyncloud.net  Fri Apr 12 14:02:32 2019
From: tpb at dyncloud.net (Tom Barron)
Date: Fri, 12 Apr 2019 10:02:32 -0400
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190412025036.GS7047@thor.bakeyournoodle.com>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <CAKSuTPZceozexAtuJtuKH=z4SUkK00n37H_=oniJ1wpWh+18Og@mail.gmail.com>
 <20190330204021.leizflkinun32bwy@barron.net>
 <CAKSuTPYLgMTAaVjeD7bvRyoOuuY4hAqbqFg7LjQ6qSS+iXptWw@mail.gmail.com>
 <20190401103544.ew26pngy2xaba62h@barron.net>
 <20190412025036.GS7047@thor.bakeyournoodle.com>
Message-ID: <20190412140232.4rt2t5skhqbhbdfb@barron.net>

On 12/04/19 12:50 +1000, Tony Breeds wrote:
>On Mon, Apr 01, 2019 at 06:35:44AM -0400, Tom Barron wrote:
>
>> At the risk of stating the obvious, but for the record, this backport
>> doesn't change *when* these deprecations occurred for VMAX.  They occurred
>> in Stein development cycle, not during the Ocata development cycle, and the
>> earliest the deprecated options could be removed is Train.
>
>That brings up an interesting point and one which is largely tangental
>to the stable backport issue but AFAICT the 'deprecated' names are still
>called out as the correct way to configure the driver.  At least in the
>case of the Unity diver:
>
>https://docs.openstack.org/manila/latest/admin/emc_unity_driver.html#configurations
>
>That could be fixed and backported to stein.  I sort of think that sets
>the timer to 'U' but that certainly isn't supported by our policy and is
>a project team decision.
>
>Yours Tony.

Thanks for this catch, Tony. Helen, you've been making a few EMC 
driver documentation fixes recently, so would you be so kind as to 
submit a review for this one as well?  Also, is there any problem 
setting the timer for removal to 'U' instead of Train as Tony suggests?

Thanks,

-- Tom



From jim at jimrollenhagen.com  Fri Apr 12 14:04:00 2019
From: jim at jimrollenhagen.com (Jim Rollenhagen)
Date: Fri, 12 Apr 2019 10:04:00 -0400
Subject: [all][tc] Repository renames during OpenDev migration
In-Reply-To: <1555057759.4997.31.camel@offenerstapel.de>
References: <CAJCXu8d90W=BYNH2f=KOmFu=qzMGyEZNuEBj-Wj-Ks8A-K9vwA@mail.gmail.com>
 <1555057759.4997.31.camel@offenerstapel.de>
Message-ID: <CAJCXu8ckKrvQPwKwzvdS2CsWL0Ux3C41F_YzV_HRaRDGPPg1Dw@mail.gmail.com>

On Fri, Apr 12, 2019 at 4:30 AM Jens Harbott <frickler at offenerstapel.de>
wrote:

> On Wed, 2019-04-10 at 16:34 -0400, Jim Rollenhagen wrote:
> ...
> > Here's how a repository's new namespace will be decided, as it stands
> > today:
> >
> > - is the repo listed in projects.yaml[2]? If so, "openstack".
> > - is the repo listed in legacy.yaml[3]? If so, "openstack".
> > - is the repo listed in foundation-board-repos.yaml[4]? If so,
> > "openstack".
> > - is the repo listed in sigs-repos.yaml[5]? If so, "openstack".
> > - is the repo listed in technical-committee-repos.yaml[6]? If so,
> > "openstack".
> > - is the repo listed in user-committee-repos.yaml[7]? If so,
> > "openstack".
>
> Is there a script already in place to generate the list of repos that
> will land in "openstack" under the previous rules? I think it would be
> helpful to have that list published somewhere, possibly in combination
> with the list of repos that don't match, so that interested people can
> easily check the status of a repo they are interested in.
>

That's something fungi is taking on. We'll definitely make sure
it gets published. :)

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/df9b14b5/attachment-0001.html>

From sean.mcginnis at gmx.com  Fri Apr 12 14:27:35 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 12 Apr 2019 09:27:35 -0500
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
 <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
Message-ID: <20190412142734.GA3579@sm-workstation>

On Fri, Apr 12, 2019 at 09:00:31AM +0200, Thomas Goirand wrote:
> On 4/12/19 1:28 AM, Jeremy Stanley wrote:
> > On 2019-04-12 00:40:03 +0200 (+0200), Thomas Goirand wrote:
> >> In such case, you know your cloud provider hasn't modified the
> >> official Debian image.
> >
> > Well, last I checked, Nova doesn't *actually* verify those
> > checksums, and even if it did the software could still be adjusted
> > by a malicious operator anyway.
>
> Oh, what do you mean? I thought it had an option for that...
>
> Cheers,
>
> Thomas Goirand (zigo)
>

Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0].
Though Cinder did not get the same enforcement until Rocky [1].

[0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
[1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image-signature-verification.html

(And specs are always 100% accurate, right?)


From mordred at inaugust.com  Fri Apr 12 14:34:08 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Fri, 12 Apr 2019 14:34:08 +0000
Subject: [osprofiler] Distributed tracing in OpenStack
In-Reply-To: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
References: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
Message-ID: <f8dc90f2-a9c2-420a-1260-939708b694d2@inaugust.com>



On 4/11/19 9:42 PM, Ilya Shakhat wrote:
> Hi,
> 
> Distributed tracing is one of must-have features when one wants to track 
> the full path of request going through different services and APIs. This 
> makes it similar to shared request-id, but with nice visualization at 
> the end [1]. In OpenStack the tracing can be achieved via osprofiler 
> library. The library was introduced 5 years ago, and back then there was 
> no standard approach on how to do tracing and that's why it stays aside 
> from what has become a mainstream. Yet there is no single standard, but 
> the major players are OpenTracing and OpenCensus communities. 
> OpenTracing is represented by Uber's Jaeger which is the default tracer 
> from k8s world.
> 
> Issues and limitations to be fixed:
> 1. Compatibility. While osprofiler library supports many different 
> storage drivers, it has only one way of transferring trace context over 
> the wire. Ideally the library should be compatible with other 
> third-party tracers and allow traces to start in front of OpenStack APIs 
> (e.g. in user apps) and continue after (e.g. in storage systems, or 
> network management tools). [2]
> 2. Operation mode. With osprofiler tracing is initiated by user request, 
> while in industrial solutions the tracing can be managed centrally via 
> dynamic sampling policies.
> 3. In-process trace propagation. Depending on execution model (threaded, 
> async) the ways of storing current trace context differ. OSProfiler 
> supports thread-local model, which recently got broken with new async 
> implementation in openstacksdk [3].

FWIW - we should have re-fixed that issue in SDK for all instances other 
than parallel uploading of Large Objects segments to swift. The 
parallism support now relies on the calling context's parallism. The 
large-object segment uploader is a thing we should make sure we do 
things with to make sure we're not losing those interactions.

That said - if we move forward with this plan - let's be sure to make 
sure it works in openstacksdk - and that we're testing it so that we 
don't break it.

> With OpenTracing it is possible to 
> select the appropriate model alongside with tracer configuration.
> 
> What's the plan:
> Switching to OpenTracing could be a good option to gain compatibility 
> with 3rd-party solutions. The actual change should go to osprofiler 
> library, but indirectly affects all OpenStack projects (should it be a 
> global team goal then?). I'm going to make a PoC of proposed change, so 
> reviews would be highly appreciated.
> 
> Comments, suggestions?

Generally supportive. I have specific impl feedbacks - but I'll leave 
those on the patches.

> Thanks,
> Ilya
> 
> [1] e.g. 
> http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-redis/7c6c14e/osprofiler-traces/trace-3e5cc660-8815-4079-86b9-778af8469d79.html.gz
> [2] https://bugs.launchpad.net/osprofiler/+bug/1798565
> [3] https://bugs.launchpad.net/osprofiler/+bug/1818493


From mordred at inaugust.com  Fri Apr 12 14:48:55 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Fri, 12 Apr 2019 14:48:55 +0000
Subject: [osprofiler] Distributed tracing in OpenStack
In-Reply-To: <f8dc90f2-a9c2-420a-1260-939708b694d2@inaugust.com>
References: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
 <f8dc90f2-a9c2-420a-1260-939708b694d2@inaugust.com>
Message-ID: <19d1c3ef-06b4-f4b8-6d83-d46a4f0185c1@inaugust.com>



On 4/12/19 2:34 PM, Monty Taylor wrote:
> 
> 
> On 4/11/19 9:42 PM, Ilya Shakhat wrote:
>> Hi,
>>
>> Distributed tracing is one of must-have features when one wants to 
>> track the full path of request going through different services and 
>> APIs. This makes it similar to shared request-id, but with nice 
>> visualization at the end [1]. In OpenStack the tracing can be achieved 
>> via osprofiler library. The library was introduced 5 years ago, and 
>> back then there was no standard approach on how to do tracing and 
>> that's why it stays aside from what has become a mainstream. Yet there 
>> is no single standard, but the major players are OpenTracing and 
>> OpenCensus communities. OpenTracing is represented by Uber's Jaeger 
>> which is the default tracer from k8s world.
>>
>> Issues and limitations to be fixed:
>> 1. Compatibility. While osprofiler library supports many different 
>> storage drivers, it has only one way of transferring trace context 
>> over the wire. Ideally the library should be compatible with other 
>> third-party tracers and allow traces to start in front of OpenStack 
>> APIs (e.g. in user apps) and continue after (e.g. in storage systems, 
>> or network management tools). [2]
>> 2. Operation mode. With osprofiler tracing is initiated by user 
>> request, while in industrial solutions the tracing can be managed 
>> centrally via dynamic sampling policies.
>> 3. In-process trace propagation. Depending on execution model 
>> (threaded, async) the ways of storing current trace context differ. 
>> OSProfiler supports thread-local model, which recently got broken with 
>> new async implementation in openstacksdk [3].
> 
> FWIW - we should have re-fixed that issue in SDK for all instances other 
> than parallel uploading of Large Objects segments to swift. The 
> parallism support now relies on the calling context's parallism. The 
> large-object segment uploader is a thing we should make sure we do 
> things with to make sure we're not losing those interactions.
> 
> That said - if we move forward with this plan - let's be sure to make 
> sure it works in openstacksdk - and that we're testing it so that we 
> don't break it.

Do we need to wrap logical operations that may make more than one remote 
call in a single span?

I ask because in the cloud layer of openstacksdk, there are methods, 
like "create_image" or "get_server" which can wind up making multiple 
calls to multiple services, but it's a single logical operation to the 
user. I don't know enough about the opentracing best practices - do we 
care about such aggregations? Or is simply wrapping the http call at the 
ksa layer enough?

>> With OpenTracing it is possible to select the appropriate model 
>> alongside with tracer configuration.
>>
>> What's the plan:
>> Switching to OpenTracing could be a good option to gain compatibility 
>> with 3rd-party solutions. The actual change should go to osprofiler 
>> library, but indirectly affects all OpenStack projects (should it be a 
>> global team goal then?). I'm going to make a PoC of proposed change, 
>> so reviews would be highly appreciated.
>>
>> Comments, suggestions?
> 
> Generally supportive. I have specific impl feedbacks - but I'll leave 
> those on the patches.
> 
>> Thanks,
>> Ilya
>>
>> [1] e.g. 
>> http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-redis/7c6c14e/osprofiler-traces/trace-3e5cc660-8815-4079-86b9-778af8469d79.html.gz 
>>
>> [2] https://bugs.launchpad.net/osprofiler/+bug/1798565
>> [3] https://bugs.launchpad.net/osprofiler/+bug/1818493
> 
> 


From gmann at ghanshyammann.com  Fri Apr 12 14:50:59 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 12 Apr 2019 09:50:59 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ3_jGSJ+GkeX8ZjNad2MneNRAwFO5hBq1GDQCn3TNp4Xg@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <9845CB2C-83D6-47C0-8DE4-1548272AAEB0@vexxhost.com>
 <20190412015507.GO7047@thor.bakeyournoodle.com>
 <CALjNAZ3_jGSJ+GkeX8ZjNad2MneNRAwFO5hBq1GDQCn3TNp4Xg@mail.gmail.com>
Message-ID: <16a1207c0dc.b067aec4294238.4793669574226186904@ghanshyammann.com>

 ---- On Thu, 11 Apr 2019 21:14:40 -0500 Lingxian Kong <anlin.kong at gmail.com> wrote ----
 > On Fri, Apr 12, 2019 at 1:55 PM Tony Breeds <tony at bakeyournoodle.com> wrote:
 > On Thu, Apr 11, 2019 at 08:00:16PM -0400, Mohammed Naser wrote:
 >  
 > > Should we perhaps look into the possibility of removing Trove from
 > > following stable policy by any chance?
 >  
 > The change in question was published and merged by a single person in 3
 > days on master.  It isn't a stable policy/tag thing.
 > 
 > So, how long do you think it's appropriate for the person who is mostly the only one cares about the improvement before merging the patch by himself? 

I think this is ok on master changes, there are lot of projects which has self approve culter due to no other core Active. Trove is lacking in term of active or Core members and Lingxian is trying his best to fill that gap. So IMO, doing self approve on the master is all ok as per current situation. 

-gmann



From mnaser at vexxhost.com  Fri Apr 12 14:56:17 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Fri, 12 Apr 2019 10:56:17 -0400
Subject: [chef] Renaming the Chef OpenStack project
In-Reply-To: <1554724565.4997.26.camel@offenerstapel.de>
References: <1554724565.4997.26.camel@offenerstapel.de>
Message-ID: <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>

On Mon, Apr 8, 2019 at 7:58 AM Jens Harbott <frickler at offenerstapel.de> wrote:
>
> In order to clean up some inconsistencies in project naming I have
> submitted a request to the TC to update the name of the Chef OpenStack
> project to "openstack-chef"[0]. The reasoning for this is twofold:
>
>     a) It brings the name into line with other deployment projects
>        like "OpenStack Ansible" and "OpenStack Charms".
>     b) In addition there are sometimes drawbacks when there is an
>        embedded space in the name, so I opted for the hyphenated
>        version. Together with lowercasing everything this also has the
>        effect to match:
>             - The name of our central repository
>             - The name of our IRC channel
>             - Our project name on Launchpad
>
> Please let me know whether you agree with this change or if there are
> any objections.

I don't think I have too much of a problem with it but I can think of
a few consumers
who might want to mention if they're broken which are

- openstack-map / OSF website
- release team
- stackalytics(?)

I haven't dug into the history if we've ever done a similar rename,
but perhaps one
of our OpenStack historians can point to commits in the past where
we've done the
same and how it was dealt with in other places.

> [0] https://review.openstack.org/648356



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From gmann at ghanshyammann.com  Fri Apr 12 14:57:49 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 12 Apr 2019 09:57:49 -0500
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <CALjNAZ318=UcFcNHLFW7nSh_grCw4zcsp2iUGW876L9teTiarw@mail.gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
 <CALjNAZ318=UcFcNHLFW7nSh_grCw4zcsp2iUGW876L9teTiarw@mail.gmail.com>
Message-ID: <16a120e0246.fd6e9b91294495.418984190748306312@ghanshyammann.com>

 ---- On Thu, 11 Apr 2019 21:39:45 -0500 Lingxian Kong <anlin.kong at gmail.com> wrote ----
 > On Fri, Apr 12, 2019 at 2:27 PM Matt Riedemann <mriedemos at gmail.com> wrote:
 > On 4/11/2019 3:47 PM, Lingxian Kong wrote:
 > > 
 > > I've already replied in the patch, since you also mentioned the patch 
 > > here, i think it's necessary also reply you here.
 > > 
 > > That patch failed to get attention from other team members and the 
 > > community who are not interested in such change, as the PTL, i have to 
 > > merge it myself to not block other patches. At the same time, some users 
 > > were complaining the current trove image build approach, which could be 
 > > improved with that patch.
 > > 
 > > If self-approved is something you disagree, I'd appreciate if you could 
 > > offer some help for the review.
 >  
 > I realize Trove is in a tough spot so I'm not trying to criticize and I 
 > understand the frustration of waiting to get something merged that you 
 > or your customers need. I don't have great answers for these problems. I 
 > was simply trying to highlight the fact that while that patch may be 
 > appropriate to merge on master it may not be appropriate to merge on 
 > stable, so there are different rules if you're following the stable 
 > policy and that's why cores on master aren't necessarily cores on stable 
 > branches.
 > 
 > Totally understand, thanks for the explanation. That's why I explained in the above email that it's not my original requirement to become a stale core, the first email was just a heading up to ask help for the stable branch review.
 >  
 > At the same time I'm coming from a place where we try to enforce some 
 > kind of standards across projects under openstack TC governance, and 
 > trove is in a tough spot there.
 >  
 > But as Mohammed pointed out, if Trove elects to *not* follow the stable 
 > policy then we simply have to remove the "stable:follows-policy" tag 
 > from governance and trove is free to backport as it pleases (I think? 
 > Tony can correct me).
 > 
 > In the current situation, i prefer to follow the ways that people who care about the project(I mean, Trove) and are willing to offer help to fix things should have the permission to merge patches to stable. So, according to https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html#deprecation, as Trove PTL of Train dev cycle, can I ask to remove stable:follows-policy tag for Trove?---Cheers,Lingxian KongCatalyst Cloud Team 

As Matt, Naser mentioned, you can do that anytime. But I am concerned that, adding the tag is always good but removing is definitely not. I want to understand, is this the only case based on which you are taking the decision to remove the  "stable:follows-policy" tag ? Or you think trove will have/need more cases like that?

-gmann




From aspiers at suse.com  Fri Apr 12 14:58:25 2019
From: aspiers at suse.com (Adam Spiers)
Date: Fri, 12 Apr 2019 15:58:25 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <790e77af-b5b3-7e45-5bdc-30adcdf61c7a@fried.cc>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <790e77af-b5b3-7e45-5bdc-30adcdf61c7a@fried.cc>
Message-ID: <20190412145825.syvcxc3yull22plk@pacific.linksys.moosehall>

[resend due to issues with our internal MTA]

Eric Fried <openstack at fried.cc> wrote: 
>>be worth considering tweaking the placement API so that only the driver 
>>can set/unset traits which it owns? 
>
>This would entail placement tracking some kind of "owner" attribute 
>(ahem, metadata) on traits. Or maintaining a list of driver-owned traits 
>per resource provider. Or <your idea here>. And then a way to establish 
>a different identity/policy for the virt driver than for the admin. And 
>then a way for the admin to override that anyway because stuff happens. 
>
>That ^, IMO, is the "more work than benefit" I led with. Happy to be 
>convinced otherwise if there's a (*much*) simpler way to achieve the 
>desired goal. 

Just thinking out aloud, but how about something as stupid as just 
maintaining that list of driver-owned traits in os_traits, and 
exposing a simple trait_is_driver_owned() function which returns a 
boolean?  Then the API implementation could simply check that and 
return 403 or whatever if the admin tries to mess with a driver-owned 
trait.

Although I'm assuming that there is already some mechanism in there 
for the API service to distinguish between admin callers and driver 
callers; if that assumption is wrong then maybe it would take too much 
more effort to add that. 

>>Although perhaps it would be better to at least spend 5 
>>minutes finding a good place in the docs to insert the Venn diagram: 
>>    https://pasteboard.co/I3iqqNm.jpg 
>
>Yes please. Bottom of [1] seems like the right place. 
>
>[1]
>https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits 

That idea was already rejected, otherwise it would be there already: 

https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523 

>But for heaven's sake, don't violate my privacy [2]. 
>
>[2]
>http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4651 

Sure, no need for that here ;-)  We can just add the raw .svg. 


From aspiers at suse.com  Fri Apr 12 15:01:25 2019
From: aspiers at suse.com (Adam Spiers)
Date: Fri, 12 Apr 2019 16:01:25 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
Message-ID: <20190412150125.oyn2p4sz3p2tjtek@pacific.linksys.moosehall>

[resend due to issues with our internal MTA]

Ed Leafe <ed at leafe.com> wrote: 
>The concept of “owning” particular traits isn’t in Placement. Rather, it is in the domain of the service that is using Placement. So any enforcement regarding which traits are acceptable has to be on the calling end, not in the Placement API. 

That feels like a slight jump in logic to me: the API can enforce 
ownership without being the authoritative source of truth for that 
ownership.  For example, as I just suggested elsewhere in this thread, 
(static) ownership of driver-provided traits could be tracked in 
os_traits.  Maybe that's a dumb idea; I'm not sure.

Having said that ... 

>So yeah, “do nothing”. 

I'm totally fine with this too ;-)  I only raised it because when I 
was developing the driver-owned capability traits code, people seemed 
somewhat concerned with the possibility of admins screwing things up. 
If the concern is minimal then I'm certainly not religious about adding 
extra safeguards. 


From skaplons at redhat.com  Fri Apr 12 15:46:05 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Fri, 12 Apr 2019 17:46:05 +0200
Subject: [osprofiler] Distributed tracing in OpenStack
In-Reply-To: <f8dc90f2-a9c2-420a-1260-939708b694d2@inaugust.com>
References: <CAE9wADwnPt5qcLx2Fvb6kicySqZFNq7DBSLdaxMxBVEdq9mG2w@mail.gmail.com>
 <f8dc90f2-a9c2-420a-1260-939708b694d2@inaugust.com>
Message-ID: <A2E9E42E-9019-4CC4-A2C7-7FA07D48CC3F@redhat.com>

Hi,

> Wiadomość napisana przez Monty Taylor <mordred at inaugust.com> w dniu 12.04.2019, o godz. 16:34:
> 
> 
> 
> On 4/11/19 9:42 PM, Ilya Shakhat wrote:
>> Hi,
>> Distributed tracing is one of must-have features when one wants to track the full path of request going through different services and APIs. This makes it similar to shared request-id, but with nice visualization at the end [1]. In OpenStack the tracing can be achieved via osprofiler library. The library was introduced 5 years ago, and back then there was no standard approach on how to do tracing and that's why it stays aside from what has become a mainstream. Yet there is no single standard, but the major players are OpenTracing and OpenCensus communities. OpenTracing is represented by Uber's Jaeger which is the default tracer from k8s world.
>> Issues and limitations to be fixed:
>> 1. Compatibility. While osprofiler library supports many different storage drivers, it has only one way of transferring trace context over the wire. Ideally the library should be compatible with other third-party tracers and allow traces to start in front of OpenStack APIs (e.g. in user apps) and continue after (e.g. in storage systems, or network management tools). [2]
>> 2. Operation mode. With osprofiler tracing is initiated by user request, while in industrial solutions the tracing can be managed centrally via dynamic sampling policies.
>> 3. In-process trace propagation. Depending on execution model (threaded, async) the ways of storing current trace context differ. OSProfiler supports thread-local model, which recently got broken with new async implementation in openstacksdk [3].
> 
> FWIW - we should have re-fixed that issue in SDK for all instances other than parallel uploading of Large Objects segments to swift. The parallism support now relies on the calling context's parallism. The large-object segment uploader is a thing we should make sure we do things with to make sure we're not losing those interactions.
> 
> That said - if we move forward with this plan - let's be sure to make sure it works in openstacksdk - and that we're testing it so that we don't break it.

There is even storyboard for that issue https://storyboard.openstack.org/#!/story/2004618

> 
>> With OpenTracing it is possible to select the appropriate model alongside with tracer configuration.
>> What's the plan:
>> Switching to OpenTracing could be a good option to gain compatibility with 3rd-party solutions. The actual change should go to osprofiler library, but indirectly affects all OpenStack projects (should it be a global team goal then?). I'm going to make a PoC of proposed change, so reviews would be highly appreciated.
>> Comments, suggestions?
> 
> Generally supportive. I have specific impl feedbacks - but I'll leave those on the patches.
> 
>> Thanks,
>> Ilya
>> [1] e.g. http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-redis/7c6c14e/osprofiler-traces/trace-3e5cc660-8815-4079-86b9-778af8469d79.html.gz
>> [2] https://bugs.launchpad.net/osprofiler/+bug/1798565
>> [3] https://bugs.launchpad.net/osprofiler/+bug/1818493

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From colleen at gazlene.net  Fri Apr 12 15:49:20 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 12 Apr 2019 11:49:20 -0400
Subject: [keystone] Re: Pike: "Observer" or "read-only" admin access?
In-Reply-To: <2358baef1296b0d821e46c86fb457f96@jots.org>
References: <2358baef1296b0d821e46c86fb457f96@jots.org>
Message-ID: <985943e0-4dc5-4db5-82bb-3bf578724e43@www.fastmail.com>

Hi Ken,

On Thu, Apr 11, 2019, at 15:05, Ken D'Ambrosio wrote:
> Hi, all.  Beginning to roll out a newer-than-what-we-had OpenStack 
> release -- likely to be Pike, "For reasons."  (Which is still *worlds* 
> newer than Juno, where we are.)  And I've been asked if there's such a 
> thing as an account (or ACL) that allows a user to read everything, but 
> write nothing.  Googling, I see mention of such things -- but nothing 
> really firm.  Does it exist?  Is it in Pike (or more recent releases)?  
> If it doesn't exist, is there a graceful way to make it happen, anyway?
> 
> Thanks!
> 
> -Ken
> 
>

There is currently no read-only role that works out of the box in Pike or even in Stein. It's been a longstanding request and we're working on it:

http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html

The problem now is that just creating a role named "reader" in keystone doesn't automatically fix the problem, we need to coordinate with every project to redefine their default policies to use the reader role instead of using a catch-all member/Member/__member__ role. In the mean time, you can modify the policies of the services you run  to limit write operations to non-reader roles:

https://docs.openstack.org/keystone/latest/admin/service-api-protection.html
https://docs.openstack.org/oslo.policy/latest/admin/policy-yaml-file.html

Hope this helps.

Colleen


From dangtrinhnt at gmail.com  Fri Apr 12 16:16:08 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Sat, 13 Apr 2019 01:16:08 +0900
Subject: [telemetry] Nominating Rong Zhu for Telemetry core
Message-ID: <CADJ6S4G3w289z3idOjar9m96iQpgV4MV4mzu61_ErS1UbYT=hA@mail.gmail.com>

Hi team,

I'd like to nominate Rong Zhu (zhurong) to become a Telemetry core.

Rong Zhu has been contributing to OpenStack for a while now [1] and
sometimes jump in to help Telemetry projects fix bugs. While being the PTL
of Murano and Solum projects [2], his experience and network of developers
working on ceilometer/aodh projects would be a huge benefit for the team.

[1]
https://review.openstack.org/#/q/owner:%22zhurong+%253Caaronzhu1121%2540gmail.com%253E%22
[2] https://governance.openstack.org/election/results/train/ptl.html

Let give +1 for your agreement.

Yours,


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/607ee61b/attachment.html>

From ianyrchoi at gmail.com  Fri Apr 12 16:30:29 2019
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Sat, 13 Apr 2019 01:30:29 +0900
Subject: "Open Infrastructure & Cloud Native Days Korea 2019" is looking for
 Sponsors and Speakers
Message-ID: <0410f774-2385-9ddc-cf7d-9d5bfbabad74@gmail.com>

Dear OpenStack Community Members,

This year, I would like to announce that there will be
"Open Infrastructure & Cloud Native Days Korea 2019" in Korea
, with tight collaboration with Kubernetes & Ceph Korea User Groups 
(July 18th - 19th)!

This is the sixth event succeeding from the first OpenStack Days Korea 
event in
2014. Each of five previous events had a huge success and attracted lots
of interest among IT expert, engineers, developers and Executives.

The event will be held on three near-buildings at Eulji-ro area in 
Seoul. There will be
various keynotes, presentations, hands-on-labs,and attractive keynotes 
on timely and in-depth
technologies and solutions.

In order to successfully execute this event, we will need your help on
both sponsoring and your participation on the event.

https://openinfradays.kr/index_en.html

In the above event webpage, you will find link for both “Sponsorship”
and “Call for Speakers”. Please kindly review and consider sponsorship,
and get back to us. If you have any question, you can contact one of 
organizers
in OpenInfra Days Korea & Cloud Native Days Korea 2019 event stated at 
the end of this email.
In addition, if you are interested in speaking at the event, please fill
the form at “Call for Speakers” link (or please directly visit to Google 
Form
: https://goo.gl/forms/ovsT0zQVauLaDlHg2 )

Thank you very much in advance, and we look forward to working with you.



Best Regards,

OpenStack Korea User Group – Ian Y. Choi (ianyrchoi at gmail.com)
Kubernetes Korea User Group Leader: Seungkyu Ahn (seungkyua at gmail.com)
Ceph Korea User Group Leader: Seungjin Han (yongiman at gmail.com)
Program Chair – Jaesuk Ahn (bluejay.ahn at gmail.com)
Event Organizing Chair – Jungwon Ku (jwon.ku at gmail.com)



From anteaya at anteaya.info  Fri Apr 12 16:48:34 2019
From: anteaya at anteaya.info (Anita Kuno)
Date: Fri, 12 Apr 2019 12:48:34 -0400
Subject: [all] Gerrit will be offline April 19, 2019
Message-ID: <577b43b5-b17a-4f01-22a6-c0e6018c5dca@anteaya.info>

Pursuant to this email thread: 
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html 
, which discusses the rationale for moving git repo namespaces, Gerrit 
will be offline on April 19, 2019. Specific start time for the outage 
will be posted to this thread when it is decided next week. Outage may 
be sporadic as needed by the infra team, you can follow the progress in 
the #openstack-infra irc channel on freenode.

Please review the above linked email and all the subsequent posts, and 
please post any concerns about the rationale or details to the above 
thread. If you have concerns about the Gerrit outage scheduled to begin 
April 19, 2019, please reply to this thread and/or join us in 
#openstack-infra on freenode to share your questions or concerns.

Thank you,
Anita


From pierre at stackhpc.com  Fri Apr 12 17:02:11 2019
From: pierre at stackhpc.com (Pierre Riteau)
Date: Fri, 12 Apr 2019 18:02:11 +0100
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <c0cea172-de48-71c6-83e4-e28486e484f2@redhat.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
 <c0cea172-de48-71c6-83e4-e28486e484f2@redhat.com>
Message-ID: <CA+ny2sz6bFVHzZ6ztQtGndGinXp5VVj0FzoTw-iPzFs9-iebwQ@mail.gmail.com>

On Wed, 10 Apr 2019 at 12:16, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> On 4/10/19 12:14 PM, Jay Pipes wrote:
> > On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
> >> On 4/9/19 7:20 PM, Jay Pipes wrote:
> >>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
> >>>>  From ironic perspective there is no issue, but there is a critical question
> >>>> to decide: when Ironic+Placement is used, which of them acts as the final
> >>>> authority? If Ironic, then we need to teach Placement to talk to its
> >>>> Allocation API when allocating a bare metal node. If Placement, then we need
> >>>> to support Allocation API talking to Placement. I suspect the latter is
> >>>> saner, but I'd like to hear more opinions.
> >>>
> >>> Ironic (scheduler?) would request candidates from the placement service using
> >>> the GET /allocation_candidates API. Ironic (scheduler?) would then claim the
> >>> resources on a provider (a baremetal node) by calling the POST /allocations API.
> >>
> >> Okay, this matches my expectation.
> >>
> >> My concern will be with Blazar and reservations. If reservations happen
> >> through Placement only, how will ironic know about them? I guess we need to
> >> teach Blazar to talk to Ironic, which in turn will talk to Placement.
> >
> > Hmm. So, here's the problem: placement has no concept of time. [1]
> >
> > Placement only knows about one period of time: now. Placement doesn't have any
> > concept of an allocation or an inventory existing at some point in the future or
> > in the past.
> >
> > Therefore, Blazar must unfortunately keep all of the temporal state about
> > reservations in its own data store. So, Ironic would actually have to talk to
> > Blazar to create a reservation of some amount of resources and Blazar will need
> > to call Placement to manage the state of resource inventory and allocations over
> > time; as reservations are activated, Blazar will either create or swap
> > allocation records in Placement to consume the Ironic resources for a tenant
> > that made the reservation.
>
> I imagined it a bit differently. I assumed that
> 1. a user (operator?) talks to Blazar to create a bare metal node reservation.
> 1.1. some kind of quota is checked? does Blazar have any notion of quota?
> 2. Blazar talks to Ironic to create an allocation (yes, we also call it
> allocation, feel free to blame me)
> 3. Ironic gets a reservation from Placement and updates its internal records
> 4. Ironic returns an allocation to Blazar
> 5. Blazar returns a reservation to a user
>
> And when a reservation in Blazar expires or is returned:
> 6. Blazar talks to Ironic to undeploy the node
> 6.1. Ironic deletes its allocation automatically
> 6.2. And thus notifies Placement to remove its allocation
>
> Am I missing something?

If we follow the current model used with Nova and now also with
Neutron, Blazar would be directly aware of all Ironic nodes (we store
a copy of the essential resource information in the Blazar database).
It would use it to make its own resource allocation decisions for
future reservations. On reservation start, it could call Ironic to
create an allocation on the node with `candidate_nodes` and provide it
to the reservation's owner for deployment.

However, is there a way to prevent anyone but the reservation's owner
from using the corresponding Ironic allocation? From looking at the
API doc, I couldn't really see any enforcement of Ironic allocations
being done.

I am not sure how placement fits into this. If Ironic starts using
placement for its allocation API, as it is mentioned in
https://storyboard.openstack.org/#!/story/2004341, we would figure out
a way for Blazar to put a hold on reservable nodes, so that users
allocating directly with Ironic could only request from a
non-reservable pool of nodes. Blazar would create Ironic allocation on
behalf of users as described above. The question of allocation
enforcement is also critical in this scenario.

PS: Blazar doesn't handle any quota yet. It's a major flaw so we'll
need to tackle it soon. I am hoping we'll be able to leverage unified
limits for this.


From dangtrinhnt at gmail.com  Fri Apr 12 13:28:50 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Fri, 12 Apr 2019 22:28:50 +0900
Subject: [tc][telemetry] Asking core privileges on Telemetry projects
In-Reply-To: <CAN2nDNvU7Tfdfs9QVBbXaH+-dn+htohDa7kh3gxz=-XbVh4-Ag@mail.gmail.com>
References: <CADJ6S4GU4gHN254OSmHO9xaSTie5E34ZoM760bjAXgZR4TXTow@mail.gmail.com>
 <1554302085.4997.19.camel@offenerstapel.de>
 <CADJ6S4F+TF8iUe8CQP0cu-F7UxhGw+gGNdQd4YAfyP+n+MZMhw@mail.gmail.com>
 <dd8e1db2-dcbc-8cfb-e321-d79a56c983a0@suse.com>
 <CADJ6S4Htyk+2=4mRs2UT3ZvS2u24XuQHXoYiBm+T4ObQ0-Ecyg@mail.gmail.com>
 <CAN2nDNvU7Tfdfs9QVBbXaH+-dn+htohDa7kh3gxz=-XbVh4-Ag@mail.gmail.com>
Message-ID: <CADJ6S4EewX6273h90-ZL0aZg40q7BmLCSRu3ssg8GKXMY2AV-Q@mail.gmail.com>

Thanks. Rong Zhu :)

On Fri, Apr 12, 2019 at 10:15 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Telemetry:
> ptl:
> name: Trinh Nguyen
> irc: dangtrinhnt
> email: dangtrinhnt at gmail.com
> appointed:
> - train
> irc-channel: openstack-telemetry
> service: Telemetry service
> mission: >
> To reliably collect measurements of the utilization of the physical and
> virtual resources comprising deployed clouds, persist these data for
> subsequent retrieval and analysis, and trigger actions when defined
> criteria are met.
> url: https://wiki.openstack.org/wiki/Telemetry
> deliverables:
> aodh:
> repos:
> - openstack/aodh
> tags:
> - assert:follows-standard-deprecation
> ceilometer:
> repos:
> - openstack/ceilometer
> tags:
> - assert:follows-standard-deprecation
> - assert:supports-upgrade
> - tc:approved-release
> telemetry-specs:
> release-management: none
> repos:
> - openstack/telemetry-specs
> ceilometermiddleware:
> repos:
> - openstack/ceilometermiddleware
> panko:
> repos:
> - openstack/panko
> tags:
> - assert:follows-standard-deprecation
> python-aodhclient:
> repos:
> - openstack/python-aodhclient
> python-pankoclient:
> repos:
> - openstack/python-pankoclient
> telemetry-tempest-plugin:
> repos:
> - openstack/telemetry-tempest-plugin
>
>
> Check from governance ceilometermiddleware is belongs to Telemetry team.
>
> Regards,
> Rong Zhu
>
> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月12日 周五11:17写道：
>
>> Hi Andreas,
>>
>> Just one question, is openstack/ceilometermiddleware project belongs to
>> the Telemetry team? If that is the case, please add me to the team.
>>
>> Thank you,
>>
>> On Wed, Apr 10, 2019 at 4:50 PM Andreas Jaeger <aj at suse.com> wrote:
>>
>>> On 10/04/2019 08.50, Trinh Nguyen wrote:
>>> > Hi Jens,
>>> >
>>> > I just see I'm not in the list of these following groups on gerrit:
>>> >
>>> > ceilometer-release
>>> > aodh-release
>>> > panko-release
>>> >
>>> > Could you please add me to those as well?
>>>
>>> You don't need to be - releases are done via the releases repo.
>>>
>>> Those groups are completely unused currently,
>>>
>>> Andreas
>>> --
>>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> <https://maps.google.com/?q=Maxfeldstr.+5,+90409+N%C3%BCrnberg,+Germany&entry=gmail&source=g>
>>>    GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
>>>        HRB 21284 (AG Nürnberg)
>>>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>>
>>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>> --
> Thanks,
> Rong Zhu
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/ec78192c/attachment-0001.html>

From cdent+os at anticdent.org  Fri Apr 12 17:54:01 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Fri, 12 Apr 2019 18:54:01 +0100 (BST)
Subject: [placement] update 19-14
Message-ID: <alpine.OSX.2.21.1904121853260.33229@cdent-a01.vmware.com>


HTML: https://anticdent.org/placement-update-19-14.html

Placement update 19-14 is here. There will be no 15, 16 or 17 due to
various bits of travel. There will be some PTG-related summaries.

# Most Important

The [Virtual
Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004225.html)
is in full swing and making some good progress towards making sure
that we only hit the hard stuff at the in-person PTG. Apologies if
it has been a bit overwhelming. The hope is that by paying the price
of a bit more whelm now we will have less whelm at the PTG. If you
have questions, please ask.

Links to all the threads are in the PTG etherpads:

* <https://etherpad.openstack.org/p/placement-ptg-train>
* <https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement>

There's also a [retrospective
etherpad](https://etherpad.openstack.org/p/placement-ptg-train-retrospective).

# What's Changed

* The [0.12.0 release of os-traits](https://review.openstack.org/652079)
   is pending. It switches that package to using the independent
   release policy. os-resource-classes will get the same treatment
   when we next need to release it.

# Specs/Features

There are four specs in flight in the placement repo and one
pending to be ported over from nova:

* <https://review.openstack.org/649992>
   support any trait in allocation candidates

* <https://review.openstack.org/649368>
   support mixing required traits with any traits

* <https://review.openstack.org/650476>
   Allocation Candidates: Subtree Affinity. There's discussion
   related to this happening in
   [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004782.html)
   as part of the pre-PTG.

* <https://review.openstack.org/651113>
   Support filtering by multiple trees.

* <https://review.openstack.org/597601>
   Request group mapping spec is still in Nova, but discussion is
   happening in
   [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004819.html)
   generating a plan for how to proceed.

There are also several nova-specs that were visited in the [nova
spec
review day](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004484.html)
earlier this week. Some are listed below.

# Bugs

* StoryBoard stories in [the placement
   group](https://storyboard.openstack.org/#!/project_group/placement): 15.
   Up by 9. 0 are
   [untagged](https://storyboard.openstack.org/#!/worklist/580). Part
   of the reason for the increase is because Matt did the fine work
   of moving osc-placement bugs over from launchpad.

* Placement related [bugs not yet in progress](https://goo.gl/TgiPXb)
   on launchpad: 13. No change.

* [In progress placement bugs](https://goo.gl/vzGGDQ) on launchpad: 4.
   -1. Those that remain are placement-related, but in nova.

# osc-placement

osc-placement is currently behind by 13^w11 microversions. -1 since last
week. Support for 1.19 has just merged. Oh wait, no, -3. 1.21 has
just merged. There was nothing to do for 1.20.

Pending changes:

* <https://review.openstack.org/#/c/640898/>
   Add 'resource provider inventory update' command (that helps with
   aggregate allocation ratios).

* <https://review.openstack.org/#/c/651783/>
   Add support for 1.22 microversion

* <https://review.openstack.org/586056>
   Provide a useful message in the case of 500-error

* <https://review.openstack.org/650257>
   Remove unused cruft from doc and releasenotes config

* <https://review.openstack.org/652100>
   Improve aggregate version check error messages with min_version

* <https://review.openstack.org/651939>
   Use PlacementFixture in functional tests. Result of discussion in
   [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004731.html)
   in the pre-PTG

# Main Themes

More work remains in the pre-PTG discussions to try to drive towards
some themes. The specs above capture some of it, but it appears
like a lot of the work will be a) supporting other projects doing
things with Placement, b) fixing bugs they discover.

# Other Placement

Mostly specs in progress (listed above) for now.

* <https://review.openstack.org/#/c/645255/>
   This is a start at unit tests for the PlacementFixture. It is
   proving a bit "fun" to get right, as there are many layers
   involved. Making sure seemingly unrelated changes in placement
   don't break the nova gate is important. Besides these unit tests,
   there's discussion on the PTG etherpad of running the nova
   functional tests, or a subset thereof, in placement's check run.

     On the one hand this is a pain and messy, but on the other
     consider what we're enabling: Functional tests that use the real
     functionality of an external service (real data, real web
     requests), not stubs or fakes.

     There's a pre-PTG
     [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004880.html)
     for this.

* <https://review.openstack.org/641404>
   Use ``code`` role in api-ref titles

* <https://review.openstack.org/#/q/topic:refactor-classmethod-diaf>
   A sequence of refactorings, based off discussion in yet another
   pre-PTG
   [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004722.html).

# Other Service Users

New discoveries are added to the end. Merged stuff is removed.

* <https://review.openstack.org/552924>
   Nova: Spec: Proposes NUMA topology with RPs

* <https://review.openstack.org/622893>
   Nova: Spec: Virtual persistent memory libvirt driver
   implementation

* <https://review.openstack.org/641899>
   Nova: Check compute_node existence in when nova-compute reports
   info to placement

* <https://review.openstack.org/601596>
   Nova: spec: support virtual persistent memory

* <https://review.openstack.org/#/q/topic:bug/1790204>
   Workaround doubling allocations on resize

* <https://review.openstack.org/555081>
   Nova: Spec: Standardize CPU resource tracking

* <https://review.openstack.org/645316>
   Nova: Pre-filter hosts based on multiattach volume support

* <https://review.openstack.org/606199>
   Ironic: A fresh way of looking at step retrieval

* <https://review.openstack.org/647396>
   Nova: Add flavor to requested_resources in RequestSpec

* <https://review.openstack.org/633204>
   Blazar: Retry on inventory update conflict

* <https://review.openstack.org/640080>
   Nova: Use aggregate_add_host in nova-manage

* <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement>
   Nova: count quota usage from placement

* <https://review.openstack.org/#/q/topic:bug/1819923>
   Nova: nova-manage: heal port allocations

* <https://review.openstack.org/624335>
   puppet-tripleo: Initial extraction of the Placement service from Nova

* <https://review.openstack.org/648665>
   Nova: Spec for a new nova virt driver to manage an RSD

* <https://review.openstack.org/#/c/642067/>
   Helm: Allow more generic overrides for nova placement-api

* <https://review.openstack.org/609960>
   Support filtering of allocation_candidates by forbidden aggregates

* <https://review.openstack.org/625284>
   Cyborg: Initial readme for nova pilot

* <https://review.openstack.org/629142>
   Tempest: Add QoS policies and minimum bandwidth rule client

* <https://review.openstack.org/641994>
   Nova-spec: Re-approve AMD SEV support for Train

* <https://review.openstack.org/648687>
   Nova-spec: Add PENDING vm state

* <https://review.openstack.org/#/q/topic:bug/1777591>
   Nova: use in_tree in RequestGroup

* <https://review.openstack.org/650856>
   kolla-ansible: Remove placement migration code

* <https://review.openstack.org/650188>
   nova-spec: Allow compute nodes to use DISK_GB from shared storage RP

* <https://review.openstack.org/651024>
   nova-spec: RMD Plugin: Energy Efficiency using CPU Core P-State control

* <https://review.openstack.org/651455>
   puppet: Debian: Add support for placement-api over uwsgi

* <https://review.openstack.org/650963>
   nova-spec: Proposes NUMA affinity for vGPUs. This describes a
   legacy way of doing things because affinity in placement may be a
   ways off. But it also [may not
   be](https://review.openstack.org/650476).

* <https://review.openstack.org/649882>
   nova-spec: Separate the vCPUs into different pools based on priority

* <https://review.openstack.org/#/q/topic:heal_allocations_dry_run>
   Nova: heal allocations, --dry-run

* <https://review.openstack.org/642527>
   Neutron: Fullstack test for placement sync

# End

There's a lot going on.


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From fungi at yuggoth.org  Fri Apr 12 18:06:41 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Apr 2019 18:06:41 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20190412142734.GA3579@sm-workstation>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
 <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
 <20190412142734.GA3579@sm-workstation>
Message-ID: <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>

On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote:
[...]
> Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0].
> Though Cinder did not get the same enforcement until Rocky [1].
> 
> [0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
> [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image-signature-verification.html
> 
> (And specs are always 100% accurate, right?)

Neat, I had no idea that had improved in the past few years. At any
rate, my main point still stands: if you don't trust the operators
of that environment then the checksums are pure theater, since they
could disable checksum validation or even just serve you a
completely fictional hash from the catalog.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/54ef5c82/attachment.sig>

From cboylan at sapwetik.org  Fri Apr 12 18:30:46 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Fri, 12 Apr 2019 14:30:46 -0400
Subject: =?UTF-8?Q?Re:_Upgrading_the_lists.(openstack|airshipit|starlingx|zuul-ci?=
 =?UTF-8?Q?).org_server_Friday_April_12?=
In-Reply-To: <179ca814-356a-46ee-ae13-a4e320a1dba4@www.fastmail.com>
References: <179ca814-356a-46ee-ae13-a4e320a1dba4@www.fastmail.com>
Message-ID: <43d3572d-08de-4e72-8c31-d8fa4d505855@www.fastmail.com>

On Tue, Apr 9, 2019, at 2:07 PM, Clark Boylan wrote:
> It is that time of the Ubuntu LTS cycle again and we need to upgrade 
> our mailman mailing list server. We'd like to do that this Friday, 
> April 12. We expect the upgrade to begin at about 17:00UTC and result 
> in a 30-45 minute outage. The reason for the extended outage is that we 
> will be upgrading the server in place to preserve its mail reputation.
> 
> Thankfully email is a persistent system and your clients should queue 
> up email sent until the server is back up again and accepting smtp 
> connections. This means the outage shouldn't be very noticeable.
> 
> Finally, for list admins, there are new DMARC moderation action 
> settings. We ask that you don't change these settings and instead work 
> with us if you need to address DMARC problems. Our current preference 
> is that we pass email through unmodified so that the signatures still 
> validate.
> 
> Thank you all for your patience and feel free to ask us questions,
> Clark
> 
>

The upgrade is complete and we believe the lists to be operational again. As always feel free to ask us questions or point out any odd behaviors if you notice them.

Thanks again for your patience,
Clark


From artem.goncharov at gmail.com  Fri Apr 12 18:36:59 2019
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Fri, 12 Apr 2019 20:36:59 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
 <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
 <20190412142734.GA3579@sm-workstation>
 <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>
Message-ID: <CAMdUkEbpUNgoeTTwKXTacGU_KGSPoOmOT6EtamBJ6Sci7cHjxQ@mail.gmail.com>

On Fri, 12 Apr 2019, 20:29 Jeremy Stanley, <fungi at yuggoth.org> wrote:

> On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote:
> [...]
> > Hmm, according to the spec, Nova verifies those checksums as of Mitaka
> [0].
> > Though Cinder did not get the same enforcement until Rocky [1].
> >
> > [0]
> https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
> > [1]
> https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image-signature-verification.html
> >
> > (And specs are always 100% accurate, right?)
>
> Neat, I had no idea that had improved in the past few years. At any
> rate, my main point still stands: if you don't trust the operators
> of that environment then the checksums are pure theater, since they
> could disable checksum validation or even just serve you a
> completely fictional hash from the catalog.
>

Fictional hash - how true it really is sometimes. Don't trust the
checksums. In the cloud I'm using the uploaded image is being automatically
converted for a backend storage by a plugin, therefore the checksum us just
a trash. And you anyway can't download image back, so you can't do anything
with the checksum anyway.

Artem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/72211782/attachment.html>

From ricardo at palmtx.com.ar  Fri Apr 12 18:47:28 2019
From: ricardo at palmtx.com.ar (Ricardo J. Barberis)
Date: Fri, 12 Apr 2019 15:47:28 -0300
Subject: Disabling SSLv3, TLSv1.0 and TLSv1.1 in nova-novncproxy?
Message-ID: <201904121547.28259.ricardo@palmtx.com.ar>

Hello list,

I've been tasked with disabling SSLv3, TLSv1.0 and TLSv1.1 in all of our 
public endpoints (not only OpenStack) and I'm having trouble finding where 
does nova-novncproxy sets which protocols to use.

I have nova-novncproxy installed in 2 servers, one CentOS 6.10 (python 2.6) 
tied to an IceHouse installation, the other a CentOS 7 (python 2.7) tied to a 
Queens installation.


Software versions:

[root at vnc01 ~] # rpm -qa \*nova\* \*vnc\* | sort
novnc-0.4-8.el6.noarch
openstack-nova-common-2014.1.5-1.el6.noarch
openstack-nova-novncproxy-2014.1.5-1.el6.noarch
python-nova-2014.1.5-1.el6.noarch
python-novaclient-2.17.0-2.el6.noarch

[root at vnc02 ~] # rpm -qa \*nova\* \*vnc\* | sort
novnc-0.5.1-2.el7.noarch
openstack-nova-common-17.0.9-1.el7.noarch
openstack-nova-novncproxy-17.0.9-1.el7.noarch
python-nova-17.0.9-1.el7.noarch
python2-novaclient-10.1.0-1.el7.noarch


Any pointers will be appreciated.

BTW, I also tried proxying them with nginx but in that case the vnc console 
doesn't work. I didn't try too hard to debug it, though.

Thanks,
-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com


From fungi at yuggoth.org  Fri Apr 12 19:09:18 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Apr 2019 19:09:18 +0000
Subject: [chef] Renaming the Chef OpenStack project
In-Reply-To: <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
References: <1554724565.4997.26.camel@offenerstapel.de>
 <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
Message-ID: <20190412190917.wpym4n5ti6422ltz@yuggoth.org>

On 2019-04-12 10:56:17 -0400 (-0400), Mohammed Naser wrote:
[...]
> I haven't dug into the history if we've ever done a similar
> rename, but perhaps one of our OpenStack historians can point to
> commits in the past where we've done the same and how it was dealt
> with in other places.

2018-03-23 PowerStackers -> PowerVMStackers
https://review.openstack.org/551413

2017-12-12 Shade -> OpenStackSDK
https://review.openstack.org/523520

2015-12-15 Release Cycle Management -> Release Management
https://review.openstack.org/255379

2014-08-20 Marconi -> Zaqar
https://review.openstack.org/114770

2014-03-17 Savanna -> Sahara
https://review.openstack.org/79765

2013-11-27 Ceilometer -> Telemetry
https://review.openstack.org/56402

2013-07-06 Quantum -> Neutron
[before openstack/governance repo existed]

And there are probably a few more I'm forgetting. A number of
unofficial teams also changed their names at the same as time or
immediately prior to petitioning the TC for recognition as official
programs or projects, mostly for legal/trademark reasons.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/8a1a3fd4/attachment.sig>

From jeremyhouser at protonmail.com  Fri Apr 12 19:44:15 2019
From: jeremyhouser at protonmail.com (Jeremy Houser)
Date: Fri, 12 Apr 2019 19:44:15 +0000
Subject: [Cinder] Odd Volume and Volume Snapshot Dependencies
Message-ID: <oWOc_saGvMPgIEV8edFU1wC_2zVecPwHi6KeFZVJ-cGUN5kE2Us5zJ4K23FBq2VuHyiCUe0QtBW-N1HqHakT_vzkP3vi5hV54HEZhVgHASg=@protonmail.com>

Currently running python-openstackclient functional tests against an
openstack deployment. Ran into some odd functionality whilst
manipulating volumes and snapshots in openstack via cli and gui.

I create a volume, create a snapshot of that volume, and then create a
volume from that snapshot. I can't delete the snapshot until I delete the
volume that I spawned using that snapshot. I understand the dependency
of "can't delete a volume while a snapshot dependent on that volume is
deleted first" but why can't a volume snapshot be deleted when volumes
are spawned from it? Is this intentional? I am working with Cinder 3.27.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/a85094cc/attachment.html>

From colleen at gazlene.net  Fri Apr 12 20:14:31 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 12 Apr 2019 16:14:31 -0400
Subject: [dev][keystone] Keystone Team Update - Week of 8 April 2019
Message-ID: <4c9c6052-44e0-4958-8c76-0cffe45ebc14@www.fastmail.com>

# Keystone Team Update - Week of 8 April 2019

## News

### Stein Release

Keystone has been released for Stein! Congrats on a great release!

### Predictable IDs

We're starting to move forward[1][2][3][4] with Adam's predictable IDs initiative[5], including discussing[6] whether and how to migrate deployments to using hashed IDs so that they can become multi-site ready.

[1] https://review.openstack.org/605169
[2] https://review.openstack.org/650615
[3] https://review.openstack.org/605235
[4] https://review.openstack.org/651655
[5] https://review.openstack.org/612099
[6] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-04-11.log.html#t2019-04-11T14:48:55

### Admin endpoint

Jens is working on getting us on track to remove the admin endpoint from deployments[7][8], since keystone is the only service that uses it and it's no longer needed in a V3-only world. There are a few hardcoded defaults that make the switchover less than straightforward that we're working out[9].

[7] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2019-04-10.log.html#t2019-04-10T12:36:14
[8] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2019-04-12.log.html#t2019-04-12T14:42:46
[9] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-04-12.log.html#t2019-04-12T17:56:45

## Open Specs

Train specs: https://bit.ly/2uZ2tRl

Ongoing specs: https://bit.ly/2OyDLTh

Train specs have begun! Please review the open spec proposals so we can discuss them at the PTG.

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 31 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2tymTje

There are 24 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots.

## Bugs

This week we opened 2 new bugs and closed 4.

Bugs opened (2) 
Bug #1823847 (keystone:Undecided) opened by Shivakumar M https://bugs.launchpad.net/keystone/+bug/1823847 
Bug #1824239 (keystone:Undecided) opened by Adam Young https://bugs.launchpad.net/keystone/+bug/1824239 

Bugs closed (1) 
Bug #1823847 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1823847 

Bugs fixed (3) 
Bug #1779889 (keystone:Medium) fixed by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1779889
Bug #1641639 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1641639 
Bug #1794527 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1794527

## Milestone Outlook

https://releases.openstack.org/train/schedule.html

The Train cycle will open next week. We'll need to decide on deadlines for the cycle soon.

## Shout-outs

Thanks everyone for making this a great release! Looking forward to seeing what we can accomplish next cycle :)

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter


From ed at leafe.com  Fri Apr 12 20:40:41 2019
From: ed at leafe.com (Ed Leafe)
Date: Fri, 12 Apr 2019 15:40:41 -0500
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <CA+ny2sz6bFVHzZ6ztQtGndGinXp5VVj0FzoTw-iPzFs9-iebwQ@mail.gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
 <c0cea172-de48-71c6-83e4-e28486e484f2@redhat.com>
 <CA+ny2sz6bFVHzZ6ztQtGndGinXp5VVj0FzoTw-iPzFs9-iebwQ@mail.gmail.com>
Message-ID: <DB4C6D36-BC2A-4DA1-BE93-F9AA4F8AC9D9@leafe.com>

On Apr 12, 2019, at 12:02 PM, Pierre Riteau <pierre at stackhpc.com> wrote:
> 
> I am not sure how placement fits into this. If Ironic starts using
> placement for its allocation API, as it is mentioned in
> https://storyboard.openstack.org/#!/story/2004341, we would figure out
> a way for Blazar to put a hold on reservable nodes, so that users
> allocating directly with Ironic could only request from a
> non-reservable pool of nodes. Blazar would create Ironic allocation on
> behalf of users as described above. The question of allocation
> enforcement is also critical in this scenario.

As was mentioned earlier in this thread, placement does not have a concept of time, except for “right now”. In other words, you cannot say “allocate this resource to this consumer next Tuesday at 1400UTC, and then delete that allocation after 48 hours”.

At an earlier PTG (Dublin?) we spoke of different ways around this. One was creating an aggregate for Blazar-controlled resources, and then somehow forbidding other services from using those resources. Another was allocating the resources to Blazar so that no one else could use them, and then Blazar would use a two-step process (release the resource; allocate it to the consumer) when the actual usage begins. Neither is ideal, but they do get around the time-agnostic nature of placement.

-- Ed Leafe







From melwittt at gmail.com  Fri Apr 12 22:09:34 2019
From: melwittt at gmail.com (melanie witt)
Date: Fri, 12 Apr 2019 15:09:34 -0700
Subject: Disabling SSLv3, TLSv1.0 and TLSv1.1 in nova-novncproxy?
In-Reply-To: <201904121547.28259.ricardo@palmtx.com.ar>
References: <201904121547.28259.ricardo@palmtx.com.ar>
Message-ID: <0f58c704-5df1-fc65-f90f-1cc6664a0601@gmail.com>

On Fri, 12 Apr 2019 15:47:28 -0300, Ricardo J. Barberis 
<ricardo at palmtx.com.ar> wrote:
> Hello list,
> 
> I've been tasked with disabling SSLv3, TLSv1.0 and TLSv1.1 in all of our
> public endpoints (not only OpenStack) and I'm having trouble finding where
> does nova-novncproxy sets which protocols to use.
> 
> I have nova-novncproxy installed in 2 servers, one CentOS 6.10 (python 2.6)
> tied to an IceHouse installation, the other a CentOS 7 (python 2.7) tied to a
> Queens installation.
> 
> 
> Software versions:
> 
> [root at vnc01 ~] # rpm -qa \*nova\* \*vnc\* | sort
> novnc-0.4-8.el6.noarch
> openstack-nova-common-2014.1.5-1.el6.noarch
> openstack-nova-novncproxy-2014.1.5-1.el6.noarch
> python-nova-2014.1.5-1.el6.noarch
> python-novaclient-2.17.0-2.el6.noarch
> 
> [root at vnc02 ~] # rpm -qa \*nova\* \*vnc\* | sort
> novnc-0.5.1-2.el7.noarch
> openstack-nova-common-17.0.9-1.el7.noarch
> openstack-nova-novncproxy-17.0.9-1.el7.noarch
> python-nova-17.0.9-1.el7.noarch
> python2-novaclient-10.1.0-1.el7.noarch
> 
> 
> Any pointers will be appreciated.
> 
> BTW, I also tried proxying them with nginx but in that case the vnc console
> doesn't work. I didn't try too hard to debug it, though.

TL;DR: The protocol version is handled automatically.

The nova-novncproxy is a websockify server and it is in websockify code 
where the socket is wrapped for SSL [1]. By default, wrap_socket [2] 
uses the PROTOCOL_SSLv23 constant. In python 2.6, it "Selects SSL 
version 2 or 3 as the channel encryption protocol." [3]. In python 2.7, 
it's an alias for PROTOCOL_TLS and "Selects the highest protocol version 
that both the client and server support." The available versions with 
PROTOCOL_SSLv23 depend on the openssl version being used [5].

Hope this helps.

-melanie

[1] 
https://github.com/novnc/websockify/blob/e4658ada2e2e179cdb8f6362dbb7c5e3ce3ff717/websockify/websockifyserver.py#L585
[2] https://docs.python.org/2/library/ssl.html#ssl.wrap_socket
[3] https://docs.python.org/2.6/library/ssl.html#ssl.PROTOCOL_SSLv23
[4] https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_SSLv23
[5] https://docs.python.org/2/library/ssl.html#id2






From tony at bakeyournoodle.com  Fri Apr 12 22:34:50 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Sat, 13 Apr 2019 08:34:50 +1000
Subject: [dev][stable][release][manila] Should we revert these stable
 branch backports?
In-Reply-To: <20190412135235.p3mwetqcja3afxsi@barron.net>
References: <20190327125654.5bazj5hic3ilj27q@barron.net>
 <20190412024708.GR7047@thor.bakeyournoodle.com>
 <20190412135235.p3mwetqcja3afxsi@barron.net>
Message-ID: <20190412223450.GT7047@thor.bakeyournoodle.com>

On Fri, Apr 12, 2019 at 09:52:35AM -0400, Tom Barron wrote:
> On 12/04/19 12:47 +1000, Tony Breeds wrote:
> > 
> > So someone that is using the VMAX driver from 5.0.3 has set
> > emc_interface_ports in the config.  Assuming we don't revert and release
> > 5.0.4[1], that same config file will continue to work but there will now be
> > a deprecation warning in the logs.
> > 
> > The VMAX user probably had to look at the code to workout that the
> > config sample was out of sync with the code?
> 
> Right, or some support person told them some magic.
> 
> > 
> > Yours Tony.
> > 
> > [1] or probably 5.1.0 as a signal to operators
> 
> Agree that 5.1.0 makes sense, thanks.

Thanks Tom.  I see that you've made that change already so I'll approve
https://review.openstack.org/#/c/650250/

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/0b89527f/attachment.sig>

From tony at bakeyournoodle.com  Fri Apr 12 22:37:08 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Sat, 13 Apr 2019 08:37:08 +1000
Subject: [release][stable][trove] Please add Lingxian Kong to
 trove-stable-maint group
In-Reply-To: <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
References: <CALjNAZ0yyHrDuHFYw1m9MTo+K9Y0cF5dWyyt=Ls7-9iqePZarw@mail.gmail.com>
 <20190410003703.GG7047@thor.bakeyournoodle.com>
 <ca85f4a6-fe45-eff4-23d3-141278a6c26c@gmail.com>
 <CALjNAZ2+abDejw4Pi8izyf9zdf2+EQ=Mv1EjBZviFVvN+hx5dg@mail.gmail.com>
 <52e4c144-fba5-eb8d-3c34-2e57fe8a8b79@gmail.com>
Message-ID: <20190412223708.GU7047@thor.bakeyournoodle.com>

On Thu, Apr 11, 2019 at 09:24:33PM -0500, Matt Riedemann wrote:

> But as Mohammed pointed out, if Trove elects to *not* follow the stable
> policy then we simply have to remove the "stable:follows-policy" tag from
> governance and trove is free to backport as it pleases (I think? Tony can
> correct me).

That is correct.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/b08ccda1/attachment-0001.sig>

From tony at bakeyournoodle.com  Fri Apr 12 22:52:46 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Sat, 13 Apr 2019 08:52:46 +1000
Subject: [chef] Renaming the Chef OpenStack project
In-Reply-To: <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
References: <1554724565.4997.26.camel@offenerstapel.de>
 <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
Message-ID: <20190412225246.GV7047@thor.bakeyournoodle.com>

On Fri, Apr 12, 2019 at 10:56:17AM -0400, Mohammed Naser wrote:
 
> I don't think I have too much of a problem with it but I can think of
> a few consumers
> who might want to mention if they're broken which are
> 
> - openstack-map / OSF website
> - release team

The release-team is fine as Chef uses it's own external process:

[tony at thor releases]$ git grep -Ei chef deliverables/
[tony at thor releases]$ cd governance
[tony at thor governance]$ yq '.["Chef OpenStack"]["deliverables"][]["release-management"]' reference/projects.yaml
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"external"
"none"

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/0aed307a/attachment.sig>

From hongbin034 at gmail.com  Fri Apr 12 22:20:26 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Fri, 12 Apr 2019 18:20:26 -0400
Subject: [Zun] Heat and Horizon Support
In-Reply-To: <CAGocpaEfiYjBfJvKdj50qk9TWD8H9bz-GwuqabFbdog0PYK=tQ@mail.gmail.com>
References: <AM6PR06MB587981E65DB6E765629A1600DE2E0@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAFNUc+Q20BYJJNAsYbaVytWmO1xNZ+xujN0NYfjB-1HPcuDKkQ@mail.gmail.com>
 <AM6PR06MB58790EA27AA1C783ACA34A04DE280@AM6PR06MB5879.eurprd06.prod.outlook.com>
 <CAGocpaEfiYjBfJvKdj50qk9TWD8H9bz-GwuqabFbdog0PYK=tQ@mail.gmail.com>
Message-ID: <CAFNUc+Rb8Rg-rcYjpi91R4_TP8j0EuDc0mxiKvY_iMZcTPmYog@mail.gmail.com>

Ivan,

Cool. Thanks a lot for the patch.

Best regards,
Hongbin

On Fri, Apr 12, 2019 at 9:20 AM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> I created a patch [1] to fix this issue in the documentation.
>
> [1] https://review.openstack.org/652047
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> On Fri, Apr 12, 2019 at 2:02 PM Navdeep Uniyal <
> navdeep.uniyal at bristol.ac.uk> wrote:
>
>> Hi Hongbin,
>>
>> Thank you very much again for your response and help.
>> I could resolve the issue with the following commands as suggested by
>> Ivan:
>>
>> cd  <path to your horizon>/
>>
>> python manage.py collectstatic && python manage.py compress
>>
>>
>>
>> Thank you again for your help.
>>
>> Kind Regards,
>> Navdeep
>>
>>
>>
>> *From:* Hongbin Lu <hongbin034 at gmail.com>
>> *Sent:* 12 April 2019 03:11
>> *To:* Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
>> *Cc:* openstack-discuss at lists.openstack.org
>> *Subject:* Re: [Zun] Heat and Horizon Support
>>
>>
>>
>> Hi Navdeep,
>>
>>
>>
>> Unfortunately, I am not quite familiar with UI. I asked our UI developer
>> and below is his response:
>>
>>
>>
>> "Horizon seems to fail in rebuilding style sheet, or to fail in reloading
>> it from his browser.
>>
>> As described in the install documentation, restarting Horizon is needed.
>> AFAIK, Horizon's starting script rebuilds style sheet including plugin's.
>> Also, reloading forcely from browser using Ctrl+F5 might help to resolve
>> the problem."
>>
>>
>>
>> Hope it helps.
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>> On Wed, Apr 10, 2019 at 1:18 PM Navdeep Uniyal <
>> navdeep.uniyal at bristol.ac.uk> wrote:
>>
>> Dear All,
>>
>> I would like to integrate my Zun deployment (OS Rocky) with Heat and
>> Horizon.
>> For horizon, I used the instructions given in
>> https://docs.openstack.org/zun-ui/rocky/install/index.html
>>
>> However, while adding the files to
>> */usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>>
>> Using : *cp zun_ui/enabled/*
>> /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled*
>>
>>
>>
>> My openstack UI is breaking down :
>>
>>
>>
>> Please advise.
>>
>>
>>
>> Kind Regards,
>>
>> Navdeep
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/e37bbbb8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 55995 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/e37bbbb8/attachment-0001.jpg>

From manuel.sb at garvan.org.au  Sat Apr 13 02:12:56 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Sat, 13 Apr 2019 02:12:56 +0000
Subject: how to define a flavor... numa topology and/or cpu pinning?
Message-ID: <9D8A2486E35F0941A60430473E29F15B017E8A88B8@MXDB1.ad.garvan.unsw.edu.au>

Hi,

considering my hosts have numa architecture.

what is the difference between "numa topology" and "cpu pinning"? would "cpu pinning" make any difference if "numa topology" is already in place?

thank you very much




NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/bb378706/attachment.html>

From anlin.kong at gmail.com  Sat Apr 13 04:43:38 2019
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Sat, 13 Apr 2019 16:43:38 +1200
Subject: [telemetry] Nominating Rong Zhu for Telemetry core
In-Reply-To: <CADJ6S4G3w289z3idOjar9m96iQpgV4MV4mzu61_ErS1UbYT=hA@mail.gmail.com>
References: <CADJ6S4G3w289z3idOjar9m96iQpgV4MV4mzu61_ErS1UbYT=hA@mail.gmail.com>
Message-ID: <CALjNAZ1ZAnZ6X8evePypRh7RRigvFM00j7SAiwob84KSX3uhdg@mail.gmail.com>

+1, welcome!

---
Cheers,
Lingxian Kong
Catalyst Cloud


On Sat, Apr 13, 2019 at 4:20 AM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> I'd like to nominate Rong Zhu (zhurong) to become a Telemetry core.
>
> Rong Zhu has been contributing to OpenStack for a while now [1] and
> sometimes jump in to help Telemetry projects fix bugs. While being the PTL
> of Murano and Solum projects [2], his experience and network of developers
> working on ceilometer/aodh projects would be a huge benefit for the team.
>
> [1]
> https://review.openstack.org/#/q/owner:%22zhurong+%253Caaronzhu1121%2540gmail.com%253E%22
> [2] https://governance.openstack.org/election/results/train/ptl.html
>
> Let give +1 for your agreement.
>
> Yours,
>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/bbccfd0d/attachment.html>

From gilles.mocellin at nuagelibre.org  Sat Apr 13 09:16:21 2019
From: gilles.mocellin at nuagelibre.org (Gilles Mocellin)
Date: Sat, 13 Apr 2019 11:16:21 +0200
Subject: [openstack-ansible] Documentation of host OS major upgrade
Message-ID: <2057532.kxi6NnfKf9@gillesxps>

Hello,

I'm actually using OpenStack-Ansible to deploy a little public cloud. For now 
it runs on Queens / Ubuntu 16.04.

I've read that Rocky will be the only release supported on both Ubuntu 16.04 
and Ubuntu 18.04 with OpenStack-Ansible.
Stein being out soon (with OpenStack-Ansible), the question of Host OS upgrade 
from Ubuntu 16.04 to ubuntu 18.04 is a big thing of this year.

I've not found any documentation about that upgrade path (Rocky->Stein, host 
OS).
I had some answers on IRC that OpenStack Ansible does not support a mixed 
environnement (adding compute nodes on Ubuntu 18.04 while the rest is on 
Ubuntu 16.04 for example).

Did I miss something in the actual doc or in some blogs ?

I'm sure some users already faced this with transition fro Ubuntu 14.04 to 
Ubuntu 16.04. There's certainly some material to start some documentation and 
add it to https://docs.openstack.org/openstack-ansible/stein/admin/upgrades/
major-upgrades.html.

I know that there's less contributors now, I'll see if I can help.

Thanks.




From noonedeadpunk at ya.ru  Sat Apr 13 10:11:37 2019
From: noonedeadpunk at ya.ru (=?utf-8?B?0KDQsNCx0L7RgtGP0LPQvtCyINCU0LzQuNGC0YDQuNC5?=)
Date: Sat, 13 Apr 2019 13:11:37 +0300
Subject: [openstack-ansible] Documentation of host OS major upgrade
In-Reply-To: <2057532.kxi6NnfKf9@gillesxps>
References: <2057532.kxi6NnfKf9@gillesxps>
Message-ID: <1721861555150297@sas1-46c84f197234.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190413/8420366c/attachment.html>

From gilles.mocellin at nuagelibre.org  Sat Apr 13 17:23:00 2019
From: gilles.mocellin at nuagelibre.org (Gilles Mocellin)
Date: Sat, 13 Apr 2019 19:23:00 +0200
Subject: [openstack-ansible] Documentation of host OS major upgrade
In-Reply-To: <1721861555150297@sas1-46c84f197234.qloud-c.yandex.net>
References: <2057532.kxi6NnfKf9@gillesxps>
 <1721861555150297@sas1-46c84f197234.qloud-c.yandex.net>
Message-ID: <2556083.Mn1VBHQMRC@guitare>

Le samedi 13 avril 2019, 12:11:37 CEST Работягов Дмитрий a écrit :
> Hi Gilles,
>  
> Regarding Xenial - Bionic upgrade - it's a possible upgrade, but it looks
> like more one-by-one re-setup than upgrade, if you wish to upgrade not only
> host OS, but containers as well. First of all you'll need to complete Q->R
> upgrade, after that you'll be able to upgrade Ubuntu.  For instance I've
> completed such upgrade for my deployments, and it was pretty successful.
> We've got some notes regarding such upgrade on
> etherpad:https://etherpad.openstack.org/p/osa-rocky-bionic-upgrade 
> Mixed deployments are supported by OSA as well - you may easily use
> different operating systems in one deployment, you just need wheels and
> packages to be build on the repo-server for this OS.
> -- 
> Kind Regards,
> Dmitriy Rabotyagov

Thank you Dmitry for your notes !

But one question : when you say the wheels need to be rebuild for the OS in 
repo-server, how do we do that, and keep and maintain the two versions ?

Doing a rolling remove/rebuild/re-add for each server seems fine if a mixed OS 
deployment is supported for the hosts OS.

Concerning the LXC OS, is it built based on the host one, or a config 
somewhere ?
Do all the containers need to be the same version ?

Again, it can be fine, but time consuming, if we first need to upgrade all 
hosts, recreating containers in xenial on them until all hosts are upgraded. 
And only after, recreate all containers in bionic.

> As far as I know work
> on upgrade Rocky->Stein is still in progress.

Of course, but it would be great if that sort of documentation is ready when 
OSA Stein is out !

--
Gilles





From noonedeadpunk at ya.ru  Sat Apr 13 18:58:12 2019
From: noonedeadpunk at ya.ru (Dmitriy Rabotjagov)
Date: Sat, 13 Apr 2019 21:58:12 +0300
Subject: [openstack-ansible] Documentation of host OS major upgrade
In-Reply-To: <2556083.Mn1VBHQMRC@guitare>
References: <2057532.kxi6NnfKf9@gillesxps>
 <1721861555150297@sas1-46c84f197234.qloud-c.yandex.net>
 <2556083.Mn1VBHQMRC@guitare>
Message-ID: <3123371555181892@iva4-bd03dd0fc225.qloud-c.yandex.net>

Hi,

You'll need to re-run repo-build.yml playbook once have at least one host running another OS. So repo-server is designed to support different operating systems, and required packages would be built for every OS. You should be able to see such selection inside repo container in /var/www/repo/pools/

LXC OS is based on the host OS, but this might be overrided: https://github.com/openstack/openstack-ansible-lxc_hosts/blob/stable/rocky/defaults/main.yml#L166 Mixed containers are ok as well. And Ubuntu 18.04 on the host supports Ubuntu 16.04 containers, so it's possible to upgrade host and only after that rebuild containers on this node. The only tricky thing is that Ubuntu 18.04 runs lxc 3, while 16.04 is running lxc 2. This migration is covered by Kevin's note inside etherpad, so shouldn't be a big problem.


13.04.2019, 20:28, "Gilles Mocellin" <gilles.mocellin at nuagelibre.org>:
> Le samedi 13 avril 2019, 12:11:37 CEST Работягов Дмитрий a écrit :
>>  Hi Gilles,
>>
>>  Regarding Xenial - Bionic upgrade - it's a possible upgrade, but it looks
>>  like more one-by-one re-setup than upgrade, if you wish to upgrade not only
>>  host OS, but containers as well. First of all you'll need to complete Q->R
>>  upgrade, after that you'll be able to upgrade Ubuntu. For instance I've
>>  completed such upgrade for my deployments, and it was pretty successful.
>>  We've got some notes regarding such upgrade on
>>  etherpad:https://etherpad.openstack.org/p/osa-rocky-bionic-upgrade
>>  Mixed deployments are supported by OSA as well - you may easily use
>>  different operating systems in one deployment, you just need wheels and
>>  packages to be build on the repo-server for this OS.
>>  --
>>  Kind Regards,
>>  Dmitriy Rabotyagov
>
> Thank you Dmitry for your notes !
>
> But one question : when you say the wheels need to be rebuild for the OS in
> repo-server, how do we do that, and keep and maintain the two versions ?
>
> Doing a rolling remove/rebuild/re-add for each server seems fine if a mixed OS
> deployment is supported for the hosts OS.
>
> Concerning the LXC OS, is it built based on the host one, or a config
> somewhere ?
> Do all the containers need to be the same version ?
>
> Again, it can be fine, but time consuming, if we first need to upgrade all
> hosts, recreating containers in xenial on them until all hosts are upgraded.
> And only after, recreate all containers in bionic.
>
>>  As far as I know work
>>  on upgrade Rocky->Stein is still in progress.
>
> Of course, but it would be great if that sort of documentation is ready when
> OSA Stein is out !
>
> --
> Gilles


-- 
Kind Regards,
Dmitriy Rabotjagov


From zigo at debian.org  Sat Apr 13 22:53:47 2019
From: zigo at debian.org (Thomas Goirand)
Date: Sun, 14 Apr 2019 00:53:47 +0200
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
 <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
 <20190412142734.GA3579@sm-workstation>
 <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>
Message-ID: <5256e4f3-9431-efe8-939e-e7887962ee48@debian.org>

On 4/12/19 8:06 PM, Jeremy Stanley wrote:
> On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote:
> [...]
>> Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0].
>> Though Cinder did not get the same enforcement until Rocky [1].
>>
>> [0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
>> [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image-signature-verification.html
>>
>> (And specs are always 100% accurate, right?)
> 
> Neat, I had no idea that had improved in the past few years. At any
> rate, my main point still stands: if you don't trust the operators
> of that environment then the checksums are pure theater, since they
> could disable checksum validation or even just serve you a
> completely fictional hash from the catalog.

If you believe your host is capable of such things, you probably should
go somewhere else.

Cheers,

Thomas Goirand (zigo)


From fungi at yuggoth.org  Sun Apr 14 00:16:02 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sun, 14 Apr 2019 00:16:02 +0000
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <5256e4f3-9431-efe8-939e-e7887962ee48@debian.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
 <20190411232805.73l2ggf3hmhlm3ny@yuggoth.org>
 <6fedf186-9032-e995-303b-8d4f40995c14@debian.org>
 <20190412142734.GA3579@sm-workstation>
 <20190412180641.zqdwlnf62cus4mfg@yuggoth.org>
 <5256e4f3-9431-efe8-939e-e7887962ee48@debian.org>
Message-ID: <20190414001602.fhtzkoooszawqfrk@yuggoth.org>

On 2019-04-14 00:53:47 +0200 (+0200), Thomas Goirand wrote:
> On 4/12/19 8:06 PM, Jeremy Stanley wrote:
> > On 2019-04-12 09:27:35 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> >> Hmm, according to the spec, Nova verifies those checksums as of Mitaka [0].
> >> Though Cinder did not get the same enforcement until Rocky [1].
> >>
> >> [0] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/image-verification.html
> >> [1] https://specs.openstack.org/openstack/cinder-specs/specs/rocky/support-image-signature-verification.html
> >>
> >> (And specs are always 100% accurate, right?)
> > 
> > Neat, I had no idea that had improved in the past few years. At any
> > rate, my main point still stands: if you don't trust the operators
> > of that environment then the checksums are pure theater, since they
> > could disable checksum validation or even just serve you a
> > completely fictional hash from the catalog.
> 
> If you believe your host is capable of such things, you probably
> should go somewhere else.

Yes, that was my point in a nutshell. (Well, s/capable/guilty/ as
all operators are *capable* of making these alterations, but we
mostly expect them to be honest enough not to.) Image checksums
reported by the API are no guarantee, regardless of whether they're
MD5 or SHA2-512. Either you trust your provider hasn't made
alterations or you don't. It's far easier to just fake the checksum
in the API than it is to engineer an MD5 hash collision a la second
preimage attack, so the fact that the MD5 algorithm is considered
cryptographically "weak" these days means very little in this
context.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190414/67034d29/attachment.sig>

From henry at thebonaths.com  Sun Apr 14 02:27:31 2019
From: henry at thebonaths.com (Henry Bonath)
Date: Sat, 13 Apr 2019 22:27:31 -0400
Subject: [neutron][hyperv] Neutron Hyper-V agent - unable to bind port
Message-ID: <CAPQYr8xnOJyQYnhadoUKXaQXrwO-jyv-cJaVfAMfjTRJ-JfQHg@mail.gmail.com>

Hello, I am relatively new to Openstack, and am not sure if
support-type questions are welcome here, but if they are, any help
would be greatly appreciated!


I have a fully working system running Rocky that I built using
Openstack-Ansible on Ubuntu 18.04.
I am using it as a POC to test out for use in my datacenter, which has
a large Hyper-V investment.

I am using the ML2 Linuxbridge agent with my KVM hosts, with VLAN,
VXLAN, and FLAT networking all working great.

While attempting to add some Hyper-V nodes into the mix, all is
working fine, I can provision new Instances from image,
Cinder volumes mount via iSCSI, and they boot up successfully. The
issue is that the Hyper-V virtual switch remains in
a disconnected state, and does not tag a VLAN when it should.
The port state also shows as "down" in the Horizon Web UI or from the
Command line.

On my neutron server containers, I have installed the
"networking-hyperv" driver.
My /etc/neutron/plugins/ml2/ml2_conf.ini file has the following:

[ml2]
extension_drivers = port_security,qos
mechanism_drivers = linuxbridge,hyperv
tenant_network_types = vxlan,flat,vlan
type_drivers = flat,vlan,vxlan,local

Neutron Server Container Logs: ( I think the key line is: Device
fbb9010c-3326-4689-b46c-c3393e43f23b has no active binding in host
None )

2019-04-14 02:10:59.141 805 DEBUG neutron.db.db_base_plugin_common
[req-c40d2349-2ade-4367-a017-181e6644c1fb
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] Allocated IP 172.31.60.62
(7559f5d9-bf1e-431a-b947-af8cc85bcf91/0c59baf1-3880-4b6c-8198-037923ec8cfb/fbb9010c-3326-4689-b46c-c3393e43f23b)
_store_ip_allocation
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:121
2019-04-14 02:10:59.151 805 DEBUG neutron.db.db_base_plugin_common
[req-c40d2349-2ade-4367-a017-181e6644c1fb
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] Allocated IP 2001:470:3ab1:ff3c::11
(7559f5d9-bf1e-431a-b947-af8cc85bcf91/d6704a54-bdd2-4ced-a1c6-ea425e87f772/fbb9010c-3326-4689-b46c-c3393e43f23b)
_store_ip_allocation
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:121
2019-04-14 02:10:59.826 805 DEBUG neutron.db.provisioning_blocks
[req-c40d2349-2ade-4367-a017-181e6644c1fb
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] Transition to ACTIVE for port object
fbb9010c-3326-4689-b46c-c3393e43f23b will not be triggered until
provisioned by entity DHCP. add_provisioning_component
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/provisioning_blocks.py:73
2019-04-14 02:10:59.964 805 DEBUG
neutron.api.rpc.handlers.resources_rpc
[req-c40d2349-2ade-4367-a017-181e6644c1fb
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - -
-] Pushing event updated for resources: {'Port':
['ID=fbb9010c-3326-4689-b46c-c3393e43f23b,revision_number=2']} push
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/api/rpc/handlers/resources_rpc.py:241
2019-04-14 02:11:02.847 1024 INFO neutron.wsgi
[req-f5b3d393-7550-477d-9dac-118149b09680
343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d -
default default] 192.168.41.6,192.168.41.58 "PUT
/v2.0/ports/fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200
 len: 1169 time: 2.3884900
2019-04-14 02:11:03.366 1024 INFO neutron.notifiers.nova [-] Nova
event response: {u'status': u'completed', u'tag':
u'fbb9010c-3326-4689-b46c-c3393e43f23b', u'name': u'network-changed',
u'server_uuid': u'4286e04d-84f7-4e1d-9ad6-d150debafca1', u'code': 200}
2019-04-14 02:11:03.438 788 INFO neutron.wsgi
[req-e491113e-0eec-4688-bbb4-835fa2473c0f
343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d -
default default] 192.168.41.6,192.168.41.58 "GET
/v2.0/floatingips?fixed_ip_address=2001%3A470%3A3ab1%3Aff3c%3A%3A11&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0544460
2019-04-14 02:11:04.616 1024 INFO neutron.wsgi
[req-c3b90556-cd97-40d8-90d5-ac7fbf19247b
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] 192.168.41.151,192.168.41.58 "GET
/v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0501890
2019-04-14 02:11:21.842 1024 INFO neutron.wsgi
[req-b7271e74-bffe-40fc-b7c5-9f50c2496626
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] 192.168.41.151,192.168.41.58 "GET
/v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0771079
2019-04-14 02:11:45.530 790 DEBUG neutron.plugins.ml2.rpc
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Device
fbb9010c-3326-4689-b46c-c3393e43f23b details requested by agent
hyperv_HOST-H with host None get_device_details
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:79
2019-04-14 02:11:45.731 790 DEBUG neutron.plugins.ml2.db
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] For port
fbb9010c-3326-4689-b46c-c3393e43f23b, host HOST-H, got binding levels
[<neutron.plugins.ml2.models.PortBindingLevel[object at 7f505617b910]
{port_id=u'fbb9010c-3326-4689-b46c-c3393e43f23b', host=u'HOST-H',
level=0, driver=u'hyperv',
segment_id=u'598c754b-1b2a-4865-9211-ef3a1e5ed95c'}>]
get_binding_levels
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/db.py:77
2019-04-14 02:11:45.753 790 DEBUG neutron.plugins.ml2.rpc
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Device
fbb9010c-3326-4689-b46c-c3393e43f23b has no active binding in host
None _get_device_details
/openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:133
2019-04-14 02:11:49.538 1024 INFO neutron.wsgi
[req-4213915d-3fee-40ff-8921-439c9ada3a30
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] 192.168.41.151,192.168.41.58 "GET
/v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0534980
2019-04-14 02:12:07.359 788 INFO neutron.wsgi
[req-6d6e94e6-9100-4923-894a-341a9b4be439
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] 192.168.41.151,192.168.41.58 "GET
/v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0527611
2019-04-14 02:12:29.106 789 INFO neutron.wsgi
[req-507d6cf9-a93e-4988-948c-e409dc226de7
202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 -
default default] 192.168.41.151,192.168.41.58 "GET
/v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b
HTTP/1.1" status: 200  len: 212 time: 0.0640750

Neutron Hyper-V Agent Log: ( Key line here is: No port
fbb9010c-3326-4689-b46c-c3393e43f23b defined on agent )

2019-04-13 22:11:02.830 4220 DEBUG
networking_hyperv.neutron.agent.layer2
[req-f5b3d393-7550-477d-9dac-118149b09680
343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - -
-] port_update received: fbb9010c-3326-4689-b46c-c3393e43f23b
port_update C:\Program Files\Cloudbase
Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:436
2019-04-13 22:11:02.846 4220 DEBUG
networking_hyperv.neutron.agent.layer2
[req-f5b3d393-7550-477d-9dac-118149b09680
343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - -
-] No port fbb9010c-3326-4689-b46c-c3393e43f23b defined on agent.
port_update C:\Program Files\Cloudbase
Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:449
2019-04-13 22:11:44.890 4220 INFO
networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added:
fbb9010c-3326-4689-b46c-c3393e43f23b
2019-04-13 22:11:45.530 4220 DEBUG
networking_hyperv.neutron.agent.layer2
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Agent loop has
new devices! _work C:\Program Files\Cloudbase
Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:427
2019-04-13 22:11:45.765 4220 INFO
networking_hyperv.neutron.agent.layer2
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Adding port
fbb9010c-3326-4689-b46c-c3393e43f23b
2019-04-13 22:11:45.765 4220 DEBUG
networking_hyperv.neutron.agent.layer2
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Missing port_id
from device details: fbb9010c-3326-4689-b46c-c3393e43f23b. Details:
{'device': 'fbb9010c-3326-4689-b46c-c3393e43f23b',
'no_active_binding': True} _treat_devices_added C:\Program
Files\Cloudbase
Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:374
2019-04-13 22:11:45.765 4220 DEBUG
networking_hyperv.neutron.agent.layer2
[req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Remove the port
from added ports set, so it doesn't get reprocessed.
_treat_devices_added C:\Program Files\Cloudbase
Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:376


If I happen to "catch" the VM in the Hyper-V console while it's being
provisioned, I can attach the vNIC to the Hyper-V Switch, and check
the box and tag the VLAN and the system will get an IP from the DHCP
Agent, Pull its hostname and ssh key from the Metadata Agent, and
everything else - although Openstack will still have the port status
as "Down"

There's not a lot of info out there on specific nuances of Nova with
Hyper-V, If I need to look into the Open vSwitch Agent, I'm not
opposed to going that direction either.
I also realize that I may need to reach out to Cloudbase directly for
better support.

Thanks for your consideration and support!
-Henry


From ifatafekn at gmail.com  Sun Apr 14 07:14:10 2019
From: ifatafekn at gmail.com (Ifat Afek)
Date: Sun, 14 Apr 2019 10:14:10 +0300
Subject: [Vitrage] Find solution on integrate vitrage to current monitor
In-Reply-To: <1035681035.2586188.1554973454213.JavaMail.zimbra@viettel.com.vn>
References: <1135240140.823214.1554345841979.JavaMail.zimbra@viettel.com.vn>
 <1923699737.906723.1554346789954.JavaMail.zimbra@viettel.com.vn>
 <CALxdkcxJnCsOom_=E8RdEbcKMewGC69ueUHThw4Ho6+cBhb2PQ@mail.gmail.com>
 <1035681035.2586188.1554973454213.JavaMail.zimbra@viettel.com.vn>
Message-ID: <CALxdkczWCTsOE39aY_V1u89T0_dhSu9Vi8vW=J_xiHNmZtRZXQ@mail.gmail.com>

Hi,

Let us know if you have any question, we will be happy to help.

Br,
Ifat


On Fri, Apr 12, 2019 at 4:14 PM <hoanq13 at viettel.com.vn> wrote:

> Hi,
> Now I try write new datasource  kapacitor to vitrage, storyboard :
> https://storyboard.openstack.org/#!/story/2005428
> I will greatly appreciate with your help.
>
>
> ------------------------------
> *From: *ifatafekn at gmail.com
> *To: *hoanq13 at viettel.com.vn, openstack-discuss at lists.openstack.org
> *Sent: *Monday, April 8, 2019 5:54:30 PM
> *Subject: *Re: [Vitrage] Find solution on integrate vitrage to current
> monitor
>
> Hi,
>
> If I understand correctly, InfluxDB is used for storing metrics, but it
> does not handle the logic of when to raise an alarm, so integrating with it
> will not help you. I'm not familiar with any tool that "converts" InfluxDB
> metrics to alarms that are sent to Vitrage.
>
> I think that the only way to integrate your alarms is to write a new
> datasource for Kapacitor, since this specific monitor is not supported yet
> in Vitrage. You can find details on how to write a new datasource here [1].
>
> [1]
> https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html
>
> Best regards,
> Ifat
>
> On Thu, Apr 4, 2019 at 6:00 AM <hoanq13 at viettel.com.vn> wrote:
>
>> Hi,
>>
>> I sent this mail for finding solution when integrate  vitrage to my
>> current monitor system.
>> I my system we use Tick stack monitor: with telegraf is collector metric,
>> influxdb for storing metric, and kapacitor for alarming.
>> It been work for a long while, all our monitor data in influxdb. I'm
>> wondering  have any tool can read influxdb, create alarm so vitrage can get
>> input alarm from it?.
>> Or any ideal you can recommend me on integrate vitrage to my system?
>>
>> p/s: i was think about write datasource driver kapacitor can alarm
>> vitrage, but it take time, and I'm not good at codding.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190414/038bae9d/attachment.html>

From smooney at redhat.com  Sun Apr 14 13:45:17 2019
From: smooney at redhat.com (Sean Mooney)
Date: Sun, 14 Apr 2019 14:45:17 +0100
Subject: how to define a flavor... numa topology and/or cpu pinning?
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017E8A88B8@MXDB1.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017E8A88B8@MXDB1.ad.garvan.unsw.edu.au>
Message-ID: <cc2dd67ba92f1ac59a8bab0eb08a417ebb8899d3.camel@redhat.com>

On Sat, 2019-04-13 at 02:12 +0000, Manuel Sopena Ballesteros wrote:
> Hi,
> 
> considering my hosts have numa architecture.
> 
> what is the difference between "numa topology"
a numa toplogy refers to the topology of your memory contorlers and therefore
effect any operation involving memory acess includeing but not limited to
memroy mapped io to hardware devices such as nics or gpus.

if we say a vm or host has 2 numa node that means that it has two indepenent meoroy controlers.
this is pretty common these these days.  by having multiple memory controlers the total memory of
bandwith of the system is doubled however the distance (the phyical lenght of the copper traces)
between a cpu and a memory contoler or a device and a memory contoler will be differenet
between each of the two memory contolers as the cpu core or device will phycially postioned closer
to one of them. basicly because the speed of light is not infiite if you have more then 1 memory contorler
then acessing different parts of memory will have different latency depening on the memroy adress, the device that is 
doing the access and the contoler that that device is closets and if that contoler is the one that manages that area 
of memory..

so put simply when we are talking about numa we are talking about memory, and when we talk about numa affinity
we are talking about minimising that latency between a device(cpu or mmio device like a nic) and that memeory
by selecting a device who local memory contoler "owns" that memory therefore resulting in the shortest path.


to do this in openstack if you add hw:numa_node=1 we will ensure the cpus and pci passthough devices that are
used by a guest come the same numa node(memory contorler) as the ram for that guest, thereby optimising for
the minium memory latency.

>  and "cpu pinning"? would "cpu pinning" make any difference if "numa topology" is already in place?
cpu pinning can althouth the effect will be less then from enableing a numa toplogy for io intesive workloads.

when you enable cpu pinning in opentack we also create a numa topology of 1 implcitly. you can specify
multiple numa node but as a result you get all the benifts of numa affity automatically when you enable cpu pinning.

we should have kept these seperate but that is the legacy we have today.

where cpu pinning helps is if your workload is compute bound. when you enable a numa afinity in openstack 
we confine the guest cpus to float over the cpus with a numa node that is local to the momory of the guest.
while this  soft pinning results in a perfromance boost for io operattions it dose not imporve cpu bound performacne.

enabling cpu pinning will pin each guest cpu to a host hardware thread and addtionaly prevent oversubciption by other
pinned cpus. i.e. we will never pin to guest vcpus to the same hardawere thread. with numa the guest not only floats
over host cpus but the host cpus can be over subscribed.
> 
> thank you very much
one other think you should look into is the use of huge page memory.
like cpu pinnign enableing hugepages creats an implict numa toplogy of 1 numa node if you do not override
it with hw:numa_nodes. useing hugepage memory for the guest via hw:mem_page_size will futher improve guest
memory intensive workload by miniuming tlb cache misses optimising virtual memory to phyical memory address traslation.
> 
> 
> 
also as i have mentioned in the past notices like the one below raise legal ambigurity of if
they are allowed to be sent to the list. with a strict reading it woudl not allow the mailinglist
to forward the email. i am choosing to read this as all subsribers or the mailing list are the intended
recipients. such disclaimer are almost allway unenforceabel and are effectivly spam so while it is not strictly
against our mailing list etiquette https://wiki.openstack.org/wiki/MailingListEtiquette it is still best avoided.

> NOTICE
> Please consider the environment before printing this email. This message and any attachments are intended for the
> addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended
> recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this
> message in error please notify us at once by return email and then delete both messages. We accept no liability for
> the distribution of viruses or similar in electronic communications. This notice should not be removed.



From smooney at redhat.com  Sun Apr 14 13:56:45 2019
From: smooney at redhat.com (Sean Mooney)
Date: Sun, 14 Apr 2019 14:56:45 +0100
Subject: [CI] nested virtualization support in OpenStack CI
In-Reply-To: <a08f325b79884eb8c4b568822806267a99c3dc0b.camel@redhat.com>
References: <2EE296D083DF2940BF4EBB91D39BB89F40C432B0@SHSMSX104.ccr.corp.intel.com>
 <20190330161446.l65jichjt2ekjubt@yuggoth.org>
 <0fc9cc551829786f3fc6725425741a3f216bd1c0.camel@redhat.com>
 <20190331124317.lzsmthiarnvvsy4l@yuggoth.org>
 <2EE296D083DF2940BF4EBB91D39BB89F40C553E7@SHSMSX104.ccr.corp.intel.com>
 <20190408122116.74lyls3tkudzbye2@yuggoth.org>
 <76aefbde-557f-4dfb-9e61-60644543c726@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C55997@SHSMSX104.ccr.corp.intel.com>
 <c5dbaff0-a148-4db1-927e-108ca33bbc39@www.fastmail.com>
 <2EE296D083DF2940BF4EBB91D39BB89F40C58E67@SHSMSX104.ccr.corp.intel.com>
 <a08f325b79884eb8c4b568822806267a99c3dc0b.camel@redhat.com>
Message-ID: <73bb103fca3422c292f821fe619bf58456735816.camel@redhat.com>


hi just a quick update.
i have created an work in progress nfv job definition that
works without nested virt in this patch.
https://review.openstack.org/#/c/652197/

i will be created a similar tempest-dpdk job before the ptg.

but form my testign using libvirt 5.2 we can now utilise the
qemu MTTCG backend to do hugepage,emulator thread realtime and cpu pinning
in the upstream gate.

i have enabled all of the above in that test job.

ovs-dpdk just needs hugepages to work so ill port my thridparty ovs-dpdk
job to the networking-ovs-dpdk repo in the next week or so and networking-ovn
will be able to inhirti form it or create there own using it as a template.

the main draw back to this approch is that fedroa 29 with the virt preview
repo is the only way to do this in the gate unless we compile libvirt and qemu
from scratch. we have devstack plugins that can do that if we wanted to
create a ubunut/centos based job but form what i can tell the only feature
we cant test that was previously tested by the intel nfv ci using
this setup would be multiple guest numa nodes.

multi numa node guest can only be created by multi numa node host due to restictions
we have in nova. if we want to test that we either need to remvoe that restiction (my perference)
or we need to ask the operators the provide our ci resouce if they would be willing
to kindly create a private flavor that had 2 numa nodes. .e.g hw:numa_nodes=2

regards
sean.



From openstack at medberry.net  Sun Apr 14 14:24:19 2019
From: openstack at medberry.net (David Medberry)
Date: Sun, 14 Apr 2019 08:24:19 -0600
Subject: [ops] Operators Informal Gathering at Summit, Monday night
Message-ID: <CAJhvMStPYo--9Xh-mbVbDt=0FehfLUUbE1DzPPH66qSuh3AyLA@mail.gmail.com>

Hi all,

Typically at large OpenStack events, the Operators try and assemble a
bit more casually to blow off steam and have some 1:1 time. And as the
Open Infrastructure Summit in Denver approaches (aka OpenStack
Summit), we're planning another one.

Monday night, April 29th, the early evening starts with the usual
Marketplace. It runs until 7pm. Consequently, I'm proposing an "after"
gathering at Wynkoop Brewery starting at 7:30pm until whenever.
Wynkoop has a second floor with a number of pool tables and a casual
environment. Many of the Operators met there last fall during the
OpenStack PTG. As more operators will be at the Summit (first half of
the week) we'll have this gathering on Monday instead of later in the
week during the PTG.

Many teams and companies have their own event on Monday evening but it
looks to provide the best opportunity to get the operators together.

This will be a "dutch treat" ie, pay your own bill event as no one is
underwriting it and it is NOT an official Open Infra event. However,
I'd appreciate a reply if you will be able to join the operators.

(Wynkoop Brewing is on the north end and a couple blocks off of the
16th St Mall but the MallRide buses that circulate will get you most
of the way there. It sits 1/2 way between 16th St and Coors Field. The
pool room is upstairs. And although it's a brewery, think of it more
as a brewpub as it has a full bar, not just beers. And of course has a
pub-style food menu as well. More info here:  https://wynkoop.com/ /
Also, it may be the only brewery founded by any of the dozens of
people running for 2020 United States president.)


From gmann at ghanshyammann.com  Sun Apr 14 18:48:25 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Sun, 14 Apr 2019 13:48:25 -0500
Subject: [tc][all] Dropping py35 testing
Message-ID: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>

Hello Everyone,

All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],
we are good to drop the py35 testing. 

Train: Good to drop.
I am going to push the patches to remove the py35 jobs from the master (which is Train now). 

Stable/Stein: Ok to drop if the project wants.
Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.
But backporting all the patches will be too many patches for projects to merge on stable/stein so
we discussed not to propose all of them to stable/stein. If the project really wants to drop it from
stable/stein then, they can backport. 

NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate
the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
[2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
       http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html 

-gmann



From lijie at unitedstack.com  Mon Apr 15 01:34:51 2019
From: lijie at unitedstack.com (=?utf-8?B?UmFtYm8=?=)
Date: Mon, 15 Apr 2019 09:34:51 +0800
Subject: [cinder]db online_data_migrations error in rocky release
Message-ID: <tencent_6F0E58D702791F7A39EA44A1@qq.com>

Hi,all
        
       When we configured backend_host (not host) for cinder-volume HA, then we execute the cli "cinder-manage db online_data_migrations", and we can get the following error: "Error attempting to run shared_targets_online_data_migration: MessagingTimeout: Timed out waiting for a reply to message ID".The problem can be reproduced by deploying cinder-volume with pacemaker.And I have set the backend_host = hostgroup, the "host" is not set.
    The reason of this I found that there will be an rpc call for all service.host. When the service.host is "hostgroup at ssd", because the "hostgroup" host is virtual, so theis is error.

    I have raise this as a bug. Can you tell me more about this? Thank you very much.













Ref:
https://github.com/openstack/cinder/blob/master/cinder/cmd/manage.py#L111

https://bugs.launchpad.net/cinder/+bug/1824509







Best Regards
Rambo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/1996e87d/attachment-0001.html>

From jwoh95 at dcn.ssu.ac.kr  Mon Apr 15 02:44:13 2019
From: jwoh95 at dcn.ssu.ac.kr (Jaewook Oh)
Date: Mon, 15 Apr 2019 11:44:13 +0900
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related things
 after rebooting host
Message-ID: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>

Hello kuryr-kubernetes team,

currently, I deployed openstack with devstack, and I added
"kuryr-kubernetes" to use kubernetes vim.
At first it worked fine and no error was occurred,
so I made some c-vnfs with kuryr-kubernetes.
But after rebooting the host, the systems that worked well before are not
working normally at all.

First, I deployed an example one ('redis') with kubectl command, (Not using
Tacker, but only using kubectl cli)
it showed below error,

Events:

│obeTime":null,"lastTransitionTime":"2019-04-15T02:28:31Z"}],"hostIP":"192.168.1.20","startTime":"2019-04-15T02:28:31Z"
  Type     Reason                  Age    From               Message

 │,"containerStatuses":[{"name":"web-server","state":{"waiting":{"reason":"ContainerCreating"}},"lastState":{},"ready":f
  ----     ------                  ----   ----               -------

 │alse,"restartCount":0,"image":"kyleoh95/iistrc-k8s-demo2:0.4","imageID":""}],"qosClass":"Guaranteed"}}]}
  Normal   Scheduled               2m25s  default-scheduler  Successfully
assigned default/redis-master-6fbbc44567-ms8n│Apr 15 11:36:52 master
tacker-server[1881]:  from (pid=1881) request
/usr/local/lib/python2.7/dist-packages/kubernetes
k to master
                                            │/client/rest.py:219
  Warning  MissingClusterDNS       2m25s  kubelet, master    pod:
"redis-master-6fbbc44567-ms8nk_default(8a6f9079-5f27-│Apr 15 11:36:52
master tacker-server[1881]: 2019-04-15 11:36:52.633 DEBUG
tacker.vnfm.infra_drivers.kubernetes.kuberne
11e9-9b42-a4bf01550f1a)". kubelet does not have ClusterDNS IP configured
and cannot create Pod using "ClusterFirst" pol│tes_driver [-] status:
Pending from (pid=1881) create_wait
/opt/stack/tacker/tacker/vnfm/infra_drivers/kubernetes/kube
icy. Falling back to "Default" policy.
                                           │rnetes_driver.py:137
  Warning  FailedCreatePodSandBox  19s    kubelet, master    Failed create
pod sandbox: rpc error: code = Unknown desc │Apr 15 11:36:52 master
tacker-server[1881]: 2019-04-15 11:36:52.634 DEBUG
tacker.vnfm.infra_drivers.kubernetes.kuberne
= failed to set up sandbox container
"310e18b859e118ad6abcaa60d29a9e332da516ce57b8cdf47456ea4882ca66f5" network
for pod│tes_driver [-] VNF initializing status: ['default',
'svc-vdu1-b9e851'] Pending from (pid=1881) create_wait /opt/stack/
 "redis-master-6fbbc44567-ms8nk": NetworkPlugin cni failed to set up pod
"redis-master-6fbbc44567-ms8nk_default"
networ│tacker/tacker/vnfm/infra_drivers/kubernetes/kubernetes_driver.py:141
k: Got invalid status code from CNI daemon.; Traceback (most recent call
last):                                        │Apr 15 11:36:52 master
tacker-server[1881]: 2019-04-15 11:36:52.634 WARNING
tacker.vnfm.infra_drivers.kubernetes.kuber
  File "/opt/stack/kuryr-kubernetes/kuryr_kubernetes/cni/api.py", line 80,
in run                                      │netes_driver [-] VNF Creation
failed: Resource creation is not completed within 500 seconds as creation
of stack defau
    vif = self._add(params)


Are there any reason for this error? And how can I resolve this problem?

Best Regards,
Jaewook.

================================================
*Jaewook Oh* (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea
Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
E-mail : jwoh95 at dcn.ssu.ac.kr
================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/af995be4/attachment.html>

From ralf.teckelmann at bertelsmann.de  Mon Apr 15 07:27:21 2019
From: ralf.teckelmann at bertelsmann.de (Teckelmann, Ralf, NMU-OIP)
Date: Mon, 15 Apr 2019 07:27:21 +0000
Subject: OpenStack Newton MessagingTimeouts for os-getVNCConsole
In-Reply-To: <AM6PR04MB4711661696592F5F37357FBD89500@AM6PR04MB4711.eurprd04.prod.outlook.com>
References: <AM6PR04MB4711F9E88C93A6F66F270F2689500@AM6PR04MB4711.eurprd04.prod.outlook.com>
 <AM6PR04MB4711661696592F5F37357FBD89500@AM6PR04MB4711.eurprd04.prod.outlook.com>
Message-ID: <AM6PR04MB4711D1A2E33C20BF4BB0E050892B0@AM6PR04MB4711.eurprd04.prod.outlook.com>

Hello everyone,

My colleagues and I are maintaining a newton-based openstack installation.
We use linux containers on ubuntu 16.04 nodes for service separation and HA.
After switiching to HTTPS + Domain for all our Endpoints (was http and IP-based before) we face the problem of MessagingTimeout for os-getVNCConsole-Requests.

In (1) you can find the Stack Trace we get on a request for VNCConsole Access.
We have traced this down to the point were we actually tcpdumped the communication and we can see the response message arriving back(2).

The timeline looks like:

- 13:37:22 GMT        - Sending request via nova get-vnc-console a29f9b95-055e-4f30-8a30-ac0bcde32dd1 novnc
- xx:xx:xx                  - Arrival at RabbitMQ
- 14:37:22.806 CET  - Compute Hosts gets the request
- 14:37:22.810 CET  - Compute Hosts sends response to RabbitMQ
- xx:xx:xx                  - Response enters RabbitMQ
- 14:37:22.812 CET  - tcpdumped response at the interface of the control node where the nova cloud controller resides on, who send the request
- 13:38:22.826 UTC  - Timeout /var/log/nova/nova-api-os-compute.log

It could be expected, that the response messages actually arrives at the requesting process.
However, I can not narrow it down to exactly this point, because
- I can't tcpdump in an lxd container
- The system is highly productive and possibilities for debugging are limited
- We have no other problems with this installation in any matter, so a global problem can be excluded

We are actually not sure if the mismatch in timezones acutally leads to a problem.
The fact, that our problem is isolated and all other communication runs fine makes us believe it's not.

Taking the returned "access_url" from the sniffed package(2) and e.g. pasting it to a browser, we get the Standard VNC Console Screen.
This shows the general communication via port 6080 is also possible.
Nonetheless, even doing the as soon as the package was sniffed I never got an actual novnc-session to the VM.

We are stuck at this point, because we simply can't completely understand the python code :(
I hope you can ask some helping questions to get us a step further.

You can find a list of our current dpkg and pip packages in (3).

Questions we are currently able formulate are:
- Is there any communication taking place besides the regular ports (8774, 6080, 5672) in the process?
- are the generated access_urls verified in any way after receiving the response message from RabbitMQ, which could lead to an exception being thrown?
- are we looking at the right communication flow (https://docs.openstack.org/nova/pike/_images/SCH_5009_V00_NUAC-VNC_OpenStack.png, there is no one for newton!?) at all?

Best regards

Ralf Teckelmann

(1)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions Traceback (most recent call last):
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 338, in wrapped
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return f(*args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in wrapper
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return func(*args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/remote_consoles.py", line 56, in get_vnc_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions console_type)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 157, in wrapped
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 3283, in get_vnc_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions access_url=connect_info['access_url'])
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/consoleauth/rpcapi.py", line 89, in authorize_console
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return cctxt.call(ctxt, 'authorize_console', **msg_args)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 169, in call
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=self.retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 97, in _send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions timeout=timeout, retry=retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 464, in send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=retry)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 453, in _send
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions result = self._waiter.wait(msg_id, timeout)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in wait
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions message = self.waiters.get(msg_id, timeout=timeout)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 238, in get
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions 'to message ID %s' % msg_id)
2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions MessagingTimeout: Timed out waiting for a reply to message ID bd66ed7b4fe44f5c8527573081379639

(2) IP addresses are obfuscate in order to meet company regulation
2019-03-29 14:37:22.812563 IP (tos 0x0, ttl 64, id 36768, offset 0, flags [DF], proto TCP (6), length 662)
 x.31.129.217.5672 > x.31.129.206.45604: Flags [P.], cksum 0x83a3 (correct), seq 959640600:959641210, ack 3516429040, win 243, options [nop,nop,TS val 3070303066 ecr 3070033633], length 610
E..... at .@.L..........(.$92....r<mailto:E..... at .@.L..........(.$92....r>............
...Z..........].<.<.1.......N.&reply_d5cb71955a3a4a39b1e8f6539a72be4f&reply_d5cb71955a3a4a39b1e8f6539a72be4f.......+.<.............application/json.utf-8..............{"oslo.message": "{\"_msg_id\": \"ae4ea417e79c43af9d1cd2d603b32076\", \"failure\": null, \"_unique_id\": \"e357642aaef34d1fbaa4d240c405d572\", \"result\": {\"internal_access_path\": null, \"host\": \"x.31.129.164\", \"access_url\": \"https://api.secret.cloud:6080/vnc_auto.html?token=44b7d9be-2aab-4239-914c-971d615fa9c0\", \"token\": \"44b7d9be-2aab-4239-914c-971d615fa9c0\", \"port\": \"5912\"}, \"ending\": true}", "oslo.version": "2.0"}.

(3)
:~# dpkg -l | grep amqp
ii  python-amqp                      1.4.9-1                                    all          Low-level AMQP client

:~# dpkg -l | grep oslo.messaging
ii  python-oslo.messaging            5.10.0-0ubuntu2~cloud0                     all          oslo messaging library - Python 2.x

:~# dpkg -l | grep nova
ii  nova-api-os-compute              2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - OpenStack Compute API frontend
ii  nova-cert                        2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - certificate management
ii  nova-common                      2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - common files
ii  nova-conductor                   2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - conductor service
ii  nova-consoleauth                 2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - Console Authenticator
ii  nova-novncproxy                  2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - NoVNC proxy
ii  nova-scheduler                   2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute - virtual machine scheduler
ii  python-nova                      2:14.1.0-0ubuntu1~cloud0                   all          OpenStack Compute Python libraries
ii  python-novaclient                2:6.0.0-0ubuntu1~cloud0                    all          client library for OpenStack Compute API - Python 2.7

:~# pip list | grep amqp
amqp (1.4.9)

:~# pip list | grep oslo
oslo.cache (1.14.0)
oslo.concurrency (3.14.0)
oslo.config (3.17.0)
oslo.context (2.9.0)
oslo.db (4.13.3)
oslo.i18n (3.9.0)
oslo.log (3.16.0)
oslo.messaging (5.10.0)
oslo.middleware (3.19.0)
oslo.policy (1.14.0)
oslo.privsep (1.13.0)
oslo.reports (1.14.0)
oslo.rootwrap (5.1.0)
oslo.serialization (2.13.0)
oslo.service (1.16.0)
oslo.utils (3.16.0)
oslo.versionedobjects (1.17.0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/fb59e315/attachment-0001.html>

From mdulko at redhat.com  Mon Apr 15 07:54:28 2019
From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko)
Date: Mon, 15 Apr 2019 09:54:28 +0200
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
Message-ID: <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>

On Mon, 2019-04-15 at 11:44 +0900, Jaewook Oh wrote:
> Hello kuryr-kubernetes team,
> 
> currently, I deployed openstack with devstack, and I added "kuryr-kubernetes" to use kubernetes vim.
> At first it worked fine and no error was occurred,
> so I made some c-vnfs with kuryr-kubernetes.
> But after rebooting the host, the systems that worked well before are not working normally at all.
> 
> First, I deployed an example one ('redis') with kubectl command, (Not using Tacker, but only using kubectl cli)
> it showed below error,
> 
> Events:                                                                                                                │obeTime":null,"lastTransitionTime":"2019-04-15T02:28:31Z"}],"hostIP":"192.168.1.20","startTime":"2019-04-15T02:28:31Z"
>   Type     Reason                  Age    From               Message                                                   │,"containerStatuses":[{"name":"web-server","state":{"waiting":{"reason":"ContainerCreating"}},"lastState":{},"ready":f
>   ----     ------                  ----   ----               -------                                                   │alse,"restartCount":0,"image":"kyleoh95/iistrc-k8s-demo2:0.4","imageID":""}],"qosClass":"Guaranteed"}}]}
>   Normal   Scheduled               2m25s  default-scheduler  Successfully assigned default/redis-master-6fbbc44567-ms8n│Apr 15 11:36:52 master tacker-server[1881]:  from (pid=1881) request /usr/local/lib/python2.7/dist-packages/kubernetes
> k to master                                                                                                            │/client/rest.py:219
>   Warning  MissingClusterDNS       2m25s  kubelet, master    pod: "redis-master-6fbbc44567-ms8nk_default(8a6f9079-5f27-│Apr 15 11:36:52 master tacker-server[1881]: 2019-04-15 11:36:52.633 DEBUG tacker.vnfm.infra_drivers.kubernetes.kuberne
> 11e9-9b42-a4bf01550f1a)". kubelet does not have ClusterDNS IP configured and cannot create Pod using "ClusterFirst" pol│tes_driver [-] status: Pending from (pid=1881) create_wait /opt/stack/tacker/tacker/vnfm/infra_drivers/kubernetes/kube
> icy. Falling back to "Default" policy.                                                                                 │rnetes_driver.py:137
>   Warning  FailedCreatePodSandBox  19s    kubelet, master    Failed create pod sandbox: rpc error: code = Unknown desc │Apr 15 11:36:52 master tacker-server[1881]: 2019-04-15 11:36:52.634 DEBUG tacker.vnfm.infra_drivers.kubernetes.kuberne
> = failed to set up sandbox container "310e18b859e118ad6abcaa60d29a9e332da516ce57b8cdf47456ea4882ca66f5" network for pod│tes_driver [-] VNF initializing status: ['default', 'svc-vdu1-b9e851'] Pending from (pid=1881) create_wait /opt/stack/
>  "redis-master-6fbbc44567-ms8nk": NetworkPlugin cni failed to set up pod "redis-master-6fbbc44567-ms8nk_default" networ│tacker/tacker/vnfm/infra_drivers/kubernetes/kubernetes_driver.py:141
> k: Got invalid status code from CNI daemon.; Traceback (most recent call last):                                        │Apr 15 11:36:52 master tacker-server[1881]: 2019-04-15 11:36:52.634 WARNING tacker.vnfm.infra_drivers.kubernetes.kuber
>   File "/opt/stack/kuryr-kubernetes/kuryr_kubernetes/cni/api.py", line 80, in run                                      │netes_driver [-] VNF Creation failed: Resource creation is not completed within 500 seconds as creation of stack defau
>     vif = self._add(params)

"Got invalid status code from CNI daemon" means that you should take a
look at kuryr-cni pods logs.

> 
> Are there any reason for this error? And how can I resolve this problem?

In general I'm pretty sure DevStack is not designed to be rebootable,
so it's probably some ip route being gone or some service that haven't
restarted. If you really want to debug this instead of firing a new
DevStack, start from checking all "devstack@*" services in systemd.

> Best Regards,
> Jaewook.
> ================================================
> Jaewook Oh (오재욱)
> IISTRC - Internet Infra System Technology Research Center
> 369 Sangdo-ro, Dongjak-gu,
> 06978, Seoul, Republic of Korea
> Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
> E-mail : jwoh95 at dcn.ssu.ac.kr
> ================================================




From frickler at offenerstapel.de  Mon Apr 15 08:09:30 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Mon, 15 Apr 2019 08:09:30 +0000
Subject: [chef] Renaming the Chef OpenStack project
In-Reply-To: <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
References: <1554724565.4997.26.camel@offenerstapel.de>
 <CAEs876hLgoqzNZ8qzpiMyRiTd2X2QcU+Vo+O4wMgYpqwjnf8dg@mail.gmail.com>
Message-ID: <1555315770.4997.35.camel@offenerstapel.de>

On Fri, 2019-04-12 at 10:56 -0400, Mohammed Naser wrote:
> On Mon, Apr 8, 2019 at 7:58 AM Jens Harbott <frickler at offenerstapel.d
> e> wrote:
> > 
> > In order to clean up some inconsistencies in project naming I have
> > submitted a request to the TC to update the name of the Chef
> > OpenStack
> > project to "openstack-chef"[0]. The reasoning for this is twofold:
> > 
> >     a) It brings the name into line with other deployment projects
> >        like "OpenStack Ansible" and "OpenStack Charms".
> >     b) In addition there are sometimes drawbacks when there is an
> >        embedded space in the name, so I opted for the hyphenated
> >        version. Together with lowercasing everything this also has
> > the
> >        effect to match:
> >             - The name of our central repository
> >             - The name of our IRC channel
> >             - Our project name on Launchpad
> > 
> > Please let me know whether you agree with this change or if there
> > are
> > any objections.
> 
> I don't think I have too much of a problem with it but I can think of
> a few consumers
> who might want to mention if they're broken which are
> 
> - openstack-map / OSF website

I did a patch[1] for that, which has already been merged and the map
has been updated accordingly [2].

> - release team

Tony has answered this one.

> - stackalytics(?)

I think our team doesn't care much about stackalytics at this point.

Jens

[1] https://review.openstack.org/645196
[2] https://www.openstack.org/assets/software/projectmap/openstack-map.
pdf


From balazs.gibizer at ericsson.com  Mon Apr 15 08:14:28 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Mon, 15 Apr 2019 08:14:28 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <284bb8f5-34cf-c07e-9921-3487074ffa32@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
 <1554986561.23392.2@smtp.office365.com>
 <284bb8f5-34cf-c07e-9921-3487074ffa32@fried.cc>
Message-ID: <1555316055.23392.7@smtp.office365.com>



On Thu, Apr 11, 2019 at 8:01 PM, Eric Fried <openstack at fried.cc> wrote:
>>  Then we need two steps:
>>  1) handle RPs that only have traits but not resources
>>  2) allow having the numbered request groups specify only a trait
>>  without requesting resources.
> 
> Nothing stops me from traiting an inventoryless provider today, right?

Does GET /allocation_candidates query handles them properly?

> 
> Do we actually need to involve numbered request groups? Does a concept
> of required_in_tree=$trait_list satisfy the requirements?

I don't know. I guess I have to read required_in_tree=$trait_list spec. 
Please ignore me.

cheers,
gibi

> 
> efried
> .
> 



From dmellado at redhat.com  Mon Apr 15 08:18:46 2019
From: dmellado at redhat.com (Daniel Mellado Area)
Date: Mon, 15 Apr 2019 10:18:46 +0200
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
 <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
Message-ID: <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>

Overall and besides of what Michal said, yeah, openstack hasn't been
designed to be rebootable.
A looong time ago and before the migration to systemd services there was a
script that restarted the screen instances [1]

That said, not there since 2016 so please restack whenever you reboot. In
any case, was there any reason for rebooting?
I'd check if just restarting service would be enough for you.

Thanks!

[1]
https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=9ba49cd82631ada84b8458b370ac535985d57725

On Mon, Apr 15, 2019 at 9:58 AM Michał Dulko <mdulko at redhat.com> wrote:

> On Mon, 2019-04-15 at 11:44 +0900, Jaewook Oh wrote:
> > Hello kuryr-kubernetes team,
> >
> > currently, I deployed openstack with devstack, and I added
> "kuryr-kubernetes" to use kubernetes vim.
> > At first it worked fine and no error was occurred,
> > so I made some c-vnfs with kuryr-kubernetes.
> > But after rebooting the host, the systems that worked well before are
> not working normally at all.
> >
> > First, I deployed an example one ('redis') with kubectl command, (Not
> using Tacker, but only using kubectl cli)
> > it showed below error,
> >
> > Events:
>
> │obeTime":null,"lastTransitionTime":"2019-04-15T02:28:31Z"}],"hostIP":"192.168.1.20","startTime":"2019-04-15T02:28:31Z"
> >   Type     Reason                  Age    From               Message
>
>  │,"containerStatuses":[{"name":"web-server","state":{"waiting":{"reason":"ContainerCreating"}},"lastState":{},"ready":f
> >   ----     ------                  ----   ----               -------
>
>  │alse,"restartCount":0,"image":"kyleoh95/iistrc-k8s-demo2:0.4","imageID":""}],"qosClass":"Guaranteed"}}]}
> >   Normal   Scheduled               2m25s  default-scheduler
> Successfully assigned default/redis-master-6fbbc44567-ms8n│Apr 15 11:36:52
> master tacker-server[1881]:  from (pid=1881) request
> /usr/local/lib/python2.7/dist-packages/kubernetes
> > k to master
>                                               │/client/rest.py:219
> >   Warning  MissingClusterDNS       2m25s  kubelet, master    pod:
> "redis-master-6fbbc44567-ms8nk_default(8a6f9079-5f27-│Apr 15 11:36:52
> master tacker-server[1881]: 2019-04-15 11:36:52.633 DEBUG
> tacker.vnfm.infra_drivers.kubernetes.kuberne
> > 11e9-9b42-a4bf01550f1a)". kubelet does not have ClusterDNS IP configured
> and cannot create Pod using "ClusterFirst" pol│tes_driver [-] status:
> Pending from (pid=1881) create_wait
> /opt/stack/tacker/tacker/vnfm/infra_drivers/kubernetes/kube
> > icy. Falling back to "Default" policy.
>                                                │rnetes_driver.py:137
> >   Warning  FailedCreatePodSandBox  19s    kubelet, master    Failed
> create pod sandbox: rpc error: code = Unknown desc │Apr 15 11:36:52 master
> tacker-server[1881]: 2019-04-15 11:36:52.634 DEBUG
> tacker.vnfm.infra_drivers.kubernetes.kuberne
> > = failed to set up sandbox container
> "310e18b859e118ad6abcaa60d29a9e332da516ce57b8cdf47456ea4882ca66f5" network
> for pod│tes_driver [-] VNF initializing status: ['default',
> 'svc-vdu1-b9e851'] Pending from (pid=1881) create_wait /opt/stack/
> >  "redis-master-6fbbc44567-ms8nk": NetworkPlugin cni failed to set up pod
> "redis-master-6fbbc44567-ms8nk_default"
> networ│tacker/tacker/vnfm/infra_drivers/kubernetes/kubernetes_driver.py:141
> > k: Got invalid status code from CNI daemon.; Traceback (most recent call
> last):                                        │Apr 15 11:36:52 master
> tacker-server[1881]: 2019-04-15 11:36:52.634 WARNING
> tacker.vnfm.infra_drivers.kubernetes.kuber
> >   File "/opt/stack/kuryr-kubernetes/kuryr_kubernetes/cni/api.py", line
> 80, in run                                      │netes_driver [-] VNF
> Creation failed: Resource creation is not completed within 500 seconds as
> creation of stack defau
> >     vif = self._add(params)
>
> "Got invalid status code from CNI daemon" means that you should take a
> look at kuryr-cni pods logs.
>
> >
> > Are there any reason for this error? And how can I resolve this problem?
>
> In general I'm pretty sure DevStack is not designed to be rebootable,
> so it's probably some ip route being gone or some service that haven't
> restarted. If you really want to debug this instead of firing a new
> DevStack, start from checking all "devstack@*" services in systemd.
>
> > Best Regards,
> > Jaewook.
> > ================================================
> > Jaewook Oh (오재욱)
> > IISTRC - Internet Infra System Technology Research Center
> > 369 Sangdo-ro, Dongjak-gu,
> > 06978, Seoul, Republic of Korea
> > Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
> > E-mail : jwoh95 at dcn.ssu.ac.kr
> > ================================================
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/3fc6f24d/attachment-0001.html>

From dtantsur at redhat.com  Mon Apr 15 08:45:19 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 15 Apr 2019 10:45:19 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <alpine.OSX.2.21.1904101236520.12309@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <alpine.OSX.2.21.1904101104090.10085@cdent-a01.vmware.com>
 <593983e7-f1b3-0637-7e81-68918ed643f2@redhat.com>
 <alpine.OSX.2.21.1904101224540.10085@cdent-a01.vmware.com>
 <0ef646d1-abaf-e820-6260-d8a6decdb1e7@redhat.com>
 <alpine.OSX.2.21.1904101236520.12309@cdent-a01.vmware.com>
Message-ID: <3358d9bb-8a73-d53b-1de7-bbcaf63ad507@redhat.com>

On 4/10/19 1:51 PM, Chris Dent wrote:
> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
> 
>> On 4/10/19 1:25 PM, Chris Dent wrote:
>>> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
>>>> We would rather have ironic aware that some nodes are reserved for internal 
>>>> bookkeeping.
>>>
>>> Could you query placement for that "bookkeeping"? That's what
>>> placement does.
>>>
>>
>> It means replacing a short database query with a call to a remote resource 
>> with all the associated performance and reliability penalties. Also if someone 
>> creates an allocation in Placement directly, we won't have an associated 
>> ironic allocation, which is fine, but may be confusing for users. E.g. they 
>> see a free node in ironic, but it's actually occupied in Placement.
> 
> This gets at some of the general concepts of "how best to use
> placement" which are still emerging and evolving and one of the
> reasons why I think these threads are useful: We can spend some time
> reflecting on that kind of big topic without feeling like it is
> wasting precious PTG time.

++ and enable more people to participate as well.

> 
>  From what I've been able to discern with the various ways I've used
> placement, it works most easily and effectively when you allow it to
> be the single source of truth for inventory and use of that
> inventory [1]. This suggests that if you want to optionally use
> placement with ironic, then having placement be a one of several
> possible backends to the ironic bookkeeping system might be worth
> considering.

I'm totally okay with it, but it will need many internal changes to ironic, 
including calling to Placement for some popular API calls. I'll try to explain 
the background a bit better now:

Ironic has a notion of instance_uuid. It use to mean "Nova server ID", but now 
is used more freely. We don't impose any restrictions on its value, except that 
it must be a UUID.

Now, an important property of instance_uuid is that it enables cooperative 
locking. It is implemented by making it possible to assign and unset 
instance_uuid, but not change it. So if you're doing

$ openstack baremetal node set --instance-uuid <UUID> <node>

and it succeeds, you know that the <node> is now "reserved" for allocation, 
instance or whatever designated by <UUID>. Fairly primitive, but works. Now, the 
challenge is that we must make sure it works no matter what we invent, because 
it's a critical part of Bare Metal API contract.

Now, instance_uuid is not a scheduler. We've built an API that can find a node 
by resource_class and traits:

$ openstack baremetal allocation create --resource-class baremetal-large --trait 
CUSTOM_OPENCV

You could argue that we should have gone with Placement instead, and you would 
probably be right. But see below about resistance to add and maintain new 
services, and blah-blah. Also the Placement split was in its early phases, and a 
solution was long overdue. My thought was that we could optionally integrate 
with Placement as a backend instead. Anyway, this is a bit of a side discussion.

What I'm worried about is compatibility with the old case of

$ openstack baremetal node set --instance-uuid <UUID> <node>

and listing free nodes with

$ openstack baremetal node list --unassociated

(which ends up filtering by instance_uuid=NULL).

Our allocation API handles it by setting node.instance_uuid = allocation.uuid in 
the same atomic fashion. Thus, it can co-operate with older code, as well as 
Nova (which also does this trick, although after going to Placement first).

If we tell users to go through Placement for reservation, we need to provide 
synchronization between Ironic and Placement somehow, so that

$ openstack baremetal node list --unassociated

does not yield unpredictable results and

$ openstack baremetal node set --instance-uuid <UUID> <node>

ends up checking for a Placement allocation for this node.

> 
> That said, I'm not sure placement is expensive or risky enough to
> not just use (solely) it. Yes, it is another http service and
> database but it is super lightweight; easy to install, scale and
> manage. If the http service is multi-homed, then there are pretty
> much the same network partitioning issues (for talking to the
> database) with or without a placement. You could easily choose to
> co-locate the placement service (web and database) on the same
> host(s) as Ironic.

Resistance to add new services to a standalone deployment can be borderline 
religious at times :(

> 
> Note, I'm not trying to twist your arm anything here, just present
> options. I recognize that achieving a standalone ironic and then
> going and adding a placement to it feels like a step backwards. It
> might help to think of placement as a library that happens to be
> packaged as an HTTP microservice.
> 
> [1] Which, if you're going to have N less than many sources of
> truth, it may as well be _one_ to avoid synchronization problems.
> Before placement came along I thought (and sometimes still do) that
> having a thing which _represents_ a view of the truth (about
> inventory) as placement does is overkill if it is possible for
> things themselves to represent their own truth, and be event/pubsub
> driven about their willingness to accept a workload (instead of
> being told by some authority).
> 



From dtantsur at redhat.com  Mon Apr 15 08:50:19 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 15 Apr 2019 10:50:19 +0200
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <CA+ny2sz6bFVHzZ6ztQtGndGinXp5VVj0FzoTw-iPzFs9-iebwQ@mail.gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
 <c0cea172-de48-71c6-83e4-e28486e484f2@redhat.com>
 <CA+ny2sz6bFVHzZ6ztQtGndGinXp5VVj0FzoTw-iPzFs9-iebwQ@mail.gmail.com>
Message-ID: <5fb19ea9-f6d4-72de-ff9a-0f3cb1bd3a0e@redhat.com>

On 4/12/19 7:02 PM, Pierre Riteau wrote:
> On Wed, 10 Apr 2019 at 12:16, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>
>> On 4/10/19 12:14 PM, Jay Pipes wrote:
>>> On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
>>>> On 4/9/19 7:20 PM, Jay Pipes wrote:
>>>>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>>>>>>   From ironic perspective there is no issue, but there is a critical question
>>>>>> to decide: when Ironic+Placement is used, which of them acts as the final
>>>>>> authority? If Ironic, then we need to teach Placement to talk to its
>>>>>> Allocation API when allocating a bare metal node. If Placement, then we need
>>>>>> to support Allocation API talking to Placement. I suspect the latter is
>>>>>> saner, but I'd like to hear more opinions.
>>>>>
>>>>> Ironic (scheduler?) would request candidates from the placement service using
>>>>> the GET /allocation_candidates API. Ironic (scheduler?) would then claim the
>>>>> resources on a provider (a baremetal node) by calling the POST /allocations API.
>>>>
>>>> Okay, this matches my expectation.
>>>>
>>>> My concern will be with Blazar and reservations. If reservations happen
>>>> through Placement only, how will ironic know about them? I guess we need to
>>>> teach Blazar to talk to Ironic, which in turn will talk to Placement.
>>>
>>> Hmm. So, here's the problem: placement has no concept of time. [1]
>>>
>>> Placement only knows about one period of time: now. Placement doesn't have any
>>> concept of an allocation or an inventory existing at some point in the future or
>>> in the past.
>>>
>>> Therefore, Blazar must unfortunately keep all of the temporal state about
>>> reservations in its own data store. So, Ironic would actually have to talk to
>>> Blazar to create a reservation of some amount of resources and Blazar will need
>>> to call Placement to manage the state of resource inventory and allocations over
>>> time; as reservations are activated, Blazar will either create or swap
>>> allocation records in Placement to consume the Ironic resources for a tenant
>>> that made the reservation.
>>
>> I imagined it a bit differently. I assumed that
>> 1. a user (operator?) talks to Blazar to create a bare metal node reservation.
>> 1.1. some kind of quota is checked? does Blazar have any notion of quota?
>> 2. Blazar talks to Ironic to create an allocation (yes, we also call it
>> allocation, feel free to blame me)
>> 3. Ironic gets a reservation from Placement and updates its internal records
>> 4. Ironic returns an allocation to Blazar
>> 5. Blazar returns a reservation to a user
>>
>> And when a reservation in Blazar expires or is returned:
>> 6. Blazar talks to Ironic to undeploy the node
>> 6.1. Ironic deletes its allocation automatically
>> 6.2. And thus notifies Placement to remove its allocation
>>
>> Am I missing something?
> 
> If we follow the current model used with Nova and now also with
> Neutron, Blazar would be directly aware of all Ironic nodes (we store
> a copy of the essential resource information in the Blazar database).
> It would use it to make its own resource allocation decisions for
> future reservations. On reservation start, it could call Ironic to
> create an allocation on the node with `candidate_nodes` and provide it
> to the reservation's owner for deployment.
> 
> However, is there a way to prevent anyone but the reservation's owner
> from using the corresponding Ironic allocation? From looking at the
> API doc, I couldn't really see any enforcement of Ironic allocations
> being done.

There is no enforcement currently, it's cooperative. We're going to discuss 
Ironic multi-tenancy at the Forum 
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23668/ironic-multi-tenancy-and-hardware-leasing 
and later at the PTG, and this is probably going to be they key question.

One way we could solve it is to create a new Deployment API in ironic (we have 
been thinking about it for long time), and create more fine-grained policies for 
who can use it and how. For example, disallow changing nodes, allow deployment 
API, but only for previously allocated nodes.

This will need some notion of an owner for an allocation or to dynamically 
change the owner field of a node.

> 
> I am not sure how placement fits into this. If Ironic starts using
> placement for its allocation API, as it is mentioned in
> https://storyboard.openstack.org/#!/story/2004341, we would figure out
> a way for Blazar to put a hold on reservable nodes, so that users
> allocating directly with Ironic could only request from a
> non-reservable pool of nodes. Blazar would create Ironic allocation on
> behalf of users as described above. The question of allocation
> enforcement is also critical in this scenario.

We probably need to work on a story of integrating the "owner" field with the 
allocation API. This is something I'm hoping to define and implement in Train 
with your input.

> 
> PS: Blazar doesn't handle any quota yet. It's a major flaw so we'll
> need to tackle it soon. I am hoping we'll be able to leverage unified
> limits for this.
> 



From dtantsur at redhat.com  Mon Apr 15 09:09:30 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 15 Apr 2019 11:09:30 +0200
Subject: [placement][ironic][blazar][ptg] "direct baremetal reservations"
 with ironic+blazar
In-Reply-To: <alpine.OSX.2.11.1904111324330.33106@seed.local>
References: <alpine.OSX.2.21.1904091246530.93787@cdent-a01.vmware.com>
 <7c73651f-d878-a784-ae84-79486919bc24@redhat.com>
 <CAF7gwdickZGtJ_jELqX3pToiUz+P_E1a28Y6FJN8y7qox4E6Qg@mail.gmail.com>
 <alpine.OSX.2.11.1904111324330.33106@seed.local>
Message-ID: <b54bfe76-b66a-9697-59cc-e49c3d29d7d6@redhat.com>

On 4/11/19 2:37 PM, Chris Dent wrote:
> On Wed, 10 Apr 2019, Julia Kreger wrote:
>> On Tue, Apr 9, 2019 at 9:58 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>> On 4/9/19 1:56 PM, Chris Dent wrote:
>>>>
>>>> The etherpad [1] doesn't have any additional notes besides the topic
>>>> but the general questions are:
>>>>
>>>> * Do people want to do baremetal reservations with some combination
>>>>    of Ironic, Placement and Blazar, now or ever?
>>>
>>> There was at least one person at the Berlin Ops meetup who wanted this.
>>
>> Neat, I've spoken to a few US based operators that are also interested
>> in this. Perhaps it we should allocate some time to the topic? It is
>> looking like there is some time for Saturday to enable smaller groups
>> of contributors to have focused area specific discussions.
> 
> There are plans for Saturday morning, but we've also got this
> virtual pre-ptg [1] thing going on so we can get on the same page
> before then, and even get rid of some pages that we resolve.
> 
> So if people have thoughts about ironic+placement, or
> ironic+blazar+placement it would be great to talk about them in
> some of the email threads that have started (this one and [2]).
> 
> How about we say "start of day Saturday" is placement+ironic+blazar
> in the placement room?

Works for me.

> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004225.html
> [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004729.html
> 



From james.page at canonical.com  Mon Apr 15 09:22:53 2019
From: james.page at canonical.com (James Page)
Date: Mon, 15 Apr 2019 10:22:53 +0100
Subject: [sig][upgrades] IRC meeting minutes 15th April 2019 @ 0900 UTC
Message-ID: <CAG1bqQroyRTzXbXjttCd1ja-J5ApVAt3kxZvXHU0jnXjJfFxDg@mail.gmail.com>

Hi All

Minutes from this mornings Upgrades SIG meeting:

http://eavesdrop.openstack.org/meetings/upgrades_sig/2019/upgrades_sig.2019-04-15-09.03.html

One question was asked about longer term running of mixed version clouds,
which although not ideal might be a reality due to management of change
slots for upgrades etc...  If anyone has experience of this situation it
would be nice to share!

Reminder that the second Upgrades SIG IRC meeting is scheduled for 1600 UTC
today, covering those in US timezones.

Thanks

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/a8c6a926/attachment.html>

From thierry at openstack.org  Mon Apr 15 09:35:01 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 15 Apr 2019 11:35:01 +0200
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <E1hF5zZ-0000i3-4C@zuul01.openstack.org>
References: <E1hF5zZ-0000i3-4C@zuul01.openstack.org>
Message-ID: <2b0e43ef-3adb-06db-7827-6aa0354854d9@openstack.org>

zuul at openstack.org wrote:
> Build failed.
> 
> - tag-releases http://logs.openstack.org/80/804d609460e6b165e0549e6759b1d0ee277a970a/release-post/tag-releases/a1dd193/ : TIMED_OUT in 31m 08s
> - publish-tox-docs-static publish-tox-docs-static : SKIPPED

During release-post processing of the ocata-em tagging change [1], we 
hit a job timeout[2].

It went as far down as sahara.yaml, where it successfully tagged sahara, 
sahara-dashboard, sahara-extra, sahara-image-elements, before hitting 
the timeout.

So it did not tackle searchlight-ui and the 28 other deliverables after 
that.

[1] 
https://git.openstack.org/cgit/openstack/releases/commit/?id=804d609460e6b165e0549e6759b1d0ee277a970a
[2] 
http://logs.openstack.org/80/804d609460e6b165e0549e6759b1d0ee277a970a/release-post/tag-releases/a1dd193/job-output.txt.gz

-- 
Thierry Carrez (ttx)


From openstack at fried.cc  Mon Apr 15 10:48:20 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 15 Apr 2019 05:48:20 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <1555316055.23392.7@smtp.office365.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
 <1554986561.23392.2@smtp.office365.com>
 <284bb8f5-34cf-c07e-9921-3487074ffa32@fried.cc>
 <1555316055.23392.7@smtp.office365.com>
Message-ID: <FABBE85B-6400-4FC8-A55C-55ED9B46BA70@fried.cc>



> On Apr 15, 2019, at 03:14, Balázs Gibizer <balazs.gibizer at ericsson.com> wrote:
> 
> 
> 
> On Thu, Apr 11, 2019 at 8:01 PM, Eric Fried <openstack at fried.cc> wrote:
>>> Then we need two steps:
>>> 1) handle RPs that only have traits but not resources
>>> 2) allow having the numbered request groups specify only a trait
>>> without requesting resources.
>> 
>> Nothing stops me from traiting an inventoryless provider today, right?
> 
> Does GET /allocation_candidates query handles them properly?

No, I was just pointing out that "step 1" was okay, depending on what you mean by "handle".

>> Do we actually need to involve numbered request groups? Does a concept
>> of required_in_tree=$trait_list satisfy the requirements?
> 
> I don't know. I guess I have to read required_in_tree=$trait_list spec. 
> Please ignore me.

There's no such spec yet. The above is a sincere question that could lead to one.

The GET /a_c syntax

 required_in_tree=$trait_list

would cause the result to include results where the listed traits are *anywhere* is the tree, even if the providers having those traits don't provide resources to the request. This should be fairly simple to implement. I'm asking us to ponder whether it will satisfy our use cases here.

Another option is something like root_required=$trait_list (the traits are only on the root, even when the root doesn't provide resources to the request). This satisfies the immediate use cases, but it's obviously more restrictive, and I don't think it's any easier to implement. 

Neither of these is perfect, probably. But also neither requires doing anything with numbered groups. Did you have something else in mind for that?

efried
.




From balazs.gibizer at ericsson.com  Mon Apr 15 11:38:44 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Mon, 15 Apr 2019 11:38:44 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <FABBE85B-6400-4FC8-A55C-55ED9B46BA70@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <fb9c4110-3a6c-c568-750a-c12cfab34bbe@fried.cc>
 <1554986561.23392.2@smtp.office365.com>
 <284bb8f5-34cf-c07e-9921-3487074ffa32@fried.cc>
 <1555316055.23392.7@smtp.office365.com>
 <FABBE85B-6400-4FC8-A55C-55ED9B46BA70@fried.cc>
Message-ID: <1555328320.23392.12@smtp.office365.com>



On Mon, Apr 15, 2019 at 12:48 PM, Eric Fried <openstack at fried.cc> wrote:
> 
> 
>>  On Apr 15, 2019, at 03:14, Balázs Gibizer 
>> <balazs.gibizer at ericsson.com> wrote:
>> 
>> 
>> 
>>  On Thu, Apr 11, 2019 at 8:01 PM, Eric Fried <openstack at fried.cc> 
>> wrote:
>>>>  Then we need two steps:
>>>>  1) handle RPs that only have traits but not resources
>>>>  2) allow having the numbered request groups specify only a trait
>>>>  without requesting resources.
>>> 
>>>  Nothing stops me from traiting an inventoryless provider today, 
>>> right?
>> 
>>  Does GET /allocation_candidates query handles them properly?
> 
> No, I was just pointing out that "step 1" was okay, depending on what 
> you mean by "handle".
> 
>>>  Do we actually need to involve numbered request groups? Does a 
>>> concept
>>>  of required_in_tree=$trait_list satisfy the requirements?
>> 
>>  I don't know. I guess I have to read required_in_tree=$trait_list 
>> spec.
>>  Please ignore me.
> 
> There's no such spec yet. The above is a sincere question that could 
> lead to one.

Sorry there was too many mails for me to process. So I assumed I 
overlooked this one as well.

> 
> The GET /a_c syntax
> 
>  required_in_tree=$trait_list
> 
> would cause the result to include results where the listed traits are 
> *anywhere* is the tree, even if the providers having those traits 
> don't provide resources to the request. This should be fairly simple 
> to implement. I'm asking us to ponder whether it will satisfy our use 
> cases here.

That would be yet another new way to require something in a different 
way that we requiring things so far.

We had initially the unumbered group (we didn't even called it that way 
from the start) with resources and traits (and aggregates), then we 
realized that we needed more granularity to express two sets of 
resources fulfilling different, even contradicting traits, so we 
created numbered request groups. Now we have the next complication due 
to traits are not on the same RP we are requesting resources from but 
numbered groups are fulfilled from a single RP only.

So what we need to solve is. Two (or more) sets of resources where the 
different sets requires different, contradicting traits, in a setup 
where the trait is not on the RP where resource inventory is.

compute RP
|
|
|____ OVS agent RP
|      |     * CUSTOM_VNIC_TYPE_NORMAL
|      |
|      |___________ br-int dev RP
|                       * CUSTOM_PHYSNET_PHYSNET0
|                       * NET_BW_EGR_KILOBIT_PER_SEC: 1000
|
|
|____ SRIOV agent RP
|      |     * CUSTOM_VNIC_TYPE_DIRECT
|      |
|      |
|      |___________ esn1 dev RP
|      |                * CUSTOM_PHYSNET_PHYSNET0
|      |                * NET_BW_EGR_KILOBIT_PER_SEC: 10000
|      |
|      |___________ esn2 dev RP
|                       * CUSTOM_PHYSNET_PHYSNET1
|                       * NET_BW_EGR_KILOBIT_PER_SEC: 20000


Then having two neutron ports in a server create request:
* port-normal:
    "resource_request": {
    "resources": {
            orc.NET_BW_EGR_KILOBIT_PER_SEC: 1000},
    "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_NORMAL"]

* port-direct:
    "resource_request": {
    "resources": {
            orc.NET_BW_EGR_KILOBIT_PER_SEC: 2000},
    "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_DIRECT"]

Today this will become two numbered request groups. But as the numbered 
groups are always fulfilled by a single RP and therefore the a_c result 
is empty due to CUSTOM_VNIC_TYPE_ traits.

The 'required_in_tree' in this case would need to contain both 
CUSTOM_VNIC_TYPE_NORMAL and CUSTOM_VNIC_TYPE_DIRECT which would be 
either be contradiction (if we interpret it in a way that both needs to 
be fulfilled from the same RP) or would not express the port request 
(if we interpret in a way that the trait needs to be in the tree 
somewhere).

> 
> Another option is something like root_required=$trait_list (the 
> traits are only on the root, even when the root doesn't provide 
> resources to the request). This satisfies the immediate use cases, 
> but it's obviously more restrictive, and I don't think it's any 
> easier to implement.

the 'root_required' would not solve the above example either as the 
above example does not depend on the root RP at all.

> 
> Neither of these is perfect, probably. But also neither requires 
> doing anything with numbered groups. Did you have something else in 
> mind for that?

See above. I think the above example is a bit more generic than the 
NUMA based one due to the fact that it does not depend on the root 
having traits. Also it shows the why the numbered groups needs to be 
considered when we talk about traits not being on the RP that provides 
the requested resources.

I would try to extend the api in a way that extends the existing tools, 
the groups, to be able to support requests against the above tree. How 
to do that? I don't know. I need to think about it. But we might need 
to revisit the decision to restring numbered group to a single RP.

Cheers,
gibi

> 
> efried
> .
> 
> 
> 



From fungi at yuggoth.org  Mon Apr 15 12:30:04 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 15 Apr 2019 12:30:04 +0000
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
 <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
 <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
Message-ID: <20190415123003.4byrip452uejqyvo@yuggoth.org>

On 2019-04-15 10:18:46 +0200 (+0200), Daniel Mellado Area wrote:
> Overall and besides of what Michal said, yeah, openstack hasn't been
> designed to be rebootable.
[...]

To be clear, it's DevStack which is designed not to be rebootable
(this is intentional, to further dissuade anyone from trying to use
it for a production deployment). There is nothing inherently
non-rebootable about OpenStack in general.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/2edcc3cf/attachment.sig>

From dmellado at redhat.com  Mon Apr 15 12:46:19 2019
From: dmellado at redhat.com (Daniel Mellado)
Date: Mon, 15 Apr 2019 14:46:19 +0200
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <20190415123003.4byrip452uejqyvo@yuggoth.org>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
 <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
 <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
 <20190415123003.4byrip452uejqyvo@yuggoth.org>
Message-ID: <52b97f07-a6e9-78bd-786d-20071fd17a59@redhat.com>



On 15/4/19 14:30, Jeremy Stanley wrote:
> On 2019-04-15 10:18:46 +0200 (+0200), Daniel Mellado Area wrote:
>> Overall and besides of what Michal said, yeah, openstack hasn't been
>> designed to be rebootable.
> [...]
> 
> To be clear, it's DevStack which is designed not to be rebootable
> (this is intentional, to further dissuade anyone from trying to use
> it for a production deployment). There is nothing inherently
> non-rebootable about OpenStack in general.
> 
My bad on the typo, I meant DevStack when I was typing OpenStack, heh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x13DDF774E05F5B85.asc
Type: application/pgp-keys
Size: 2208 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/b2578aae/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/b2578aae/attachment.sig>

From sean.mcginnis at gmx.com  Mon Apr 15 13:00:46 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 15 Apr 2019 08:00:46 -0500
Subject: [Cinder] Odd Volume and Volume Snapshot Dependencies
In-Reply-To: <oWOc_saGvMPgIEV8edFU1wC_2zVecPwHi6KeFZVJ-cGUN5kE2Us5zJ4K23FBq2VuHyiCUe0QtBW-N1HqHakT_vzkP3vi5hV54HEZhVgHASg=@protonmail.com>
References: <oWOc_saGvMPgIEV8edFU1wC_2zVecPwHi6KeFZVJ-cGUN5kE2Us5zJ4K23FBq2VuHyiCUe0QtBW-N1HqHakT_vzkP3vi5hV54HEZhVgHASg=@protonmail.com>
Message-ID: <20190415130046.GA20276@sm-workstation>

On Fri, Apr 12, 2019 at 07:44:15PM +0000, Jeremy Houser wrote:
> Currently running python-openstackclient functional tests against an
> openstack deployment. Ran into some odd functionality whilst
> manipulating volumes and snapshots in openstack via cli and gui.
>
> I create a volume, create a snapshot of that volume, and then create a
> volume from that snapshot. I can't delete the snapshot until I delete the
> volume that I spawned using that snapshot. I understand the dependency
> of "can't delete a volume while a snapshot dependent on that volume is
> deleted first" but why can't a volume snapshot be deleted when volumes
> are spawned from it? Is this intentional? I am working with Cinder 3.27.
>
> Jeremy

I think it may depend a little on the storage backend you are using through
Cinder, but many storage systems will have an internal dependency on that
snapshot with the volume created from it. So some are able to handle things
correctly and mark that snapshot as deleted, even though it can't actually
delete the snapshot until the volume "using" it is also deleted.

This is an optimization that the storage devices do. Many are able to very
quickly create a volume from snapshot because it is really just a metadata
operation. Then any new writes the the new volume are really just a copy on
write operation or something similar. Great for speed of creation and for
optimizing space consumption, but then it does create a hard dependency on that
source snapshot.

If the backend you are using is not able to handle marking that source snapshot
as deleting while it is being used (with actual cleanup happening later) then a
workaround for you might be a multi-step process of creating a volume from
snapshot, cloning that new volume to have a new completely independent one,
then deleting that created-from-snapshot volume. Kind of a hacky process, but I
believe it should get around any backend storage restrictions.

Sean


From soulxu at gmail.com  Mon Apr 15 13:04:39 2019
From: soulxu at gmail.com (Alex Xu)
Date: Mon, 15 Apr 2019 21:04:39 +0800
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
Message-ID: <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>

Contribute an another idea at here. Pretty sure I didn't explore this with
all the cases by my limited vision.

So I'm thinking we can continue use query string build a tree structure by
the request group number. I know the number request group problem for the
cyborg and neutron, but I think there must be some way to describe the
cyborg device will be attached to which instance numa node. So I guess that
it isn't the fault of number request group, maybe we are just missing a way
to describe that.

For the case in the spec https://review.openstack.org/#/c/650476, an
instance with one numa node and two VFs from different network. We can
write as below:

?resources=DISK_GB:10&
resources1=VCPU:2,MEMORY_MB:128&
resources1.1=VF:1&required=NET_A
resources1.2=VF:1&required=NET_B

Another example, we request an instance with two numa nodes, 2 vcpus and
128mb memory in each node. In each node has two VFs come from different PF
to have HA.

?resources=DISK_GB:10&
resources1=VCPU:2,MEMORY_MB:128&
resources1.1=VF:1&
resources1.2=VF:1&
resources2=VCPU:2,MEMORY_MB:128&
resources2.1=VF:1&
resources2.2=VF:1&
group_policy=isolate&
group_policy1=isolate&
group_policy2=isolate

The `group_policy` ensure the resources1 and resources2 aren't coming from
the same RP. The 'group_poilcy1' ensures `resource1.x` aren't coming from
the same RP. The `group_policy2` ensures `resources2.x` aren't coming from
same RP.

For the cyborg case, I think we can propose the flavor extra specs as below:
accel:device_profile.[numa node id]=<profile_name>

Then we will know the user hope the cyborg device being attach to which
instance numa node.

The cyborg only needs to return un-numbered request group, then Nova will
base on all the 'hw:xxx' extra specs and 'accel:device_profile.[numa node
id]' to generate a placement request like above.

For example, if it is PCI device under first numa node, the extra spec will
be 'accel:device_profile.0=<profile_name>' the cyborg can return a simple
request 'resources=CYBORG_PCI_XX_DEVICE:1', then we merge this into the
request group 'resources1=VCPU:2,MEMORY_MB:128,CYBORG_PCI_XX_DEVICE:1'. If
the pci device has a special trait, then cyborg should return request group
as 'resources1=CYBORG_PCI_XX_DEVICE:1&required=SOME_TRAIT', then nova merge
this into placement request as 'resources1.1'.

Chris Dent <cdent+os at anticdent.org> 于2019年4月9日周二 下午8:42写道：

>
> Spec: https://review.openstack.org/650476
>
> From the commit message:
>
>      To support NUMA and similar concepts, this proposes the ability
>      to request resources from different providers nested under a
>      common subtree (below the root provider).
>
> There's much in the feature described by the spec and the surrounding
> context that is frequently a source of contention in the placement
> group, so working through this spec is probably going to require
> some robust discussion. Doing most of that before the PTG will help
> make sure we're not going in circles in person.k
>
> Some of the areas of potential contention:
>
> * Adequate for limited but maybe not all use case solutions
> * Strict trait constructionism
> * Evolving the complexity of placement solely for the satisfaction
>    of hardware representation in Nova
> * Inventory-less resource providers
> * Developing new features in placement before existing features are
>    fully used in client services
> * Others?
>
> I list this not because they are deal breakers or the only thing
> that matters, but because they have presented stumbling blocks in
> the past and we may as well work to address them (or make an
> agreement to punt them until later) otherwise there will be
> lingering dread.
>
> And, beyond all that squishy stuff, there is the necessary
> discussion over the solution described in the spec. There are
> several alternatives listed in the spec, and a few more in the
> comments. We'd like to figure out the best solution that can
> actually be done in a reasonable amount of time, not the best
> solution in the absolute.
>
> Discuss!
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/07dca449/attachment.html>

From mark at stackhpc.com  Mon Apr 15 13:34:25 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 15 Apr 2019 14:34:25 +0100
Subject: [kolla] Virtual PTG scheduling poll
Message-ID: <CAFHSqWr2Urj4X+sywQijvfHO54WHNdzd25sM=t10gwbCqb=VNQ@mail.gmail.com>

Hi,

Since most of the Kolla team aren't attending the PTG, we've agreed to hold
a virtual PTG.

We agreed to start with two 4 hour sessions. We can finish early or
schedule another session, depending on how we progress. We'll use some
video conferencing software TBD.

I've created a Doodle poll here [2], please fill it in if you hope to
attend. Times are in UTC.

Please continue to fill out the planning Etherpad [1].

Thanks,
Mark

[1] https://etherpad.openstack.org/p/kolla-train-ptg
[2] https://doodle.com/poll/adk2smds76d8db4u
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/ff6277da/attachment.html>

From moguimar at redhat.com  Mon Apr 15 13:35:36 2019
From: moguimar at redhat.com (Moises Guimaraes de Medeiros)
Date: Mon, 15 Apr 2019 15:35:36 +0200
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
Message-ID: <CAG_6SUDr3ug1j4OQg6+97+=UWzR0958xYFNXYGcyZEg0GirH2A@mail.gmail.com>

Hi Ghanshyam,

I saw your patch on oslo.config and I notice that in the tox.ini file it
drops Python 3 at all. Should we add py36 in the same patch before
approving it?

I'm sending this here cause it might also be the same case for other
patches.

Em dom, 14 de abr de 2019 às 20:48, Ghanshyam Mann <gmann at ghanshyammann.com>
escreveu:

> Hello Everyone,
>
> All the integration testing has been moved to Bionic[1] now and as
> discussed in the TC meeting[2],
> we are good to drop the py35 testing.
>
> Train: Good to drop.
> I am going to push the patches to remove the py35 jobs from the master
> (which is Train now).
>
> Stable/Stein: Ok to drop if the project wants.
> Stable/Stein gate is also moved to Bionic so we are good to drop py35 from
> stable/stein too.
> But backporting all the patches will be too many patches for projects to
> merge on stable/stein so
> we discussed not to propose all of them to stable/stein. If the project
> really wants to drop it from
> stable/stein then, they can backport.
>
> NOTE: Till stable/rocky, we should keep testing py35. If your project is
> branchless like Tempest and gate
> the same jobs for stable/rocky or older then, you should keep testing the
> py35 until stable/rocky EOL.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
> [2]
> http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
>
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html
>
> -gmann
>
>
>

-- 
Thanks,
Moisés Guimarães
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/f3fe2f6c/attachment.html>

From smooney at redhat.com  Mon Apr 15 13:54:34 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 15 Apr 2019 14:54:34 +0100
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
Message-ID: <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>

On Mon, 2019-04-15 at 21:04 +0800, Alex Xu wrote:
> Contribute an another idea at here. Pretty sure I didn't explore this with
> all the cases by my limited vision.
> 
> So I'm thinking we can continue use query string build a tree structure by
> the request group number. I know the number request group problem for the
> cyborg and neutron, but I think there must be some way to describe the
> cyborg device will be attached to which instance numa node. So I guess that
> it isn't the fault of number request group, maybe we are just missing a way
> to describe that.
> 
> For the case in the spec https://review.openstack.org/#/c/650476, an
> instance with one numa node and two VFs from different network. We can
> write as below:
> 
> ?resources=DISK_GB:10&
> resources1=VCPU:2,MEMORY_MB:128&
> resources1.1=VF:1&required=NET_A
> resources1.2=VF:1&required=NET_B
im not sure what NET_A and NET_B correspond to
as they are not prefixed with CUSTOM_ that implies they are standard
traits but how woudl you map dynamically created neutron network to reouce providres as
traits.

i can see and have argued for doing something similar for neutron physnet
as tehy are mostly static and can be applied by the neutron agent to the RP they create
using a CUSTOM_PHYSNET_<physnet name> trait but i dont see how NET_A woudl work.
> 
> Another example, we request an instance with two numa nodes, 2 vcpus and
> 128mb memory in each node. In each node has two VFs come from different PF
> to have HA.
> 
> ?resources=DISK_GB:10&
> resources1=VCPU:2,MEMORY_MB:128&
> resources1.1=VF:1&
> resources1.2=VF:1&
> resources2=VCPU:2,MEMORY_MB:128&
> resources2.1=VF:1&
> resources2.2=VF:1&
> group_policy=isolate&
> group_policy1=isolate&
> group_policy2=isolate

this gets messy as there is no way to express that i have a 2 numa node guest
and i want a vf form either numa node without changing the grouping and group policies.

if we went down this road the we woudl have to generate this request dynamically(im ok with that)
but that woudl mean the operator should not add resouce:... extra_spec to falvor ever.

personally i would like to move in the direction of creating the placement queries dynamically
and not requiring or allowing operators to specify resouce in the flavor as its the only way
i can see to beable to generage a query like the one above. the main gap i see to enabling
that is we have no numa infomation from neutron with regards to what numa node we shoudl
attach the vf too so we cant create the request above without chaning the neutron api.

> 
> The `group_policy` ensure the resources1 and resources2 aren't coming from
> the same RP. The 'group_poilcy1' ensures `resource1.x` aren't coming from
> the same RP. The `group_policy2` ensures `resources2.x` aren't coming from
> same RP.
> 
> For the cyborg case, I think we can propose the flavor extra specs as below:
> accel:device_profile.[numa node id]=<profile_name>
this i think could work short term but honestly i think we should not do this.
in the long term we would want to allow the device_profile to be passed on the
nova boot commandlline and manage qouta/billing of device outside of flavors.

we will also want to provide a policy attibe i think for virtual to host numa affitity
for devices.

the other asspect is we curently do not create a pci root complex per numa node
until we do that  we cant support requesting cyborg device per numa node
the numa node id in accel:device_profile.[numa node id]=<profile_name>
should be the guest numa node not a host numa node.

personally i woudl prefer to create the pci root complex per numa node first
and automaticlly assign the device to the correct root complex before allowing
enduser to request cyborge device to be attached to a specific guest numa node
as i think accel:device_profile.[numa node id]=<profile_name>  might be too constiringing
while also leaking to much host specific infomation via our api if it is used to select
placment resouce providers and therefore host numa nodes.

> 
> Then we will know the user hope the cyborg device being attach to which
> instance numa node.
> 
> The cyborg only needs to return un-numbered request group, then Nova will
> base on all the 'hw:xxx' extra specs and 'accel:device_profile.[numa node
> id]' to generate a placement request like above.
> 
> For example, if it is PCI device under first numa node, the extra spec will
> be 'accel:device_profile.0=<profile_name>' the cyborg can return a simple
> request 'resources=CYBORG_PCI_XX_DEVICE:1', then we merge this into the
> request group 'resources1=VCPU:2,MEMORY_MB:128,CYBORG_PCI_XX_DEVICE:1'. If
> the pci device has a special trait, then cyborg should return request group
> as 'resources1=CYBORG_PCI_XX_DEVICE:1&required=SOME_TRAIT', then nova merge
> this into placement request as 'resources1.1'.
> 
> Chris Dent <cdent+os at anticdent.org> 于2019年4月9日周二 下午8:42写道：
> 
> > 
> > Spec: https://review.openstack.org/650476
> > 
> > From the commit message:
> > 
> >      To support NUMA and similar concepts, this proposes the ability
> >      to request resources from different providers nested under a
> >      common subtree (below the root provider).
> > 
> > There's much in the feature described by the spec and the surrounding
> > context that is frequently a source of contention in the placement
> > group, so working through this spec is probably going to require
> > some robust discussion. Doing most of that before the PTG will help
> > make sure we're not going in circles in person.k
> > 
> > Some of the areas of potential contention:
> > 
> > * Adequate for limited but maybe not all use case solutions
> > * Strict trait constructionism
> > * Evolving the complexity of placement solely for the satisfaction
> >    of hardware representation in Nova
> > * Inventory-less resource providers
> > * Developing new features in placement before existing features are
> >    fully used in client services
> > * Others?
> > 
> > I list this not because they are deal breakers or the only thing
> > that matters, but because they have presented stumbling blocks in
> > the past and we may as well work to address them (or make an
> > agreement to punt them until later) otherwise there will be
> > lingering dread.
> > 
> > And, beyond all that squishy stuff, there is the necessary
> > discussion over the solution described in the spec. There are
> > several alternatives listed in the spec, and a few more in the
> > comments. We'd like to figure out the best solution that can
> > actually be done in a reasonable amount of time, not the best
> > solution in the absolute.
> > 
> > Discuss!
> > 
> > --
> > Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> > freenode: cdent                                         tw: @anticdent



From smooney at redhat.com  Mon Apr 15 13:59:51 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 15 Apr 2019 14:59:51 +0100
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
Message-ID: <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>

On Sun, 2019-04-14 at 13:48 -0500, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],
> we are good to drop the py35 testing. 
> 
> Train: Good to drop.
> I am going to push the patches to remove the py35 jobs from the master (which is Train now). 
so i asked this a number of months ago and at the time i did not get a concreate answer.
if we drop py35 testing that means we are increaseing our minium python 3 version to py36

so projects are free to use python 3.6 only feature correct once py2.7 support is removed.

i recently found out that nova does not work on py37 and if we have no testing for py35 then
its possible that we could also break there so if this goes ahead i want to carify that for train
the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train
goal.
> 
> Stable/Stein: Ok to drop if the project wants.
> Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.
> But backporting all the patches will be too many patches for projects to merge on stable/stein so
> we discussed not to propose all of them to stable/stein. If the project really wants to drop it from
> stable/stein then, they can backport. 
> 
> NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate
> the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.
> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
> [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
>        http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html 
> 
> -gmann
> 
> 



From pawel.konczalski at everyware.ch  Mon Apr 15 14:02:47 2019
From: pawel.konczalski at everyware.ch (Pawel Konczalski)
Date: Mon, 15 Apr 2019 16:02:47 +0200
Subject: kube_cluster_deploy fails
In-Reply-To: <0f00a092-1f7d-e85b-9ce4-da38cfd2c9da@everyware.ch>
References: <0f00a092-1f7d-e85b-9ce4-da38cfd2c9da@everyware.ch>
Message-ID: <fa4c513a-a773-2ec8-2643-ea4534a449f2@everyware.ch>

Hi,

i try to deploy a kubernetes cluster on OpenStack rocky with Magnum. All 
Heat steps runs fine except for the last one "kube_cluster_deploy":

kube_cluster_deploy    c3a79e96-87d8-442e-83f1-91d7a1acd896    1 
minute    Create Failed    CREATE aborted (Task create from 
SoftwareDeployment "kube_cluster_deploy" Stack 
"kubernetes-cluster9-l4ol4ger3key" 
[b17bfab3-f46a-477b-921f-4719bfd8df06] Timed out)

The cluster contains three control / compute nodes, Octavia is also 
installed and works fine as far as I can see.

Atomic Image:
https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.raw.xz

The command was:
openstack coe cluster template create kubernetes-cluster-template \
   --image fedora-atomic-latest \
   --external-network public \
   --dns-nameserver 8.8.8.8 \
   --master-flavor m1.small \
   --flavor m1.large \
   --coe kubernetes \
   --docker-volume-size 10 \
   --tls-disabled \
   --floating-ip-enabled

openstack coe cluster create kubernetes-cluster \
   --cluster-template kubernetes-cluster-template \
   --master-count 1 \
   --node-count 1 \
   --timeout 30 \
   --keypair mykey

Did someone run also into this Problem or know how to fix it?

BR

Pawel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5227 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/d774ee5b/attachment.bin>

From bence.romsics at gmail.com  Mon Apr 15 14:11:16 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Mon, 15 Apr 2019 16:11:16 +0200
Subject: [heat][neutron] improving extraroute support
Message-ID: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>

Hi Heat and Neutron folks,

I'm wondering how could I improve support for extra routes for one of
our users. In this email I'd like to get your input (from both Heat
and Neutron folks) in which direction should I start before I sit down
to write the relevant blueprints and RFEs. This will be a bit long,
please bear with me.

As you know a neutron router can have extra static routing table
entries as the 'routes' attribute like this (please see the api-ref in
[1]):

$ openstack router show router1 -f value -c routes
destination='10.1.0.0/24', gateway='10.0.0.11'
destination='10.2.0.0/24', gateway='10.0.0.12'
...

To my best knowledge the whole set of extra routes must be updated at
once which easily leads to lost updates if multiple clients modify
this attribute concurrently (imagine client A and B working
concurrently, for example both reads routes [r1], client A writes [r1,
r2], client B writes [r1, r3]; depending on timing either r2 or r3
will be lost).

Heat has an unsupported resource OS::Neutron::ExtraRoute [2] to front
Neutron extra routes. For example:

heat_template_version: '2015-04-30'
resources:
  Extra_route_1:
    type: OS::Neutron::ExtraRoute
    properties:
      destination: '10.1.0.0/24'
      nexthop: '10.0.0.11'
      router_id: 'd544b5c5-d4d2-4b52-aaa8-ef4b9fa3e154'

The Heat resource represents a single extra route out of the many in
the router's routes attribute. If you have multiple
OS::Neutron::ExtraRoute resources Heat by default handles them
concurrently leading to the lost update problem. You can easily
reproduce the problem just by having 10 extra routes in a template.
The stack creation will succeed, but the router in fact will have only
6-7 (the exact number changes based on timing) extra routes. AFAIU
this is exactly why this was marked unsupported. (Please let me know
if you know other reasons.)

As a workaround I suggested our user a hack to serialize the
OS::Neutron::ExtraRoute resources by 'depends_on'.

But which way should I go if I want to fix this properly?

way #1 - changes in Heat only: Introduce a new Heat resource
OS::Neutron::ExtraRoutes (please notice the plural) which can
represent the whole routes attribute of a router (i.e. multiple extra
routes in a single resource). This will not solve the design
shortcomings of the neutron extraroute API, but it can at least
express what can be done in the Neutron API as is. Lost updates of
multiple stacks editing the same router's routes are still possible.

way #2 - changes in Heat and Neutron: Introduce a new Neutron
extension with a better API (either extraroutes as a top level
resource, each object with a router_id or an action map a'la
add/remove_router_interface to edit extra routes on the server side).
This new API would work on the same DB tables and backends as the old.
The old API would be kept for backwards compatibility. But if a new
user exclusively uses the new API it can work concurrently. Then
introduce a new Heat resource (or change the existing unsupported one)
to use this new Neutron API. This is obviously more work than the
first option.

Which one do you prefer and why? Or let me know please if I missed a
better alternative.

In this thread I hope to get a cross-project agreement of this between
Heat and Neutron so I can go ahead and open the relevant Heat and
Neutron blueprints where we can focus only on each projects' internal
questions.

Thanks in advance,
Bence Romsics
irc: rubasov

[1] https://developer.openstack.org/api-ref/network/v2/?expanded=update-router-detail#update-router
[2] https://docs.openstack.org/heat/latest/template_guide/unsupported.html#OS::Neutron::ExtraRoute


From lbragstad at gmail.com  Mon Apr 15 14:16:02 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Mon, 15 Apr 2019 09:16:02 -0500
Subject: Pike: "Observer" or "read-only" admin access?
In-Reply-To: <2358baef1296b0d821e46c86fb457f96@jots.org>
References: <2358baef1296b0d821e46c86fb457f96@jots.org>
Message-ID: <16f3c456-304a-f04f-2bfa-a9fbcf204837@gmail.com>

Hi Ken,

On 4/11/19 5:05 PM, Ken D'Ambrosio wrote:
> Hi, all.  Beginning to roll out a newer-than-what-we-had OpenStack
> release -- likely to be Pike, "For reasons."  (Which is still *worlds*
> newer than Juno, where we are.)  And I've been asked if there's such a
> thing as an account (or ACL) that allows a user to read everything,
> but write nothing.  Googling, I see mention of such things -- but
> nothing really firm.  Does it exist?

Not yet, but it is something we're working towards.

> Is it in Pike (or more recent releases)?  

A few projects implemented support for better policy configuration (nova
and keystone) in Pike. During the Queens development cycle there was a
community-wide initiative to register all policy defaults in code [0].
I'm mentioning this because that work makes the changes required for a
read-only role a little easier to manage. At least until things get
fixed upstream.

[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html

> If it doesn't exist, is there a graceful way to make it happen, anyway?

Yes (though it depends on you definition of "graceful".) Most OpenStack
services support a policy file that facilitates a way for operators to
specify the policies they want to use in their deployment. For example,
if you want to override `identity:get_users = role:reader`, you would do
that in keystone's policy file. Each service has their own policy file,
and most will have defaults in code, so if you don't specify a policy
for a given API a default will be applied.

There has been extensive work done in Pike, Queens, Rocky, and Stein to
make a read-only a first-class citizen in OpenStack. As of the Stein
release, only a handful of projects support it out-of-the-box [1][2]
(see keystone's Stein release notes for more details on what exactly we
worked on for this release). We're hoping it will catch hold in some
other services in the Train and U development cycles.

If you're going to be in Denver for the summit/forum/ptg there is a
hands-on lab scheduled to help people write custom policies while we get
things squared-away by default [3].

[1] https://docs.openstack.org/releasenotes/keystone/stein.html
[2]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html
[3]
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23005/access-control-policy-hands-on-lab

>
> Thanks!
>
> -Ken
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/8df36f6b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/8df36f6b/attachment-0001.sig>

From sean.mcginnis at gmx.com  Mon Apr 15 14:21:48 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 15 Apr 2019 09:21:48 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>
Message-ID: <20190415142147.GA24916@sm-workstation>

> > we are good to drop the py35 testing.
> >
> > Train: Good to drop.
> > I am going to push the patches to remove the py35 jobs from the master (which is Train now).
> so i asked this a number of months ago and at the time i did not get a concreate answer.
> if we drop py35 testing that means we are increaseing our minium python 3 version to py36
>

Yes, following our policy of using the python version supported on the distros
we target at the beginning of the cycle. the Stein minimum py3 version was
Python 3.6 [0].

> so projects are free to use python 3.6 only feature correct once py2.7 support is removed.
>

Dropping py2 support is currently planned for the U release cycle.

> i recently found out that nova does not work on py37 and if we have no testing for py35 then
> its possible that we could also break there so if this goes ahead i want to carify that for train
> the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train
> goal.
> >

Failures on py3.7 will need to be addressed as that is one of the Python
runtimes required for Train [1].

[0] https://governance.openstack.org/tc/reference/runtimes/stein.html
[1] https://governance.openstack.org/tc/reference/runtimes/train.html


From sean.mcginnis at gmx.com  Mon Apr 15 14:26:42 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 15 Apr 2019 09:26:42 -0500
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <2b0e43ef-3adb-06db-7827-6aa0354854d9@openstack.org>
References: <E1hF5zZ-0000i3-4C@zuul01.openstack.org>
 <2b0e43ef-3adb-06db-7827-6aa0354854d9@openstack.org>
Message-ID: <20190415142642.GB24916@sm-workstation>

>
> During release-post processing of the ocata-em tagging change [1], we hit a
> job timeout[2].
>
> It went as far down as sahara.yaml, where it successfully tagged sahara,
> sahara-dashboard, sahara-extra, sahara-image-elements, before hitting the
> timeout.
>
> So it did not tackle searchlight-ui and the 28 other deliverables after
> that.
>
> [1] https://git.openstack.org/cgit/openstack/releases/commit/?id=804d609460e6b165e0549e6759b1d0ee277a970a
> [2] http://logs.openstack.org/80/804d609460e6b165e0549e6759b1d0ee277a970a/release-post/tag-releases/a1dd193/job-output.txt.gz
>

I have submitted https://review.openstack.org/652659  to increase the job
timeout for tag-releases. I have also submitted a revert of the tagging with
https://review.openstack.org/652672. I think easiest fix for this for now will
be to merge both of those, resubmit the ocata-em tagging on top of the longer
job timeout, then see how long the actual tagging of every deliverable takes
and adjust our job timeout if we need to be a little more reasonable about how
long we wait. Keeping in mind that there may be a few more deliverables in
later series though.

Jeremy had a great suggestion that we may also want to consider doing these
full-cycle EM tagging patches in multiple batches so we avoid the need to
process so many tags in one job run.


From ramishra at redhat.com  Mon Apr 15 14:39:45 2019
From: ramishra at redhat.com (Rabi Mishra)
Date: Mon, 15 Apr 2019 20:09:45 +0530
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
Message-ID: <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>

On Mon, Apr 15, 2019 at 7:48 PM Bence Romsics <bence.romsics at gmail.com>
wrote:

> Hi Heat and Neutron folks,
>
> I'm wondering how could I improve support for extra routes for one of
> our users. In this email I'd like to get your input (from both Heat
> and Neutron folks) in which direction should I start before I sit down
> to write the relevant blueprints and RFEs. This will be a bit long,
> please bear with me.
>
> As you know a neutron router can have extra static routing table
> entries as the 'routes' attribute like this (please see the api-ref in
> [1]):
>
> $ openstack router show router1 -f value -c routes
> destination='10.1.0.0/24', gateway='10.0.0.11'
> destination='10.2.0.0/24', gateway='10.0.0.12'
> ...
>
> To my best knowledge the whole set of extra routes must be updated at
> once which easily leads to lost updates if multiple clients modify
> this attribute concurrently (imagine client A and B working
> concurrently, for example both reads routes [r1], client A writes [r1,
> r2], client B writes [r1, r3]; depending on timing either r2 or r3
> will be lost).
>
> Heat has an unsupported resource OS::Neutron::ExtraRoute [2] to front
> Neutron extra routes. For example:
>
> heat_template_version: '2015-04-30'
> resources:
>   Extra_route_1:
>     type: OS::Neutron::ExtraRoute
>     properties:
>       destination: '10.1.0.0/24'
>       nexthop: '10.0.0.11'
>       router_id: 'd544b5c5-d4d2-4b52-aaa8-ef4b9fa3e154'
>
> The Heat resource represents a single extra route out of the many in
> the router's routes attribute. If you have multiple
> OS::Neutron::ExtraRoute resources Heat by default handles them
> concurrently leading to the lost update problem. You can easily
> reproduce the problem just by having 10 extra routes in a template.
> The stack creation will succeed, but the router in fact will have only
> 6-7 (the exact number changes based on timing) extra routes. AFAIU
> this is exactly why this was marked unsupported. (Please let me know
> if you know other reasons.)
>
>
I think this had been discussed on several occasions[1] before and one of
the
suggestions from the neutron team was to use compare-and-swap update api [2]
to avoid race conditions.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html
 [2] https://bugs.launchpad.net/neutron/+bug/1703234

As a workaround I suggested our user a hack to serialize the
> OS::Neutron::ExtraRoute resources by 'depends_on'.
>
> But which way should I go if I want to fix this properly?
>
> way #1 - changes in Heat only: Introduce a new Heat resource
> OS::Neutron::ExtraRoutes (please notice the plural) which can
> represent the whole routes attribute of a router (i.e. multiple extra
> routes in a single resource). This will not solve the design
> shortcomings of the neutron extraroute API, but it can at least
> express what can be done in the Neutron API as is. Lost updates of
> multiple stacks editing the same router's routes are still possible.
>
>
way #2 - changes in Heat and Neutron: Introduce a new Neutron
> extension with a better API (either extraroutes as a top level
> resource, each object with a router_id or an action map a'la
> add/remove_router_interface to edit extra routes on the server side).
> This new API would work on the same DB tables and backends as the old.
> The old API would be kept for backwards compatibility. But if a new
> user exclusively uses the new API it can work concurrently. Then
> introduce a new Heat resource (or change the existing unsupported one)
> to use this new Neutron API. This is obviously more work than the
> first option.
>
> Which one do you prefer and why? Or let me know please if I missed a
> better alternative.
>
> In this thread I hope to get a cross-project agreement of this between
> Heat and Neutron so I can go ahead and open the relevant Heat and
> Neutron blueprints where we can focus only on each projects' internal
> questions.
>
> Thanks in advance,
> Bence Romsics
> irc: rubasov
>
> [1]
> https://developer.openstack.org/api-ref/network/v2/?expanded=update-router-detail#update-router
> [2]
> https://docs.openstack.org/heat/latest/template_guide/unsupported.html#OS::Neutron::ExtraRoute
>
>

-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/6c34f3ed/attachment.html>

From zbitter at redhat.com  Mon Apr 15 14:45:06 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Mon, 15 Apr 2019 10:45:06 -0400
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
Message-ID: <457e9c1d-2713-79f1-de98-4a1fd2abd928@redhat.com>

On 14/04/19 2:48 PM, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],
> we are good to drop the py35 testing.
> 
> Train: Good to drop.
> I am going to push the patches to remove the py35 jobs from the master (which is Train now).

+1

Can I suggest that you instead push patches to switch to 
openstack-python3-train-jobs?

The only downside of that is that since it can't merge until py37 works, 
projects will end up continuing to run py35 tests until py37 support is 
ready to merge. But the upside is we only have to make one change for Train.

> Stable/Stein: Ok to drop if the project wants.
> Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.
> But backporting all the patches will be too many patches for projects to merge on stable/stein so
> we discussed not to propose all of them to stable/stein. If the project really wants to drop it from
> stable/stein then, they can backport.
> 
> NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate
> the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.
> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
> [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
>         http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html
> 
> -gmann
> 
> 



From bence.romsics at gmail.com  Mon Apr 15 15:01:52 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Mon, 15 Apr 2019 17:01:52 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
Message-ID: <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>

On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra at redhat.com> wrote:
> I think this had been discussed on several occasions[1] before and one of the
> suggestions from the neutron team was to use compare-and-swap update api [2]
> to avoid race conditions.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html
>  [2] https://bugs.launchpad.net/neutron/+bug/1703234

Thank you for your quick answer. I did read that previous discussion
and I did not properly understand why compare-and-swap was
recommended. To my understanding compare-and-swap allows a client to
detect a race with another, but it would not eliminate the races. All
clients would have to retry until success and with the current
OS::Neutron::ExtraRoute we do actively generate those races. That's
why I went in the directions mentioned in my original mail. Am I
missing something?


From gmann at ghanshyammann.com  Mon Apr 15 15:32:47 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 15 Apr 2019 10:32:47 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <20190415142147.GA24916@sm-workstation>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>
 <20190415142147.GA24916@sm-workstation>
Message-ID: <16a21a11b71.cafa55a78148.4359963475441472467@ghanshyammann.com>

 ---- On Mon, 15 Apr 2019 09:21:48 -0500 Sean McGinnis <sean.mcginnis at gmx.com> wrote ----
 > > > we are good to drop the py35 testing. 
 > > > 
 > > > Train: Good to drop. 
 > > > I am going to push the patches to remove the py35 jobs from the master (which is Train now). 
 > > so i asked this a number of months ago and at the time i did not get a concreate answer. 
 > > if we drop py35 testing that means we are increaseing our minium python 3 version to py36 
 > > 
 >  
 > Yes, following our policy of using the python version supported on the distros 
 > we target at the beginning of the cycle. the Stein minimum py3 version was 
 > Python 3.6 [0]. 
 >  
 > > so projects are free to use python 3.6 only feature correct once py2.7 support is removed. 
 > > 
 >  
 > Dropping py2 support is currently planned for the U release cycle. 

As per Train testing runtime, we will have py3.7 support also which will be before we
drop the py2.7 support.

 >  
 > > i recently found out that nova does not work on py37 and if we have no testing for py35 then 
 > > its possible that we could also break there so if this goes ahead i want to carify that for train 
 > > the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train 
 > > goal. 
 > > > 
 >  
 > Failures on py3.7 will need to be addressed as that is one of the Python 
 > runtimes required for Train [1]. 

Yeah, py3.7 support is Train target. We will be making all py3.6 job voting in train with
fixing the failure if any. Most of the projects already running py3.7 jobs.

-gmann

 >  
 > [0] https://governance.openstack.org/tc/reference/runtimes/stein.html 
 > [1] https://governance.openstack.org/tc/reference/runtimes/train.html 
 > 



From smooney at redhat.com  Mon Apr 15 15:33:54 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 15 Apr 2019 16:33:54 +0100
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <20190415142147.GA24916@sm-workstation>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>
 <20190415142147.GA24916@sm-workstation>
Message-ID: <db83f86edb7d5cdd1f7e24e6fbefc4270ddddb1a.camel@redhat.com>

On Mon, 2019-04-15 at 09:21 -0500, Sean McGinnis wrote:
> > > we are good to drop the py35 testing.
> > > 
> > > Train: Good to drop.
> > > I am going to push the patches to remove the py35 jobs from the master (which is Train now).
> > 
> > so i asked this a number of months ago and at the time i did not get a concreate answer.
> > if we drop py35 testing that means we are increaseing our minium python 3 version to py36
> > 
> 
> Yes, following our policy of using the python version supported on the distros
> we target at the beginning of the cycle. the Stein minimum py3 version was
> Python 3.6 [0].
ok so we should we update teh setup cfg markers to reflect that?
we still state 3.5 on nova master 
https://github.com/openstack/nova/blob/78e742662edd164c46382c31e106884762fed029/setup.cfg#L18-L19

> 
> > so projects are free to use python 3.6 only feature correct once py2.7 support is removed.
> > 
> 
> Dropping py2 support is currently planned for the U release cycle.
yes i know what i was getting at is becauese we still have to support pyton 2.7 in train
the subset of lanague feautres we can currently use is what is support on python 2.7 and
also work son python 3.6

meaning we cannot use any python3 only feature until U.
> 
> > i recently found out that nova does not work on py37 and if we have no testing for py35 then
> > its possible that we could also break there so if this goes ahead i want to carify that for train
> > the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train
> > goal.
> > > 
> 
> Failures on py3.7 will need to be addressed as that is one of the Python
> runtimes required for Train [1].
i have not dug into the failure other than to know that the agent hangs or crashes when you boot a vm with
no error messages of any kind in journalctl.
so we will need to fix it but at this point it could be anything form eventlet not working properly to we have some
python27/36 only code on the spawn codepath.

the fact that even with devstack and debug loggin enabeld the output just stops makes i hard figure out whats actully
going on but i also have not dug into it much yet.

> 
> [0] https://governance.openstack.org/tc/reference/runtimes/stein.html
> [1] https://governance.openstack.org/tc/reference/runtimes/train.html



From gmann at ghanshyammann.com  Mon Apr 15 15:28:52 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 15 Apr 2019 10:28:52 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <CAG_6SUDr3ug1j4OQg6+97+=UWzR0958xYFNXYGcyZEg0GirH2A@mail.gmail.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <CAG_6SUDr3ug1j4OQg6+97+=UWzR0958xYFNXYGcyZEg0GirH2A@mail.gmail.com>
Message-ID: <16a219d8323.e2a7b9cf7998.4956954946250714225@ghanshyammann.com>

 ---- On Mon, 15 Apr 2019 08:35:36 -0500 Moises Guimaraes de Medeiros <moguimar at redhat.com> wrote ----
 > Hi Ghanshyam,
 > I saw your patch on oslo.config and I notice that in the tox.ini file it drops Python 3 at all. Should we add py36 in the same patch before approving it?
 > I'm sending this here cause it might also be the same case for other patches.

I did not explicitly added the py36 tox env in same patch which was not there. I thought it is intentional from the project side. But yeah we can modify the py35 env to py36
if there is no. 

-gmann

 > Em dom, 14 de abr de 2019 às 20:48, Ghanshyam Mann <gmann at ghanshyammann.com> escreveu:
 > 
 > 
 > -- 
 > Thanks,Moisés Guimarães
 >  Hello Everyone,
 >  
 >  All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],
 >  we are good to drop the py35 testing. 
 >  
 >  Train: Good to drop.
 >  I am going to push the patches to remove the py35 jobs from the master (which is Train now). 
 >  
 >  Stable/Stein: Ok to drop if the project wants.
 >  Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.
 >  But backporting all the patches will be too many patches for projects to merge on stable/stein so
 >  we discussed not to propose all of them to stable/stein. If the project really wants to drop it from
 >  stable/stein then, they can backport. 
 >  
 >  NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate
 >  the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.
 >  
 >  [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
 >  [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
 >         http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html 
 >  
 >  -gmann
 >  
 >  
 > 



From nicolas.ghirlanda at everyware.ch  Mon Apr 15 15:36:08 2019
From: nicolas.ghirlanda at everyware.ch (Nicolas Ghirlanda)
Date: Mon, 15 Apr 2019 17:36:08 +0200
Subject: [nova][scheduler] scheduler spawns to the same compute node only
Message-ID: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>

Hi all,

we have a kolla-ansible deployed "Queens" Release of openstack with 8 
compute nodes and an external Percona XtraDB Cluster (with read-write 
split with haproxy).


New VMs  are just currently always scheduled to the same compute node, 
even though a manual live-migration is working fine to other compute nodes.


We're not sure, what the issue is, but perhaps someone may spot it from 
our config:


# nova.conf  scheduler config

default_availability_zone = az1

...

[filter_scheduler]
available_filters = nova.scheduler.filters.all_filters
enabled_filters = RetryFilter, AvailabilityZoneFilter, 
ComputeCapabilitiesFilter, ImagePropertiesFilter, 
ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, 
AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation, 
DifferentHostFilter, RamFilter, SameHostFilter, NUMATopologyFilter



Database is an external Percona XtraDB Cluster (Version 5.7.24) with 
haproxy for read-write-splitting (currently only one write node).

We do see mysql errors in the nova-scheduler.log on the write DB node 
when an instance is created.


2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db [-] 
Unexpected error while reporting service status: OperationalError: 
(pymysql.err.OperationalError) (1213, u'WSREP detected deadlock/conflict 
and aborted the transaction. Try restarting the transaction') 
(Background on this error at: http://sqlalche.me/e/e3q8)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db Traceback 
(most recent call last):
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py", 
line 91, in _report_state
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
service.service_ref.save()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py", 
line 226, in wrapper
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
fn(self, *args, **kwargs)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/service.py", 
line 397, in save
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db db_service 
= db.service_update(self._context, self.id, updates)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/api.py", 
line 183, in service_update
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
IMPL.service_update(context, service_id, values)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
line 154, in wrapper
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
ectxt.value = e.inner_exc
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 220, in __exit__
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.force_reraise()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 196, in force_reraise
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
six.reraise(self.type_, self.value, self.tb)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
line 142, in wrapper
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
f(*args, **kwargs)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", 
line 227, in wrapped
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
f(context, *args, **kwargs)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/usr/lib/python2.7/contextlib.py", line 24, in __exit__
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.gen.next()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
line 1043, in _transaction_scope
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db yield resource
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/usr/lib/python2.7/contextlib.py", line 24, in __exit__
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.gen.next()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
line 653, in _session
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.session.rollback()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 220, in __exit__
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.force_reraise()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
line 196, in force_reraise
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
six.reraise(self.type_, self.value, self.tb)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
line 650, in _session
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self._end_session_transaction(self.session)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
line 678, in _end_session_transaction
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
session.commit()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
line 943, in commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.transaction.commit()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
line 471, in commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db t[1].commit()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
line 1643, in commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self._do_commit()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
line 1674, in _do_commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.connection._commit_impl()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
line 726, in _commit_impl
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self._handle_dbapi_exception(e, None, None, None, None)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
line 1409, in _handle_dbapi_exception
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
util.raise_from_cause(newraise, exc_info)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", 
line 265, in raise_from_cause
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
reraise(type(exception), exception, tb=exc_tb, cause=cause)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
line 724, in _commit_impl
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self.engine.dialect.do_commit(self.connection)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py", 
line 1765, in do_commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
dbapi_connection.commit()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
line 422, in commit
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
self._read_ok_packet()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
line 396, in _read_ok_packet
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db pkt = 
self._read_packet()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
line 683, in _read_packet
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
packet.check_error()
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/protocol.py", 
line 220, in check_error
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
err.raise_mysql_exception(self._data)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
"/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/err.py", 
line 109, in raise_mysql_exception
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db raise 
errorclass(errno, errval)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
OperationalError: (pymysql.err.OperationalError) (1213, u'WSREP detected 
deadlock/conflict and aborted the transaction. Try restarting the 
transaction') (Background on this error at: http://sqlalche.me/e/e3q8)
2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
2019-04-15 16:52:20.020 24 INFO nova.servicegroup.drivers.db [-] 
Recovered from being unable to report status.


The deadlock message is quite strange, as we have haproxy configured so 
all write requests are handled by one node.


There are NO errors in the mysqld.log WHILE creating an instance, but we 
see from time to time aborted connections from nova.

2019-04-15T14:22:36.232108Z 30616972 [Note] Aborted connection 30616972 
to db: 'nova' user: 'nova' host: '10.x.y.z' (Got an error reading 
communication packets)



As I said, all instances are allocated to the same compute node. 
nova-compute.log doesn't show an error while creating the instance.


Beside that, we also see messages from nova.scheduler.host_manager on 
all other nodes like (but those messages are _not_ triggered, when an 
instance is spawned.!)


2019-04-15 16:28:47.771 22 INFO nova.scheduler.host_manager 
[req-f92e340e-a88a-44a0-8cad-588390c25bc2 - - - - -] The instance sync 
for host 'xxx' did not match. Re-created its InstanceList.



Don't know if that may be relevant, but somehow our (currently single) 
AZ is listed several times.


# openstack availability zone list
+------------+-------------+
| Zone Name  | Zone Status |
+------------+-------------+
| internal   | available   |
| az1 | available           |
| az1 | available           |
| az1 | available           |
| az1 | available           |
+------------+-------------+

May that be related somehow?


Thanks for any consideration and support!


kind regards


Nicolas

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/6c21110a/attachment-0001.bin>

From gmann at ghanshyammann.com  Mon Apr 15 15:44:51 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 15 Apr 2019 10:44:51 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <457e9c1d-2713-79f1-de98-4a1fd2abd928@redhat.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <457e9c1d-2713-79f1-de98-4a1fd2abd928@redhat.com>
Message-ID: <16a21ac27fe.11abf9b078630.6641890910997380340@ghanshyammann.com>

 ---- On Mon, 15 Apr 2019 09:45:06 -0500 Zane Bitter <zbitter at redhat.com> wrote ----
 > On 14/04/19 2:48 PM, Ghanshyam Mann wrote: 
 > > Hello Everyone, 
 > >  
 > > All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2], 
 > > we are good to drop the py35 testing. 
 > >  
 > > Train: Good to drop. 
 > > I am going to push the patches to remove the py35 jobs from the master (which is Train now). 
 >  
 > +1 
 >  
 > Can I suggest that you instead push patches to switch to  
 > openstack-python3-train-jobs? 
 >  
 > The only downside of that is that since it can't merge until py37 works,  
 > projects will end up continuing to run py35 tests until py37 support is  
 > ready to merge. But the upside is we only have to make one change for Train. 

I was thinking to update the Train runtime targets in 'openstack-python-jobs' project template
which is already present on each project side. If we use this template to update testing
runtime jobs each cycle then, we do not need to update all projects.

Any drop of py version or addition will be done at a single place and with consistency. 

-gmann

 >  
 > > Stable/Stein: Ok to drop if the project wants. 
 > > Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too. 
 > > But backporting all the patches will be too many patches for projects to merge on stable/stein so 
 > > we discussed not to propose all of them to stable/stein. If the project really wants to drop it from 
 > > stable/stein then, they can backport. 
 > >  
 > > NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate 
 > > the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL. 
 > >  
 > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html 
 > > [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html 
 > >         http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html 
 > >  
 > > -gmann 
 > >  
 > >  
 >  
 >  
 > 



From anteaya at anteaya.info  Mon Apr 15 15:52:31 2019
From: anteaya at anteaya.info (Anita Kuno)
Date: Mon, 15 Apr 2019 11:52:31 -0400
Subject: [all] Gerrit will be offline April 19, 2019
In-Reply-To: <577b43b5-b17a-4f01-22a6-c0e6018c5dca@anteaya.info>
References: <577b43b5-b17a-4f01-22a6-c0e6018c5dca@anteaya.info>
Message-ID: <6c77fa23-2e80-1d3e-1aa0-ffd402f4a710@anteaya.info>

On 2019-04-12 12:48 p.m., Anita Kuno wrote:
> Pursuant to this email thread: 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html 
> , which discusses the rationale for moving git repo namespaces, Gerrit 
> will be offline on April 19, 2019. Specific start time for the outage 
> will be posted to this thread when it is decided next week. Outage may 
> be sporadic as needed by the infra team, you can follow the progress in 
> the #openstack-infra irc channel on freenode.
> 
> Please review the above linked email and all the subsequent posts, and 
> please post any concerns about the rationale or details to the above 
> thread. If you have concerns about the Gerrit outage scheduled to begin 
> April 19, 2019, please reply to this thread and/or join us in 
> #openstack-infra on freenode to share your questions or concerns.
> 
> Thank you,
> Anita

Bumping this post to ensure Monday inboxes receive it.

Thank you,
Anita


From gmann at ghanshyammann.com  Mon Apr 15 15:52:25 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 15 Apr 2019 10:52:25 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <db83f86edb7d5cdd1f7e24e6fbefc4270ddddb1a.camel@redhat.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <32b7bb26b39b349a3026754f07ad982c92d1d3db.camel@redhat.com>
 <20190415142147.GA24916@sm-workstation>
 <db83f86edb7d5cdd1f7e24e6fbefc4270ddddb1a.camel@redhat.com>
Message-ID: <16a21b31381.cc3635e18918.7214639241878327646@ghanshyammann.com>

 ---- On Mon, 15 Apr 2019 10:33:54 -0500 Sean Mooney <smooney at redhat.com> wrote ----
 > On Mon, 2019-04-15 at 09:21 -0500, Sean McGinnis wrote: 
 > > > > we are good to drop the py35 testing. 
 > > > >  
 > > > > Train: Good to drop. 
 > > > > I am going to push the patches to remove the py35 jobs from the master (which is Train now). 
 > > >  
 > > > so i asked this a number of months ago and at the time i did not get a concreate answer. 
 > > > if we drop py35 testing that means we are increaseing our minium python 3 version to py36 
 > > >  
 > >  
 > > Yes, following our policy of using the python version supported on the distros 
 > > we target at the beginning of the cycle. the Stein minimum py3 version was 
 > > Python 3.6 [0]. 
 > ok so we should we update teh setup cfg markers to reflect that? 
 > we still state 3.5 on nova master  
 > https://github.com/openstack/nova/blob/78e742662edd164c46382c31e106884762fed029/setup.cfg#L18-L19 

+1, that has been updated as part of this - https://review.openstack.org/#/c/643871/

-gmann

 >  
 > >  
 > > > so projects are free to use python 3.6 only feature correct once py2.7 support is removed. 
 > > >  
 > >  
 > > Dropping py2 support is currently planned for the U release cycle. 
 > yes i know what i was getting at is becauese we still have to support pyton 2.7 in train 
 > the subset of lanague feautres we can currently use is what is support on python 2.7 and 
 > also work son python 3.6 
 >  
 > meaning we cannot use any python3 only feature until U. 
 > >  
 > > > i recently found out that nova does not work on py37 and if we have no testing for py35 then 
 > > > its possible that we could also break there so if this goes ahead i want to carify that for train 
 > > > the only supported python veriosn will by py27 and py36 unless we elect to add py37 support as a train 
 > > > goal. 
 > > > >  
 > >  
 > > Failures on py3.7 will need to be addressed as that is one of the Python 
 > > runtimes required for Train [1]. 
 > i have not dug into the failure other than to know that the agent hangs or crashes when you boot a vm with 
 > no error messages of any kind in journalctl. 
 > so we will need to fix it but at this point it could be anything form eventlet not working properly to we have some 
 > python27/36 only code on the spawn codepath. 
 >  
 > the fact that even with devstack and debug loggin enabeld the output just stops makes i hard figure out whats actully 
 > going on but i also have not dug into it much yet. 
 >  
 > >  
 > > [0] https://governance.openstack.org/tc/reference/runtimes/stein.html 
 > > [1] https://governance.openstack.org/tc/reference/runtimes/train.html 
 >  
 >  
 > 



From mark at stackhpc.com  Mon Apr 15 16:05:12 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 15 Apr 2019 17:05:12 +0100
Subject: [kayobe] No IRC meeting on 29th April
Message-ID: <CAFHSqWqHNbSLAxBpJPrfuBgTpcopscedHd1NcUWoDUf0qz=Rog@mail.gmail.com>

Hi,

We'll cancel the next IRC meeting due to the OpenStack summit. Please bring
up any items in #openstack-kayobe on an ad-hoc basis.

Thanks,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/5011963e/attachment.html>

From mark at stackhpc.com  Mon Apr 15 16:08:04 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 15 Apr 2019 17:08:04 +0100
Subject: [kolla] No IRC meeting on 17th April
Message-ID: <CAFHSqWqc15OhdqR_bKOWjerU-egYT6FeTQNtgeWz=QLxmvjcCw@mail.gmail.com>

Hi,

I'm cancelling this weeks IRC meeting because I'm on vacation from tomorrow
until 24th April and nobody offered to chair. Please continue to coordinate
in #openstack-kolla. Focus should be on testing the upcoming Stein release
and fixing bugs.

Thanks,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/909ce9f6/attachment.html>

From colleen at gazlene.net  Mon Apr 15 16:42:33 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Mon, 15 Apr 2019 12:42:33 -0400
Subject: [keystone] Team dinner in Denver
Message-ID: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>

Berlin feels like it was ages ago, so let's organize a team dinner in Denver. Poll here:

https://framadate.org/BHNNU9S3f9N3lasH

If you have strong feelings or even mild inclinations about where to go, please comment on the poll or in the brainstorming etherpad[1] because otherwise I am pretty much just going to throw a dart.

Colleen

[1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions


From skaplons at redhat.com  Mon Apr 15 17:01:04 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 15 Apr 2019 19:01:04 +0200
Subject: [neutron] Bug deputy report - week 8.04 - 15.04
Message-ID: <2471CA0D-956D-4F12-B80D-FA6EE72D9381@redhat.com>

Hi,

I was on bug deputy last week. Below is summary of bugs reported this week.

There is couple of bugs which require help from the team:

High:
https://bugs.launchpad.net/neutron/+bug/1824299 - Race condition during init may lead to neutron server malfunction - marked as High, there is no volunteer for this one, someone needs to take a look into it.

https://bugs.launchpad.net/neutron/+bug/1824571 - l3agent can't create router if there are multiple external networks - I confirmed it today, it looks that when there is more than one network marked as „external” than router can’t be created properly. It looks that it is quite serious one and someone from L3 sub team should take a look into it


Medium:
https://bugs.launchpad.net/neutron/+bug/1824799 - neutron dhcp agent looks for external pid unexpectedly - volunteer for this one is needed, if there will be no any I will take a look for this bug,


Low:
https://bugs.launchpad.net/neutron/+bug/1824788 - [DOCS] installed neutron, but no provider network exists - volunteer needed,


Also I would like to ask team about this one:
https://bugs.launchpad.net/neutron/+bug/1818682 - issue in keepalived 1.2.24 - user asked about list of software (and versions) compatible with neutron. Do we have anything like that?


And now list of all other bugs from this week:

Critical
https://bugs.launchpad.net/neutron/+bug/1823865 - [neutron][networking-ovn] The function provider_network_attribute_updates_supported is breaking networking-ovn gate - marked as critical because it broke gate for stadium project - fix already released, thx Rodolfo.


High
https://bugs.launchpad.net/kolla/+bug/1823818 - Memory leak in some neutron agents - set to high but in fact this issue is in openvswitch, not in neutron agents directly, I marked it as invalid in neutron as fix is in openvswitch already,

https://bugs.launchpad.net/neutron/+bug/1824095 - Fullstack job broken in stable/stein branch - I set to High and not to urgent because fullstack job is non-voting in stein currently so it’s not blocking gate completely - fix already merged (https://review.openstack.org/#/c/651458/) - thx again Rodolfo :)

https://bugs.launchpad.net/neutron/+bug/1824138 - Fullstack QoS tests should not handle other tests port events - marked as High because it’s causing gate failures - fix already proposed by Rodolfo (again): https://review.openstack.org/#/c/651523/ - please review it,


Medium
https://bugs.launchpad.net/neutron/+bug/1823798 - rfp and fpr interfaces not updated after changing network MTU - fixed by Brian already - thx Brian,

https://bugs.launchpad.net/neutron/+bug/1824178 - SQLAlchemy broke association proxy into a descriptor + per-class accessor - fix proposed by Rodolfo (is anyone else except Rodolfo working in Neutron now? :P) - https://review.openstack.org/#/c/651584/

https://bugs.launchpad.net/neutron/+bug/1824346 - Check in "_update_segmentation_id" that the mech_driver has an agent - fix proposed by (what a surprise) … Rodolfo - https://review.openstack.org/#/c/651878/

https://bugs.launchpad.net/neutron/+bug/1824504 - arp responder will be created for a vlan port when port ip changed - fix proposed already https://review.openstack.org/652043

https://bugs.launchpad.net/neutron/+bug/1824566 - DVR-Nexthop static routes are not getting configured in FIP Namespace when disassociating and reassociating a FloatingIP in Ocata - only for Ocata, looks that it don’t affects newer releases, fix proposed https://review.openstack.org/652122

Low
https://bugs.launchpad.net/neutron/+bug/1823716 - (DOCS) url --> endpoint_template in Install and configure controller node in neutron section of nova.conf - there is volunteer for this one already assigned

RFE
* https://bugs.launchpad.net/neutron/+bug/1823633 - [RFE] L3 - netfilter Contrack Helper Support - already approved by drivers team (that was fast)

Others
https://bugs.launchpad.net/neutron/+bug/1824107 - marked as duplicate of https://bugs.launchpad.net/neutron/+bug/1808112


So the winner of "bug fixer of the week” title is definitely Rodolfo :)

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From zbitter at redhat.com  Mon Apr 15 17:02:41 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Mon, 15 Apr 2019 13:02:41 -0400
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
Message-ID: <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>

On 15/04/19 11:01 AM, Bence Romsics wrote:
> On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra at redhat.com> wrote:
>> I think this had been discussed on several occasions[1] before and one of the
>> suggestions from the neutron team was to use compare-and-swap update api [2]
>> to avoid race conditions.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html
>>   [2] https://bugs.launchpad.net/neutron/+bug/1703234
> 
> Thank you for your quick answer. I did read that previous discussion
> and I did not properly understand why compare-and-swap was
> recommended. To my understanding compare-and-swap allows a client to
> detect a race with another, but it would not eliminate the races. All
> clients would have to retry until success and with the current
> OS::Neutron::ExtraRoute we do actively generate those races. That's
> why I went in the directions mentioned in my original mail. Am I
> missing something?

Yes, you have to do it in a loop. So instead of just:

* read the current status
* add the new route to the data
* write back the whole thing

you'd need to do:

* read the current status and remember the ETag
* add the new route to the data
* write back the whole thing with If-Match
* if the write is rejected with status code 412, go back to the beginning

IMHO the best place to implement this would be in 
neutronclient/openstacksdk and not Heat, because the problem is inherent 
to the API and exists everywhere. However, I wouldn't reject a fix in Heat.

cheers,
Zane.


From skaplons at redhat.com  Mon Apr 15 17:03:49 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 15 Apr 2019 19:03:49 +0200
Subject: [neutron] Bug deputy report - week 8.04 - 15.04
In-Reply-To: <2471CA0D-956D-4F12-B80D-FA6EE72D9381@redhat.com>
References: <2471CA0D-956D-4F12-B80D-FA6EE72D9381@redhat.com>
Message-ID: <A604E9D0-5151-4037-AEED-CFCD43EE4918@redhat.com>

Hi again,

I missed one more bug which I just marked as „High”:

https://bugs.launchpad.net/neutron/+bug/1824802 - dhcp agent dnsmasq process mgmt race condition between launch and operations - there is volunteer for this one needed too if someone would have some free cycles :)

> Wiadomość napisana przez Slawomir Kaplonski <skaplons at redhat.com> w dniu 15.04.2019, o godz. 19:01:
> 
> Hi,
> 
> I was on bug deputy last week. Below is summary of bugs reported this week.
> 
> There is couple of bugs which require help from the team:
> 
> High:
> https://bugs.launchpad.net/neutron/+bug/1824299 - Race condition during init may lead to neutron server malfunction - marked as High, there is no volunteer for this one, someone needs to take a look into it.
> 
> https://bugs.launchpad.net/neutron/+bug/1824571 - l3agent can't create router if there are multiple external networks - I confirmed it today, it looks that when there is more than one network marked as „external” than router can’t be created properly. It looks that it is quite serious one and someone from L3 sub team should take a look into it
> 
> 
> Medium:
> https://bugs.launchpad.net/neutron/+bug/1824799 - neutron dhcp agent looks for external pid unexpectedly - volunteer for this one is needed, if there will be no any I will take a look for this bug,
> 
> 
> Low:
> https://bugs.launchpad.net/neutron/+bug/1824788 - [DOCS] installed neutron, but no provider network exists - volunteer needed,
> 
> 
> Also I would like to ask team about this one:
> https://bugs.launchpad.net/neutron/+bug/1818682 - issue in keepalived 1.2.24 - user asked about list of software (and versions) compatible with neutron. Do we have anything like that?
> 
> 
> And now list of all other bugs from this week:
> 
> Critical
> https://bugs.launchpad.net/neutron/+bug/1823865 - [neutron][networking-ovn] The function provider_network_attribute_updates_supported is breaking networking-ovn gate - marked as critical because it broke gate for stadium project - fix already released, thx Rodolfo.
> 
> 
> High
> https://bugs.launchpad.net/kolla/+bug/1823818 - Memory leak in some neutron agents - set to high but in fact this issue is in openvswitch, not in neutron agents directly, I marked it as invalid in neutron as fix is in openvswitch already,
> 
> https://bugs.launchpad.net/neutron/+bug/1824095 - Fullstack job broken in stable/stein branch - I set to High and not to urgent because fullstack job is non-voting in stein currently so it’s not blocking gate completely - fix already merged (https://review.openstack.org/#/c/651458/) - thx again Rodolfo :)
> 
> https://bugs.launchpad.net/neutron/+bug/1824138 - Fullstack QoS tests should not handle other tests port events - marked as High because it’s causing gate failures - fix already proposed by Rodolfo (again): https://review.openstack.org/#/c/651523/ - please review it,
> 
> 
> Medium
> https://bugs.launchpad.net/neutron/+bug/1823798 - rfp and fpr interfaces not updated after changing network MTU - fixed by Brian already - thx Brian,
> 
> https://bugs.launchpad.net/neutron/+bug/1824178 - SQLAlchemy broke association proxy into a descriptor + per-class accessor - fix proposed by Rodolfo (is anyone else except Rodolfo working in Neutron now? :P) - https://review.openstack.org/#/c/651584/
> 
> https://bugs.launchpad.net/neutron/+bug/1824346 - Check in "_update_segmentation_id" that the mech_driver has an agent - fix proposed by (what a surprise) … Rodolfo - https://review.openstack.org/#/c/651878/
> 
> https://bugs.launchpad.net/neutron/+bug/1824504 - arp responder will be created for a vlan port when port ip changed - fix proposed already https://review.openstack.org/652043
> 
> https://bugs.launchpad.net/neutron/+bug/1824566 - DVR-Nexthop static routes are not getting configured in FIP Namespace when disassociating and reassociating a FloatingIP in Ocata - only for Ocata, looks that it don’t affects newer releases, fix proposed https://review.openstack.org/652122
> 
> Low
> https://bugs.launchpad.net/neutron/+bug/1823716 - (DOCS) url --> endpoint_template in Install and configure controller node in neutron section of nova.conf - there is volunteer for this one already assigned
> 
> RFE
> * https://bugs.launchpad.net/neutron/+bug/1823633 - [RFE] L3 - netfilter Contrack Helper Support - already approved by drivers team (that was fast)
> 
> Others
> https://bugs.launchpad.net/neutron/+bug/1824107 - marked as duplicate of https://bugs.launchpad.net/neutron/+bug/1808112
> 
> 
> So the winner of "bug fixer of the week” title is definitely Rodolfo :)
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From mriedemos at gmail.com  Mon Apr 15 17:04:17 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 15 Apr 2019 12:04:17 -0500
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
Message-ID: <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>

On 4/15/2019 10:36 AM, Nicolas Ghirlanda wrote:
> New VMs  are just currently always scheduled to the same compute node, 
> even though a manual live-migration is working fine to other compute nodes.

How are you doing the live migration? If you're using the openstack 
command line and defaulting to the 2.1 compute API microversion, you're 
forcing the server to another host by bypassing the scheduler which is 
maybe why live migration is "working" but server create is not ever 
using the other computes.

> 
> 
> We're not sure, what the issue is, but perhaps someone may spot it from 
> our config:
> 
> 
> # nova.conf  scheduler config
> 
> default_availability_zone = az1

How many computes are in az1? All 8?

> 
> ...
> 
> [filter_scheduler]
> available_filters = nova.scheduler.filters.all_filters
> enabled_filters = RetryFilter, AvailabilityZoneFilter, 
> ComputeCapabilitiesFilter, ImagePropertiesFilter, 
> ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, 
> AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation, 
> DifferentHostFilter, RamFilter, SameHostFilter, NUMATopologyFilter
> 

Not really related to this probably but you can remove RamFilter since 
placement does the MEMORY_MB filtering and the RamFilter was deprecated 
in Stein as a result.

It looks like you're getting the default host_subset_size value:

https://docs.openstack.org/nova/queens/configuration/config.html#filter_scheduler.host_subset_size

Which means your scheduler is "packing" by default. If you have multiple 
computes and you want to spread instances across them, you can adjust 
the host_subset_size value.

> 
> 
> Database is an external Percona XtraDB Cluster (Version 5.7.24) with 
> haproxy for read-write-splitting (currently only one write node).
> 
> We do see mysql errors in the nova-scheduler.log on the write DB node 
> when an instance is created.
> 
> 
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db [-] 
> Unexpected error while reporting service status: OperationalError: 
> (pymysql.err.OperationalError) (1213, u'WSREP detected deadlock/conflict 
> and aborted the transaction. Try restarting the transaction') 
> (Background on this error at: http://sqlalche.me/e/e3q8)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db Traceback 
> (most recent call last):
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py", 
> line 91, in _report_state
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> service.service_ref.save()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py", 
> line 226, in wrapper
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
> fn(self, *args, **kwargs)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/service.py", 
> line 397, in save
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db db_service 
> = db.service_update(self._context, self.id, updates)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/api.py", 
> line 183, in service_update
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
> IMPL.service_update(context, service_id, values)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
> line 154, in wrapper
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> ectxt.value = e.inner_exc
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
> line 220, in __exit__
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.force_reraise()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
> line 196, in force_reraise
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> six.reraise(self.type_, self.value, self.tb)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
> line 142, in wrapper
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
> f(*args, **kwargs)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", 
> line 227, in wrapped
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
> f(context, *args, **kwargs)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.gen.next()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
> line 1043, in _transaction_scope
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db yield 
> resource
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.gen.next()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
> line 653, in _session
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.session.rollback()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
> line 220, in __exit__
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.force_reraise()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
> line 196, in force_reraise
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> six.reraise(self.type_, self.value, self.tb)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
> line 650, in _session
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self._end_session_transaction(self.session)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
> line 678, in _end_session_transaction
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> session.commit()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
> line 943, in commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.transaction.commit()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
> line 471, in commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db t[1].commit()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
> line 1643, in commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self._do_commit()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
> line 1674, in _do_commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.connection._commit_impl()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
> line 726, in _commit_impl
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self._handle_dbapi_exception(e, None, None, None, None)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
> line 1409, in _handle_dbapi_exception
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> util.raise_from_cause(newraise, exc_info)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", 
> line 265, in raise_from_cause
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> reraise(type(exception), exception, tb=exc_tb, cause=cause)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
> line 724, in _commit_impl
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self.engine.dialect.do_commit(self.connection)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py", 
> line 1765, in do_commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> dbapi_connection.commit()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
> line 422, in commit
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> self._read_ok_packet()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
> line 396, in _read_ok_packet
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db pkt = 
> self._read_packet()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
> line 683, in _read_packet
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> packet.check_error()
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/protocol.py", 
> line 220, in check_error
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> err.raise_mysql_exception(self._data)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/err.py", 
> line 109, in raise_mysql_exception
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db raise 
> errorclass(errno, errval)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
> OperationalError: (pymysql.err.OperationalError) (1213, u'WSREP detected 
> deadlock/conflict and aborted the transaction. Try restarting the 
> transaction') (Background on this error at: http://sqlalche.me/e/e3q8)
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> 2019-04-15 16:52:20.020 24 INFO nova.servicegroup.drivers.db [-] 
> Recovered from being unable to report status.

This is a service update operation which could indicate that the other 
computes are reported as 'down' and that's why nothing is getting 
scheduled to them. Have you checked the "openstack compute service list" 
output to make sure those computes are all reporting as "up"?

https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-list

There is a retry_on_deadlock decorator on that service_update DB API 
though so I'm kind of surprised to still see the deadlock errors, unless 
those just get logged while retrying?

https://github.com/openstack/nova/blob/stable/queens/nova/db/sqlalchemy/api.py#L566

> 
> 
> The deadlock message is quite strange, as we have haproxy configured so 
> all write requests are handled by one node.
> 
> 
> There are NO errors in the mysqld.log WHILE creating an instance, but we 
> see from time to time aborted connections from nova.
> 
> 2019-04-15T14:22:36.232108Z 30616972 [Note] Aborted connection 30616972 
> to db: 'nova' user: 'nova' host: '10.x.y.z' (Got an error reading 
> communication packets)
> 
> 
> 
> As I said, all instances are allocated to the same compute node. 
> nova-compute.log doesn't show an error while creating the instance.
> 
> 
> Beside that, we also see messages from nova.scheduler.host_manager on 
> all other nodes like (but those messages are _not_ triggered, when an 
> instance is spawned.!)
> 
> 
> 2019-04-15 16:28:47.771 22 INFO nova.scheduler.host_manager 
> [req-f92e340e-a88a-44a0-8cad-588390c25bc2 - - - - -] The instance sync 
> for host 'xxx' did not match. Re-created its InstanceList.

Are there any instances on these other hosts? My guess is you're seeing 
that after the live migration to another host.

> 
> 
> 
> Don't know if that may be relevant, but somehow our (currently single) 
> AZ is listed several times.
> 
> 
> # openstack availability zone list
> +------------+-------------+
> | Zone Name  | Zone Status |
> +------------+-------------+
> | internal   | available   |
> | az1 | available           |
> | az1 | available           |
> | az1 | available           |
> | az1 | available           |
> +------------+-------------+
> 
> May that be related somehow?

I believe those are the AZs for other services as well (cinder/neutron). 
Specify the --compute option to filter that.

--

Another thing to check is placement - are there 8 compute node resource 
providers reporting into placement? You can check using the CLI:

https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list

In Queens, there should be one resource provider per working compute 
node in the cell database's compute_nodes table (the UUIDs should match 
as well).

-- 

Thanks,

Matt


From gmann at ghanshyammann.com  Mon Apr 15 17:14:11 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 15 Apr 2019 12:14:11 -0500
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a21ac27fe.11abf9b078630.6641890910997380340@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <457e9c1d-2713-79f1-de98-4a1fd2abd928@redhat.com>
 <16a21ac27fe.11abf9b078630.6641890910997380340@ghanshyammann.com>
Message-ID: <16a21fdef07.c8e5aa4b344735.4650846513002262805@ghanshyammann.com>

 ---- On Mon, 15 Apr 2019 10:44:51 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Mon, 15 Apr 2019 09:45:06 -0500 Zane Bitter <zbitter at redhat.com> wrote ---- 
 >  > On 14/04/19 2:48 PM, Ghanshyam Mann wrote:  
 >  > > Hello Everyone,  
 >  > >   
 >  > > All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],  
 >  > > we are good to drop the py35 testing.  
 >  > >   
 >  > > Train: Good to drop.  
 >  > > I am going to push the patches to remove the py35 jobs from the master (which is Train now).  
 >  >   
 >  > +1  
 >  >   
 >  > Can I suggest that you instead push patches to switch to   
 >  > openstack-python3-train-jobs?  
 >  >   
 >  > The only downside of that is that since it can't merge until py37 works,   
 >  > projects will end up continuing to run py35 tests until py37 support is   
 >  > ready to merge. But the upside is we only have to make one change for Train.  
 >  
 > I was thinking to update the Train runtime targets in 'openstack-python-jobs' project template 
 > which is already present on each project side. If we use this template to update testing 
 > runtime jobs each cycle then, we do not need to update all projects. 
 >  
 > Any drop of py version or addition will be done at a single place and with consistency.  

Another reason I kept it separate from Train testing runtime is that if any project wants to backport py35
dropping to stable/stein then, they can do with this patchset. 

-gmann

 >  
 > -gmann 
 >  
 >  >   
 >  > > Stable/Stein: Ok to drop if the project wants.  
 >  > > Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.  
 >  > > But backporting all the patches will be too many patches for projects to merge on stable/stein so  
 >  > > we discussed not to propose all of them to stable/stein. If the project really wants to drop it from  
 >  > > stable/stein then, they can backport.  
 >  > >   
 >  > > NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate  
 >  > > the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.  
 >  > >   
 >  > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html  
 >  > > [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html  
 >  > >         http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html  
 >  > >   
 >  > > -gmann  
 >  > >   
 >  > >   
 >  >   
 >  >   
 >  >  
 > 



From sxmatch1986 at gmail.com  Mon Apr 15 17:21:14 2019
From: sxmatch1986 at gmail.com (hao wang)
Date: Tue, 16 Apr 2019 01:21:14 +0800
Subject: [cinder][emc-unisphere]Need help: Some exception raise when using
 IPV6 to connect the EMC unisphere.
Message-ID: <CAOEh+o0MoPS145Sz6tEtyWGaZQ3aWTm1n=skZ=wW11j-671fTw@mail.gmail.com>

hi guys:

Now I was using unisphere 4.4 as cinder's backend with ipv6 address.
But there is an exception when I try to start the cinder volume:

2019-04-15 17:14:25.832 25795 DEBUG storops.connection.client
[req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] REQ URL: [GET]
https://[2019:c:0:0:0:0:0:220]:443/api/types/basicSystemInfo?compact=True&fields=attributes.description,attributes.displayValue,attributes.initialValue,attributes.name,attributes.type,description,documentation,name,type,
TIME: 0.019809961319, RESP CODE: 400 log_response
/usr/local/lib/python2.7/site-packages/storops/connection/client.py:186
2019-04-15 17:14:25.833 25795 DEBUG storops.connection.client
[req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] RESP BODY:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
 _debug_print_json
/usr/local/lib/python2.7/site-packages/storops/connection/client.py:179

I have configured the ipv6 and ipv4 address in unisphere and it
connected well with my cinder volume node. When I switched the unify
driver to ipv4 san ip in cinder.conf, it worked well....  So I really
didn't get where is wrong.

Could guys help me out here?  thanks.


From skaplons at redhat.com  Mon Apr 15 17:23:22 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 15 Apr 2019 19:23:22 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
Message-ID: <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>

Hi,

> Wiadomość napisana przez Zane Bitter <zbitter at redhat.com> w dniu 15.04.2019, o godz. 19:02:
> 
> On 15/04/19 11:01 AM, Bence Romsics wrote:
>> On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra at redhat.com> wrote:
>>> I think this had been discussed on several occasions[1] before and one of the
>>> suggestions from the neutron team was to use compare-and-swap update api [2]
>>> to avoid race conditions.
>>> 
>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html
>>>  [2] https://bugs.launchpad.net/neutron/+bug/1703234
>> Thank you for your quick answer. I did read that previous discussion
>> and I did not properly understand why compare-and-swap was
>> recommended. To my understanding compare-and-swap allows a client to
>> detect a race with another, but it would not eliminate the races. All
>> clients would have to retry until success and with the current
>> OS::Neutron::ExtraRoute we do actively generate those races. That's
>> why I went in the directions mentioned in my original mail. Am I
>> missing something?
> 
> Yes, you have to do it in a loop. So instead of just:
> 
> * read the current status
> * add the new route to the data
> * write back the whole thing
> 
> you'd need to do:
> 
> * read the current status and remember the ETag
> * add the new route to the data
> * write back the whole thing with If-Match
> * if the write is rejected with status code 412, go back to the beginning
> 
> IMHO the best place to implement this would be in neutronclient/openstacksdk and not Heat, because the problem is inherent to the API and exists everywhere. However, I wouldn't reject a fix in Heat.

IMO option 2 provided by Bence is the best one here. This should be fixed in neutron API by making extra routes first class API objects and treat them as router interfaces. DB layer is „ready” for that IMO so it should be handled easy.
All other ways it will just be kind of workaround of the issue. Even if we will fix it in OpenStack SDK and/or neutron client there may be someone who is using API in some other way and will still hit the same issue.

> 
> cheers,
> Zane.
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From zbitter at redhat.com  Mon Apr 15 18:06:18 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Mon, 15 Apr 2019 14:06:18 -0400
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
 <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
Message-ID: <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>

On 15/04/19 1:23 PM, Slawomir Kaplonski wrote:
> Hi,
> 
>> Wiadomość napisana przez Zane Bitter <zbitter at redhat.com> w dniu 15.04.2019, o godz. 19:02:
>>
>> On 15/04/19 11:01 AM, Bence Romsics wrote:
>>> On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra at redhat.com> wrote:
>>>> I think this had been discussed on several occasions[1] before and one of the
>>>> suggestions from the neutron team was to use compare-and-swap update api [2]
>>>> to avoid race conditions.
>>>>
>>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html
>>>>   [2] https://bugs.launchpad.net/neutron/+bug/1703234
>>> Thank you for your quick answer. I did read that previous discussion
>>> and I did not properly understand why compare-and-swap was
>>> recommended. To my understanding compare-and-swap allows a client to
>>> detect a race with another, but it would not eliminate the races. All
>>> clients would have to retry until success and with the current
>>> OS::Neutron::ExtraRoute we do actively generate those races. That's
>>> why I went in the directions mentioned in my original mail. Am I
>>> missing something?
>>
>> Yes, you have to do it in a loop. So instead of just:
>>
>> * read the current status
>> * add the new route to the data
>> * write back the whole thing
>>
>> you'd need to do:
>>
>> * read the current status and remember the ETag
>> * add the new route to the data
>> * write back the whole thing with If-Match
>> * if the write is rejected with status code 412, go back to the beginning
>>
>> IMHO the best place to implement this would be in neutronclient/openstacksdk and not Heat, because the problem is inherent to the API and exists everywhere. However, I wouldn't reject a fix in Heat.
> 
> IMO option 2 provided by Bence is the best one here. This should be fixed in neutron API by making extra routes first class API objects and treat them as router interfaces. DB layer is „ready” for that IMO so it should be handled easy.
> All other ways it will just be kind of workaround of the issue. Even if we will fix it in OpenStack SDK and/or neutron client there may be someone who is using API in some other way and will still hit the same issue.

Oh, for sure. If Neutron is willing to do that then that is definitely 
the best solution. (As you say, there are other non-Python clients that 
also need to implement the If-Match thing to work reliably with the 
current API.) Double points for not making another "extension" API and 
just saying this is either something Neutron can do or not.

- ZB


From fungi at yuggoth.org  Mon Apr 15 18:35:27 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 15 Apr 2019 18:35:27 +0000
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a21fdef07.c8e5aa4b344735.4650846513002262805@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
 <457e9c1d-2713-79f1-de98-4a1fd2abd928@redhat.com>
 <16a21ac27fe.11abf9b078630.6641890910997380340@ghanshyammann.com>
 <16a21fdef07.c8e5aa4b344735.4650846513002262805@ghanshyammann.com>
Message-ID: <20190415183526.54naxois3agyahuh@yuggoth.org>

On 2019-04-15 12:14:11 -0500 (-0500), Ghanshyam Mann wrote:
[...]
> Another reason I kept it separate from Train testing runtime is
> that if any project wants to backport py35 dropping to
> stable/stein then, they can do with this patchset.
[...]

In the past the stable branch managers have considered that changes
to package metadata and test configuration don't need to follow
strict backporting rules, so I guess it's a balance between being
able to make these clean backports (even though it may not be
entirely necessary) vs creating additional changes.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190415/47757613/attachment.sig>

From ricardo at palmtx.com.ar  Mon Apr 15 20:21:57 2019
From: ricardo at palmtx.com.ar (Ricardo J. Barberis)
Date: Mon, 15 Apr 2019 17:21:57 -0300
Subject: Disabling SSLv3, TLSv1.0 and TLSv1.1 in nova-novncproxy?
In-Reply-To: <0f58c704-5df1-fc65-f90f-1cc6664a0601@gmail.com>
References: <201904121547.28259.ricardo@palmtx.com.ar>
 <0f58c704-5df1-fc65-f90f-1cc6664a0601@gmail.com>
Message-ID: <201904151721.57589.ricardo@palmtx.com.ar>

El Viernes 12/04/2019 a las 19:09, melanie witt escribió:
> On Fri, 12 Apr 2019 15:47:28 -0300, Ricardo J. Barberis
>
> <ricardo at palmtx.com.ar> wrote:
> > Hello list,
> >
> > I've been tasked with disabling SSLv3, TLSv1.0 and TLSv1.1 in all of our
> > public endpoints (not only OpenStack) and I'm having trouble finding
> > where does nova-novncproxy sets which protocols to use.
> >
> > I have nova-novncproxy installed in 2 servers, one CentOS 6.10 (python
> > 2.6) tied to an IceHouse installation, the other a CentOS 7 (python 2.7)
> > tied to a Queens installation.
> >
> >
> > Software versions:
> >
> > [root at vnc01 ~] # rpm -qa \*nova\* \*vnc\* | sort
> > novnc-0.4-8.el6.noarch
> > openstack-nova-common-2014.1.5-1.el6.noarch
> > openstack-nova-novncproxy-2014.1.5-1.el6.noarch
> > python-nova-2014.1.5-1.el6.noarch
> > python-novaclient-2.17.0-2.el6.noarch
> >
> > [root at vnc02 ~] # rpm -qa \*nova\* \*vnc\* | sort
> > novnc-0.5.1-2.el7.noarch
> > openstack-nova-common-17.0.9-1.el7.noarch
> > openstack-nova-novncproxy-17.0.9-1.el7.noarch
> > python-nova-17.0.9-1.el7.noarch
> > python2-novaclient-10.1.0-1.el7.noarch
> >
> >
> > Any pointers will be appreciated.
> >
> > BTW, I also tried proxying them with nginx but in that case the vnc
> > console doesn't work. I didn't try too hard to debug it, though.
>
> TL;DR: The protocol version is handled automatically.
>
> The nova-novncproxy is a websockify server and it is in websockify code
> where the socket is wrapped for SSL [1]. By default, wrap_socket [2]
> uses the PROTOCOL_SSLv23 constant. In python 2.6, it "Selects SSL
> version 2 or 3 as the channel encryption protocol." [3]. In python 2.7,
> it's an alias for PROTOCOL_TLS and "Selects the highest protocol version
> that both the client and server support." The available versions with
> PROTOCOL_SSLv23 depend on the openssl version being used [5].
>
> Hope this helps.

Thanks, it clarifies a lot :)


> -melanie
>
> [1]
> https://github.com/novnc/websockify/blob/e4658ada2e2e179cdb8f6362dbb7c5e3ce
>3ff717/websockify/websockifyserver.py#L585 [2]
> https://docs.python.org/2/library/ssl.html#ssl.wrap_socket
> [3] https://docs.python.org/2.6/library/ssl.html#ssl.PROTOCOL_SSLv23
> [4] https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_SSLv23
> [5] https://docs.python.org/2/library/ssl.html#id2

-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com


From jungleboyj at gmail.com  Mon Apr 15 20:53:31 2019
From: jungleboyj at gmail.com (Jay Bryant)
Date: Mon, 15 Apr 2019 15:53:31 -0500
Subject: [cinder][emc-unisphere]Need help: Some exception raise when using
 IPV6 to connect the EMC unisphere.
In-Reply-To: <CAOEh+o0MoPS145Sz6tEtyWGaZQ3aWTm1n=skZ=wW11j-671fTw@mail.gmail.com>
References: <CAOEh+o0MoPS145Sz6tEtyWGaZQ3aWTm1n=skZ=wW11j-671fTw@mail.gmail.com>
Message-ID: <3cd82d24-0d41-18ab-aff8-5e45ab10424e@gmail.com>

Unfortunately EMC doesn't monitor the mailing lists well.

I would recommend reaching out to Helen.Walsh at dell.com .  She can get 
you in touch with the right person to help.

Thanks!

Jay


On 4/15/2019 12:21 PM, hao wang wrote:
> hi guys:
>
> Now I was using unisphere 4.4 as cinder's backend with ipv6 address.
> But there is an exception when I try to start the cinder volume:
>
> 2019-04-15 17:14:25.832 25795 DEBUG storops.connection.client
> [req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] REQ URL: [GET]
> https://[2019:c:0:0:0:0:0:220]:443/api/types/basicSystemInfo?compact=True&fields=attributes.description,attributes.displayValue,attributes.initialValue,attributes.name,attributes.type,description,documentation,name,type,
> TIME: 0.019809961319, RESP CODE: 400 log_response
> /usr/local/lib/python2.7/site-packages/storops/connection/client.py:186
> 2019-04-15 17:14:25.833 25795 DEBUG storops.connection.client
> [req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] RESP BODY:
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>400 Bad Request</title>
> </head><body>
> <h1>Bad Request</h1>
> <p>Your browser sent a request that this server could not understand.<br />
> </p>
> </body></html>
>   _debug_print_json
> /usr/local/lib/python2.7/site-packages/storops/connection/client.py:179
>
> I have configured the ipv6 and ipv4 address in unisphere and it
> connected well with my cinder volume node. When I switched the unify
> driver to ipv4 san ip in cinder.conf, it worked well....  So I really
> didn't get where is wrong.
>
> Could guys help me out here?  thanks.
>


From mriedemos at gmail.com  Mon Apr 15 21:00:46 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 15 Apr 2019 16:00:46 -0500
Subject: [goals][upgrade-checkers] Retrospective
Message-ID: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>

Now that Stein is GA I figured I'd write up a quick retrospective for 
the upgrade-checkers goal [1].

Statistics
----------

 From the tasks in the story [2]:

- There were 52 total tasks.
- Merged: 40
- Review: 4 (still open)
- Invalid: 8* (not applicable or opted out)

Excluding Invalid tasks, the overall completion percentage of the goal 
was 91% which is pretty good. Granted, the majority of projects just 
added the placeholder framework for the upgrade check command which is 
not very useful for operators, but it's a start for those projects to 
build in real checks later.

*5 of the Invalid tasks were for deployment projects which were not a 
target for the goal [3]. The others were for swift, telemetry and panko.

oslo library
------------

To ease development, Ben Nemec extracted the framework of the nova check 
code into the oslo.upgradecheck library [4]. This made getting the 
framework in place for all projects much easier and ensures a high level 
of consistency in the command structure which is really important with 
this type of thing. Thanks again Ben!

Not universal
-------------

As mentioned above, not all projects implemented the command since it 
maybe didn't make sense for those projects (swift, mistral and adjutant 
are good examples) and other projects just aren't in a place 
development-wise to put much priority in the goal (telemetry and panko).

Extension points
----------------

Neutron created an extension point for their upgrade checks to support 
stadium projects and have already been using it. This was not something 
I thought about when we started the goal so it was cool that the neutron 
team embraced this and put their own spin on it.

Contributions from NEC developers
---------------------------------

Akhil Jain and Rajat Dhasmana from NEC volunteered to add the framework 
of the command in most projects which was extremely helpful. Thank you 
Akhil and Rajat, and NEC for providing development resources to work on 
a cross-community goal like this.

Next
----

While most projects have the framework in place for upgrade checks, a 
lot of projects released Stein with a simple placeholder check. A few 
projects have started adding real checks to aid in upgrades to Stein, 
which is great. I'm hopeful that other projects will add real checks as 
they encounter upgrade issues during Train development and need a way to 
signal those changes to operators in an automated way. Remember: if 
you're adding an upgrades release note, consider if you can automate 
that note.

Another next step is to get deployment projects to build in a call to 
each project's upgrade check command because without deployment projects 
using the tool it doesn't serve much purpose. Let me note that this does 
not need to be driven by the deployment projects either - developers 
from each project can integrate their check into a deployment project of 
choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment 
project dev teams would appreciate the service project teams driving 
this work.

[1] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
[2] https://storyboard.openstack.org/#!/story/2003657
[3] See the note: 
https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#completion-criteria
[4] https://docs.openstack.org/oslo.upgradecheck/latest/
[5] https://review.openstack.org/#/c/575125/

-- 

Thanks,

Matt


From giorgis at acmac.uoc.gr  Mon Apr 15 21:39:31 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Tue, 16 Apr 2019 00:39:31 +0300
Subject: [nova] - Stack VMs based on RAM
Message-ID: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>

 All,

 in the past I used to stack VMs based on RAM on hosts by putting the 
 following settings in my nova.conf file:

 ->ram_weight_multiplier=-1.0
 ->available_filters=nova.scheduler.filters.all_filters
 ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter


 I have now a Rocky installation and although I have set the above on my 
 controller node and restarted corresponding services the result when 
 spawning two VMs (one after another) is still to be distributed on two 
 different hosts. Seems that the something is missing in order to 
 override the default behavior.

 Any suggestions please?

 Best regards,

 G.


From mike.carden at gmail.com  Mon Apr 15 21:46:14 2019
From: mike.carden at gmail.com (Mike Carden)
Date: Tue, 16 Apr 2019 07:46:14 +1000
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
Message-ID: <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>

For what it's worth, we had a discussion about this in November last year:

http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000209.html

I made a comment at the end of that thread about a 'workaround' we have
used. It still happens here on Queens and the workaround doesn't solve it
permanently.

--
MC



On Tue, Apr 16, 2019 at 3:22 AM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/15/2019 10:36 AM, Nicolas Ghirlanda wrote:
> > New VMs  are just currently always scheduled to the same compute node,
> > even though a manual live-migration is working fine to other compute
> nodes.
>
> How are you doing the live migration? If you're using the openstack
> command line and defaulting to the 2.1 compute API microversion, you're
> forcing the server to another host by bypassing the scheduler which is
> maybe why live migration is "working" but server create is not ever
> using the other computes.
>
> >
> >
> > We're not sure, what the issue is, but perhaps someone may spot it from
> > our config:
> >
> >
> > # nova.conf  scheduler config
> >
> > default_availability_zone = az1
>
> How many computes are in az1? All 8?
>
> >
> > ...
> >
> > [filter_scheduler]
> > available_filters = nova.scheduler.filters.all_filters
> > enabled_filters = RetryFilter, AvailabilityZoneFilter,
> > ComputeCapabilitiesFilter, ImagePropertiesFilter,
> > ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter,
> > AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation,
> > DifferentHostFilter, RamFilter, SameHostFilter, NUMATopologyFilter
> >
>
> Not really related to this probably but you can remove RamFilter since
> placement does the MEMORY_MB filtering and the RamFilter was deprecated
> in Stein as a result.
>
> It looks like you're getting the default host_subset_size value:
>
>
> https://docs.openstack.org/nova/queens/configuration/config.html#filter_scheduler.host_subset_size
>
> Which means your scheduler is "packing" by default. If you have multiple
> computes and you want to spread instances across them, you can adjust
> the host_subset_size value.
>
> >
> >
> > Database is an external Percona XtraDB Cluster (Version 5.7.24) with
> > haproxy for read-write-splitting (currently only one write node).
> >
> > We do see mysql errors in the nova-scheduler.log on the write DB node
> > when an instance is created.
> >
> >
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db [-]
> > Unexpected error while reporting service status: OperationalError:
> > (pymysql.err.OperationalError) (1213, u'WSREP detected deadlock/conflict
> > and aborted the transaction. Try restarting the transaction')
> > (Background on this error at: http://sqlalche.me/e/e3q8)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db Traceback
> > (most recent call last):
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py",
>
> > line 91, in _report_state
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > service.service_ref.save()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
>
> > line 226, in wrapper
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return
> > fn(self, *args, **kwargs)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/service.py",
>
> > line 397, in save
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db db_service
> > = db.service_update(self._context, self.id, updates)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/api.py",
> > line 183, in service_update
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return
> > IMPL.service_update(context, service_id, values)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py",
> > line 154, in wrapper
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > ectxt.value = e.inner_exc
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
>
> > line 220, in __exit__
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.force_reraise()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
>
> > line 196, in force_reraise
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > six.reraise(self.type_, self.value, self.tb)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py",
> > line 142, in wrapper
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return
> > f(*args, **kwargs)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py",
>
> > line 227, in wrapped
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return
> > f(context, *args, **kwargs)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.gen.next()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
>
> > line 1043, in _transaction_scope
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db yield
> > resource
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.gen.next()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
>
> > line 653, in _session
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.session.rollback()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
>
> > line 220, in __exit__
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.force_reraise()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
>
> > line 196, in force_reraise
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > six.reraise(self.type_, self.value, self.tb)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
>
> > line 650, in _session
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self._end_session_transaction(self.session)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py",
>
> > line 678, in _end_session_transaction
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > session.commit()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
>
> > line 943, in commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.transaction.commit()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
>
> > line 471, in commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> t[1].commit()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
>
> > line 1643, in commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self._do_commit()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
>
> > line 1674, in _do_commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.connection._commit_impl()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
>
> > line 726, in _commit_impl
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self._handle_dbapi_exception(e, None, None, None, None)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
>
> > line 1409, in _handle_dbapi_exception
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > util.raise_from_cause(newraise, exc_info)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
>
> > line 265, in raise_from_cause
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > reraise(type(exception), exception, tb=exc_tb, cause=cause)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
>
> > line 724, in _commit_impl
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self.engine.dialect.do_commit(self.connection)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py",
>
> > line 1765, in do_commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > dbapi_connection.commit()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py",
>
> > line 422, in commit
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > self._read_ok_packet()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py",
>
> > line 396, in _read_ok_packet
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db pkt =
> > self._read_packet()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py",
>
> > line 683, in _read_packet
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > packet.check_error()
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> >
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/protocol.py",
>
> > line 220, in check_error
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > err.raise_mysql_exception(self._data)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File
> > "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/err.py",
> > line 109, in raise_mysql_exception
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db raise
> > errorclass(errno, errval)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > OperationalError: (pymysql.err.OperationalError) (1213, u'WSREP detected
> > deadlock/conflict and aborted the transaction. Try restarting the
> > transaction') (Background on this error at: http://sqlalche.me/e/e3q8)
> > 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
> > 2019-04-15 16:52:20.020 24 INFO nova.servicegroup.drivers.db [-]
> > Recovered from being unable to report status.
>
> This is a service update operation which could indicate that the other
> computes are reported as 'down' and that's why nothing is getting
> scheduled to them. Have you checked the "openstack compute service list"
> output to make sure those computes are all reporting as "up"?
>
>
> https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-list
>
> There is a retry_on_deadlock decorator on that service_update DB API
> though so I'm kind of surprised to still see the deadlock errors, unless
> those just get logged while retrying?
>
>
> https://github.com/openstack/nova/blob/stable/queens/nova/db/sqlalchemy/api.py#L566
>
> >
> >
> > The deadlock message is quite strange, as we have haproxy configured so
> > all write requests are handled by one node.
> >
> >
> > There are NO errors in the mysqld.log WHILE creating an instance, but we
> > see from time to time aborted connections from nova.
> >
> > 2019-04-15T14:22:36.232108Z 30616972 [Note] Aborted connection 30616972
> > to db: 'nova' user: 'nova' host: '10.x.y.z' (Got an error reading
> > communication packets)
> >
> >
> >
> > As I said, all instances are allocated to the same compute node.
> > nova-compute.log doesn't show an error while creating the instance.
> >
> >
> > Beside that, we also see messages from nova.scheduler.host_manager on
> > all other nodes like (but those messages are _not_ triggered, when an
> > instance is spawned.!)
> >
> >
> > 2019-04-15 16:28:47.771 22 INFO nova.scheduler.host_manager
> > [req-f92e340e-a88a-44a0-8cad-588390c25bc2 - - - - -] The instance sync
> > for host 'xxx' did not match. Re-created its InstanceList.
>
> Are there any instances on these other hosts? My guess is you're seeing
> that after the live migration to another host.
>
> >
> >
> >
> > Don't know if that may be relevant, but somehow our (currently single)
> > AZ is listed several times.
> >
> >
> > # openstack availability zone list
> > +------------+-------------+
> > | Zone Name  | Zone Status |
> > +------------+-------------+
> > | internal   | available   |
> > | az1 | available           |
> > | az1 | available           |
> > | az1 | available           |
> > | az1 | available           |
> > +------------+-------------+
> >
> > May that be related somehow?
>
> I believe those are the AZs for other services as well (cinder/neutron).
> Specify the --compute option to filter that.
>
> --
>
> Another thing to check is placement - are there 8 compute node resource
> providers reporting into placement? You can check using the CLI:
>
>
> https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list
>
> In Queens, there should be one resource provider per working compute
> node in the cell database's compute_nodes table (the UUIDs should match
> as well).
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/29d8a95d/attachment-0001.html>

From mriedemos at gmail.com  Mon Apr 15 21:55:48 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 15 Apr 2019 16:55:48 -0500
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
 <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>
Message-ID: <3a48d771-6b06-f1b4-9554-858c0fff0cc9@gmail.com>

On 4/15/2019 4:46 PM, Mike Carden wrote:
> For what it's worth, we had a discussion about this in November last year:
> 
> http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000209.html
> 
> I made a comment at the end of that thread about a 'workaround' we have 
> used. It still happens here on Queens and the workaround doesn't solve 
> it permanently.

OK so specifically setting 
[placement]/randomize_allocation_candidates=True in your config that's 
running the placement service, correct?

I can always remember host_subset_size but always forget 
randomize_allocation_candidates. At least they default to the same 
behavior (packing).

https://docs.openstack.org/nova/queens/configuration/config.html#placement.randomize_allocation_candidates

-- 

Thanks,

Matt


From mike.carden at gmail.com  Mon Apr 15 21:55:44 2019
From: mike.carden at gmail.com (Mike Carden)
Date: Tue, 16 Apr 2019 07:55:44 +1000
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
 <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>
Message-ID: <CAJ+DxurCvjutgOFYortcVQQGtv2N9ZX8o0dQUBb88=o7E8UrBw@mail.gmail.com>

Oh, I see the November archive truncates the mailing list thread. Here's
the post from December with the terrible workaround:

http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001156.html

--
MC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/91991eb3/attachment.html>

From mike.carden at gmail.com  Mon Apr 15 21:57:20 2019
From: mike.carden at gmail.com (Mike Carden)
Date: Tue, 16 Apr 2019 07:57:20 +1000
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <3a48d771-6b06-f1b4-9554-858c0fff0cc9@gmail.com>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
 <CAJ+Dxup48FmA_nyBBkTxK39rgO-J16wmW1azTcO5tBQ1iJv3Lg@mail.gmail.com>
 <3a48d771-6b06-f1b4-9554-858c0fff0cc9@gmail.com>
Message-ID: <CAJ+Dxuqie=VovdFwmiK9YC3ig47f8DH252ge3GjdqjRTTFvvEA@mail.gmail.com>

>
>
>
> OK so specifically setting
> [placement]/randomize_allocation_candidates=True in your config that's
> running the placement service, correct?
>

Yep, didn't change the behavior.

--
MC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/3337b46e/attachment.html>

From feilong at catalyst.net.nz  Mon Apr 15 22:09:10 2019
From: feilong at catalyst.net.nz (Feilong Wang)
Date: Tue, 16 Apr 2019 10:09:10 +1200
Subject: kube_cluster_deploy fails
In-Reply-To: <fa4c513a-a773-2ec8-2643-ea4534a449f2@everyware.ch>
References: <0f00a092-1f7d-e85b-9ce4-da38cfd2c9da@everyware.ch>
 <fa4c513a-a773-2ec8-2643-ea4534a449f2@everyware.ch>
Message-ID: <c23b496c-bfe0-d850-bf9f-0bd58abdc8f5@catalyst.net.nz>

Hi Pawel,

Firstly, please remove the tls-disabled param which it's a known issue.
And m1.small is a bit small for master which 30mins timout maybe not
enough. Please address them and try again, then if you still see error,
pls provied the log /var/log/cloud-init-output.log on your master node.
Cheers.


On 16/04/19 2:02 AM, Pawel Konczalski wrote:
> Hi,
>
> i try to deploy a kubernetes cluster on OpenStack rocky with Magnum.
> All Heat steps runs fine except for the last one "kube_cluster_deploy":
>
> kube_cluster_deploy    c3a79e96-87d8-442e-83f1-91d7a1acd896    1
> minute    Create Failed    CREATE aborted (Task create from
> SoftwareDeployment "kube_cluster_deploy" Stack
> "kubernetes-cluster9-l4ol4ger3key"
> [b17bfab3-f46a-477b-921f-4719bfd8df06] Timed out)
>
> The cluster contains three control / compute nodes, Octavia is also
> installed and works fine as far as I can see.
>
> Atomic Image:
> https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.raw.xz
>
>
> The command was:
> openstack coe cluster template create kubernetes-cluster-template \
>   --image fedora-atomic-latest \
>   --external-network public \
>   --dns-nameserver 8.8.8.8 \
>   --master-flavor m1.small \
>   --flavor m1.large \
>   --coe kubernetes \
>   --docker-volume-size 10 \
>   --tls-disabled \
>   --floating-ip-enabled
>
> openstack coe cluster create kubernetes-cluster \
>   --cluster-template kubernetes-cluster-template \
>   --master-count 1 \
>   --node-count 1 \
>   --timeout 30 \
>   --keypair mykey
>
> Did someone run also into this Problem or know how to fix it?
>
> BR
>
> Pawel

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 



From soulxu at gmail.com  Mon Apr 15 23:34:02 2019
From: soulxu at gmail.com (Alex Xu)
Date: Tue, 16 Apr 2019 07:34:02 +0800
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <CAH7mGat5-dA=DVqJ2L8fney3=iMcwEUk0mJLuwgx1VCSC=PfXQ@mail.gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGauCG7idBoar-BtZUoNK9xpQ_nqwH5LnBQGU-cPJBey0Gw@mail.gmail.com>
 <CAH7mGasetMp8L_jFN6fab2PkvGbwmtHPkfAFQn8WPiWr2RL6Ww@mail.gmail.com>
 <b21ce640506e5f5340fb217897441a983dac6e80.camel@redhat.com>
 <CAH7mGat5-dA=DVqJ2L8fney3=iMcwEUk0mJLuwgx1VCSC=PfXQ@mail.gmail.com>
Message-ID: <CAH7mGatAFiR0EiD1+BpWLx_O8=QL-Z2yF+-ouqBvTcg+OR4=QQ@mail.gmail.com>

we miss the maillist address, sorry I start that one....add it back.

Alex Xu <soulxu at gmail.com> 于2019年4月16日周二 上午7:16写道：

>
>
> Sean Mooney <smooney at redhat.com> 于2019年4月16日周二 上午2:27写道：
>
>> On Mon, 2019-04-15 at 23:16 +0800, Alex Xu wrote:
>> >
>> > >
>> > > ?resources=DISK_GB&
>> > > resources1=VCPU:2,MEMORY_MB:128&
>> > > resources1.1=VF:1&
>> > > resources2=VCPU:2,MEMORY_MB:128&
>> > > resources2.1=VF:1&
>> > > group_policy=isolate
>> > >
>> > > Is it the case you talking about? Sorry, I probably didn't get what
>> you
>> > > mean about changing grouping and group policies. Is there any
>> conflict case
>> > > from you vision?
>> > >
>> >
>> > Sorry, I miss read your case. It should be
>> >
>> > ?resources=DISK_GB:10,VF:1&
>> > resources1=VCPU:2,MEMORY_MB:128&
>> > resources2=VCPU:2,MEMORY_MB:128&
>> > group_policy=isolate
>> >
>> > VF may get from any RP in the whole tree.
>> no that wont work because it would require the disk_GB and the VF to come
>> form the same resouce provideer.
>>  so you would have to do
>>
>
> No, that isn't un-numbered resources meaning.  DISK_GB and VF are in
> un-numbered request group. It may get from any RP in the whole tree, and
> needn't to be same resource provider.
>
>
> http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/granular-resource-requests.html#semantics
> "The semantic for the (single) un-numbered grouping is unchanged. That is,
> it may still return results from different RPs in the same tree (or, when
> “shared” is fully implemented, the same aggregate)."
>
>
>> ?resources=DISK_GB:10&
>> resources1=VCPU:2,MEMORY_MB:128&
>> resources2=VCPU:2,MEMORY_MB:128&
>> resoucees3=VF:1
>> group_policy=isolate
>>
>> the issue aries if i want 2 VF
>>
>> do you do
>> ?resources=DISK_GB:10&
>> resources1=VCPU:2,MEMORY_MB:128&
>> resources2=VCPU:2,MEMORY_MB:128&
>> resoucees3=VF:1
>> resoucees4=VF:1
>> group_policy=isolate
>>
>> or
>> ?resources=DISK_GB:10&
>> resources1=VCPU:2,MEMORY_MB:128&
>> resources2=VCPU:2,MEMORY_MB:128&
>> resoucees3=VF:2
>> group_policy=isolate
>>
>> or
>> ?resources=DISK_GB:10&
>> resources1=VCPU:2,MEMORY_MB:128&
>> resources2=VCPU:2,MEMORY_MB:128&
>> resoucees3=VF:1
>> resoucees4=VF:1
>> grou
>> p_policy=None
>>
>> i woudl say the last one is the most correct from the neutorn point of
>> view
>> however we lose guarentee teh cpu and ram come form different numa node
>> the first option forces the vif to be form different RP and the second
>> requires them to
>> be form the same RPs
>>
>> what you really want is
>> ?resources=DISK_GB:10&
>> resources1=VCPU:2,MEMORY_MB:128&
>> resources2=VCPU:2,MEMORY_MB:128&
>> resoucees3=VF:1
>> resoucees4=VF:1
>> grou
>> p_policy=isolate;none:3,4
>>
>> i.e. the vfs can come form any RP in the tree but resouce group 1 an 2
>> need to be isolated.
>> or said another way by default each resouce group is isolated but resouce
>> groups 3 and 4 have policy none.
>>
>> >
>> >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/ad24f8d7/attachment-0001.html>

From soulxu at gmail.com  Mon Apr 15 23:49:31 2019
From: soulxu at gmail.com (Alex Xu)
Date: Tue, 16 Apr 2019 07:49:31 +0800
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
Message-ID: <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>

Sorry, I missed the mailist address in the reply, there probably discussion
and reply missed in the lastest email. So I reply to the mailist address
with those reply, hope other people can catch up our discussion.

Sean Mooney <smooney at redhat.com> 于2019年4月15日周一 下午9:54写道：

> On Mon, 2019-04-15 at 21:04 +0800, Alex Xu wrote:
> > Contribute an another idea at here. Pretty sure I didn't explore this
> with
> > all the cases by my limited vision.
> >
> > So I'm thinking we can continue use query string build a tree structure
> by
> > the request group number. I know the number request group problem for the
> > cyborg and neutron, but I think there must be some way to describe the
> > cyborg device will be attached to which instance numa node. So I guess
> that
> > it isn't the fault of number request group, maybe we are just missing a
> way
> > to describe that.
> >
> > For the case in the spec https://review.openstack.org/#/c/650476, an
> > instance with one numa node and two VFs from different network. We can
> > write as below:
> >
> > ?resources=DISK_GB:10&
> > resources1=VCPU:2,MEMORY_MB:128&
> > resources1.1=VF:1&required=NET_A
> > resources1.2=VF:1&required=NET_B
> im not sure what NET_A and NET_B correspond to
> as they are not prefixed with CUSTOM_ that implies they are standard
> traits but how woudl you map dynamically created neutron network to reouce
> providres as
> traits.
>
> i can see and have argued for doing something similar for neutron physnet
> as tehy are mostly static and can be applied by the neutron agent to the
> RP they create
> using a CUSTOM_PHYSNET_<physnet name> trait but i dont see how NET_A woudl
> work.
>

Yes, it is CUSTOM_PHYSNET_NET_A/CUSTON_PHYSNET_NET_B, just use a simple
version. But the case I want to show is two VFs from different physical
network.


> >
> > Another example, we request an instance with two numa nodes, 2 vcpus and
> > 128mb memory in each node. In each node has two VFs come from different
> PF
> > to have HA.
> >
> > ?resources=DISK_GB:10&
> > resources1=VCPU:2,MEMORY_MB:128&
> > resources1.1=VF:1&
> > resources1.2=VF:1&
> > resources2=VCPU:2,MEMORY_MB:128&
> > resources2.1=VF:1&
> > resources2.2=VF:1&
> > group_policy=isolate&
> > group_policy1=isolate&
> > group_policy2=isolate
>
> this gets messy as there is no way to express that i have a 2 numa node
> guest
> and i want a vf form either numa node without changing the grouping and
> group policies.
>
>
It can be done by
GET /allocation_candidates?
resources=DISK_GB:10,VF:1&
resources1=VCPU:2,MEMORY_MB:128&
resources2=VCPU:2,MEMORY_MB:128&
group_policy=isolate

The DISK_GB and VF are in a un-numbered request group. So they may come
from any RP in the tree.

http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/granular-resource-requests.html#semantics
"The semantic for the (single) un-numbered grouping is unchanged. That is,
it may still return results from different RPs in the same tree (or, when
“shared” is fully implemented, the same aggregate)."



> if we went down this road the we woudl have to generate this request
> dynamically(im ok with that)
> but that woudl mean the operator should not add resouce:... extra_spec to
> falvor ever.
>

Yes, I prefer the way generate from extra spec, not asking the operator
write such complex request by hand. The opearor can continue use
'resources' extra spec, we can merge it into the generate one.


>
> personally i would like to move in the direction of creating the placement
> queries dynamically
> and not requiring or allowing operators to specify resouce in the flavor
> as its the only way
> i can see to beable to generage a query like the one above. the main gap i
> see to enabling
> that is we have no numa infomation from neutron with regards to what numa
> node we shoudl
> attach the vf too so we cant create the request above without chaning the
> neutron api.
>

Yes, we are one the same side. The neutron problem see below.


>
> >
> > The `group_policy` ensure the resources1 and resources2 aren't coming
> from
> > the same RP. The 'group_poilcy1' ensures `resource1.x` aren't coming from
> > the same RP. The `group_policy2` ensures `resources2.x` aren't coming
> from
> > same RP.
> >
> > For the cyborg case, I think we can propose the flavor extra specs as
> below:
> > accel:device_profile.[numa node id]=<profile_name>
> this i think could work short term but honestly i think we should not do
> this.
> in the long term we would want to allow the device_profile to be passed on
> the
> nova boot commandlline and manage qouta/billing of device outside of
> flavors.
>

We can also allow specify guest numa node id in the boot command. But I
want to say, the problem is
we miss a way to specify that info for the neutron and cyborg. Other
proposal in the spec doesn't resolve this problem.
And I think this problem isn't the fault of request group number.


>
> we will also want to provide a policy attibe i think for virtual to host
> numa affitity
> for devices.
>
> the other asspect is we curently do not create a pci root complex per numa
> node
> until we do that  we cant support requesting cyborg device per numa node
> the numa node id in accel:device_profile.[numa node id]=<profile_name>
> should be the guest numa node not a host numa node.
>

Yes, The "[numa node id]" in "accel:device_profile.[numa node id]" is guest
numa node id. Just like other extra spec "hw:cpus.0=1,2", we are using the
guest numa node id in those extra specs.


>
> personally i woudl prefer to create the pci root complex per numa node
> first
> and automaticlly assign the device to the correct root complex before
> allowing
> enduser to request cyborge device to be attached to a specific guest numa
> node
> as i think accel:device_profile.[numa node id]=<profile_name>  might be
> too constiringing
> while also leaking to much host specific infomation via our api if it is
> used to select
> placment resouce providers and therefore host numa nodes.
>
> >
> > Then we will know the user hope the cyborg device being attach to which
> > instance numa node.
> >
> > The cyborg only needs to return un-numbered request group, then Nova will
> > base on all the 'hw:xxx' extra specs and 'accel:device_profile.[numa node
> > id]' to generate a placement request like above.
> >
> > For example, if it is PCI device under first numa node, the extra spec
> will
> > be 'accel:device_profile.0=<profile_name>' the cyborg can return a simple
> > request 'resources=CYBORG_PCI_XX_DEVICE:1', then we merge this into the
> > request group 'resources1=VCPU:2,MEMORY_MB:128,CYBORG_PCI_XX_DEVICE:1'.
> If
> > the pci device has a special trait, then cyborg should return request
> group
> > as 'resources1=CYBORG_PCI_XX_DEVICE:1&required=SOME_TRAIT', then nova
> merge
> > this into placement request as 'resources1.1'.
> >
> > Chris Dent <cdent+os at anticdent.org> 于2019年4月9日周二 下午8:42写道：
> >
> > >
> > > Spec: https://review.openstack.org/650476
> > >
> > > From the commit message:
> > >
> > >      To support NUMA and similar concepts, this proposes the ability
> > >      to request resources from different providers nested under a
> > >      common subtree (below the root provider).
> > >
> > > There's much in the feature described by the spec and the surrounding
> > > context that is frequently a source of contention in the placement
> > > group, so working through this spec is probably going to require
> > > some robust discussion. Doing most of that before the PTG will help
> > > make sure we're not going in circles in person.k
> > >
> > > Some of the areas of potential contention:
> > >
> > > * Adequate for limited but maybe not all use case solutions
> > > * Strict trait constructionism
> > > * Evolving the complexity of placement solely for the satisfaction
> > >    of hardware representation in Nova
> > > * Inventory-less resource providers
> > > * Developing new features in placement before existing features are
> > >    fully used in client services
> > > * Others?
> > >
> > > I list this not because they are deal breakers or the only thing
> > > that matters, but because they have presented stumbling blocks in
> > > the past and we may as well work to address them (or make an
> > > agreement to punt them until later) otherwise there will be
> > > lingering dread.
> > >
> > > And, beyond all that squishy stuff, there is the necessary
> > > discussion over the solution described in the spec. There are
> > > several alternatives listed in the spec, and a few more in the
> > > comments. We'd like to figure out the best solution that can
> > > actually be done in a reasonable amount of time, not the best
> > > solution in the absolute.
> > >
> > > Discuss!
> > >
> > > --
> > > Chris Dent                       ٩◔̯◔۶
> https://anticdent.org/
> > > freenode: cdent                                         tw: @anticdent
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/d3969e04/attachment.html>

From juliaashleykreger at gmail.com  Tue Apr 16 00:19:45 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 15 Apr 2019 17:19:45 -0700
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
Message-ID: <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>

In working on the project update for Ironic, I too have noticed wild
inaccuracies.

For one contributor, I found it reported 1 commit for a specific
contributor in one screen, but when looking at the data differently
that same user showed four different commits.

Looking at the commit count reporting for ironic-group, it also only
shows about 200 commits for stein, but when I manually dump the data
out from the `git log` output I count in excess of 600 commits.

It also reported like 63 contributors for stein, but I get 123 based
on just the commit log author/co-authored-by data. I totally get that
there are lots of edge cases to cover in any UI to show insight, but
the data just does not seem like it is accurately reporting.

Is it time for us, as a community, to whip up something that helps
provide basic insight?

-Julia

On Thu, Apr 11, 2019 at 11:29 AM Mark Goddard <mark at stackhpc.com> wrote:
>
> Hi,
>
> I've heard a couple of people say they don't feel the numbers reported by Stackalytics accurately reflect reality. I've been trying to gather a few stats for my Kolla update session in Denver, and am finding the same. I'll try to give some concrete examples.
>
> Reviews for all kolla deliverables in Stein [1]. Here the company stats don't reflect the individual stats. Also, the total reviews in the 'Kolla Official' module does not equal the sum of the reviews of its submodules (kolla, kolla-ansible, kolla-cli).
>
> If I look at the contribution summary for Kolla Official in the last 90 days [2], they are actually greater than those for the last 180 days [3]!
>
> There are also similar issues with commit metrics, and none seem to match what I see in git.
>
> Thanks,
> Mark
>
> [1] https://www.stackalytics.com/?metric=marks&module=kolla-group
> [2] https://www.stackalytics.com/report/contribution/kolla-group/90
> [3] https://www.stackalytics.com/report/contribution/kolla-group/180


From colleen at gazlene.net  Tue Apr 16 00:33:12 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Mon, 15 Apr 2019 20:33:12 -0400
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
Message-ID: <3ba8fe89-803c-49fc-8cc5-cec58a4f495d@www.fastmail.com>

On Mon, Apr 15, 2019, at 17:20, Julia Kreger wrote:
> In working on the project update for Ironic, I too have noticed wild
> inaccuracies.
> 
> For one contributor, I found it reported 1 commit for a specific
> contributor in one screen, but when looking at the data differently
> that same user showed four different commits.
> 
> Looking at the commit count reporting for ironic-group, it also only
> shows about 200 commits for stein, but when I manually dump the data
> out from the `git log` output I count in excess of 600 commits.
> 
> It also reported like 63 contributors for stein, but I get 123 based
> on just the commit log author/co-authored-by data. I totally get that
> there are lots of edge cases to cover in any UI to show insight, but
> the data just does not seem like it is accurately reporting.
> 
> Is it time for us, as a community, to whip up something that helps
> provide basic insight?

I too found that stackalytics was wildly unuseful for preparing data for project updates. I started using reviewstats[1] (after learning about it from another thread) which provided a much better starting point. So I don't think we need to whip up something new, we should make that thing better.

[1] https://opendev.org/openstack-infra/reviewstats

Colleen

> 
> -Julia
> 
> On Thu, Apr 11, 2019 at 11:29 AM Mark Goddard <mark at stackhpc.com> wrote:
> >
> > Hi,
> >
> > I've heard a couple of people say they don't feel the numbers reported by Stackalytics accurately reflect reality. I've been trying to gather a few stats for my Kolla update session in Denver, and am finding the same. I'll try to give some concrete examples.
> >
> > Reviews for all kolla deliverables in Stein [1]. Here the company stats don't reflect the individual stats. Also, the total reviews in the 'Kolla Official' module does not equal the sum of the reviews of its submodules (kolla, kolla-ansible, kolla-cli).
> >
> > If I look at the contribution summary for Kolla Official in the last 90 days [2], they are actually greater than those for the last 180 days [3]!
> >
> > There are also similar issues with commit metrics, and none seem to match what I see in git.
> >
> > Thanks,
> > Mark
> >
> > [1] https://www.stackalytics.com/?metric=marks&module=kolla-group
> > [2] https://www.stackalytics.com/report/contribution/kolla-group/90
> > [3] https://www.stackalytics.com/report/contribution/kolla-group/180
> 
>


From jwoh95 at dcn.ssu.ac.kr  Tue Apr 16 01:17:21 2019
From: jwoh95 at dcn.ssu.ac.kr (Jaewook Oh)
Date: Tue, 16 Apr 2019 10:17:21 +0900
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <52b97f07-a6e9-78bd-786d-20071fd17a59@redhat.com>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
 <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
 <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
 <20190415123003.4byrip452uejqyvo@yuggoth.org>
 <52b97f07-a6e9-78bd-786d-20071fd17a59@redhat.com>
Message-ID: <CABZrd4w3BKpXPdM_+kgT9VSjqRABntV+xtbHAh4Xns73AgwM4Q@mail.gmail.com>

Thanks for all replying!

I thought Devstack was rebootable, cause when I didn't use any kuryr
things, the devstack was working normally haha...
Anyway I got it :)

Thanks again for the information!

BR,
Jaewook.

================================================
*Jaewook Oh* (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea
Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
E-mail : jwoh95 at dcn.ssu.ac.kr
================================================


2019년 4월 15일 (월) 오후 9:49, Daniel Mellado <dmellado at redhat.com>님이 작성:

>
>
> On 15/4/19 14:30, Jeremy Stanley wrote:
> > On 2019-04-15 10:18:46 +0200 (+0200), Daniel Mellado Area wrote:
> >> Overall and besides of what Michal said, yeah, openstack hasn't been
> >> designed to be rebootable.
> > [...]
> >
> > To be clear, it's DevStack which is designed not to be rebootable
> > (this is intentional, to further dissuade anyone from trying to use
> > it for a production deployment). There is nothing inherently
> > non-rebootable about OpenStack in general.
> >
> My bad on the typo, I meant DevStack when I was typing OpenStack, heh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/af2eedde/attachment.html>

From dangtrinhnt at gmail.com  Tue Apr 16 01:19:40 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 16 Apr 2019 10:19:40 +0900
Subject: [telemetry][panko][ceilometer][aodh][zuul] Replace
 telemetry-tox-py37 with openstack-python37-jobs
In-Reply-To: <CADJ6S4GRM6WuLw8kCpEguYt=_ZEJyirPBYrkhDs_WNZfNqZNmA@mail.gmail.com>
References: <CADJ6S4FOqMcf6mFqGEroNnQVYhJSQk4QTWi-mhZfwKRPcaVuWw@mail.gmail.com>
 <CADJ6S4GRM6WuLw8kCpEguYt=_ZEJyirPBYrkhDs_WNZfNqZNmA@mail.gmail.com>
Message-ID: <CADJ6S4EJNdna4rA+_kvJyb27XwzVjz-9+Wvmo9v-vuZUamuWQg@mail.gmail.com>

Thanks. All are merged now.

On Thu, Apr 11, 2019 at 12:36 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi again,
>
> I proposed the patches to remove telemetry-tox-py37. Please take some time
> to review. Thanks.
>
> [1] https://review.openstack.org/651688
> [2] https://review.openstack.org/651689
> [3] https://review.openstack.org/650197
>
> Yours,
>
>
> On Wed, Apr 10, 2019 at 4:37 PM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Hi team,
>>
>> I would love to replace telemetry-tox-py37 with openstack-python37-jobs
>> since the only main difference is the nodeset [1]. If you know any reason
>> to keep it that way, please let me know.
>>
>> Yours,
>>
>> [1] https://github.com/openstack/ceilometer/blob/master/.zuul.yaml#L47
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/192e4fc5/attachment.html>

From jwoh95 at dcn.ssu.ac.kr  Tue Apr 16 01:21:21 2019
From: jwoh95 at dcn.ssu.ac.kr (Jaewook Oh)
Date: Tue, 16 Apr 2019 10:21:21 +0900
Subject: [kuryr] [kuryr-kubernetes] Unable to use kubernetes-related
 things after rebooting host
In-Reply-To: <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
References: <CABZrd4yrCo9nwK=4dLz7=UvY0Zu-9s-1pG6zEPR_ivw-FxMsNw@mail.gmail.com>
 <7948bf1a21e00b583712a8617e226b74d3716949.camel@redhat.com>
 <CAFk8guvPfsyCMeCO+a3pT7BbWaPsSAn42TR4KQGSS9fTpsTdEw@mail.gmail.com>
Message-ID: <CABZrd4xos0BxCdZtTryH7sZQR6ba_R91nHpfpKRkOG0goib_UA@mail.gmail.com>

My server that I deployed devstack was halted suddenly. I don't know what
exact reason is but, that made rebooting devstack.

Thanks!

================================================
*Jaewook Oh* (오재욱)
IISTRC - Internet Infra System Technology Research Center
369 Sangdo-ro, Dongjak-gu,
06978, Seoul, Republic of Korea
Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
E-mail : jwoh95 at dcn.ssu.ac.kr
================================================


2019년 4월 15일 (월) 오후 5:23, Daniel Mellado Area <dmellado at redhat.com>님이 작성:

> Overall and besides of what Michal said, yeah, openstack hasn't been
> designed to be rebootable.
> A looong time ago and before the migration to systemd services there was a
> script that restarted the screen instances [1]
>
> That said, not there since 2016 so please restack whenever you reboot. In
> any case, was there any reason for rebooting?
> I'd check if just restarting service would be enough for you.
>
> Thanks!
>
> [1]
> https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=9ba49cd82631ada84b8458b370ac535985d57725
>
> On Mon, Apr 15, 2019 at 9:58 AM Michał Dulko <mdulko at redhat.com> wrote:
>
>> On Mon, 2019-04-15 at 11:44 +0900, Jaewook Oh wrote:
>> > Hello kuryr-kubernetes team,
>> >
>> > currently, I deployed openstack with devstack, and I added
>> "kuryr-kubernetes" to use kubernetes vim.
>> > At first it worked fine and no error was occurred,
>> > so I made some c-vnfs with kuryr-kubernetes.
>> > But after rebooting the host, the systems that worked well before are
>> not working normally at all.
>> >
>> > First, I deployed an example one ('redis') with kubectl command, (Not
>> using Tacker, but only using kubectl cli)
>> > it showed below error,
>> >
>> > Events:
>>
>> │obeTime":null,"lastTransitionTime":"2019-04-15T02:28:31Z"}],"hostIP":"192.168.1.20","startTime":"2019-04-15T02:28:31Z"
>> >   Type     Reason                  Age    From               Message
>>
>>  │,"containerStatuses":[{"name":"web-server","state":{"waiting":{"reason":"ContainerCreating"}},"lastState":{},"ready":f
>> >   ----     ------                  ----   ----               -------
>>
>>  │alse,"restartCount":0,"image":"kyleoh95/iistrc-k8s-demo2:0.4","imageID":""}],"qosClass":"Guaranteed"}}]}
>> >   Normal   Scheduled               2m25s  default-scheduler
>> Successfully assigned default/redis-master-6fbbc44567-ms8n│Apr 15 11:36:52
>> master tacker-server[1881]:  from (pid=1881) request
>> /usr/local/lib/python2.7/dist-packages/kubernetes
>> > k to master
>>                                                 │/client/rest.py:219
>> >   Warning  MissingClusterDNS       2m25s  kubelet, master    pod:
>> "redis-master-6fbbc44567-ms8nk_default(8a6f9079-5f27-│Apr 15 11:36:52
>> master tacker-server[1881]: 2019-04-15 11:36:52.633 DEBUG
>> tacker.vnfm.infra_drivers.kubernetes.kuberne
>> > 11e9-9b42-a4bf01550f1a)". kubelet does not have ClusterDNS IP
>> configured and cannot create Pod using "ClusterFirst" pol│tes_driver [-]
>> status: Pending from (pid=1881) create_wait
>> /opt/stack/tacker/tacker/vnfm/infra_drivers/kubernetes/kube
>> > icy. Falling back to "Default" policy.
>>                                                │rnetes_driver.py:137
>> >   Warning  FailedCreatePodSandBox  19s    kubelet, master    Failed
>> create pod sandbox: rpc error: code = Unknown desc │Apr 15 11:36:52 master
>> tacker-server[1881]: 2019-04-15 11:36:52.634 DEBUG
>> tacker.vnfm.infra_drivers.kubernetes.kuberne
>> > = failed to set up sandbox container
>> "310e18b859e118ad6abcaa60d29a9e332da516ce57b8cdf47456ea4882ca66f5" network
>> for pod│tes_driver [-] VNF initializing status: ['default',
>> 'svc-vdu1-b9e851'] Pending from (pid=1881) create_wait /opt/stack/
>> >  "redis-master-6fbbc44567-ms8nk": NetworkPlugin cni failed to set up
>> pod "redis-master-6fbbc44567-ms8nk_default"
>> networ│tacker/tacker/vnfm/infra_drivers/kubernetes/kubernetes_driver.py:141
>> > k: Got invalid status code from CNI daemon.; Traceback (most recent
>> call last):                                        │Apr 15 11:36:52 master
>> tacker-server[1881]: 2019-04-15 11:36:52.634 WARNING
>> tacker.vnfm.infra_drivers.kubernetes.kuber
>> >   File "/opt/stack/kuryr-kubernetes/kuryr_kubernetes/cni/api.py", line
>> 80, in run                                      │netes_driver [-] VNF
>> Creation failed: Resource creation is not completed within 500 seconds as
>> creation of stack defau
>> >     vif = self._add(params)
>>
>> "Got invalid status code from CNI daemon" means that you should take a
>> look at kuryr-cni pods logs.
>>
>> >
>> > Are there any reason for this error? And how can I resolve this problem?
>>
>> In general I'm pretty sure DevStack is not designed to be rebootable,
>> so it's probably some ip route being gone or some service that haven't
>> restarted. If you really want to debug this instead of firing a new
>> DevStack, start from checking all "devstack@*" services in systemd.
>>
>> > Best Regards,
>> > Jaewook.
>> > ================================================
>> > Jaewook Oh (오재욱)
>> > IISTRC - Internet Infra System Technology Research Center
>> > 369 Sangdo-ro, Dongjak-gu,
>> > 06978, Seoul, Republic of Korea
>> > Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618
>> > E-mail : jwoh95 at dcn.ssu.ac.kr
>> > ================================================
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/97650c97/attachment-0001.html>

From dangtrinhnt at gmail.com  Tue Apr 16 01:24:31 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 16 Apr 2019 10:24:31 +0900
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CADJ6S4HCKxTyxyLntmN=JKvs781Hx3wED+RKg8Awz21FX+jGDA@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
 <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
 <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>
 <CADJ6S4GoRPrAttgX9_ccwo2geBtiqzrCPsG128jadUasvsZvcg@mail.gmail.com>
 <CADJ6S4HCKxTyxyLntmN=JKvs781Hx3wED+RKg8Awz21FX+jGDA@mail.gmail.com>
Message-ID: <CADJ6S4E8DCzHAufx53NYCNhUzv8=4AmT5goGgyRUxv873PYO=Q@mail.gmail.com>

Hi team,

Let set the meeting time at 2:00 UTC on Thursday every 2 weeks, starting
from May 9. I will update the irc-meeting information.

Thanks,

On Wed, Apr 10, 2019 at 4:40 PM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Done. First team bi-weekly meeting will be on May 9 :)
>
> On Wed, Apr 10, 2019 at 4:37 PM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Oops, totally forgot. Will update the poll. Thanks.
>>
>> On Wed, Apr 10, 2019 at 4:36 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>>
>>> May 2nd is the day after the summit ends, so I think many of the people
>>> are on the road.
>>> Shall we choice another day?
>>>
>>> Thanks,
>>> Rong Zhu
>>>
>>> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月10日 周三15:17写道：
>>>
>>>> P/S: deadline will be 23:00 April 17, 2019.
>>>>
>>>> On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi team,
>>>>>
>>>>> There're many things we need to discuss for the Train cycle so I
>>>>> propose we have a bi-weekly meeting and the first one would be on May 2
>>>>> (next two weeks will be the vacation of most of the people). Please cast
>>>>> your vote for an appropriate time:
>>>>>
>>>>> https://doodle.com/poll/8akawam8yk38q2hh
>>>>>
>>>>> Yours,
>>>>>
>>>>> --
>>>>> *Trinh Nguyen*
>>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Trinh Nguyen*
>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>
>>>> --
>>> Thanks,
>>> Rong Zhu
>>>
>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/908c0779/attachment.html>

From dangtrinhnt at gmail.com  Tue Apr 16 01:40:53 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Tue, 16 Apr 2019 10:40:53 +0900
Subject: [telemetry] Vote for team meeting datetime
In-Reply-To: <CADJ6S4E8DCzHAufx53NYCNhUzv8=4AmT5goGgyRUxv873PYO=Q@mail.gmail.com>
References: <CADJ6S4FA67f1GQpvpXZSx6m+nG5DWngQ32p+PXqZ6SJqPFkfNg@mail.gmail.com>
 <CADJ6S4EM6ZoZm6UHU8SE9PQfxVzFt+tf9kWU6A_BwTgjpdWcCw@mail.gmail.com>
 <CAN2nDNvZ2wmdHppaZRU=OKjFGSjDQUYdnJ6thkFG_0kuQgSSpw@mail.gmail.com>
 <CADJ6S4GoRPrAttgX9_ccwo2geBtiqzrCPsG128jadUasvsZvcg@mail.gmail.com>
 <CADJ6S4HCKxTyxyLntmN=JKvs781Hx3wED+RKg8Awz21FX+jGDA@mail.gmail.com>
 <CADJ6S4E8DCzHAufx53NYCNhUzv8=4AmT5goGgyRUxv873PYO=Q@mail.gmail.com>
Message-ID: <CADJ6S4FhDiv1s2OJt=oKHivOLeb+oN9H+8ZtPbo9=2hb9za8ng@mail.gmail.com>

Hi again,

This is the proposed patch for the meeting on IRC:
https://review.openstack.org/#/c/652809/

Yours,

On Tue, Apr 16, 2019 at 10:24 AM Trinh Nguyen <dangtrinhnt at gmail.com> wrote:

> Hi team,
>
> Let set the meeting time at 2:00 UTC on Thursday every 2 weeks, starting
> from May 9. I will update the irc-meeting information.
>
> Thanks,
>
> On Wed, Apr 10, 2019 at 4:40 PM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Done. First team bi-weekly meeting will be on May 9 :)
>>
>> On Wed, Apr 10, 2019 at 4:37 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>> wrote:
>>
>>> Oops, totally forgot. Will update the poll. Thanks.
>>>
>>> On Wed, Apr 10, 2019 at 4:36 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:
>>>
>>>> May 2nd is the day after the summit ends, so I think many of the people
>>>> are on the road.
>>>> Shall we choice another day?
>>>>
>>>> Thanks,
>>>> Rong Zhu
>>>>
>>>> Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月10日 周三15:17写道：
>>>>
>>>>> P/S: deadline will be 23:00 April 17, 2019.
>>>>>
>>>>> On Wed, Apr 10, 2019 at 4:13 PM Trinh Nguyen <dangtrinhnt at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi team,
>>>>>>
>>>>>> There're many things we need to discuss for the Train cycle so I
>>>>>> propose we have a bi-weekly meeting and the first one would be on May 2
>>>>>> (next two weeks will be the vacation of most of the people). Please cast
>>>>>> your vote for an appropriate time:
>>>>>>
>>>>>> https://doodle.com/poll/8akawam8yk38q2hh
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> --
>>>>>> *Trinh Nguyen*
>>>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> *Trinh Nguyen*
>>>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>>>
>>>>> --
>>>> Thanks,
>>>> Rong Zhu
>>>>
>>>
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/589d88b4/attachment-0001.html>

From cboylan at sapwetik.org  Tue Apr 16 03:09:09 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 15 Apr 2019 23:09:09 -0400
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
Message-ID: <f43c4c11-3623-41f0-992c-b8033c00bf3b@www.fastmail.com>

On Mon, Apr 15, 2019, at 5:20 PM, Julia Kreger wrote:
> In working on the project update for Ironic, I too have noticed wild
> inaccuracies.
> 
> For one contributor, I found it reported 1 commit for a specific
> contributor in one screen, but when looking at the data differently
> that same user showed four different commits.
> 
> Looking at the commit count reporting for ironic-group, it also only
> shows about 200 commits for stein, but when I manually dump the data
> out from the `git log` output I count in excess of 600 commits.

To add to the weirdness: if you start at the default stackalytics page, then select "Ironic Official" as the module, then switch from reviews to commits it seems to reload for me and show 964 commits instead of ~200. Perhaps there are multiple backends and one or more of them have old/inaccurate data?

> 
> It also reported like 63 contributors for stein, but I get 123 based
> on just the commit log author/co-authored-by data. I totally get that
> there are lots of edge cases to cover in any UI to show insight, but
> the data just does not seem like it is accurately reporting.
> 
> Is it time for us, as a community, to whip up something that helps
> provide basic insight?
> 
> -Julia


From aj at suse.com  Tue Apr 16 06:42:45 2019
From: aj at suse.com (Andreas Jaeger)
Date: Tue, 16 Apr 2019 08:42:45 +0200
Subject: [tc][all] Dropping py35 testing
In-Reply-To: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
References: <16a1d2dd9c1.da7cfdc0309589.2071670653168020424@ghanshyammann.com>
Message-ID: <ecc8b019-e92f-8297-e55b-f6dd45b5e903@suse.com>

On 14/04/2019 20.48, Ghanshyam Mann wrote:
> Hello Everyone,
> 
> All the integration testing has been moved to Bionic[1] now and as discussed in the TC meeting[2],
> we are good to drop the py35 testing. 
> 
> Train: Good to drop.
> I am going to push the patches to remove the py35 jobs from the master (which is Train now). 

Please check periodic jobs as well, there are jobs like
openstack-tox-py35-with-neutron-lib-master that need updating,

Andreas

> Stable/Stein: Ok to drop if the project wants.
> Stable/Stein gate is also moved to Bionic so we are good to drop py35 from stable/stein too.
> But backporting all the patches will be too many patches for projects to merge on stable/stein so
> we discussed not to propose all of them to stable/stein. If the project really wants to drop it from
> stable/stein then, they can backport. 
> 
> NOTE: Till stable/rocky, we should keep testing py35. If your project is branchless like Tempest and gate
> the same jobs for stable/rocky or older then, you should keep testing the py35 until stable/rocky EOL.
> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
> [2] http://eavesdrop.openstack.org/meetings/tc_python3/2019/tc_python3.2019-03-07-21.00.html
>        http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003610.html 
> 
> -gmann
> 
> 
> 


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



From smooney at redhat.com  Tue Apr 16 08:13:20 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 16 Apr 2019 09:13:20 +0100
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <f43c4c11-3623-41f0-992c-b8033c00bf3b@www.fastmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
 <f43c4c11-3623-41f0-992c-b8033c00bf3b@www.fastmail.com>
Message-ID: <fa8bea41cc421910c7e9e5b04628a667354573c5.camel@redhat.com>

On Mon, 2019-04-15 at 23:09 -0400, Clark Boylan wrote:
> On Mon, Apr 15, 2019, at 5:20 PM, Julia Kreger wrote:
> > In working on the project update for Ironic, I too have noticed wild
> > inaccuracies.
> > 
> > For one contributor, I found it reported 1 commit for a specific
> > contributor in one screen, but when looking at the data differently
> > that same user showed four different commits.
> > 
> > Looking at the commit count reporting for ironic-group, it also only
> > shows about 200 commits for stein, but when I manually dump the data
> > out from the `git log` output I count in excess of 600 commits.
> 
> To add to the weirdness: if you start at the default stackalytics page, then select "Ironic Official" as the module,
> then switch from reviews to commits it seems to reload for me and show 964 commits instead of ~200. Perhaps there are
> multiple backends and one or more of them have old/inaccurate data?
ya i have noticed the same thing since the new ui was intoducd.
sometimes of you referesh or start again form the manin page then you will get different data
> 
> > 
> > It also reported like 63 contributors for stein, but I get 123 based
> > on just the commit log author/co-authored-by data. I totally get that
> > there are lots of edge cases to cover in any UI to show insight, but
> > the data just does not seem like it is accurately reporting.
> > 
> > Is it time for us, as a community, to whip up something that helps
> > provide basic insight?
> > 
> > -Julia
> 
> 



From thierry at openstack.org  Tue Apr 16 08:27:15 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 16 Apr 2019 10:27:15 +0200
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
Message-ID: <c1150b3f-c2d3-4c8f-974a-759fee5090dc@openstack.org>

Julia Kreger wrote:
> [...]
> Is it time for us, as a community, to whip up something that helps
> provide basic insight?

I think we should first agree on what we actually need.

A first level would be to extract the data about changes and reviews 
from Gerrit into a query-able system so that we don't have everyone 
hammering Gerrit with individual stats queries. Then people can share 
their "insights scripts" and run them on the same official data.

A second level would be to come up with some common definition of "basic 
insight" and produce that data for all teams. Personally I think the 
first level would already give us a lot more confidence and consistency 
in the numbers we produce.

As an aside, the OSF has been driving a proof-of-concept experiment to 
use Bitergia tooling (now ELK-based) for Kata Containers and StarlingX, 
which we could extend to OpenStack and all other OSF projects if successful.

Historically we dropped the old Bitergia tooling because it was falling 
short with OpenStack complexity (groups of repositories per project 
team) and release-timeframe data, and its visualization capabilities 
were limited. But the new version is much better-looking and flexible, 
so it might be a solution in the long term.

-- 
Thierry Carrez (ttx)


From bence.romsics at gmail.com  Tue Apr 16 08:48:29 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Tue, 16 Apr 2019 10:48:29 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
 <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
 <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>
Message-ID: <CAHeS+3-yeROwZkjSyQ93vjaECEfNsdC_hGEDC9BarNQ4tgOeNg@mail.gmail.com>

Hi All,

On Mon, Apr 15, 2019 at 8:08 PM Zane Bitter <zbitter at redhat.com> wrote:
> On 15/04/19 1:23 PM, Slawomir Kaplonski wrote:
> > IMO option 2 provided by Bence is the best one here. This should be fixed in neutron API by making extra routes first class API objects and treat them as router interfaces. DB layer is „ready” for that IMO so it should be handled easy.
> > All other ways it will just be kind of workaround of the issue. Even if we will fix it in OpenStack SDK and/or neutron client there may be someone who is using API in some other way and will still hit the same issue.
>
> Oh, for sure. If Neutron is willing to do that then that is definitely
> the best solution.

I'm inclined to take that as a shared agreement to prefer way #2 over
the other alternatives brought up in this thread. That is first class
extra routes in neutron and adapt the heat resource to that.

I am willing to take up both the Neutron and Heat sides of this work
in the Train cycle if the projects agree this is a good idea to work
on and it is worth the review cycles. As a next step I'll write up a
Neutron RFE. And at least open a placeholder Heat blueprint - which
I'll be able to specify better when the first class extraroute Neutron
API is agreed on. Please expect these coming still before the PTG.
I'll be attending the Summit and the PTG in Denver so we can discuss
these in person if we feel that's needed at that time.

Thanks,
Bence


From stig.openstack at telfer.org  Tue Apr 16 08:51:39 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Tue, 16 Apr 2019 09:51:39 +0100
Subject: [scientific-sig] Meeting tonight: Ironic and Data Center Inventory,
 Denver Summit
Message-ID: <DFDC97DB-3ABB-49D1-9965-27F835E937BD@telfer.org>

Hi All - 

We have a Scientific SIG IRC meeting today at 2100 UTC in channel #openstack-meeting.  Everyone is welcome.

Today's agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_16th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_16th_2019>

We’d like to continue the discussion started last week (in the other timezone) on surveying data center inventory management systems used in research computing, and how those might be better integrated with Ironic.  We also have preparations for the Denver summit to discuss.

Cheers,
Stig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/0f8c31cc/attachment.html>

From nicolas.ghirlanda at everyware.ch  Tue Apr 16 09:02:09 2019
From: nicolas.ghirlanda at everyware.ch (Nicolas Ghirlanda)
Date: Tue, 16 Apr 2019 11:02:09 +0200
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
Message-ID: <750d4346-26cc-f462-9a5e-454e520e950a@everyware.ch>

Hi Matt,


thanks for your answers.. find mine below

On 15.04.19 19:04, Matt Riedemann wrote:
> On 4/15/2019 10:36 AM, Nicolas Ghirlanda wrote:
>> New VMs  are just currently always scheduled to the same compute 
>> node, even though a manual live-migration is working fine to other 
>> compute nodes.
>
> How are you doing the live migration? If you're using the openstack 
> command line and defaulting to the 2.1 compute API microversion, 
> you're forcing the server to another host by bypassing the scheduler 
> which is maybe why live migration is "working" but server create is 
> not ever using the other computes.
>
Sound reasonable and yes, I used nova live-migration and specified the 
target machine.
When I used  "openstack server migrate --live", it seemed that all vms 
are transferred to one specific other compute node (but need to confirm 
that).


>>
>>
>> We're not sure, what the issue is, but perhaps someone may spot it 
>> from our config:
>>
>>
>> # nova.conf  scheduler config
>>
>> default_availability_zone = az1
>
> How many computes are in az1? All 8?

yes, in 2 hostgroups.


>
>>
>> ...
>>
>> [filter_scheduler]
>> available_filters = nova.scheduler.filters.all_filters
>> enabled_filters = RetryFilter, AvailabilityZoneFilter, 
>> ComputeCapabilitiesFilter, ImagePropertiesFilter, 
>> ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, 
>> AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation, 
>> DifferentHostFilter, RamFilter, SameHostFilter, NUMATopologyFilter
>>
>
> Not really related to this probably but you can remove RamFilter since 
> placement does the MEMORY_MB filtering and the RamFilter was 
> deprecated in Stein as a result.
>
> It looks like you're getting the default host_subset_size value:
>
> https://docs.openstack.org/nova/queens/configuration/config.html#filter_scheduler.host_subset_size 
>
>
> Which means your scheduler is "packing" by default. If you have 
> multiple computes and you want to spread instances across them, you 
> can adjust the host_subset_size value.


Thanks, I will try.

>
>>
>>
>> Database is an external Percona XtraDB Cluster (Version 5.7.24) with 
>> haproxy for read-write-splitting (currently only one write node).
>>
>> We do see mysql errors in the nova-scheduler.log on the write DB node 
>> when an instance is created.
>>
>>
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db [-] 
>> Unexpected error while reporting service status: OperationalError: 
>> (pymysql.err.OperationalError) (1213, u'WSREP detected 
>> deadlock/conflict and aborted the transaction. Try restarting the 
>> transaction') (Background on this error at: http://sqlalche.me/e/e3q8)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> Traceback (most recent call last):
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py", 
>> line 91, in _report_state
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> service.service_ref.save()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py", 
>> line 226, in wrapper
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
>> fn(self, *args, **kwargs)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/service.py", 
>> line 397, in save
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> db_service = db.service_update(self._context, self.id, updates)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/api.py", 
>> line 183, in service_update
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
>> IMPL.service_update(context, service_id, values)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
>> line 154, in wrapper
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> ectxt.value = e.inner_exc
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
>> line 220, in __exit__
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.force_reraise()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
>> line 196, in force_reraise
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> six.reraise(self.type_, self.value, self.tb)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", 
>> line 142, in wrapper
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
>> f(*args, **kwargs)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", 
>> line 227, in wrapped
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return 
>> f(context, *args, **kwargs)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.gen.next()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
>> line 1043, in _transaction_scope
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db yield 
>> resource
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.gen.next()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
>> line 653, in _session
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.session.rollback()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
>> line 220, in __exit__
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.force_reraise()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", 
>> line 196, in force_reraise
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> six.reraise(self.type_, self.value, self.tb)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
>> line 650, in _session
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self._end_session_transaction(self.session)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", 
>> line 678, in _end_session_transaction
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> session.commit()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
>> line 943, in commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.transaction.commit()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", 
>> line 471, in commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> t[1].commit()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
>> line 1643, in commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self._do_commit()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
>> line 1674, in _do_commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.connection._commit_impl()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
>> line 726, in _commit_impl
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self._handle_dbapi_exception(e, None, None, None, None)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
>> line 1409, in _handle_dbapi_exception
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> util.raise_from_cause(newraise, exc_info)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", 
>> line 265, in raise_from_cause
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> reraise(type(exception), exception, tb=exc_tb, cause=cause)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", 
>> line 724, in _commit_impl
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self.engine.dialect.do_commit(self.connection)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py", 
>> line 1765, in do_commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> dbapi_connection.commit()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
>> line 422, in commit
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> self._read_ok_packet()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
>> line 396, in _read_ok_packet
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db pkt = 
>> self._read_packet()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", 
>> line 683, in _read_packet
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> packet.check_error()
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/protocol.py", 
>> line 220, in check_error
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> err.raise_mysql_exception(self._data)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File 
>> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/err.py", 
>> line 109, in raise_mysql_exception
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db raise 
>> errorclass(errno, errval)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db 
>> OperationalError: (pymysql.err.OperationalError) (1213, u'WSREP 
>> detected deadlock/conflict and aborted the transaction. Try 
>> restarting the transaction') (Background on this error at: 
>> http://sqlalche.me/e/e3q8)
>> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db
>> 2019-04-15 16:52:20.020 24 INFO nova.servicegroup.drivers.db [-] 
>> Recovered from being unable to report status.
>
> This is a service update operation which could indicate that the other 
> computes are reported as 'down' and that's why nothing is getting 
> scheduled to them. Have you checked the "openstack compute service 
> list" output to make sure those computes are all reporting as "up"?


yes, all compute nodes are up in the "openstack compute service list"

>
> https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-list 
>
>
> There is a retry_on_deadlock decorator on that service_update DB API 
> though so I'm kind of surprised to still see the deadlock errors, 
> unless those just get logged while retrying?
>
> https://github.com/openstack/nova/blob/stable/queens/nova/db/sqlalchemy/api.py#L566 
>

yep, it's pretty unclear why this is happening. Our Cloud is not used 
that much, so it's very likely to be the only intance spawned in that 
timeframe, and as we have a single writer node in the Percona Cluster, I 
can't imagine why there should be any deadlock situation occurring.


>
>>
>>
>> The deadlock message is quite strange, as we have haproxy configured 
>> so all write requests are handled by one node.
>>
>>
>> There are NO errors in the mysqld.log WHILE creating an instance, but 
>> we see from time to time aborted connections from nova.
>>
>> 2019-04-15T14:22:36.232108Z 30616972 [Note] Aborted connection 
>> 30616972 to db: 'nova' user: 'nova' host: '10.x.y.z' (Got an error 
>> reading communication packets)
>>
>>
>>
>> As I said, all instances are allocated to the same compute node. 
>> nova-compute.log doesn't show an error while creating the instance.
>>
>>
>> Beside that, we also see messages from nova.scheduler.host_manager on 
>> all other nodes like (but those messages are _not_ triggered, when an 
>> instance is spawned.!)
>>
>>
>> 2019-04-15 16:28:47.771 22 INFO nova.scheduler.host_manager 
>> [req-f92e340e-a88a-44a0-8cad-588390c25bc2 - - - - -] The instance 
>> sync for host 'xxx' did not match. Re-created its InstanceList.
>
> Are there any instances on these other hosts? My guess is you're 
> seeing that after the live migration to another host.

that may be true as I manually reallocated lots of VMs around that 
timestamps. Thanks for the explanation.


>
>>
>>
>>
>> Don't know if that may be relevant, but somehow our (currently 
>> single) AZ is listed several times.
>>
>>
>> # openstack availability zone list
>> +------------+-------------+
>> | Zone Name  | Zone Status |
>> +------------+-------------+
>> | internal   | available   |
>> | az1 | available           |
>> | az1 | available           |
>> | az1 | available           |
>> | az1 | available           |
>> +------------+-------------+
>>
>> May that be related somehow?
>
> I believe those are the AZs for other services as well 
> (cinder/neutron). Specify the --compute option to filter that.
you're right, when I specify --compute there is only one AZ shown. Again 
thanks for the clarification! :-)
>
> -- 
>
> Another thing to check is placement - are there 8 compute node 
> resource providers reporting into placement? You can check using the CLI:
>
> https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list 
>
>
> In Queens, there should be one resource provider per working compute 
> node in the cell database's compute_nodes table (the UUIDs should 
> match as well).

I do not have "openstack resource provider"? but in "openstack 
hypervisor list" I can see all compute nodes with state "up".


-- 


EveryWare AG
Nicolas Ghirlanda
Senior Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

T  +41 44 466 60 00
F  +41 44 466 60 10

nicolas.ghirlanda at everyware.ch
www.everyware.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/00b1a505/attachment-0001.bin>

From skaplons at redhat.com  Tue Apr 16 09:03:50 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Tue, 16 Apr 2019 11:03:50 +0200
Subject: [neutron] Cleaning in Neutron
Message-ID: <ED09A138-C9C9-497F-A051-D79A7706268B@redhat.com>

Hi,

I just run abandon_old_reviews.sh [1] script again for neutron, neutron-lib and neutron-tempest-plugin repositories.
So if You have Your patch abandoned but You want to continue to work on it, please simple restore it or if You can’t restore it by self, please ping me on irc (slaweq) and I will restore it for You.

[1] https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From skaplons at redhat.com  Tue Apr 16 09:06:53 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Tue, 16 Apr 2019 11:06:53 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <CAHeS+3-yeROwZkjSyQ93vjaECEfNsdC_hGEDC9BarNQ4tgOeNg@mail.gmail.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
 <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
 <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>
 <CAHeS+3-yeROwZkjSyQ93vjaECEfNsdC_hGEDC9BarNQ4tgOeNg@mail.gmail.com>
Message-ID: <8748D38C-4ACA-4823-9C24-52260AC8A058@redhat.com>

Hi,

> Wiadomość napisana przez Bence Romsics <bence.romsics at gmail.com> w dniu 16.04.2019, o godz. 10:48:
> 
> Hi All,
> 
> On Mon, Apr 15, 2019 at 8:08 PM Zane Bitter <zbitter at redhat.com> wrote:
>> On 15/04/19 1:23 PM, Slawomir Kaplonski wrote:
>>> IMO option 2 provided by Bence is the best one here. This should be fixed in neutron API by making extra routes first class API objects and treat them as router interfaces. DB layer is „ready” for that IMO so it should be handled easy.
>>> All other ways it will just be kind of workaround of the issue. Even if we will fix it in OpenStack SDK and/or neutron client there may be someone who is using API in some other way and will still hit the same issue.
>> 
>> Oh, for sure. If Neutron is willing to do that then that is definitely
>> the best solution.
> 
> I'm inclined to take that as a shared agreement to prefer way #2 over
> the other alternatives brought up in this thread. That is first class
> extra routes in neutron and adapt the heat resource to that.
> 
> I am willing to take up both the Neutron and Heat sides of this work
> in the Train cycle if the projects agree this is a good idea to work
> on and it is worth the review cycles. As a next step I'll write up a
> Neutron RFE. And at least open a placeholder Heat blueprint - which
> I'll be able to specify better when the first class extraroute Neutron
> API is agreed on. Please expect these coming still before the PTG.
> I'll be attending the Summit and the PTG in Denver so we can discuss
> these in person if we feel that's needed at that time.

Thx a lot for working on this Bence :)

> 
> Thanks,
> Bence
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From florian.engelmann at everyware.ch  Tue Apr 16 09:38:29 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Tue, 16 Apr 2019 11:38:29 +0200
Subject: [ceilometer] Missing some notifications
Message-ID: <71e6e899-9a9f-417a-f2d8-e76302002f21@everyware.ch>

Hi,

I am not sure if this problem is related to ceilometer or rabbitmq but 
it looks like our ceilometer notification agent is missing some 
notifications. Creating, eg. 10 cinder volumes in a row results in some 
of those volumes are not stored in gnocchi. "openstack metric resource 
show <ID>" results in a 404 error. Attaching the volume and detaching it 
again sometimes helps to "create" it in gnocchi.
We do use gnocchi for billing. So missing volumes is very bad.
Any recommendation on how to debug this problem?

Thank you very much,
flo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/67ce2772/attachment.bin>

From thierry at openstack.org  Tue Apr 16 09:44:33 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 16 Apr 2019 11:44:33 +0200
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
Message-ID: <99141c3a-14e7-fbe5-e411-63db423d1328@openstack.org>

Matt Riedemann wrote:
> Now that Stein is GA I figured I'd write up a quick retrospective for 
> the upgrade-checkers goal [1].
> [...]

Thanks Matt for driving this, and thanks to Akhil, Rajat, Ben and others 
for working on it ! Hoping to see that framework more widely used in the 
future to help operators proactively address OpenStack upgrade issues.

-- 
Thierry Carrez (ttx)


From yamamoto at midokura.com  Tue Apr 16 10:05:16 2019
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Tue, 16 Apr 2019 19:05:16 +0900
Subject: [taas] stein
In-Reply-To: <CAH=wFzTTLBksv5oaCOAUDWHN3Ge3=unUrC4vb89MgAe-BCWVhw@mail.gmail.com>
References: <CAH=wFzTTLBksv5oaCOAUDWHN3Ge3=unUrC4vb89MgAe-BCWVhw@mail.gmail.com>
Message-ID: <CAH=wFzRro6f_MmHoxLQcDZp1F3+fTPTCq2um73_tbQyeBG33Fg@mail.gmail.com>

On Wed, Apr 10, 2019, 11:35 Takashi Yamamoto <yamamoto at midokura.com> wrote:

> hi,
>
> i'll branch and release it sooner or later.
> probably in this week, or maybe the next one.
>

Done


> wrt dashboard, i'm not sure if the repo is in a ready-to-release state.
> have anyone tested it recently?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/4af11c82/attachment.html>

From florian.engelmann at everyware.ch  Tue Apr 16 10:14:25 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Tue, 16 Apr 2019 12:14:25 +0200
Subject: [neutron] neutron-metering-agent track router and floating IP traffic
Message-ID: <f69a282d-5ab1-32fc-0290-b41e1f34fcc0@everyware.ch>

Hi,

I configured our neutron meters like:

labels:
openstack network meter create --description "shared 
bandwidth-public-out" --share bandwidth-public-out
openstack network meter create --description "shared 
bandwidth-public-in" --share bandwidth-public-in

rules:
openstack network meter rule create --egress --remote-ip-prefix 
0.0.0.0/0 bandwidth-public-out
openstack network meter rule create --ingress --remote-ip-prefix 
0.0.0.0/0 bandwidth-public-in

This created the iptables rules in all namespaces and collects data:

openstack metric measures show bc6c670f-cbb5-4fe1-974c-10455448fa27
+---------------------------+-------------+---------------+
| timestamp                 | granularity |         value |
+---------------------------+-------------+---------------+
| 2019-04-15T16:00:00+02:00 |      3600.0 | 581854.954545 |
| 2019-04-15T17:00:00+02:00 |      3600.0 | 23169398.5625 |
| 2019-04-15T18:00:00+02:00 |      3600.0 |      586508.9 |
| 2019-04-15T19:00:00+02:00 |      3600.0 | 1276372.84375 |
| 2019-04-15T20:00:00+02:00 |      3600.0 | 507482.911765 |
[...]

But how to know which project caused which amount of traffic?

It looks like only one metric is created for each label?

openstack metric list | grep bandwidth
| 0f9f20a4-1c60-442f-81cb-48285e3f70da | ceilometer-ew-low | bandwidth 
                     | B       | efae8040-85d7-455a-958d-213a81ef98ef |
| 1a058a79-965f-4a0a-a9ee-d482f57892ab | ceilometer-ew-low | bandwidth 
                     | B       | 837ed34a-65d2-42ef-924e-fd3c7e5aaed6 |


What does "shared" mean? I was not able to find any relevant documentation.
Do I have to create a meter for each project or a rule or both? Is it 
possible to define a "default" meter and rule for every existing project 
and all future projects?

All the best,
Flo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/04336c44/attachment-0001.bin>

From pshchelokovskyy at mirantis.com  Tue Apr 16 10:38:29 2019
From: pshchelokovskyy at mirantis.com (Pavlo Shchelokovskyy)
Date: Tue, 16 Apr 2019 13:38:29 +0300
Subject: [keystone][heat] security_compliance options and auto-created users
Message-ID: <CACfB1uvuOkqNx49148axje6Y-pMnr-bZtSZsyeQbZn9L9_WboQ@mail.gmail.com>

Hi all,

I am currently looking at options defined in [security_compliance] section
of keystone.conf [0] and trying to understand how enabling those security
features may affect other services.

The first thing I see is that any project that auto-creates some temporary
users may be affected.
Of the top of my head I can recall only Heat and Tempest doing this.
For Tempest situation is easier as a) tempest can use static credentials
instead of dynamic ones so it is possible to craft appropriate users
beforehand and b) those users are relatively short-lived (required for
limited time).
In case of Heat though those users are used for deferred auth (like in
autoscaling) which for long lived stacks can happen at arbitrary time in
future - which is a problem.

Below is breakdown of options/features possible to set and what problems
that may pose for Heat and ideas on how to work those around:

- disable_user_account_days_inactive - this may pose a problem for deferred
auth, and it seems is not possible to override it via user "options". IMO
there's a need to add a new user option to Keystone to ignore this setting
for given user, and then use it in Heat to create temporary users.
- lockout failure options (lockout_failure_attempts, lockout_duration) -
can be overridden by user option, but Heat has to set it first. Also the
question remains how realistically such problem may arise for an
auto-created internal user and whether Heat should set this option at all
- password expiry options
(password_expires_days, unique_last_password_count, minimum_password_age) -
poses a problem for deferred auth, but can be overridden by user option, so
Heat should definitely set it IMO for users it creates
- change_password_upon_first_use - poses problem for auto-generated users,
can be overridden by a user option, but Heat must set it for its generated
users
- password strength enforcement
(password_regex, password_regex_description) - now this is an interesting
one. Currently Heat creates passwords for its temporary users with this
function [1] falling back to empty password if a resource is not generating
one for itself. Depending on regex_password setting in keystone, it may or
may not be enough to pass the password strength check.
I've looked around and (as expected) generating a random string which
satisfies a pre-defined arbitrary regex is quite a non-trivial task, couple
of existing Python libraries that can do this note that they support only a
limited subset of full regex spec.
So it seems that a most simple solution would be to add yet another user
option to Keystone to ignore password strength enforcement for this given
user, and amend Heat to set this option as well for internal users it
creates.

We in Heat may also think as to whether it would have any benefit to also
set the 'lock_password' user option for the auto-created users which will
prohibit such users to change their passwords via API themselves.

I'd very like to hear opinion from Keystone community as most solutions I
named are 'add new user option to Keystone' :-)

[0]
https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/security_compliance.py
[1]
https://opendev.org/openstack/heat/src/branch/master/heat/common/password_gen.py#L112

Cheers,
- Pavlo
-- 
Dr. Pavlo Shchelokovskyy
Principal Software Engineer
Mirantis Inc
www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/4beed7e4/attachment.html>

From navdeep.uniyal at bristol.ac.uk  Tue Apr 16 12:01:34 2019
From: navdeep.uniyal at bristol.ac.uk (Navdeep Uniyal)
Date: Tue, 16 Apr 2019 12:01:34 +0000
Subject: [Zun] Openstack Rocky Appcontainer start error
Message-ID: <AM6PR06MB5879F2DBBBB098F8AC03B50ADE240@AM6PR06MB5879.eurprd06.prod.outlook.com>

Dear All,

I am getting following error while trying to start the ubuntu container
Command: openstack appcontainer run --name containerA --net network=5guknet ubuntu ping 8.8.8.8

Error:
status_reason     | Docker internal error: 500 Server Error: Internal Server Error ("legacy plugin: Post http://127.0.0.1:23750/Plugin.Activate: dial tcp 127.0.0.1:23750: connect: connection refused").

Secondly, with Heat Template:

heat_template_version: 2015-04-30

resources:
  the_resource:
    type: OS::Zun::Container
    properties:
      cpu: 4
      image: ubuntu
      image_pull_policy: "ifnotpresent"
      interactive: true
      memory: 2048
      name: "ubuntu16"
      command: "ping 8.8.8.8"
      networks: [{"network": 5guknet}]
      restart_policy: "no"

The command I can see on the appcontainer show is : command           | [u'p', u'i', u'n', u'g', u' ', u'8', u'.', u'8', u'.', u'8', u'.', u'8']

Please advise how to resolve the two issues.

Kind Regards,
Navdeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/fe919db0/attachment.html>

From cdent+os at anticdent.org  Tue Apr 16 12:33:53 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 13:33:53 +0100 (BST)
Subject: [nova][scheduler] scheduler spawns to the same compute node only
In-Reply-To: <750d4346-26cc-f462-9a5e-454e520e950a@everyware.ch>
References: <6e565fe1-0ca0-72f3-4b4c-e4379806dc9b@everyware.ch>
 <3bd1426d-101a-03fb-3c54-e8937956a67b@gmail.com>
 <750d4346-26cc-f462-9a5e-454e520e950a@everyware.ch>
Message-ID: <alpine.OSX.2.21.1904161332520.1166@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Nicolas Ghirlanda wrote:

>> Another thing to check is placement - are there 8 compute node resource 
>> providers reporting into placement? You can check using the CLI:
>> 
>> https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list 
>> 
>> In Queens, there should be one resource provider per working compute node 
>> in the cell database's compute_nodes table (the UUIDs should match as 
>> well).
>
> I do not have "openstack resource provider"? but in "openstack hypervisor 
> list" I can see all compute nodes with state "up".

To get the placement related commands in the openstack you need to
install the osc-placement plugin: https://pypi.org/project/osc-placement/

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From petebirley+openstack-dev at gmail.com  Tue Apr 16 12:51:12 2019
From: petebirley+openstack-dev at gmail.com (Pete Birley)
Date: Tue, 16 Apr 2019 07:51:12 -0500
Subject: [openstack-helm] Office hours - 20:00-21:00UTC Wednesdays in
 #openstack-helm
Message-ID: <CALR0ytAJHw8M4mBCcBhg2HOR=h04xLvy_n2yaPUib2ZCtHX_jA@mail.gmail.com>

------------------------------

Hey!

Thanks to all those who could attend the meeting we held on the 9th of
April; at this meeting we decided that we would resume holding office
hours weekly in IRC until the end of this development cycle at least.
These will be in our standard channel #openstack-helm, from
20:00-21:00UTC on Wednesdays. During this time we will ensure that
there is representation from the core reviewers, and try to help with
general support: from onboarding, and deployment issues, to more
interactive disucssion regarding specs and testing - please drop in
and ask us anything! :)

The meeting agenda for this is here:

* https://etherpad.openstack.org/p/openstack-helm-meeting-2019-04-09

With minutes logged here:
* http://eavesdrop.openstack.org/meetings/openstack_helm/2019/openstack_helm.2019-04-09-15.01.txt

The next OpenStack-Helm meeting will be held on the 16th April, at
3pm UTC in #openstack-meeting-4 in freenode IRC, with the following
agenda: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-04-16

Cheers

Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/ecf4e36f/attachment-0001.html>

From mike_mp at zzzcomputing.com  Tue Apr 16 13:11:26 2019
From: mike_mp at zzzcomputing.com (Mike Bayer)
Date: Tue, 16 Apr 2019 09:11:26 -0400
Subject: [neutron] Cleaning in Neutron
In-Reply-To: <ED09A138-C9C9-497F-A051-D79A7706268B@redhat.com>
References: <ED09A138-C9C9-497F-A051-D79A7706268B@redhat.com>
Message-ID: <CA+RjkXGdFq_=E8oOA6SYyRf9uiscWtHaGY7Bcz8=S96u2zJ89Q@mail.gmail.com>

There are a lot of very important and large DB related changes here
that were unfortunately abandoned by their contributors [1] [2].
Neutron remains from a SQLAlchemy / oslo.db perspective in this very
awkward state where it is halfway between using legacy oslo.db access
patterns and the "newer" enginefacade, which is now four years old.
This leads to complicated issues that are difficult to develop around
and debug [3].

I don't have a solution to this problem as I am not tasked with
Neutron to the degree that would be necessary to complete these
migrations on my own, however as always, I eagerly await the arrival
of developers who can commit to seeing these refactorings through,
where I will of course be available to help.

[1] https://review.openstack.org/#/c/545501/
[2] https://review.openstack.org/#/c/396121/
[3] https://review.openstack.org/#/c/348080/57/neutron/tests/unit/extensions/test_subnet_onboard.py at 42


On Tue, Apr 16, 2019 at 5:08 AM Slawomir Kaplonski <skaplons at redhat.com> wrote:
>
> Hi,
>
> I just run abandon_old_reviews.sh [1] script again for neutron, neutron-lib and neutron-tempest-plugin repositories.
> So if You have Your patch abandoned but You want to continue to work on it, please simple restore it or if You can’t restore it by self, please ping me on irc (slaweq) and I will restore it for You.
>
> [1] https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
>
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>


From juliaashleykreger at gmail.com  Tue Apr 16 14:12:52 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Tue, 16 Apr 2019 07:12:52 -0700
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <c1150b3f-c2d3-4c8f-974a-759fee5090dc@openstack.org>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
 <c1150b3f-c2d3-4c8f-974a-759fee5090dc@openstack.org>
Message-ID: <CAF7gwdhVOJ0Y77LF450SHkez4MZeKYgFf_1ysML0fZ_91xJ4OQ@mail.gmail.com>

On Tue, Apr 16, 2019 at 1:33 AM Thierry Carrez <thierry at openstack.org> wrote:
>
> Julia Kreger wrote:
> > [...]
> > Is it time for us, as a community, to whip up something that helps
> > provide basic insight?
>
> I think we should first agree on what we actually need.
>

I think this is vital. Things like reviewstats seems to be useful for
review activity but I think there is also an aspect of activity that
comes between releases or between stable branches for project teams.
Statements like "We had x number of contributors during y release
contribute code into z project" and "we observed x percentage change
in activity over the past cycle? The cycle before was z percentage?"
Helps us determine where we are presently so we can chart our future
course. Lots of graphs are pretty, but I think we can all turn numbers
based reporting into pretty aggregate graphs if something is
collecting the dimensions of raw data needed to count lines or to add
numbers in columns.

> A first level would be to extract the data about changes and reviews
> from Gerrit into a query-able system so that we don't have everyone
> hammering Gerrit with individual stats queries. Then people can share
> their "insights scripts" and run them on the same official data.
>

In my mind, the extracted data could just be data in text files that
could be used with some simple scripting to create useful reporting.
The moderate pain point is collecting all of that data and the point
where things start breaking is repositories that are part of projects
that do are considered released as needed utilities that are not
branched and the branch points can't be used to compare velocity.

> A second level would be to come up with some common definition of "basic
> insight" and produce that data for all teams. Personally I think the
> first level would already give us a lot more confidence and consistency
> in the numbers we produce.

++

> As an aside, the OSF has been driving a proof-of-concept experiment to
> use Bitergia tooling (now ELK-based) for Kata Containers and StarlingX,
> which we could extend to OpenStack and all other OSF projects if successful.
>
> Historically we dropped the old Bitergia tooling because it was falling
> short with OpenStack complexity (groups of repositories per project
> team) and release-timeframe data, and its visualization capabilities
> were limited. But the new version is much better-looking and flexible,
> so it might be a solution in the long term.
>
> --
> Thierry Carrez (ttx)
>


From fungi at yuggoth.org  Tue Apr 16 14:31:20 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 16 Apr 2019 14:31:20 +0000
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CCAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
Message-ID: <20190416143120.bnrfztyvdnnwzhqg@yuggoth.org>

On 2019-04-11 18:21:13 UTC (+0000), Mark Goddard wrote:
> I've heard a couple of people say they don't feel the numbers
> reported by Stackalytics accurately reflect reality. I've been
> trying to gather a few stats for my Kolla update session in
> Denver, and am finding the same.
[...]

I'm not going to attempt to debate the value of the Stackalytics
site, but given the maintainers seem to have set their sights beyond
OpenStack lately they're probably not following discussions on the
openstack-discuss mailing list (their lack of replies here after
nearly a week would indicate this as well). According to the
readme[*] for the project, they seem to prefer bug reports via
Launchpad so that may be a more effective place to follow up on this
concern if there is a desire for continued use of Stackalytics by
the OpenStack community. That said, someone already seems to have
reported[**] the problem back in January and the bug hasn't been
triaged yet, but maybe additional mee-toos will up their urgency?

[*] https://opendev.org/openstack/stackalytics/src/branch/master/README.rst#project-info
[**] https://launchpad.net/bugs/1811028
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/77728155/attachment.sig>

From Arkady.Kanevsky at dell.com  Tue Apr 16 14:31:54 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Tue, 16 Apr 2019 14:31:54 +0000
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAF7gwdhVOJ0Y77LF450SHkez4MZeKYgFf_1ysML0fZ_91xJ4OQ@mail.gmail.com>
References: <CAFHSqWokLbRpBD94mSHxekqgztnxMiSeAie9+oLxwnRi8+0Yaw@mail.gmail.com>
 <CAF7gwdjo9Z3s27sMn+o-oHY4mx5-qhPKpcQBbbpfy1zBi++1Gg@mail.gmail.com>
 <c1150b3f-c2d3-4c8f-974a-759fee5090dc@openstack.org>
 <CAF7gwdhVOJ0Y77LF450SHkez4MZeKYgFf_1ysML0fZ_91xJ4OQ@mail.gmail.com>
Message-ID: <217f78ae953f4c40a1f0443c732018d8@AUSX13MPS308.AMER.DELL.COM>

We are using it to see company-wide contributions per release, per some specific time period work company wide.
I usually look for PR, reviews, and time spend. This is for individuals and companies.

-----Original Message-----
From: Julia Kreger <juliaashleykreger at gmail.com> 
Sent: Tuesday, April 16, 2019 9:13 AM
To: Thierry Carrez
Cc: openstack-discuss
Subject: Re: [stackalytics] Reported numbers seem inaccurate


[EXTERNAL EMAIL] 

On Tue, Apr 16, 2019 at 1:33 AM Thierry Carrez <thierry at openstack.org> wrote:
>
> Julia Kreger wrote:
> > [...]
> > Is it time for us, as a community, to whip up something that helps 
> > provide basic insight?
>
> I think we should first agree on what we actually need.
>

I think this is vital. Things like reviewstats seems to be useful for review activity but I think there is also an aspect of activity that comes between releases or between stable branches for project teams.
Statements like "We had x number of contributors during y release contribute code into z project" and "we observed x percentage change in activity over the past cycle? The cycle before was z percentage?"
Helps us determine where we are presently so we can chart our future course. Lots of graphs are pretty, but I think we can all turn numbers based reporting into pretty aggregate graphs if something is collecting the dimensions of raw data needed to count lines or to add numbers in columns.

> A first level would be to extract the data about changes and reviews 
> from Gerrit into a query-able system so that we don't have everyone 
> hammering Gerrit with individual stats queries. Then people can share 
> their "insights scripts" and run them on the same official data.
>

In my mind, the extracted data could just be data in text files that could be used with some simple scripting to create useful reporting.
The moderate pain point is collecting all of that data and the point where things start breaking is repositories that are part of projects that do are considered released as needed utilities that are not branched and the branch points can't be used to compare velocity.

> A second level would be to come up with some common definition of 
> "basic insight" and produce that data for all teams. Personally I 
> think the first level would already give us a lot more confidence and 
> consistency in the numbers we produce.

++

> As an aside, the OSF has been driving a proof-of-concept experiment to 
> use Bitergia tooling (now ELK-based) for Kata Containers and 
> StarlingX, which we could extend to OpenStack and all other OSF projects if successful.
>
> Historically we dropped the old Bitergia tooling because it was 
> falling short with OpenStack complexity (groups of repositories per 
> project
> team) and release-timeframe data, and its visualization capabilities 
> were limited. But the new version is much better-looking and flexible, 
> so it might be a solution in the long term.
>
> --
> Thierry Carrez (ttx)
>


From juliaashleykreger at gmail.com  Tue Apr 16 14:55:13 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Tue, 16 Apr 2019 07:55:13 -0700
Subject: [ironic] Cancelling meetings April 22nd through May 6th,
 resuming May 13th
Message-ID: <CAF7gwdiPHVkMfvz5-b5aKmhOefiBg8zpzWTvnAebabVKBprOXg@mail.gmail.com>

Greeting fellow practitioners of irony!

I meant to raise this question during our weekly meeting yesterday,
but simply forgot. Some discussion on irc[0] today has reached a
consensus that we should just cancel the next few meetings.

* This next week, April 22nd, out meeting conflicts with holidays for
a number of contributors.
* The week after, April 29th, will be during the Open Infrastructure
Summit. Historically we cancel the meeting on the week following such
a gathering to give contributors time to re-group.

We will be resuming meetings on May 13th. As always you can find
ironic contributors in #openstack-ironic. Review priorities should be
sourced from the whiteboard[1] using the "This Week's Priorities"
section..

Thanks everyone!

-Julia

[0]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2019-04-16.log.html#t2019-04-16T14:16:33
[1]: https://etherpad.openstack.org/p/IronicWhiteBoard


From soulxu at gmail.com  Tue Apr 16 15:15:59 2019
From: soulxu at gmail.com (Alex Xu)
Date: Tue, 16 Apr 2019 23:15:59 +0800
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <1554908040.15038.0@smtp.office365.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
Message-ID: <CAH7mGatD+8i_zVCdtA-MfEXXRWwnY9-6uJCB7kERkGpjmC0f6Q@mail.gmail.com>

Balázs Gibizer <balazs.gibizer at ericsson.com> 于2019年4月10日周三 下午10:59写道：

>
>
> On Wed, Apr 10, 2019 at 3:38 PM, Eric Fried <openstack at fried.cc> wrote:
> >>  Since providers can be nested a provider can be a strucutral
> >> element in
> >>  a nested tree without providing resources.
> >
> > This.
> >
> > I wouldn't get too hung up on "a resource provider that doesn't
> > provide
> > resources". "Resource provider" is just a name of a thing. It doesn't
> > (can't) exhaustively define what the thing is and does.
> >
> >>  To avoid the trait on an empty RP problem in this case all
> >>  the traits are added to the device RPs even if some of the traits
> >>  (CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP.
> >
> > Noting that I have at best a cursory understanding of all things
> > network, this seems okay to me; I can get my brain around a "network
> > device" having a "VNIC type" trait. However...
> >
> >>  I think the possible solution to move the trait down to the RP that
> >>  provides the resources that has a capability described by the trait
> >
> > In Matt's patch, the traits represent capabilities of the virt
> > driver. I
> > *suppose* you could argue to attach traits like
> > COMPUTE_NET_ATTACH_INTERFACE to providers of network resources, or
> > COMPUTE_VOLUME_EXTEND to providers of disk resources (even those are
> > pretty awkward). But where would you put COMPUTE_TRUSTED_CERTS? And
> > let's please not contrive non-resource resources to satisfy
> > architectural purity.
>
> Good point. I agree that the COMPUTE_TRUSTED_CERTS logically belong to
> the root RP of the compute node.
> So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA requires
> placement to support traits on RPs that are not providing resources.
> Will in this case VCPU and MEMORY_MB always requested in the unnumbered
> group still? Or there are cases when those resources are requested in a
> numbered group? If the alter then we have a use case to support request
> groups in a_c query that only requires a trait COMPUTE_TRUSTED_CERTS
> but does not require any resoruces.
>

Maybe the problem isn't "traits on RP that are not providing resources",
the problem is we don't count the resources, those traits are attach to, in
the compute node. So all those virt driver capability traits are talking
about the capability of VM (or say VM resources). But we don't count the
number of VM, so we won't have inventory for the VM. The compute node is
using the VM(or BM, but just use VM as example here) to provide the compute
resources. So I think it is ok to attach those traits to the RP which
provides VCPU resource.


>
>
> >>  I think this work should be driven by a specific need, like the NUMA
> >>  modelling in placement by nova. What is the timeline of NUMA
> >> modelling
> >>  in placement?
> >
> > Proposes NUMA topology with RPs: https://review.openstack.org/552924
> > Proposes NUMA affinity for vGPUs: https://review.openstack.org/650963
> > Spec: Allocation Candidates: Subtree Affinity:
> > https://review.openstack.org/650476
> >
> > and a bunch of the other specs in flight are affected by NUMA
> > modeling.
> >
> > We've been building up to this for years. If it doesn't happen in
> > Train,
> > it'll happen in U. While I agree we shouldn't solve a problem until
> > it's
> > a problem, I also don't want to another situation like reshaper, where
> > suddenly at the end of the cycle we realize/remember this nontrivial
> > thing we need to handle.
>
> I don't want to delay the developement of this feature. I would like to
> see that we implement a certain feature in placement because it is
> needed for specific use case for a specific consumer of placement. So
> if the above discovered use case (COMPUTE_TRUSTED_CERTS + NUMA) are
> valid then I have no problem adding the necessary changes to placement
> to make this use case doable in nova.
>
> Cheers,
> gibi
>
> >
> > efried
> > .
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/0edb4b89/attachment-0001.html>

From balazs.gibizer at ericsson.com  Tue Apr 16 15:25:39 2019
From: balazs.gibizer at ericsson.com (=?utf-8?B?QmFsw6F6cyBHaWJpemVy?=)
Date: Tue, 16 Apr 2019 15:25:39 +0000
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <CAH7mGatD+8i_zVCdtA-MfEXXRWwnY9-6uJCB7kERkGpjmC0f6Q@mail.gmail.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <1554888244.14045.10@smtp.office365.com>
 <f4db6c80-7833-3a65-4c03-679f1abcc23a@fried.cc>
 <1554908040.15038.0@smtp.office365.com>
 <CAH7mGatD+8i_zVCdtA-MfEXXRWwnY9-6uJCB7kERkGpjmC0f6Q@mail.gmail.com>
Message-ID: <1555428333.23392.24@smtp.office365.com>



On Tue, Apr 16, 2019 at 5:15 PM, Alex Xu <soulxu at gmail.com> wrote:
> 
> 
> Balázs Gibizer <balazs.gibizer at ericsson.com> 
> 于2019年4月10日周三 下午10:59写道：
>> 
>> 
>> On Wed, Apr 10, 2019 at 3:38 PM, Eric Fried <openstack at fried.cc> 
>> wrote:
>> >>  Since providers can be nested a provider can be a strucutral
>> >> element in
>> >>  a nested tree without providing resources.
>> >
>> > This.
>> >
>> > I wouldn't get too hung up on "a resource provider that doesn't
>> > provide
>> > resources". "Resource provider" is just a name of a thing. It 
>> doesn't
>> > (can't) exhaustively define what the thing is and does.
>> >
>> >>  To avoid the trait on an empty RP problem in this case all
>> >>  the traits are added to the device RPs even if some of the traits
>> >>  (CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP.
>> >
>> > Noting that I have at best a cursory understanding of all things
>> > network, this seems okay to me; I can get my brain around a 
>> "network
>> > device" having a "VNIC type" trait. However...
>> >
>> >>  I think the possible solution to move the trait down to the RP 
>> that
>> >>  provides the resources that has a capability described by the 
>> trait
>> >
>> > In Matt's patch, the traits represent capabilities of the virt
>> > driver. I
>> > *suppose* you could argue to attach traits like
>> > COMPUTE_NET_ATTACH_INTERFACE to providers of network resources, or
>> > COMPUTE_VOLUME_EXTEND to providers of disk resources (even those 
>> are
>> > pretty awkward). But where would you put COMPUTE_TRUSTED_CERTS? And
>> > let's please not contrive non-resource resources to satisfy
>> > architectural purity.
>> 
>> Good point. I agree that the COMPUTE_TRUSTED_CERTS logically belong 
>> to
>> the root RP of the compute node.
>> So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA requires
>> placement to support traits on RPs that are not providing resources.
>> Will in this case VCPU and MEMORY_MB always requested in the 
>> unnumbered
>> group still? Or there are cases when those resources are requested 
>> in a
>> numbered group? If the alter then we have a use case to support 
>> request
>> groups in a_c query that only requires a trait COMPUTE_TRUSTED_CERTS
>> but does not require any resoruces.
> 
> Maybe the problem isn't "traits on RP that are not providing 
> resources", the problem is we don't count the resources, those traits 
> are attach to, in the compute node. So all those virt driver 
> capability traits are talking about the capability of VM (or say VM 
> resources). But we don't count the number of VM, so we won't have 
> inventory for the VM. The compute node is using the VM(or BM, but 
> just use VM as example here) to provide the compute resources. So I 
> think it is ok to attach those traits to the RP which provides VCPU 
> resource.

I'm not sure I understand your proposal. Would you introduce a VM 
resource and then allocate 1 of that resource for each VM?

Cheers,
gibi


From aschultz at redhat.com  Tue Apr 16 15:27:19 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Tue, 16 Apr 2019 09:27:19 -0600
Subject: [tripleo][ptg] Initial PTG schedule
Message-ID: <CAFsb3b5Cqi3V9Y1PKGYi=DyDh1OF9V4C-Wr42trTP3HRfiz-tQ@mail.gmail.com>

Hey folks,

I've taken the topics from the previously announced etherpad[0] and
put together a basic schedule for Thursday-Saturday.  Please take a
moment to review https://etherpad.openstack.org/p/tripleo-ptg-train
and let me know if there are any issues with the timing. We have some
extra time most days if we need to shift things around.

Thanks,
-Alex

[0] https://etherpad.openstack.org/p/tripleo-train-topics


From aschultz at redhat.com  Tue Apr 16 15:28:57 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Tue, 16 Apr 2019 09:28:57 -0600
Subject: [tripleo] Canceling IRC meeting on April 30, 2019
Message-ID: <CAFsb3b5JQBWH0p=iEFYYg9r5bSn=D4YdBt1tvaOXiftgH65HLA@mail.gmail.com>

Due to the summit and PTG, most folks won't be around so we'll cancel
the meeting for that week. We will resume the weekly IRC meeting on
May 7, 2019.

Thanks,
-Alex


From cdent+os at anticdent.org  Tue Apr 16 15:55:29 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 16:55:29 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.11.1904081452240.9091@seed.local>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
Message-ID: <alpine.OSX.2.21.1904161651510.4039@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Chris Dent wrote:

> As as I recall, allocation partitioning (distinct from
> resource provider partitioning) is a way of declaring that a set of
> allocations below to a specific service. This is useful as a way,
> for example, of counting instances spawned via nova. Right now it is
> possible to count vcpus, ram and disk but if something besides nova
> is making allocations using those resource classes how do we
> distinguish?

[snip]

> This functionality is closely tied to resource provider
> partitioning. In a complex placement scenario, where placement is
> managing multiple instance spawning tools, in multiple cloud-like
> things, it seems like both would be needed.

Above discussed at http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004720.html

Both these threads haven't really gone anywhere concrete, yet. Since
I know they've expressed some interest in partitioning in various
ways I've pinged Dan and Mel to join in when they get the chance.

If any operators or people from the Edge or NFV communities want to
chime in here, that would be excellent. If we don't hear anything
before the PTG it will be difficult to prioritize work related to
partitioning in the Train cycle.

Thanks.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Tue Apr 16 16:04:42 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 17:04:42 +0100 (BST)
Subject: [placement][ptg] Keeping osc-placement healthy
In-Reply-To: <alpine.OSX.2.11.1904081734490.9091@seed.local>
References: <alpine.OSX.2.11.1904081734490.9091@seed.local>
Message-ID: <alpine.OSX.2.21.1904161701230.4039@cdent-a01.vmware.com>


Since this thread started there have been a few changes:

> * It is behind (in microversions) and sometimes hard to remember

A new contributor has provided a microversion 1.22: https://review.openstack.org/#/c/651783/

> * It's functional tests require a working devstack, which is a bit meh
>    * Maybe something like https://vcrpy.readthedocs.io/en/latest/
>      could help (reasonable given microversions)

Based on Matt's suggestion I've changed the functional tests to use
the PlacementFixture https://review.openstack.org/#/c/651939/ and it
seems to work rather well.

> * (edleafe) It might be useful to have an osc-placement lead (czar?
>  princess? mayor?) who can devote some of their time to this and
>  help coordinate others. I might be able to rustle up some cycles.

What do people think of the idea of czar for osc-placement? Someone
who will keep it on the radar, thank kind of thing.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dms at danplanet.com  Tue Apr 16 16:13:47 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 09:13:47 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com> (Jay Pipes's
 message of "Tue, 9 Apr 2019 08:58:26 -0400")
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
Message-ID: <m2tveyyll0.fsf@caffeine.hv.danplanet.com>

> Obviously, all consumers are currently Nova instances in placement
> since (AFAIK) no other services have begun using placement to store
> allocations.

This is not the case, actually. In Nova, we can have consumers that are
instances, as well as consumers that are migrations (related to
instances, but distinct). In order to be able to distinguish between the
two, a partitioning key (I'd prefer we call this consumer type too) is
needed. The quota work needs this specifically, so that we can know the
usage by instances separately from usage that is reserved or pinned by
an ongoing migration.

>> How urgent is this? Is there anyone available to do the work this
>> cycle? How damaging is it to punt to U? What details are missing in
>> the above description?

I guess we defer this question to Melanie, but I think the ability to
count most of the quota elements we want using placement instead of the
current method hinges on the ability to distinguish these things.

--Dan


From dtantsur at redhat.com  Tue Apr 16 16:21:27 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 16 Apr 2019 18:21:27 +0200
Subject: [tripleo][ptg] Initial PTG schedule
In-Reply-To: <CAFsb3b5Cqi3V9Y1PKGYi=DyDh1OF9V4C-Wr42trTP3HRfiz-tQ@mail.gmail.com>
References: <CAFsb3b5Cqi3V9Y1PKGYi=DyDh1OF9V4C-Wr42trTP3HRfiz-tQ@mail.gmail.com>
Message-ID: <f71fb640-5e92-9e4c-d81d-d7e7595aa85d@redhat.com>

Hi,

On 4/16/19 5:27 PM, Alex Schultz wrote:
> Hey folks,
> 
> I've taken the topics from the previously announced etherpad[0] and
> put together a basic schedule for Thursday-Saturday.  Please take a
> moment to review https://etherpad.openstack.org/p/tripleo-ptg-train
> and let me know if there are any issues with the timing. We have some
> extra time most days if we need to shift things around.

If you'd like my input on the Nova/Ironic question of "Undercloud service 
review", would it be possible to move it to e.g. 4pm?

Dmitry

> 
> Thanks,
> -Alex
> 
> [0] https://etherpad.openstack.org/p/tripleo-train-topics
> 



From cdent+os at anticdent.org  Tue Apr 16 16:22:27 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 17:22:27 +0100 (BST)
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <76c1870b-aff9-6789-1569-8175568f82e1@gmail.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
 <DF3E4736-AF29-49F7-A10B-567A07742710@leafe.com>
 <76c1870b-aff9-6789-1569-8175568f82e1@gmail.com>
Message-ID: <alpine.OSX.2.21.1904161709430.4039@cdent-a01.vmware.com>

On Wed, 10 Apr 2019, Jay Pipes wrote:
> On 04/10/2019 12:46 PM, Ed Leafe wrote:
>> On Apr 9, 2019, at 2:37 PM, Monty Taylor <mordred at inaugust.com> wrote:
>>> We actually have some pretty awesome new container building jobs in Zuul 
>>> now - I'd recommend using them. One of the things they can do is build 
>>> your container image to be used in a gate job, and then when the patch for 
>>> the gate job merges, publish and tag the actual container image used in 
>>> the gate.
>> 
>> My concern is the one-offness of placedock, not that it wouldn't work. But 
>> if Zuul can support this container building step, and we ensure that 
>> placedock follows the pattern that Zuul uses, we should be good.
>
> Yeah, this was my thought as well. If we can (as the placement team) can take 
> and own the "recipe" for constructing the container image using the Zuul 
> container-image-building playbooks, then I'm 100% on board.

Right, I'll make a proto-story for this and we can pick it back up
post-PTG. Is there anyone itching to take the lead on this? Feel
free to adapt the story and add more tasks and assign yourself if
so.

https://storyboard.openstack.org/#!/story/2005463


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dms at danplanet.com  Tue Apr 16 16:23:37 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 09:23:37 -0700
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com> (Jay Pipes's
 message of "Tue, 9 Apr 2019 09:14:54 -0400")
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
Message-ID: <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>

>> As as I recall, resource provider partitioning (distinct from
>> allocation partitioning) is a way of declaring that a set of
>> resource providers are in a thing. This would allow, for example,
>> one placement to service multiple OpenStack clouds or for a
>> placement to be a part of a single pane of glass system in a FOG or
>> edge setup.

Yep, so taking the edge case because it's easy: It's very nice to be
able to have one single central cloud, where things like your keystone
(and possibly glance) lives. Then on the edges, you might have very
small or single-node nova deployments that use those services. They're
necessarily tiny because they're edges, and you want to maximize your
workload space on those nodes by not running anything you don't really
need. Further, since they're all disparate and disconnected (from a
resource-reporting point of view), being able to get *some* amount of
unified capacity view from a centralized placement would be nice (at the
expense of availability of course).

> 1:1 is the only thing that makes sense to me. Therefore, it should be
> a field on the resource_providers table (source_id or partition_id or
> whatever).

Yep, agree. Also, I think this would make it easy to use regular
database replication on just a shard of the whole dataset to improve the
availability concern above.

I don't think there's anyone beating down the door needing this right
now, but it's one of those things that will take a little time to filter
in (since we have to shard-ify the existing data) and we can hardly even
propose the conversation until it's at least planned. Most of the other
services are going through a more painful "okay we need to shard our
data" phase right now, so the longer we wait to do this, the harder it
will be (and the more latency involved when we do). Easy for me to say,
I know.

--Dan


From aschultz at redhat.com  Tue Apr 16 16:28:56 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Tue, 16 Apr 2019 10:28:56 -0600
Subject: [tripleo][ptg] Initial PTG schedule
In-Reply-To: <f71fb640-5e92-9e4c-d81d-d7e7595aa85d@redhat.com>
References: <CAFsb3b5Cqi3V9Y1PKGYi=DyDh1OF9V4C-Wr42trTP3HRfiz-tQ@mail.gmail.com>
 <f71fb640-5e92-9e4c-d81d-d7e7595aa85d@redhat.com>
Message-ID: <CAFsb3b7yYm8V-1Rgvp=dt_TQan576JKWDHEpkmeUNJyZZn=nzQ@mail.gmail.com>

On Tue, Apr 16, 2019 at 10:27 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> Hi,
>
> On 4/16/19 5:27 PM, Alex Schultz wrote:
> > Hey folks,
> >
> > I've taken the topics from the previously announced etherpad[0] and
> > put together a basic schedule for Thursday-Saturday.  Please take a
> > moment to review https://etherpad.openstack.org/p/tripleo-ptg-train
> > and let me know if there are any issues with the timing. We have some
> > extra time most days if we need to shift things around.
>
> If you'd like my input on the Nova/Ironic question of "Undercloud service
> review", would it be possible to move it to e.g. 4pm?
>

Sure we can discuss that last that day.

> Dmitry
>
> >
> > Thanks,
> > -Alex
> >
> > [0] https://etherpad.openstack.org/p/tripleo-train-topics
> >
>
>


From cdent+os at anticdent.org  Tue Apr 16 16:32:03 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 17:32:03 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
Message-ID: <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Dan Smith wrote:

>> Obviously, all consumers are currently Nova instances in placement
>> since (AFAIK) no other services have begun using placement to store
>> allocations.
>
> This is not the case, actually. In Nova, we can have consumers that are
> instances, as well as consumers that are migrations (related to
> instances, but distinct). In order to be able to distinguish between the
> two, a partitioning key (I'd prefer we call this consumer type too) is
> needed. The quota work needs this specifically, so that we can know the
> usage by instances separately from usage that is reserved or pinned by
> an ongoing migration.

When you think of "consumer type" do you imagine it as an
enumeration with members similar to "instance",
"instance-migration", "reservation" where those types are the same
in all placement deployments, including those which are being used
by multiple clouds (or multiple novas).

What I'm trying to make sure about is: Is this a concept that is
fully distinct from resource provider partitioning/shards/whatever
the right word is, solely associated a consumer and the allocations
it has right now? If not, how so?

Thanks.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dms at danplanet.com  Tue Apr 16 17:33:45 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 10:33:45 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com> (Chris
 Dent's message of "Tue, 16 Apr 2019 17:32:03 +0100 (BST)")
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
Message-ID: <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>

> When you think of "consumer type" do you imagine it as an enumeration
> with members similar to "instance", "instance-migration",
> "reservation" where those types are the same in all placement
> deployments, including those which are being used by multiple clouds
> (or multiple novas).

I guess it seems more like it needs to be (loosely) an enum within a
given shard. Like "I'm nova, my shard is $UUID and within that shard, my
consumer types are instance, migration, etc". Might also be "I'm ironic,
my shard is $UUID and within that shard, my consumer types are
nova-instance, standalone-use, etc".

I don't really want to codify the enum in placement, as I think it's
just a key that the consuming service uses to correlate the "reason" for
each allocation. Some (like nova) could be a static small enum, but for
others it could need to be dynamic and scale per tenant or something
like that.

> What I'm trying to make sure about is: Is this a concept that is
> fully distinct from resource provider partitioning/shards/whatever
> the right word is, solely associated a consumer and the allocations
> it has right now? If not, how so?

I'd like it to be fully distinct. If it's not, then nova basically needs
to define consumers as "instance-$nova_distinct_deployment_uuid" instead
of "instance", effectively using the consumer type as both a consumer
type and a shard key.

--Dan


From melwittt at gmail.com  Tue Apr 16 17:38:50 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 10:38:50 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
Message-ID: <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>

On Tue, 16 Apr 2019 10:33:45 -0700, Dan Smith <dms at danplanet.com> wrote:
>> When you think of "consumer type" do you imagine it as an enumeration
>> with members similar to "instance", "instance-migration",
>> "reservation" where those types are the same in all placement
>> deployments, including those which are being used by multiple clouds
>> (or multiple novas).
> 
> I guess it seems more like it needs to be (loosely) an enum within a
> given shard. Like "I'm nova, my shard is $UUID and within that shard, my
> consumer types are instance, migration, etc". Might also be "I'm ironic,
> my shard is $UUID and within that shard, my consumer types are
> nova-instance, standalone-use, etc".
> 
> I don't really want to codify the enum in placement, as I think it's
> just a key that the consuming service uses to correlate the "reason" for
> each allocation. Some (like nova) could be a static small enum, but for
> others it could need to be dynamic and scale per tenant or something
> like that.
> 
>> What I'm trying to make sure about is: Is this a concept that is
>> fully distinct from resource provider partitioning/shards/whatever
>> the right word is, solely associated a consumer and the allocations
>> it has right now? If not, how so?
> 
> I'd like it to be fully distinct. If it's not, then nova basically needs
> to define consumers as "instance-$nova_distinct_deployment_uuid" instead
> of "instance", effectively using the consumer type as both a consumer
> type and a shard key.

+1 to all of this.

-melanie






From cdent+os at anticdent.org  Tue Apr 16 17:54:23 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 18:54:23 +0100 (BST)
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
Message-ID: <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>

On Tue, 9 Apr 2019, Chris Dent wrote:

> * The problem: we want to be able to request allocation candidates
>  filtered by a trait that exists on the root provider; but
>
>    * (a) the root provider may provide no resources (eventually -
>      e.g. CPU/mem in NUMA providers, shared disk); and/or
>
>        * (My brain hurts from the concept for a provider that
>          provides nothing. Perhaps it provides something we aren't
>          remembering to count?)
>
>    * (b) we are using only numbered groups and would have to guess
>      where to stuff the `required` - again probably based on
>      looking for the VCPU/mem resources, which, as above, may wind
>      up not on the root provider.

I've been trying to think about this (and related nested things) in a
general way. In part to see if I can resolve my unease with them,
but also to see if there are other angles at which we can come at the
problems. Basically look around from all angles.

In [1] Tetsuro talks about "spanning" and how we have different
spanning policies for different situations. Ed mentions "graphs"
as a better model for providers, often.

How far away are we from being able to say that all attributes could
be treated as spanning whether requests are expressed granularly or
not? It seems we are closer in some areas, less so in others, and
different depending on how we ask. If we made it true by default, in
all contexts, would it help?

For example, if we said that "traits always flow down [4]" (the
phrase that entered my brain and got me to start this email, "down"
in this case is "in the direction of children") then some traits
could be on the compute node, but expressed in a numbered request
group if that happened to be more convenient.

This mental model works well for me, because nested often represents
a _containing_ hierarchy [2].

If the "compute RP has no resources to give [...] but it's still the thing
exposing traits we want to filter by" [3], if we make it so the children
inherit those traits (because they have flowed down and the children
are "inside" the thing) things feel a bit saner to me. Would be good
if Eric were able to express in more detail why inherit feels
"terrible" [3]. It could very well be.

Similarly, aggregate membership would flow down as well, because a
child is always in its parent's aggregate too because it is inside its
parent.

A numeric requiredN or member_ofN span would be capped by the resource
provider that satisfied resourcesN.

As I'm writing this I'm feeling a big sense of "isn't this the
obvious way?" and "what am I missing?" and "somewhere there is a DAG
lover laughing".

So:

* Where is it like this?
* Where is it not like this?
* What now?

We need to work out a consistent and relatively easy to explain
mental model for this, because we need to be able to talk about it
with other people without them being required to re-experience all
the mental hurdles we are having to overcome.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004909.html

[2] Where this might break down is with interactions with neutron if
we're trying to get switches into the mix. However, if the port is
considered effectively a part of the node, not really an issue. I
think this is okay. A shared provider is one that we care about but
is not "inside". Nested means nested.

[3] https://review.openstack.org/#/c/645316/1/nova/compute/api.py at 1098

[4] A corollary could be "classes of inventory always flow up": If
you need a SRIOV_NET_VF, this root resource provider can provide it
because it has a great grandchild which has it.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From jaypipes at gmail.com  Tue Apr 16 18:12:29 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Tue, 16 Apr 2019 14:12:29 -0400
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
Message-ID: <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>

On 04/16/2019 01:38 PM, melanie witt wrote:
> On Tue, 16 Apr 2019 10:33:45 -0700, Dan Smith <dms at danplanet.com> wrote:
>>> When you think of "consumer type" do you imagine it as an enumeration
>>> with members similar to "instance", "instance-migration",
>>> "reservation" where those types are the same in all placement
>>> deployments, including those which are being used by multiple clouds
>>> (or multiple novas).
>>
>> I guess it seems more like it needs to be (loosely) an enum within a
>> given shard. Like "I'm nova, my shard is $UUID and within that shard, my
>> consumer types are instance, migration, etc". Might also be "I'm ironic,
>> my shard is $UUID and within that shard, my consumer types are
>> nova-instance, standalone-use, etc".
>>
>> I don't really want to codify the enum in placement, as I think it's
>> just a key that the consuming service uses to correlate the "reason" for
>> each allocation. Some (like nova) could be a static small enum, but for
>> others it could need to be dynamic and scale per tenant or something
>> like that.
>>
>>> What I'm trying to make sure about is: Is this a concept that is
>>> fully distinct from resource provider partitioning/shards/whatever
>>> the right word is, solely associated a consumer and the allocations
>>> it has right now? If not, how so?
>>
>> I'd like it to be fully distinct. If it's not, then nova basically needs
>> to define consumers as "instance-$nova_distinct_deployment_uuid" instead
>> of "instance", effectively using the consumer type as both a consumer
>> type and a shard key.
> 
> +1 to all of this.
> 
> -melanie

Yeah, +1 from me as well. Great point about the migrations being 
separate consumer type than instance.

Best,
-jay


From cdent+os at anticdent.org  Tue Apr 16 19:12:36 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 20:12:36 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
Message-ID: <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Jay Pipes wrote:
> On 04/16/2019 01:38 PM, melanie witt wrote:
>> On Tue, 16 Apr 2019 10:33:45 -0700, Dan Smith <dms at danplanet.com> wrote:
>>> I guess it seems more like it needs to be (loosely) an enum within a
>>> given shard. Like "I'm nova, my shard is $UUID and within that shard, my
>>> consumer types are instance, migration, etc". Might also be "I'm ironic,
>>> my shard is $UUID and within that shard, my consumer types are
>>> nova-instance, standalone-use, etc".
>>> 
>>> I don't really want to codify the enum in placement, as I think it's
>>> just a key that the consuming service uses to correlate the "reason" for
>>> each allocation. Some (like nova) could be a static small enum, but for
>>> others it could need to be dynamic and scale per tenant or something
>>> like that.

[snip]

>> +1 to all of this.

> Yeah, +1 from me as well. Great point about the migrations being separate 
> consumer type than instance.

For reference, there's also some discussion in IRC [1] with me, Dan,
Jay.

The summary, if I'm understanding correctly, is something like this:

The thing we want is a "consumer type", it is used to distinguish
one type of a consumer (and thus group of allocations representing a
"workload") from another. For example "these allocations are for an
instance", "these are for a migration".

Different services will need to be in charge of the distinctions
they want to make. We can't predict all those services and distinctions,
therefore placement should not be authoritative on types, each
service is.

In any given deployment, collaborating services (like nova, neutron,
ironic, cinder) would need to agree on how they are not overlapping.
That's out of scope for the placement side of things, but not
irrelevant generally.

>From an implementation standpoint, if/when we do this that makes
consumer type a string associated with a consumer. To get overly
detailed for this level of discussion: Since there will be a lot of
duplication we should probably normalize it out to its own table.

When a /usages query is made, the consumer type could be optionally
expressed, limiting results. Are multiple types something that needs
to be expressed in one query? Not yet discussed.

There's been no discussion yet about how the consumer type would be
expressed when an allocation is written. Nor whether it will be
required and what happens with existing consumers that don't have
it.

And most importantly, no volunteers for the work. Interested?

Ideally, if we want to do this in Train, we'd have someone owning this
before the PTG.

Thanks.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-04-16.log.html#t2019-04-16T17:58:38k

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From mthode at mthode.org  Tue Apr 16 19:20:45 2019
From: mthode at mthode.org (Matthew Thode)
Date: Tue, 16 Apr 2019 14:20:45 -0500
Subject: [gentoo] Looking for members to help maintain OpenStack packages on
 Gentoo
Message-ID: <20190416192045.bawpzlaoczkubl7c@mthode.org>

I'm considering disbanding the Gentoo OpenStack  project and switching
to sole maintainership of the project.  So far I'm the only active
maintianer in the project that I can see.

I'm looking for others that are interested in helping maintain the
openstack ebuilds.  It's fairly easy as an ongoing thing with two major
releases a year (which starts an update of 160 or so packages).  It's
python based and I've found maintaining the ebuilds to be very easy
individually if that helps.

There are other actions that'd be helpful as well.  Some arm64 stage
work (catalyst builds these) to then do some arm64 diskimage-builder
work to work on building VM images for other arches
(openstack or 'vanilla').

Please respond if you are intrested in joining.  I've also emailed the
Gentoo developer list separately with the same request.

Thanks,

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/913d58c0/attachment.sig>

From openstack at fried.cc  Tue Apr 16 19:24:45 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 16 Apr 2019 14:24:45 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>
Message-ID: <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>

> I'm not sure I understand your proposal. Would you introduce a VM 
> resource and then allocate 1 of that resource for each VM?

This has been proposed before, somewhere: translating
max_instances_per_host to an inventory of resource class "VM" on the
compute node RP, and including resources:VM=1 in every GET /a_c request.

This would solve the class of use cases like:

>>  So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA 

but wouldn't help us for:

> So what we need to solve is. Two (or more) sets of resources where the 
> different sets requires different, contradicting traits, in a setup 
> where the trait is not on the RP where resource inventory is.
> 
> compute RP
> |
> |
> |____ OVS agent RP
> |      |     * CUSTOM_VNIC_TYPE_NORMAL
> |      |
> |      |___________ br-int dev RP
> |                       * CUSTOM_PHYSNET_PHYSNET0
> |                       * NET_BW_EGR_KILOBIT_PER_SEC: 1000
> |
> |
> |____ SRIOV agent RP
> |      |     * CUSTOM_VNIC_TYPE_DIRECT
> |      |
> |      |
> |      |___________ esn1 dev RP
> |      |                * CUSTOM_PHYSNET_PHYSNET0
> |      |                * NET_BW_EGR_KILOBIT_PER_SEC: 10000
> |      |
> |      |___________ esn2 dev RP
> |                       * CUSTOM_PHYSNET_PHYSNET1
> |                       * NET_BW_EGR_KILOBIT_PER_SEC: 20000
> 
> 
> Then having two neutron ports in a server create request:
> * port-normal:
>     "resource_request": {
>     "resources": {
>             orc.NET_BW_EGR_KILOBIT_PER_SEC: 1000},
>     "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_NORMAL"]
> 
> * port-direct:
>     "resource_request": {
>     "resources": {
>             orc.NET_BW_EGR_KILOBIT_PER_SEC: 2000},
>     "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_DIRECT"]

...unless we contrive some inventory unit to put on the agent RPs. What
would that be? VNIC? How would we know how many to create?

Interestingly, the above is closely approaching the space we're
exploring for "subtree affinity". I'm wondering if there's a Unified
Solution...

> For example, if we said that "traits always flow down [4]" (the
> phrase that entered my brain and got me to start this email, "down"
> in this case is "in the direction of children") then some traits
> could be on the compute node, but expressed in a numbered request
> group if that happened to be more convenient.
> 
> This mental model works well for me, because nested often represents
> a _containing_ hierarchy [2].
> 
> If the "compute RP has no resources to give [...] but it's still the thing
> exposing traits we want to filter by" [3], if we make it so the children
> inherit those traits (because they have flowed down and the children
> are "inside" the thing) things feel a bit saner to me. Would be good
> if Eric were able to express in more detail why inherit feels
> "terrible" [3]. It could very well be.

I also said "feels". I can't really explain it any better than I could
explain why "using group numbers as values" gave me the ooks. And given
we're coming up ugly with all other proposals, convince me that this one
is practical and not fraught with peril and I'll quickly get over my
discomfort. Right now I'm pretty close to that point because it
elegantly solves both classes of problem described above, and I can't
think of a way to break it that isn't ridiculously contrived.

It's possible we punted on it before because a) we didn't have the
concrete use cases we have now; and b) it was going to be pretty tricky
to implement. More on that below.

> Similarly, aggregate membership would flow down as well, because a
> child is always in its parent's aggregate too because it is inside its
> parent.

This one I'm not so convinced about. Can we defer making changes here
until we have similarly concrete use cases?

> A numeric requiredN or member_ofN span would be capped by the resource
> provider that satisfied resourcesN.

Eh? I was following you up to this point. Do you just mean that we don't
have to worry about ascending the tree looking for requiredN because the
trait is implicitly on the provider with resourceN by virtue of being on
its ancestor?

> We need to work out a consistent and relatively easy to explain
> mental model for this, because we need to be able to talk about it
> with other people without them being required to re-experience all
> the mental hurdles we are having to overcome.

I think the hurdles are more around "why" and "are you sure you want to"
- once we've made those decisions, IMO it can be understood fairly
easily with one or both of "encapsulation" and "traits flow down" as
you've explained them.

> [4] A corollary could be "classes of inventory always flow up": If
> you need a SRIOV_NET_VF, this root resource provider can provide it
> because it has a great grandchild which has it.

This one bakes my noodle pretty good. I have a harder time visualizing
how the above use cases are satisfied by walking backwards up the tree
accumulating resources (and you have to accumulate the traits as well,
right?) until I hit a point where I've gathered everything I need.

So I'll come down in favor of making "traits flow down" happen. Question
is, how? (And I know we've talked about this before - maybe Queens+Denver?)

(A) In the database.
  (i) Any time a trait is added to a provider, we create records for
same trait for all descendants.
  (ii) Need a data migration to bring existing data into conformance with ^
  (iii) When a trait is deleted from a provider, I assume we need to
recursively delete it from all descendants. If you didn't want that,
you'd have to go back and re-add it to the descendants you wanted it on.

Pros: Easy to do. We don't have to change any of the APIs' algorithms -
they just work the way we want them to by virtue of the trait data being
where we want it. Reporting (e.g. GET /rps and therefore CLI output)
reflects "reality".
Cons: Irreversible. Not backward compatible. Can't do it in a microversion.

(B) In the algorithms.
  (i) GET /rps and GET /a_cs queries need JOINs I can't even begin to
comprehend.
  (ii) Do we tweak the outputs (GET /rps response and GET /a_cs
provider_summaries) to report the "inherited" traits as well?

Pros: Can do it in a microversion.
Cons: See "can't even begin to comprehend". Maybe I'm a dunce.

Perhaps this suggests a hybrid approach:

(C) Create a "ghost" table of inherited resource provider traits. If
$old_microversion we ignore it; if $new_microversion we logically
combine it with the existing rp traits table in all our queries.

Thoughts?

efried
.


From dms at danplanet.com  Tue Apr 16 19:26:37 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 12:26:37 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com> (Chris
 Dent's message of "Tue, 16 Apr 2019 20:12:36 +0100 (BST)")
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
 <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
Message-ID: <m2h8axzr82.fsf@caffeine.hv.danplanet.com>

> When a /usages query is made, the consumer type could be optionally
> expressed, limiting results. Are multiple types something that needs
> to be expressed in one query? Not yet discussed.

I expect that Nova's quota stuff will want to be able to express
multiples, FWIW. However, I think I can say for sure that the usage
result will be the most useful for quota behavior if it returns usages
grouped by type (whether or not a subset of types were in a filter
query).

--Dan


From cdent+os at anticdent.org  Tue Apr 16 19:29:14 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 20:29:14 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
Message-ID: <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Dan Smith wrote:

> I don't think there's anyone beating down the door needing this right
> now, but it's one of those things that will take a little time to filter
> in (since we have to shard-ify the existing data) and we can hardly even
> propose the conversation until it's at least planned. Most of the other
> services are going through a more painful "okay we need to shard our
> data" phase right now, so the longer we wait to do this, the harder it
> will be (and the more latency involved when we do). Easy for me to say,
> I know.

In a sense we're already sharded now, it's just that everyone is in
the same default null shard.

So, for the sake of making it explicit, what's wrong with:

* add a nullable shard column
* enable the openstack-shard header I suggested at the last ptg [1]
* let deployments start using that, but only if they want to. If
   they do all rp writes and queries use it.

There are probably plenty of things wrong with it, but if we write
it out then we can come up with the right solution fairly quickly.

[1] around line 259 in https://etherpad.openstack.org/p/nova-ptg-stein


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From openstack at nemebean.com  Tue Apr 16 19:34:55 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Tue, 16 Apr 2019 14:34:55 -0500
Subject: Does anyone care about reviewstats?
In-Reply-To: <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
Message-ID: <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>



On 3/12/19 10:01 AM, Ben Nemec wrote:
> 
> 
> On 3/12/19 8:54 AM, Matt Riedemann wrote:
>> There are open reviewstats changes [1] but the non-infra core team is 
>> entirely made up of people that no longer work on openstack [2]. I had 
>> a change that was open so long some of the projects are now owned by 
>> placement [3] so I just abandoned it.
>>
>> So the question is, does anyone use reviewstats anymore? If so, we 
>> should probably just start adding new people to the core team that 
>> actually use it. Otherwise we should probably just put it in the attic 
>> and rely on stackalytics (which is probably what most people are 
>> already doing).
> 
> I am still using it. I have a local change that pulls the project list 
> from governance instead of the manually curated lists in reviewstats 
> which reduces the maintenance burden somewhat. I'm not sure if it works 
> for all projects though. I mostly use it for the Oslo stats these days 
> and my all projects page hasn't been updated in almost two years. I 
> suspect that's because of errors when it tries to process everything, 
> but I haven't really dug into it.
> 
> So I'm happy to push up my changes, but they may cause other people 
> issues. Of course, given how out of date I suspect the project lists in 
> reviewstats are I'm not sure how much worse I could make it. I doubt the 
> numbers it spits out right now are terribly accurate anyway.

The stackalytics thread prompted me to clean this up and push it to 
gerrit: https://review.openstack.org/#/c/653024

It should help a lot with maintainability of the project lists, although 
I haven't investigated how many mismatches there are between the json 
files and governance. Probably a lot.

> 
>>
>> [1] 
>> https://review.openstack.org/#/q/project:openstack-infra/reviewstats+status:open 
>>
>> [2] https://review.openstack.org/#/admin/groups/893,members
>> [3] https://review.openstack.org/#/c/499197/
>>
> 


From dms at danplanet.com  Tue Apr 16 19:43:35 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 12:43:35 -0700
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com> (Chris
 Dent's message of "Tue, 16 Apr 2019 20:29:14 +0100 (BST)")
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com>
Message-ID: <m2d0llzqfs.fsf@caffeine.hv.danplanet.com>

>> I don't think there's anyone beating down the door needing this right
>> now, but it's one of those things that will take a little time to filter
>> in (since we have to shard-ify the existing data) and we can hardly even
>> propose the conversation until it's at least planned. Most of the other
>> services are going through a more painful "okay we need to shard our
>> data" phase right now, so the longer we wait to do this, the harder it
>> will be (and the more latency involved when we do). Easy for me to say,
>> I know.
>
> In a sense we're already sharded now, it's just that everyone is in
> the same default null shard.

Yep.

> So, for the sake of making it explicit, what's wrong with:
>
> * add a nullable shard column
> * enable the openstack-shard header I suggested at the last ptg [1]
> * let deployments start using that, but only if they want to. If
>   they do all rp writes and queries use it.

This sounds like a trap, so I'm curious... What, um, is left in such a
feature beyond this? :)

When we discussed this some number of Denvers ago, I think I said that I
would want everything to declare a shard identifier all the time, and
you (and I think Jay) wanted a "null is the default shard" type
behavior. So, what you say above seems to map to the latter, no?

I'm not crazy opposed to everyone being in the undeclared null shard
until they need to be in something else. I don't prefer it because:

 - I think it will be better tested (and test-able) if it's not optional
 - It's an identifier, and we'd never say "we don't need a non-null row
   id column until later when we need it"
 - I think that other services that may start reporting to or using
   placement may just omit that part in early development

However, whether the null default thing is transitional or lives
forever, doing what you said above is better than doing nothing, IMHO.

--Dan


From cdent+os at anticdent.org  Tue Apr 16 20:23:24 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 21:23:24 +0100 (BST)
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>
 <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>
Message-ID: <alpine.OSX.2.21.1904162034240.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Eric Fried wrote:

> Interestingly, the above is closely approaching the space we're
> exploring for "subtree affinity". I'm wondering if there's a Unified
> Solution...

Some kind of unified solution is what I'm trying to find too, mostly
by noodling.

> I also said "feels". I can't really explain it any better than I could
> explain why "using group numbers as values" gave me the ooks. And given
> we're coming up ugly with all other proposals, convince me that this one
> is practical and not fraught with peril and I'll quickly get over my
> discomfort. Right now I'm pretty close to that point because it
> elegantly solves both classes of problem described above, and I can't
> think of a way to break it that isn't ridiculously contrived.

My message isn't a proposal, it's a question to see if there is a
proposal in there somewhere.

>> Similarly, aggregate membership would flow down as well, because a
>> child is always in its parent's aggregate too because it is inside its
>> parent.
>
> This one I'm not so convinced about. Can we defer making changes here
> until we have similarly concrete use cases?

I mentioned it because Tetsuro is suggesting that we likely do or
will have use cases, in thread

   http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4787

and if traits flow down and aggregate membership does not, then we
don't have a grand unified theory and a big point of my message is
gone.

>> A numeric requiredN or member_ofN span would be capped by the resource
>> provider that satisfied resourcesN.
>
> Eh? I was following you up to this point. Do you just mean that we don't
> have to worry about ascending the tree looking for requiredN because the
> trait is implicitly on the provider with resourceN by virtue of being on
> its ancestor?

No, I think I just got lost trying to explain myself and thinking
about making sure that distinct number groups still manage to stay
distinct. So let's go with "ignore that paragraph".

>> We need to work out a consistent and relatively easy to explain
>> mental model for this, because we need to be able to talk about it
>> with other people without them being required to re-experience all
>> the mental hurdles we are having to overcome.
>
> I think the hurdles are more around "why" and "are you sure you want to"
> - once we've made those decisions, IMO it can be understood fairly
> easily with one or both of "encapsulation" and "traits flow down" as
> you've explained them.

I think perhaps you've been in this too long to recognize how mind
boggling some of the concepts (and the inconsistencies thereof) can
be. If we are able to come up with not just a unified solution, but
a unified theory that supports that solution, it's a huge win for
those that follow us.

>> [4] A corollary could be "classes of inventory always flow up": If
>> you need a SRIOV_NET_VF, this root resource provider can provide it
>> because it has a great grandchild which has it.
>
> This one bakes my noodle pretty good. I have a harder time visualizing
> how the above use cases are satisfied by walking backwards up the tree
> accumulating resources (and you have to accumulate the traits as well,
> right?) until I hit a point where I've gathered everything I need.

Classes flowing up is already true for unnumbered resources. If you
don't specify which group you want it from, any child can provide
it. That's what I was describing. The associated question would be
if a numbered resources should do the same, which presumably it
should not because that would pretty much violate the point of
numbered, wouldn't it? Which begs the question: Why/How are traits
and maybe aggregates different? I think the answer is the
containership.

> So I'll come down in favor of making "traits flow down" happen. Question
> is, how? (And I know we've talked about this before - maybe Queens+Denver?)
>
> (A) In the database.

This feels like it misrepresents the reality and the relationships
and the concept of _nested_. But the way the data is represented in
the DB doesn't have to directly map to the meaning, so it might be a
goer. A worthwhile member of the list of alternatives.

> (B) In the algorithms.
>  (i) GET /rps and GET /a_cs queries need JOINs I can't even begin to
> comprehend.

If we wanted to we could figure this out (or do a D as another way
round). I think if we're going to commit to use a SQL db as the
datastore, we can do quite a bit of work to improve our SQL,
probably by writing some SQL, directly, in a manual test environment
to find out the right queries (or just get a dump out of Jay's
brain). Doing recursive or graph queries in tables is a thing people
do, it can be looked up on stackoverflow, etc.

That is, I think this is a surmountable problem and the organic
approach we've had up to now may make it look harder than it might
be.

Of course I could be completely wrong about that. I haven't tried
it yet, and I don't expect to have any chance before mid May.

>  (ii) Do we tweak the outputs (GET /rps response and GET /a_cs
> provider_summaries) to report the "inherited" traits as well?

That seems wrong to me. a) we don't list anything but uuid, name and
generation on /rps, b) in /a_cs the meaningful thing is the groups
of providers. That inheritance satisfied a trait isn't meaningful,
it's that something in the group did, isn't it? Plus, we don't want
to misrepresent the reality of traits back to, for example, the
weighers in nova-scheduler.

> Perhaps this suggests a hybrid approach:
>
> (C) Create a "ghost" table of inherited resource provider traits. If
> $old_microversion we ignore it; if $new_microversion we logically
> combine it with the existing rp traits table in all our queries.

This sounds a lot like a 'view', in which case if a view is
possible, then B is possible. Also, a ghost table sounds a whole lot
like a cache and makes me scared (as a ghost should I suppose) and:

     https://twitter.com/jaypipes/status/1113457517538021376

(D) Switch to a graph db. I think this is an important avenue of
exploration for greenfield deployments but pretty much no good for
existing deployments given the historical shyness about
compatibility, migrations, etc. (as well as fatigue that people seem
to have from being compelled to do a migration to get existing
placement).  However, the exploration could very well reveal some
techniques that are transferable.

Thanks for making a list of suggestions. Having ideas to compare is
awesome. I think the immediate next step is continue sharing and
comparing.


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From melwittt at gmail.com  Tue Apr 16 20:23:26 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 13:23:26 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <m2h8axzr82.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
 <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
 <m2h8axzr82.fsf@caffeine.hv.danplanet.com>
Message-ID: <4d35cab2-62de-2753-e785-e65b57516ff9@gmail.com>

On Tue, 16 Apr 2019 12:26:37 -0700, Dan Smith <dms at danplanet.com> wrote:
>> When a /usages query is made, the consumer type could be optionally
>> expressed, limiting results. Are multiple types something that needs
>> to be expressed in one query? Not yet discussed.
> 
> I expect that Nova's quota stuff will want to be able to express
> multiples, FWIW. However, I think I can say for sure that the usage
> result will be the most useful for quota behavior if it returns usages
> grouped by type (whether or not a subset of types were in a filter
> query).

Yes, would be helpful to be able to get multiple consumer types in a 
single query. I agree that we would need to be able to sort through the 
different consumer types on the response side. For example, we'll want 
to be able to count quota usage as max('instance' usage, 'migration' 
usage) during a resize. And if a multiple consumer types filtered query 
returned a roll-up of all usages without grouping by consumer type, we 
would not be able to do the max thing we want to do without multiple 
separate queries to placement. Note that this reminds me that today we 
have to do two separate queries to placement, one filtered by project_id 
and one filtered by project_id and user_id in order to roll-up usage for 
a project and usage for a project user, for similar reasons.

-melanie






From cdent+os at anticdent.org  Tue Apr 16 20:27:08 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 21:27:08 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <m2h8axzr82.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
 <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
 <m2h8axzr82.fsf@caffeine.hv.danplanet.com>
Message-ID: <alpine.OSX.2.21.1904162123530.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Dan Smith wrote:

>> When a /usages query is made, the consumer type could be optionally
>> expressed, limiting results. Are multiple types something that needs
>> to be expressed in one query? Not yet discussed.
>
> I expect that Nova's quota stuff will want to be able to express
> multiples, FWIW. However, I think I can say for sure that the usage
> result will be the most useful for quota behavior if it returns usages
> grouped by type (whether or not a subset of types were in a filter
> query).

I find myself far more excited by modifying the query parameters
than modifying the response structure. But if it makes life a bunch 
easier then I guess my excitement is not the important bit.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From snikitin at mirantis.com  Tue Apr 16 20:33:37 2019
From: snikitin at mirantis.com (Sergey Nikitin)
Date: Wed, 17 Apr 2019 00:33:37 +0400
Subject: [stackalytics] Reported numbers seem inaccurate
Message-ID: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>

Hello everyone,
As you mentioned there are some inaccuracies in stats on stackalytics.com.
It happened because of outdated Prod env. At this moment we are in a
process of migration to the new env. All data on this env is fresh and
accurate. So the problem will be solved soon.

-- 
Best Regards,
Sergey Nikitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/53bc35c7/attachment.html>

From cdent+os at anticdent.org  Tue Apr 16 20:34:42 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Tue, 16 Apr 2019 21:34:42 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <m2d0llzqfs.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com>
 <m2d0llzqfs.fsf@caffeine.hv.danplanet.com>
Message-ID: <alpine.OSX.2.21.1904162127500.4039@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Dan Smith wrote:

>> So, for the sake of making it explicit, what's wrong with:
>>
>> * add a nullable shard column
>> * enable the openstack-shard header I suggested at the last ptg [1]
>> * let deployments start using that, but only if they want to. If
>>   they do all rp writes and queries use it.
>
> This sounds like a trap, so I'm curious... What, um, is left in such a
> feature beyond this? :)

Sorry, no trap intended. I had recalled that you had a preference to
not null and I couldn't remember the reasons.

[snip]

> I'm not crazy opposed to everyone being in the undeclared null shard
> until they need to be in something else. I don't prefer it because:
>
> - I think it will be better tested (and test-able) if it's not optional
> - It's an identifier, and we'd never say "we don't need a non-null row
>   id column until later when we need it"
> - I think that other services that may start reporting to or using
>   placement may just omit that part in early development

For completeness, your preference would be something more like the
way we do incomplete project and user for allocations that pre-dated
consumers? Make an explicit default (and configurable) shard uuid
and migrate to that?

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dms at danplanet.com  Tue Apr 16 20:39:54 2019
From: dms at danplanet.com (Dan Smith)
Date: Tue, 16 Apr 2019 13:39:54 -0700
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <alpine.OSX.2.21.1904162127500.4039@cdent-a01.vmware.com> (Chris
 Dent's message of "Tue, 16 Apr 2019 21:34:42 +0100 (BST)")
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com>
 <m2d0llzqfs.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162127500.4039@cdent-a01.vmware.com>
Message-ID: <m25zrdzntx.fsf@caffeine.hv.danplanet.com>

> For completeness, your preference would be something more like the
> way we do incomplete project and user for allocations that pre-dated
> consumers? Make an explicit default (and configurable) shard uuid
> and migrate to that?

Yup.

--Dan


From mihalis68 at gmail.com  Tue Apr 16 20:45:07 2019
From: mihalis68 at gmail.com (Chris Morgan)
Date: Tue, 16 Apr 2019 16:45:07 -0400
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3, 2019-9-4 NYC
Message-ID: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>

Hello All,
  My employer Bloomberg LP would like to offer to host the next OpenStack
Ops meetup here in NYC in early September this year. Please see

https://etherpad.openstack.org/p/ops-meetup-2nd-2019

for some early details on this.

All hosting offers are subject to scrutiny by the ops meetups team and the
overal community for content, location, timing etc and then approved via a
mix of consensus gathering and (if there are multiple offers) voting, see
https://wiki.openstack.org/wiki/Ops_Meetups_Team and
https://wiki.openstack.org/wiki/Operations/Meetups

Thanks,

Chris
-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/b52befb5/attachment.html>

From amy at demarco.com  Tue Apr 16 20:52:48 2019
From: amy at demarco.com (Amy Marrich)
Date: Tue, 16 Apr 2019 22:52:48 +0200
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3,
 2019-9-4 NYC
In-Reply-To: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
Message-ID: <76AB0248-2FB7-4240-BABB-48AC2C8CAB93@demarco.com>

Chris,

Just wanted to thank you and Bloomberg for extending this offer to the community!

Amy (spotz)

Sent from my iPad

> On Apr 16, 2019, at 10:45 PM, Chris Morgan <mihalis68 at gmail.com> wrote:
> 
> Hello All,
>   My employer Bloomberg LP would like to offer to host the next OpenStack Ops meetup here in NYC in early September this year. Please see 
> 
> https://etherpad.openstack.org/p/ops-meetup-2nd-2019 
> 
> for some early details on this.
> 
> All hosting offers are subject to scrutiny by the ops meetups team and the overal community for content, location, timing etc and then approved via a mix of consensus gathering and (if there are multiple offers) voting, see https://wiki.openstack.org/wiki/Ops_Meetups_Team and https://wiki.openstack.org/wiki/Operations/Meetups
> 
> Thanks,
> 
> Chris
> -- 
> Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/3decfca9/attachment.html>

From melwittt at gmail.com  Tue Apr 16 21:03:24 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 14:03:24 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
Message-ID: <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>

On Tue, 16 Apr 2019 09:13:47 -0700, Dan Smith <dms at danplanet.com> wrote:
>> Obviously, all consumers are currently Nova instances in placement
>> since (AFAIK) no other services have begun using placement to store
>> allocations.
> 
> This is not the case, actually. In Nova, we can have consumers that are
> instances, as well as consumers that are migrations (related to
> instances, but distinct). In order to be able to distinguish between the
> two, a partitioning key (I'd prefer we call this consumer type too) is
> needed. The quota work needs this specifically, so that we can know the
> usage by instances separately from usage that is reserved or pinned by
> an ongoing migration.
> 
>>> How urgent is this? Is there anyone available to do the work this
>>> cycle? How damaging is it to punt to U? What details are missing in
>>> the above description?
> 
> I guess we defer this question to Melanie, but I think the ability to
> count most of the quota elements we want using placement instead of the
> current method hinges on the ability to distinguish these things.

The latest incarnation of the quota usage from placement work [1] has 
counting from placement as opt-in, based on a few reasons explained in 
the commit message. And the spec will be amended when/if there is 
confirmation the patches will land in this form.

Given the opt-in nature of the quota stuff ^, it could be tempting to 
punt it. But my biased opinion is that it would be nice to get working 
on it so we can make counting quota usage from placement our default 
behavior sooner than later.

Consumer types would enable us to count instances from placement, I 
believe. Current code [1] has to count instances from instance mappings 
in the API database. Consumer types would also enable us to implement 
the quota usage behavior we want during a resize, to take max('instance' 
usage, 'migration' usage).

Finally, resource provider partitioning would allow quota usage from 
placement to be correct in an environment with multiple nova deployments 
sharing a single placement deployment.

If we are able to fill in those gaps, we would be in a good position to 
make counting quota usage from placement our default behavior in nova.

-melanie

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






From Arkady.Kanevsky at dell.com  Tue Apr 16 21:21:15 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Tue, 16 Apr 2019 21:21:15 +0000
Subject: Does anyone care about reviewstats?
In-Reply-To: <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
Message-ID: <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>

I do use it

-----Original Message-----
From: Ben Nemec <openstack at nemebean.com> 
Sent: Tuesday, April 16, 2019 2:35 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: Does anyone care about reviewstats?


[EXTERNAL EMAIL] 



On 3/12/19 10:01 AM, Ben Nemec wrote:
> 
> 
> On 3/12/19 8:54 AM, Matt Riedemann wrote:
>> There are open reviewstats changes [1] but the non-infra core team is 
>> entirely made up of people that no longer work on openstack [2]. I 
>> had a change that was open so long some of the projects are now owned 
>> by placement [3] so I just abandoned it.
>>
>> So the question is, does anyone use reviewstats anymore? If so, we 
>> should probably just start adding new people to the core team that 
>> actually use it. Otherwise we should probably just put it in the 
>> attic and rely on stackalytics (which is probably what most people 
>> are already doing).
> 
> I am still using it. I have a local change that pulls the project list 
> from governance instead of the manually curated lists in reviewstats 
> which reduces the maintenance burden somewhat. I'm not sure if it 
> works for all projects though. I mostly use it for the Oslo stats 
> these days and my all projects page hasn't been updated in almost two 
> years. I suspect that's because of errors when it tries to process 
> everything, but I haven't really dug into it.
> 
> So I'm happy to push up my changes, but they may cause other people 
> issues. Of course, given how out of date I suspect the project lists 
> in reviewstats are I'm not sure how much worse I could make it. I 
> doubt the numbers it spits out right now are terribly accurate anyway.

The stackalytics thread prompted me to clean this up and push it to
gerrit: https://review.openstack.org/#/c/653024

It should help a lot with maintainability of the project lists, although I haven't investigated how many mismatches there are between the json files and governance. Probably a lot.

> 
>>
>> [1]
>> https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
>> status:open
>>
>> [2] https://review.openstack.org/#/admin/groups/893,members
>> [3] https://review.openstack.org/#/c/499197/
>>
> 


From melwittt at gmail.com  Tue Apr 16 21:22:37 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 14:22:37 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
 <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
Message-ID: <d5a3a3bf-8c3d-80ca-a376-c18068155c09@gmail.com>

On Tue, 16 Apr 2019 20:12:36 +0100 (BST), Chris Dent 
<cdent+os at anticdent.org> wrote:
> On Tue, 16 Apr 2019, Jay Pipes wrote:
>> On 04/16/2019 01:38 PM, melanie witt wrote:
>>> On Tue, 16 Apr 2019 10:33:45 -0700, Dan Smith <dms at danplanet.com> wrote:
>>>> I guess it seems more like it needs to be (loosely) an enum within a
>>>> given shard. Like "I'm nova, my shard is $UUID and within that shard, my
>>>> consumer types are instance, migration, etc". Might also be "I'm ironic,
>>>> my shard is $UUID and within that shard, my consumer types are
>>>> nova-instance, standalone-use, etc".
>>>>
>>>> I don't really want to codify the enum in placement, as I think it's
>>>> just a key that the consuming service uses to correlate the "reason" for
>>>> each allocation. Some (like nova) could be a static small enum, but for
>>>> others it could need to be dynamic and scale per tenant or something
>>>> like that.
> 
> [snip]
> 
>>> +1 to all of this.
> 
>> Yeah, +1 from me as well. Great point about the migrations being separate
>> consumer type than instance.
> 
> For reference, there's also some discussion in IRC [1] with me, Dan,
> Jay.
> 
> The summary, if I'm understanding correctly, is something like this:
> 
> The thing we want is a "consumer type", it is used to distinguish
> one type of a consumer (and thus group of allocations representing a
> "workload") from another. For example "these allocations are for an
> instance", "these are for a migration".
> 
> Different services will need to be in charge of the distinctions
> they want to make. We can't predict all those services and distinctions,
> therefore placement should not be authoritative on types, each
> service is.
> 
> In any given deployment, collaborating services (like nova, neutron,
> ironic, cinder) would need to agree on how they are not overlapping.
> That's out of scope for the placement side of things, but not
> irrelevant generally.

I must admit that this last paragraph makes the idea of codifying the 
consumer types in placement more appealing. Guess it's a trade-off on 
where the effort goes. Projects collaborating to avoid overlap vs a 
heavier process and implementation for placement to provide the consumer 
types.

-melanie





From miguel at mlavalle.com  Tue Apr 16 21:55:00 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Tue, 16 Apr 2019 16:55:00 -0500
Subject: [neutron] Cleaning in Neutron
In-Reply-To: <CA+RjkXGdFq_=E8oOA6SYyRf9uiscWtHaGY7Bcz8=S96u2zJ89Q@mail.gmail.com>
References: <ED09A138-C9C9-497F-A051-D79A7706268B@redhat.com>
 <CA+RjkXGdFq_=E8oOA6SYyRf9uiscWtHaGY7Bcz8=S96u2zJ89Q@mail.gmail.com>
Message-ID: <CAEzGLDibuOQsU3t4cKLDRj_UnCu3HA7Lxi6Xs9=__c33qUGS=A@mail.gmail.com>

Hi Mike,

Thank you for catching this. This topic was discussed during the September
PTG and it was agreed that: "The OVO sub-team has accepted to also continue
the adoption of the new engine facade (
https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch),
since both efforts work in the DB layer and entail traversing the code
looking for opportunities of adoption" [1]. Unfortunately, we lost members
of the OVO sub-team, to the point that the weekly meeting was recently
removed [2]. As a consequence, this will be my personal goal for the Train
cycle. I have restored the two patches that you pointed out and I'll
re-start the effort from there [3][4]. I am also adding this topic to the
discussion during the upcoming PTG.


[1] See section "Neutron upgrades/OVO" in
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135032.html
[2] https://review.openstack.org/#/c/645181/
[3] https://review.openstack.org/#/c/545501/
[4] https://review.openstack.org/#/c/396121/

On Tue, Apr 16, 2019 at 8:13 AM Mike Bayer <mike_mp at zzzcomputing.com> wrote:

> There are a lot of very important and large DB related changes here
> that were unfortunately abandoned by their contributors [1] [2].
> Neutron remains from a SQLAlchemy / oslo.db perspective in this very
> awkward state where it is halfway between using legacy oslo.db access
> patterns and the "newer" enginefacade, which is now four years old.
> This leads to complicated issues that are difficult to develop around
> and debug [3].
>
> I don't have a solution to this problem as I am not tasked with
> Neutron to the degree that would be necessary to complete these
> migrations on my own, however as always, I eagerly await the arrival
> of developers who can commit to seeing these refactorings through,
> where I will of course be available to help.
>
> [1] https://review.openstack.org/#/c/545501/
> [2] https://review.openstack.org/#/c/396121/
> [3]
> https://review.openstack.org/#/c/348080/57/neutron/tests/unit/extensions/test_subnet_onboard.py at 42
>
>
> On Tue, Apr 16, 2019 at 5:08 AM Slawomir Kaplonski <skaplons at redhat.com>
> wrote:
> >
> > Hi,
> >
> > I just run abandon_old_reviews.sh [1] script again for neutron,
> neutron-lib and neutron-tempest-plugin repositories.
> > So if You have Your patch abandoned but You want to continue to work on
> it, please simple restore it or if You can’t restore it by self, please
> ping me on irc (slaweq) and I will restore it for You.
> >
> > [1]
> https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
> >
> > —
> > Slawek Kaplonski
> > Senior software engineer
> > Red Hat
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/06e75a48/attachment.html>

From brenski at mirantis.com  Tue Apr 16 21:55:45 2019
From: brenski at mirantis.com (Boris Renski)
Date: Tue, 16 Apr 2019 14:55:45 -0700
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
References: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
Message-ID: <CAOHrpwGRjb_3fMONsuS-vFs98SARLcMp=G28LPKzmzB4fjV-tA@mail.gmail.com>

Folks - more specifically, we plan to roll out an update by tomorrow
mid-day PT which should fix all the numbers + add aggregate details on
Airship project contributions.

Would really appreciate the help of the community to poke around tomorrow
afternoon and see if there are still discrepancies.

Sorry about this and thank you for catching it and brining it to our
attention.

-Boris

On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin at mirantis.com>
wrote:

> Hello everyone,
> As you mentioned there are some inaccuracies in stats on stackalytics.com.
> It happened because of outdated Prod env. At this moment we are in a
> process of migration to the new env. All data on this env is fresh and
> accurate. So the problem will be solved soon.
>
> --
> Best Regards,
> Sergey Nikitin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/62af188c/attachment.html>

From openstack at fried.cc  Tue Apr 16 22:07:04 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 16 Apr 2019 17:07:04 -0500
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <alpine.OSX.2.21.1904162034240.4039@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>
 <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>
 <alpine.OSX.2.21.1904162034240.4039@cdent-a01.vmware.com>
Message-ID: <b52d3ba1-c988-326c-15ee-c43fe1fc9728@fried.cc>

>> (B) In the algorithms.
>>  (i) GET /rps and GET /a_cs queries need JOINs I can't even begin to
>> comprehend.
> 
> If we wanted to we could figure this out (or do a D as another way
> round).

Sure, for some values of "we". In relative terms, I have "high
confidence" that I could write (and maintain!) the code for (A) or (C);
but "low confidence" that I could do the same for (B) or (D).

Now, does "traits flow down" help us at all with affinity? I'm gonna
say... not really. It would make it easy for us to tag NUMA nodes with a
*specific* trait (CUSTOM_NUMA_NODE_0) and affine multiple request groups
to that *specific* NUMA node. But then we need multiple permutations of
each request, which is feels horrible (with same caveat as before about
horrible feeling).

efried
.


From giorgis at acmac.uoc.gr  Tue Apr 16 22:15:49 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Wed, 17 Apr 2019 01:15:49 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
Message-ID: <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>

 Is there a way I can further debug this?

 Setting debug to "true" didn't show a reason why VMs are spreading and 
 which filter is used every time which will make VMs spread.

 In addition I think that I 've read somewhere that placement does this 
 (stack VMs) by default but have not seen that behavior at all...

 Any ideas appreciated...

 Regards,

 G.

 P.S: Added the "scheduler" tag to catch more attention from the correct 
 people.


> All,
>
> in the past I used to stack VMs based on RAM on hosts by putting the
> following settings in my nova.conf file:
>
> ->ram_weight_multiplier=-1.0
> ->available_filters=nova.scheduler.filters.all_filters
> 
> ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
>
>
> I have now a Rocky installation and although I have set the above on
> my controller node and restarted corresponding services the result
> when spawning two VMs (one after another) is still to be distributed
> on two different hosts. Seems that the something is missing in order
> to override the default behavior.
>
> Any suggestions please?
>
> Best regards,
>
> G.


From melwittt at gmail.com  Tue Apr 16 22:37:01 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 15:37:01 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
Message-ID: <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>

On Wed, 17 Apr 2019 01:15:49 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
>   Is there a way I can further debug this?
> 
>   Setting debug to "true" didn't show a reason why VMs are spreading and
>   which filter is used every time which will make VMs spread.
> 
>   In addition I think that I 've read somewhere that placement does this
>   (stack VMs) by default but have not seen that behavior at all...
> 
>   Any ideas appreciated...
> 
>   Regards,
> 
>   G.
> 
>   P.S: Added the "scheduler" tag to catch more attention from the correct
>   people.

I had a look through the code and config options and have not yet found 
anything that could have caused the default stack behavior to have changed.

The related config options are:

* [placement]randomize_allocation_candidates which defaults to False
* [filter_scheduler]host_subset_size which defaults to 1
* [filter_scheduler]shuffle_best_same_weighed_hosts which defaults to False

If you have these set to the defaults, you should be getting stacking 
behavior. Can you double check whether those options are set (or left as 
default) properly in your scheduler configs?

-melanie

>> All,
>>
>> in the past I used to stack VMs based on RAM on hosts by putting the
>> following settings in my nova.conf file:
>>
>> ->ram_weight_multiplier=-1.0
>> ->available_filters=nova.scheduler.filters.all_filters
>>
>> ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
>>
>>
>> I have now a Rocky installation and although I have set the above on
>> my controller node and restarted corresponding services the result
>> when spawning two VMs (one after another) is still to be distributed
>> on two different hosts. Seems that the something is missing in order
>> to override the default behavior.
>>
>> Any suggestions please?
>>
>> Best regards,
>>
>> G.
> 






From mike_mp at zzzcomputing.com  Tue Apr 16 22:42:14 2019
From: mike_mp at zzzcomputing.com (Mike Bayer)
Date: Tue, 16 Apr 2019 18:42:14 -0400
Subject: [neutron] Cleaning in Neutron
In-Reply-To: <CAEzGLDibuOQsU3t4cKLDRj_UnCu3HA7Lxi6Xs9=__c33qUGS=A@mail.gmail.com>
References: <ED09A138-C9C9-497F-A051-D79A7706268B@redhat.com>
 <CA+RjkXGdFq_=E8oOA6SYyRf9uiscWtHaGY7Bcz8=S96u2zJ89Q@mail.gmail.com>
 <CAEzGLDibuOQsU3t4cKLDRj_UnCu3HA7Lxi6Xs9=__c33qUGS=A@mail.gmail.com>
Message-ID: <CA+RjkXFQRQD0ALNcdT2Q3xA6dQvH7NB_J9Yq9gDuxcG93AC-Yw@mail.gmail.com>

Wow that's amazing, it's a very large amount of work so please keep me
in the loop to help!

- mike

On Tue, Apr 16, 2019 at 6:00 PM Miguel Lavalle <miguel at mlavalle.com> wrote:
>
> Hi Mike,
>
> Thank you for catching this. This topic was discussed during the September PTG and it was agreed that: "The OVO sub-team has accepted to also continue the adoption of the new engine facade (https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch), since both efforts work in the DB layer and entail traversing the code looking for opportunities of adoption" [1]. Unfortunately, we lost members of the OVO sub-team, to the point that the weekly meeting was recently removed [2]. As a consequence, this will be my personal goal for the Train cycle. I have restored the two patches that you pointed out and I'll re-start the effort from there [3][4]. I am also adding this topic to the discussion during the upcoming PTG.
>
>
> [1] See section "Neutron upgrades/OVO" in http://lists.openstack.org/pipermail/openstack-dev/2018-September/135032.html
> [2] https://review.openstack.org/#/c/645181/
> [3] https://review.openstack.org/#/c/545501/
> [4] https://review.openstack.org/#/c/396121/
>
> On Tue, Apr 16, 2019 at 8:13 AM Mike Bayer <mike_mp at zzzcomputing.com> wrote:
>>
>> There are a lot of very important and large DB related changes here
>> that were unfortunately abandoned by their contributors [1] [2].
>> Neutron remains from a SQLAlchemy / oslo.db perspective in this very
>> awkward state where it is halfway between using legacy oslo.db access
>> patterns and the "newer" enginefacade, which is now four years old.
>> This leads to complicated issues that are difficult to develop around
>> and debug [3].
>>
>> I don't have a solution to this problem as I am not tasked with
>> Neutron to the degree that would be necessary to complete these
>> migrations on my own, however as always, I eagerly await the arrival
>> of developers who can commit to seeing these refactorings through,
>> where I will of course be available to help.
>>
>> [1] https://review.openstack.org/#/c/545501/
>> [2] https://review.openstack.org/#/c/396121/
>> [3] https://review.openstack.org/#/c/348080/57/neutron/tests/unit/extensions/test_subnet_onboard.py at 42
>>
>>
>> On Tue, Apr 16, 2019 at 5:08 AM Slawomir Kaplonski <skaplons at redhat.com> wrote:
>> >
>> > Hi,
>> >
>> > I just run abandon_old_reviews.sh [1] script again for neutron, neutron-lib and neutron-tempest-plugin repositories.
>> > So if You have Your patch abandoned but You want to continue to work on it, please simple restore it or if You can’t restore it by self, please ping me on irc (slaweq) and I will restore it for You.
>> >
>> > [1] https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
>> >
>> > —
>> > Slawek Kaplonski
>> > Senior software engineer
>> > Red Hat
>> >
>> >
>>


From colleen at gazlene.net  Tue Apr 16 22:48:13 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Tue, 16 Apr 2019 18:48:13 -0400
Subject: =?UTF-8?Q?Re:_[keystone][heat]_security=5Fcompliance_options_and_auto-cr?=
 =?UTF-8?Q?eated_users?=
In-Reply-To: <CACfB1uvuOkqNx49148axje6Y-pMnr-bZtSZsyeQbZn9L9_WboQ@mail.gmail.com>
References: <CACfB1uvuOkqNx49148axje6Y-pMnr-bZtSZsyeQbZn9L9_WboQ@mail.gmail.com>
Message-ID: <42fb9862-fc73-4b38-b00a-20d2b719cfd5@www.fastmail.com>

Hello,

On Tue, Apr 16, 2019, at 03:38, Pavlo Shchelokovskyy wrote:
> Hi all,
> 
> I am currently looking at options defined in [security_compliance] 
> section of keystone.conf [0] and trying to understand how enabling 
> those security features may affect other services.
> 
> The first thing I see is that any project that auto-creates some 
> temporary users may be affected.
> Of the top of my head I can recall only Heat and Tempest doing this.
> For Tempest situation is easier as a) tempest can use static 
> credentials instead of dynamic ones so it is possible to craft 
> appropriate users beforehand and b) those users are relatively 
> short-lived (required for limited time).
> In case of Heat though those users are used for deferred auth (like in 
> autoscaling) which for long lived stacks can happen at arbitrary time 
> in future - which is a problem.
> 
> Below is breakdown of options/features possible to set and what 
> problems that may pose for Heat and ideas on how to work those around:
> 
> - disable_user_account_days_inactive - this may pose a problem for 
> deferred auth, and it seems is not possible to override it via user 
> "options". IMO there's a need to add a new user option to Keystone to 
> ignore this setting for given user, and then use it in Heat to create 
> temporary users.
> - lockout failure options (lockout_failure_attempts, lockout_duration) 
> - can be overridden by user option, but Heat has to set it first. Also 
> the question remains how realistically such problem may arise for an 
> auto-created internal user and whether Heat should set this option at 
> all
> - password expiry options (password_expires_days, 
> unique_last_password_count, minimum_password_age) - poses a problem for 
> deferred auth, but can be overridden by user option, so Heat should 
> definitely set it IMO for users it creates
> - change_password_upon_first_use - poses problem for auto-generated 
> users, can be overridden by a user option, but Heat must set it for its 
> generated users
> - password strength enforcement (password_regex, 
> password_regex_description) - now this is an interesting one. Currently 
> Heat creates passwords for its temporary users with this function [1] 
> falling back to empty password if a resource is not generating one for 
> itself. Depending on regex_password setting in keystone, it may or may 
> not be enough to pass the password strength check.
> I've looked around and (as expected) generating a random string which 
> satisfies a pre-defined arbitrary regex is quite a non-trivial task, 
> couple of existing Python libraries that can do this note that they 
> support only a limited subset of full regex spec.
> So it seems that a most simple solution would be to add yet another 
> user option to Keystone to ignore password strength enforcement for 
> this given user, and amend Heat to set this option as well for internal 
> users it creates.
> 
> We in Heat may also think as to whether it would have any benefit to 
> also set the 'lock_password' user option for the auto-created users 
> which will prohibit such users to change their passwords via API 
> themselves.
> 
> I'd very like to hear opinion from Keystone community as most solutions 
> I named are 'add new user option to Keystone' :-)
> 
> [0] 
> https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/security_compliance.py
> [1] 
> https://opendev.org/openstack/heat/src/branch/master/heat/common/password_gen.py#L112
> 
> Cheers,
> - Pavlo
> -- 
> Dr. Pavlo Shchelokovskyy
> Principal Software Engineer
> Mirantis Inc
> www.mirantis.com

Just in case you hadn't already found it, the documentation for these features is here:

https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss

Much less obviously, we document the way to override these features per-user here:

https://docs.openstack.org/keystone/latest/admin/resource-options.html

The security compliance feature isn't really meant to be applied to service users, it's for real human users, used for the sake of compliance with PCI-DSS requirements. If your organization requires your deployment to conform to PCI-DSS restrictions, service users should most likely be exempted.

In the case of temporary users, I wasn't aware that heat does that. In this case overriding the security compliance options per-user wouldn't work if the users are being deleted and recreated. The only advice I can think of is to not use this feature if you don't really need it in your organization, or to find a way to ensure heat can re-use a known user for these use cases.

Hope this helps,

Colleen


From giorgis at acmac.uoc.gr  Tue Apr 16 22:51:48 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Wed, 17 Apr 2019 01:51:48 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
Message-ID: <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>

Hi Melanie,

thx for looking into this!

The values you are referring to have not been set in “nova.conf” neither at the controller nor at the compute hosts which as far as I understand means that they have their default values and the initial behavior was to spread VMs across hosts.

In order to change that behavior what I have changed are:
1)ram_weight_multiplier=-1.0
2)available_filters=nova.scheduler.filters.all_filters
3)enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

but the behavior remained the same without any change since when launching 2VMs the second one always go to the other host that the first is running. 
Launching more VMs has the same result.

Best,

G.

>> On Wed, 17 Apr 2019 01:15:49 +0300, Georgios Dimitrakakis <giorgis at acmac.uoc.gr> wrote:
>> Is there a way I can further debug this?
>> Setting debug to "true" didn't show a reason why VMs are spreading and
>> which filter is used every time which will make VMs spread.
>> In addition I think that I 've read somewhere that placement does this
>> (stack VMs) by default but have not seen that behavior at all...
>> Any ideas appreciated...
>> Regards,
>> G.
>> P.S: Added the "scheduler" tag to catch more attention from the correct
>> people.
> 
> I had a look through the code and config options and have not yet found anything that could have caused the default stack behavior to have changed.
> 
> The related config options are:
> 
> * [placement]randomize_allocation_candidates which defaults to False
> * [filter_scheduler]host_subset_size which defaults to 1
> * [filter_scheduler]shuffle_best_same_weighed_hosts which defaults to False
> 
> If you have these set to the defaults, you should be getting stacking behavior. Can you double check whether those options are set (or left as default) properly in your scheduler configs?
> 
> -melanie
> 
>>> All,
>>> 
>>> in the past I used to stack VMs based on RAM on hosts by putting the
>>> following settings in my nova.conf file:
>>> 
>>> ->ram_weight_multiplier=-1.0
>>> ->available_filters=nova.scheduler.filters.all_filters
>>> 
>>> ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
>>> 
>>> 
>>> I have now a Rocky installation and although I have set the above on
>>> my controller node and restarted corresponding services the result
>>> when spawning two VMs (one after another) is still to be distributed
>>> on two different hosts. Seems that the something is missing in order
>>> to override the default behavior.
>>> 
>>> Any suggestions please?
>>> 
>>> Best regards,
>>> 
>>> G.
> 
> 
> 
> 



From hongbin034 at gmail.com  Tue Apr 16 23:53:34 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Tue, 16 Apr 2019 19:53:34 -0400
Subject: [Zun] Openstack Rocky Appcontainer start error
In-Reply-To: <AM6PR06MB5879F2DBBBB098F8AC03B50ADE240@AM6PR06MB5879.eurprd06.prod.outlook.com>
References: <AM6PR06MB5879F2DBBBB098F8AC03B50ADE240@AM6PR06MB5879.eurprd06.prod.outlook.com>
Message-ID: <CAFNUc+RJxR8juaH5vz1DFfb2QgkLSiJo9pbAjDSrJMupuw840Q@mail.gmail.com>

On Tue, Apr 16, 2019 at 8:09 AM Navdeep Uniyal <navdeep.uniyal at bristol.ac.uk>
wrote:

> Dear All,
>
> I am getting following error while trying to start the ubuntu container
>
> Command: openstack appcontainer run --name containerA --net
> network=5guknet ubuntu ping 8.8.8.8
>
>
>
> Error:
>
> status_reason     | Docker internal error: 500 Server Error: Internal
> Server Error ("legacy plugin: Post http://127.0.0.1:23750/Plugin.Activate:
> dial tcp 127.0.0.1:23750: connect: connection refused").
>
>
>

You might want to check the following:

1. if kuryr-libnetwork process is healthy and listens to port 23750 (do
this in each compute node):

   $ sudo systemctl status kuryr-libnetwork
   $ sudo journalctl -u kuryr-libnetwork > kuryr.log

2. if there is anything blocking the port 23750

  $ curl -X POST http://127.0.0.1:23750/NetworkDriver.GetCapabilities

If above doesn't help, you could paste me your kuryr-libnetwork's log (sudo
journalctl -u kuryr-libnetwork > kuryr.log) and config file
(/etc/kuryr/kuryr.conf).


> Secondly, with Heat Template:
>
> heat_template_version: 2015-04-30
>
>
>
> resources:
>
>   the_resource:
>
>     type: OS::Zun::Container
>
>     properties:
>
>       cpu: 4
>
>       image: ubuntu
>
>       image_pull_policy: "ifnotpresent"
>
>       interactive: true
>
>       memory: 2048
>
>       name: "ubuntu16"
>
>       command: "ping 8.8.8.8"
>
>       networks: [{"network": 5guknet}]
>
>       restart_policy: "no"
>
>
>
> The command I can see on the appcontainer show is : command           |
> [u'p', u'i', u'n', u'g', u' ', u'8', u'.', u'8', u'.', u'8', u'.', u'8']
>
>
>

This looks like a bug. I created a ticket for this:
https://storyboard.openstack.org/#!/story/2005469


> Please advise how to resolve the two issues.
>
>
>
> Kind Regards,
>
> Navdeep
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/c7444454/attachment.html>

From melwittt at gmail.com  Wed Apr 17 00:03:57 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 17:03:57 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
Message-ID: <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>

On Wed, 17 Apr 2019 01:51:48 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
> Hi Melanie,
> 
> thx for looking into this!
> 
> The values you are referring to have not been set in “nova.conf” neither at the controller nor at the compute hosts which as far as I understand means that they have their default values and the initial behavior was to spread VMs across hosts.
> 
> In order to change that behavior what I have changed are:
> 1)ram_weight_multiplier=-1.0
> 2)available_filters=nova.scheduler.filters.all_filters
> 3)enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
> 
> but the behavior remained the same without any change since when launching 2VMs the second one always go to the other host that the first is running.
> Launching more VMs has the same result.

OK, yeah if you have not set those config options in nova.conf then they 
should be defaulting to stacking behavior.

I see and understand now that the default value 1.0 for 
[filter_scheduler]ram_weight_multiplier will spread VMs, but you have it 
correctly set to a negative value to instead stack VMs [1].

So, it seems by everything you have set up, you should be seeing 
stacking VM behavior.

To debug further, you should set debug to True in the nova.conf on your 
scheduler host and look for which filter is removing the desired host 
for the second VM. You can find where to start by looking for a message 
like, "Starting with N host(s)". If you have two hosts with enough RAM, 
you should see "Starting with 2 host(s)" and then look for the log 
message where it says "Filter returned 1 host(s)" and that will be the 
filter that is removing the desired host. Once you know which filter is 
removing it, you can debug further.

-melanie

[1] 
https://docs.openstack.org/nova/latest/user/filter-scheduler.html#weights

>>> On Wed, 17 Apr 2019 01:15:49 +0300, Georgios Dimitrakakis <giorgis at acmac.uoc.gr> wrote:
>>> Is there a way I can further debug this?
>>> Setting debug to "true" didn't show a reason why VMs are spreading and
>>> which filter is used every time which will make VMs spread.
>>> In addition I think that I 've read somewhere that placement does this
>>> (stack VMs) by default but have not seen that behavior at all...
>>> Any ideas appreciated...
>>> Regards,
>>> G.
>>> P.S: Added the "scheduler" tag to catch more attention from the correct
>>> people.
>>
>> I had a look through the code and config options and have not yet found anything that could have caused the default stack behavior to have changed.
>>
>> The related config options are:
>>
>> * [placement]randomize_allocation_candidates which defaults to False
>> * [filter_scheduler]host_subset_size which defaults to 1
>> * [filter_scheduler]shuffle_best_same_weighed_hosts which defaults to False
>>
>> If you have these set to the defaults, you should be getting stacking behavior. Can you double check whether those options are set (or left as default) properly in your scheduler configs?
>>
>> -melanie
>>
>>>> All,
>>>>
>>>> in the past I used to stack VMs based on RAM on hosts by putting the
>>>> following settings in my nova.conf file:
>>>>
>>>> ->ram_weight_multiplier=-1.0
>>>> ->available_filters=nova.scheduler.filters.all_filters
>>>>
>>>> ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
>>>>
>>>>
>>>> I have now a Rocky installation and although I have set the above on
>>>> my controller node and restarted corresponding services the result
>>>> when spawning two VMs (one after another) is still to be distributed
>>>> on two different hosts. Seems that the something is missing in order
>>>> to override the default behavior.
>>>>
>>>> Any suggestions please?
>>>>
>>>> Best regards,
>>>>
>>>> G.
>>
>>
>>
>>
> 






From mriedemos at gmail.com  Wed Apr 17 00:13:05 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 16 Apr 2019 19:13:05 -0500
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
Message-ID: <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>

On 4/16/2019 4:03 PM, melanie witt wrote:
> Consumer types would enable us to count instances from placement, I believe.

I don't see how. The GET /usages API doesn't return anything until there 
are allocations, and there aren't allocations until the scheduler picks 
a host and creates the allocations, and that might fail resulting in 
NoValidHost and a server in ERROR status but that doesn't mean there 
aren't any instances. Changing that would be a break in behavior for 
counting instances.

-- 

Thanks,

Matt


From cboylan at sapwetik.org  Wed Apr 17 00:13:06 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 16 Apr 2019 20:13:06 -0400
Subject: Migrating git repos to OpenDev
In-Reply-To: <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
Message-ID: <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>

On Thu, Apr 11, 2019, at 3:21 PM, Clark Boylan wrote:
> On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote:
> > Hi,
> > 
> > As discussed in November[1], the OpenStack project infrastructure is
> > being rebranded as "OpenDev" to better support a wider community of
> > projects.
> > 
> > We are nearly ready to perform the part of this transition with the
> > largest impact: moving the authoritative git repositories for existing
> > projects.
> > 
> > In this email, I'd like to introduce the new hosting system we are
> > preparing, discuss the transition, and invite projects to work with us
> > on the logistics of the change.
> > 
> > Gerrit
> > ======
> > 
> > Gerrit is the core of our system and it will remain so in OpenDev.  As
> > part of this move, we will rename the gerrit server from
> > review.openstack.org to review.opendev.org.  As part of the transition,
> > we will automatically merge appropriate changes to all branches of all
> > repositories updating .gitreview and Zuul configuration files.  Any
> > further changes (README files, etc.) we expect to be made by individual
> > project contributors.
> > 
> > Repository Browsing
> > ===================
> > 
> > Currently our canonical *public* repository system is the cgit server at
> > https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and
> > git.zuul-ci.org).  This is a load balanced cluster of several servers
> > which is designed to handle all the public git repository traffic, as it
> > scales much better than Gerrit (and has a more friendly domain name).
> > From a technical standpoint, it's excellent, but its usability could be
> > improved.
> > 
> > Therefore, as part of this transition, we will replace the cgit servers
> > with a new system based on Gitea.  Gitea is a complete development
> > collaboration system, but it's very flexible and will allow us to
> > disable components which we aren't using.  We will operate it in a
> > read-only configuration where it will act as the public mirror for
> > Gerrit.  The advantages it has over the current system are:
> > 
> > * Shorter domain name in project URLs:
> >   https://git.openstack.org/openstack/nova   vs
> >   https://opendev.org/openstack/nova
> > * Clone and browsing URLs are the same (with cgit, the browsing URL has
> >   an extra path component)
> > * More visually pleasing code browsing
> > * Integrated code searching
> > * Ability to highlight multiple lines in links
> > 
> > When we perform the transition we will install redirects from
> > git.openstack.org (and the other git sites) to opendev.org, and will
> > maintain those redirects for the foreseeable future.  We will construct
> > them so that even existing deep links to individual files in individual
> > commits to cgit will redirect to the correct location on opendev.org.
> > 
> > This system is up and running now with a live mirror of data from
> > Gerrit, and you can start testing it out today at https://opendev.org/
> > 
> > Please let us know if you encounter any problems.
> > 
> > If you would like to read more about the design of this system and the
> > transition, see the infra-spec[2].
> > 
> > GitHub
> > ======
> > 
> > Currently all OpenStack projects are replicated to GitHub.  We do not
> > plan on changing that during the transition, however, any projects
> > outside of the openstack*/ namespaces will not automatically be
> > replicated to GitHub, and we do not plan on adding that in the future.
> > We do, however, support projects using Zuul to run post-merge jobs to
> > push updates to GitHub or any other third-party mirrors with their own
> > credentials.  We will be happy to work with anyone interested in that to
> > help set up jobs to do so.
> > 
> > We are adopting this approach so that individual projects can have more
> > control over how they are represented in social media, and to give us
> > more flexibility in supporting our own organizational namespaces on
> > OpenDev without assuming they map directly to GitHub.
> > 
> > Eventually we plan on moving the OpenStack project to that system as
> > well and retiring direct replication from Gerrit to GitHub completely.
> > But we will defer that work until after this transition.
> > 
> > Logistics
> > =========
> > 
> > We can prepare much of the system in advance (as we have for the hosting
> > system on opendev.org), but the actual transition and renaming of the
> > Gerrit server will need to happen at once during an outage window.  We
> > need to schedule that outage and begin preparing for it.
> > 
> > Since all of the project git URLs are going to change (to replace
> > git.openstack.org with opendev.org and review.openstack.org with
> > review.opendev.org), we can additionally take the opportunity to
> > reorganize projects into different organizations.
> > 
> > For example, during the transition we will rename Zuul, and it's
> > associated projects, from the "openstack-infra" org to "zuul".  So their
> > new names will be "zuul/zuul", "zuul/nodepool", etc.
> > 
> > This is an excellent time for the rest of the OpenStack Foundation
> > pilot projects to do the same.
> > 
> > If the OpenStack project desires this, it would also be a good time to
> > move unofficial projects out of the openstack/ namespace.
> > 
> > Therefore, we need your help:
> > 
> > Action Items
> > ============
> > 
> > We need each of the following projects:
> > 
> >   * OpenStack
> >   * Airship
> >   * StarlingX
> >   * Zuul
> > 
> > To nominate a single point of contact to work with us on the transition.
> > It would be helpful for that person to attend the next (and possibly
> > next several) openstack infra team meetings in IRC [3].  We will work
> > with those people on scheduling the transition, as well as finalizing
> > the list of projects which should be renamed as part of the transition.
> > 
> > If you manage an unofficial project and would like to take the
> > opportunity to move or rename your project, please add it to this
> > ethercalc[4].
> > 
> > [1] 
> > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
> > [2] 
> > http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html
> > [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting
> > [4] https://ethercalc.openstack.org/opendev-transition
> > 
> >
> 
> We've made good progress in preparing this change and are still on 
> track to do this Friday April 19, 2019.  Our project liasons have been 
> drawing up lists of projects to rename during the outage. One big thing 
> to keep in mind is unofficial OpenStack projects will no longer be in 
> the "openstack" namespace.  They will be placed in the 'x/' namespace 
> instead which intends to indicate no endorsement or special ownership.
> 
> One side effect of this change (as noted in Jim's earlier email) is 
> that we will stop replicating projects that move out of the openstack 
> namespace. Projects that wish to be replicated to Github or anywhere 
> else they like can do so following the steps that David Moreau-Simard 
> put together for us here [5].
> 
> This transition is likely to be a bit bumpy particularly at the start. 
> We'll be around after the transition to help fix unexpected errors and 
> are likely to spend a fair bit of time at the PTG improving things as 
> well.
> 
> Finally, to be extra clear, we intend to put http redirects in place so 
> that all your old http(s) urls continue to work.  Fungi has set this up 
> for testing with details here [6] if you would like to ensure your urls 
> redirect properly.
> 
> [5] 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
> [6] 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html

The infra/OpenDev team continues to make good progress towards this transition and plans to perform the transition on April 19, 2019 as previously scheduled.  We will begin the transition at 15:00UTC and users should plan for intermittent Gerrit and git repo outages through the day. We expect most of those will be closer to 15:00UTC than 23:00UTC.

Fungi has generated a master list of project renames for the openstack namespaces: http://paste.openstack.org/show/749402/. If you have a moment please quickly review these planned renames for any obvious errors or issues.

For the airship, starlingx, and zuul repo renames the repositories listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were used placing repos in airship/, starlingx/ and zuul/ namespaces. Any repo name prefix (like stx- and airship-) is dropped.

As always we are happy to answer any questions you might have or address any concerns. Feel free to reach out.
Thank you for your patience,
Clark


From mriedemos at gmail.com  Wed Apr 17 00:18:03 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 16 Apr 2019 19:18:03 -0500
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
Message-ID: <7b11643f-b34c-8cff-c448-8a47411d0663@gmail.com>

On 4/16/2019 4:03 PM, melanie witt wrote:
> Consumer types would also enable us to implement the quota usage 
> behavior we want during a resize, to take max('instance' usage, 
> 'migration' usage).

To be clear, and you did the testing on this recently, but this is how 
quota usage worked pre-pike counting quotas in nova, correct? And that 
counting behavior was changed in Pike because we now only count the new 
flavor resources for vcpus/ram while the server is in VERIFY_RESIZE 
status, even if it was a resize down - which could prevent the user from 
reverting the resize if they would go over-quota during revert because 
we didn't track quota properly during a resize.

So "behavior we want" meaning, "get us back to pre-pike behavior" but at 
the same time no one has really complained about this slight wrinkle 
since it happened in pike (I think it dawned on me last week). Meaning, 
it's low priority, yeah?

-- 

Thanks,

Matt


From melwittt at gmail.com  Wed Apr 17 00:22:14 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 17:22:14 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
Message-ID: <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>

On Tue, 16 Apr 2019 19:13:05 -0500, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 4/16/2019 4:03 PM, melanie witt wrote:
>> Consumer types would enable us to count instances from placement, I believe.
> 
> I don't see how. The GET /usages API doesn't return anything until there
> are allocations, and there aren't allocations until the scheduler picks
> a host and creates the allocations, and that might fail resulting in
> NoValidHost and a server in ERROR status but that doesn't mean there
> aren't any instances. Changing that would be a break in behavior for
> counting instances.

True, but now that you mention it, it seems the current proposed patch 
for counting cores and ram from placement results in a similar break in 
behavior. Today, an ERROR instance that has never been scheduled will 
consume cores and ram quota usage, but would not consume any in the same 
scenario when we count cores and ram from placement because of lack of 
allocations.

-melanie






From mriedemos at gmail.com  Wed Apr 17 00:32:57 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 16 Apr 2019 19:32:57 -0500
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
 <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>
Message-ID: <76040bb2-be1f-290d-7a33-552499a7065c@gmail.com>

On 4/16/2019 7:22 PM, melanie witt wrote:
> Today, an ERROR instance that has never been scheduled will consume 
> cores and ram quota usage

Hmm, I wonder if that was also a regression in Pike with counting 
quotas. Because that usage is not real and arguably shouldn't count 
against the tenant.

-- 

Thanks,

Matt


From melwittt at gmail.com  Wed Apr 17 00:33:29 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 17:33:29 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <7b11643f-b34c-8cff-c448-8a47411d0663@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <7b11643f-b34c-8cff-c448-8a47411d0663@gmail.com>
Message-ID: <8b73ac76-9f70-dc49-ad45-2224a334cd0a@gmail.com>

On Tue, 16 Apr 2019 19:18:03 -0500, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 4/16/2019 4:03 PM, melanie witt wrote:
>> Consumer types would also enable us to implement the quota usage
>> behavior we want during a resize, to take max('instance' usage,
>> 'migration' usage).
> 
> To be clear, and you did the testing on this recently, but this is how
> quota usage worked pre-pike counting quotas in nova, correct? And that
> counting behavior was changed in Pike because we now only count the new
> flavor resources for vcpus/ram while the server is in VERIFY_RESIZE
> status, even if it was a resize down - which could prevent the user from
> reverting the resize if they would go over-quota during revert because
> we didn't track quota properly during a resize.

Yes, that is how quota usage worked pre-Pike. And yes, the counting 
behavior in Pike means that we only count the vcpus, memory_mb, and 
disk_gb attributes that are set on the instance. Since those attributes 
are updated to the new flavor on the instance at finish_resize time 
(before confirm/revert), we get only the new flavor count, regardless of 
whether it was an upsize or a downsize. To do it in a way that reserves 
room for a revert of a downsize, we would have to defer saving the 
instance attributes until after a resize confirm, only if it's a 
downsize. I'm not sure whether it's worth the complexity.

> So "behavior we want" meaning, "get us back to pre-pike behavior" but at
> the same time no one has really complained about this slight wrinkle
> since it happened in pike (I think it dawned on me last week). Meaning,
> it's low priority, yeah?

Yes, back to pre-Pike behavior is the ideal state, I think. But what I 
was saying is getting to pre-Pike behavior from the current counting 
from placement proposal is a significant improvement. The current 
counting from placement proposal necessarily results in "doubled" 
allocations for upsizes and downsizes. If we're interested in making 
counting from placement the default in the future, getting away from 
"doubled" allocations seems important.

For completeness, here are the results of the tests I did with Ocata and 
Train devstacks:

* Ocata behavior, uses max of old flavor and new flavor until 
confirmed/reverted: http://paste.openstack.org/show/749221

* Train behavior, uses new flavor until confirmed/reverted: 
http://paste.openstack.org/show/749266

* Train behavior + counting from placement, uses old flavor + new flavor 
until confirmed/reverted: http://paste.openstack.org/show/749267

-melanie






From melwittt at gmail.com  Wed Apr 17 00:46:15 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 17:46:15 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <76040bb2-be1f-290d-7a33-552499a7065c@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
 <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>
 <76040bb2-be1f-290d-7a33-552499a7065c@gmail.com>
Message-ID: <bc0ca9ee-1d23-a7d2-134d-282d0b54b861@gmail.com>

On Tue, 16 Apr 2019 19:32:57 -0500, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 4/16/2019 7:22 PM, melanie witt wrote:
>> Today, an ERROR instance that has never been scheduled will consume
>> cores and ram quota usage
> 
> Hmm, I wonder if that was also a regression in Pike with counting
> quotas. Because that usage is not real and arguably shouldn't count
> against the tenant.

I don't think so, based on hazy anecdotal experience and a look at the 
code which does a quota reservation before scheduling and doesn't appear 
to rollback quota in any failure case in conductor:

https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L313

I still have my Ocata devstack up, so I'll do a test and reply with the 
results for Ocata, Train, and Train + counting from placement.

-melanie






From syd.logan at broadcom.com  Wed Apr 17 00:51:33 2019
From: syd.logan at broadcom.com (Syd Logan)
Date: Tue, 16 Apr 2019 17:51:33 -0700
Subject: Routed networks and FIP gateway assignments
Message-ID: <CACmumLhXeLXCuGkdmEytr954t8iGnuYdOj50ThqUbkcPRrBu3g@mail.gmail.com>

I'm currently learning about routed networks and have a lab that is
implementing a 3 tier leaf spine and have a question.

I know that I can create a subnet from which FIP gateway IP addresses are
consumed, e.g.,

openstack subnet create demo-floating-ip-agent-gateway-subnet \
  --subnet-range 198.51.100.0/24 --no-dhcp \
  --service-type 'network:floatingip_agent_gateway' \
  --network demo-ext-net

In videos from past OpenStack summits such as this
https://youtu.be/XnXSwCSHc4U drawings show that the subnet is used within a
single segment's compute nodes, and I can believe that would work. What
isn't clear is whether the same subnet should be used across multiple
segments, or the intent is for each segment defined in the routed network
to have a unique subnet from which these FIP gateway IPs are assigned,
e.g., some other segment would be using, say 198.52.100.0/24.

In the non-routed network setup where I leanred about DVR it was pretty
clear only one subnet was allowed, but what is the best practice/intent for
routed nets?

Thanks.

syd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/a3bba3c9/attachment.html>

From melwittt at gmail.com  Wed Apr 17 01:20:35 2019
From: melwittt at gmail.com (melanie witt)
Date: Tue, 16 Apr 2019 18:20:35 -0700
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <bc0ca9ee-1d23-a7d2-134d-282d0b54b861@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
 <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>
 <76040bb2-be1f-290d-7a33-552499a7065c@gmail.com>
 <bc0ca9ee-1d23-a7d2-134d-282d0b54b861@gmail.com>
Message-ID: <648ae0d8-d1f0-1deb-0d58-91cda5e7747a@gmail.com>

On Tue, 16 Apr 2019 17:46:15 -0700, Melanie Witt <melwittt at gmail.com> wrote:
> On Tue, 16 Apr 2019 19:32:57 -0500, Matt Riedemann <mriedemos at gmail.com>
> wrote:
>> On 4/16/2019 7:22 PM, melanie witt wrote:
>>> Today, an ERROR instance that has never been scheduled will consume
>>> cores and ram quota usage
>>
>> Hmm, I wonder if that was also a regression in Pike with counting
>> quotas. Because that usage is not real and arguably shouldn't count
>> against the tenant.
> 
> I don't think so, based on hazy anecdotal experience and a look at the
> code which does a quota reservation before scheduling and doesn't appear
> to rollback quota in any failure case in conductor:
> 
> https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L313
> 
> I still have my Ocata devstack up, so I'll do a test and reply with the
> results for Ocata, Train, and Train + counting from placement.

Here are the results:

* Ocata behavior, unscheduled ERROR instance consumes quota usage for 
instances, cores, and ram: http://paste.openstack.org/show/749406

* Train behavior, unscheduled ERROR instance consumes quota usage for 
instances, cores, and ram: http://paste.openstack.org/show/749407

* Train behavior + counting from placement, consumes quota usage for 
instances (API database) but not for cores and ram (placement 
allocations): http://paste.openstack.org/show/749408

-melanie






From gmann at ghanshyammann.com  Wed Apr 17 02:10:18 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 16 Apr 2019 21:10:18 -0500
Subject: Migrating git repos to OpenDev
In-Reply-To: <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
Message-ID: <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>

 ---- On Tue, 16 Apr 2019 19:13:06 -0500 Clark Boylan <cboylan at sapwetik.org> wrote ----
 > On Thu, Apr 11, 2019, at 3:21 PM, Clark Boylan wrote: 
 > > On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote: 
 > > > Hi, 
 > > >  
 > > > As discussed in November[1], the OpenStack project infrastructure is 
 > > > being rebranded as "OpenDev" to better support a wider community of 
 > > > projects. 
 > > >  
 > > > We are nearly ready to perform the part of this transition with the 
 > > > largest impact: moving the authoritative git repositories for existing 
 > > > projects. 
 > > >  
 > > > In this email, I'd like to introduce the new hosting system we are 
 > > > preparing, discuss the transition, and invite projects to work with us 
 > > > on the logistics of the change. 
 > > >  
 > > > Gerrit 
 > > > ====== 
 > > >  
 > > > Gerrit is the core of our system and it will remain so in OpenDev.  As 
 > > > part of this move, we will rename the gerrit server from 
 > > > review.openstack.org to review.opendev.org.  As part of the transition, 
 > > > we will automatically merge appropriate changes to all branches of all 
 > > > repositories updating .gitreview and Zuul configuration files.  Any 
 > > > further changes (README files, etc.) we expect to be made by individual 
 > > > project contributors. 
 > > >  
 > > > Repository Browsing 
 > > > =================== 
 > > >  
 > > > Currently our canonical *public* repository system is the cgit server at 
 > > > https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and 
 > > > git.zuul-ci.org).  This is a load balanced cluster of several servers 
 > > > which is designed to handle all the public git repository traffic, as it 
 > > > scales much better than Gerrit (and has a more friendly domain name). 
 > > > From a technical standpoint, it's excellent, but its usability could be 
 > > > improved. 
 > > >  
 > > > Therefore, as part of this transition, we will replace the cgit servers 
 > > > with a new system based on Gitea.  Gitea is a complete development 
 > > > collaboration system, but it's very flexible and will allow us to 
 > > > disable components which we aren't using.  We will operate it in a 
 > > > read-only configuration where it will act as the public mirror for 
 > > > Gerrit.  The advantages it has over the current system are: 
 > > >  
 > > > * Shorter domain name in project URLs: 
 > > >   https://git.openstack.org/openstack/nova   vs 
 > > >   https://opendev.org/openstack/nova 
 > > > * Clone and browsing URLs are the same (with cgit, the browsing URL has 
 > > >   an extra path component) 
 > > > * More visually pleasing code browsing 
 > > > * Integrated code searching 
 > > > * Ability to highlight multiple lines in links 
 > > >  
 > > > When we perform the transition we will install redirects from 
 > > > git.openstack.org (and the other git sites) to opendev.org, and will 
 > > > maintain those redirects for the foreseeable future.  We will construct 
 > > > them so that even existing deep links to individual files in individual 
 > > > commits to cgit will redirect to the correct location on opendev.org. 
 > > >  
 > > > This system is up and running now with a live mirror of data from 
 > > > Gerrit, and you can start testing it out today at https://opendev.org/ 
 > > >  
 > > > Please let us know if you encounter any problems. 
 > > >  
 > > > If you would like to read more about the design of this system and the 
 > > > transition, see the infra-spec[2]. 
 > > >  
 > > > GitHub 
 > > > ====== 
 > > >  
 > > > Currently all OpenStack projects are replicated to GitHub.  We do not 
 > > > plan on changing that during the transition, however, any projects 
 > > > outside of the openstack*/ namespaces will not automatically be 
 > > > replicated to GitHub, and we do not plan on adding that in the future. 
 > > > We do, however, support projects using Zuul to run post-merge jobs to 
 > > > push updates to GitHub or any other third-party mirrors with their own 
 > > > credentials.  We will be happy to work with anyone interested in that to 
 > > > help set up jobs to do so. 
 > > >  
 > > > We are adopting this approach so that individual projects can have more 
 > > > control over how they are represented in social media, and to give us 
 > > > more flexibility in supporting our own organizational namespaces on 
 > > > OpenDev without assuming they map directly to GitHub. 
 > > >  
 > > > Eventually we plan on moving the OpenStack project to that system as 
 > > > well and retiring direct replication from Gerrit to GitHub completely. 
 > > > But we will defer that work until after this transition. 
 > > >  
 > > > Logistics 
 > > > ========= 
 > > >  
 > > > We can prepare much of the system in advance (as we have for the hosting 
 > > > system on opendev.org), but the actual transition and renaming of the 
 > > > Gerrit server will need to happen at once during an outage window.  We 
 > > > need to schedule that outage and begin preparing for it. 
 > > >  
 > > > Since all of the project git URLs are going to change (to replace 
 > > > git.openstack.org with opendev.org and review.openstack.org with 
 > > > review.opendev.org), we can additionally take the opportunity to 
 > > > reorganize projects into different organizations. 
 > > >  
 > > > For example, during the transition we will rename Zuul, and it's 
 > > > associated projects, from the "openstack-infra" org to "zuul".  So their 
 > > > new names will be "zuul/zuul", "zuul/nodepool", etc. 
 > > >  
 > > > This is an excellent time for the rest of the OpenStack Foundation 
 > > > pilot projects to do the same. 
 > > >  
 > > > If the OpenStack project desires this, it would also be a good time to 
 > > > move unofficial projects out of the openstack/ namespace. 
 > > >  
 > > > Therefore, we need your help: 
 > > >  
 > > > Action Items 
 > > > ============ 
 > > >  
 > > > We need each of the following projects: 
 > > >  
 > > >   * OpenStack 
 > > >   * Airship 
 > > >   * StarlingX 
 > > >   * Zuul 
 > > >  
 > > > To nominate a single point of contact to work with us on the transition. 
 > > > It would be helpful for that person to attend the next (and possibly 
 > > > next several) openstack infra team meetings in IRC [3].  We will work 
 > > > with those people on scheduling the transition, as well as finalizing 
 > > > the list of projects which should be renamed as part of the transition. 
 > > >  
 > > > If you manage an unofficial project and would like to take the 
 > > > opportunity to move or rename your project, please add it to this 
 > > > ethercalc[4]. 
 > > >  
 > > > [1]  
 > > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html 
 > > > [2]  
 > > > http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html 
 > > > [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting 
 > > > [4] https://ethercalc.openstack.org/opendev-transition 
 > > >  
 > > > 
 > >  
 > > We've made good progress in preparing this change and are still on  
 > > track to do this Friday April 19, 2019.  Our project liasons have been  
 > > drawing up lists of projects to rename during the outage. One big thing  
 > > to keep in mind is unofficial OpenStack projects will no longer be in  
 > > the "openstack" namespace.  They will be placed in the 'x/' namespace  
 > > instead which intends to indicate no endorsement or special ownership. 
 > >  
 > > One side effect of this change (as noted in Jim's earlier email) is  
 > > that we will stop replicating projects that move out of the openstack  
 > > namespace. Projects that wish to be replicated to Github or anywhere  
 > > else they like can do so following the steps that David Moreau-Simard  
 > > put together for us here [5]. 
 > >  
 > > This transition is likely to be a bit bumpy particularly at the start.  
 > > We'll be around after the transition to help fix unexpected errors and  
 > > are likely to spend a fair bit of time at the PTG improving things as  
 > > well. 
 > >  
 > > Finally, to be extra clear, we intend to put http redirects in place so  
 > > that all your old http(s) urls continue to work.  Fungi has set this up  
 > > for testing with details here [6] if you would like to ensure your urls  
 > > redirect properly. 
 > >  
 > > [5]  
 > > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html 
 > > [6]  
 > > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html 
 >  
 > The infra/OpenDev team continues to make good progress towards this transition and plans to perform the transition on April 19, 2019 as previously scheduled.  We will begin the transition at 15:00UTC and users should plan for intermittent Gerrit and git repo outages through the day. We expect most of those will be closer to 15:00UTC than 23:00UTC. 
 >  
 > Fungi has generated a master list of project renames for the openstack namespaces: http://paste.openstack.org/show/749402/. If you have a moment please quickly review these planned renames for any obvious errors or issues. 

Thanks Clark, Fungi for the list. With quick review, below are the two repo which I feel need a home somewhere. 

- gerrit-dash-creator - it thought it was under infra. 
- upstream-institute-virtual-environment - We use this in OUI trainings. I pinged this on #openstack-upstream-institute to find home. 

-gmann

 >  
 > For the airship, starlingx, and zuul repo renames the repositories listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were used placing repos in airship/, starlingx/ and zuul/ namespaces. Any repo name prefix (like stx- and airship-) is dropped. 
 >  
 > As always we are happy to answer any questions you might have or address any concerns. Feel free to reach out. 
 > Thank you for your patience, 
 > Clark 
 >  
 > 



From gmann at ghanshyammann.com  Wed Apr 17 02:27:07 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 16 Apr 2019 21:27:07 -0500
Subject: Migrating git repos to OpenDev
In-Reply-To: <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
Message-ID: <16a291e8818.b2a0ab2f16578.5918920171050047498@ghanshyammann.com>

 ---- On Tue, 16 Apr 2019 21:10:18 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Tue, 16 Apr 2019 19:13:06 -0500 Clark Boylan <cboylan at sapwetik.org> wrote ---- 
 >  > On Thu, Apr 11, 2019, at 3:21 PM, Clark Boylan wrote:  
 >  > > On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote:  
 >  > > > Hi,  
 >  > > >   
 >  > > > As discussed in November[1], the OpenStack project infrastructure is  
 >  > > > being rebranded as "OpenDev" to better support a wider community of  
 >  > > > projects.  
 >  > > >   
 >  > > > We are nearly ready to perform the part of this transition with the  
 >  > > > largest impact: moving the authoritative git repositories for existing  
 >  > > > projects.  
 >  > > >   
 >  > > > In this email, I'd like to introduce the new hosting system we are  
 >  > > > preparing, discuss the transition, and invite projects to work with us  
 >  > > > on the logistics of the change.  
 >  > > >   
 >  > > > Gerrit  
 >  > > > ======  
 >  > > >   
 >  > > > Gerrit is the core of our system and it will remain so in OpenDev.  As  
 >  > > > part of this move, we will rename the gerrit server from  
 >  > > > review.openstack.org to review.opendev.org.  As part of the transition,  
 >  > > > we will automatically merge appropriate changes to all branches of all  
 >  > > > repositories updating .gitreview and Zuul configuration files.  Any  
 >  > > > further changes (README files, etc.) we expect to be made by individual  
 >  > > > project contributors.  
 >  > > >   
 >  > > > Repository Browsing  
 >  > > > ===================  
 >  > > >   
 >  > > > Currently our canonical *public* repository system is the cgit server at  
 >  > > > https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and  
 >  > > > git.zuul-ci.org).  This is a load balanced cluster of several servers  
 >  > > > which is designed to handle all the public git repository traffic, as it  
 >  > > > scales much better than Gerrit (and has a more friendly domain name).  
 >  > > > From a technical standpoint, it's excellent, but its usability could be  
 >  > > > improved.  
 >  > > >   
 >  > > > Therefore, as part of this transition, we will replace the cgit servers  
 >  > > > with a new system based on Gitea.  Gitea is a complete development  
 >  > > > collaboration system, but it's very flexible and will allow us to  
 >  > > > disable components which we aren't using.  We will operate it in a  
 >  > > > read-only configuration where it will act as the public mirror for  
 >  > > > Gerrit.  The advantages it has over the current system are:  
 >  > > >   
 >  > > > * Shorter domain name in project URLs:  
 >  > > >   https://git.openstack.org/openstack/nova   vs  
 >  > > >   https://opendev.org/openstack/nova  
 >  > > > * Clone and browsing URLs are the same (with cgit, the browsing URL has  
 >  > > >   an extra path component)  
 >  > > > * More visually pleasing code browsing  
 >  > > > * Integrated code searching  
 >  > > > * Ability to highlight multiple lines in links  
 >  > > >   
 >  > > > When we perform the transition we will install redirects from  
 >  > > > git.openstack.org (and the other git sites) to opendev.org, and will  
 >  > > > maintain those redirects for the foreseeable future.  We will construct  
 >  > > > them so that even existing deep links to individual files in individual  
 >  > > > commits to cgit will redirect to the correct location on opendev.org.  
 >  > > >   
 >  > > > This system is up and running now with a live mirror of data from  
 >  > > > Gerrit, and you can start testing it out today at https://opendev.org/  
 >  > > >   
 >  > > > Please let us know if you encounter any problems.  
 >  > > >   
 >  > > > If you would like to read more about the design of this system and the  
 >  > > > transition, see the infra-spec[2].  
 >  > > >   
 >  > > > GitHub  
 >  > > > ======  
 >  > > >   
 >  > > > Currently all OpenStack projects are replicated to GitHub.  We do not  
 >  > > > plan on changing that during the transition, however, any projects  
 >  > > > outside of the openstack*/ namespaces will not automatically be  
 >  > > > replicated to GitHub, and we do not plan on adding that in the future.  
 >  > > > We do, however, support projects using Zuul to run post-merge jobs to  
 >  > > > push updates to GitHub or any other third-party mirrors with their own  
 >  > > > credentials.  We will be happy to work with anyone interested in that to  
 >  > > > help set up jobs to do so.  
 >  > > >   
 >  > > > We are adopting this approach so that individual projects can have more  
 >  > > > control over how they are represented in social media, and to give us  
 >  > > > more flexibility in supporting our own organizational namespaces on  
 >  > > > OpenDev without assuming they map directly to GitHub.  
 >  > > >   
 >  > > > Eventually we plan on moving the OpenStack project to that system as  
 >  > > > well and retiring direct replication from Gerrit to GitHub completely.  
 >  > > > But we will defer that work until after this transition.  
 >  > > >   
 >  > > > Logistics  
 >  > > > =========  
 >  > > >   
 >  > > > We can prepare much of the system in advance (as we have for the hosting  
 >  > > > system on opendev.org), but the actual transition and renaming of the  
 >  > > > Gerrit server will need to happen at once during an outage window.  We  
 >  > > > need to schedule that outage and begin preparing for it.  
 >  > > >   
 >  > > > Since all of the project git URLs are going to change (to replace  
 >  > > > git.openstack.org with opendev.org and review.openstack.org with  
 >  > > > review.opendev.org), we can additionally take the opportunity to  
 >  > > > reorganize projects into different organizations.  
 >  > > >   
 >  > > > For example, during the transition we will rename Zuul, and it's  
 >  > > > associated projects, from the "openstack-infra" org to "zuul".  So their  
 >  > > > new names will be "zuul/zuul", "zuul/nodepool", etc.  
 >  > > >   
 >  > > > This is an excellent time for the rest of the OpenStack Foundation  
 >  > > > pilot projects to do the same.  
 >  > > >   
 >  > > > If the OpenStack project desires this, it would also be a good time to  
 >  > > > move unofficial projects out of the openstack/ namespace.  
 >  > > >   
 >  > > > Therefore, we need your help:  
 >  > > >   
 >  > > > Action Items  
 >  > > > ============  
 >  > > >   
 >  > > > We need each of the following projects:  
 >  > > >   
 >  > > >   * OpenStack  
 >  > > >   * Airship  
 >  > > >   * StarlingX  
 >  > > >   * Zuul  
 >  > > >   
 >  > > > To nominate a single point of contact to work with us on the transition.  
 >  > > > It would be helpful for that person to attend the next (and possibly  
 >  > > > next several) openstack infra team meetings in IRC [3].  We will work  
 >  > > > with those people on scheduling the transition, as well as finalizing  
 >  > > > the list of projects which should be renamed as part of the transition.  
 >  > > >   
 >  > > > If you manage an unofficial project and would like to take the  
 >  > > > opportunity to move or rename your project, please add it to this  
 >  > > > ethercalc[4].  
 >  > > >   
 >  > > > [1]   
 >  > > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html  
 >  > > > [2]   
 >  > > > http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html  
 >  > > > [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting  
 >  > > > [4] https://ethercalc.openstack.org/opendev-transition  
 >  > > >   
 >  > > >  
 >  > >   
 >  > > We've made good progress in preparing this change and are still on   
 >  > > track to do this Friday April 19, 2019.  Our project liasons have been   
 >  > > drawing up lists of projects to rename during the outage. One big thing   
 >  > > to keep in mind is unofficial OpenStack projects will no longer be in   
 >  > > the "openstack" namespace.  They will be placed in the 'x/' namespace   
 >  > > instead which intends to indicate no endorsement or special ownership.  
 >  > >   
 >  > > One side effect of this change (as noted in Jim's earlier email) is   
 >  > > that we will stop replicating projects that move out of the openstack   
 >  > > namespace. Projects that wish to be replicated to Github or anywhere   
 >  > > else they like can do so following the steps that David Moreau-Simard   
 >  > > put together for us here [5].  
 >  > >   
 >  > > This transition is likely to be a bit bumpy particularly at the start.   
 >  > > We'll be around after the transition to help fix unexpected errors and   
 >  > > are likely to spend a fair bit of time at the PTG improving things as   
 >  > > well.  
 >  > >   
 >  > > Finally, to be extra clear, we intend to put http redirects in place so   
 >  > > that all your old http(s) urls continue to work.  Fungi has set this up   
 >  > > for testing with details here [6] if you would like to ensure your urls   
 >  > > redirect properly.  
 >  > >   
 >  > > [5]   
 >  > > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html  
 >  > > [6]   
 >  > > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html  
 >  >   
 >  > The infra/OpenDev team continues to make good progress towards this transition and plans to perform the transition on April 19, 2019 as previously scheduled.  We will begin the transition at 15:00UTC and users should plan for intermittent Gerrit and git repo outages through the day. We expect most of those will be closer to 15:00UTC than 23:00UTC.  
 >  >   
 >  > Fungi has generated a master list of project renames for the openstack namespaces: http://paste.openstack.org/show/749402/. If you have a moment please quickly review these planned renames for any obvious errors or issues.  
 >  
 > Thanks Clark, Fungi for the list. With quick review, below are the two repo which I feel need a home somewhere.  
 >  
 > - gerrit-dash-creator - it thought it was under infra.  
 > - upstream-institute-virtual-environment - We use this in OUI trainings. I pinged this on #openstack-upstream-institute to find home.  
 
I found one more which need to be placed somewhere in openstack/

- microversion-parse - this lib is used by many projects for API microversion parsing.  maybe cdent can suggest. 

>  
 > -gmann 
 >  
 >  >   
 >  > For the airship, starlingx, and zuul repo renames the repositories listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were used placing repos in airship/, starlingx/ and zuul/ namespaces. Any repo name prefix (like stx- and airship-) is dropped.  
 >  >   
 >  > As always we are happy to answer any questions you might have or address any concerns. Feel free to reach out.  
 >  > Thank you for your patience,  
 >  > Clark  
 >  >   
 >  >  
 > 



From mriedemos at gmail.com  Wed Apr 17 02:30:55 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 16 Apr 2019 21:30:55 -0500
Subject: [nova] Stein regressions
Message-ID: <27a23eb0-b31b-0f25-db74-bdef81908939@gmail.com>

Hey cool cats,

I know we just released Stein last week so what better time to write an 
email about a bunch of Stein regressions?!

I wanted to dump this in the list so (a) I don't lose track of them all 
and (b) other people are aware and get involved.

In no particular order:

1. https://bugs.launchpad.net/nova/+bug/1822801

There is a patch being worked: https://review.openstack.org/#/c/649345/

The workaround for this would be to disable the 
_heal_instance_info_cache periodic in nova-compute services that manage 
baremetal nodes by setting the heal_instance_info_cache_interval value to 0.

2. https://bugs.launchpad.net/nova/+bug/1824435

We have a re-create scenario for this in devstack (noted in the bug 
report). I've been unable to recreate in a functional test, possibly 
because of how sqlite deals with NULL values in unique constraints 
differently from mysql. I would have thought this regression test [1] 
would have hit it but it didn't.

There are some options for fixing this, some more hacky than others, e.g.:

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

Need some input from others on fixing that bug in maybe a less hacky way.

3. https://bugs.launchpad.net/nova/+bug/1825034

I found this when writing [1] to try and recreate the previous bug 
1824435. I have a series up for this starting with a recreate patch [1].
The fix on top is one of a few options I detailed in the bug report. 
It's not pretty but it works.

The workaround for this would be to archive deleted records but you'd 
have to do that after each run of the online data migration which is not 
great.

4. https://bugs.launchpad.net/nova/+bug/1825020

I just triaged this a couple of hours ago. I plan on writing a 
functional regression recreate test since the recreate scenario seems 
pretty easy - try to resize a volume-backed server where the new flavor 
has a smaller disk than the old flavor. The fix should also be 
relatively straight-forward.

--

Once we get fixes landed and backported to stable/stein for these bugs 
we should do a patch release ASAP.

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

-- 

Thanks,

Matt


From mriedemos at gmail.com  Wed Apr 17 02:49:00 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 16 Apr 2019 21:49:00 -0500
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
Message-ID: <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>

On 4/16/2019 7:03 PM, melanie witt wrote:
> To debug further, you should set debug to True in the nova.conf on your 
> scheduler host and look for which filter is removing the desired host 
> for the second VM. You can find where to start by looking for a message 
> like, "Starting with N host(s)". If you have two hosts with enough RAM, 
> you should see "Starting with 2 host(s)" and then look for the log 
> message where it says "Filter returned 1 host(s)" and that will be the 
> filter that is removing the desired host. Once you know which filter is 
> removing it, you can debug further.

If the other host isn't getting filtered out, it could be the weighers 
that aren't prioritizing the host you expect, but debug logs should dump 
the weighed hosts as well which might give a clue.

-- 

Thanks,

Matt


From yamamoto at midokura.com  Wed Apr 17 03:46:26 2019
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Wed, 17 Apr 2019 12:46:26 +0900
Subject: Migrating git repos to OpenDev
In-Reply-To: <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
Message-ID: <CAH=wFzT2Eq_9etcC08FmhzF1X80ivPmVg9UbTtPBLemBxWtvLw@mail.gmail.com>

On Wed, Apr 17, 2019 at 9:16 AM Clark Boylan <cboylan at sapwetik.org> wrote:
>
> On Thu, Apr 11, 2019, at 3:21 PM, Clark Boylan wrote:
> > On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote:
> > > Hi,
> > >
> > > As discussed in November[1], the OpenStack project infrastructure is
> > > being rebranded as "OpenDev" to better support a wider community of
> > > projects.
> > >
> > > We are nearly ready to perform the part of this transition with the
> > > largest impact: moving the authoritative git repositories for existing
> > > projects.
> > >
> > > In this email, I'd like to introduce the new hosting system we are
> > > preparing, discuss the transition, and invite projects to work with us
> > > on the logistics of the change.
> > >
> > > Gerrit
> > > ======
> > >
> > > Gerrit is the core of our system and it will remain so in OpenDev.  As
> > > part of this move, we will rename the gerrit server from
> > > review.openstack.org to review.opendev.org.  As part of the transition,
> > > we will automatically merge appropriate changes to all branches of all
> > > repositories updating .gitreview and Zuul configuration files.  Any
> > > further changes (README files, etc.) we expect to be made by individual
> > > project contributors.
> > >
> > > Repository Browsing
> > > ===================
> > >
> > > Currently our canonical *public* repository system is the cgit server at
> > > https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and
> > > git.zuul-ci.org).  This is a load balanced cluster of several servers
> > > which is designed to handle all the public git repository traffic, as it
> > > scales much better than Gerrit (and has a more friendly domain name).
> > > From a technical standpoint, it's excellent, but its usability could be
> > > improved.
> > >
> > > Therefore, as part of this transition, we will replace the cgit servers
> > > with a new system based on Gitea.  Gitea is a complete development
> > > collaboration system, but it's very flexible and will allow us to
> > > disable components which we aren't using.  We will operate it in a
> > > read-only configuration where it will act as the public mirror for
> > > Gerrit.  The advantages it has over the current system are:
> > >
> > > * Shorter domain name in project URLs:
> > >   https://git.openstack.org/openstack/nova   vs
> > >   https://opendev.org/openstack/nova
> > > * Clone and browsing URLs are the same (with cgit, the browsing URL has
> > >   an extra path component)
> > > * More visually pleasing code browsing
> > > * Integrated code searching
> > > * Ability to highlight multiple lines in links
> > >
> > > When we perform the transition we will install redirects from
> > > git.openstack.org (and the other git sites) to opendev.org, and will
> > > maintain those redirects for the foreseeable future.  We will construct
> > > them so that even existing deep links to individual files in individual
> > > commits to cgit will redirect to the correct location on opendev.org.
> > >
> > > This system is up and running now with a live mirror of data from
> > > Gerrit, and you can start testing it out today at https://opendev.org/
> > >
> > > Please let us know if you encounter any problems.
> > >
> > > If you would like to read more about the design of this system and the
> > > transition, see the infra-spec[2].
> > >
> > > GitHub
> > > ======
> > >
> > > Currently all OpenStack projects are replicated to GitHub.  We do not
> > > plan on changing that during the transition, however, any projects
> > > outside of the openstack*/ namespaces will not automatically be
> > > replicated to GitHub, and we do not plan on adding that in the future.
> > > We do, however, support projects using Zuul to run post-merge jobs to
> > > push updates to GitHub or any other third-party mirrors with their own
> > > credentials.  We will be happy to work with anyone interested in that to
> > > help set up jobs to do so.
> > >
> > > We are adopting this approach so that individual projects can have more
> > > control over how they are represented in social media, and to give us
> > > more flexibility in supporting our own organizational namespaces on
> > > OpenDev without assuming they map directly to GitHub.
> > >
> > > Eventually we plan on moving the OpenStack project to that system as
> > > well and retiring direct replication from Gerrit to GitHub completely.
> > > But we will defer that work until after this transition.
> > >
> > > Logistics
> > > =========
> > >
> > > We can prepare much of the system in advance (as we have for the hosting
> > > system on opendev.org), but the actual transition and renaming of the
> > > Gerrit server will need to happen at once during an outage window.  We
> > > need to schedule that outage and begin preparing for it.
> > >
> > > Since all of the project git URLs are going to change (to replace
> > > git.openstack.org with opendev.org and review.openstack.org with
> > > review.opendev.org), we can additionally take the opportunity to
> > > reorganize projects into different organizations.
> > >
> > > For example, during the transition we will rename Zuul, and it's
> > > associated projects, from the "openstack-infra" org to "zuul".  So their
> > > new names will be "zuul/zuul", "zuul/nodepool", etc.
> > >
> > > This is an excellent time for the rest of the OpenStack Foundation
> > > pilot projects to do the same.
> > >
> > > If the OpenStack project desires this, it would also be a good time to
> > > move unofficial projects out of the openstack/ namespace.
> > >
> > > Therefore, we need your help:
> > >
> > > Action Items
> > > ============
> > >
> > > We need each of the following projects:
> > >
> > >   * OpenStack
> > >   * Airship
> > >   * StarlingX
> > >   * Zuul
> > >
> > > To nominate a single point of contact to work with us on the transition.
> > > It would be helpful for that person to attend the next (and possibly
> > > next several) openstack infra team meetings in IRC [3].  We will work
> > > with those people on scheduling the transition, as well as finalizing
> > > the list of projects which should be renamed as part of the transition.
> > >
> > > If you manage an unofficial project and would like to take the
> > > opportunity to move or rename your project, please add it to this
> > > ethercalc[4].
> > >
> > > [1]
> > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
> > > [2]
> > > http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html
> > > [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting
> > > [4] https://ethercalc.openstack.org/opendev-transition
> > >
> > >
> >
> > We've made good progress in preparing this change and are still on
> > track to do this Friday April 19, 2019.  Our project liasons have been
> > drawing up lists of projects to rename during the outage. One big thing
> > to keep in mind is unofficial OpenStack projects will no longer be in
> > the "openstack" namespace.  They will be placed in the 'x/' namespace
> > instead which intends to indicate no endorsement or special ownership.
> >
> > One side effect of this change (as noted in Jim's earlier email) is
> > that we will stop replicating projects that move out of the openstack
> > namespace. Projects that wish to be replicated to Github or anywhere
> > else they like can do so following the steps that David Moreau-Simard
> > put together for us here [5].
> >
> > This transition is likely to be a bit bumpy particularly at the start.
> > We'll be around after the transition to help fix unexpected errors and
> > are likely to spend a fair bit of time at the PTG improving things as
> > well.
> >
> > Finally, to be extra clear, we intend to put http redirects in place so
> > that all your old http(s) urls continue to work.  Fungi has set this up
> > for testing with details here [6] if you would like to ensure your urls
> > redirect properly.
> >
> > [5]
> > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
> > [6]
> > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html
>
> The infra/OpenDev team continues to make good progress towards this transition and plans to perform the transition on April 19, 2019 as previously scheduled.  We will begin the transition at 15:00UTC and users should plan for intermittent Gerrit and git repo outages through the day. We expect most of those will be closer to 15:00UTC than 23:00UTC.
>
> Fungi has generated a master list of project renames for the openstack namespaces: http://paste.openstack.org/show/749402/. If you have a moment please quickly review these planned renames for any obvious errors or issues.

while tap-as-a-service is unofficial at this point, the intention is
to make it a part of neutron sooner or later.
i want to keep them under openstack/ if acceptable.
openstack/tap-as-a-service -> x/tap-as-a-service
openstack/tap-as-a-service-dashboard -> x/tap-as-a-service-dashboard
openstack/tap-as-a-service-tempest-plugin -> x/tap-as-a-service-tempest-plugin

>
> For the airship, starlingx, and zuul repo renames the repositories listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were used placing repos in airship/, starlingx/ and zuul/ namespaces. Any repo name prefix (like stx- and airship-) is dropped.
>
> As always we are happy to answer any questions you might have or address any concerns. Feel free to reach out.
> Thank you for your patience,
> Clark
>


From yamamoto at midokura.com  Wed Apr 17 04:11:09 2019
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Wed, 17 Apr 2019 13:11:09 +0900
Subject: Migrating git repos to OpenDev
In-Reply-To: <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
Message-ID: <CAH=wFzTpwpiU_bGOe7n9+A5RYZSs=mDsgq+r-OtLFP5zk2je3A@mail.gmail.com>

On Wed, Apr 17, 2019 at 9:16 AM Clark Boylan <cboylan at sapwetik.org> wrote:
>
> On Thu, Apr 11, 2019, at 3:21 PM, Clark Boylan wrote:
> > On Thu, Mar 7, 2019, at 1:46 PM, James E. Blair wrote:
> > > Hi,
> > >
> > > As discussed in November[1], the OpenStack project infrastructure is
> > > being rebranded as "OpenDev" to better support a wider community of
> > > projects.
> > >
> > > We are nearly ready to perform the part of this transition with the
> > > largest impact: moving the authoritative git repositories for existing
> > > projects.
> > >
> > > In this email, I'd like to introduce the new hosting system we are
> > > preparing, discuss the transition, and invite projects to work with us
> > > on the logistics of the change.
> > >
> > > Gerrit
> > > ======
> > >
> > > Gerrit is the core of our system and it will remain so in OpenDev.  As
> > > part of this move, we will rename the gerrit server from
> > > review.openstack.org to review.opendev.org.  As part of the transition,
> > > we will automatically merge appropriate changes to all branches of all
> > > repositories updating .gitreview and Zuul configuration files.  Any
> > > further changes (README files, etc.) we expect to be made by individual
> > > project contributors.
> > >
> > > Repository Browsing
> > > ===================
> > >
> > > Currently our canonical *public* repository system is the cgit server at
> > > https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and
> > > git.zuul-ci.org).  This is a load balanced cluster of several servers
> > > which is designed to handle all the public git repository traffic, as it
> > > scales much better than Gerrit (and has a more friendly domain name).
> > > From a technical standpoint, it's excellent, but its usability could be
> > > improved.
> > >
> > > Therefore, as part of this transition, we will replace the cgit servers
> > > with a new system based on Gitea.  Gitea is a complete development
> > > collaboration system, but it's very flexible and will allow us to
> > > disable components which we aren't using.  We will operate it in a
> > > read-only configuration where it will act as the public mirror for
> > > Gerrit.  The advantages it has over the current system are:
> > >
> > > * Shorter domain name in project URLs:
> > >   https://git.openstack.org/openstack/nova   vs
> > >   https://opendev.org/openstack/nova
> > > * Clone and browsing URLs are the same (with cgit, the browsing URL has
> > >   an extra path component)
> > > * More visually pleasing code browsing
> > > * Integrated code searching
> > > * Ability to highlight multiple lines in links
> > >
> > > When we perform the transition we will install redirects from
> > > git.openstack.org (and the other git sites) to opendev.org, and will
> > > maintain those redirects for the foreseeable future.  We will construct
> > > them so that even existing deep links to individual files in individual
> > > commits to cgit will redirect to the correct location on opendev.org.
> > >
> > > This system is up and running now with a live mirror of data from
> > > Gerrit, and you can start testing it out today at https://opendev.org/
> > >
> > > Please let us know if you encounter any problems.
> > >
> > > If you would like to read more about the design of this system and the
> > > transition, see the infra-spec[2].
> > >
> > > GitHub
> > > ======
> > >
> > > Currently all OpenStack projects are replicated to GitHub.  We do not
> > > plan on changing that during the transition, however, any projects
> > > outside of the openstack*/ namespaces will not automatically be
> > > replicated to GitHub, and we do not plan on adding that in the future.
> > > We do, however, support projects using Zuul to run post-merge jobs to
> > > push updates to GitHub or any other third-party mirrors with their own
> > > credentials.  We will be happy to work with anyone interested in that to
> > > help set up jobs to do so.
> > >
> > > We are adopting this approach so that individual projects can have more
> > > control over how they are represented in social media, and to give us
> > > more flexibility in supporting our own organizational namespaces on
> > > OpenDev without assuming they map directly to GitHub.
> > >
> > > Eventually we plan on moving the OpenStack project to that system as
> > > well and retiring direct replication from Gerrit to GitHub completely.
> > > But we will defer that work until after this transition.
> > >
> > > Logistics
> > > =========
> > >
> > > We can prepare much of the system in advance (as we have for the hosting
> > > system on opendev.org), but the actual transition and renaming of the
> > > Gerrit server will need to happen at once during an outage window.  We
> > > need to schedule that outage and begin preparing for it.
> > >
> > > Since all of the project git URLs are going to change (to replace
> > > git.openstack.org with opendev.org and review.openstack.org with
> > > review.opendev.org), we can additionally take the opportunity to
> > > reorganize projects into different organizations.
> > >
> > > For example, during the transition we will rename Zuul, and it's
> > > associated projects, from the "openstack-infra" org to "zuul".  So their
> > > new names will be "zuul/zuul", "zuul/nodepool", etc.
> > >
> > > This is an excellent time for the rest of the OpenStack Foundation
> > > pilot projects to do the same.
> > >
> > > If the OpenStack project desires this, it would also be a good time to
> > > move unofficial projects out of the openstack/ namespace.
> > >
> > > Therefore, we need your help:
> > >
> > > Action Items
> > > ============
> > >
> > > We need each of the following projects:
> > >
> > >   * OpenStack
> > >   * Airship
> > >   * StarlingX
> > >   * Zuul
> > >
> > > To nominate a single point of contact to work with us on the transition.
> > > It would be helpful for that person to attend the next (and possibly
> > > next several) openstack infra team meetings in IRC [3].  We will work
> > > with those people on scheduling the transition, as well as finalizing
> > > the list of projects which should be renamed as part of the transition.
> > >
> > > If you manage an unofficial project and would like to take the
> > > opportunity to move or rename your project, please add it to this
> > > ethercalc[4].
> > >
> > > [1]
> > > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
> > > [2]
> > > http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html
> > > [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting
> > > [4] https://ethercalc.openstack.org/opendev-transition
> > >
> > >
> >
> > We've made good progress in preparing this change and are still on
> > track to do this Friday April 19, 2019.  Our project liasons have been
> > drawing up lists of projects to rename during the outage. One big thing
> > to keep in mind is unofficial OpenStack projects will no longer be in
> > the "openstack" namespace.  They will be placed in the 'x/' namespace
> > instead which intends to indicate no endorsement or special ownership.
> >
> > One side effect of this change (as noted in Jim's earlier email) is
> > that we will stop replicating projects that move out of the openstack
> > namespace. Projects that wish to be replicated to Github or anywhere
> > else they like can do so following the steps that David Moreau-Simard
> > put together for us here [5].
> >
> > This transition is likely to be a bit bumpy particularly at the start.
> > We'll be around after the transition to help fix unexpected errors and
> > are likely to spend a fair bit of time at the PTG improving things as
> > well.
> >
> > Finally, to be extra clear, we intend to put http redirects in place so
> > that all your old http(s) urls continue to work.  Fungi has set this up
> > for testing with details here [6] if you would like to ensure your urls
> > redirect properly.
> >
> > [5]
> > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
> > [6]
> > http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004921.html
>
> The infra/OpenDev team continues to make good progress towards this transition and plans to perform the transition on April 19, 2019 as previously scheduled.  We will begin the transition at 15:00UTC and users should plan for intermittent Gerrit and git repo outages through the day. We expect most of those will be closer to 15:00UTC than 23:00UTC.
>
> Fungi has generated a master list of project renames for the openstack namespaces: http://paste.openstack.org/show/749402/. If you have a moment please quickly review these planned renames for any obvious errors or issues.

i guess networking-l2gw-tempest-plugin should go to the same namespace
with networking-l2gw.

>
> For the airship, starlingx, and zuul repo renames the repositories listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were used placing repos in airship/, starlingx/ and zuul/ namespaces. Any repo name prefix (like stx- and airship-) is dropped.
>
> As always we are happy to answer any questions you might have or address any concerns. Feel free to reach out.
> Thank you for your patience,
> Clark
>


From aj at suse.com  Wed Apr 17 07:14:29 2019
From: aj at suse.com (Andreas Jaeger)
Date: Wed, 17 Apr 2019 09:14:29 +0200
Subject: Migrating git repos to OpenDev
In-Reply-To: <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
Message-ID: <da554de2-1a00-ebdb-efb0-e3cd0e0fd850@suse.com>

On 17/04/2019 04.10, Ghanshyam Mann wrote:
> [...]
> Thanks Clark, Fungi for the list. With quick review, below are the two repo which I feel need a home somewhere. 
> 
> - gerrit-dash-creator - it thought it was under infra. 

It was never under governance, so is independent.

Looks like I'm the only reviewer of it at the moment, if anybody wants
to help and move it to another place, please speak up,

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



From ifatafekn at gmail.com  Wed Apr 17 07:31:15 2019
From: ifatafekn at gmail.com (Ifat Afek)
Date: Wed, 17 Apr 2019 10:31:15 +0300
Subject: [vitrage][ptg] Vitrage PTG etherpad
Message-ID: <CALxdkcwZ3MsQn3TUL-w8YvQvtjRCaLOpsEKcU6Tt1W0Fry5+TQ@mail.gmail.com>

Hi,


I created an etherpad for discussion topics for the Vitrage PTG, which will
be held on Friday morning, May 3rd.

Feel free to comment or add other topics.



https://etherpad.openstack.org/p/vitrage-train-ptg



Thanks,

Ifat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/7865ee7d/attachment.html>

From shiina.hironori at fujitsu.com  Wed Apr 17 07:43:42 2019
From: shiina.hironori at fujitsu.com (shiina.hironori at fujitsu.com)
Date: Wed, 17 Apr 2019 07:43:42 +0000
Subject: [ironic] Stepping down from core
Message-ID: <TYXPR01MB1568525B894BC6A30EAEE93CEB250@TYXPR01MB1568.jpnprd01.prod.outlook.com>

Hi ironic folks,

I'm sorry for my long absence. My job responsibility changed last November. Since it,
I have been trying to spend some time on the core activity. But, I couldn't. So, I'm
stepping down from the ironic core team.

Thank you for accepting me to the team even though I didn't often appear in IRC due
to the time difference. I hope I will work with you again someday.

Best regards,
Hironori



From dtantsur at redhat.com  Wed Apr 17 07:46:59 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 17 Apr 2019 09:46:59 +0200
Subject: [ironic] Stepping down from core
In-Reply-To: <TYXPR01MB1568525B894BC6A30EAEE93CEB250@TYXPR01MB1568.jpnprd01.prod.outlook.com>
References: <TYXPR01MB1568525B894BC6A30EAEE93CEB250@TYXPR01MB1568.jpnprd01.prod.outlook.com>
Message-ID: <2c707b00-08d2-96e2-056f-1e9ee4daa884@redhat.com>

Hi Hironori,

It was great to work with you all this time. Thank you for your invaluable  
contributions, and good luck with your new challenge!

Dmitry

On 4/17/19 9:43 AM, shiina.hironori at fujitsu.com wrote:
> Hi ironic folks,
> 
> I'm sorry for my long absence. My job responsibility changed last November. Since it,
> I have been trying to spend some time on the core activity. But, I couldn't. So, I'm
> stepping down from the ironic core team.
> 
> Thank you for accepting me to the team even though I didn't often appear in IRC due
> to the time difference. I hope I will work with you again someday.
> 
> Best regards,
> Hironori
> 
> 



From surya.seetharaman9 at gmail.com  Wed Apr 17 08:45:40 2019
From: surya.seetharaman9 at gmail.com (Surya Seetharaman)
Date: Wed, 17 Apr 2019 10:45:40 +0200
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
Message-ID: <CAB+ArpZePQUw1B0Psw+f8CsEW29F+K8idZOTbyvLJF=n1ZGycA@mail.gmail.com>

On Tue, Apr 16, 2019 at 11:05 PM melanie witt <melwittt at gmail.com> wrote:

> On Tue, 16 Apr 2019 09:13:47 -0700, Dan Smith <dms at danplanet.com> wrote:
> >> Obviously, all consumers are currently Nova instances in placement
> >> since (AFAIK) no other services have begun using placement to store
> >> allocations.
> >
> > This is not the case, actually. In Nova, we can have consumers that are
> > instances, as well as consumers that are migrations (related to
> > instances, but distinct). In order to be able to distinguish between the
> > two, a partitioning key (I'd prefer we call this consumer type too) is
> > needed. The quota work needs this specifically, so that we can know the
> > usage by instances separately from usage that is reserved or pinned by
> > an ongoing migration.
> >
> >>> How urgent is this? Is there anyone available to do the work this
> >>> cycle? How damaging is it to punt to U? What details are missing in
> >>> the above description?
> >
> > I guess we defer this question to Melanie, but I think the ability to
> > count most of the quota elements we want using placement instead of the
> > current method hinges on the ability to distinguish these things.
>
> The latest incarnation of the quota usage from placement work [1] has
> counting from placement as opt-in, based on a few reasons explained in
> the commit message. And the spec will be amended when/if there is
> confirmation the patches will land in this form.
>
> Given the opt-in nature of the quota stuff ^, it could be tempting to
> punt it. But my biased opinion is that it would be nice to get working
> on it so we can make counting quota usage from placement our default
> behavior sooner than later.
>
>
+1



> Consumer types would enable us to count instances from placement, I
> believe. Current code [1] has to count instances from instance mappings
> in the API database. Consumer types would also enable us to implement
> the quota usage behavior we want during a resize, to take max('instance'
> usage, 'migration' usage).
>
> Finally, resource provider partitioning would allow quota usage from
> placement to be correct in an environment with multiple nova deployments
> sharing a single placement deployment.
>
> If we are able to fill in those gaps, we would be in a good position to
> make counting quota usage from placement our default behavior in nova.
>
>
I agree that while we have started the quota counting from placement as an
opt-in it would be good to get the missing pieces in to make it whole asap.
I can offer help if needed for the pieces.

-- 

Regards,
Surya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/858aa62d/attachment-0001.html>

From surya.seetharaman9 at gmail.com  Wed Apr 17 08:53:32 2019
From: surya.seetharaman9 at gmail.com (Surya Seetharaman)
Date: Wed, 17 Apr 2019 10:53:32 +0200
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <648ae0d8-d1f0-1deb-0d58-91cda5e7747a@gmail.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <956785d0-d11c-7d00-7d68-1826d5a093ae@gmail.com>
 <f51095ad-a5e4-33b1-018b-fbc009180477@gmail.com>
 <5c99cd97-2522-c9dd-dfab-e393dd23e6b2@gmail.com>
 <76040bb2-be1f-290d-7a33-552499a7065c@gmail.com>
 <bc0ca9ee-1d23-a7d2-134d-282d0b54b861@gmail.com>
 <648ae0d8-d1f0-1deb-0d58-91cda5e7747a@gmail.com>
Message-ID: <CAB+ArpYdAPhsoER1Oc+BQMJzLt2bLiZzia+DTCEjdYwOvPTCuQ@mail.gmail.com>

On Wed, Apr 17, 2019 at 3:22 AM melanie witt <melwittt at gmail.com> wrote:

> On Tue, 16 Apr 2019 17:46:15 -0700, Melanie Witt <melwittt at gmail.com>
> wrote:
> > On Tue, 16 Apr 2019 19:32:57 -0500, Matt Riedemann <mriedemos at gmail.com>
> > wrote:
> >> On 4/16/2019 7:22 PM, melanie witt wrote:
> >>> Today, an ERROR instance that has never been scheduled will consume
> >>> cores and ram quota usage
> >>
> >> Hmm, I wonder if that was also a regression in Pike with counting
> >> quotas. Because that usage is not real and arguably shouldn't count
> >> against the tenant.
> >
> > I don't think so, based on hazy anecdotal experience and a look at the
> > code which does a quota reservation before scheduling and doesn't appear
> > to rollback quota in any failure case in conductor:
> >
> >
> https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L313
> >
> > I still have my Ocata devstack up, so I'll do a test and reply with the
> > results for Ocata, Train, and Train + counting from placement.
>
> Here are the results:
>
> * Ocata behavior, unscheduled ERROR instance consumes quota usage for
> instances, cores, and ram: http://paste.openstack.org/show/749406
>
> * Train behavior, unscheduled ERROR instance consumes quota usage for
> instances, cores, and ram: http://paste.openstack.org/show/749407
>
> * Train behavior + counting from placement, consumes quota usage for
> instances (API database) but not for cores and ram (placement
> allocations): http://paste.openstack.org/show/749408
>
>
I guess this would be the expected/needed behaviour right? That is we count
the instance but don't count the RAM and cores. Maybe we should fix this
for the stable branches also in the current way of counting.

-- 

Regards,
Surya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/8a0693de/attachment.html>

From Helen.Walsh at dell.com  Wed Apr 17 08:53:54 2019
From: Helen.Walsh at dell.com (Walsh, Helen)
Date: Wed, 17 Apr 2019 08:53:54 +0000
Subject: [cinder][dev] support-revert-to-any-snapshot
In-Reply-To: <6031C821D2144A4CB722005A21B34BD53AE7E1AC@MX202CL02.corp.emc.com>
References: <6031C821D2144A4CB722005A21B34BD53AE7E1AC@MX202CL02.corp.emc.com>
Message-ID: <6031C821D2144A4CB722005A21B34BD53AE81F42@MX202CL02.corp.emc.com>


To cinder driver developers:

*        https://blueprints.launchpad.net/cinder/+spec/support-revert-to-any-snapshot

In relation to the blueprint above.  I am wondering if there are any drivers that whose later snapshots will not be valid after a revert to an snapshot that is NOT the last in the series

                                                              Vol1
                                                                 \
-----------------------------------------------------
Mon        Tue          Wed       Thu           Fri
   \              \                 \                \              \
    S1 -------- S2 ---------S3 -------- S4 ---------S5


If on Fri, I was to revert back to Tuesday's Snapshot S2, would S3, S4 and S5 still be usable Snapshots?


             Vol1
                \
-----------------------------------------------------
Mon        Tue          Wed       Thu           Fri
   \              \                 \                \              \
    S1 -------- S2 ---------S3 -------- S4 ---------S5

Thank you,
Helen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/3dbc2b05/attachment.html>

From soulxu at gmail.com  Wed Apr 17 09:16:59 2019
From: soulxu at gmail.com (Alex Xu)
Date: Wed, 17 Apr 2019 17:16:59 +0800
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <alpine.OSX.2.21.1904161812170.4039@cdent-a01.vmware.com>
 <bd75e7ec-1c7f-0dd4-f8ef-fc74174b9fb7@fried.cc>
Message-ID: <CAH7mGatO330ybaaBnTtzepFaU+L9tzO4ga1Z-L8NjO+PaAuOgQ@mail.gmail.com>

Eric Fried <openstack at fried.cc> 于2019年4月17日周三 上午3:28写道：

> > I'm not sure I understand your proposal. Would you introduce a VM
> > resource and then allocate 1 of that resource for each VM?
>
> This has been proposed before, somewhere: translating
> max_instances_per_host to an inventory of resource class "VM" on the
> compute node RP, and including resources:VM=1 in every GET /a_c request.
>

Actually, I propose to attach traits to the RP which has the VCPU resource.
In the case, we have NUMA in placement. We will attach traits to the numa
node RP. I just try to explain why that may makes sense. Since the those
traits should be attached to the "Compute" resource, and the VCPU is just
that "Compute" resource.(yes, we have two numa nodes, then both two numa
nodes has those traits, but it should be fine). When we are asking those
traits, then we must asking the VCPU, right? If so, it sounds make sense.
Or is there any case we only request a trait, totally no resource
requesting? If yes, that may not works. But I think the case we begin to
discussion is about the trait and resource aren't in the same RP. For the
neutron bw case, we still attach nic type trait to the PF, not the agent,
for the same reason.


>
> This would solve the class of use cases like:
>
> >>  So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA
>
> but wouldn't help us for:
>
> > So what we need to solve is. Two (or more) sets of resources where the
> > different sets requires different, contradicting traits, in a setup
> > where the trait is not on the RP where resource inventory is.
> >
> > compute RP
> > |
> > |
> > |____ OVS agent RP
> > |      |     * CUSTOM_VNIC_TYPE_NORMAL
> > |      |
> > |      |___________ br-int dev RP
> > |                       * CUSTOM_PHYSNET_PHYSNET0
> > |                       * NET_BW_EGR_KILOBIT_PER_SEC: 1000
> > |
> > |
> > |____ SRIOV agent RP
> > |      |     * CUSTOM_VNIC_TYPE_DIRECT
> > |      |
> > |      |
> > |      |___________ esn1 dev RP
> > |      |                * CUSTOM_PHYSNET_PHYSNET0
> > |      |                * NET_BW_EGR_KILOBIT_PER_SEC: 10000
> > |      |
> > |      |___________ esn2 dev RP
> > |                       * CUSTOM_PHYSNET_PHYSNET1
> > |                       * NET_BW_EGR_KILOBIT_PER_SEC: 20000
> >
> >
> > Then having two neutron ports in a server create request:
> > * port-normal:
> >     "resource_request": {
> >     "resources": {
> >             orc.NET_BW_EGR_KILOBIT_PER_SEC: 1000},
> >     "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_NORMAL"]
> >
> > * port-direct:
> >     "resource_request": {
> >     "resources": {
> >             orc.NET_BW_EGR_KILOBIT_PER_SEC: 2000},
> >     "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_DIRECT"]
>
> ...unless we contrive some inventory unit to put on the agent RPs. What
> would that be? VNIC? How would we know how many to create?
>
> Interestingly, the above is closely approaching the space we're
> exploring for "subtree affinity". I'm wondering if there's a Unified
> Solution...
>

yea, if we are going to create a virtual resource 'VM', then we need
'VNIC', and then we need more. I don't like that.


>
> > For example, if we said that "traits always flow down [4]" (the
> > phrase that entered my brain and got me to start this email, "down"
> > in this case is "in the direction of children") then some traits
> > could be on the compute node, but expressed in a numbered request
> > group if that happened to be more convenient.
> >
> > This mental model works well for me, because nested often represents
> > a _containing_ hierarchy [2].
> >
> > If the "compute RP has no resources to give [...] but it's still the
> thing
> > exposing traits we want to filter by" [3], if we make it so the children
> > inherit those traits (because they have flowed down and the children
> > are "inside" the thing) things feel a bit saner to me. Would be good
> > if Eric were able to express in more detail why inherit feels
> > "terrible" [3]. It could very well be.
>
> I also said "feels". I can't really explain it any better than I could
> explain why "using group numbers as values" gave me the ooks. And given
> we're coming up ugly with all other proposals, convince me that this one
> is practical and not fraught with peril and I'll quickly get over my
> discomfort. Right now I'm pretty close to that point because it
> elegantly solves both classes of problem described above, and I can't
> think of a way to break it that isn't ridiculously contrived.
>
> It's possible we punted on it before because a) we didn't have the
> concrete use cases we have now; and b) it was going to be pretty tricky
> to implement. More on that below.
>
> > Similarly, aggregate membership would flow down as well, because a
> > child is always in its parent's aggregate too because it is inside its
> > parent.
>
> This one I'm not so convinced about. Can we defer making changes here
> until we have similarly concrete use cases?
>
> > A numeric requiredN or member_ofN span would be capped by the resource
> > provider that satisfied resourcesN.
>
> Eh? I was following you up to this point. Do you just mean that we don't
> have to worry about ascending the tree looking for requiredN because the
> trait is implicitly on the provider with resourceN by virtue of being on
> its ancestor?
>
> > We need to work out a consistent and relatively easy to explain
> > mental model for this, because we need to be able to talk about it
> > with other people without them being required to re-experience all
> > the mental hurdles we are having to overcome.
>
> I think the hurdles are more around "why" and "are you sure you want to"
> - once we've made those decisions, IMO it can be understood fairly
> easily with one or both of "encapsulation" and "traits flow down" as
> you've explained them.
>
> > [4] A corollary could be "classes of inventory always flow up": If
> > you need a SRIOV_NET_VF, this root resource provider can provide it
> > because it has a great grandchild which has it.
>
> This one bakes my noodle pretty good. I have a harder time visualizing
> how the above use cases are satisfied by walking backwards up the tree
> accumulating resources (and you have to accumulate the traits as well,
> right?) until I hit a point where I've gathered everything I need.
>
> So I'll come down in favor of making "traits flow down" happen. Question
> is, how? (And I know we've talked about this before - maybe Queens+Denver?)
>
> (A) In the database.
>   (i) Any time a trait is added to a provider, we create records for
> same trait for all descendants.
>   (ii) Need a data migration to bring existing data into conformance with ^
>   (iii) When a trait is deleted from a provider, I assume we need to
> recursively delete it from all descendants. If you didn't want that,
> you'd have to go back and re-add it to the descendants you wanted it on.
>
> Pros: Easy to do. We don't have to change any of the APIs' algorithms -
> they just work the way we want them to by virtue of the trait data being
> where we want it. Reporting (e.g. GET /rps and therefore CLI output)
> reflects "reality".
> Cons: Irreversible. Not backward compatible. Can't do it in a microversion.
>
> (B) In the algorithms.
>   (i) GET /rps and GET /a_cs queries need JOINs I can't even begin to
> comprehend.
>   (ii) Do we tweak the outputs (GET /rps response and GET /a_cs
> provider_summaries) to report the "inherited" traits as well?
>
> Pros: Can do it in a microversion.
> Cons: See "can't even begin to comprehend". Maybe I'm a dunce.
>
> Perhaps this suggests a hybrid approach:
>
> (C) Create a "ghost" table of inherited resource provider traits. If
> $old_microversion we ignore it; if $new_microversion we logically
> combine it with the existing rp traits table in all our queries.
>
> Thoughts?
>
> efried
> .
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/a0afd957/attachment-0001.html>

From cdent+os at anticdent.org  Wed Apr 17 09:45:18 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 17 Apr 2019 10:45:18 +0100 (BST)
Subject: Migrating git repos to OpenDev
In-Reply-To: <16a291e8818.b2a0ab2f16578.5918920171050047498@ghanshyammann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
 <16a291e8818.b2a0ab2f16578.5918920171050047498@ghanshyammann.com>
Message-ID: <alpine.OSX.2.21.1904171034230.14914@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Ghanshyam Mann wrote:

> I found one more which need to be placed somewhere in openstack/
>
> - microversion-parse - this lib is used by many projects for API microversion parsing.  maybe cdent can suggest.

When microversion-parse was first put together it wasn't put under
an official project for three reasons:

* Make it accessible to anything outside the OpenStack world that
   might like to work with microversion (if ever such a thing cae to
   exist).

* Make it crystal clear that the library was just a thing you
   install from PyPI, no big deal.

* Couldn't decide anywhere to put it.

We're essentially still in that boat, but what's changed, at least a
bit, is that it's increasingly easy to think of things born in the
OpenStack world as just things you can install from PyPI.

All of which is a long way of saying I don't really have any good
suggestions.

The current core group is made up of members of the API-SIG but that
group doesn't currently own any code-oriented repos.

If it is acceptable for it to be openstack/microversion-parse then
let's do that. If it can't, because it is not "official", then it's
also fine for it to be in the 'x' namespace. The main signifier (to
me) is the domain name, and with that changing anyway, the rest of
it doesn't really signify.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From thierry at openstack.org  Wed Apr 17 10:10:04 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 17 Apr 2019 12:10:04 +0200
Subject: [Release-job-failures] Release of openstack/solum failed
In-Reply-To: <E1hGaDR-0007Uq-Bx@zuul01.openstack.org>
References: <E1hGaDR-0007Uq-Bx@zuul01.openstack.org>
Message-ID: <415605cf-ba81-d4ed-a76b-63ad1fb44a64@openstack.org>

zuul at openstack.org wrote:
> Build failed.
> 
> - release-openstack-python http://logs.openstack.org/19/19a7574237f44807b16c37e0983223ff57340ba3/release/release-openstack-python/769f856/ : POST_FAILURE in 4m 40s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED

Solum release post-job (triggered by stable/pike 5.4.1 tagging) failed 
with the following error:

Ensure twine is installed:
[
     "python3",
     "-m",
     "pip",
     "install",
     "twine!=1.12.0",
     "readme_renderer[md]!=23.0",
     "requests-toolbelt!=0.9.0",
     "--user"
]
Can not perform a '--user' install. User site-packages are not visible 
in this virtualenv.

http://logs.openstack.org/19/19a7574237f44807b16c37e0983223ff57340ba3/release/release-openstack-python/769f856/ara-report/result/163bcef4-584f-4f51-8b40-6c45d4e2282a/

This seems to be a new error hitting us recently (also happened for 
networking-arista, which the release management team does not directly 
handle). It is weird since the job (exact same command) worked in 
subsequent runs:

http://logs.openstack.org/d0/d0d2089455efb6d01a1158bad597f42cf2306c30/release/release-openstack-python/3e92184/ara-report/result/6f1ee497-f721-4f01-80f0-14ea0835cebe/

-- 
Thierry Carrez (ttx)


From chkumar246 at gmail.com  Wed Apr 17 10:31:00 2019
From: chkumar246 at gmail.com (Chandan kumar)
Date: Wed, 17 Apr 2019 16:01:00 +0530
Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update
 XIX - Apr 16, 2019
Message-ID: <CAMzQOdnNZXUfriBCoKUuz9z1h6RY5JoEe+ci52yGM3Mk4WnjzA@mail.gmail.com>

Hello,

Here is the 19th update (Apr 10 to Apr 06, 2019) on collaboration
on os_tempest[1] role between TripleO and OpenStack-Ansible projects.

Highlights of the week:
* os_tempest user guide is now published here:
  https://docs.openstack.org/openstack-ansible-os_tempest/stein/user/index.html
* os_tempest role now have debian support.
* In tripleo side, all standalone and standalone scenario [1-4]
periodics jobs are
  consuming os_tempest to run tempest in CI

Thanks to mnaser for debian support, mkopec, noonedeadpunk for user guide &
Arx for porting all standalone periodic jobs to os_tempest

Things got merged:
os_tempest:
* os_tempest user guide: https://review.openstack.org/644570
* debian: add ci and update meta : https://review.openstack.org/652346

tripleo:
* Port base standalone job to os_tempest - https://review.rdoproject.org/r/20061
* Port standalone scenario01 to os_tempest -
https://review.rdoproject.org/r/19916
* Port scenario002-standalone-master to os_tempest -
https://review.rdoproject.org/r/20059
* Port scenario003-standalone-master to os_tempest -
https://review.rdoproject.org/r/20037
* Port scenario004-standalone-master to os_tempest -
https://review.rdoproject.org/r/20140
* Port standalone full tempest job to os_tempest -
https://review.rdoproject.org/r/20203

Things in Progress:
os_tempest:
* Make smoke tests as a default whitelist tests -
https://review.openstack.org/652060
* Enable support for novajoin tempest plugin -
https://review.openstack.org/652986

tripleo:
* Enable os_tempest in baremetal-full-overcloud-validate playbook -
https://review.openstack.org/652983
* Run novajoin tempest tests in all TLS job using os_tempest -
https://review.openstack.org/639324

What's coming?
Once we have tripleo master promotion, we will update the tripleo ci
upstream job config to os_tempest
We will be continue working on current os_tempest patches.

Here is the 18th update [2]. Have queries, Feel free to ping us on
#tripleo or #openstack-ansible channel.

Links:
[1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest
[2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004878.html

Thanks,

Chandan Kumar


From chkumar246 at gmail.com  Wed Apr 17 10:32:37 2019
From: chkumar246 at gmail.com (Chandan kumar)
Date: Wed, 17 Apr 2019 16:02:37 +0530
Subject: [tripleo][openstack-ansible] collaboration on os_tempest role
 update XIX - Apr 16, 2019
In-Reply-To: <CAMzQOdnNZXUfriBCoKUuz9z1h6RY5JoEe+ci52yGM3Mk4WnjzA@mail.gmail.com>
References: <CAMzQOdnNZXUfriBCoKUuz9z1h6RY5JoEe+ci52yGM3Mk4WnjzA@mail.gmail.com>
Message-ID: <CAMzQOd=6U5yekrW+iTMZUPkFm_hYz1Y5R5AaQB9tKMFFPrNKjg@mail.gmail.com>

On Wed, Apr 17, 2019 at 4:01 PM Chandan kumar <chkumar246 at gmail.com> wrote:
>
> Hello,
>
> Here is the 19th update (Apr 10 to Apr 06, 2019) on collaboration

Ah, small typo (Apr 10 to Apr 16, 2019)
> on os_tempest[1] role between TripleO and OpenStack-Ansible projects.
>
> Highlights of the week:
> * os_tempest user guide is now published here:
>   https://docs.openstack.org/openstack-ansible-os_tempest/stein/user/index.html
> * os_tempest role now have debian support.
> * In tripleo side, all standalone and standalone scenario [1-4]
> periodics jobs are
>   consuming os_tempest to run tempest in CI
>
> Thanks to mnaser for debian support, mkopec, noonedeadpunk for user guide &
> Arx for porting all standalone periodic jobs to os_tempest
>
> Things got merged:
> os_tempest:
> * os_tempest user guide: https://review.openstack.org/644570
> * debian: add ci and update meta : https://review.openstack.org/652346
>
> tripleo:
> * Port base standalone job to os_tempest - https://review.rdoproject.org/r/20061
> * Port standalone scenario01 to os_tempest -
> https://review.rdoproject.org/r/19916
> * Port scenario002-standalone-master to os_tempest -
> https://review.rdoproject.org/r/20059
> * Port scenario003-standalone-master to os_tempest -
> https://review.rdoproject.org/r/20037
> * Port scenario004-standalone-master to os_tempest -
> https://review.rdoproject.org/r/20140
> * Port standalone full tempest job to os_tempest -
> https://review.rdoproject.org/r/20203
>
> Things in Progress:
> os_tempest:
> * Make smoke tests as a default whitelist tests -
> https://review.openstack.org/652060
> * Enable support for novajoin tempest plugin -
> https://review.openstack.org/652986
>
> tripleo:
> * Enable os_tempest in baremetal-full-overcloud-validate playbook -
> https://review.openstack.org/652983
> * Run novajoin tempest tests in all TLS job using os_tempest -
> https://review.openstack.org/639324
>
> What's coming?
> Once we have tripleo master promotion, we will update the tripleo ci
> upstream job config to os_tempest
> We will be continue working on current os_tempest patches.
>
> Here is the 18th update [2]. Have queries, Feel free to ping us on
> #tripleo or #openstack-ansible channel.
>
> Links:
> [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest
> [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004878.html
>

Thanks,

Chandan Kumar


From cjeanner at redhat.com  Wed Apr 17 11:09:48 2019
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Wed, 17 Apr 2019 13:09:48 +0200
Subject: [Neutron][TripleO] Avoid dangling sidecars containers - add hook
 support
Message-ID: <19517c9e-c198-a4d9-abf9-b3a078beb044@redhat.com>

Dear List,

While doing some validations on an "in-use" node, we detected a
container being Exited with status 137. After some researches and
discussions, it appears this container is launched from a Neutron
container, as a sidecar, and then the service is killed:

https://github.com/openstack/neutron/blob/master/neutron/agent/linux/external_process.py#L98

While the "kill" is fine outside of a container, it leads to some issues
in a containerized world:
- dangling container is here, with a failed state
- validating container state is therefore complicated
- might lead to false assumption if we don't know that "kill" process
- might lead to disk space issues

In order to sort that bad situation out, and prevent disk space issues
and the like, I propose to discuss about some "hook" addition in that
"external_process.py" (or wherever is more suited for that usage)

There is apparently something like that for the service launch, since
there are wrapper scripts in /var/lib/neutron.
In my idea, that wrapper script could generate a new wrapper used in
order to actually delete the container (instead of kill -9 <pid>).

The neutron code could be modified in a simple way, something like:
###############
if os.path.exists(<wrapper-file>):
  utils.execute(['bash', <wrapper-file>])
else:
# current way to handle things
###############

The <wrapper-file> might have "something" in its name in order to ensure
we're actually killing the right process/container.
self.pid, or maybe some specific string that neutron is aware of... you
get the idea.

Even outside of a container, that might be used in order to clean
temporary configurations/files, and ensure we're actually facing a clean
environment.
It's really something more like "hooks" than "container-centric thingy"

Would you consider that kind of new feature?

Thank you for your time and consideration!

Cheers,

C.

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/0864616a/attachment.sig>

From sean.mcginnis at gmx.com  Wed Apr 17 11:26:29 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 17 Apr 2019 06:26:29 -0500
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3, 2019-9-4
 NYC
In-Reply-To: <76AB0248-2FB7-4240-BABB-48AC2C8CAB93@demarco.com>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
 <76AB0248-2FB7-4240-BABB-48AC2C8CAB93@demarco.com>
Message-ID: <20190417112628.GA11604@sm-xps>

On Tue, Apr 16, 2019 at 10:52:48PM +0200, Amy Marrich wrote:
> Chris,
>
> Just wanted to thank you and Bloomberg for extending this offer to the community!
>
> Amy (spotz)
>

+1

Thanks for pulling this together Chris and thanks to Bloomberg for being
willing to host. I think this would be a great location for an ops meetup.

Sean



From mvanwinkle at salesforce.com  Wed Apr 17 11:46:03 2019
From: mvanwinkle at salesforce.com (Matt Van Winkle)
Date: Wed, 17 Apr 2019 06:46:03 -0500
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3,
 2019-9-4 NYC
In-Reply-To: <20190417112628.GA11604@sm-xps>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
 <76AB0248-2FB7-4240-BABB-48AC2C8CAB93@demarco.com>
 <20190417112628.GA11604@sm-xps>
Message-ID: <CA+eV8ig9x8XeTzWbHPdy0xu2obpVK3CzERrUstZp3KvWDcEErg@mail.gmail.com>

On Wed, Apr 17, 2019 at 6:29 AM Sean McGinnis <sean.mcginnis at gmx.com> wrote:

> On Tue, Apr 16, 2019 at 10:52:48PM +0200, Amy Marrich wrote:
> > Chris,
> >
> > Just wanted to thank you and Bloomberg for extending this offer to the
> community!
> >
> > Amy (spotz)
> >
>
> +1
>
> Thanks for pulling this together Chris and thanks to Bloomberg for being
> willing to host. I think this would be a great location for an ops meetup.
>
> Sean
>
>
> Agreed all around.  I can also vouch that Bloomberg was a wonderful host
when we had the Ops meetup there a few years ago.

VW

-- 
Matt Van Winkle
Senior Manager, Software Engineering | Salesforce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/10114e2f/attachment.html>

From cdent+os at anticdent.org  Wed Apr 17 12:46:34 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 17 Apr 2019 13:46:34 +0100 (BST)
Subject: [placement][ptg] Allocation Partitioning
In-Reply-To: <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
References: <alpine.OSX.2.11.1904081452240.9091@seed.local>
 <18afa504-b013-37f5-1158-8d350b5808c4@gmail.com>
 <m2tveyyll0.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904161725080.4039@cdent-a01.vmware.com>
 <m2lg09zwg6.fsf@caffeine.hv.danplanet.com>
 <c89dc1d3-dc1e-b90a-e863-8a004985b737@gmail.com>
 <ebbdb06c-fd14-9879-282d-1bc1912c56ef@gmail.com>
 <alpine.OSX.2.21.1904161952070.4039@cdent-a01.vmware.com>
Message-ID: <alpine.OSX.2.21.1904171343340.17967@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Chris Dent wrote:

> And most importantly, no volunteers for the work. Interested?
>
> Ideally, if we want to do this in Train, we'd have someone owning this
> before the PTG.

I've made a story for this: https://storyboard.openstack.org/#!/story/2005473

The first task on it is to create a spec. If you want to do that,
assign yourself.

As stated in the contributing docs [1] not all features will require
a spec, but as things one has several undecided features and a fair
few alternatives as spec seems reasonable.

[1] https://docs.openstack.org/placement/latest/contributor/contributing.html#new-features

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Wed Apr 17 13:32:54 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 17 Apr 2019 14:32:54 +0100 (BST)
Subject: [placement][ptg] Resource Provider Partitioning
In-Reply-To: <m25zrdzntx.fsf@caffeine.hv.danplanet.com>
References: <alpine.OSX.2.11.1904081436290.9091@seed.local>
 <b117313d-3410-a3fa-c064-988ce91d2810@gmail.com>
 <m2pnplzzp2.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162015380.4039@cdent-a01.vmware.com>
 <m2d0llzqfs.fsf@caffeine.hv.danplanet.com>
 <alpine.OSX.2.21.1904162127500.4039@cdent-a01.vmware.com>
 <m25zrdzntx.fsf@caffeine.hv.danplanet.com>
Message-ID: <alpine.OSX.2.21.1904171428360.17967@cdent-a01.vmware.com>

On Tue, 16 Apr 2019, Dan Smith wrote:

>> For completeness, your preference would be something more like the
>> way we do incomplete project and user for allocations that pre-dated
>> consumers? Make an explicit default (and configurable) shard uuid
>> and migrate to that?
>
> Yup.

I've made a story for this one too https://storyboard.openstack.org/#!/story/2005474

Again, the first task is to create a spec. If someone is
interested in taking on this work, please assign yourself.

If nobody assigns themselves, it most likely won't happen in Train
unless we come up with a magical time or clone or both machine.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From juliaashleykreger at gmail.com  Wed Apr 17 13:36:51 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 17 Apr 2019 06:36:51 -0700
Subject: [ironic] Stepping down from core
In-Reply-To: <2c707b00-08d2-96e2-056f-1e9ee4daa884@redhat.com>
References: <TYXPR01MB1568525B894BC6A30EAEE93CEB250@TYXPR01MB1568.jpnprd01.prod.outlook.com>
 <2c707b00-08d2-96e2-056f-1e9ee4daa884@redhat.com>
Message-ID: <CAF7gwdhH7Ozb=EiRSVCb8eUqLuLrHqDc3=LYKG=24qLJugnMwg@mail.gmail.com>

Greetings Hironori,

Thank you for your hard work and contributions to Ironic! It was great
working with you and I hope to work with you again in the future. Good
luck on your next challenge!

-Julia

On Wed, Apr 17, 2019 at 12:52 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> Hi Hironori,
>
> It was great to work with you all this time. Thank you for your invaluable
> contributions, and good luck with your new challenge!
>
> Dmitry
>
> On 4/17/19 9:43 AM, shiina.hironori at fujitsu.com wrote:
> > Hi ironic folks,
> >
> > I'm sorry for my long absence. My job responsibility changed last November. Since it,
> > I have been trying to spend some time on the core activity. But, I couldn't. So, I'm
> > stepping down from the ironic core team.
> >
> > Thank you for accepting me to the team even though I didn't often appear in IRC due
> > to the time difference. I hope I will work with you again someday.
> >
> > Best regards,
> > Hironori
> >
> >
>
>


From jim at jimrollenhagen.com  Wed Apr 17 14:32:06 2019
From: jim at jimrollenhagen.com (Jim Rollenhagen)
Date: Wed, 17 Apr 2019 10:32:06 -0400
Subject: Migrating git repos to OpenDev
In-Reply-To: <CAH=wFzTpwpiU_bGOe7n9+A5RYZSs=mDsgq+r-OtLFP5zk2je3A@mail.gmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <CAH=wFzTpwpiU_bGOe7n9+A5RYZSs=mDsgq+r-OtLFP5zk2je3A@mail.gmail.com>
Message-ID: <CAJCXu8fKZvfGd8PWNq2z-OiUHwWeScNM87CwfZK=GyPhDGe05w@mail.gmail.com>

On Wed, Apr 17, 2019 at 12:12 AM Takashi Yamamoto <yamamoto at midokura.com>
wrote:

> On Wed, Apr 17, 2019 at 9:16 AM Clark Boylan <cboylan at sapwetik.org> wrote:
> > [snip]
> >
> > Fungi has generated a master list of project renames for the openstack
> namespaces: http://paste.openstack.org/show/749402/. If you have a moment
> please quickly review these planned renames for any obvious errors or
> issues.
>
> i guess networking-l2gw-tempest-plugin should go to the same namespace
> with networking-l2gw.
>

+1, this should take care of it: https://review.openstack.org/#/c/653449/

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/5b4d5e03/attachment.html>

From jungleboyj at gmail.com  Wed Apr 17 14:51:03 2019
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 17 Apr 2019 09:51:03 -0500
Subject: [cinder] Proposing Brian Rosmaita for Core ...
Message-ID: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>

Team,

I would like to propose Brian Rosmaita for Cinder core.

His participation in Cinder has been steadily increasing during the 
Stein release.  He attended the mid-cycle meeting in Raleigh and was 
able to provide great insight and input using his experience from Glance.

His review activity has been consistent during Stein.  He has helped get 
backports to our stable branches and subsequently has ensured that we do 
timely releases of Cinder's components.

Considering the broad range of activity Brian has demonstrated and his 
years of experience in OpenStack I think he will serve as an excellent 
addition to our core team.

If I do not hear any concerns with this nomination I will make Brian 
core on 4/24.

Thank you!

Jay




From cdent+os at anticdent.org  Wed Apr 17 15:09:01 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 17 Apr 2019 16:09:01 +0100 (BST)
Subject: [placement][ptg] JSON payload for GET /a_c
In-Reply-To: <alpine.OSX.2.11.1904081645350.9091@seed.local>
References: <alpine.OSX.2.11.1904081645350.9091@seed.local>
Message-ID: <alpine.OSX.2.21.1904171525540.19741@cdent-a01.vmware.com>

On Mon, 8 Apr 2019, Chris Dent wrote:

> * would make things like "resource provider affinity" above easier.
>  much easier. and let us express granular-ness less awkwardly, and
>  let us add new and richer group_policy concepts (which is
>  basically the affinity thing).
>
>    * Brought up briefly in the above spec at
>      https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst at 184
>
> As clients making GET /allocation_candidates queries desire to
> express more and more complexity [2], query parameters start to feel
> cumbersome. At various times people have suggest that a JSON body
> might be easier to manage. The first time was during the discussion
> that resulted in the creation of the allocation_candidates resource.

In one of the other threads yesterday, Eric and I were batting about
terms like "unified solution" and "unified theory" [1]. I was trying to
suggest that if we could come up with a grand unified theory of
nested resource providers that would make it easier for us to come
up with a solution to the various nested goals that are on the go
right now. One that feels consistent and sensible.

I think there's still room for discussion on that tack, on that thread,
despite it seeming a bit stalled out, but wanted to also try a different
approach over here, to see if it might be productive:

Suppose we did have an in-body JSON syntax to make topologically complex
queries for allocation candidates. Would it be able to provide both
a unified solution and a unified theory of nested operation? If so,
that (especially the latter) would be a pretty compelling reason to
have it, despite my other reservations.

Ideas?

A naive model would be to represent a graph of resource requirements
in JSON and then search for branches of trees which are coincident
with that graph. In its most naive form this would not easily
represent requirements where arbitrarily large gaps, either
parent or sibling-oriented in the graph, may acceptably satisfy a
query. That is, there are intervening structural providers that
"don't matter" to the requester.

The problem expressed there is a derivation of some of the problems
we've been expressing elsewhere (things like the need to use
references to other resource group identifiers in the values of
query parameters). Presumably the solution is similar in either
context.

Pushing out a bit, if we went for a syntax like GraphQL, the same
problem will be present there, but I would expect recursive or
gapped queries to be a thing that community has addressed. Does
anyone know?

To add a little more clarity on the concept of "unified theory of
operation", if we had one it would be the case that when anyone
introduced a new idea we could see how it felt with regard to the
theory and say, quickly/intuitively, "yeah that fits" or "no that
doesn't fit". That we have the following:

* some people who think that a theory exists, but it is a different
   theory from some other people who also think that a theory exists

* some people who are involved regularly who don't think a theory
   exists

suggests that things could be better and despite how annoying
talking it out might seem, it's useful.

The theory doesn't have to mean that everything is explained and
decided. Nor does it mean that things cannot change. It's simply a
set of contextual constraints, which if present would probably help
us move things long more quickly than we have a history of doing.

It also doesn't mean we can't do things piecemeal. We must be able
to do piecemeal and be able to change things later. The theory helps
provide some boundaries or encapsulation.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.html

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From gmann at ghanshyammann.com  Wed Apr 17 15:23:08 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 17 Apr 2019 10:23:08 -0500
Subject: Migrating git repos to OpenDev
In-Reply-To: <alpine.OSX.2.21.1904171034230.14914@cdent-a01.vmware.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
 <16a291e8818.b2a0ab2f16578.5918920171050047498@ghanshyammann.com>
 <alpine.OSX.2.21.1904171034230.14914@cdent-a01.vmware.com>
Message-ID: <16a2be4fcf1.f2c717f442006.4148727453857786644@ghanshyammann.com>

 ---- On Wed, 17 Apr 2019 04:45:18 -0500 Chris Dent <cdent+os at anticdent.org> wrote ----
 > On Tue, 16 Apr 2019, Ghanshyam Mann wrote: 
 >  
 > > I found one more which need to be placed somewhere in openstack/ 
 > > 
 > > - microversion-parse - this lib is used by many projects for API microversion parsing.  maybe cdent can suggest. 
 >  
 > When microversion-parse was first put together it wasn't put under 
 > an official project for three reasons: 
 >  
 > * Make it accessible to anything outside the OpenStack world that 
 >    might like to work with microversion (if ever such a thing cae to 
 >    exist). 
 >  
 > * Make it crystal clear that the library was just a thing you 
 >    install from PyPI, no big deal. 
 >  
 > * Couldn't decide anywhere to put it. 
 >  
 > We're essentially still in that boat, but what's changed, at least a 
 > bit, is that it's increasingly easy to think of things born in the 
 > OpenStack world as just things you can install from PyPI. 
 >  
 > All of which is a long way of saying I don't really have any good 
 > suggestions. 
 >  
 > The current core group is made up of members of the API-SIG but that 
 > group doesn't currently own any code-oriented repos. 
 >  
 > If it is acceptable for it to be openstack/microversion-parse then 
 > let's do that. If it can't, because it is not "official", then it's 
 > also fine for it to be in the 'x' namespace. The main signifier (to 
 > me) is the domain name, and with that changing anyway, the rest of 
 > it doesn't really signify. 

Thanks Chris for detail information. As it is very close and OpenStack-only-used lib,
For long term maintenance, it will be good if it stay under openstack. and if we want to
extend it with more common classes like APIVersionRequest thing[1]

Moving to oslo can be one idea to discuss. 

If you would like to keep it under openstack/ till opendev-transition, you can add
this in this ethercal[2] and after that, we can discuss to propose under some
official project like oslo etc ?

[1]  https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/api_version_request.py#n231
[2] https://ethercalc.openstack.org/opendev-transition

-gmann

 >  
 > --  
 > Chris Dent                       ٩◔̯◔۶           https://anticdent.org/ 
 > freenode: cdent                                         tw: @anticdent



From anteaya at anteaya.info  Wed Apr 17 15:24:37 2019
From: anteaya at anteaya.info (Anita Kuno)
Date: Wed, 17 Apr 2019 11:24:37 -0400
Subject: [all] Gerrit will be offline April 19, 2019
In-Reply-To: <577b43b5-b17a-4f01-22a6-c0e6018c5dca@anteaya.info>
References: <577b43b5-b17a-4f01-22a6-c0e6018c5dca@anteaya.info>
Message-ID: <2512febe-6f17-c0f2-82b1-03219b98a31e@anteaya.info>

On 2019-04-12 12:48 p.m., Anita Kuno wrote:
> Specific start time for the outage will be posted to this thread when it 
> is decided next week.

The outage is scheduled to begin at 1500 UTC.

Thank you,
Anita


From e0ne at e0ne.info  Wed Apr 17 15:29:38 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Wed, 17 Apr 2019 18:29:38 +0300
Subject: Does anyone care about reviewstats?
In-Reply-To: <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
 <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
Message-ID: <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>

I use it but not for a regular basis at the moment.

Do we have any kind of official place where its results are published?

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


On Wed, Apr 17, 2019 at 12:22 AM <Arkady.Kanevsky at dell.com> wrote:

> I do use it
>
> -----Original Message-----
> From: Ben Nemec <openstack at nemebean.com>
> Sent: Tuesday, April 16, 2019 2:35 PM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: Does anyone care about reviewstats?
>
>
> [EXTERNAL EMAIL]
>
>
>
> On 3/12/19 10:01 AM, Ben Nemec wrote:
> >
> >
> > On 3/12/19 8:54 AM, Matt Riedemann wrote:
> >> There are open reviewstats changes [1] but the non-infra core team is
> >> entirely made up of people that no longer work on openstack [2]. I
> >> had a change that was open so long some of the projects are now owned
> >> by placement [3] so I just abandoned it.
> >>
> >> So the question is, does anyone use reviewstats anymore? If so, we
> >> should probably just start adding new people to the core team that
> >> actually use it. Otherwise we should probably just put it in the
> >> attic and rely on stackalytics (which is probably what most people
> >> are already doing).
> >
> > I am still using it. I have a local change that pulls the project list
> > from governance instead of the manually curated lists in reviewstats
> > which reduces the maintenance burden somewhat. I'm not sure if it
> > works for all projects though. I mostly use it for the Oslo stats
> > these days and my all projects page hasn't been updated in almost two
> > years. I suspect that's because of errors when it tries to process
> > everything, but I haven't really dug into it.
> >
> > So I'm happy to push up my changes, but they may cause other people
> > issues. Of course, given how out of date I suspect the project lists
> > in reviewstats are I'm not sure how much worse I could make it. I
> > doubt the numbers it spits out right now are terribly accurate anyway.
>
> The stackalytics thread prompted me to clean this up and push it to
> gerrit: https://review.openstack.org/#/c/653024
>
> It should help a lot with maintainability of the project lists, although I
> haven't investigated how many mismatches there are between the json files
> and governance. Probably a lot.
>
> >
> >>
> >> [1]
> >> https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
> >> status:open
> >>
> >> [2] https://review.openstack.org/#/admin/groups/893,members
> >> [3] https://review.openstack.org/#/c/499197/
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/1397413e/attachment.html>

From zbitter at redhat.com  Wed Apr 17 15:38:39 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Wed, 17 Apr 2019 11:38:39 -0400
Subject: [keystone][heat] security_compliance options and auto-created
 users
In-Reply-To: <CACfB1uvuOkqNx49148axje6Y-pMnr-bZtSZsyeQbZn9L9_WboQ@mail.gmail.com>
References: <CACfB1uvuOkqNx49148axje6Y-pMnr-bZtSZsyeQbZn9L9_WboQ@mail.gmail.com>
Message-ID: <7c744974-a22d-517b-765d-d5ea9912d953@redhat.com>

On 16/04/19 6:38 AM, Pavlo Shchelokovskyy wrote:
> Hi all,
> 
> I am currently looking at options defined in [security_compliance] 
> section of keystone.conf [0] and trying to understand how enabling those 
> security features may affect other services.
> 
> The first thing I see is that any project that auto-creates some 
> temporary users may be affected.
> Of the top of my head I can recall only Heat and Tempest doing this.
> For Tempest situation is easier as a) tempest can use static credentials 
> instead of dynamic ones so it is possible to craft appropriate users 
> beforehand and b) those users are relatively short-lived (required for 
> limited time).
> In case of Heat though those users are used for deferred auth (like in 
> autoscaling) which for long lived stacks can happen at arbitrary time in 
> future - which is a problem.
> 
> Below is breakdown of options/features possible to set and what problems 
> that may pose for Heat and ideas on how to work those around:
> 
> - disable_user_account_days_inactive - this may pose a problem for 
> deferred auth, and it seems is not possible to override it via user 
> "options". IMO there's a need to add a new user option to Keystone to 
> ignore this setting for given user, and then use it in Heat to create 
> temporary users.

+1

> - lockout failure options (lockout_failure_attempts, lockout_duration) - 
> can be overridden by user option, but Heat has to set it first. Also the 
> question remains how realistically such problem may arise for an 
> auto-created internal user and whether Heat should set this option at all

Sounds like a DoS waiting to happen if we don't override.

> - password expiry options 
> (password_expires_days, unique_last_password_count, minimum_password_age) - 
> poses a problem for deferred auth, but can be overridden by user option, 
> so Heat should definitely set it IMO for users it creates

+1

> - change_password_upon_first_use - poses problem for auto-generated 
> users, can be overridden by a user option, but Heat must set it for its 
> generated users

+1

> - password strength enforcement 
> (password_regex, password_regex_description) - now this is an 
> interesting one. Currently Heat creates passwords for its temporary 
> users with this function [1] falling back to empty password if a 
> resource is not generating one for itself. Depending on regex_password 
> setting in keystone, it may or may not be enough to pass the password 
> strength check.

This is technically true, although I implemented it so it should pass 
all but the most brain-dead of policies. So I feel like doing nothing is 
a valid option ;)

> I've looked around and (as expected) generating a random string which 
> satisfies a pre-defined arbitrary regex is quite a non-trivial task, 
> couple of existing Python libraries that can do this note that they 
> support only a limited subset of full regex spec.

Yeah. If we're going to do it I think a more achievable way is by making 
the current generator's rules (which essentially consist of a length 
plus minimum counts of characters from particular classes) configurable 
instead of hard-coded. I always assumed that we might eventually do 
this, but didn't build it in at the start because the patch needed to be 
backported.

This is still pretty terrible because it's a configuration option the 
operator has to set to match keystone's, and in a different format to 
boot. Although, TBH a regex isn't a great choice for how to configure it 
in keystone either - it's trivial if you want to force the user to 
always use the password "password", but if you want to force the user to 
e.g. have both uppercase and lowercase characters then you have to do 
all kinds of weird lookahead assertions that require a PhD in Python's 
specific flavour of regexps.

As long as we don't try to do something like 
https://review.openstack.org/436324

Note that Heat has it's own requirements too - one that I discovered is 
that the passwords can't contain '$' because of reasons.

> So it seems that a most simple solution would be to add yet another user 
> option to Keystone to ignore password strength enforcement for this 
> given user, and amend Heat to set this option as well for internal users 
> it creates.

That also works.

> We in Heat may also think as to whether it would have any benefit to 
> also set the 'lock_password' user option for the auto-created users 
> which will prohibit such users to change their passwords via API themselves.

I can't think of any real benefit - or for that matter any real harm. 
Presumably Heat itself would still be able to change the account's 
password later, so it wouldn't stop us from implementing some sort of 
rotation thing in the future.

> I'd very like to hear opinion from Keystone community as most solutions 
> I named are 'add new user option to Keystone' :-)
> 
> [0] 
> https://opendev.org/openstack/keystone/src/branch/master/keystone/conf/security_compliance.py
> [1] 
> https://opendev.org/openstack/heat/src/branch/master/heat/common/password_gen.py#L112
> 
> Cheers,
> - Pavlo
> -- 
> Dr. Pavlo Shchelokovskyy
> Principal Software Engineer
> Mirantis Inc
> www.mirantis.com <http://www.mirantis.com>



From eionel at mirantis.com  Wed Apr 17 15:40:18 2019
From: eionel at mirantis.com (Edward Ionel)
Date: Wed, 17 Apr 2019 08:40:18 -0700
Subject: Does anyone care about reviewstats?
In-Reply-To: <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
 <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
 <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
Message-ID: <F416D3AB-8DF8-4D5E-A1BA-5A624A76C628@mirantis.com>

Www. Stackayltics.com publish all types of stats:) 

Sent from my iPhone

> On Apr 17, 2019, at 8:29 AM, Ivan Kolodyazhny <e0ne at e0ne.info> wrote:
> 
> I use it but not for a regular basis at the moment.
> 
> Do we have any kind of official place where its results are published?
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> 
>> On Wed, Apr 17, 2019 at 12:22 AM <Arkady.Kanevsky at dell.com> wrote:
>> I do use it
>> 
>> -----Original Message-----
>> From: Ben Nemec <openstack at nemebean.com> 
>> Sent: Tuesday, April 16, 2019 2:35 PM
>> To: openstack-discuss at lists.openstack.org
>> Subject: Re: Does anyone care about reviewstats?
>> 
>> 
>> [EXTERNAL EMAIL] 
>> 
>> 
>> 
>> On 3/12/19 10:01 AM, Ben Nemec wrote:
>> > 
>> > 
>> > On 3/12/19 8:54 AM, Matt Riedemann wrote:
>> >> There are open reviewstats changes [1] but the non-infra core team is 
>> >> entirely made up of people that no longer work on openstack [2]. I 
>> >> had a change that was open so long some of the projects are now owned 
>> >> by placement [3] so I just abandoned it.
>> >>
>> >> So the question is, does anyone use reviewstats anymore? If so, we 
>> >> should probably just start adding new people to the core team that 
>> >> actually use it. Otherwise we should probably just put it in the 
>> >> attic and rely on stackalytics (which is probably what most people 
>> >> are already doing).
>> > 
>> > I am still using it. I have a local change that pulls the project list 
>> > from governance instead of the manually curated lists in reviewstats 
>> > which reduces the maintenance burden somewhat. I'm not sure if it 
>> > works for all projects though. I mostly use it for the Oslo stats 
>> > these days and my all projects page hasn't been updated in almost two 
>> > years. I suspect that's because of errors when it tries to process 
>> > everything, but I haven't really dug into it.
>> > 
>> > So I'm happy to push up my changes, but they may cause other people 
>> > issues. Of course, given how out of date I suspect the project lists 
>> > in reviewstats are I'm not sure how much worse I could make it. I 
>> > doubt the numbers it spits out right now are terribly accurate anyway.
>> 
>> The stackalytics thread prompted me to clean this up and push it to
>> gerrit: https://review.openstack.org/#/c/653024
>> 
>> It should help a lot with maintainability of the project lists, although I haven't investigated how many mismatches there are between the json files and governance. Probably a lot.
>> 
>> > 
>> >>
>> >> [1]
>> >> https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
>> >> status:open
>> >>
>> >> [2] https://review.openstack.org/#/admin/groups/893,members
>> >> [3] https://review.openstack.org/#/c/499197/
>> >>
>> > 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/06fcf47f/attachment-0001.html>

From cdent+os at anticdent.org  Wed Apr 17 15:53:35 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Wed, 17 Apr 2019 16:53:35 +0100 (BST)
Subject: Migrating git repos to OpenDev
In-Reply-To: <16a2be4fcf1.f2c717f442006.4148727453857786644@ghanshyammann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <16a290f21b0.1029b8b1416478.3983663153618736876@ghanshyammann.com>
 <16a291e8818.b2a0ab2f16578.5918920171050047498@ghanshyammann.com>
 <alpine.OSX.2.21.1904171034230.14914@cdent-a01.vmware.com>
 <16a2be4fcf1.f2c717f442006.4148727453857786644@ghanshyammann.com>
Message-ID: <alpine.OSX.2.21.1904171651040.20884@cdent-a01.vmware.com>

On Wed, 17 Apr 2019, Ghanshyam Mann wrote:

> If you would like to keep it under openstack/ till opendev-transition, you can add
> this in this ethercal[2] and after that, we can discuss to propose under some
> official project like oslo etc ?

I've added it to the ethercalc with a reference back to this
discussion.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From openstack at nemebean.com  Wed Apr 17 16:02:03 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 17 Apr 2019 11:02:03 -0500
Subject: Does anyone care about reviewstats?
In-Reply-To: <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
 <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
 <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
Message-ID: <9ba4dd9f-0df9-30a1-0754-ca971d865ecd@nemebean.com>



On 4/17/19 10:29 AM, Ivan Kolodyazhny wrote:
> I use it but not for a regular basis at the moment.
> 
> Do we have any kind of official place where its results are published?

Not that I know of. Russell used to run it on his site, but I think he 
changed it to redirect to stackalytics a while back. I publish my output 
to http://nemebean.com/reviewstats/ but it only includes the projects I 
am core on.

> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> 
> On Wed, Apr 17, 2019 at 12:22 AM <Arkady.Kanevsky at dell.com 
> <mailto:Arkady.Kanevsky at dell.com>> wrote:
> 
>     I do use it
> 
>     -----Original Message-----
>     From: Ben Nemec <openstack at nemebean.com
>     <mailto:openstack at nemebean.com>>
>     Sent: Tuesday, April 16, 2019 2:35 PM
>     To: openstack-discuss at lists.openstack.org
>     <mailto:openstack-discuss at lists.openstack.org>
>     Subject: Re: Does anyone care about reviewstats?
> 
> 
>     [EXTERNAL EMAIL]
> 
> 
> 
>     On 3/12/19 10:01 AM, Ben Nemec wrote:
>      >
>      >
>      > On 3/12/19 8:54 AM, Matt Riedemann wrote:
>      >> There are open reviewstats changes [1] but the non-infra core
>     team is
>      >> entirely made up of people that no longer work on openstack [2]. I
>      >> had a change that was open so long some of the projects are now
>     owned
>      >> by placement [3] so I just abandoned it.
>      >>
>      >> So the question is, does anyone use reviewstats anymore? If so, we
>      >> should probably just start adding new people to the core team that
>      >> actually use it. Otherwise we should probably just put it in the
>      >> attic and rely on stackalytics (which is probably what most people
>      >> are already doing).
>      >
>      > I am still using it. I have a local change that pulls the project
>     list
>      > from governance instead of the manually curated lists in reviewstats
>      > which reduces the maintenance burden somewhat. I'm not sure if it
>      > works for all projects though. I mostly use it for the Oslo stats
>      > these days and my all projects page hasn't been updated in almost
>     two
>      > years. I suspect that's because of errors when it tries to process
>      > everything, but I haven't really dug into it.
>      >
>      > So I'm happy to push up my changes, but they may cause other people
>      > issues. Of course, given how out of date I suspect the project lists
>      > in reviewstats are I'm not sure how much worse I could make it. I
>      > doubt the numbers it spits out right now are terribly accurate
>     anyway.
> 
>     The stackalytics thread prompted me to clean this up and push it to
>     gerrit: https://review.openstack.org/#/c/653024
> 
>     It should help a lot with maintainability of the project lists,
>     although I haven't investigated how many mismatches there are
>     between the json files and governance. Probably a lot.
> 
>      >
>      >>
>      >> [1]
>      >>
>     https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
>      >> status:open
>      >>
>      >> [2] https://review.openstack.org/#/admin/groups/893,members
>      >> [3] https://review.openstack.org/#/c/499197/
>      >>
>      >
> 


From sean.mcginnis at gmx.com  Wed Apr 17 16:09:23 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 17 Apr 2019 11:09:23 -0500
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
Message-ID: <20190417160922.GA6130@sm-workstation>

On Wed, Apr 17, 2019 at 09:51:03AM -0500, Jay Bryant wrote:
> Team,
>
> I would like to propose Brian Rosmaita for Cinder core.
>
> His participation in Cinder has been steadily increasing during the Stein
> release.  He attended the mid-cycle meeting in Raleigh and was able to
> provide great insight and input using his experience from Glance.
>
> His review activity has been consistent during Stein.  He has helped get
> backports to our stable branches and subsequently has ensured that we do
> timely releases of Cinder's components.
>
> Considering the broad range of activity Brian has demonstrated and his years
> of experience in OpenStack I think he will serve as an excellent addition to
> our core team.
>
> If I do not hear any concerns with this nomination I will make Brian core on
> 4/24.
>
> Thank you!
>
> Jay
>

Big +1 from me. Thanks for all the work you've been doing Brian. Will be great
having you as core.


From Arkady.Kanevsky at dell.com  Wed Apr 17 16:18:39 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Wed, 17 Apr 2019 16:18:39 +0000
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <20190417160922.GA6130@sm-workstation>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
 <20190417160922.GA6130@sm-workstation>
Message-ID: <7dc40fa5ccec4483841d23696197a425@AUSX13MPS308.AMER.DELL.COM>

+1

-----Original Message-----
From: Sean McGinnis <sean.mcginnis at gmx.com> 
Sent: Wednesday, April 17, 2019 11:09 AM
To: jsbryant at electronicjungle.net
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [cinder] Proposing Brian Rosmaita for Core ...


[EXTERNAL EMAIL] 

On Wed, Apr 17, 2019 at 09:51:03AM -0500, Jay Bryant wrote:
> Team,
>
> I would like to propose Brian Rosmaita for Cinder core.
>
> His participation in Cinder has been steadily increasing during the 
> Stein release.  He attended the mid-cycle meeting in Raleigh and was 
> able to provide great insight and input using his experience from Glance.
>
> His review activity has been consistent during Stein.  He has helped 
> get backports to our stable branches and subsequently has ensured that 
> we do timely releases of Cinder's components.
>
> Considering the broad range of activity Brian has demonstrated and his 
> years of experience in OpenStack I think he will serve as an excellent 
> addition to our core team.
>
> If I do not hear any concerns with this nomination I will make Brian 
> core on 4/24.
>
> Thank you!
>
> Jay
>

Big +1 from me. Thanks for all the work you've been doing Brian. Will be great having you as core.



From Arkady.Kanevsky at dell.com  Wed Apr 17 16:20:03 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Wed, 17 Apr 2019 16:20:03 +0000
Subject: Does anyone care about reviewstats?
In-Reply-To: <9ba4dd9f-0df9-30a1-0754-ca971d865ecd@nemebean.com>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
 <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
 <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
 <9ba4dd9f-0df9-30a1-0754-ca971d865ecd@nemebean.com>
Message-ID: <0d29516589fd41f0857cacaeed45a0bd@AUSX13MPS308.AMER.DELL.COM>

We do need a single tool for all projects.

-----Original Message-----
From: Ben Nemec <openstack at nemebean.com> 
Sent: Wednesday, April 17, 2019 11:02 AM
To: Ivan Kolodyazhny; OpenStack Discuss
Subject: Re: Does anyone care about reviewstats?


[EXTERNAL EMAIL] 



On 4/17/19 10:29 AM, Ivan Kolodyazhny wrote:
> I use it but not for a regular basis at the moment.
> 
> Do we have any kind of official place where its results are published?

Not that I know of. Russell used to run it on his site, but I think he changed it to redirect to stackalytics a while back. I publish my output to http://nemebean.com/reviewstats/ but it only includes the projects I am core on.

> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> 
> On Wed, Apr 17, 2019 at 12:22 AM <Arkady.Kanevsky at dell.com 
> <mailto:Arkady.Kanevsky at dell.com>> wrote:
> 
>     I do use it
> 
>     -----Original Message-----
>     From: Ben Nemec <openstack at nemebean.com
>     <mailto:openstack at nemebean.com>>
>     Sent: Tuesday, April 16, 2019 2:35 PM
>     To: openstack-discuss at lists.openstack.org
>     <mailto:openstack-discuss at lists.openstack.org>
>     Subject: Re: Does anyone care about reviewstats?
> 
> 
>     [EXTERNAL EMAIL]
> 
> 
> 
>     On 3/12/19 10:01 AM, Ben Nemec wrote:
>      >
>      >
>      > On 3/12/19 8:54 AM, Matt Riedemann wrote:
>      >> There are open reviewstats changes [1] but the non-infra core
>     team is
>      >> entirely made up of people that no longer work on openstack [2]. I
>      >> had a change that was open so long some of the projects are now
>     owned
>      >> by placement [3] so I just abandoned it.
>      >>
>      >> So the question is, does anyone use reviewstats anymore? If so, we
>      >> should probably just start adding new people to the core team that
>      >> actually use it. Otherwise we should probably just put it in the
>      >> attic and rely on stackalytics (which is probably what most people
>      >> are already doing).
>      >
>      > I am still using it. I have a local change that pulls the project
>     list
>      > from governance instead of the manually curated lists in reviewstats
>      > which reduces the maintenance burden somewhat. I'm not sure if it
>      > works for all projects though. I mostly use it for the Oslo stats
>      > these days and my all projects page hasn't been updated in almost
>     two
>      > years. I suspect that's because of errors when it tries to process
>      > everything, but I haven't really dug into it.
>      >
>      > So I'm happy to push up my changes, but they may cause other people
>      > issues. Of course, given how out of date I suspect the project lists
>      > in reviewstats are I'm not sure how much worse I could make it. I
>      > doubt the numbers it spits out right now are terribly accurate
>     anyway.
> 
>     The stackalytics thread prompted me to clean this up and push it to
>     gerrit: https://review.openstack.org/#/c/653024
> 
>     It should help a lot with maintainability of the project lists,
>     although I haven't investigated how many mismatches there are
>     between the json files and governance. Probably a lot.
> 
>      >
>      >>
>      >> [1]
>      >>
>     https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
>      >> status:open
>      >>
>      >> [2] https://review.openstack.org/#/admin/groups/893,members
>      >> [3] https://review.openstack.org/#/c/499197/
>      >>
>      >
> 


From Rajini.Karthik at Dell.com  Wed Apr 17 16:29:00 2019
From: Rajini.Karthik at Dell.com (Rajini.Karthik at Dell.com)
Date: Wed, 17 Apr 2019 16:29:00 +0000
Subject: Does anyone care about reviewstats?
In-Reply-To: <0d29516589fd41f0857cacaeed45a0bd@AUSX13MPS308.AMER.DELL.COM>
References: <ed259da7-aa15-09b3-12c6-c3325e7d50f9@gmail.com>
 <d46fa94a-a2ae-54b6-593a-737553469b67@nemebean.com>
 <8f5e9118-7084-5d56-39ae-3524af4c5a23@nemebean.com>
 <be1d318b618c429880926bedaaecb44f@AUSX13MPS308.AMER.DELL.COM>
 <CAGocpaGJsabeW1xHN5dtuChp12GCQnLskzu+_daYzs4kS5_X5g@mail.gmail.com>
 <9ba4dd9f-0df9-30a1-0754-ca971d865ecd@nemebean.com>
 <0d29516589fd41f0857cacaeed45a0bd@AUSX13MPS308.AMER.DELL.COM>
Message-ID: <40833ae8b65a46d38618ff4314c8f05c@AUSX13MPS308.AMER.DELL.COM>

+1

-----Original Message-----
From: Kanevsky, Arkady 
Sent: Wednesday, April 17, 2019 11:20 AM
To: openstack at nemebean.com; e0ne at e0ne.info; openstack-discuss at lists.openstack.org
Subject: RE: Does anyone care about reviewstats?


[EXTERNAL EMAIL] 

We do need a single tool for all projects.

-----Original Message-----
From: Ben Nemec <openstack at nemebean.com> 
Sent: Wednesday, April 17, 2019 11:02 AM
To: Ivan Kolodyazhny; OpenStack Discuss
Subject: Re: Does anyone care about reviewstats?


[EXTERNAL EMAIL] 



On 4/17/19 10:29 AM, Ivan Kolodyazhny wrote:
> I use it but not for a regular basis at the moment.
> 
> Do we have any kind of official place where its results are published?

Not that I know of. Russell used to run it on his site, but I think he changed it to redirect to stackalytics a while back. I publish my output to http://nemebean.com/reviewstats/ but it only includes the projects I am core on.

> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> 
> On Wed, Apr 17, 2019 at 12:22 AM <Arkady.Kanevsky at dell.com 
> <mailto:Arkady.Kanevsky at dell.com>> wrote:
> 
>     I do use it
> 
>     -----Original Message-----
>     From: Ben Nemec <openstack at nemebean.com
>     <mailto:openstack at nemebean.com>>
>     Sent: Tuesday, April 16, 2019 2:35 PM
>     To: openstack-discuss at lists.openstack.org
>     <mailto:openstack-discuss at lists.openstack.org>
>     Subject: Re: Does anyone care about reviewstats?
> 
> 
>     [EXTERNAL EMAIL]
> 
> 
> 
>     On 3/12/19 10:01 AM, Ben Nemec wrote:
>      >
>      >
>      > On 3/12/19 8:54 AM, Matt Riedemann wrote:
>      >> There are open reviewstats changes [1] but the non-infra core
>     team is
>      >> entirely made up of people that no longer work on openstack [2]. I
>      >> had a change that was open so long some of the projects are now
>     owned
>      >> by placement [3] so I just abandoned it.
>      >>
>      >> So the question is, does anyone use reviewstats anymore? If so, we
>      >> should probably just start adding new people to the core team that
>      >> actually use it. Otherwise we should probably just put it in the
>      >> attic and rely on stackalytics (which is probably what most people
>      >> are already doing).
>      >
>      > I am still using it. I have a local change that pulls the project
>     list
>      > from governance instead of the manually curated lists in reviewstats
>      > which reduces the maintenance burden somewhat. I'm not sure if it
>      > works for all projects though. I mostly use it for the Oslo stats
>      > these days and my all projects page hasn't been updated in almost
>     two
>      > years. I suspect that's because of errors when it tries to process
>      > everything, but I haven't really dug into it.
>      >
>      > So I'm happy to push up my changes, but they may cause other people
>      > issues. Of course, given how out of date I suspect the project lists
>      > in reviewstats are I'm not sure how much worse I could make it. I
>      > doubt the numbers it spits out right now are terribly accurate
>     anyway.
> 
>     The stackalytics thread prompted me to clean this up and push it to
>     gerrit: https://review.openstack.org/#/c/653024
> 
>     It should help a lot with maintainability of the project lists,
>     although I haven't investigated how many mismatches there are
>     between the json files and governance. Probably a lot.
> 
>      >
>      >>
>      >> [1]
>      >>
>     https://review.openstack.org/#/q/project:openstack-infra/reviewstats+
>      >> status:open
>      >>
>      >> [2] https://review.openstack.org/#/admin/groups/893,members
>      >> [3] https://review.openstack.org/#/c/499197/
>      >>
>      >
> 


From xingyang105 at gmail.com  Wed Apr 17 17:10:24 2019
From: xingyang105 at gmail.com (Xing Yang)
Date: Wed, 17 Apr 2019 13:10:24 -0400
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
Message-ID: <CADwwA9swoW-kwE3YL6fbvy3Ki1sC=P4wsb+dPZo+225YB1JF7g@mail.gmail.com>

+1

On Wed, Apr 17, 2019 at 10:51 AM Jay Bryant <jungleboyj at gmail.com> wrote:

> Team,
>
> I would like to propose Brian Rosmaita for Cinder core.
>
> His participation in Cinder has been steadily increasing during the
> Stein release.  He attended the mid-cycle meeting in Raleigh and was
> able to provide great insight and input using his experience from Glance.
>
> His review activity has been consistent during Stein.  He has helped get
> backports to our stable branches and subsequently has ensured that we do
> timely releases of Cinder's components.
>
> Considering the broad range of activity Brian has demonstrated and his
> years of experience in OpenStack I think he will serve as an excellent
> addition to our core team.
>
> If I do not hear any concerns with this nomination I will make Brian
> core on 4/24.
>
> Thank you!
>
> Jay
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/8260e8a1/attachment.html>

From dave at medberry.net  Tue Apr 16 21:20:25 2019
From: dave at medberry.net (David Medberry)
Date: Tue, 16 Apr 2019 15:20:25 -0600
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3,
 2019-9-4 NYC
In-Reply-To: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
Message-ID: <CAJhvMSufBX+9tzJPkTwe9ZWVCTzkY=+jpRr3HA50NP5kBh85Pg@mail.gmail.com>

Thanks Bloomberg. Thanks Chris. Thanks New York!

On Tue, Apr 16, 2019 at 2:45 PM Chris Morgan <mihalis68 at gmail.com> wrote:
>
> Hello All,
>   My employer Bloomberg LP would like to offer to host the next OpenStack Ops meetup here in NYC in early September this year. Please see
>
> https://etherpad.openstack.org/p/ops-meetup-2nd-2019
>
> for some early details on this.
>
> All hosting offers are subject to scrutiny by the ops meetups team and the overal community for content, location, timing etc and then approved via a mix of consensus gathering and (if there are multiple offers) voting, see https://wiki.openstack.org/wiki/Ops_Meetups_Team and https://wiki.openstack.org/wiki/Operations/Meetups
>
> Thanks,
>
> Chris
> --
> Chris Morgan <mihalis68 at gmail.com>


From eionel at mirantis.com  Wed Apr 17 03:37:29 2019
From: eionel at mirantis.com (Edward Ionel)
Date: Tue, 16 Apr 2019 20:37:29 -0700
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAEvYov3wpSeR90eZxxhM7PqXcHXuLQqTOCu3_Hhxm+i2-w8GrA@mail.gmail.com>
References: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
 <CAOHrpwGRjb_3fMONsuS-vFs98SARLcMp=G28LPKzmzB4fjV-tA@mail.gmail.com>
 <CAEvYov3wpSeR90eZxxhM7PqXcHXuLQqTOCu3_Hhxm+i2-w8GrA@mail.gmail.com>
Message-ID: <C84F43F3-0E68-49A2-961D-3B22C8E23E8D@mirantis.com>

Hello All,

I first want to thank each and everyone of you for reaching out and sharing the inaccuracies you all have found within Stackalytics, this has helped us tremendously with the efforts to correct these flaws. 

I am writing this email to directly address each individual that has reached out and shared their concerns with our Stackalytics data.

Mark Goddard
Michael Johnson
Julia Kreger
Collen Murphy
Clark Boylan
Sean Mooney
Thierry Carrez
Jermey Stanley
Arkady Kanvesky
(Hopefully, I did not miss anyone)

I want to insure everyone that the team is working hard to fix the inaccuracies in some of our data. We are still very much involved in OpenStack and we do read each and every message regarding Stackalytics.

As Boris and Sergey mentioned, we found that this occurred due to an outdated production environment. We are currently in the progress of migrating to a new environment, and the data should be corrected. 

The team and I are sorry for these discrepancies and appreciate you all for bringing this to our attention. 
Thank you all, for providing links and examples of the inaccuracies. This has helped our efforts greatly in correcting the current issues. It would be great if the community can continue reviewing Stackalytics data and help us provide a better service to all. 


Once again, we are all very sorry for this and will continue to fix these issues.

Cheers,
Edward 

> On Apr 16, 2019, at 4:05 PM, Edward Ionel <eionel at mirantis.com> wrote:
> 
> 
> 
>> On Tue, Apr 16, 2019 at 2:56 PM Boris Renski <brenski at mirantis.com> wrote:
>> Folks - more specifically, we plan to roll out an update by tomorrow mid-day PT which should fix all the numbers + add aggregate details on Airship project contributions. 
>> 
>> Would really appreciate the help of the community to poke around tomorrow afternoon and see if there are still discrepancies. 
>> 
>> Sorry about this and thank you for catching it and brining it to our attention. 
>> 
>> -Boris
>> 
>>> On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin at mirantis.com> wrote:
>>> Hello everyone,
>>> As you mentioned there are some inaccuracies in stats on stackalytics.com. It happened because of outdated Prod env. At this moment we are in a process of migration to the new env. All data on this env is fresh and accurate. So the problem will be solved soon. 
>>> 
>>> -- 
>>> Best Regards,
>>> Sergey Nikitin
> 
> 
> -- 
> Edward Ionel
> Marketing Operations Manager
> Mirantis, Inc.
> 900 E Hamilton Ave, Suite 650
> Campbell, CA 95008
> Eionel at mirantis.com
> www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/626d32a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mirantis-logo-2color-rgb-transparent.png
Type: image/png
Size: 31598 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/626d32a5/attachment-0001.png>

From giorgis at acmac.uoc.gr  Wed Apr 17 19:02:43 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Wed, 17 Apr 2019 22:02:43 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
Message-ID: <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>


 Thank you both Melanie and Matt for trying to assist me.

 I have double checked the nova.conf at the controller and here is what 
 I have (ignored hashed lines and obfuscating sensitive data): 
 https://pastebin.com/hW1PE4U7

 As you can see I have everything with default values as discussed 
 before with Melanie except the filters and the weight that I have 
 applied that should lead to VM stacking instead of spreading.

 My case scenario is with two compute hosts (let's call them "cpu1" and 
 "cpu2") and when an instance is already placed on "cpu2" I expect the 
 next instance to be placed also there. But instead is placed on "cpu1" 
 as you can see from the scheduler log that can find here: 
 https://pastebin.com/sCzB9L2e

 Do you see something strange that I fail to recognize?

 Best regards,

 G.

> On 4/16/2019 7:03 PM, melanie witt wrote:
>> To debug further, you should set debug to True in the nova.conf on 
>> your scheduler host and look for which filter is removing the desired 
>> host for the second VM. You can find where to start by looking for a 
>> message like, "Starting with N host(s)". If you have two hosts with 
>> enough RAM, you should see "Starting with 2 host(s)" and then look for 
>> the log message where it says "Filter returned 1 host(s)" and that 
>> will be the filter that is removing the desired host. Once you know 
>> which filter is removing it, you can debug further.
>
> If the other host isn't getting filtered out, it could be the
> weighers that aren't prioritizing the host you expect, but debug logs
> should dump the weighed hosts as well which might give a clue.




From melwittt at gmail.com  Wed Apr 17 19:19:26 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 17 Apr 2019 12:19:26 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
Message-ID: <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>

On Wed, 17 Apr 2019 22:02:43 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
> 
>   Thank you both Melanie and Matt for trying to assist me.
> 
>   I have double checked the nova.conf at the controller and here is what
>   I have (ignored hashed lines and obfuscating sensitive data):
>   https://pastebin.com/hW1PE4U7
> 
>   As you can see I have everything with default values as discussed
>   before with Melanie except the filters and the weight that I have
>   applied that should lead to VM stacking instead of spreading.
> 
>   My case scenario is with two compute hosts (let's call them "cpu1" and
>   "cpu2") and when an instance is already placed on "cpu2" I expect the
>   next instance to be placed also there. But instead is placed on "cpu1"
>   as you can see from the scheduler log that can find here:
>   https://pastebin.com/sCzB9L2e
> 
>   Do you see something strange that I fail to recognize?

Thanks for providing the helpful data. It appears you have set your 
nova.conf correctly (this is where your scheduler is running, yes?). I 
notice you have duplicated the ram_weight_multiplier setting but that 
shouldn't hurt anything.

The relevant scheduler log is this one:

2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler 
[req-02fb5504-cbdb-4219-9509-d2be9da7bb0e 
6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB 
io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB 
io_ops: 0 instances: 1] _get_sorted_hosts 
/usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455

and here we see that host 'cpu1' is being weighed ahead of host 'cpu2', 
which is the problem. I don't understand this considering the docs say 
that setting the ram_weight_multiplier to a negative value should result 
in the host with the lesser RAM being weighed higher/first. According to 
your log, the opposite is happening -- 'cpu1' with 32153MB RAM is being 
weighed higher than 'cpu2' with 30105MB RAM.

Either your ram_weight_multiplier setting is not being picked up or 
there's a bug causing weight to be applied with reverse logic?

Can you look at the scheduler debug log when the service first started 
up and verify what value of ram_weight_multiplier the service is using?

-melanie

>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>> To debug further, you should set debug to True in the nova.conf on
>>> your scheduler host and look for which filter is removing the desired
>>> host for the second VM. You can find where to start by looking for a
>>> message like, "Starting with N host(s)". If you have two hosts with
>>> enough RAM, you should see "Starting with 2 host(s)" and then look for
>>> the log message where it says "Filter returned 1 host(s)" and that
>>> will be the filter that is removing the desired host. Once you know
>>> which filter is removing it, you can debug further.
>>
>> If the other host isn't getting filtered out, it could be the
>> weighers that aren't prioritizing the host you expect, but debug logs
>> should dump the weighed hosts as well which might give a clue.
> 
> 






From mriedemos at gmail.com  Wed Apr 17 19:45:00 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 17 Apr 2019 14:45:00 -0500
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
Message-ID: <363f073d-c6cc-ca0a-0211-442e0af8acaf@gmail.com>

On 4/17/2019 2:19 PM, melanie witt wrote:
> The relevant scheduler log is this one:
> 
> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler 
> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e 
> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB 
> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB 
> io_ops: 0 instances: 1] _get_sorted_hosts 
> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
> 
> and here we see that host 'cpu1' is being weighed ahead of host 'cpu2', 
> which is the problem. I don't understand this considering the docs say 
> that setting the ram_weight_multiplier to a negative value should result 
> in the host with the lesser RAM being weighed higher/first. According to 
> your log, the opposite is happening -- 'cpu1' with 32153MB RAM is being 
> weighed higher than 'cpu2' with 30105MB RAM.
> 
> Either your ram_weight_multiplier setting is not being picked up or 
> there's a bug causing weight to be applied with reverse logic?
> 
> Can you look at the scheduler debug log when the service first started 
> up and verify what value of ram_weight_multiplier the service is using?

I agree with Melanie's assessment. Looking at the RAMWeigher code in 
Rocky we see it's weighing based on the free_ram_mb value in the 
HostState object:

https://github.com/openstack/nova/blob/stable/rocky/nova/scheduler/weights/ram.py#L38

Looking at the filtered hosts that were logged:

Filtered [(cpu2, cpu2) ram: 30105MB disk: 1886208MB io_ops: 0 instances: 
1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0]

The ram value that is logged is free_ram_mb:

https://github.com/openstack/nova/blob/stable/rocky/nova/scheduler/host_manager.py#L333

It looks like you also don't have this logging regression fix in your 
rocky scheduler code, so you might want to patch this in when getting 
new debug logs:

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

That could tell us what the resulting weight is.

-- 

Thanks,

Matt


From giorgis at acmac.uoc.gr  Wed Apr 17 19:45:45 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Wed, 17 Apr 2019 22:45:45 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
Message-ID: <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>

 Hello again Menalie!

 Exactly this is what I am thinking...something is not working 
 correctly!

 To answer your questions there is one node acting as controller where 
 the scheduler is running and I have pasted the nova.conf file from 
 there.

 I have also noticed that I have "ram_weight_multiplier" two times (one 
 in [cells] and one in [filter_scheduler]) therefore I have removed the 
 one in [cells] because I though it might give a problem but the results 
 are still the same.

 The log for the scheduler has this entry:

 2019-04-17 22:04:50.045 131723 DEBUG oslo_service.service 
 [req-7e548ecb-f3ed-4a4d-835f-b3a996e32534 - - - - -] 
 filter_scheduler.ram_weight_multiplier = -1.0 log_opt_values 
 /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3032

 so it seems to be picked up correctly but without any influence.

 What also worries me from the scheduler log that I have send to you 
 before is that in there I see an entry like this:

 2019-04-17 19:53:07.298 98874 DEBUG nova.filters 
 [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e 
 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
 default default] Filter RamFilter returned 2 host(s) 
 get_filtered_objects 
 /usr/lib/python2.7/site-packages/nova/filters.py:104

 Shouldn't the RamFilter return 1host and the one with less RAM? Why 
 does it return 2hosts??

 If you have any other ideas or would like me to do some more checking I 
 am all ears!

 Thank you,

 G.


>> Thank you both Melanie and Matt for trying to assist me.
>> I have double checked the nova.conf at the controller and here is 
>> what
>>   I have (ignored hashed lines and obfuscating sensitive data):
>>   https://pastebin.com/hW1PE4U7
>> As you can see I have everything with default values as discussed
>>   before with Melanie except the filters and the weight that I have
>>   applied that should lead to VM stacking instead of spreading.
>> My case scenario is with two compute hosts (let's call them "cpu1" 
>> and
>>   "cpu2") and when an instance is already placed on "cpu2" I expect 
>> the
>>   next instance to be placed also there. But instead is placed on 
>> "cpu1"
>>   as you can see from the scheduler log that can find here:
>>   https://pastebin.com/sCzB9L2e
>> Do you see something strange that I fail to recognize?
>
> Thanks for providing the helpful data. It appears you have set your
> nova.conf correctly (this is where your scheduler is running, yes?). 
> I
> notice you have duplicated the ram_weight_multiplier setting but that
> shouldn't hurt anything.
>
> The relevant scheduler log is this one:
>
> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler
> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB
> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
> io_ops: 0 instances: 1] _get_sorted_hosts
> 
> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
>
> and here we see that host 'cpu1' is being weighed ahead of host
> 'cpu2', which is the problem. I don't understand this considering the
> docs say that setting the ram_weight_multiplier to a negative value
> should result in the host with the lesser RAM being weighed
> higher/first. According to your log, the opposite is happening --
> 'cpu1' with 32153MB RAM is being weighed higher than 'cpu2' with
> 30105MB RAM.
>
> Either your ram_weight_multiplier setting is not being picked up or
> there's a bug causing weight to be applied with reverse logic?
>
> Can you look at the scheduler debug log when the service first
> started up and verify what value of ram_weight_multiplier the service
> is using?
>
> -melanie
>
>>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>>> To debug further, you should set debug to True in the nova.conf on
>>>> your scheduler host and look for which filter is removing the 
>>>> desired
>>>> host for the second VM. You can find where to start by looking for 
>>>> a
>>>> message like, "Starting with N host(s)". If you have two hosts 
>>>> with
>>>> enough RAM, you should see "Starting with 2 host(s)" and then look 
>>>> for
>>>> the log message where it says "Filter returned 1 host(s)" and that
>>>> will be the filter that is removing the desired host. Once you 
>>>> know
>>>> which filter is removing it, you can debug further.
>>>
>>> If the other host isn't getting filtered out, it could be the
>>> weighers that aren't prioritizing the host you expect, but debug 
>>> logs
>>> should dump the weighed hosts as well which might give a clue.
>>
>>



From kennelson11 at gmail.com  Wed Apr 17 19:30:44 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 17 Apr 2019 12:30:44 -0700
Subject: [PTG] FINAL SCHEDULE..NO SERIOUSLY.
Message-ID: <CAJ6yrQiVW7wk+Rv9m46ixQxOE8Tzev73MG3NsG41zVxLybg8-A@mail.gmail.com>

Since I published the first 'Final Schedule' we have had a number of small
changes that we've had to make so I wanted to update everyone to make sure
we are all on the same page.

Seriously though, this is the last round of changes as this version of the
schedule has already gone to the design team and is going to print sometime
tomorrow/Friday.

To textually summarize the changes:

   - Tacker will no longer be meeting
   - Converted the Interop WG into a dynamically scheduled team
   - Horizon will be all day Thursday instead of a half day


See you all soon!

-Kendall (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/6df1a012/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: for_cereal_final.png
Type: image/png
Size: 55552 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/6df1a012/attachment-0001.png>

From melwittt at gmail.com  Wed Apr 17 19:55:45 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 17 Apr 2019 12:55:45 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
Message-ID: <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>

On Wed, 17 Apr 2019 22:45:45 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
>   Hello again Menalie!
> 
>   Exactly this is what I am thinking...something is not working
>   correctly!
> 
>   To answer your questions there is one node acting as controller where
>   the scheduler is running and I have pasted the nova.conf file from
>   there.
> 
>   I have also noticed that I have "ram_weight_multiplier" two times (one
>   in [cells] and one in [filter_scheduler]) therefore I have removed the
>   one in [cells] because I though it might give a problem but the results
>   are still the same.
> 
>   The log for the scheduler has this entry:
> 
>   2019-04-17 22:04:50.045 131723 DEBUG oslo_service.service
>   [req-7e548ecb-f3ed-4a4d-835f-b3a996e32534 - - - - -]
>   filter_scheduler.ram_weight_multiplier = -1.0 log_opt_values
>   /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3032
> 
>   so it seems to be picked up correctly but without any influence.

Agreed, that log shows that the -1.0 value is being picked up properly 
by the scheduler service.

>   What also worries me from the scheduler log that I have send to you
>   before is that in there I see an entry like this:
> 
>   2019-04-17 19:53:07.298 98874 DEBUG nova.filters
>   [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>   6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>   default default] Filter RamFilter returned 2 host(s)
>   get_filtered_objects
>   /usr/lib/python2.7/site-packages/nova/filters.py:104
> 
>   Shouldn't the RamFilter return 1host and the one with less RAM? Why
>   does it return 2hosts??

No -- the RamFilter will return any hosts that meet the RAM requirement. 
Filters do not weigh hosts. The RamFilter returns two hosts because both 
hosts have enough RAM to fulfill the request. FYI though, as of Pike 
[1], the (Core|Ram|Disk)Filter are redundant, as placement will do the 
filtering for those resources before the nova scheduler filters run. So 
you can safely remove (Core|Ram|Disk)Filter from your enabled_filters.

[1] 
https://docs.openstack.org/releasenotes/nova/pike.html#relnotes-16-0-0-stable-pike-upgrade-notes

>   If you have any other ideas or would like me to do some more checking I
>   am all ears!
At this point, you could take Matt's suggestion from his latest reply on 
this thread and patch in the logging regression fix he linked. That 
would allow you to see in the debug log what weights nova is giving to 
the hosts.

Aside from that, it's looking like we/I would need to reproduce this 
issue locally with a devstack and try to figure out what's causing this 
behavior.

-melanie

>>> Thank you both Melanie and Matt for trying to assist me.
>>> I have double checked the nova.conf at the controller and here is
>>> what
>>>    I have (ignored hashed lines and obfuscating sensitive data):
>>>    https://pastebin.com/hW1PE4U7
>>> As you can see I have everything with default values as discussed
>>>    before with Melanie except the filters and the weight that I have
>>>    applied that should lead to VM stacking instead of spreading.
>>> My case scenario is with two compute hosts (let's call them "cpu1"
>>> and
>>>    "cpu2") and when an instance is already placed on "cpu2" I expect
>>> the
>>>    next instance to be placed also there. But instead is placed on
>>> "cpu1"
>>>    as you can see from the scheduler log that can find here:
>>>    https://pastebin.com/sCzB9L2e
>>> Do you see something strange that I fail to recognize?
>>
>> Thanks for providing the helpful data. It appears you have set your
>> nova.conf correctly (this is where your scheduler is running, yes?).
>> I
>> notice you have duplicated the ram_weight_multiplier setting but that
>> shouldn't hurt anything.
>>
>> The relevant scheduler log is this one:
>>
>> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler
>> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB
>> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
>> io_ops: 0 instances: 1] _get_sorted_hosts
>>
>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
>>
>> and here we see that host 'cpu1' is being weighed ahead of host
>> 'cpu2', which is the problem. I don't understand this considering the
>> docs say that setting the ram_weight_multiplier to a negative value
>> should result in the host with the lesser RAM being weighed
>> higher/first. According to your log, the opposite is happening --
>> 'cpu1' with 32153MB RAM is being weighed higher than 'cpu2' with
>> 30105MB RAM.
>>
>> Either your ram_weight_multiplier setting is not being picked up or
>> there's a bug causing weight to be applied with reverse logic?
>>
>> Can you look at the scheduler debug log when the service first
>> started up and verify what value of ram_weight_multiplier the service
>> is using?
>>
>> -melanie
>>
>>>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>>>> To debug further, you should set debug to True in the nova.conf on
>>>>> your scheduler host and look for which filter is removing the
>>>>> desired
>>>>> host for the second VM. You can find where to start by looking for
>>>>> a
>>>>> message like, "Starting with N host(s)". If you have two hosts
>>>>> with
>>>>> enough RAM, you should see "Starting with 2 host(s)" and then look
>>>>> for
>>>>> the log message where it says "Filter returned 1 host(s)" and that
>>>>> will be the filter that is removing the desired host. Once you
>>>>> know
>>>>> which filter is removing it, you can debug further.
>>>>
>>>> If the other host isn't getting filtered out, it could be the
>>>> weighers that aren't prioritizing the host you expect, but debug
>>>> logs
>>>> should dump the weighed hosts as well which might give a clue.
>>>
>>>
> 






From melwittt at gmail.com  Wed Apr 17 20:07:09 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 17 Apr 2019 13:07:09 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
Message-ID: <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>

On Wed, 17 Apr 2019 12:55:45 -0700, Melanie Witt <melwittt at gmail.com> wrote:
> On Wed, 17 Apr 2019 22:45:45 +0300, Georgios Dimitrakakis
> <giorgis at acmac.uoc.gr> wrote:
>>    Hello again Menalie!
>>
>>    Exactly this is what I am thinking...something is not working
>>    correctly!
>>
>>    To answer your questions there is one node acting as controller where
>>    the scheduler is running and I have pasted the nova.conf file from
>>    there.
>>
>>    I have also noticed that I have "ram_weight_multiplier" two times (one
>>    in [cells] and one in [filter_scheduler]) therefore I have removed the
>>    one in [cells] because I though it might give a problem but the results
>>    are still the same.
>>
>>    The log for the scheduler has this entry:
>>
>>    2019-04-17 22:04:50.045 131723 DEBUG oslo_service.service
>>    [req-7e548ecb-f3ed-4a4d-835f-b3a996e32534 - - - - -]
>>    filter_scheduler.ram_weight_multiplier = -1.0 log_opt_values
>>    /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3032
>>
>>    so it seems to be picked up correctly but without any influence.
> 
> Agreed, that log shows that the -1.0 value is being picked up properly
> by the scheduler service.
> 
>>    What also worries me from the scheduler log that I have send to you
>>    before is that in there I see an entry like this:
>>
>>    2019-04-17 19:53:07.298 98874 DEBUG nova.filters
>>    [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>    6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>>    default default] Filter RamFilter returned 2 host(s)
>>    get_filtered_objects
>>    /usr/lib/python2.7/site-packages/nova/filters.py:104
>>
>>    Shouldn't the RamFilter return 1host and the one with less RAM? Why
>>    does it return 2hosts??
> 
> No -- the RamFilter will return any hosts that meet the RAM requirement.
> Filters do not weigh hosts. The RamFilter returns two hosts because both
> hosts have enough RAM to fulfill the request. FYI though, as of Pike
> [1], the (Core|Ram|Disk)Filter are redundant, as placement will do the
> filtering for those resources before the nova scheduler filters run. So
> you can safely remove (Core|Ram|Disk)Filter from your enabled_filters.
> 
> [1]
> https://docs.openstack.org/releasenotes/nova/pike.html#relnotes-16-0-0-stable-pike-upgrade-notes
> 
>>    If you have any other ideas or would like me to do some more checking I
>>    am all ears!
> At this point, you could take Matt's suggestion from his latest reply on
> this thread and patch in the logging regression fix he linked. That
> would allow you to see in the debug log what weights nova is giving to
> the hosts.

OK, so I just searched open nova bugs for "weigh" and found this issue, 
which isn't necessarily a defect:

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

but something that could be affecting the host weighing in your 
environment. There's something called the BuildFailureWeigher which will 
apply a low weight multiplier to hosts that have had VMs fail to build 
on them. And that weight resets when a host experiences a successful VM 
build.

If you apply the patch Matt suggested and take a look at the host 
weights, we should be able to see whether the BuildFailureWeigher is 
involved in the behavior you're seeing.

-melanie

> Aside from that, it's looking like we/I would need to reproduce this
> issue locally with a devstack and try to figure out what's causing this
> behavior.
> 
> -melanie
> 
>>>> Thank you both Melanie and Matt for trying to assist me.
>>>> I have double checked the nova.conf at the controller and here is
>>>> what
>>>>     I have (ignored hashed lines and obfuscating sensitive data):
>>>>     https://pastebin.com/hW1PE4U7
>>>> As you can see I have everything with default values as discussed
>>>>     before with Melanie except the filters and the weight that I have
>>>>     applied that should lead to VM stacking instead of spreading.
>>>> My case scenario is with two compute hosts (let's call them "cpu1"
>>>> and
>>>>     "cpu2") and when an instance is already placed on "cpu2" I expect
>>>> the
>>>>     next instance to be placed also there. But instead is placed on
>>>> "cpu1"
>>>>     as you can see from the scheduler log that can find here:
>>>>     https://pastebin.com/sCzB9L2e
>>>> Do you see something strange that I fail to recognize?
>>>
>>> Thanks for providing the helpful data. It appears you have set your
>>> nova.conf correctly (this is where your scheduler is running, yes?).
>>> I
>>> notice you have duplicated the ram_weight_multiplier setting but that
>>> shouldn't hurt anything.
>>>
>>> The relevant scheduler log is this one:
>>>
>>> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler
>>> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>>> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB
>>> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
>>> io_ops: 0 instances: 1] _get_sorted_hosts
>>>
>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
>>>
>>> and here we see that host 'cpu1' is being weighed ahead of host
>>> 'cpu2', which is the problem. I don't understand this considering the
>>> docs say that setting the ram_weight_multiplier to a negative value
>>> should result in the host with the lesser RAM being weighed
>>> higher/first. According to your log, the opposite is happening --
>>> 'cpu1' with 32153MB RAM is being weighed higher than 'cpu2' with
>>> 30105MB RAM.
>>>
>>> Either your ram_weight_multiplier setting is not being picked up or
>>> there's a bug causing weight to be applied with reverse logic?
>>>
>>> Can you look at the scheduler debug log when the service first
>>> started up and verify what value of ram_weight_multiplier the service
>>> is using?
>>>
>>> -melanie
>>>
>>>>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>>>>> To debug further, you should set debug to True in the nova.conf on
>>>>>> your scheduler host and look for which filter is removing the
>>>>>> desired
>>>>>> host for the second VM. You can find where to start by looking for
>>>>>> a
>>>>>> message like, "Starting with N host(s)". If you have two hosts
>>>>>> with
>>>>>> enough RAM, you should see "Starting with 2 host(s)" and then look
>>>>>> for
>>>>>> the log message where it says "Filter returned 1 host(s)" and that
>>>>>> will be the filter that is removing the desired host. Once you
>>>>>> know
>>>>>> which filter is removing it, you can debug further.
>>>>>
>>>>> If the other host isn't getting filtered out, it could be the
>>>>> weighers that aren't prioritizing the host you expect, but debug
>>>>> logs
>>>>> should dump the weighed hosts as well which might give a clue.
>>>>
>>>>
>>
> 
> 
> 
> 






From lbragstad at gmail.com  Wed Apr 17 20:15:11 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Wed, 17 Apr 2019 15:15:11 -0500
Subject: [dev][tc][all] Train Goal Schedule and Update
In-Reply-To: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
References: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
Message-ID: <a3ba268f-493f-444a-dbd8-4bf22091e2ed@gmail.com>

Sending a quick follow-up here. We now have a proposal for ipv6 testing
support as a community goal [0]. Thanks to gmann for writing it up!

I encourage folks to have a look if you have time before the PTG.

[0] https://review.openstack.org/653545

On 4/3/19 11:59 AM, Lance Bragstad wrote:
> Hi all,
>
> Since the community goal selection process has taken a turn, we wanted
> to send  an update regarding the current goals. We originally wanted
> to have the goals for Train be merged by this point to give project
> teams ample time to plan for them accordingly in their PTG scheduled.
> Due to discussions raised in each [0][1], it doesn't sound like either
> will be making it into Train as a feasible community goal.
> Fortunately, a couple of last minute goals might be a perfect fit for
> Train, instead of having a release without any community goals.
>
> The first one suggested is to render documentation as PDFs [2]. The
> second goal, which still needs to be proposed, is for IPv6 support.
> The advantage is that both of these goals are much smaller in scope,
> but still useful. We're running up against the clock on getting goals
> selected for Train, but we still have an opportunity to come to
> agreement on the new proposals before the PTG.
>
> We'd like to ask TC and members of the community to review the
> proposed goals at their earliest convenience. Additionally, if someone
> wants help write up the IPv6 support goal [3][4], please reach out
> gmann and mnaser. Even though we were originally trying to make sure
> we had firm goals well before the PTG, the reduced scope of the new
> goals should make them easier to talk about in impromptu sessions or
> the hallway track.
>
> Thanks,
>
> JP & Lance
>
> [0] https://review.openstack.org/#/c/639376/
> [1] https://review.openstack.org/#/c/639010/
> [2] https://review.openstack.org/#/c/647712/
> [3] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-03-28.log.html#t2019-03-28T15:10:36
> [4] Note that this goal is for testing IPv6 networking setups in all
> projects. We already have a tempest full ipv6 job, it would be a
> matter of making these jobs passing and voting in the future.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/c7f5d018/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/c7f5d018/attachment-0001.sig>

From giorgis at acmac.uoc.gr  Wed Apr 17 20:50:24 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Wed, 17 Apr 2019 23:50:24 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
Message-ID: <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>

 OK! I have applied the patch and now weights are shown!
 Furthermore as per your suggestion I have removed the "RamFilter" which 
 was the only one present.


 And here is the new log where spawning of 2 VMs can be seen with a few 
 seconds of difference: https://pastebin.com/Xy2FL2KL

 Initially both hosts are of weight 1.0 then the one with one VM already 
 running has negative weight but the new VM is placed on the other host.

 Really-really strange why this is happening...

 G.


> On Wed, 17 Apr 2019 12:55:45 -0700, Melanie Witt <melwittt at gmail.com> 
> wrote:
>> On Wed, 17 Apr 2019 22:45:45 +0300, Georgios Dimitrakakis
>> <giorgis at acmac.uoc.gr> wrote:
>>>    Hello again Menalie!
>>>
>>>    Exactly this is what I am thinking...something is not working
>>>    correctly!
>>>
>>>    To answer your questions there is one node acting as controller 
>>> where
>>>    the scheduler is running and I have pasted the nova.conf file 
>>> from
>>>    there.
>>>
>>>    I have also noticed that I have "ram_weight_multiplier" two 
>>> times (one
>>>    in [cells] and one in [filter_scheduler]) therefore I have 
>>> removed the
>>>    one in [cells] because I though it might give a problem but the 
>>> results
>>>    are still the same.
>>>
>>>    The log for the scheduler has this entry:
>>>
>>>    2019-04-17 22:04:50.045 131723 DEBUG oslo_service.service
>>>    [req-7e548ecb-f3ed-4a4d-835f-b3a996e32534 - - - - -]
>>>    filter_scheduler.ram_weight_multiplier = -1.0 log_opt_values
>>>    /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3032
>>>
>>>    so it seems to be picked up correctly but without any influence.
>> Agreed, that log shows that the -1.0 value is being picked up 
>> properly
>> by the scheduler service.
>>
>>>    What also worries me from the scheduler log that I have send to 
>>> you
>>>    before is that in there I see an entry like this:
>>>
>>>    2019-04-17 19:53:07.298 98874 DEBUG nova.filters
>>>    [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>>    6a4c2e32919e4a6fa5c5d956beb68eef 
>>> 9f22e9bfa7974e14871d58bbb62242b2 -
>>>    default default] Filter RamFilter returned 2 host(s)
>>>    get_filtered_objects
>>>    /usr/lib/python2.7/site-packages/nova/filters.py:104
>>>
>>>    Shouldn't the RamFilter return 1host and the one with less RAM? 
>>> Why
>>>    does it return 2hosts??
>> No -- the RamFilter will return any hosts that meet the RAM 
>> requirement.
>> Filters do not weigh hosts. The RamFilter returns two hosts because 
>> both
>> hosts have enough RAM to fulfill the request. FYI though, as of Pike
>> [1], the (Core|Ram|Disk)Filter are redundant, as placement will do 
>> the
>> filtering for those resources before the nova scheduler filters run. 
>> So
>> you can safely remove (Core|Ram|Disk)Filter from your 
>> enabled_filters.
>> [1]
>> 
>> https://docs.openstack.org/releasenotes/nova/pike.html#relnotes-16-0-0-stable-pike-upgrade-notes
>>
>>>    If you have any other ideas or would like me to do some more 
>>> checking I
>>>    am all ears!
>> At this point, you could take Matt's suggestion from his latest 
>> reply on
>> this thread and patch in the logging regression fix he linked. That
>> would allow you to see in the debug log what weights nova is giving 
>> to
>> the hosts.
>
> OK, so I just searched open nova bugs for "weigh" and found this
> issue, which isn't necessarily a defect:
>
> https://bugs.launchpad.net/nova/+bug/1818239
>
> but something that could be affecting the host weighing in your
> environment. There's something called the BuildFailureWeigher which
> will apply a low weight multiplier to hosts that have had VMs fail to
> build on them. And that weight resets when a host experiences a
> successful VM build.
>
> If you apply the patch Matt suggested and take a look at the host
> weights, we should be able to see whether the BuildFailureWeigher is
> involved in the behavior you're seeing.
>
> -melanie
>
>> Aside from that, it's looking like we/I would need to reproduce this
>> issue locally with a devstack and try to figure out what's causing 
>> this
>> behavior.
>> -melanie
>>
>>>>> Thank you both Melanie and Matt for trying to assist me.
>>>>> I have double checked the nova.conf at the controller and here is
>>>>> what
>>>>>     I have (ignored hashed lines and obfuscating sensitive data):
>>>>>     https://pastebin.com/hW1PE4U7
>>>>> As you can see I have everything with default values as discussed
>>>>>     before with Melanie except the filters and the weight that I 
>>>>> have
>>>>>     applied that should lead to VM stacking instead of spreading.
>>>>> My case scenario is with two compute hosts (let's call them 
>>>>> "cpu1"
>>>>> and
>>>>>     "cpu2") and when an instance is already placed on "cpu2" I 
>>>>> expect
>>>>> the
>>>>>     next instance to be placed also there. But instead is placed 
>>>>> on
>>>>> "cpu1"
>>>>>     as you can see from the scheduler log that can find here:
>>>>>     https://pastebin.com/sCzB9L2e
>>>>> Do you see something strange that I fail to recognize?
>>>>
>>>> Thanks for providing the helpful data. It appears you have set 
>>>> your
>>>> nova.conf correctly (this is where your scheduler is running, 
>>>> yes?).
>>>> I
>>>> notice you have duplicated the ram_weight_multiplier setting but 
>>>> that
>>>> shouldn't hurt anything.
>>>>
>>>> The relevant scheduler log is this one:
>>>>
>>>> 2019-04-17 19:53:07.303 98874 DEBUG 
>>>> nova.scheduler.filter_scheduler
>>>> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 
>>>> -
>>>> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 
>>>> 1906688MB
>>>> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
>>>> io_ops: 0 instances: 1] _get_sorted_hosts
>>>>
>>>> 
>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
>>>>
>>>> and here we see that host 'cpu1' is being weighed ahead of host
>>>> 'cpu2', which is the problem. I don't understand this considering 
>>>> the
>>>> docs say that setting the ram_weight_multiplier to a negative 
>>>> value
>>>> should result in the host with the lesser RAM being weighed
>>>> higher/first. According to your log, the opposite is happening --
>>>> 'cpu1' with 32153MB RAM is being weighed higher than 'cpu2' with
>>>> 30105MB RAM.
>>>>
>>>> Either your ram_weight_multiplier setting is not being picked up 
>>>> or
>>>> there's a bug causing weight to be applied with reverse logic?
>>>>
>>>> Can you look at the scheduler debug log when the service first
>>>> started up and verify what value of ram_weight_multiplier the 
>>>> service
>>>> is using?
>>>>
>>>> -melanie
>>>>
>>>>>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>>>>>> To debug further, you should set debug to True in the nova.conf 
>>>>>>> on
>>>>>>> your scheduler host and look for which filter is removing the
>>>>>>> desired
>>>>>>> host for the second VM. You can find where to start by looking 
>>>>>>> for
>>>>>>> a
>>>>>>> message like, "Starting with N host(s)". If you have two hosts
>>>>>>> with
>>>>>>> enough RAM, you should see "Starting with 2 host(s)" and then 
>>>>>>> look
>>>>>>> for
>>>>>>> the log message where it says "Filter returned 1 host(s)" and 
>>>>>>> that
>>>>>>> will be the filter that is removing the desired host. Once you
>>>>>>> know
>>>>>>> which filter is removing it, you can debug further.
>>>>>>
>>>>>> If the other host isn't getting filtered out, it could be the
>>>>>> weighers that aren't prioritizing the host you expect, but debug
>>>>>> logs
>>>>>> should dump the weighed hosts as well which might give a clue.
>>>>>
>>>>>
>>>
>>
>>
>>
>>


From jeremyfreudberg at gmail.com  Wed Apr 17 21:05:22 2019
From: jeremyfreudberg at gmail.com (Jeremy Freudberg)
Date: Wed, 17 Apr 2019 17:05:22 -0400
Subject: [sahara] Sahara meeting April 18 - volunteer chair? (or cancel?)
Message-ID: <CAFntmSicCgSFg2oZ9P2d6ZNAkVHvRSiePZKQfV=GRNCMRxCB-Q@mail.gmail.com>

I have a personal conflict and will not be around to run the Sahara
meeting on April 18 (tomorrow).

There isn't too much to discuss, so I'm comfortable letting it be
cancelled. But if there is any volunteer chair, the meeting can still
run.

Thanks,
Jeremy


From sombrafam at gmail.com  Wed Apr 17 21:25:58 2019
From: sombrafam at gmail.com (Erlon Cruz)
Date: Wed, 17 Apr 2019 18:25:58 -0300
Subject: [cinder][dev] support-revert-to-any-snapshot
In-Reply-To: <6031C821D2144A4CB722005A21B34BD53AE81F42@MX202CL02.corp.emc.com>
References: <6031C821D2144A4CB722005A21B34BD53AE7E1AC@MX202CL02.corp.emc.com>
 <6031C821D2144A4CB722005A21B34BD53AE81F42@MX202CL02.corp.emc.com>
Message-ID: <CAF+CadsiutAFoQrSEVVLQ0_xjoOMBH23P_9Ou3eiuW9OPnAjvg@mail.gmail.com>

Hey Helen,

The NFS Generic driver relies on QEMU rollback/commit which in some cases
will  merge the intermediary snapshots, so you would loose them. I think
that there are others, really hard to tell, as looking at the code may not
reveal what some backends do internally and I'm pretty sure not all backend
maintainers will promptly inform if they support or not.

Erlon

Em qua, 17 de abr de 2019 às 05:56, Walsh, Helen <Helen.Walsh at dell.com>
escreveu:

>
>
> To cinder driver developers:
>
>
>
> ·
> https://blueprints.launchpad.net/cinder/+spec/support-revert-to-any-snapshot
>
>
>
> In relation to the blueprint above.  I am wondering if there are any
> drivers that whose later snapshots will not be valid after a revert to an
> snapshot that is NOT the last in the series
>
>
>
>                                                               Vol1
>
>                                                                  \
>
> -----------------------------------------------------
>
> Mon        Tue          Wed       Thu           Fri
>
>    \              \                 \                \              \
>
>     S1 -------- S2 ---------S3 -------- S4 ---------S5
>
>
>
>
>
> If on Fri, I was to revert back to Tuesday’s Snapshot S2, would S3, S4 and
> S5 still be usable Snapshots?
>
>
>
>
>
>              Vol1
>
>                 \
>
> -----------------------------------------------------
>
> Mon        Tue          Wed       Thu           Fri
>
>    \              \                 \                \              \
>
>     S1 -------- S2 ---------S3 -------- S4 ---------S5
>
>
>
> Thank you,
>
> Helen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190417/77440eee/attachment.html>

From mriedemos at gmail.com  Wed Apr 17 22:08:30 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 17 Apr 2019 17:08:30 -0500
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
Message-ID: <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>

On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
> And here is the new log where spawning of 2 VMs can be seen with a few 
> seconds of difference: https://pastebin.com/Xy2FL2KL
> 
> Initially both hosts are of weight 1.0 then the one with one VM already 
> running has negative weight but the new VM is placed on the other host.
> 
> Really-really strange why this is happening...

< 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler 
[req-14c666e4-3ff4-4d88-947e-377b3d37bff9 
6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
default default] Filtered [(cpu2, cpu2) ram: 30105MB disk: 1887232MB 
io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB 
io_ops: 0 instances: 0] _get_sorted_hosts 
/usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435

< 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler 
[req-14c666e4-3ff4-4d88-947e-377b3d37bff9 
6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
default default] Weighed [WeighedHost [host: (cpu1, cpu1) ram: 32153MB 
disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: 
(cpu2, cpu2) ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, 
weight: -0.00900862553213]] _get_sorted_hosts 
/usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454

cpu1 is definitely getting weighed higher but I'm not sure why. We 
likely need some debug logging on the result of each weigher like we 
have for each filter to figure out what's going on with the weighers.

-- 

Thanks,

Matt


From giorgis at acmac.uoc.gr  Wed Apr 17 22:08:27 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Thu, 18 Apr 2019 01:08:27 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
Message-ID: <1FE0FD6C-102E-472F-9157-407AC6BB299F@acmac.uoc.gr>

OK! I have applied the patch and now weights are shown!
Furthermore as per your suggestion I have removed the "RamFilter" which was the only one present

And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference: https://pastebin.com/Xy2FL2KL

Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the new VM is placed on the other host.

Really-really strange why this is happening...

G.

>>> On Wed, 17 Apr 2019 12:55:45 -0700, Melanie Witt <melwittt at gmail.com> wrote:
>>> On Wed, 17 Apr 2019 22:45:45 +0300, Georgios Dimitrakakis
>>> <giorgis at acmac.uoc.gr> wrote:
>>>>  Hello again Menalie!
>>>> 
>>>>  Exactly this is what I am thinking...something is not working
>>>>  correctly!
>>>> 
>>>>  To answer your questions there is one node acting as controller where
>>>>  the scheduler is running and I have pasted the nova.conf file from
>>>>  there.
>>>> 
>>>>  I have also noticed that I have "ram_weight_multiplier" two times (one
>>>>  in [cells] and one in [filter_scheduler]) therefore I have removed the
>>>>  one in [cells] because I though it might give a problem but the results
>>>>  are still the same.
>>>> 
>>>>  The log for the scheduler has this entry:
>>>> 
>>>>  2019-04-17 22:04:50.045 131723 DEBUG oslo_service.service
>>>>  [req-7e548ecb-f3ed-4a4d-835f-b3a996e32534 - - - - -]
>>>>  filter_scheduler.ram_weight_multiplier = -1.0 log_opt_values
>>>>  /usr/lib/python2.7/site-packages/oslo_config/cfg.py:3032
>>>> 
>>>>  so it seems to be picked up correctly but without any influence.
>>> Agreed, that log shows that the -1.0 value is being picked up properly
>>> by the scheduler service.
>>> 
>>>>  What also worries me from the scheduler log that I have send to you
>>>>  before is that in there I see an entry like this:
>>>> 
>>>>  2019-04-17 19:53:07.298 98874 DEBUG nova.filters
>>>>  [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>>>  6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>>>>  default default] Filter RamFilter returned 2 host(s)
>>>>  get_filtered_objects
>>>>  /usr/lib/python2.7/site-packages/nova/filters.py:104
>>>> 
>>>>  Shouldn't the RamFilter return 1host and the one with less RAM? Why
>>>>  does it return 2hosts??
>>> No -- the RamFilter will return any hosts that meet the RAM requirement.
>>> Filters do not weigh hosts. The RamFilter returns two hosts because both
>>> hosts have enough RAM to fulfill the request. FYI though, as of Pike
>>> [1], the (Core|Ram|Disk)Filter are redundant, as placement will do the
>>> filtering for those resources before the nova scheduler filters run. So
>>> you can safely remove (Core|Ram|Disk)Filter from your enabled_filters.
>>> [1]
>>> https://docs.openstack.org/releasenotes/nova/pike.html#relnotes-16-0-0-stable-pike-upgrade-notes
>>> 
>>>>  If you have any other ideas or would like me to do some more checking I
>>>>  am all ears!
>>> At this point, you could take Matt's suggestion from his latest reply on
>>> this thread and patch in the logging regression fix he linked. That
>>> would allow you to see in the debug log what weights nova is giving to
>>> the hosts.
>> 
>> OK, so I just searched open nova bugs for "weigh" and found this
>> issue, which isn't necessarily a defect:
>> 
>> https://bugs.launchpad.net/nova/+bug/1818239
>> 
>> but something that could be affecting the host weighing in your
>> environment. There's something called the BuildFailureWeigher which
>> will apply a low weight multiplier to hosts that have had VMs fail to
>> build on them. And that weight resets when a host experiences a
>> successful VM build.
>> 
>> If you apply the patch Matt suggested and take a look at the host
>> weights, we should be able to see whether the BuildFailureWeigher is
>> involved in the behavior you're seeing.
>> 
>> -melanie
>> 
>>> Aside from that, it's looking like we/I would need to reproduce this
>>> issue locally with a devstack and try to figure out what's causing this
>>> behavior.
>>> -melanie
>>> 
>>>>>> Thank you both Melanie and Matt for trying to assist me.
>>>>>> I have double checked the nova.conf at the controller and here is
>>>>>> what
>>>>>>   I have (ignored hashed lines and obfuscating sensitive data):
>>>>>>   https://pastebin.com/hW1PE4U7
>>>>>> As you can see I have everything with default values as discussed
>>>>>>   before with Melanie except the filters and the weight that I have
>>>>>>   applied that should lead to VM stacking instead of spreading.
>>>>>> My case scenario is with two compute hosts (let's call them "cpu1"
>>>>>> and
>>>>>>   "cpu2") and when an instance is already placed on "cpu2" I expect
>>>>>> the
>>>>>>   next instance to be placed also there. But instead is placed on
>>>>>> "cpu1"
>>>>>>   as you can see from the scheduler log that can find here:
>>>>>>   https://pastebin.com/sCzB9L2e
>>>>>> Do you see something strange that I fail to recognize?
>>>>> 
>>>>> Thanks for providing the helpful data. It appears you have set your
>>>>> nova.conf correctly (this is where your scheduler is running, yes?).
>>>>> I
>>>>> notice you have duplicated the ram_weight_multiplier setting but that
>>>>> shouldn't hurt anything.
>>>>> 
>>>>> The relevant scheduler log is this one:
>>>>> 
>>>>> 2019-04-17 19:53:07.303 98874 DEBUG nova.scheduler.filter_scheduler
>>>>> [req-02fb5504-cbdb-4219-9509-d2be9da7bb0e
>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>>>>> default default] Weighed [(cpu1, cpu1) ram: 32153MB disk: 1906688MB
>>>>> io_ops: 0 instances: 0, (cpu2, cpu2) ram: 30105MB disk: 1886208MB
>>>>> io_ops: 0 instances: 1] _get_sorted_hosts
>>>>> 
>>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:455
>>>>> 
>>>>> and here we see that host 'cpu1' is being weighed ahead of host
>>>>> 'cpu2', which is the problem. I don't understand this considering the
>>>>> docs say that setting the ram_weight_multiplier to a negative value
>>>>> should result in the host with the lesser RAM being weighed
>>>>> higher/first. According to your log, the opposite is happening --
>>>>> 'cpu1' with 32153MB RAM is being weighed higher than 'cpu2' with
>>>>> 30105MB RAM.
>>>>> 
>>>>> Either your ram_weight_multiplier setting is not being picked up or
>>>>> there's a bug causing weight to be applied with reverse logic?
>>>>> 
>>>>> Can you look at the scheduler debug log when the service first
>>>>> started up and verify what value of ram_weight_multiplier the service
>>>>> is using?
>>>>> 
>>>>> -melanie
>>>>> 
>>>>>>>> On 4/16/2019 7:03 PM, melanie witt wrote:
>>>>>>>> To debug further, you should set debug to True in the nova.conf on
>>>>>>>> your scheduler host and look for which filter is removing the
>>>>>>>> desired
>>>>>>>> host for the second VM. You can find where to start by looking for
>>>>>>>> a
>>>>>>>> message like, "Starting with N host(s)". If you have two hosts
>>>>>>>> with
>>>>>>>> enough RAM, you should see "Starting with 2 host(s)" and then look
>>>>>>>> for
>>>>>>>> the log message where it says "Filter returned 1 host(s)" and that
>>>>>>>> will be the filter that is removing the desired host. Once you
>>>>>>>> know
>>>>>>>> which filter is removing it, you can debug further.
>>>>>>> 
>>>>>>> If the other host isn't getting filtered out, it could be the
>>>>>>> weighers that aren't prioritizing the host you expect, but debug
>>>>>>> logs
>>>>>>> should dump the weighed hosts as well which might give a clue.
> 



From giorgis at acmac.uoc.gr  Wed Apr 17 22:13:42 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Thu, 18 Apr 2019 01:13:42 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
Message-ID: <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>

Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what the negative value for “ram_weight_multiplier” does ?

Please let me know how I can provide to you more debug info....

Best,

G.

>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>> And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference: https://pastebin.com/Xy2FL2KL
>> Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the new VM is placed on the other host.
>> Really-really strange why this is happening...
> 
> < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2) ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0] _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
> 
> < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost [host: (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2, cpu2) ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
> 
> cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the result of each weigher like we have for each filter to figure out what's going on with the weighers.
> 
> -- 
> 
> Thanks,
> 
> Matt



From david.ames at canonical.com  Wed Apr 17 22:22:10 2019
From: david.ames at canonical.com (David Ames)
Date: Wed, 17 Apr 2019 15:22:10 -0700
Subject: [charms] OpenStack Charms 19.04 release is available with Stein
 enablement
Message-ID: <CADP3vqQx5Vy2h+nXbAZ1a6OCPtBf-uacqty1PDKpAvN9mhZVsg@mail.gmail.com>

The OpenStack Charms development team is happy to announce the 19.04
charms release, introducing support for OpenStack Stein with Ceph
Mimic on Ubuntu 18.04 (LTS) and Ubuntu 19.04.  This charm release also
brings several new and valuable features to the existing OpenStack
Charms deployments for Queens, Rocky, Stein, and many other stable
combinations of Ubuntu + OpenStack.

For the full release notes, please reference:
    https://docs.openstack.org/charm-guide/latest/1904.html

Some highlights:
* Masakari instance high-availability
* Keystone SSO/SAML integration
* Nova GPU and general device pass-through
* Multi-site replication between Ceph RADOS Gateways
* Mirroring of RBD images across Ceph Clusters

The charms dev team is available on Freenode #openstack-charms, and
will be at the Open Infrastructure Summit and PTG events in Denver, CO
(May 2019).

Huge thanks to the 71 charm contributors who worked together to squash
247 bugs, to enable an entirely new charmed version of OpenStack, and
to move the line forward on several key features!

Ryan Beisner
Frode Nordahl
Liam Young
James Page
Doug Hellmann
David Ames
Corey Bryant
Chris MacNaughton
Paul Goins
Pete Vander Giessen
Alex Kavanagh
Edward Hope-Morley
melissaml
Chris MacNaughton
Sahid Orentino Ferdjaoui
zhouxinyong
Andreas Jaeger
lijunjie
Felipe Reyes
caoyuan
zhulingjie
Vladimir Grevtsev
Dmitrii Shcherbakov
inspurericzhang
Andrew McLeod
Syed Mohammad Adnan Karim
Andre Ruiz
Tiago Pasqualini
Billy Olsen
Drew Freiberger
Seyeong Kim
Hua Zhang
Vu Cong Tuan
wanghui
Trent Lloyd
Przemyslaw Hausman
xulei
Andrea Ieri
Xav Paice
Alvaro Uria
Tytus Kurek
Nikolay Vinogradov
lvxianguo
Nobuto Murata
Nicolas Pochet
Aymen Frikha
Marian Gasparovic
lei zhang
Niels van Adrichem
andy wang
Shane Peters
Jonathan Herlin
Andrey Grebennikov
wangyayan
zhangbailin
Diko Parvanov
Dimos Alevizos
Mike Wilson
David Coronel
Tilman Baumann
MaoyangLiu
gaobin
Jesper M
Gábor Mészáros
Junien Fridrick
Pedro Guimarães
Wouter van Bommel
Abhijeet Patra
Peter Zhang
Barry Price
Dongdong Tao

--
OpenStack Charm Team


From melwittt at gmail.com  Wed Apr 17 22:30:46 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 17 Apr 2019 15:30:46 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
Message-ID: <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>

On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
> Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what the negative value for “ram_weight_multiplier” does ?

No, it's the opposite, higher weights win. That's why you have to use a 
negative value for ram_weight_multiplier if you want hosts with _less_ 
RAM to win over hosts with more RAM (stacking).

> Please let me know how I can provide to you more debug info....

One thing I noticed from your log is on the second request, 'cpu1' has 
io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] will 
prefer hosts with fewer io_iops by default. Note that's only one piece 
of the ending weight -- the weighing process will take a sum of all of 
the weights each weigher returns. So the weight returned from RamWeigher 
is added to the weight returned from IoOpsWeigher is added the weight 
returned from CPUWeigher, and so on.

So, as Matt said, we're a bit in the dark now as far as what each 
weigher is returning and we don't currently have debug logging per 
weigher the way we do for filters. That would be an enhancement we could 
make to aid in debugging issues like this one. You could hack something 
up locally to log/print the returned weight in each weight class under 
the nova/scheduler/weights/ directory, if you want to dig into that.

Another thing I noticed is that there are probably some new weighers 
available by default that did not exist in the previous version of nova 
that you were using in the past. By default, the config option for weighers:

[filter_scheduler]weight_classes = ["nova.scheduler.weights.all_weighers"]

will pick up all weigher classes in the nova/scheduler/weights/ code 
directory. You might take a look at these and see if any are ones you 
should exclude in your environment. For example, the CPUWeigher [1] (new 
in Rocky) will spread VMs based on available CPU by default. This 
weigher might be contributing to the VM spreading you're seeing. You 
might try playing with the '[filter_scheduler]weight_classes' config 
option to select only the weighers you want or alternatively you could 
set the weighers multipliers the way you prefer.

-melanie

[1] https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights

>>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>>> And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference: https://pastebin.com/Xy2FL2KL
>>> Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the new VM is placed on the other host.
>>> Really-really strange why this is happening...
>>
>> < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2) ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0] _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>>
>> < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost [host: (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2, cpu2) ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>>
>> cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the result of each weigher like we have for each filter to figure out what's going on with the weighers.
>>
>> -- 
>>
>> Thanks,
>>
>> Matt
> 






From smooney at redhat.com  Thu Apr 18 00:38:17 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 01:38:17 +0100
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
Message-ID: <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>

On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
> On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis 
> <giorgis at acmac.uoc.gr> wrote:
> > Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what the
> > negative value for “ram_weight_multiplier” does ?
> 
> No, it's the opposite, higher weights win. That's why you have to use a 
> negative value for ram_weight_multiplier if you want hosts with _less_ 
> RAM to win over hosts with more RAM (stacking).
> 
> > Please let me know how I can provide to you more debug info....
> 
> One thing I noticed from your log is on the second request, 'cpu1' has 
> io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] will 
> prefer hosts with fewer io_iops by default. Note that's only one piece 
> of the ending weight -- the weighing process will take a sum of all of 
> the weights each weigher returns. So the weight returned from RamWeigher 
> is added to the weight returned from IoOpsWeigher is added the weight 
> returned from CPUWeigher, and so on.
> 
> So, as Matt said, we're a bit in the dark now as far as what each 
> weigher is returning and we don't currently have debug logging per 
> weigher the way we do for filters. That would be an enhancement we could 
> make to aid in debugging issues like this one. You could hack something 
> up locally to log/print the returned weight in each weight class under 
> the nova/scheduler/weights/ directory, if you want to dig into that.
> 
> Another thing I noticed is that there are probably some new weighers 
> available by default that did not exist in the previous version of nova 
> that you were using in the past. By default, the config option for weighers:
> 
> [filter_scheduler]weight_classes = ["nova.scheduler.weights.all_weighers"]
> 
> will pick up all weigher classes in the nova/scheduler/weights/ code 
> directory. You might take a look at these and see if any are ones you 
> should exclude in your environment. For example, the CPUWeigher [1] (new 
> in Rocky) will spread VMs based on available CPU by default. 
most of the weighers spread by default so the cpu weigher may be a factor but
the the disk weigher tends to all hevily impact the choice.

we do not normalise any of the values retured by the different weighers
the disk wighter is basically  host_state.free_disk_mb * disk_weight_multiplier

althoer host_state.free_disk_mb is actully disk_available_least.

as a result the disk filter will weigh cpu1 19456 height then cpu2
the dela between the cpu1 and cpu2 based on the ram weigher is only 2048

if you want the ram filter to take presedence over teh disk filter you will
need to scale the disk filter down to be in a similar value range

i woudl suggest setting disk_weight_multiplier=0.001

> This 
> weigher might be contributing to the VM spreading you're seeing. You 
> might try playing with the '[filter_scheduler]weight_classes' config 
> option to select only the weighers you want or alternatively you could 
> set the weighers multipliers the way you prefer.
> 
> -melanie
> 
> [1] https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
> 
> > > > On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
> > > > And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference: 
> > > > https://pastebin.com/Xy2FL2KL
> > > > Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the new
> > > > VM is placed on the other host.
> > > > Really-really strange why this is happening...
> > > 
> > > < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
> > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2) ram:
> > > 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0]
> > > _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
> > > 
> > > < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
> > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost [host:
> > > (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2, cpu2)
> > > ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts
> > > /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
> > > 
> > > cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the result of
> > > each weigher like we have for each filter to figure out what's going on with the weighers.
> > > 
> > > -- 
> > > 
> > > Thanks,
> > > 
> > > Matt
> 
> 
> 
> 
> 



From adriant at catalyst.net.nz  Thu Apr 18 01:14:14 2019
From: adriant at catalyst.net.nz (Adrian Turjak)
Date: Thu, 18 Apr 2019 13:14:14 +1200
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
Message-ID: <25f8c208-e9d5-ee51-a256-b66c25a32361@catalyst.net.nz>

>From a billing perspective I'd be interested in helping Ceilometer where
needed, and doing some code review to get more familiar with the service.

When I first started with OpenStack it was in Ceilometer, so it has been
a while, but considering our billing solution relies on it (albeit an
older version), I think making sure it works, and still fulfills what we
need for billing is important!

I don't know if adding me to core yet is a good idea, but feel free to
throw some review patches my way for Ceilometer. :)

On 10/04/19 6:46 PM, Trinh Nguyen wrote:
> Hi team,
>
> As you may know, existing core members of Telemetry cannot work on the
> projects anymore. So, I would like to set up a new core team for
> Telemetry projects in the Train cycle. At the moment, only Lixian Kong
> and I have the core privileges over Ceilometer, AODH, and Panko
> projects. I expect to have 1 more core reviewer to help maintain
> Telemetry. So *please send us your proposal if you're interested*.
>
> This is the current structure of Telemetry:
>
>   * AODH: Lixian Kong is the team lead
>   * Ceilometer and Panko: myself. This is just tempory until we can
>     find someone that has enough experience and willing to take the role.
>
> As discussed in yesterday meeting [1], you may argue that having
> experience does not necessarily qualify for code contributions but
> with the current situation, I would propose "*the willing to help*" as
> the number 1 criteria. We will move forward with it and fix processes
> when we see issues.
>
> Thank all the people that want to keep Telemetry alive.
>
> Yours,
>
> [1] https://etherpad.openstack.org/p/telemetry-train
>
> -- 
> *Trinh Nguyen*
> _www.edlab.xyz <https://www.edlab.xyz>_
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/cffb97fb/attachment.html>

From melwittt at gmail.com  Thu Apr 18 01:24:11 2019
From: melwittt at gmail.com (melanie witt)
Date: Wed, 17 Apr 2019 18:24:11 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
Message-ID: <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>

On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney <smooney at redhat.com> wrote:
> On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
>> On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
>> <giorgis at acmac.uoc.gr> wrote:
>>> Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what the
>>> negative value for “ram_weight_multiplier” does ?
>>
>> No, it's the opposite, higher weights win. That's why you have to use a
>> negative value for ram_weight_multiplier if you want hosts with _less_
>> RAM to win over hosts with more RAM (stacking).
>>
>>> Please let me know how I can provide to you more debug info....
>>
>> One thing I noticed from your log is on the second request, 'cpu1' has
>> io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] will
>> prefer hosts with fewer io_iops by default. Note that's only one piece
>> of the ending weight -- the weighing process will take a sum of all of
>> the weights each weigher returns. So the weight returned from RamWeigher
>> is added to the weight returned from IoOpsWeigher is added the weight
>> returned from CPUWeigher, and so on.
>>
>> So, as Matt said, we're a bit in the dark now as far as what each
>> weigher is returning and we don't currently have debug logging per
>> weigher the way we do for filters. That would be an enhancement we could
>> make to aid in debugging issues like this one. You could hack something
>> up locally to log/print the returned weight in each weight class under
>> the nova/scheduler/weights/ directory, if you want to dig into that.
>>
>> Another thing I noticed is that there are probably some new weighers
>> available by default that did not exist in the previous version of nova
>> that you were using in the past. By default, the config option for weighers:
>>
>> [filter_scheduler]weight_classes = ["nova.scheduler.weights.all_weighers"]
>>
>> will pick up all weigher classes in the nova/scheduler/weights/ code
>> directory. You might take a look at these and see if any are ones you
>> should exclude in your environment. For example, the CPUWeigher [1] (new
>> in Rocky) will spread VMs based on available CPU by default.
> most of the weighers spread by default so the cpu weigher may be a factor but
> the the disk weigher tends to all hevily impact the choice.
> 
> we do not normalise any of the values retured by the different weighers
> the disk wighter is basically  host_state.free_disk_mb * disk_weight_multiplier

Hm, I thought we do based on this code:

https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135

which normalizes the weight to a value between 0.0 and 1.0.

If the multiplier is large though, that could make the considered value 
 > 1.0 (as is the case with the default build_failure_weight_multiplier:

https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501

-melanie

> althoer host_state.free_disk_mb is actully disk_available_least.
> 
> as a result the disk filter will weigh cpu1 19456 height then cpu2
> the dela between the cpu1 and cpu2 based on the ram weigher is only 2048
> 
> if you want the ram filter to take presedence over teh disk filter you will
> need to scale the disk filter down to be in a similar value range
> 
> i woudl suggest setting disk_weight_multiplier=0.001
> 
>> This
>> weigher might be contributing to the VM spreading you're seeing. You
>> might try playing with the '[filter_scheduler]weight_classes' config
>> option to select only the weighers you want or alternatively you could
>> set the weighers multipliers the way you prefer.
>>
>> -melanie
>>
>> [1] https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
>>
>>>>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>>>>> And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference:
>>>>> https://pastebin.com/Xy2FL2KL
>>>>> Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the new
>>>>> VM is placed on the other host.
>>>>> Really-really strange why this is happening...
>>>>
>>>> < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
>>>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2) ram:
>>>> 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0]
>>>> _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>>>>
>>>> < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
>>>> 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost [host:
>>>> (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2, cpu2)
>>>> ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts
>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>>>>
>>>> cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the result of
>>>> each weigher like we have for each filter to figure out what's going on with the weighers.
>>>>
>>>> -- 
>>>>
>>>> Thanks,
>>>>
>>>> Matt
>>
>>
>>
>>
>>
> 






From smooney at redhat.com  Thu Apr 18 01:29:06 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 02:29:06 +0100
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
Message-ID: <76b02b6925d874c3c99c04f66da6f7adf7616930.camel@redhat.com>

On Thu, 2019-04-18 at 01:38 +0100, Sean Mooney wrote:
> On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
> > On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis 
> > <giorgis at acmac.uoc.gr> wrote:
> > > Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what
> > > the
> > > negative value for “ram_weight_multiplier” does ?
> > 
> > No, it's the opposite, higher weights win. That's why you have to use a 
> > negative value for ram_weight_multiplier if you want hosts with _less_ 
> > RAM to win over hosts with more RAM (stacking).
> > 
> > > Please let me know how I can provide to you more debug info....
> > 
> > One thing I noticed from your log is on the second request, 'cpu1' has 
> > io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] will 
> > prefer hosts with fewer io_iops by default. Note that's only one piece 
> > of the ending weight -- the weighing process will take a sum of all of 
> > the weights each weigher returns. So the weight returned from RamWeigher 
> > is added to the weight returned from IoOpsWeigher is added the weight 
> > returned from CPUWeigher, and so on.
> > 
> > So, as Matt said, we're a bit in the dark now as far as what each 
> > weigher is returning and we don't currently have debug logging per 
> > weigher the way we do for filters. That would be an enhancement we could 
> > make to aid in debugging issues like this one. You could hack something 
> > up locally to log/print the returned weight in each weight class under 
> > the nova/scheduler/weights/ directory, if you want to dig into that.
> > 
> > Another thing I noticed is that there are probably some new weighers 
> > available by default that did not exist in the previous version of nova 
> > that you were using in the past. By default, the config option for weighers:
> > 
> > [filter_scheduler]weight_classes = ["nova.scheduler.weights.all_weighers"]
> > 
> > will pick up all weigher classes in the nova/scheduler/weights/ code 
> > directory. You might take a look at these and see if any are ones you 
> > should exclude in your environment. For example, the CPUWeigher [1] (new 
> > in Rocky) will spread VMs based on available CPU by default. 
> 
> most of the weighers spread by default so the cpu weigher may be a factor but
> the the disk weigher tends to all hevily impact the choice.
> 
> we do not normalise any of the values retured by the different weighers
> the disk wighter is basically  host_state.free_disk_mb * disk_weight_multiplier
> 
> althoer host_state.free_disk_mb is actully disk_available_least.
> 
> as a result the disk filter will weigh cpu1 19456 height then cpu2
> the dela between the cpu1 and cpu2 based on the ram weigher is only 2048
> 
> if you want the ram filter to take presedence over teh disk filter you will
> need to scale the disk filter down to be in a similar value range
> 
> i woudl suggest setting disk_weight_multiplier=0.001
actully based on 
https://github.com/openstack/nova/commit/e5ba8494374a1b049eae257fe05b10c5804049ae#diff-365237a9b19e60931b8790a0f7d46f71
we do nomalise however i have had issues with this in the past where i have had to re addjsut the weights
to effectivly renomalise the different weighers.

disk_weight_multiplier=0.001 is proably a little extream


> 
> > This 
> > weigher might be contributing to the VM spreading you're seeing. You 
> > might try playing with the '[filter_scheduler]weight_classes' config 
> > option to select only the weighers you want or alternatively you could 
> > set the weighers multipliers the way you prefer.
> > 
> > -melanie
> > 
> > [1] https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
> > 
> > > > > On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
> > > > > And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference: 
> > > > > https://pastebin.com/Xy2FL2KL
> > > > > Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the
> > > > > new
> > > > > VM is placed on the other host.
> > > > > Really-really strange why this is happening...
> > > > 
> > > > < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
> > > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2) ram:
> > > > 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances:
> > > > 0]
> > > > _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
> > > > 
> > > > < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-377b3d37bff9
> > > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost [host:
> > > > (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2, cpu2)
> > > > ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts
> > > > /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
> > > > 
> > > > cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the result
> > > > of
> > > > each weigher like we have for each filter to figure out what's going on with the weighers.
> > > > 
> > > > -- 
> > > > 
> > > > Thanks,
> > > > 
> > > > Matt
> > 
> > 
> > 
> > 
> > 
> 
> 



From dangtrinhnt at gmail.com  Thu Apr 18 01:32:10 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 18 Apr 2019 10:32:10 +0900
Subject: [telemetry] Update cores team and team lead recruitment
In-Reply-To: <25f8c208-e9d5-ee51-a256-b66c25a32361@catalyst.net.nz>
References: <CADJ6S4FiV4q0K6p6DaVrVL03PNzOKqpKb6JkZYZ1ySzM6iHq-g@mail.gmail.com>
 <25f8c208-e9d5-ee51-a256-b66c25a32361@catalyst.net.nz>
Message-ID: <CADJ6S4EC3Dkv2-JzcjuuMz8LSp4Fci_Hf0jntWNSssPBz7Zyiw@mail.gmail.com>

Hi Adrian,

Thanks for nominating. We absolutely need your help. I will send out and
email at the end of the week.

Yours,

On Thu, Apr 18, 2019 at 10:17 AM Adrian Turjak <adriant at catalyst.net.nz>
wrote:

> From a billing perspective I'd be interested in helping Ceilometer where
> needed, and doing some code review to get more familiar with the service.
>
> When I first started with OpenStack it was in Ceilometer, so it has been a
> while, but considering our billing solution relies on it (albeit an older
> version), I think making sure it works, and still fulfills what we need for
> billing is important!
>
> I don't know if adding me to core yet is a good idea, but feel free to
> throw some review patches my way for Ceilometer. :)
> On 10/04/19 6:46 PM, Trinh Nguyen wrote:
>
> Hi team,
>
> As you may know, existing core members of Telemetry cannot work on the
> projects anymore. So, I would like to set up a new core team for Telemetry
> projects in the Train cycle. At the moment, only Lixian Kong and I have the
> core privileges over Ceilometer, AODH, and Panko projects. I expect to have
> 1 more core reviewer to help maintain Telemetry. So *please send us your
> proposal if you're interested*.
>
> This is the current structure of Telemetry:
>
>    - AODH: Lixian Kong is the team lead
>    - Ceilometer and Panko: myself. This is just tempory until we can find
>    someone that has enough experience and willing to take the role.
>
> As discussed in yesterday meeting [1], you may argue that having
> experience does not necessarily qualify for code contributions but with the
> current situation, I would propose "*the willing to help*" as the number
> 1 criteria. We will move forward with it and fix processes when we see
> issues.
>
> Thank all the people that want to keep Telemetry alive.
>
> Yours,
>
> [1] https://etherpad.openstack.org/p/telemetry-train
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/5bdb4e7b/attachment.html>

From dangtrinhnt at gmail.com  Thu Apr 18 01:35:17 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Thu, 18 Apr 2019 10:35:17 +0900
Subject: [telemetry] Nominating Rong Zhu for Telemetry core
In-Reply-To: <CALjNAZ1ZAnZ6X8evePypRh7RRigvFM00j7SAiwob84KSX3uhdg@mail.gmail.com>
References: <CADJ6S4G3w289z3idOjar9m96iQpgV4MV4mzu61_ErS1UbYT=hA@mail.gmail.com>
 <CALjNAZ1ZAnZ6X8evePypRh7RRigvFM00j7SAiwob84KSX3uhdg@mail.gmail.com>
Message-ID: <CADJ6S4Hw1uXD=ZZaVEnUbbnAR3fQn80Hew+JzyJHDNAUb_MXiQ@mail.gmail.com>

Hi Rong Zhu,

Welcome to the team :)

Yours,

On Sat, Apr 13, 2019 at 1:43 PM Lingxian Kong <anlin.kong at gmail.com> wrote:

> +1, welcome!
>
> ---
> Cheers,
> Lingxian Kong
> Catalyst Cloud
>
>
> On Sat, Apr 13, 2019 at 4:20 AM Trinh Nguyen <dangtrinhnt at gmail.com>
> wrote:
>
>> Hi team,
>>
>> I'd like to nominate Rong Zhu (zhurong) to become a Telemetry core.
>>
>> Rong Zhu has been contributing to OpenStack for a while now [1] and
>> sometimes jump in to help Telemetry projects fix bugs. While being the PTL
>> of Murano and Solum projects [2], his experience and network of developers
>> working on ceilometer/aodh projects would be a huge benefit for the team.
>>
>> [1]
>> https://review.openstack.org/#/q/owner:%22zhurong+%253Caaronzhu1121%2540gmail.com%253E%22
>> [2] https://governance.openstack.org/election/results/train/ptl.html
>>
>> Let give +1 for your agreement.
>>
>> Yours,
>>
>>
>> --
>> *Trinh Nguyen*
>> *www.edlab.xyz <https://www.edlab.xyz>*
>>
>>

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/3f842946/attachment.html>

From aaronzhu1121 at gmail.com  Thu Apr 18 01:38:06 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Thu, 18 Apr 2019 09:38:06 +0800
Subject: [telemetry] Nominating Rong Zhu for Telemetry core
In-Reply-To: <CADJ6S4Hw1uXD=ZZaVEnUbbnAR3fQn80Hew+JzyJHDNAUb_MXiQ@mail.gmail.com>
References: <CADJ6S4G3w289z3idOjar9m96iQpgV4MV4mzu61_ErS1UbYT=hA@mail.gmail.com>
 <CALjNAZ1ZAnZ6X8evePypRh7RRigvFM00j7SAiwob84KSX3uhdg@mail.gmail.com>
 <CADJ6S4Hw1uXD=ZZaVEnUbbnAR3fQn80Hew+JzyJHDNAUb_MXiQ@mail.gmail.com>
Message-ID: <CAN2nDNud9a0JZs_PT=ZDZZ+MYvnvBov=oK-wHxw28mxFLGPu1A@mail.gmail.com>

Thanks, Trinh Nguyen and Lingxian.

Regards,
Rong Zhu

Trinh Nguyen <dangtrinhnt at gmail.com>于2019年4月18日 周四09:35写道：

> Hi Rong Zhu,
>
> Welcome to the team :)
>
> Yours,
>
> On Sat, Apr 13, 2019 at 1:43 PM Lingxian Kong <anlin.kong at gmail.com>
> wrote:
>
>> +1, welcome!
>>
>> ---
>> Cheers,
>> Lingxian Kong
>> Catalyst Cloud
>>
>>
>> On Sat, Apr 13, 2019 at 4:20 AM Trinh Nguyen <dangtrinhnt at gmail.com>
>> wrote:
>>
>>> Hi team,
>>>
>>> I'd like to nominate Rong Zhu (zhurong) to become a Telemetry core.
>>>
>>> Rong Zhu has been contributing to OpenStack for a while now [1] and
>>> sometimes jump in to help Telemetry projects fix bugs. While being the PTL
>>> of Murano and Solum projects [2], his experience and network of developers
>>> working on ceilometer/aodh projects would be a huge benefit for the team.
>>>
>>> [1]
>>> https://review.openstack.org/#/q/owner:%22zhurong+%253Caaronzhu1121%2540gmail.com%253E%22
>>> [2] https://governance.openstack.org/election/results/train/ptl.html
>>>
>>> Let give +1 for your agreement.
>>>
>>> Yours,
>>>
>>>
>>> --
>>> *Trinh Nguyen*
>>> *www.edlab.xyz <https://www.edlab.xyz>*
>>>
>>>
>
> --
> *Trinh Nguyen*
> *www.edlab.xyz <https://www.edlab.xyz>*
>
> --
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/4dc8103c/attachment-0001.html>

From smooney at redhat.com  Thu Apr 18 02:14:35 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 03:14:35 +0100
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
Message-ID: <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>

On Wed, 2019-04-17 at 18:24 -0700, melanie witt wrote:
> On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney <smooney at redhat.com> wrote:
> > On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
> > > On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
> > > <giorgis at acmac.uoc.gr> wrote:
> > > > Shouldn’t that be the correct behavior and place the new VM on the host with the smaller weight? Isn’t that what
> > > > the
> > > > negative value for “ram_weight_multiplier” does ?
> > > 
> > > No, it's the opposite, higher weights win. That's why you have to use a
> > > negative value for ram_weight_multiplier if you want hosts with _less_
> > > RAM to win over hosts with more RAM (stacking).
> > > 
> > > > Please let me know how I can provide to you more debug info....
> > > 
> > > One thing I noticed from your log is on the second request, 'cpu1' has
> > > io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] will
> > > prefer hosts with fewer io_iops by default. Note that's only one piece
> > > of the ending weight -- the weighing process will take a sum of all of
> > > the weights each weigher returns. So the weight returned from RamWeigher
> > > is added to the weight returned from IoOpsWeigher is added the weight
> > > returned from CPUWeigher, and so on.
> > > 
> > > So, as Matt said, we're a bit in the dark now as far as what each
> > > weigher is returning and we don't currently have debug logging per
> > > weigher the way we do for filters. That would be an enhancement we could
> > > make to aid in debugging issues like this one. You could hack something
> > > up locally to log/print the returned weight in each weight class under
> > > the nova/scheduler/weights/ directory, if you want to dig into that.
> > > 
> > > Another thing I noticed is that there are probably some new weighers
> > > available by default that did not exist in the previous version of nova
> > > that you were using in the past. By default, the config option for weighers:
> > > 
> > > [filter_scheduler]weight_classes = ["nova.scheduler.weights.all_weighers"]
> > > 
> > > will pick up all weigher classes in the nova/scheduler/weights/ code
> > > directory. You might take a look at these and see if any are ones you
> > > should exclude in your environment. For example, the CPUWeigher [1] (new
> > > in Rocky) will spread VMs based on available CPU by default.
> > 
> > most of the weighers spread by default so the cpu weigher may be a factor but
> > the the disk weigher tends to all hevily impact the choice.
> > 
> > we do not normalise any of the values retured by the different weighers
> > the disk wighter is basically  host_state.free_disk_mb * disk_weight_multiplier
> 
> Hm, I thought we do based on this code:
> 
> https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135
> 
> which normalizes the weight to a value between 0.0 and 1.0.
yes we do but that is witnin the same resouce type.

we do not normalise between resoucser types.
on a typical host you will have between 2GB and 8GB of ram per cpu core
and you will have between 10G and 100G of local disk typically.

so we dont look at the capasity of each resouce and renomalise between them.
if you want achive that you have to carefully tweek the weights to do that manually.

that said i have not sat down and worked out the math to do that in about 3-4 years
but i think i used to run my dev clouster with the disk_weight_multiplier around 0.04
and i think i used to set the ram_weight_multiplier to 2.0

anyway that is just my personal experience and i was trying to tweek the spreading behavior
to spread based on ram then cpus then disk rather then pack based on ram but spread based on the rest.
so i dont know if this is relvent or correct for this usecase.
 
> 
> If the multiplier is large though, that could make the considered value 
>  > 1.0 (as is the case with the default build_failure_weight_multiplier:
> 
> https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501
> 
> -melanie
> 
> > althoer host_state.free_disk_mb is actully disk_available_least.
> > 
> > as a result the disk filter will weigh cpu1 19456 height then cpu2
> > the dela between the cpu1 and cpu2 based on the ram weigher is only 2048
> > 
> > if you want the ram filter to take presedence over teh disk filter you will
> > need to scale the disk filter down to be in a similar value range
> > 
> > i woudl suggest setting disk_weight_multiplier=0.001
> > 
> > > This
> > > weigher might be contributing to the VM spreading you're seeing. You
> > > might try playing with the '[filter_scheduler]weight_classes' config
> > > option to select only the weighers you want or alternatively you could
> > > set the weighers multipliers the way you prefer.
> > > 
> > > -melanie
> > > 
> > > [1] https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
> > > 
> > > > > > On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
> > > > > > And here is the new log where spawning of 2 VMs can be seen with a few seconds of difference:
> > > > > > https://pastebin.com/Xy2FL2KL
> > > > > > Initially both hosts are of weight 1.0 then the one with one VM already running has negative weight but the
> > > > > > new
> > > > > > VM is placed on the other host.
> > > > > > Really-really strange why this is happening...
> > > > > 
> > > > > < 2019-04-17 23:26:18.770 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
> > > > > 377b3d37bff9
> > > > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, cpu2)
> > > > > ram:
> > > > > 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances:
> > > > > 0]
> > > > > _get_sorted_hosts /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
> > > > > 
> > > > > < 2019-04-17 23:26:18.771 157355 DEBUG nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
> > > > > 377b3d37bff9
> > > > > 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed [WeighedHost
> > > > > [host:
> > > > > (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 instances: 0, weight: 1.0], WeighedHost [host: (cpu2,
> > > > > cpu2)
> > > > > ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: -0.00900862553213]] _get_sorted_hosts
> > > > > /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
> > > > > 
> > > > > cpu1 is definitely getting weighed higher but I'm not sure why. We likely need some debug logging on the
> > > > > result of
> > > > > each weigher like we have for each filter to figure out what's going on with the weighers.
> > > > > 
> > > > > -- 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Matt
> > > 
> > > 
> > > 
> > > 
> > > 
> 
> 
> 
> 



From iain.macdonnell at oracle.com  Thu Apr 18 05:48:51 2019
From: iain.macdonnell at oracle.com (iain.macdonnell at oracle.com)
Date: Wed, 17 Apr 2019 22:48:51 -0700
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running under
 uWSGI
Message-ID: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>


Is anyone running Stein nova-api under uWSGI? I'm trying to do this, in 
exactly the same way as I did with Rocky, but encountering a new problem...

The symptom is intermittent failure of API operations that involve RPC 
calls - notably getting the noVNC console URL for an instance. The 
nova-api log shows RPC timeouts and "connection reset by peer" for AMQP. 
I've ruled out environmental issues, as a Rocky installation on the same 
hosts works fine. With oslo debug enabled, I see that the first API call 
causes a AMQP connections to be established, and the RPC call gets its 
reply, and all is well... but there are no heartbeats logged after that. 
3 minutes later, rabbitmq-server reports that it has received no 
heartbeats, and drops the connection. On a subsequent API call (but not 
before), nova-api logging "connection reset by peer" and the RPC call 
times out. With the Rocky code, once the first API call causes the AMQP 
connections to be established, regular heartbeats start happening, the 
connections are maintained, and subsequent API calls work as expected.

It seems like a lockup in a thread that's supposed to maintain the AMQP 
connection, or something. I tried to use SIGUSR2 to trigger guru 
meditation, but it seems that uWSGI has its own interpretation of 
SIGUSR2, so nova-api never sees it (anyone know a way around this?).

Running nova-api as a standalone service, instead of under uWSGI, the 
problem does not occur (I see the heartbeats, and everything works fine).

I've tried updating oslo-messaging (and python-amqp) on a Rocky 
installation to the Stein version, but the problem does not reproduce.

Ideas?

     ~iain




From tomi.juvonen at nokia.com  Thu Apr 18 06:28:22 2019
From: tomi.juvonen at nokia.com (Juvonen, Tomi (Nokia - FI/Espoo))
Date: Thu, 18 Apr 2019 06:28:22 +0000
Subject: [fenix][forum][ptg]
Message-ID: <HE1PR0701MB270048D2EFCE31970BB52A4685260@HE1PR0701MB2700.eurprd07.prod.outlook.com>

Hi,

If you did not yet know Fenix:
      Fenix - rolling infrastructure maintenance and upgrade with VNF interaction to guarantee zero impact.
      https://wiki.openstack.org/wiki/Fenix

Now there has been the rolling OpenStack upgrade with zero impact to VNF showcased in ONS America two weeks ago and it is time to look the Train and the way forward. Most importantly to harmonize with ETSI NFV and prioritize the work to have a solid base after this cycle.

Here is etherpad for the forum:
      Fenix project update, future, discuss
      Tue 30th April, 9:00am - 9:40am The Colorado Convention Center - Ballroom Level - 4B
      https://etherpad.openstack.org/p/DEN-fenix-forum-brainstorming

Here are etherpads for the PTG:
      Fenix and ETSI NFV synch:
      Sat 4th May, 10:00am - 11:00am
      https://etherpad.openstack.org/p/DEN2019-fenix-ETSI-NFV-PTG

      Fenix Train PTG, What to do next, prioritizing
      Sat 4th May, 11:10am - 12:10am
      https://etherpad.openstack.org/p/DEN2019-fenix-PTG

br,
Tomi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/37d3ce58/attachment.html>

From rico.lin.guanyu at gmail.com  Thu Apr 18 07:05:44 2019
From: rico.lin.guanyu at gmail.com (Rico Lin)
Date: Thu, 18 Apr 2019 15:05:44 +0800
Subject: Scuba Diving at the Denver Summit
In-Reply-To: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
References: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
Message-ID: <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>

We usually need to reraise important stuff before Summit. So bump this
one!:) Can't wait!

On Wed, Jan 23, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com> wrote:

> Hey everybody!
>
> tl;dr - Let me know if you'd like to go diving in the Rocky Mountains.
>
> Of all of the places we've had a Summit where one might reasonably
> expect there to be a possibility of Scuba Diving, the Denver Summit is
> probably REALLY low on the list.
>
> But it turns out that there is a Dive Shop that does dives at the Denver
> Aquarium [0] (with all the fish and sharks and whatnot) The Denver
> Aquarium is also very close to the Convention Center.
>
> I'm going to see about putting together a private group dive event for
> those of us who think that sounds like a fun idea. Due to
> cross-contamination concerns for the health and safety of the fish, the
> dive shop provides all equipment - so you don't have to bring gear. They
> will allow bringing your own mask - and I'm assuming if a well-scrubbed
> mask is ok then a well-scrubbed dive computer would be ok - but I'll be
> checking with them when I call to arrange things.
>
> If you are Open Water certified and would like to join, please send me a
> response back (reply directly to me rather than the list is fine) so I
> can judge general interest level when talking to the lovely humans.
>
> If you are **NOT** Open Water certified but are thinking to yourself
> "wow, that sounds like fun" - the dive shop does certification dives at
> the aquarium on the weekends. That's a bit out of scope for me to
> arrange, but if you want to show up in Denver early and do an Open Water
> class then join us, that's awesome. You can also get certified at home
> before coming ... but you'll need an Open Water certification to join us.
>
> BUT WAIT - THERE'S MORE!
>
> There is another interesting diving opportunity in the general Mountain
> West area - although not immediately **close** to Denver - that Sandy
> and I are going to be going to before the Summit - Homestead Crater.
> We're arranging to meet a Scuba instructor there to do our second
> Altitude cert dive, and also to do a 2-dive "Hot Springs Diver"
> specialty. We'd be happy to have folks join us.
>
> Homestead Crater [1] is outside of Salt Lake City. It's a hot spring -
> the water is 96F/35.5C and it's also an altitude dive. If people are
> interested, we can meet at the crater on Thursday morning pre-summit,
> dive the crater, then drive to Denver on Friday/Saturday.
>
> ** If only a small number of people are interested in any of this -
> we'll likely just do the Denver dives the weekend before during one of
> the normally scheduled dive times instead of arranging a group outing,
> and shift Homestead, if anyone is interested, a few days earlier **
>
> I will not have space enough in my car to get you from the crater to
> Denver, so if you want to fly in to SLC ahead of time and meet there,
> awesome.
>
> Unlike Denver, the crater will require you have equipment, including
> scuba tanks. For anyone interested in coming, there are dive shops in
> Salt Lake where you can rent gear. There is a dive shop at the crater to
> do air fills.
>
> Anyway - if anyone is interested in some or all of these things, let me
> know this week so I can get a headcount and then we can talk more
> off-list about logistics and figure out how to deal with things for
> people coming from far off (carpools, equipment, etc)
>
> Monty
>
> PS. If any of you aren't already using Subsurface for dive logging, I'll
> be happy to help you get set up.
>
> [0] https://divedowntown.com/
> [1] https://homesteadresort.com/utah-resort-things-to-do/homestead-crater/
>
>

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/8c695892/attachment-0001.html>

From openstack at gmx.net  Thu Apr 18 07:18:21 2019
From: openstack at gmx.net (Marc Vorwerk)
Date: Thu, 18 Apr 2019 09:18:21 +0200
Subject: [murano] Galera Table package_to_tag has no PRIMARY_KEY
Message-ID: <638FC97A-29FA-4CF7-A572-8D286E5C0FF4@gmx.net>

Hello,



uploading an application to Murano fails after upgrading "percona-xtradb-cluster-common-5.6" to "percona-xtradb-cluster-common-5.7":



Importing package io.murano

Error {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, "error": {"message": "(pymysql.err.InternalError) (1105, u'Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u'INSERT INTO package_to_tag (package_id, tag_id) VALUES (%(package_id)s, %(tag_id)s)'] [parameters: {'package_id': 'a345ab1fe4924aaf8ed32f954a6fe32d', 'tag_id': '0cb3765d7fe1486ba9741f4eb9b2a437'}]", "traceback": null, "type": "DBError"}, "title": "Internal Server Error"} (HTTP 500) occurred while installing package io.murano



If i looks on the galera table, i get the following information:



$ mysql -u murano -p



mysql> Use murano;

mysql> INSERT INTO package_to_tag (package_id, tag_id) VALUES (a345ab1fe4924aaf8ed32f954a6fe32d, 0cb3765d7fe1486ba9741f4eb9b2a437);

ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

mysql> SHOW KEYS FROM package_to_tag WHERE Key_name = 'PRIMARY';

Empty set (0.00 sec)



My package list:



$pkg -l | grep -e mysql -e percona

root at control02ve:~# dpkg -l | grep -e mysql -e percona

ii  libdbd-mysql-perl                     4.033-1ubuntu0.1                           amd64        Perl5 database interface to the MySQL database

ii  libmysqlclient20:amd64                5.7.25-0ubuntu0.16.04.2                    amd64        MySQL database client library

ii  mysql-common                          5.7.25-0ubuntu0.16.04.2                    all          MySQL database common files, e.g. /etc/mysql/my.cnf

ii  percona-release                       1.0-11.generic                             all          Package to install Percona gpg key and APT repos

ii  percona-xtrabackup-24                 2.4.13-1.xenial                            amd64        Open source backup tool for InnoDB and XtraDB

ii  percona-xtradb-cluster-client-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database client binaries

ii  percona-xtradb-cluster-common-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database common files (e.g. /etc/mysql/my.cnf)

ii  percona-xtradb-cluster-galera-3.x     3.32-1.xenial                              amd64        Galera components of Percona XtraDB Cluster

ii  percona-xtradb-cluster-server-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database server binaries

ii  python-mysqldb                        1.3.7-1build2                              amd64        Python interface to MySQL

ii  python-pymysql                        0.7.11-1~cloud0                            all          Pure-Python MySQL driver - Python 2.x



Murano is installed in the latest version of queens (https://github.com/openstack/murano/tree/stable/queens).



Has anyone an idea?



Best Regards,

Marc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/f6a140a6/attachment.html>

From aaronzhu1121 at gmail.com  Thu Apr 18 07:39:14 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Thu, 18 Apr 2019 15:39:14 +0800
Subject: [murano] Galera Table package_to_tag has no PRIMARY_KEY
In-Reply-To: <638FC97A-29FA-4CF7-A572-8D286E5C0FF4@gmx.net>
References: <638FC97A-29FA-4CF7-A572-8D286E5C0FF4@gmx.net>
Message-ID: <CAN2nDNugcv6UM3zOzi+UaqYqc638NvouvUyK1ZYhEruw0CiCoQ@mail.gmail.com>

Hi Marc,


Glad to hear you are using murano.
I googled this, the reason is Percona using pxc_strict_mode = ENFORCING
will catch error when table without primary keys. package_to_tag table
don't have a primary key. I think you can set the mode Permissive.

[0]
https://www.percona.com/doc/percona-xtradb-cluster/LATEST/features/pxc-strict-mode.html
[1]
https://www.percona.com/forums/questions-discussions/percona-xtradb-cluster/47107-dml-command-rejected-when-pxc-mode-set-to-enforcing


Thanks,
Rong Zhu

Marc Vorwerk <openstack at gmx.net>于2019年4月18日 周四15:19写道：

> Hello,
>
>
>
> uploading an application to Murano fails after upgrading
> "percona-xtradb-cluster-common-5.6" to "percona-xtradb-cluster-common-5.7":
>
>
>
> Importing package io.murano
>
> Error {"explanation": "The server has either erred or is incapable of
> performing the requested operation.", "code": 500, "error": {"message":
> "(pymysql.err.InternalError) (1105, u'Percona-XtraDB-Cluster prohibits use
> of DML command on a table (murano.package_to_tag) without an explicit
> primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u'INSERT
> INTO package_to_tag (package_id, tag_id) VALUES (%(package_id)s,
> %(tag_id)s)'] [parameters: {'package_id':
> 'a345ab1fe4924aaf8ed32f954a6fe32d', 'tag_id':
> '0cb3765d7fe1486ba9741f4eb9b2a437'}]", "traceback": null, "type":
> "DBError"}, "title": "Internal Server Error"} (HTTP 500) occurred while
> installing package io.murano
>
>
>
> If i looks on the galera table, i get the following information:
>
>
>
> $ mysql -u murano -p
>
>
>
> mysql> Use murano;
>
> mysql> INSERT INTO package_to_tag (package_id, tag_id) VALUES
> (a345ab1fe4924aaf8ed32f954a6fe32d, 0cb3765d7fe1486ba9741f4eb9b2a437);
>
> ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on
> a table (murano.package_to_tag) without an explicit primary key with
> pxc_strict_mode = ENFORCING or MASTER
>
> mysql> SHOW KEYS FROM package_to_tag WHERE Key_name = 'PRIMARY';
>
> Empty set (0.00 sec)
>
>
>
> My package list:
>
>
>
> $pkg -l | grep -e mysql -e percona
>
> root at control02ve:~# dpkg -l | grep -e mysql -e percona
>
> ii  libdbd-mysql-perl
> 4.033-1ubuntu0.1                           amd64        Perl5 database
> interface to the MySQL database
>
> ii  libmysqlclient20:amd64
> 5.7.25-0ubuntu0.16.04.2                    amd64        MySQL database
> client library
>
> ii  mysql-common
> 5.7.25-0ubuntu0.16.04.2                    all          MySQL database
> common files, e.g. /etc/mysql/my.cnf
>
> ii  percona-release
> 1.0-11.generic                             all          Package to install
> Percona gpg key and APT repos
>
> ii  percona-xtrabackup-24
> 2.4.13-1.xenial                            amd64        Open source backup
> tool for InnoDB and XtraDB
>
> ii  percona-xtradb-cluster-client-5.7
> 5.7.25-31.35-1.xenial                      amd64        Percona XtraDB
> Cluster database client binaries
>
> ii  percona-xtradb-cluster-common-5.7
> 5.7.25-31.35-1.xenial                      amd64        Percona XtraDB
> Cluster database common files (e.g. /etc/mysql/my.cnf)
>
> ii  percona-xtradb-cluster-galera-3.x
> 3.32-1.xenial                              amd64        Galera components
> of Percona XtraDB Cluster
>
> ii  percona-xtradb-cluster-server-5.7
> 5.7.25-31.35-1.xenial                      amd64        Percona XtraDB
> Cluster database server binaries
>
> ii  python-mysqldb
> 1.3.7-1build2                              amd64        Python interface to
> MySQL
>
> ii  python-pymysql
> 0.7.11-1~cloud0                            all          Pure-Python MySQL
> driver - Python 2.x
>
>
>
> Murano is installed in the latest version of queens (
> https://github.com/openstack/murano/tree/stable/queens).
>
>
>
> Has anyone an idea?
>
>
>
> Best Regards,
>
> Marc
>
>
>
-- 
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/0c3e2c61/attachment-0001.html>

From dciabrin at redhat.com  Thu Apr 18 07:48:08 2019
From: dciabrin at redhat.com (Damien Ciabrini)
Date: Thu, 18 Apr 2019 09:48:08 +0200
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
Message-ID: <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>

On Thu, Apr 18, 2019 at 7:51 AM <iain.macdonnell at oracle.com> wrote:

>
> Is anyone running Stein nova-api under uWSGI? I'm trying to do this, in
> exactly the same way as I did with Rocky, but encountering a new problem...
>
>
This sounds similar to a problem that we're currently debugging with John
Eckersberg and Michele Baldessari (in CC) in Stein, but when nova-api runs
under Apache mod_wsgi.

The symptoms for us seem similar: sometimes the scheduling of the AMQP
heartbeat greenlet seems heratic (no run for 75 seconds), RabbitMQ
drops the connection to the client during this idle period, and next time
nova-api needs to communicate over AMQP it logs a "connection reset
by peer" and reestablish a new connection.

This is fresh news from yesterday so this is still to be
confirmed/disproved;
but currently we're investigating how eventlet schedules recurring tasks
such as the AMQP heartbeat greenlet under Apache mod_wsgi's execution
model.

Once the AMQP heartbeat greenlet has sent its heartbeat, it sleeps for a
fixed amount of time; i.e. it suspends its execution, eventlet registers a
timer
for this greenlet, and continues scheduling other greenlets. Once the timer
expires, eventlet marks the heartbeat greenlet as "eligible for scheduling"
and eventually this greenlet resumes its execution.
For that mechanism to work, eventlet regularly watches for all the timers
that are registered in its event loop (with select/epoll/whatnot).

Now, Apache mod_wsgi embeds its own Python interpreter, and calls it
whenever there's an API call to process. It seems that - the precise course
of event is unclear to me yet - once the API call is processed, the Python
Interpreter returns a result to mod_wsgi and stops its execution even if
some timers were still registered in eventlet.

The state of the Python Interpreter is conserved though, and next time
mod_wsgi receives an API call, it resumes the execution of the Python
Interpreter: eventlet resumes its execution and process every timer
that were registered previously. So ultimately, the AMQP heartbeat
greenlet is rescheduled, but that might be a long time already since the
last AMQP heartbeat.

So I have the feeling that when there's no traffic, mod_wsgi doesn't execute
the Python interpreter, which prevents eventlet from running, watching for
timers, and triggering the AMQP heartbeat greenlet. So far, the evidences
in favour of this theory are:
  . When there's no traffic for nova-api running under mod_wsgi, and I use
    gdb to dump the call stack of the mod_wsgi process, I see no CPython
    interpreter in the stack. Whereas when there's traffic, I see many
CPython
    stack frames.
  . When there's no traffic to nova-api and the AMQP heartbeat greenlet seem
    to be unscheduled for a long time, running a simple 'nova list' command
    seems to unblock everything and trigger a AMQP heartbeat.

This would also explain why running the nova-api service in standalone works
just fine as you said. because the Python interpreter is never stopped in
this
execution model.

I'm still trying to figure out when the Python interpreter returns to
mod_wsgi
to make sure what I'm saying makes sense. And I also need to double check
that running in standalone works fine for me as well.

The symptom is intermittent failure of API operations that involve RPC
> calls - notably getting the noVNC console URL for an instance. The
> nova-api log shows RPC timeouts and "connection reset by peer" for AMQP.
> I've ruled out environmental issues, as a Rocky installation on the same
> hosts works fine. With oslo debug enabled, I see that the first API call
> causes a AMQP connections to be established, and the RPC call gets its
> reply, and all is well... but there are no heartbeats logged after that.
> 3 minutes later, rabbitmq-server reports that it has received no
> heartbeats, and drops the connection. On a subsequent API call (but not
> before), nova-api logging "connection reset by peer" and the RPC call
> times out. With the Rocky code, once the first API call causes the AMQP
> connections to be established, regular heartbeats start happening, the
> connections are maintained, and subsequent API calls work as expected.
>
> It seems like a lockup in a thread that's supposed to maintain the AMQP
> connection, or something. I tried to use SIGUSR2 to trigger guru
> meditation, but it seems that uWSGI has its own interpretation of
> SIGUSR2, so nova-api never sees it (anyone know a way around this?).
>
> Running nova-api as a standalone service, instead of under uWSGI, the
> problem does not occur (I see the heartbeats, and everything works fine).
>
> I've tried updating oslo-messaging (and python-amqp) on a Rocky
> installation to the Stein version, but the problem does not reproduce.
>
> Ideas?
>
>      ~iain
>
>
>
>

-- 
Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/960d09c1/attachment.html>

From openstack at gmx.net  Thu Apr 18 08:18:34 2019
From: openstack at gmx.net (Marc Vorwerk)
Date: Thu, 18 Apr 2019 10:18:34 +0200
Subject: [murano] Galera Table package_to_tag has no PRIMARY_KEY
In-Reply-To: <CAN2nDNugcv6UM3zOzi+UaqYqc638NvouvUyK1ZYhEruw0CiCoQ@mail.gmail.com>
References: <638FC97A-29FA-4CF7-A572-8D286E5C0FF4@gmx.net>
 <CAN2nDNugcv6UM3zOzi+UaqYqc638NvouvUyK1ZYhEruw0CiCoQ@mail.gmail.com>
Message-ID: <413B8FE7-497A-40EE-9218-DCCB29CBD8E4@gmx.net>

Hi Rong,

 

thank you for your answer!

 

I will test it with changing the pxc_strict_mode.

 

But in your second link I can read that it would be better to add a PRIMARY_KEY to the table?

 

Best regards,

 

Marc

 

 

Von: Rong Zhu <aaronzhu1121 at gmail.com>
Datum: Donnerstag, 18. April 2019 um 09:40
An: <openstack-discuss at lists.openstack.org>
Betreff: Re: [murano] Galera Table package_to_tag has no PRIMARY_KEY

 

Hi Marc,

 

 

Glad to hear you are using murano.

I googled this, the reason is Percona using pxc_strict_mode = ENFORCING will catch error when table without primary keys. package_to_tag table don't have a primary key. I think you can set the mode Permissive.

 

[0] https://www.percona.com/doc/percona-xtradb-cluster/LATEST/features/pxc-strict-mode.html

[1] https://www.percona.com/forums/questions-discussions/percona-xtradb-cluster/47107-dml-command-rejected-when-pxc-mode-set-to-enforcing

 

 

Thanks,

Rong Zhu

 

Marc Vorwerk <openstack at gmx.net>于2019年4月18日 周四15:19写道：

Hello,

 

uploading an application to Murano fails after upgrading "percona-xtradb-cluster-common-5.6" to "percona-xtradb-cluster-common-5.7":

 

Importing package io.murano

Error {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, "error": {"message": "(pymysql.err.InternalError) (1105, u'Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u'INSERT INTO package_to_tag (package_id, tag_id) VALUES (%(package_id)s, %(tag_id)s)'] [parameters: {'package_id': 'a345ab1fe4924aaf8ed32f954a6fe32d', 'tag_id': '0cb3765d7fe1486ba9741f4eb9b2a437'}]", "traceback": null, "type": "DBError"}, "title": "Internal Server Error"} (HTTP 500) occurred while installing package io.murano

 

If i looks on the galera table, i get the following information:

 

$ mysql -u murano -p

 

mysql> Use murano;

mysql> INSERT INTO package_to_tag (package_id, tag_id) VALUES (a345ab1fe4924aaf8ed32f954a6fe32d, 0cb3765d7fe1486ba9741f4eb9b2a437);

ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

mysql> SHOW KEYS FROM package_to_tag WHERE Key_name = 'PRIMARY';

Empty set (0.00 sec)

 

My package list:

 

$pkg -l | grep -e mysql -e percona

root at control02ve:~# dpkg -l | grep -e mysql -e percona

ii  libdbd-mysql-perl                     4.033-1ubuntu0.1                           amd64        Perl5 database interface to the MySQL database

ii  libmysqlclient20:amd64                5.7.25-0ubuntu0.16.04.2                    amd64        MySQL database client library

ii  mysql-common                          5.7.25-0ubuntu0.16.04.2                    all          MySQL database common files, e.g. /etc/mysql/my.cnf

ii  percona-release                       1.0-11.generic                             all          Package to install Percona gpg key and APT repos

ii  percona-xtrabackup-24                 2.4.13-1.xenial                            amd64        Open source backup tool for InnoDB and XtraDB

ii  percona-xtradb-cluster-client-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database client binaries

ii  percona-xtradb-cluster-common-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database common files (e.g. /etc/mysql/my.cnf)

ii  percona-xtradb-cluster-galera-3.x     3.32-1.xenial                              amd64        Galera components of Percona XtraDB Cluster

ii  percona-xtradb-cluster-server-5.7     5.7.25-31.35-1.xenial                      amd64        Percona XtraDB Cluster database server binaries

ii  python-mysqldb                        1.3.7-1build2                              amd64        Python interface to MySQL

ii  python-pymysql                        0.7.11-1~cloud0                            all          Pure-Python MySQL driver - Python 2.x

 

Murano is installed in the latest version of queens (https://github.com/openstack/murano/tree/stable/queens).

 

Has anyone an idea?

 

Best Regards,

Marc

 

-- 

Thanks,
Rong Zhu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/6662037f/attachment-0001.html>

From ltoscano at redhat.com  Thu Apr 18 08:40:57 2019
From: ltoscano at redhat.com (Luigi Toscano)
Date: Thu, 18 Apr 2019 10:40:57 +0200
Subject: [sahara] Sahara meeting April 18 - volunteer chair? (or cancel?)
In-Reply-To: <CAFntmSicCgSFg2oZ9P2d6ZNAkVHvRSiePZKQfV=GRNCMRxCB-Q@mail.gmail.com>
References: <CAFntmSicCgSFg2oZ9P2d6ZNAkVHvRSiePZKQfV=GRNCMRxCB-Q@mail.gmail.com>
Message-ID: <27784755.qKaqT3Wa9e@whitebase.usersys.redhat.com>

On Wednesday, 17 April 2019 23:05:22 CEST Jeremy Freudberg wrote:
> I have a personal conflict and will not be around to run the Sahara
> meeting on April 18 (tomorrow).
> 
> There isn't too much to discuss, so I'm comfortable letting it be
> cancelled. But if there is any volunteer chair, the meeting can still
> run.
> 

I don't have new updates from last week (I didn't touch the *wsgi patches), so 
maybe we can cancel. In any case, I will be around in case anyone asks for it.

Just a notice: I prepared the s/git.openstack.org/opendev.org/ changes which 
should extend the fixes which will provided by -infra, but it's better to wait 
for the migration before sending them. After that, please merge them if they 
pass.

Ciao
-- 
Luigi




From natal at redhat.com  Thu Apr 18 08:51:47 2019
From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=)
Date: Thu, 18 Apr 2019 10:51:47 +0200
Subject: The python black project.
Message-ID: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>

Hi everyone,

Black is project to format Python code. It's more and more used by the python
community. That can save time and harmonize the code. For example, simple quote
versus double quote, that was not checked by pep8.i It's just an example of
what make  black With a pre-hook commit hook this will be also avoid to lose
time with pep8 errors.

Two links to see more:

https://github.com/ambv/black
https://www.mattlayman.com/blog/2018/python-code-black/

I think it can be very interesting to start to use Black on OpenStack. What
do you thinks about that? For example, we can introduce it on some projects, I
would volunteer to try on TripleO.

My best regards


From dtantsur at redhat.com  Thu Apr 18 08:57:38 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 18 Apr 2019 10:57:38 +0200
Subject: The python black project.
In-Reply-To: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
Message-ID: <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>

Hi,

On 4/18/19 10:51 AM, Natal Ngétal wrote:
> Hi everyone,
> 
> Black is project to format Python code. It's more and more used by the python
> community. That can save time and harmonize the code. For example, simple quote
> versus double quote, that was not checked by pep8.i It's just an example of
> what make  black With a pre-hook commit hook this will be also avoid to lose
> time with pep8 errors.

I'm not sure what exactly Black does, but the last thing I want to see is 
patches changing between single and double quotes. If it's not the case or it 
can be turned off, I'm all for experimenting.

> 
> Two links to see more:
> 
> https://github.com/ambv/black
> https://www.mattlayman.com/blog/2018/python-code-black/
> 
> I think it can be very interesting to start to use Black on OpenStack. What
> do you thinks about that? For example, we can introduce it on some projects, I
> would volunteer to try on TripleO.

Given it's a pre-commit hook, isn't it supposed to be done on developer's 
machines? If so, how do you see applying Black to the whole OpenStack?

Dmitry

> 
> My best regards
> 



From dtantsur at redhat.com  Thu Apr 18 09:01:02 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 18 Apr 2019 11:01:02 +0200
Subject: [dev][tc][all] Train Goal Schedule and Update
In-Reply-To: <a3ba268f-493f-444a-dbd8-4bf22091e2ed@gmail.com>
References: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
 <a3ba268f-493f-444a-dbd8-4bf22091e2ed@gmail.com>
Message-ID: <59598f4f-0df8-8642-0eff-34ef76e881b1@redhat.com>

I know ironic has a lot of issues with IPv6, not all of them are even under our 
control. I quite doubt we can make it, although I know there is downstream 
interest to make it happen.

On 4/17/19 10:15 PM, Lance Bragstad wrote:
> Sending a quick follow-up here. We now have a proposal for ipv6 testing support 
> as a community goal [0]. Thanks to gmann for writing it up!
> 
> I encourage folks to have a look if you have time before the PTG.
> 
> [0] https://review.openstack.org/653545
> 
> On 4/3/19 11:59 AM, Lance Bragstad wrote:
>> Hi all,
>>
>> Since the community goal selection process has taken a turn, we wanted to 
>> send  an update regarding the current goals. We originally wanted to have the 
>> goals for Train be merged by this point to give project teams ample time to 
>> plan for them accordingly in their PTG scheduled. Due to discussions raised in 
>> each [0][1], it doesn't sound like either will be making it into Train as a 
>> feasible community goal. Fortunately, a couple of last minute goals might be a 
>> perfect fit for Train, instead of having a release without any community goals.
>>
>> The first one suggested is to render documentation as PDFs [2]. The second 
>> goal, which still needs to be proposed, is for IPv6 support. The advantage is 
>> that both of these goals are much smaller in scope, but still useful. We're 
>> running up against the clock on getting goals selected for Train, but we still 
>> have an opportunity to come to agreement on the new proposalsbefore the PTG.
>>
>> We'd like to ask TC and members of the community to review the proposed goals 
>> at their earliest convenience. Additionally, if someone wants help write up 
>> the IPv6 support goal [3][4], please reach out gmann and mnaser. Even though 
>> we were originally trying to make sure we had firm goals well before the PTG, 
>> the reduced scope of the new goals should make them easier to talk about in 
>> impromptu sessions or the hallway track.
>>
>> Thanks,
>>
>> JP & Lance
>>
>> [0] https://review.openstack.org/#/c/639376/
>> [1] https://review.openstack.org/#/c/639010/
>> [2] https://review.openstack.org/#/c/647712/
>> [3]http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-03-28.log.html#t2019-03-28T15:10:36
>> [4] Note that this goal is for testing IPv6 networking setups in all projects. 
>> We already have a tempest full ipv6 job, it would be a matter of making these 
>> jobs passing and voting in the future.
> 



From ssbarnea at redhat.com  Thu Apr 18 09:52:18 2019
From: ssbarnea at redhat.com (Sorin Sbarnea)
Date: Thu, 18 Apr 2019 10:52:18 +0100
Subject: The python black project.
In-Reply-To: <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
Message-ID: <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>

Black is a python code formatter, something similar to the older yapf.

I do like to avoid discussions about formatting in code reviews and prefer to let the linter take care of what could count as appointed.

My experience with yapf was far from idea as they decided to change formatting in a major way in their last *minor* version update, breaking havoc.

There is one reason why I did not even try black: it does require python3.6 !!!

While I do have a huge range of python version installed on my own dev machines, I cannot say the same about the average developer/contributor.

Considering that on CentOS-7 you can only get python3.5... this rest my case.

I do not want to limit the number of platform for contributors on any project, especially when we talk about one of the most basic/early check a developer would have to run on any change they make.

That is why -1 on black, and I guess it will be like this until we have CentOS 8 released. On the other hand, about yapf use I have mixed feelings.

I would rather prefer to see better adoption/coverage of: flake8, ansible-lint and yamllint -- preferably orchestrated via pre-commit as it lowers the execution time and disk footprint (sharing/caching identical linters between repositories) -- opposed to tox which does not shared anything between repositories. Tripleo-quickstart and tripleo-ci repositories are already using it and I did not hear many complaints, other than having to explain that pre-commit is does not require the use of a git hook.  


Shortly, +2 on more pre-commit use, the tool not the git hook.


PS. Please do not bring the SCL into the thread, they do not provide a single command enablement of additional python interpreters (not in PATH).

> On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> 
> Hi,
> 
> On 4/18/19 10:51 AM, Natal Ngétal wrote:
>> Hi everyone,
>> Black is project to format Python code. It's more and more used by the python
>> community. That can save time and harmonize the code. For example, simple quote
>> versus double quote, that was not checked by pep8.i It's just an example of
>> what make  black With a pre-hook commit hook this will be also avoid to lose
>> time with pep8 errors.
> 
> I'm not sure what exactly Black does, but the last thing I want to see is patches changing between single and double quotes. If it's not the case or it can be turned off, I'm all for experimenting.
> 
>> Two links to see more:
>> https://github.com/ambv/black
>> https://www.mattlayman.com/blog/2018/python-code-black/
>> I think it can be very interesting to start to use Black on OpenStack. What
>> do you thinks about that? For example, we can introduce it on some projects, I
>> would volunteer to try on TripleO.
> 
> Given it's a pre-commit hook, isn't it supposed to be done on developer's machines? If so, how do you see applying Black to the whole OpenStack?
> 
> Dmitry
> 
>> My best regards
> 
> 



From dtantsur at redhat.com  Thu Apr 18 09:56:43 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 18 Apr 2019 11:56:43 +0200
Subject: The python black project.
In-Reply-To: <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
Message-ID: <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>

On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> Black is a python code formatter, something similar to the older yapf.
> 
> I do like to avoid discussions about formatting in code reviews and prefer to let the linter take care of what could count as appointed.

That's what pep8 jobs are for. They cannot be replaced with a pre-commit hooks, 
because people who are mostly likely to screw up formatting are also most likely 
to not have it installed.

> 
> My experience with yapf was far from idea as they decided to change formatting in a major way in their last *minor* version update, breaking havoc.
> 
> There is one reason why I did not even try black: it does require python3.6 !!!
> 
> While I do have a huge range of python version installed on my own dev machines, I cannot say the same about the average developer/contributor.
> 
> Considering that on CentOS-7 you can only get python3.5... this rest my case.

You're welcome: 
https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)

> 
> I do not want to limit the number of platform for contributors on any project, especially when we talk about one of the most basic/early check a developer would have to run on any change they make.
> 
> That is why -1 on black, and I guess it will be like this until we have CentOS 8 released. On the other hand, about yapf use I have mixed feelings.
> 
> I would rather prefer to see better adoption/coverage of: flake8, ansible-lint and yamllint -- preferably orchestrated via pre-commit as it lowers the execution time and disk footprint (sharing/caching identical linters between repositories) -- opposed to tox which does not shared anything between repositories. Tripleo-quickstart and tripleo-ci repositories are already using it and I did not hear many complaints, other than having to explain that pre-commit is does not require the use of a git hook.

I think we already use flake8 openstack-wide, what will Black bring us in 
addition to that?

Dmitry

> 
> 
> Shortly, +2 on more pre-commit use, the tool not the git hook.
> 
> 
> PS. Please do not bring the SCL into the thread, they do not provide a single command enablement of additional python interpreters (not in PATH).
> 
>> On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>
>> Hi,
>>
>> On 4/18/19 10:51 AM, Natal Ngétal wrote:
>>> Hi everyone,
>>> Black is project to format Python code. It's more and more used by the python
>>> community. That can save time and harmonize the code. For example, simple quote
>>> versus double quote, that was not checked by pep8.i It's just an example of
>>> what make  black With a pre-hook commit hook this will be also avoid to lose
>>> time with pep8 errors.
>>
>> I'm not sure what exactly Black does, but the last thing I want to see is patches changing between single and double quotes. If it's not the case or it can be turned off, I'm all for experimenting.
>>
>>> Two links to see more:
>>> https://github.com/ambv/black
>>> https://www.mattlayman.com/blog/2018/python-code-black/
>>> I think it can be very interesting to start to use Black on OpenStack. What
>>> do you thinks about that? For example, we can introduce it on some projects, I
>>> would volunteer to try on TripleO.
>>
>> Given it's a pre-commit hook, isn't it supposed to be done on developer's machines? If so, how do you see applying Black to the whole OpenStack?
>>
>> Dmitry
>>
>>> My best regards
>>
>>
> 



From gchamoul at redhat.com  Thu Apr 18 10:29:39 2019
From: gchamoul at redhat.com (=?utf-8?B?R2HDq2w=?= Chamoulaud)
Date: Thu, 18 Apr 2019 12:29:39 +0200
Subject: [tripleo] Nominate =?utf-8?B?Q8OpZHJp?= =?utf-8?Q?c?= Jeanneret
 (Tengu) for tripleo-validations core
Message-ID: <20190418102939.heykaeyphydgocq4@olivia.strider.local>

Hi TripleO devs,

The new Validation Framework is a big step further for the tripleo-validations
project. In many ways, it improves the way of detecting & reporting potential
issues during a TripleO deployment. As the mastermind of this new framework,
Cédric brought a new lease of life to the tripleo-validations project. That's
why we would highly benefit from his addition to the core reviewer team.

Assuming that there are no objections, we will add Cédric to the core team next
week.

Thanks, Cédric, for your excellent work!

=Gaël
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/cf67b5f9/attachment-0001.sig>

From sfinucan at redhat.com  Thu Apr 18 10:33:54 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Thu, 18 Apr 2019 11:33:54 +0100
Subject: The python black project.
In-Reply-To: <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
Message-ID: <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>

On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > Black is a python code formatter, something similar to the older
> > yapf.
> > 
> > I do like to avoid discussions about formatting in code reviews and
> > prefer to let the linter take care of what could count as
> > appointed.
> 
> That's what pep8 jobs are for. They cannot be replaced with a pre-
> commit hooks, because people who are mostly likely to screw up
> formatting are also most likely to not have it installed.
> 
> > My experience with yapf was far from idea as they decided to change
> > formatting in a major way in their last *minor* version update,
> > breaking havoc.
> > 
> > There is one reason why I did not even try black: it does require
> > python3.6 !!!
> > 
> > While I do have a huge range of python version installed on my own
> > dev machines, I cannot say the same about the average
> > developer/contributor.
> > 
> > Considering that on CentOS-7 you can only get python3.5... this
> > rest my case.
> 
> You're welcome: 
> https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)

You've also got tox and virtualenvs in general, but I don't think this
is a serious issue tbh...

> > I do not want to limit the number of platform for contributors on
> > any project, especially when we talk about one of the most
> > basic/early check a developer would have to run on any change they
> > make.
> > 
> > That is why -1 on black, and I guess it will be like this until we
> > have CentOS 8 released. On the other hand, about yapf use I have
> > mixed feelings.
> > 
> > I would rather prefer to see better adoption/coverage of: flake8,
> > ansible-lint and yamllint -- preferably orchestrated via pre-commit 
> > as it lowers the execution time and disk footprint (sharing/caching
> > identical linters between repositories) -- opposed to tox which
> > does not shared anything between repositories. Tripleo-quickstart
> > and tripleo-ci repositories are already using it and I did not hear
> > many complaints, other than having to explain that pre-commit is
> > does not require the use of a git hook.
> 
> I think we already use flake8 openstack-wide, what will Black bring
> us in addition to that?

I've seen this used with packages such as tox and warehouse (the new
code base for pypi.org). black is intended to be an opinionated code
formatter and exposes no knobs to the user, meaning it's very much
"their way or the highway". This makes it different from something like
yapf, which exposes all these knobs and therefore allows for arguments
about e.g. whether one should use single or double quotes. No
configuration knobs means no ability to discuss these preferences,
which for something as subjective as code formatting seems to be a good
thing to me.

Now, as to whether it's practical, you have to realize that for it to
be of any use, black has to be run initially over your entire codebase
and then rerun on each commit. The latter isn't an issue (we already
run flake8 for this purpose) but I genuinely cannot see something like
nova rewrapping every line of code (all 552,347 of them, if my quick
check is correct), essentially breaking the ability to cleanly backport
patches and get meaningful 'git blame' output simply to avoid the
occasional debate about code formatting. I think adopting black for a
_new_ project (or even a very small one) could be a great idea, but for
something as large and cumbersome as nova (or neutron, glance, cinder,
some of the oslo libraries, etc.), maaaaaybe not.

Stephen

PS: As an aside, I would like to see something like black provided as
part of the Python standard library to settle formatting issues for
once and for all and help ensure that a minimum standard is set for
most code you'll find (though code quality covers far more than mere
formatting). To the best of my knowledge, the gofmt tool in go(lang)
fills this role but I really can't see that happening within Python any
time soon.

> Dmitry
> 
> > 
> > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > 
> > 
> > PS. Please do not bring the SCL into the thread, they do not
> > provide a single command enablement of additional python
> > interpreters (not in PATH).
> > 
> > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
> > > wrote:
> > > 
> > > Hi,
> > > 
> > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > Hi everyone,
> > > > Black is project to format Python code. It's more and more used
> > > > by the python community. That can save time and harmonize the
> > > > code. For example, simple quote versus double quote, that was
> > > > not checked by pep8.i It's just an example of what make  black
> > > > With a pre-hook commit hook this will be also avoid to lose
> > > > time with pep8 errors.
> > > 
> > > I'm not sure what exactly Black does, but the last thing I want
> > > to see is patches changing between single and double quotes. If
> > > it's not the case or it can be turned off, I'm all for
> > > experimenting.
> > > 
> > > > Two links to see more:
> > > > https://github.com/ambv/black
> > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > I think it can be very interesting to start to use Black on
> > > > OpenStack. What do you thinks about that? For example, we can
> > > > introduce it on some projects, I would volunteer to try on
> > > > TripleO.
> > > 
> > > Given it's a pre-commit hook, isn't it supposed to be done on
> > > developer's machines? If so, how do you see applying Black to the
> > > whole OpenStack?
> > > 
> > > Dmitry
> > > 
> > > > My best regards



From gchamoul at redhat.com  Thu Apr 18 10:36:04 2019
From: gchamoul at redhat.com (=?utf-8?B?R2HDq2w=?= Chamoulaud)
Date: Thu, 18 Apr 2019 12:36:04 +0200
Subject: [tripleo] Nominate =?utf-8?B?Q8OpZHJp?= =?utf-8?Q?c?= Jeanneret
 (Tengu) for tripleo-validations core
Message-ID: <20190418103604.glowbbbrbieg4fj6@olivia.strider.local>

Hi TripleO devs,

The new Validation Framework is a big step further for the tripleo-validations
project. In many ways, it improves the way of detecting & reporting potential
issues during a TripleO deployment. As the mastermind of this new framework,
Cédric brought a new lease of life to the tripleo-validations project. That's
why we would highly benefit from his addition to the core reviewer team.

Assuming that there are no objections, we will add Cédric to the core team next
week.

Thanks, Cédric, for your excellent work!

=Gaël
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/4fd93fca/attachment.sig>

From smooney at redhat.com  Thu Apr 18 10:42:40 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 11:42:40 +0100
Subject: The python black project.
In-Reply-To: <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
Message-ID: <6cea797666bdf3cab31447db60eefbad2b5b6432.camel@redhat.com>

On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > Black is a python code formatter, something similar to the older yapf.
> > 
> > I do like to avoid discussions about formatting in code reviews and prefer to let the linter take care of what could
> > count as appointed.
> 
> That's what pep8 jobs are for. They cannot be replaced with a pre-commit hooks, 
> because people who are mostly likely to screw up formatting are also most likely 
> to not have it installed.
im not sure about the later point. i mess up pep8 with parctially every patch
and i have worked on openstack/python for almost 6 years at this point
but i agree it cant replace the pep8 job but we shoudl also have a black job.

also we could easily provide a tox -e black to do the formatting.
> 
> > 
> > My experience with yapf was far from idea as they decided to change formatting in a major way in their last *minor*
> > version update, breaking havoc.
> > 
> > There is one reason why I did not even try black: it does require python3.6 !!!
> > 
> > While I do have a huge range of python version installed on my own dev machines, I cannot say the same about the
> > average developer/contributor.
> > 
> > Considering that on CentOS-7 you can only get python3.5... this rest my case.
you can get 3.6 on centos. that is what my dev vms ues by default.
python3.6 is shiped in the epel repos and centos defaults to python 3.4 py3.5 was the version i tought
you could not easily install on centos7
> 
> You're welcome: 
> https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
> 
> > 
> > I do not want to limit the number of platform for contributors on any project, especially when we talk about one of
> > the most basic/early check a developer would have to run on any change they make.
> > 
> > That is why -1 on black, and I guess it will be like this until we have CentOS 8 released. On the other hand, about
> > yapf use I have mixed feelings.
> > 
> > I would rather prefer to see better adoption/coverage of: flake8, ansible-lint and yamllint -- preferably
> > orchestrated via pre-commit as it lowers the execution time and disk footprint (sharing/caching identical linters
> > between repositories) -- opposed to tox which does not shared anything between repositories. Tripleo-quickstart and
> > tripleo-ci repositories are already using it and I did not hear many complaints, other than having to explain that
> > pre-commit is does not require the use of a git hook.
> 
> I think we already use flake8 openstack-wide, what will Black bring us in 
> addition to that?
i have not looked at black but if its anything like clang-format or go's gofmt tool
there is a lot to be gained by haveing a tool format all code in a repo to follow
a project/langage specific coding style with 0 human interaction required.

i we were to apply this to openstack we woudl need a singel mechanical commit that used
black to reformat all code in a repo which also intoduces a black gate jobs.

the black gate job going forward would reject any patch that would require
black to modify it. e.g. the job woudl take the change run black and check git diff
to see if anything changed. if it did fail if it didn't pass.
> 
> Dmitry
> 
> > 
> > 
> > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > 
> > 
> > PS. Please do not bring the SCL into the thread, they do not provide a single command enablement of additional
> > python interpreters (not in PATH).
> > 
> > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> > > 
> > > Hi,
> > > 
> > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > Hi everyone,
> > > > Black is project to format Python code. It's more and more used by the python
> > > > community. That can save time and harmonize the code. For example, simple quote
> > > > versus double quote, that was not checked by pep8.i It's just an example of
> > > > what make  black With a pre-hook commit hook this will be also avoid to lose
> > > > time with pep8 errors.
> > > 
> > > I'm not sure what exactly Black does, but the last thing I want to see is patches changing between single and
> > > double quotes. If it's not the case or it can be turned off, I'm all for experimenting.
> > > 
> > > > Two links to see more:
> > > > https://github.com/ambv/black
> > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > I think it can be very interesting to start to use Black on OpenStack. What
> > > > do you thinks about that? For example, we can introduce it on some projects, I
> > > > would volunteer to try on TripleO.
> > > 
> > > Given it's a pre-commit hook, isn't it supposed to be done on developer's machines? If so, how do you see applying
> > > Black to the whole OpenStack?
> > > 
> > > Dmitry
> > > 
> > > > My best regards
> > > 
> > > 
> 
> 



From cdent+os at anticdent.org  Thu Apr 18 10:46:33 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 18 Apr 2019 11:46:33 +0100 (BST)
Subject: The python black project.
In-Reply-To: <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
Message-ID: <alpine.OSX.2.21.1904181144540.29709@cdent-a01.vmware.com>

On Thu, 18 Apr 2019, Stephen Finucane wrote:

> Now, as to whether it's practical, you have to realize that for it to
> be of any use, black has to be run initially over your entire codebase
> and then rerun on each commit. The latter isn't an issue (we already
> run flake8 for this purpose) but I genuinely cannot see something like
> nova rewrapping every line of code (all 552,347 of them, if my quick
> check is correct), essentially breaking the ability to cleanly backport
> patches and get meaningful 'git blame' output simply to avoid the
> occasional debate about code formatting. I think adopting black for a
> _new_ project (or even a very small one) could be a great idea, but for
> something as large and cumbersome as nova (or neutron, glance, cinder,
> some of the oslo libraries, etc.), maaaaaybe not.

Exactly this. Introducing black to an existing project with a long
history is pretty much a non-starter.

The fact that it provides no knobs is, as you say, a feature
(everyone must must bow to the same evil dictator).

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From dtantsur at redhat.com  Thu Apr 18 10:53:21 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 18 Apr 2019 12:53:21 +0200
Subject: The python black project.
In-Reply-To: <alpine.OSX.2.21.1904181144540.29709@cdent-a01.vmware.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <alpine.OSX.2.21.1904181144540.29709@cdent-a01.vmware.com>
Message-ID: <fa25c428-61fb-081a-16ed-56b676b39098@redhat.com>

On 4/18/19 12:46 PM, Chris Dent wrote:
> On Thu, 18 Apr 2019, Stephen Finucane wrote:
> 
>> Now, as to whether it's practical, you have to realize that for it to
>> be of any use, black has to be run initially over your entire codebase
>> and then rerun on each commit. The latter isn't an issue (we already
>> run flake8 for this purpose) but I genuinely cannot see something like
>> nova rewrapping every line of code (all 552,347 of them, if my quick
>> check is correct), essentially breaking the ability to cleanly backport
>> patches and get meaningful 'git blame' output simply to avoid the
>> occasional debate about code formatting. I think adopting black for a
>> _new_ project (or even a very small one) could be a great idea, but for
>> something as large and cumbersome as nova (or neutron, glance, cinder,
>> some of the oslo libraries, etc.), maaaaaybe not.
> 
> Exactly this. Introducing black to an existing project with a long
> history is pretty much a non-starter.
> 
> The fact that it provides no knobs is, as you say, a feature
> (everyone must must bow to the same evil dictator).
> 

... except when somebody blocks the adoption completely because of a dislike for 
some aspect :) This is where a tool officially blessed by the Python core team 
would come handier (like 'go fmt', 'cargo fmt', etc).


From smooney at redhat.com  Thu Apr 18 10:55:11 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 11:55:11 +0100
Subject: The python black project.
In-Reply-To: <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
Message-ID: <884ef12e3a298e33a253d0f39c70a0ad8a975ee7.camel@redhat.com>

On Thu, 2019-04-18 at 11:33 +0100, Stephen Finucane wrote:
> On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> > On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > > Black is a python code formatter, something similar to the older
> > > yapf.
> > > 
> > > I do like to avoid discussions about formatting in code reviews and
> > > prefer to let the linter take care of what could count as
> > > appointed.
> > 
> > That's what pep8 jobs are for. They cannot be replaced with a pre-
> > commit hooks, because people who are mostly likely to screw up
> > formatting are also most likely to not have it installed.
> > 
> > > My experience with yapf was far from idea as they decided to change
> > > formatting in a major way in their last *minor* version update,
> > > breaking havoc.
> > > 
> > > There is one reason why I did not even try black: it does require
> > > python3.6 !!!
> > > 
> > > While I do have a huge range of python version installed on my own
> > > dev machines, I cannot say the same about the average
> > > developer/contributor.
> > > 
> > > Considering that on CentOS-7 you can only get python3.5... this
> > > rest my case.
> > 
> > You're welcome: 
> > https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
> 
> You've also got tox and virtualenvs in general, but I don't think this
> is a serious issue tbh...
> 
> > > I do not want to limit the number of platform for contributors on
> > > any project, especially when we talk about one of the most
> > > basic/early check a developer would have to run on any change they
> > > make.
> > > 
> > > That is why -1 on black, and I guess it will be like this until we
> > > have CentOS 8 released. On the other hand, about yapf use I have
> > > mixed feelings.
> > > 
> > > I would rather prefer to see better adoption/coverage of: flake8,
> > > ansible-lint and yamllint -- preferably orchestrated via pre-commit 
> > > as it lowers the execution time and disk footprint (sharing/caching
> > > identical linters between repositories) -- opposed to tox which
> > > does not shared anything between repositories. Tripleo-quickstart
> > > and tripleo-ci repositories are already using it and I did not hear
> > > many complaints, other than having to explain that pre-commit is
> > > does not require the use of a git hook.
> > 
> > I think we already use flake8 openstack-wide, what will Black bring
> > us in addition to that?
> 
> I've seen this used with packages such as tox and warehouse (the new
> code base for pypi.org). black is intended to be an opinionated code
> formatter and exposes no knobs to the user, meaning it's very much
> "their way or the highway". This makes it different from something like
> yapf, which exposes all these knobs and therefore allows for arguments
> about e.g. whether one should use single or double quotes. No
> configuration knobs means no ability to discuss these preferences,
> which for something as subjective as code formatting seems to be a good
> thing to me.
> 
> Now, as to whether it's practical, you have to realize that for it to
> be of any use, black has to be run initially over your entire codebase
> and then rerun on each commit. The latter isn't an issue (we already
> run flake8 for this purpose) but I genuinely cannot see something like
> nova rewrapping every line of code (all 552,347 of them, if my quick
> check is correct), essentially breaking the ability to cleanly backport
> patches and get meaningful 'git blame' output simply to avoid the
> occasional debate about code formatting.
i get the git blame argument but i really hope the rest are not valid.
that would be a seriously depressing situation as it means we can never
automate away the formatting of our code which we really should. the fact
we have automated checking but not fixing of code style is one of the
most irritating parts of working with openstack development personally.

it might be worth seeing fi there is a way to use yapf or black but only
on the functions being modifed in a current patch? in other word find
a way to do it incrementally.

>  I think adopting black for a
> _new_ project (or even a very small one) could be a great idea, but for
> something as large and cumbersome as nova (or neutron, glance, cinder,
> some of the oslo libraries, etc.), maaaaaybe not.
i didnt actully know there were tool like this for python.
i have wanted to add something similar to os-vif since it was created
but the best i could comeup with was "maybe we can convice clangfromat to work"
> 
> Stephen
> 
> PS: As an aside, I would like to see something like black provided as
> part of the Python standard library to settle formatting issues for
> once and for all and help ensure that a minimum standard is set for
> most code you'll find (though code quality covers far more than mere
> formatting). To the best of my knowledge, the gofmt tool in go(lang)
> fills this role but I really can't see that happening within Python any
> time soon.
+42 this is why i would like something like this to be a thing in the openstack
ecosystem at least but yes i also agree with this idea and that it does not
seam to be happening in the sort term :(
> 
> > Dmitry
> > 
> > > 
> > > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > > 
> > > 
> > > PS. Please do not bring the SCL into the thread, they do not
> > > provide a single command enablement of additional python
> > > interpreters (not in PATH).
> > > 
> > > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
> > > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > > Hi everyone,
> > > > > Black is project to format Python code. It's more and more used
> > > > > by the python community. That can save time and harmonize the
> > > > > code. For example, simple quote versus double quote, that was
> > > > > not checked by pep8.i It's just an example of what make  black
> > > > > With a pre-hook commit hook this will be also avoid to lose
> > > > > time with pep8 errors.
> > > > 
> > > > I'm not sure what exactly Black does, but the last thing I want
> > > > to see is patches changing between single and double quotes. If
> > > > it's not the case or it can be turned off, I'm all for
> > > > experimenting.
> > > > 
> > > > > Two links to see more:
> > > > > https://github.com/ambv/black
> > > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > > I think it can be very interesting to start to use Black on
> > > > > OpenStack. What do you thinks about that? For example, we can
> > > > > introduce it on some projects, I would volunteer to try on
> > > > > TripleO.
> > > > 
> > > > Given it's a pre-commit hook, isn't it supposed to be done on
> > > > developer's machines? If so, how do you see applying Black to the
> > > > whole OpenStack?
> > > > 
> > > > Dmitry
> > > > 
> > > > > My best regards
> 
> 



From skaplons at redhat.com  Thu Apr 18 11:02:10 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Thu, 18 Apr 2019 13:02:10 +0200
Subject: The python black project.
In-Reply-To: <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
Message-ID: <1D2902DD-2956-4F04-A985-9F4114CE601C@redhat.com>

Hi,

> Wiadomość napisana przez Stephen Finucane <sfinucan at redhat.com> w dniu 18.04.2019, o godz. 12:33:
> 
> On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
>> On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
>>> Black is a python code formatter, something similar to the older
>>> yapf.
>>> 
>>> I do like to avoid discussions about formatting in code reviews and
>>> prefer to let the linter take care of what could count as
>>> appointed.
>> 
>> That's what pep8 jobs are for. They cannot be replaced with a pre-
>> commit hooks, because people who are mostly likely to screw up
>> formatting are also most likely to not have it installed.
>> 
>>> My experience with yapf was far from idea as they decided to change
>>> formatting in a major way in their last *minor* version update,
>>> breaking havoc.
>>> 
>>> There is one reason why I did not even try black: it does require
>>> python3.6 !!!
>>> 
>>> While I do have a huge range of python version installed on my own
>>> dev machines, I cannot say the same about the average
>>> developer/contributor.
>>> 
>>> Considering that on CentOS-7 you can only get python3.5... this
>>> rest my case.
>> 
>> You're welcome: 
>> https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
> 
> You've also got tox and virtualenvs in general, but I don't think this
> is a serious issue tbh...
> 
>>> I do not want to limit the number of platform for contributors on
>>> any project, especially when we talk about one of the most
>>> basic/early check a developer would have to run on any change they
>>> make.
>>> 
>>> That is why -1 on black, and I guess it will be like this until we
>>> have CentOS 8 released. On the other hand, about yapf use I have
>>> mixed feelings.
>>> 
>>> I would rather prefer to see better adoption/coverage of: flake8,
>>> ansible-lint and yamllint -- preferably orchestrated via pre-commit 
>>> as it lowers the execution time and disk footprint (sharing/caching
>>> identical linters between repositories) -- opposed to tox which
>>> does not shared anything between repositories. Tripleo-quickstart
>>> and tripleo-ci repositories are already using it and I did not hear
>>> many complaints, other than having to explain that pre-commit is
>>> does not require the use of a git hook.
>> 
>> I think we already use flake8 openstack-wide, what will Black bring
>> us in addition to that?
> 
> I've seen this used with packages such as tox and warehouse (the new
> code base for pypi.org). black is intended to be an opinionated code
> formatter and exposes no knobs to the user, meaning it's very much
> "their way or the highway". This makes it different from something like
> yapf, which exposes all these knobs and therefore allows for arguments
> about e.g. whether one should use single or double quotes. No
> configuration knobs means no ability to discuss these preferences,
> which for something as subjective as code formatting seems to be a good
> thing to me.
> 
> Now, as to whether it's practical, you have to realize that for it to
> be of any use, black has to be run initially over your entire codebase
> and then rerun on each commit. The latter isn't an issue (we already
> run flake8 for this purpose) but I genuinely cannot see something like
> nova rewrapping every line of code (all 552,347 of them, if my quick
> check is correct), essentially breaking the ability to cleanly backport
> patches and get meaningful 'git blame' output simply to avoid the
> occasional debate about code formatting. I think adopting black for a
> _new_ project (or even a very small one) could be a great idea, but for
> something as large and cumbersome as nova (or neutron, glance, cinder,
> some of the oslo libraries, etc.), maaaaaybe not.

+100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was changed doesn’t seems like good thing :)

> 
> Stephen
> 
> PS: As an aside, I would like to see something like black provided as
> part of the Python standard library to settle formatting issues for
> once and for all and help ensure that a minimum standard is set for
> most code you'll find (though code quality covers far more than mere
> formatting). To the best of my knowledge, the gofmt tool in go(lang)
> fills this role but I really can't see that happening within Python any
> time soon.
> 
>> Dmitry
>> 
>>> 
>>> Shortly, +2 on more pre-commit use, the tool not the git hook.
>>> 
>>> 
>>> PS. Please do not bring the SCL into the thread, they do not
>>> provide a single command enablement of additional python
>>> interpreters (not in PATH).
>>> 
>>>> On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 4/18/19 10:51 AM, Natal Ngétal wrote:
>>>>> Hi everyone,
>>>>> Black is project to format Python code. It's more and more used
>>>>> by the python community. That can save time and harmonize the
>>>>> code. For example, simple quote versus double quote, that was
>>>>> not checked by pep8.i It's just an example of what make  black
>>>>> With a pre-hook commit hook this will be also avoid to lose
>>>>> time with pep8 errors.
>>>> 
>>>> I'm not sure what exactly Black does, but the last thing I want
>>>> to see is patches changing between single and double quotes. If
>>>> it's not the case or it can be turned off, I'm all for
>>>> experimenting.
>>>> 
>>>>> Two links to see more:
>>>>> https://github.com/ambv/black
>>>>> https://www.mattlayman.com/blog/2018/python-code-black/
>>>>> I think it can be very interesting to start to use Black on
>>>>> OpenStack. What do you thinks about that? For example, we can
>>>>> introduce it on some projects, I would volunteer to try on
>>>>> TripleO.
>>>> 
>>>> Given it's a pre-commit hook, isn't it supposed to be done on
>>>> developer's machines? If so, how do you see applying Black to the
>>>> whole OpenStack?
>>>> 
>>>> Dmitry
>>>> 
>>>>> My best regards

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From smooney at redhat.com  Thu Apr 18 11:07:18 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 12:07:18 +0100
Subject: [tc] The python black project.
In-Reply-To: <fa25c428-61fb-081a-16ed-56b676b39098@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <alpine.OSX.2.21.1904181144540.29709@cdent-a01.vmware.com>
 <fa25c428-61fb-081a-16ed-56b676b39098@redhat.com>
Message-ID: <aa437e1de548c12b44b67040da46518dc38a1931.camel@redhat.com>

On Thu, 2019-04-18 at 12:53 +0200, Dmitry Tantsur wrote:
> On 4/18/19 12:46 PM, Chris Dent wrote:
> > On Thu, 18 Apr 2019, Stephen Finucane wrote:
> > 
> > > Now, as to whether it's practical, you have to realize that for it to
> > > be of any use, black has to be run initially over your entire codebase
> > > and then rerun on each commit. The latter isn't an issue (we already
> > > run flake8 for this purpose) but I genuinely cannot see something like
> > > nova rewrapping every line of code (all 552,347 of them, if my quick
> > > check is correct), essentially breaking the ability to cleanly backport
> > > patches and get meaningful 'git blame' output simply to avoid the
> > > occasional debate about code formatting. I think adopting black for a
> > > _new_ project (or even a very small one) could be a great idea, but for
> > > something as large and cumbersome as nova (or neutron, glance, cinder,
> > > some of the oslo libraries, etc.), maaaaaybe not.
> > 
> > Exactly this. Introducing black to an existing project with a long
> > history is pretty much a non-starter.
> > 
> > The fact that it provides no knobs is, as you say, a feature
> > (everyone must must bow to the same evil dictator).
> > 
> 
> ... except when somebody blocks the adoption completely because of a dislike for 
> some aspect :) This is where a tool officially blessed by the Python core team 
> would come handier (like 'go fmt', 'cargo fmt', etc).
yes but it does not need to be the python core team that blesses it.
for yapf which is based on clang-format you can provide project specific styles.

so we could have an openstack style that we applied however to do that i think this would
need the help of the TC and consultation with all projects to a.) agree on a tool
b.) agree on a style config and c.) agree on an implementation path.

indivigual projects, espically small/new ones could standardise on a tool/style themselves
but in the absence of a blessed formater form the Python core team if we wanted to adopt
this in openstack as a whole it would have to become part of the PTI which would require
TC involvement and comunity buy in.



From smooney at redhat.com  Thu Apr 18 11:18:00 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 12:18:00 +0100
Subject: The python black project.
In-Reply-To: <1D2902DD-2956-4F04-A985-9F4114CE601C@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <1D2902DD-2956-4F04-A985-9F4114CE601C@redhat.com>
Message-ID: <e1a8462234b25ab679d81b72c177d8242969c7bd.camel@redhat.com>

On Thu, 2019-04-18 at 13:02 +0200, Slawomir Kaplonski wrote:
> Hi,
> 
> > Wiadomość napisana przez Stephen Finucane <sfinucan at redhat.com> w dniu 18.04.2019, o godz. 12:33:
> > 
> > On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> > > On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > > > Black is a python code formatter, something similar to the older
> > > > yapf.
> > > > 
> > > > I do like to avoid discussions about formatting in code reviews and
> > > > prefer to let the linter take care of what could count as
> > > > appointed.
> > > 
> > > That's what pep8 jobs are for. They cannot be replaced with a pre-
> > > commit hooks, because people who are mostly likely to screw up
> > > formatting are also most likely to not have it installed.
> > > 
> > > > My experience with yapf was far from idea as they decided to change
> > > > formatting in a major way in their last *minor* version update,
> > > > breaking havoc.
> > > > 
> > > > There is one reason why I did not even try black: it does require
> > > > python3.6 !!!
> > > > 
> > > > While I do have a huge range of python version installed on my own
> > > > dev machines, I cannot say the same about the average
> > > > developer/contributor.
> > > > 
> > > > Considering that on CentOS-7 you can only get python3.5... this
> > > > rest my case.
> > > 
> > > You're welcome: 
> > > https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
> > 
> > You've also got tox and virtualenvs in general, but I don't think this
> > is a serious issue tbh...
> > 
> > > > I do not want to limit the number of platform for contributors on
> > > > any project, especially when we talk about one of the most
> > > > basic/early check a developer would have to run on any change they
> > > > make.
> > > > 
> > > > That is why -1 on black, and I guess it will be like this until we
> > > > have CentOS 8 released. On the other hand, about yapf use I have
> > > > mixed feelings.
> > > > 
> > > > I would rather prefer to see better adoption/coverage of: flake8,
> > > > ansible-lint and yamllint -- preferably orchestrated via pre-commit 
> > > > as it lowers the execution time and disk footprint (sharing/caching
> > > > identical linters between repositories) -- opposed to tox which
> > > > does not shared anything between repositories. Tripleo-quickstart
> > > > and tripleo-ci repositories are already using it and I did not hear
> > > > many complaints, other than having to explain that pre-commit is
> > > > does not require the use of a git hook.
> > > 
> > > I think we already use flake8 openstack-wide, what will Black bring
> > > us in addition to that?
> > 
> > I've seen this used with packages such as tox and warehouse (the new
> > code base for pypi.org). black is intended to be an opinionated code
> > formatter and exposes no knobs to the user, meaning it's very much
> > "their way or the highway". This makes it different from something like
> > yapf, which exposes all these knobs and therefore allows for arguments
> > about e.g. whether one should use single or double quotes. No
> > configuration knobs means no ability to discuss these preferences,
> > which for something as subjective as code formatting seems to be a good
> > thing to me.
> > 
> > Now, as to whether it's practical, you have to realize that for it to
> > be of any use, black has to be run initially over your entire codebase
> > and then rerun on each commit. The latter isn't an issue (we already
> > run flake8 for this purpose) but I genuinely cannot see something like
> > nova rewrapping every line of code (all 552,347 of them, if my quick
> > check is correct), essentially breaking the ability to cleanly backport
> > patches and get meaningful 'git blame' output simply to avoid the
> > occasional debate about code formatting. I think adopting black for a
> > _new_ project (or even a very small one) could be a great idea, but for
> > something as large and cumbersome as nova (or neutron, glance, cinder,
> > some of the oslo libraries, etc.), maaaaaybe not.
> 
> +100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was
> changed doesn’t seems like good thing :)
you realise if we also applied this to the stable branches too we would never need to resolve
a merge conflict due to formating again or correct any pep8/style issues on backports.
but yes its a valid concern.

i guess the general feedback so far has been unless there is a way to do it incrementally this is a non starter.
that is sad but if that is how people feel ill let this to the original poster to fight.
> 
> > 
> > Stephen
> > 
> > PS: As an aside, I would like to see something like black provided as
> > part of the Python standard library to settle formatting issues for
> > once and for all and help ensure that a minimum standard is set for
> > most code you'll find (though code quality covers far more than mere
> > formatting). To the best of my knowledge, the gofmt tool in go(lang)
> > fills this role but I really can't see that happening within Python any
> > time soon.
> > 
> > > Dmitry
> > > 
> > > > 
> > > > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > > > 
> > > > 
> > > > PS. Please do not bring the SCL into the thread, they do not
> > > > provide a single command enablement of additional python
> > > > interpreters (not in PATH).
> > > > 
> > > > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
> > > > > wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > > > Hi everyone,
> > > > > > Black is project to format Python code. It's more and more used
> > > > > > by the python community. That can save time and harmonize the
> > > > > > code. For example, simple quote versus double quote, that was
> > > > > > not checked by pep8.i It's just an example of what make  black
> > > > > > With a pre-hook commit hook this will be also avoid to lose
> > > > > > time with pep8 errors.
> > > > > 
> > > > > I'm not sure what exactly Black does, but the last thing I want
> > > > > to see is patches changing between single and double quotes. If
> > > > > it's not the case or it can be turned off, I'm all for
> > > > > experimenting.
> > > > > 
> > > > > > Two links to see more:
> > > > > > https://github.com/ambv/black
> > > > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > > > I think it can be very interesting to start to use Black on
> > > > > > OpenStack. What do you thinks about that? For example, we can
> > > > > > introduce it on some projects, I would volunteer to try on
> > > > > > TripleO.
> > > > > 
> > > > > Given it's a pre-commit hook, isn't it supposed to be done on
> > > > > developer's machines? If so, how do you see applying Black to the
> > > > > whole OpenStack?
> > > > > 
> > > > > Dmitry
> > > > > 
> > > > > > My best regards
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 
> 



From marios at redhat.com  Thu Apr 18 11:21:32 2019
From: marios at redhat.com (Marios Andreou)
Date: Thu, 18 Apr 2019 14:21:32 +0300
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <20190418103604.glowbbbrbieg4fj6@olivia.strider.local>
References: <20190418103604.glowbbbrbieg4fj6@olivia.strider.local>
Message-ID: <CAM51kHVp8wO+D1j3-7XdTyNemMu0=ziDaT3L+h1Y1JkLtwXQGQ@mail.gmail.com>

On Thu, Apr 18, 2019 at 1:37 PM Gaël Chamoulaud <gchamoul at redhat.com> wrote:

> Hi TripleO devs,
>
> The new Validation Framework is a big step further for the
> tripleo-validations
> project. In many ways, it improves the way of detecting & reporting
> potential
> issues during a TripleO deployment. As the mastermind of this new
> framework,
> Cédric brought a new lease of life to the tripleo-validations project.
> That's
> why we would highly benefit from his addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Cédric to the core team
> next
> week.
>
> Thanks, Cédric, for your excellent work!
>

+1


>
> =Gaël
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/1dccfed8/attachment.html>

From florian.engelmann at everyware.ch  Thu Apr 18 11:51:06 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Thu, 18 Apr 2019 13:51:06 +0200
Subject: [neutron] neutron-metering-agent track router and floating IP
 traffic
In-Reply-To: <f69a282d-5ab1-32fc-0290-b41e1f34fcc0@everyware.ch>
References: <f69a282d-5ab1-32fc-0290-b41e1f34fcc0@everyware.ch>
Message-ID: <ddb93ef1-4991-c807-6031-ace82094d6c8@everyware.ch>

it looks like every notification is bound to the label:

grep -A6 bandwidth meters.yaml
   - name: 'bandwidth'
     event_type: 'l3.meter'
     type: 'delta'
     unit: 'B'
     volume: $.payload.bytes
     project_id: $.payload.tenant_id
     resource_id: $.payload.label_id

Wouldn't it make sense to change this to:

   - name: 'bandwidth'
     event_type: 'l3.meter'
     type: 'delta'
     unit: 'B'
     volume: $.payload.bytes
     project_id: $.payload.tenant_id
     resource_id: $.payload.label_id + "_" + $.payload.tenant_id




Am 4/16/19 um 12:14 PM schrieb Florian Engelmann:
> Hi,
> 
> I configured our neutron meters like:
> 
> labels:
> openstack network meter create --description "shared 
> bandwidth-public-out" --share bandwidth-public-out
> openstack network meter create --description "shared 
> bandwidth-public-in" --share bandwidth-public-in
> 
> rules:
> openstack network meter rule create --egress --remote-ip-prefix 
> 0.0.0.0/0 bandwidth-public-out
> openstack network meter rule create --ingress --remote-ip-prefix 
> 0.0.0.0/0 bandwidth-public-in
> 
> This created the iptables rules in all namespaces and collects data:
> 
> openstack metric measures show bc6c670f-cbb5-4fe1-974c-10455448fa27
> +---------------------------+-------------+---------------+
> | timestamp                 | granularity |         value |
> +---------------------------+-------------+---------------+
> | 2019-04-15T16:00:00+02:00 |      3600.0 | 581854.954545 |
> | 2019-04-15T17:00:00+02:00 |      3600.0 | 23169398.5625 |
> | 2019-04-15T18:00:00+02:00 |      3600.0 |      586508.9 |
> | 2019-04-15T19:00:00+02:00 |      3600.0 | 1276372.84375 |
> | 2019-04-15T20:00:00+02:00 |      3600.0 | 507482.911765 |
> [...]
> 
> But how to know which project caused which amount of traffic?
> 
> It looks like only one metric is created for each label?
> 
> openstack metric list | grep bandwidth
> | 0f9f20a4-1c60-442f-81cb-48285e3f70da | ceilometer-ew-low | bandwidth 
>                      | B       | efae8040-85d7-455a-958d-213a81ef98ef |
> | 1a058a79-965f-4a0a-a9ee-d482f57892ab | ceilometer-ew-low | bandwidth 
>                      | B       | 837ed34a-65d2-42ef-924e-fd3c7e5aaed6 |
> 
> 
> What does "shared" mean? I was not able to find any relevant documentation.
> Do I have to create a meter for each project or a rule or both? Is it 
> possible to define a "default" meter and rule for every existing project 
> and all future projects?
> 
> All the best,
> Flo
> 

-- 

EveryWare AG
Florian Engelmann
Senior UNIX Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: mailto:florian.engelmann at everyware.ch
web: http://www.everyware.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/107b43a8/attachment-0001.bin>

From cdent+os at anticdent.org  Thu Apr 18 12:11:20 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Thu, 18 Apr 2019 13:11:20 +0100 (BST)
Subject: [placement][ptg] pre-ptg checkpoint
Message-ID: <alpine.OSX.2.21.1904181239370.29709@cdent-a01.vmware.com>


Since I'm going to be out of touch next week, I thought it best to
provide a checkpoint summarizing where things are with the virtual
pre-PTG process so that we go into the PTG in reasonable shape.

For reference, the pre-PTG has been a series of email threads
discussion topics raised in the two placement-related PTG
etherpads:

* https://etherpad.openstack.org/p/placement-ptg-train
* https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement

Each thread is linked from its topic in the etherpad. Any thread
which reached some resolution is marked with a boldface "ACTION", often
with a link to a story or review associated with the next step.

Overall I think the process has been useful. We've figured out some
plans of action for resource provider partitioning and consumer types,
worked out better testing for osc-placement, and have some ideas on
better container manager and performance testing. These things are
reflected in worklists on storyboard [1, 2].

We've also managed to uncover some more ideas, challenges, and
benefits with nested resource providers.

We have a planned Saturday morning session at the PTG with Ironic,
Blazar and anyone else who is thinking about using placement outside
of nova.

Where we've made less progress is getting owners on the new features
[3] and reaching some resolution or plan with the several nested
provider related threads (aggregate spanning, subtree "affinity",
json body, NUMA in placement, request group mapping, resource trait
filters). We've shared some ideas and managed to dismiss some things
that won't work, but at least so far a solid plan is yet to emerge.

Part of the latter may be my fault. I'm compelled to fully
understand what's going on and for things to make as much sense to
as many people as possible and I believed we had the time and space
to have a wide-open discussion in that direction in the weeks prior
to the PTG. There's still next week, so perhaps that's still the
case, but maybe a different approach is required. If you've got
ideas, please share.

Please carry on with the threads if there's more to add. I'll
incorporate them early in the week before the PTG and extract some
kind of schedule for our time at the PTG. As I've said before there
may not be much opportunity, we've only got Friday and Saturday and
it is mostly consumed. Friday will mostly be taken up with Nova,
Saturday morning will be talking with Ironic and Blazar. By Saturday
afternoon we will probably be exhausted and I suspect the best use
of our time will be talking without agenda about making sure working
on Placement is pleasant and useful for everyone [4]. We don't need to
actively seek more work: We've already defined got a lot, especially
when we account for work in other projects.

Thanks.

[1] Cleanups: https://storyboard.openstack.org/#!/worklist/575
[2] Features: https://storyboard.openstack.org/#!/worklist/594

[3] However, thanks very much to Surya for stepping up to make a
spec for the consumer type feature:
https://storyboard.openstack.org/#!/story/2005473

[4] To that end, please make sure you have added your thoughts to
the retrospective etherpad: 
https://etherpad.openstack.org/p/placement-ptg-train-retrospective

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From e0ne at e0ne.info  Thu Apr 18 12:13:24 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Thu, 18 Apr 2019 15:13:24 +0300
Subject: The python black project.
In-Reply-To: <e1a8462234b25ab679d81b72c177d8242969c7bd.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <1D2902DD-2956-4F04-A985-9F4114CE601C@redhat.com>
 <e1a8462234b25ab679d81b72c177d8242969c7bd.camel@redhat.com>
Message-ID: <CAGocpaHpVJMM6EwUvHnduR-EGqF5jNEbVVqHi6Ku1ymnUjbxWw@mail.gmail.com>

Hi all,

In general, I would like to have black formatter for the OpenStack code.

I agree with the points mentioned above about git blame. Also, I really
don't want to have dozens of patches just to address few more black rules
in the existing code base.

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


On Thu, Apr 18, 2019 at 2:18 PM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2019-04-18 at 13:02 +0200, Slawomir Kaplonski wrote:
> > Hi,
> >
> > > Wiadomość napisana przez Stephen Finucane <sfinucan at redhat.com> w
> dniu 18.04.2019, o godz. 12:33:
> > >
> > > On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
> > > > On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
> > > > > Black is a python code formatter, something similar to the older
> > > > > yapf.
> > > > >
> > > > > I do like to avoid discussions about formatting in code reviews and
> > > > > prefer to let the linter take care of what could count as
> > > > > appointed.
> > > >
> > > > That's what pep8 jobs are for. They cannot be replaced with a pre-
> > > > commit hooks, because people who are mostly likely to screw up
> > > > formatting are also most likely to not have it installed.
> > > >
> > > > > My experience with yapf was far from idea as they decided to change
> > > > > formatting in a major way in their last *minor* version update,
> > > > > breaking havoc.
> > > > >
> > > > > There is one reason why I did not even try black: it does require
> > > > > python3.6 !!!
> > > > >
> > > > > While I do have a huge range of python version installed on my own
> > > > > dev machines, I cannot say the same about the average
> > > > > developer/contributor.
> > > > >
> > > > > Considering that on CentOS-7 you can only get python3.5... this
> > > > > rest my case.
> > > >
> > > > You're welcome:
> > > >
> https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72
> :)
> > >
> > > You've also got tox and virtualenvs in general, but I don't think this
> > > is a serious issue tbh...
> > >
> > > > > I do not want to limit the number of platform for contributors on
> > > > > any project, especially when we talk about one of the most
> > > > > basic/early check a developer would have to run on any change they
> > > > > make.
> > > > >
> > > > > That is why -1 on black, and I guess it will be like this until we
> > > > > have CentOS 8 released. On the other hand, about yapf use I have
> > > > > mixed feelings.
> > > > >
> > > > > I would rather prefer to see better adoption/coverage of: flake8,
> > > > > ansible-lint and yamllint -- preferably orchestrated via
> pre-commit
> > > > > as it lowers the execution time and disk footprint (sharing/caching
> > > > > identical linters between repositories) -- opposed to tox which
> > > > > does not shared anything between repositories. Tripleo-quickstart
> > > > > and tripleo-ci repositories are already using it and I did not hear
> > > > > many complaints, other than having to explain that pre-commit is
> > > > > does not require the use of a git hook.
> > > >
> > > > I think we already use flake8 openstack-wide, what will Black bring
> > > > us in addition to that?
> > >
> > > I've seen this used with packages such as tox and warehouse (the new
> > > code base for pypi.org). black is intended to be an opinionated code
> > > formatter and exposes no knobs to the user, meaning it's very much
> > > "their way or the highway". This makes it different from something like
> > > yapf, which exposes all these knobs and therefore allows for arguments
> > > about e.g. whether one should use single or double quotes. No
> > > configuration knobs means no ability to discuss these preferences,
> > > which for something as subjective as code formatting seems to be a good
> > > thing to me.
> > >
> > > Now, as to whether it's practical, you have to realize that for it to
> > > be of any use, black has to be run initially over your entire codebase
> > > and then rerun on each commit. The latter isn't an issue (we already
> > > run flake8 for this purpose) but I genuinely cannot see something like
> > > nova rewrapping every line of code (all 552,347 of them, if my quick
> > > check is correct), essentially breaking the ability to cleanly backport
> > > patches and get meaningful 'git blame' output simply to avoid the
> > > occasional debate about code formatting. I think adopting black for a
> > > _new_ project (or even a very small one) could be a great idea, but for
> > > something as large and cumbersome as nova (or neutron, glance, cinder,
> > > some of the oslo libraries, etc.), maaaaaybe not.
> >
> > +100 to this. Resolving manually many conflicts between master and
> stable branches just because e.g. quoting was
> > changed doesn’t seems like good thing :)
> you realise if we also applied this to the stable branches too we would
> never need to resolve
> a merge conflict due to formating again or correct any pep8/style issues
> on backports.
> but yes its a valid concern.
>
> i guess the general feedback so far has been unless there is a way to do
> it incrementally this is a non starter.
> that is sad but if that is how people feel ill let this to the original
> poster to fight.
> >
> > >
> > > Stephen
> > >
> > > PS: As an aside, I would like to see something like black provided as
> > > part of the Python standard library to settle formatting issues for
> > > once and for all and help ensure that a minimum standard is set for
> > > most code you'll find (though code quality covers far more than mere
> > > formatting). To the best of my knowledge, the gofmt tool in go(lang)
> > > fills this role but I really can't see that happening within Python any
> > > time soon.
> > >
> > > > Dmitry
> > > >
> > > > >
> > > > > Shortly, +2 on more pre-commit use, the tool not the git hook.
> > > > >
> > > > >
> > > > > PS. Please do not bring the SCL into the thread, they do not
> > > > > provide a single command enablement of additional python
> > > > > interpreters (not in PATH).
> > > > >
> > > > > > On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com>
> > > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On 4/18/19 10:51 AM, Natal Ngétal wrote:
> > > > > > > Hi everyone,
> > > > > > > Black is project to format Python code. It's more and more used
> > > > > > > by the python community. That can save time and harmonize the
> > > > > > > code. For example, simple quote versus double quote, that was
> > > > > > > not checked by pep8.i It's just an example of what make  black
> > > > > > > With a pre-hook commit hook this will be also avoid to lose
> > > > > > > time with pep8 errors.
> > > > > >
> > > > > > I'm not sure what exactly Black does, but the last thing I want
> > > > > > to see is patches changing between single and double quotes. If
> > > > > > it's not the case or it can be turned off, I'm all for
> > > > > > experimenting.
> > > > > >
> > > > > > > Two links to see more:
> > > > > > > https://github.com/ambv/black
> > > > > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > > > > I think it can be very interesting to start to use Black on
> > > > > > > OpenStack. What do you thinks about that? For example, we can
> > > > > > > introduce it on some projects, I would volunteer to try on
> > > > > > > TripleO.
> > > > > >
> > > > > > Given it's a pre-commit hook, isn't it supposed to be done on
> > > > > > developer's machines? If so, how do you see applying Black to the
> > > > > > whole OpenStack?
> > > > > >
> > > > > > Dmitry
> > > > > >
> > > > > > > My best regards
> >
> > —
> > Slawek Kaplonski
> > Senior software engineer
> > Red Hat
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/38c7a14b/attachment.html>

From e0ne at e0ne.info  Thu Apr 18 12:21:57 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Thu, 18 Apr 2019 15:21:57 +0300
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <CADwwA9swoW-kwE3YL6fbvy3Ki1sC=P4wsb+dPZo+225YB1JF7g@mail.gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
 <CADwwA9swoW-kwE3YL6fbvy3Ki1sC=P4wsb+dPZo+225YB1JF7g@mail.gmail.com>
Message-ID: <CAGocpaGrdnSftGqqoBK_3JwW==LmNL6OzapkVAfOH3G6gwXY_w@mail.gmail.com>

+1 from me.

Brian, thank you for your contributions especially for stable branch
maintenance and IRC participation.

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


On Wed, Apr 17, 2019 at 8:12 PM Xing Yang <xingyang105 at gmail.com> wrote:

> +1
>
> On Wed, Apr 17, 2019 at 10:51 AM Jay Bryant <jungleboyj at gmail.com> wrote:
>
>> Team,
>>
>> I would like to propose Brian Rosmaita for Cinder core.
>>
>> His participation in Cinder has been steadily increasing during the
>> Stein release.  He attended the mid-cycle meeting in Raleigh and was
>> able to provide great insight and input using his experience from Glance.
>>
>> His review activity has been consistent during Stein.  He has helped get
>> backports to our stable branches and subsequently has ensured that we do
>> timely releases of Cinder's components.
>>
>> Considering the broad range of activity Brian has demonstrated and his
>> years of experience in OpenStack I think he will serve as an excellent
>> addition to our core team.
>>
>> If I do not hear any concerns with this nomination I will make Brian
>> core on 4/24.
>>
>> Thank you!
>>
>> Jay
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/f19e5567/attachment-0001.html>

From rajatdhasmana at gmail.com  Thu Apr 18 12:32:29 2019
From: rajatdhasmana at gmail.com (Rajat Dhasmana)
Date: Thu, 18 Apr 2019 18:02:29 +0530
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
Message-ID: <CAPhBjvZd7TcERvjD3=1qds7QgFRTsOisrbtOoA=PiSd4-6X0JQ@mail.gmail.com>

+1 from my side.

On Wed, Apr 17, 2019, 8:25 PM Jay Bryant <jungleboyj at gmail.com wrote:

> Team,
>
> I would like to propose Brian Rosmaita for Cinder core.
>
> His participation in Cinder has been steadily increasing during the
> Stein release.  He attended the mid-cycle meeting in Raleigh and was
> able to provide great insight and input using his experience from Glance.
>
> His review activity has been consistent during Stein.  He has helped get
> backports to our stable branches and subsequently has ensured that we do
> timely releases of Cinder's components.
>
> Considering the broad range of activity Brian has demonstrated and his
> years of experience in OpenStack I think he will serve as an excellent
> addition to our core team.
>
> If I do not hear any concerns with this nomination I will make Brian
> core on 4/24.
>
> Thank you!
>
> Jay
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/91c1b631/attachment.html>

From rosmaita.fossdev at gmail.com  Thu Apr 18 12:37:16 2019
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 18 Apr 2019 08:37:16 -0400
Subject: [glance][interop] standardized image "name" ?
In-Reply-To: <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
References: <CAEs876hqdVk9+PbSdvSVB1i-++T6tkChnuOk2P1nic_89sR_Vw@mail.gmail.com>
 <939FEDBD-6E5E-43F2-AE1F-2FE71A71BF58@vmware.com>
 <20190408123255.vqwwvzzdt24tm3pq@yuggoth.org>
 <d6056691-497f-c6f9-b1ee-22ed4af4c49c@debian.org>
Message-ID: <4234325e-7569-e11f-53e9-72f07ed8ce53@gmail.com>

I really need to get caught up on my ML reading.

On 4/11/19 6:40 PM, Thomas Goirand wrote:
[snip]
> It's just a shame that Glance doesn't show MD5 and not sha512 sums by
> default...

The Secure Hash Algorithm Support ("multihash") spec [0] for Glance was
implemented in Rocky and provides a self-describing secure hash on
images (in addition to the 'checksum', which is preserved for backward
compatability.)  The default is SHA-512. See the Rocky release notes [1]
for some implementation details not covered by the spec.

The multihash is displayed in the image-list and image-show API
responses since Images API v2.7, and in the glanceclient since 2.12.0.

The glanceclient has been using the secure hash for download
verification since 2.13.0, with a fallback to the md5 'checksum' field
if the multihash isn't populated.  (It also optionally allows fallback
to md5 if the algorithm for the secure hash isn't available to the
client; this option is off by default.)  See the 2.13.0 release notes
[2] for details.

[0]
https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/multihash.html
[1] https://docs.openstack.org/releasenotes/glance/rocky.html#new-features
[2]
https://docs.openstack.org/releasenotes/python-glanceclient/rocky.html#relnotes-2-13-0-stable-rocky

> Cheers,
> 
> Thomas Goirand (zigo)




From opensrloo at gmail.com  Thu Apr 18 12:43:03 2019
From: opensrloo at gmail.com (Ruby Loo)
Date: Thu, 18 Apr 2019 08:43:03 -0400
Subject: [ironic] Stepping down from core
In-Reply-To: <CAF7gwdhH7Ozb=EiRSVCb8eUqLuLrHqDc3=LYKG=24qLJugnMwg@mail.gmail.com>
References: <TYXPR01MB1568525B894BC6A30EAEE93CEB250@TYXPR01MB1568.jpnprd01.prod.outlook.com>
 <2c707b00-08d2-96e2-056f-1e9ee4daa884@redhat.com>
 <CAF7gwdhH7Ozb=EiRSVCb8eUqLuLrHqDc3=LYKG=24qLJugnMwg@mail.gmail.com>
Message-ID: <CAJkGiNsK0TE53H8LVTj_ZMmxQcWNr+gTBJsxcVivMZwEvUC_EA@mail.gmail.com>

++++ Thank you!

--ruby

On Wed, Apr 17, 2019 at 9:39 AM Julia Kreger <juliaashleykreger at gmail.com>
wrote:

> Greetings Hironori,
>
> Thank you for your hard work and contributions to Ironic! It was great
> working with you and I hope to work with you again in the future. Good
> luck on your next challenge!
>
> -Julia
>
> On Wed, Apr 17, 2019 at 12:52 AM Dmitry Tantsur <dtantsur at redhat.com>
> wrote:
> >
> > Hi Hironori,
> >
> > It was great to work with you all this time. Thank you for your
> invaluable
> > contributions, and good luck with your new challenge!
> >
> > Dmitry
> >
> > On 4/17/19 9:43 AM, shiina.hironori at fujitsu.com wrote:
> > > Hi ironic folks,
> > >
> > > I'm sorry for my long absence. My job responsibility changed last
> November. Since it,
> > > I have been trying to spend some time on the core activity. But, I
> couldn't. So, I'm
> > > stepping down from the ironic core team.
> > >
> > > Thank you for accepting me to the team even though I didn't often
> appear in IRC due
> > > to the time difference. I hope I will work with you again someday.
> > >
> > > Best regards,
> > > Hironori
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/7c83e24f/attachment.html>

From emilien at redhat.com  Thu Apr 18 12:50:33 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 18 Apr 2019 08:50:33 -0400
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
Message-ID: <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>

Yes! And a great step forward to have new leaders in TripleO.

Thanks for your hard work Cédric!

On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com> wrote:

> Hi TripleO devs,
>
> The new Validation Framework is a big step further for the
> tripleo-validations
> project. In many ways, it improves the way of detecting & reporting
> potential
> issues during a TripleO deployment. As the mastermind of this new
> framework,
> Cédric brought a new lease of life to the tripleo-validations project.
> That's
> why we would highly benefit from his addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Cédric to the core team
> next
> week.
>
> Thanks, Cédric, for your excellent work!
>
> =Gaël
>


-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/4230ce66/attachment.html>

From bdobreli at redhat.com  Thu Apr 18 13:07:15 2019
From: bdobreli at redhat.com (Bogdan Dobrelya)
Date: Thu, 18 Apr 2019 15:07:15 +0200
Subject: =?UTF-8?Q?Re=3a_=5btripleo=5d_Nominate_C=c3=a9dric_Jeanneret_=28Ten?=
 =?UTF-8?Q?gu=29_for_tripleo-validations_core?=
In-Reply-To: <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
Message-ID: <d76cb4f7-3515-2ede-8e5b-b6c4fdb23745@redhat.com>

+1

On 18.04.2019 14:50, Emilien Macchi wrote:
> Yes! And a great step forward to have new leaders in TripleO.
> 
> Thanks for your hard work Cédric!
> 
> On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com 
> <mailto:gchamoul at redhat.com>> wrote:
> 
>     Hi TripleO devs,
> 
>     The new Validation Framework is a big step further for the
>     tripleo-validations
>     project. In many ways, it improves the way of detecting & reporting
>     potential
>     issues during a TripleO deployment. As the mastermind of this new
>     framework,
>     Cédric brought a new lease of life to the tripleo-validations
>     project. That's
>     why we would highly benefit from his addition to the core reviewer team.
> 
>     Assuming that there are no objections, we will add Cédric to the
>     core team next
>     week.
> 
>     Thanks, Cédric, for your excellent work!
> 
>     =Gaël
> 
> 
> 
> -- 
> Emilien Macchi


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando


From ccamacho at redhat.com  Thu Apr 18 13:16:28 2019
From: ccamacho at redhat.com (Carlos Camacho Gonzalez)
Date: Thu, 18 Apr 2019 15:16:28 +0200
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <d76cb4f7-3515-2ede-8e5b-b6c4fdb23745@redhat.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
 <d76cb4f7-3515-2ede-8e5b-b6c4fdb23745@redhat.com>
Message-ID: <CANYJBfb-RGETm6PtnRsX-o8tMuUY5sXx9obuP3A8c=MWRL_Hzw@mail.gmail.com>

tengu++ (+1)

On Thu, Apr 18, 2019, 15:15 Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> +1
>
> On 18.04.2019 14:50, Emilien Macchi wrote:
> > Yes! And a great step forward to have new leaders in TripleO.
> >
> > Thanks for your hard work Cédric!
> >
> > On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com
> > <mailto:gchamoul at redhat.com>> wrote:
> >
> >     Hi TripleO devs,
> >
> >     The new Validation Framework is a big step further for the
> >     tripleo-validations
> >     project. In many ways, it improves the way of detecting & reporting
> >     potential
> >     issues during a TripleO deployment. As the mastermind of this new
> >     framework,
> >     Cédric brought a new lease of life to the tripleo-validations
> >     project. That's
> >     why we would highly benefit from his addition to the core reviewer
> team.
> >
> >     Assuming that there are no objections, we will add Cédric to the
> >     core team next
> >     week.
> >
> >     Thanks, Cédric, for your excellent work!
> >
> >     =Gaël
> >
> >
> >
> > --
> > Emilien Macchi
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/f2ef521a/attachment-0001.html>

From jaosorior at redhat.com  Thu Apr 18 13:22:24 2019
From: jaosorior at redhat.com (Juan Antonio Osorio Robles)
Date: Thu, 18 Apr 2019 16:22:24 +0300
Subject: =?UTF-8?Q?Re=3a_=5btripleo=5d_Nominate_C=c3=a9dric_Jeanneret_=28Ten?=
 =?UTF-8?Q?gu=29_for_tripleo-validations_core?=
In-Reply-To: <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
Message-ID: <5459f83c-03b4-ebb2-17d5-db688d821af7@redhat.com>

+1

On 4/18/19 3:50 PM, Emilien Macchi wrote:
> Yes! And a great step forward to have new leaders in TripleO.
>
> Thanks for your hard work Cédric!
>
> On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com
> <mailto:gchamoul at redhat.com>> wrote:
>
>     Hi TripleO devs,
>
>     The new Validation Framework is a big step further for the
>     tripleo-validations
>     project. In many ways, it improves the way of detecting &
>     reporting potential
>     issues during a TripleO deployment. As the mastermind of this new
>     framework,
>     Cédric brought a new lease of life to the tripleo-validations
>     project. That's
>     why we would highly benefit from his addition to the core reviewer
>     team.
>
>     Assuming that there are no objections, we will add Cédric to the
>     core team next
>     week.
>
>     Thanks, Cédric, for your excellent work!
>
>     =Gaël
>
>
>
> -- 
> Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/2bf42675/attachment.html>

From johfulto at redhat.com  Thu Apr 18 13:25:50 2019
From: johfulto at redhat.com (John Fulton)
Date: Thu, 18 Apr 2019 09:25:50 -0400
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <5459f83c-03b4-ebb2-17d5-db688d821af7@redhat.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
 <5459f83c-03b4-ebb2-17d5-db688d821af7@redhat.com>
Message-ID: <CAE66OMDDdWuxBX8iM2uHHC2Z5S_oLYu2c_c_zbaf3H3ubr4u2g@mail.gmail.com>

+1

On Thu, Apr 18, 2019 at 9:24 AM Juan Antonio Osorio Robles
<jaosorior at redhat.com> wrote:
>
> +1
>
> On 4/18/19 3:50 PM, Emilien Macchi wrote:
>
> Yes! And a great step forward to have new leaders in TripleO.
>
> Thanks for your hard work Cédric!
>
> On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com> wrote:
>>
>> Hi TripleO devs,
>>
>> The new Validation Framework is a big step further for the tripleo-validations
>> project. In many ways, it improves the way of detecting & reporting potential
>> issues during a TripleO deployment. As the mastermind of this new framework,
>> Cédric brought a new lease of life to the tripleo-validations project. That's
>> why we would highly benefit from his addition to the core reviewer team.
>>
>> Assuming that there are no objections, we will add Cédric to the core team next
>> week.
>>
>> Thanks, Cédric, for your excellent work!
>>
>> =Gaël
>
>
>
> --
> Emilien Macchi


From bence.romsics at gmail.com  Thu Apr 18 13:34:37 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Thu, 18 Apr 2019 15:34:37 +0200
Subject: [neutron] RFE Decouple placement reporting service plugin from ML2
Message-ID: <CAHeS+39FSaNaq0KhiEF3LYxn3Px4Yeejqcm8-h=Cb-zY5GY_1w@mail.gmail.com>

Hi Neutrinos,

I'm wondering if we have a use case for the following RFE:

https://bugs.launchpad.net/neutron/+bug/1818479
Decouple placement reporting service plugin from ML2

Very close to the Stein rc1 deadline we merged a change with a review
comment we agreed to tackle in a followup RFE - the one above. Here's
the original comment from Slawek:

https://review.openstack.org/#/c/580672/30/neutron/services/placement_report/plugin.py at 187

I see why Slawek left the comment, the placement reporter service
plugin's dependency on ML2 does hurt my aestethic sense too. But now
starting to work out the details of the followup work I'm not sure if
we have a use case here. I would like to understand if we have a use
case or not, because the change we talked about would increase code
complexity. So it needs justification. If we don't have a use case we
better do nothing and leave the complexity as it is. But if we do have
a use case I'm still happy to work on that.

In short: What concrete problems does it mean if the placement
reporter service plugin depends on the ML2 core plugin? When
eliminating that dependency what use case(s) are we generalizing the
code for?

I see the following options:

1) There may be an agent reporting its resource information in a
different format - unlike ovs-agent and sriov-agent.

2) There may be an agentless mechanism driver needing to sync to Placement.

3) There may be a non-ML2 core plugin needing to sync to Placement.

For (1) we standardized the format included in the agent's
configurations attribute. An agent newly implementing support for
reporting resource information should only deviate from that format if
that format cannot express the resource information. Do we have an
agent like that?

The format is basically a 2-layer mapping from physnets to the list of
their backing physical devices (whatever that is for an agent:
bridges, sriov PFs, etc) and further mapping to the backing devices'
inventory numbers.

For the exact format please see this piece of the docs:
https://docs.openstack.org/neutron/stein/admin/config-qos-min-bw.html#neutron-openvswitch-agent-config

Case (2) may be a realistic use case, but I'm not much familiar with
agentless mechanism drivers.

IIUC some agentless mechanism drivers actually maintain fake agent
entries in the neutron db. Those drivers can utilize the current
service plugin via the fake agent entries as if they were real.

For really agentless mechanism drivers (not even fake agent records)
and for (3) I'm inclined to say: Don't load this placement reporter
service plugin but write your own.

To summarize on a high level: Slawek's original comment on the
implicit dependency detects a real design smell, but I don't see how
refactoring the service plugin to a driver architecture would improve
the situation. What could nicely make this plugin more generic is
subscribing to another interface: create/update_host_resources()
instead of create/update_agent() because agents today are an
implementation detail of the ML2 drivers. But the host (instead of an
agent) is an abstraction we never had in neutron.

What do you think?

Sorry for the long mail,
Bence
irc: rubasov


From sean.mcginnis at gmx.com  Thu Apr 18 13:45:42 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 18 Apr 2019 08:45:42 -0500
Subject: The python black project.
In-Reply-To: <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
Message-ID: <20190418134541.GA19784@sm-workstation>

> I think we already use flake8 openstack-wide, what will Black bring us in
> addition to that?
>
> Dmitry

Based on my quick test, it would bring us code churn of changing ' to " and
flake8 errors due to unwrapping lines and making them longer than 80
characters.

I like the idea of code consistency. But having a tool automatically do it
without being able to tweak the settings, and having defaults do things that
introduce pep8 errors, seems like a non-starter.

And as mentioned elsewhere, introducing something like this to a long
established code base has a lot of problems. Maybe new projects just starting
off may want to investigate further, but running on most projects could be a
nightmare.

Sean


From mordred at inaugust.com  Thu Apr 18 14:00:32 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Thu, 18 Apr 2019 14:00:32 +0000
Subject: The python black project.
In-Reply-To: <20190418134541.GA19784@sm-workstation>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
Message-ID: <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>



On 4/18/19 1:45 PM, Sean McGinnis wrote:
>> I think we already use flake8 openstack-wide, what will Black bring us in
>> addition to that?
>>
>> Dmitry
> 
> Based on my quick test, it would bring us code churn of changing ' to " and
> flake8 errors due to unwrapping lines and making them longer than 80
> characters.
> 
> I like the idea of code consistency. But having a tool automatically do it
> without being able to tweak the settings, and having defaults do things that
> introduce pep8 errors, seems like a non-starter.
> 
> And as mentioned elsewhere, introducing something like this to a long
> established code base has a lot of problems. Maybe new projects just starting
> off may want to investigate further, but running on most projects could be a
> nightmare.

I agree.

I actually looked at black a little while ago for openstacksdk - because 
I do like me some strict style rules. The long-line-length sucked, 
although making a tox env that passes a reasonable line-length worked 
around that.

The biggest problem is that, even in a pretty clean codebase that 
already tries to follow a lot of what black likes (line breaks after 
brackets - yes please!) - the churn was MASSIVE and really just not 
worth it.

If we were starting OpenStack from-scratch today, I'd recommend we adopt 
it. But we're not.

Also - if new projects decided to adopt black, we'd wind up with two 
conflicting codestyles across OpenStack, which is one of the things our 
long-standing gating on pep8 is supposed to prevent. I don't think it's 
a good idea for OpenStack to _partially_ adopt black.

Monty


From ebiibe82 at gmail.com  Thu Apr 18 05:24:38 2019
From: ebiibe82 at gmail.com (Amit Kumar)
Date: Thu, 18 Apr 2019 10:54:38 +0530
Subject: [Kolla-Ansible] Support for LXC
Message-ID: <CAKLnnCsRkODbcVd-ZCocULfJK3bk7xm7caWa4gcKM5CZVStxew@mail.gmail.com>

Hello All,

We have deployed OpenStack multinode using Kolla-Ansible. We are able to
create VMs, Docker Containers (using Zun). However, we also want to launch
LXCs, but we couldn't find any such option in globals.yaml to enable this
support.

Is there any plan to provide it out-of-box? If anybody has enabled LXC
using Kolla-Ansible by themselves, then also please let us know.

Thanks.

Regards,
Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/13d81dd5/attachment-0001.html>

From mbollo at redhat.com  Thu Apr 18 13:13:18 2019
From: mbollo at redhat.com (Mats Bollo)
Date: Thu, 18 Apr 2019 15:13:18 +0200
Subject: The python black project.
In-Reply-To: <CAGocpaHpVJMM6EwUvHnduR-EGqF5jNEbVVqHi6Ku1ymnUjbxWw@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <1D2902DD-2956-4F04-A985-9F4114CE601C@redhat.com>
 <e1a8462234b25ab679d81b72c177d8242969c7bd.camel@redhat.com>
 <CAGocpaHpVJMM6EwUvHnduR-EGqF5jNEbVVqHi6Ku1ymnUjbxWw@mail.gmail.com>
Message-ID: <CAF+jc3Vu1y8703Y48z-_1MxFN7rBTxLfT60okTAa5o7vRmY-Zw@mail.gmail.com>

On Thu, Apr 18, 2019 at 2:13 PM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:
> In general, I would like to have black formatter for the OpenStack code.
Maybe we can use black formatter on a new projects.

> I agree with the points mentioned above about git blame. Also, I really
> don't want to have dozens of patches just to address few more black rules
> in the existing code base.
I understand what you mean. Merge and backport problem.


From sean.mcginnis at gmx.com  Thu Apr 18 15:15:49 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 18 Apr 2019 10:15:49 -0500
Subject: [tripleo] [Release-job-failures] Release of openstack/puppet-tripleo
 failed
Message-ID: <20190418151548.GA26446@sm-workstation>

There was a failure in the post-release job for puppet-tripleo that I think we
will need someone from TripleO and or someone with Puppet knowledge to address.

The error received was:

    Forge API failed to upload tarball with code: 400 errors: The dependency
    'sensu/sensu' in metadata.json is empty. All dependencies must have a
    'version_requirement'.,The dependency 'yelp/uchiwa' in metadata.json is
    empty. All dependencies must have a 'version_requirement'.

http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/job-output.txt.gz#_2019-04-18_15_03_39_765725

I'm guessing that's something in the puppet-tripleo repo, but really have no
idea how this part works. If someone from the team could look into this, we can
then do a follow up release if needed to correct any issues.

----- Forwarded message from zuul at openstack.org -----

Date: Thu, 18 Apr 2019 15:04:39 +0000
From: zuul at openstack.org
To: release-job-failures at lists.openstack.org
Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed
Reply-To: openstack-discuss at lists.openstack.org

Build failed.

- release-openstack-puppet http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/ : POST_FAILURE in 3m 18s
- announce-release announce-release : SKIPPED

_______________________________________________
Release-job-failures mailing list
Release-job-failures at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

----- End forwarded message -----


From whayutin at redhat.com  Thu Apr 18 15:24:40 2019
From: whayutin at redhat.com (Wesley Hayutin)
Date: Thu, 18 Apr 2019 09:24:40 -0600
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <CAE66OMDDdWuxBX8iM2uHHC2Z5S_oLYu2c_c_zbaf3H3ubr4u2g@mail.gmail.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
 <5459f83c-03b4-ebb2-17d5-db688d821af7@redhat.com>
 <CAE66OMDDdWuxBX8iM2uHHC2Z5S_oLYu2c_c_zbaf3H3ubr4u2g@mail.gmail.com>
Message-ID: <CAOHJT4+zuYyejo0raoMJfR9-50TQ06RPx8QEVvFsPWzoSXetBg@mail.gmail.com>

woot +1

On Thu, Apr 18, 2019 at 7:33 AM John Fulton <johfulto at redhat.com> wrote:

> +1
>
> On Thu, Apr 18, 2019 at 9:24 AM Juan Antonio Osorio Robles
> <jaosorior at redhat.com> wrote:
> >
> > +1
> >
> > On 4/18/19 3:50 PM, Emilien Macchi wrote:
> >
> > Yes! And a great step forward to have new leaders in TripleO.
> >
> > Thanks for your hard work Cédric!
> >
> > On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com>
> wrote:
> >>
> >> Hi TripleO devs,
> >>
> >> The new Validation Framework is a big step further for the
> tripleo-validations
> >> project. In many ways, it improves the way of detecting & reporting
> potential
> >> issues during a TripleO deployment. As the mastermind of this new
> framework,
> >> Cédric brought a new lease of life to the tripleo-validations project.
> That's
> >> why we would highly benefit from his addition to the core reviewer team.
> >>
> >> Assuming that there are no objections, we will add Cédric to the core
> team next
> >> week.
> >>
> >> Thanks, Cédric, for your excellent work!
> >>
> >> =Gaël
> >
> >
> >
> > --
> > Emilien Macchi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/d9f441f8/attachment.html>

From aschultz at redhat.com  Thu Apr 18 15:37:01 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Thu, 18 Apr 2019 09:37:01 -0600
Subject: [tripleo] [Release-job-failures] Release of
 openstack/puppet-tripleo failed
In-Reply-To: <20190418151548.GA26446@sm-workstation>
References: <20190418151548.GA26446@sm-workstation>
Message-ID: <CAFsb3b48_B68kmAi2MgMfzAkPZbmUx7FnawxFDjVPa4mNdMegQ@mail.gmail.com>

On Thu, Apr 18, 2019 at 9:21 AM Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>
> There was a failure in the post-release job for puppet-tripleo that I think we
> will need someone from TripleO and or someone with Puppet knowledge to address.
>
> The error received was:
>
>     Forge API failed to upload tarball with code: 400 errors: The dependency
>     'sensu/sensu' in metadata.json is empty. All dependencies must have a
>     'version_requirement'.,The dependency 'yelp/uchiwa' in metadata.json is
>     empty. All dependencies must have a 'version_requirement'.
>
> http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/job-output.txt.gz#_2019-04-18_15_03_39_765725
>
> I'm guessing that's something in the puppet-tripleo repo, but really have no
> idea how this part works. If someone from the team could look into this, we can
> then do a follow up release if needed to correct any issues.
>

https://review.openstack.org/#/c/653795/ to fix the version
requirements. We'll likely have to bump versions and release
puppet-tripleo again

> ----- Forwarded message from zuul at openstack.org -----
>
> Date: Thu, 18 Apr 2019 15:04:39 +0000
> From: zuul at openstack.org
> To: release-job-failures at lists.openstack.org
> Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed
> Reply-To: openstack-discuss at lists.openstack.org
>
> Build failed.
>
> - release-openstack-puppet http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/ : POST_FAILURE in 3m 18s
> - announce-release announce-release : SKIPPED
>
> _______________________________________________
> Release-job-failures mailing list
> Release-job-failures at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> ----- End forwarded message -----
>


From beagles at redhat.com  Thu Apr 18 15:48:50 2019
From: beagles at redhat.com (Brent Eagles)
Date: Thu, 18 Apr 2019 13:18:50 -0230
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <CAOHJT4+zuYyejo0raoMJfR9-50TQ06RPx8QEVvFsPWzoSXetBg@mail.gmail.com>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
 <CACu=hyurigB-O+E6f_f07uHn=WJDZ8w9xvQyh7Ob-KWcmBFCuQ@mail.gmail.com>
 <5459f83c-03b4-ebb2-17d5-db688d821af7@redhat.com>
 <CAE66OMDDdWuxBX8iM2uHHC2Z5S_oLYu2c_c_zbaf3H3ubr4u2g@mail.gmail.com>
 <CAOHJT4+zuYyejo0raoMJfR9-50TQ06RPx8QEVvFsPWzoSXetBg@mail.gmail.com>
Message-ID: <CADnDpCb7mAYWzJ-JYwAjYA+sLKbc_SiHpwu+g-By=KCiSUJVGg@mail.gmail.com>

+1 indeed

On Thu, Apr 18, 2019 at 1:00 PM Wesley Hayutin <whayutin at redhat.com> wrote:

> woot +1
>
> On Thu, Apr 18, 2019 at 7:33 AM John Fulton <johfulto at redhat.com> wrote:
>
>> +1
>>
>> On Thu, Apr 18, 2019 at 9:24 AM Juan Antonio Osorio Robles
>> <jaosorior at redhat.com> wrote:
>> >
>> > +1
>> >
>> > On 4/18/19 3:50 PM, Emilien Macchi wrote:
>> >
>> > Yes! And a great step forward to have new leaders in TripleO.
>> >
>> > Thanks for your hard work Cédric!
>> >
>> > On Thu, Apr 18, 2019 at 6:34 AM Gaël Chamoulaud <gchamoul at redhat.com>
>> wrote:
>> >>
>> >> Hi TripleO devs,
>> >>
>> >> The new Validation Framework is a big step further for the
>> tripleo-validations
>> >> project. In many ways, it improves the way of detecting & reporting
>> potential
>> >> issues during a TripleO deployment. As the mastermind of this new
>> framework,
>> >> Cédric brought a new lease of life to the tripleo-validations project.
>> That's
>> >> why we would highly benefit from his addition to the core reviewer
>> team.
>> >>
>> >> Assuming that there are no objections, we will add Cédric to the core
>> team next
>> >> week.
>> >>
>> >> Thanks, Cédric, for your excellent work!
>> >>
>> >> =Gaël
>> >
>> >
>> >
>> > --
>> > Emilien Macchi
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/c699cfb7/attachment.html>

From fungi at yuggoth.org  Thu Apr 18 15:51:10 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 18 Apr 2019 15:51:10 +0000
Subject: The python black project.
In-Reply-To: <884ef12e3a298e33a253d0f39c70a0ad8a975ee7.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <3c4eeaa564e84a8ad93726680e34fb59cdd84989.camel@redhat.com>
 <884ef12e3a298e33a253d0f39c70a0ad8a975ee7.camel@redhat.com>
Message-ID: <20190418155110.tjucnv7pe4otkaqk@yuggoth.org>

On 2019-04-18 11:55:11 +0100 (+0100), Sean Mooney wrote:
[...]
> the fact we have automated checking but not fixing of code style
> is one of the most irritating parts of working with openstack
> development personally.
[...]

Contrary to popular belief, the primary benefit we get from
automated style checks is *not* code consistency, it's reducing the
number of arguments and conflicting style recommendations reviewers
tend to have when we leave it up to them to decide how they think
someone else's patch should be written. With a style checker in
place we can more reliably tell reviewers to focus on function
rather than form, and to please keep their opinions about
indentation and quote choices to themselves.

Between projects (and even between branches of the same projects),
we already have a variety of linters at varying versions with a slew
of different per-project skips, choice of additional plugins and so
on. Code styles across the many hundreds of official Git
repositories in OpenStack aren't consistent and never have been, but
we still manage to produce much more readable, maintainable code
than most free/libre open source projects I've encountered. I for
one am willing to call that a win, and would prefer to focus on
producing software rather than producing whitespace and punctuation.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/2b67b806/attachment-0001.sig>

From emilien at redhat.com  Thu Apr 18 15:58:25 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 18 Apr 2019 11:58:25 -0400
Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed
In-Reply-To: <E1hH8ad-0001UV-6m@zuul01.openstack.org>
References: <E1hH8ad-0001UV-6m@zuul01.openstack.org>
Message-ID: <CACu=hyshXNSOfesNTwgHPxFwoetHQsSGN=aaD=BsjCEbQijeQg@mail.gmail.com>

fixed by https://review.openstack.org/#/c/653796/ and
https://review.openstack.org/#/c/653795/

On Thu, Apr 18, 2019 at 11:04 AM <zuul at openstack.org> wrote:

> Build failed.
>
> - release-openstack-puppet
> http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/
> : POST_FAILURE in 3m 18s
> - announce-release announce-release : SKIPPED
>
> _______________________________________________
> Release-job-failures mailing list
> Release-job-failures at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>


-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/9e417d1b/attachment.html>

From lbragstad at gmail.com  Thu Apr 18 16:08:37 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Thu, 18 Apr 2019 11:08:37 -0500
Subject: The python black project.
In-Reply-To: <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
Message-ID: <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>



On 4/18/19 9:00 AM, Monty Taylor wrote:
>
>
> On 4/18/19 1:45 PM, Sean McGinnis wrote:
>>> I think we already use flake8 openstack-wide, what will Black bring
>>> us in
>>> addition to that?
>>>
>>> Dmitry
>>
>> Based on my quick test, it would bring us code churn of changing ' to
>> " and
>> flake8 errors due to unwrapping lines and making them longer than 80
>> characters.
>>
>> I like the idea of code consistency. But having a tool automatically
>> do it
>> without being able to tweak the settings, and having defaults do
>> things that
>> introduce pep8 errors, seems like a non-starter.
>>
>> And as mentioned elsewhere, introducing something like this to a long
>> established code base has a lot of problems. Maybe new projects just
>> starting
>> off may want to investigate further, but running on most projects
>> could be a
>> nightmare.
>
> I agree.
>
> I actually looked at black a little while ago for openstacksdk -
> because I do like me some strict style rules. The long-line-length
> sucked, although making a tox env that passes a reasonable line-length
> worked around that.
>
> The biggest problem is that, even in a pretty clean codebase that
> already tries to follow a lot of what black likes (line breaks after
> brackets - yes please!) - the churn was MASSIVE and really just not
> worth it.
>
> If we were starting OpenStack from-scratch today, I'd recommend we
> adopt it. But we're not.
>
> Also - if new projects decided to adopt black, we'd wind up with two
> conflicting codestyles across OpenStack, which is one of the things
> our long-standing gating on pep8 is supposed to prevent. I don't think
> it's a good idea for OpenStack to _partially_ adopt black.

++

Conflicting code styles is just going to raise the cognitive bar for
contributors. If black's conventions are too restrictive, but we still
want more consistency, someone can drive an effort to start writing down
conventions we, as in OpenStack, think are important. Maybe our desired
conventions are closer to black's than we originally anticipated. Maybe
they're not.

Regardless, it seems the underlying issue is applying any convention to
a large codebase.

>
> Monty
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/eec67635/attachment.sig>

From mordred at inaugust.com  Thu Apr 18 16:11:45 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Thu, 18 Apr 2019 16:11:45 +0000
Subject: Scuba Diving at the Denver Summit
In-Reply-To: <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>
References: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
 <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>
Message-ID: <9cd4d330-5812-0b12-b783-017d23b2fd66@inaugust.com>

Hey folks!

So - I have good news and bad news. I'll start with the bad news.

The bad news is that there wasn't enough interest to justify booking a 
private dive. (There was also *no* interest in homestead crater) So 
we're down to just booking slots in their regularly scheduled dives on 
the weekend.

The good news is that there are still spaces available for booking. So I 
recommend going to:

https://a1scubastore.com/product/dive-with-the-fish/
https://a1scubastore.com/product/dive-with-the-sharks/

and booking a dive directly.

Sandy and I booked dive with the fish for Saturday (because I've got a 
board meeting on Sunday) Dive with the Fish is also now full (we got the 
last slots)

I sent a message to the dive shop to see if it's possible for us to 
_also_ do the shark dive on the same day. It is - so if any of you are 
interested in doing the Saturday shark dive, let me know and I'll book 
spots for Sandy and I for the shark dive as well. But go ahead and book 
yourself a spot - so we can make sure you get to dive before we book a 
second spot.

If that doesn't work for people, or if you prefer to do the fish dive on 
Sunday - don't worry about us.

Monty

On 4/18/19 7:05 AM, Rico Lin wrote:
> We usually need to reraise important stuff before Summit. So bump this 
> one!:) Can't wait!
> 
> On Wed, Jan 23, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com 
> <mailto:mordred at inaugust.com>> wrote:
> 
>     Hey everybody!
> 
>     tl;dr - Let me know if you'd like to go diving in the Rocky Mountains.
> 
>     Of all of the places we've had a Summit where one might reasonably
>     expect there to be a possibility of Scuba Diving, the Denver Summit is
>     probably REALLY low on the list.
> 
>     But it turns out that there is a Dive Shop that does dives at the
>     Denver
>     Aquarium [0] (with all the fish and sharks and whatnot) The Denver
>     Aquarium is also very close to the Convention Center.
> 
>     I'm going to see about putting together a private group dive event for
>     those of us who think that sounds like a fun idea. Due to
>     cross-contamination concerns for the health and safety of the fish, the
>     dive shop provides all equipment - so you don't have to bring gear.
>     They
>     will allow bringing your own mask - and I'm assuming if a well-scrubbed
>     mask is ok then a well-scrubbed dive computer would be ok - but I'll be
>     checking with them when I call to arrange things.
> 
>     If you are Open Water certified and would like to join, please send
>     me a
>     response back (reply directly to me rather than the list is fine) so I
>     can judge general interest level when talking to the lovely humans.
> 
>     If you are **NOT** Open Water certified but are thinking to yourself
>     "wow, that sounds like fun" - the dive shop does certification dives at
>     the aquarium on the weekends. That's a bit out of scope for me to
>     arrange, but if you want to show up in Denver early and do an Open
>     Water
>     class then join us, that's awesome. You can also get certified at home
>     before coming ... but you'll need an Open Water certification to
>     join us.
> 
>     BUT WAIT - THERE'S MORE!
> 
>     There is another interesting diving opportunity in the general Mountain
>     West area - although not immediately **close** to Denver - that Sandy
>     and I are going to be going to before the Summit - Homestead Crater.
>     We're arranging to meet a Scuba instructor there to do our second
>     Altitude cert dive, and also to do a 2-dive "Hot Springs Diver"
>     specialty. We'd be happy to have folks join us.
> 
>     Homestead Crater [1] is outside of Salt Lake City. It's a hot spring -
>     the water is 96F/35.5C and it's also an altitude dive. If people are
>     interested, we can meet at the crater on Thursday morning pre-summit,
>     dive the crater, then drive to Denver on Friday/Saturday.
> 
>     ** If only a small number of people are interested in any of this -
>     we'll likely just do the Denver dives the weekend before during one of
>     the normally scheduled dive times instead of arranging a group outing,
>     and shift Homestead, if anyone is interested, a few days earlier **
> 
>     I will not have space enough in my car to get you from the crater to
>     Denver, so if you want to fly in to SLC ahead of time and meet there,
>     awesome.
> 
>     Unlike Denver, the crater will require you have equipment, including
>     scuba tanks. For anyone interested in coming, there are dive shops in
>     Salt Lake where you can rent gear. There is a dive shop at the
>     crater to
>     do air fills.
> 
>     Anyway - if anyone is interested in some or all of these things, let me
>     know this week so I can get a headcount and then we can talk more
>     off-list about logistics and figure out how to deal with things for
>     people coming from far off (carpools, equipment, etc)
> 
>     Monty
> 
>     PS. If any of you aren't already using Subsurface for dive logging,
>     I'll
>     be happy to help you get set up.
> 
>     [0] https://divedowntown.com/
>     [1]
>     https://homesteadresort.com/utah-resort-things-to-do/homestead-crater/
> 
> 
> 
> -- 
> May The Force of OpenStack Be With You,
> */Rico Lin
> /*irc: ricolin
> 
> 


From mriedemos at gmail.com  Thu Apr 18 16:12:22 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 18 Apr 2019 11:12:22 -0500
Subject: [nova][dev] Pike Extended Maintenance coming soon
In-Reply-To: <a15eae55-5843-49aa-62e3-ef578db2ea12@gmail.com>
References: <a15eae55-5843-49aa-62e3-ef578db2ea12@gmail.com>
Message-ID: <cabd1716-ae37-44b7-1f3c-d1da76b60652@gmail.com>

On 3/14/2019 6:52 PM, melanie witt wrote:
> Hi all,
> 
> As mentioned in the nova meeting today, Pike Extended Maintenance is 
> coming soon. The date shown on the release page says 2019-03-03 but it's 
> predicted to occur after the Stein release (2019-04-10):
> 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003745.html 
> 
> 
> We are currently in the process of flushing the stable/pike review queue 
> for a final release of stable/pike:
> 
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z 
> 
> 
> Please be sure you get your backports proposed that you'd like to land 
> in the final Pike release. After Pike is put into extended maintenance, 
> there will be no more releases, but patches will still be accepted to 
> the branch:
> 
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases 
> 
> 
> Cheers,
> -melanie

I'm tracking the final push to nova's pike extended maintenance here:

https://etherpad.openstack.org/p/nova-stable-pike-em

-- 

Thanks,

Matt


From ralonsoh at redhat.com  Thu Apr 18 16:15:36 2019
From: ralonsoh at redhat.com (Rodolfo Alonso)
Date: Thu, 18 Apr 2019 17:15:36 +0100
Subject: [Neutron][QoS] No meeting on April 23
Message-ID: <8b5fce8770b310091879ffbbc01c908751c5b003.camel@redhat.com>

Hello folks:

Because of an agenda problem, I won't chair the QoS meeting on April 23. I talked to Miguel and
there is no problem to postpone this meeting until May 7, after the PTG.

Regards.




From cboylan at sapwetik.org  Thu Apr 18 16:20:49 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 18 Apr 2019 12:20:49 -0400
Subject: The python black project.
In-Reply-To: <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
 <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
Message-ID: <5dc44ed4-96d1-4437-8e83-bad8ddfc2bae@www.fastmail.com>

On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
> 
> 
> On 4/18/19 9:00 AM, Monty Taylor wrote:
> >
> >
> > On 4/18/19 1:45 PM, Sean McGinnis wrote:
> >>> I think we already use flake8 openstack-wide, what will Black bring
> >>> us in
> >>> addition to that?
> >>>
> >>> Dmitry
> >>
> >> Based on my quick test, it would bring us code churn of changing ' to
> >> " and
> >> flake8 errors due to unwrapping lines and making them longer than 80
> >> characters.
> >>
> >> I like the idea of code consistency. But having a tool automatically
> >> do it
> >> without being able to tweak the settings, and having defaults do
> >> things that
> >> introduce pep8 errors, seems like a non-starter.
> >>
> >> And as mentioned elsewhere, introducing something like this to a long
> >> established code base has a lot of problems. Maybe new projects just
> >> starting
> >> off may want to investigate further, but running on most projects
> >> could be a
> >> nightmare.
> >
> > I agree.
> >
> > I actually looked at black a little while ago for openstacksdk -
> > because I do like me some strict style rules. The long-line-length
> > sucked, although making a tox env that passes a reasonable line-length
> > worked around that.
> >
> > The biggest problem is that, even in a pretty clean codebase that
> > already tries to follow a lot of what black likes (line breaks after
> > brackets - yes please!) - the churn was MASSIVE and really just not
> > worth it.
> >
> > If we were starting OpenStack from-scratch today, I'd recommend we
> > adopt it. But we're not.
> >
> > Also - if new projects decided to adopt black, we'd wind up with two
> > conflicting codestyles across OpenStack, which is one of the things
> > our long-standing gating on pep8 is supposed to prevent. I don't think
> > it's a good idea for OpenStack to _partially_ adopt black.
> 
> ++
> 
> Conflicting code styles is just going to raise the cognitive bar for
> contributors. If black's conventions are too restrictive, but we still
> want more consistency, someone can drive an effort to start writing down
> conventions we, as in OpenStack, think are important. Maybe our desired
> conventions are closer to black's than we originally anticipated. Maybe
> they're not.
> 
> Regardless, it seems the underlying issue is applying any convention to
> a large codebase.

I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always format the code the way I (or you) want it.

Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other.

That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we probably don't want to have inconsistent rules across repos.

Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid needing to incur massive churn all at once.

Clark


From dtantsur at redhat.com  Thu Apr 18 16:28:51 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 18 Apr 2019 18:28:51 +0200
Subject: The python black project.
In-Reply-To: <5dc44ed4-96d1-4437-8e83-bad8ddfc2bae@www.fastmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
 <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
 <5dc44ed4-96d1-4437-8e83-bad8ddfc2bae@www.fastmail.com>
Message-ID: <fc3f0d5d-e412-c470-3a73-abdc6dc156b4@redhat.com>

On 4/18/19 6:20 PM, Clark Boylan wrote:
> On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
>>
>>
>> On 4/18/19 9:00 AM, Monty Taylor wrote:
>>>
>>>
>>> On 4/18/19 1:45 PM, Sean McGinnis wrote:
>>>>> I think we already use flake8 openstack-wide, what will Black bring
>>>>> us in
>>>>> addition to that?
>>>>>
>>>>> Dmitry
>>>>
>>>> Based on my quick test, it would bring us code churn of changing ' to
>>>> " and
>>>> flake8 errors due to unwrapping lines and making them longer than 80
>>>> characters.
>>>>
>>>> I like the idea of code consistency. But having a tool automatically
>>>> do it
>>>> without being able to tweak the settings, and having defaults do
>>>> things that
>>>> introduce pep8 errors, seems like a non-starter.
>>>>
>>>> And as mentioned elsewhere, introducing something like this to a long
>>>> established code base has a lot of problems. Maybe new projects just
>>>> starting
>>>> off may want to investigate further, but running on most projects
>>>> could be a
>>>> nightmare.
>>>
>>> I agree.
>>>
>>> I actually looked at black a little while ago for openstacksdk -
>>> because I do like me some strict style rules. The long-line-length
>>> sucked, although making a tox env that passes a reasonable line-length
>>> worked around that.
>>>
>>> The biggest problem is that, even in a pretty clean codebase that
>>> already tries to follow a lot of what black likes (line breaks after
>>> brackets - yes please!) - the churn was MASSIVE and really just not
>>> worth it.
>>>
>>> If we were starting OpenStack from-scratch today, I'd recommend we
>>> adopt it. But we're not.
>>>
>>> Also - if new projects decided to adopt black, we'd wind up with two
>>> conflicting codestyles across OpenStack, which is one of the things
>>> our long-standing gating on pep8 is supposed to prevent. I don't think
>>> it's a good idea for OpenStack to _partially_ adopt black.
>>
>> ++
>>
>> Conflicting code styles is just going to raise the cognitive bar for
>> contributors. If black's conventions are too restrictive, but we still
>> want more consistency, someone can drive an effort to start writing down
>> conventions we, as in OpenStack, think are important. Maybe our desired
>> conventions are closer to black's than we originally anticipated. Maybe
>> they're not.
>>
>> Regardless, it seems the underlying issue is applying any convention to
>> a large codebase.
> 
> I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always format the code the way I (or you) want it.
> 
> Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other.

Won't it make OpenStack code more surprising for outside contributors? I think 
if something is worth following, it is PEP-8, since it's a Python standard.

> 
> That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we probably don't want to have inconsistent rules across repos.
> 
> Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid needing to incur massive churn all at once.

This can become a big issue, actually. We'd probably have to pin Black to an 
exact version (excluding it from global-requirements).

> 
> Clark
> 



From emilien at redhat.com  Thu Apr 18 17:10:03 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 18 Apr 2019 13:10:03 -0400
Subject: [tripleo] Stein RC1 is out (with stable/stein branch)
Message-ID: <CACu=hyu1w2vJ-MpM5mDQ1wgCv9zo9jE0G9hRehD1aRfE25QCpw@mail.gmail.com>

We decided to branch stable/stein and release our first Stein release
candidate this week.
The main action that is being asked to our dear community is to think about
backporting patches landing in master that you want to see in Stein.
As usual some of us will watch things which land on master but really any
help on that is very welcome.

Also I've produced some stats about the evolution of TripleO since Newton.
https://docs.google.com/presentation/d/1RV30OVxmXv1y_z33LuXMVB56TA54Urp7oHIoTNwrtzA/edit?usp=sharing

A few highlights:
- Bug fixing is pretty consistent since Pike, no major change
- Stein is the release with the less implemented blueprints since before
Newton
- Our core contributors number keep growing
- Number of LOC & reviews keep growing since Queens

Thanks everyone for your hard work during this cycle, I'm looking forward
to seeing you in Denver and work on "Train".
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/eb2e8ea9/attachment.html>

From mriedemos at gmail.com  Thu Apr 18 17:26:26 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 18 Apr 2019 12:26:26 -0500
Subject: The python black project.
In-Reply-To: <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
 <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
Message-ID: <2b3e890e-1ec2-4315-8f9c-3e1d35c4b39e@gmail.com>

On 4/18/2019 11:08 AM, Lance Bragstad wrote:
> If black's conventions are too restrictive, but we still
> want more consistency, someone can drive an effort to start writing down
> conventions we, as in OpenStack, think are important.

Seems we've all forgotten openstack already has a project to do this:

http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst

It's just that people probably don't do many new hacking checks in their 
projects anymore, or they don't think about "upstreaming" them to the 
hacking library and then percolating those rules out to all other projects.

Also, each project can pick and choose which hacking checks they want to 
adopt, and enforce them gradually rather than all at once - which is one 
of the knocks I'm reading about Black in this thread.

-- 

Thanks,

Matt


From smooney at redhat.com  Thu Apr 18 17:35:27 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 18:35:27 +0100
Subject: The python black project.
In-Reply-To: <fc3f0d5d-e412-c470-3a73-abdc6dc156b4@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
 <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
 <5dc44ed4-96d1-4437-8e83-bad8ddfc2bae@www.fastmail.com>
 <fc3f0d5d-e412-c470-3a73-abdc6dc156b4@redhat.com>
Message-ID: <a3a7eb67e30b08b844afcffd80237ac11facc52f.camel@redhat.com>

On Thu, 2019-04-18 at 18:28 +0200, Dmitry Tantsur wrote:
> On 4/18/19 6:20 PM, Clark Boylan wrote:
> > On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
> > > 
> > > 
> > > On 4/18/19 9:00 AM, Monty Taylor wrote:
> > > > 
> > > > 
> > > > On 4/18/19 1:45 PM, Sean McGinnis wrote:
> > > > > > I think we already use flake8 openstack-wide, what will Black bring
> > > > > > us in
> > > > > > addition to that?
> > > > > > 
> > > > > > Dmitry
> > > > > 
> > > > > Based on my quick test, it would bring us code churn of changing ' to
> > > > > " and
> > > > > flake8 errors due to unwrapping lines and making them longer than 80
> > > > > characters.
> > > > > 
> > > > > I like the idea of code consistency. But having a tool automatically
> > > > > do it
> > > > > without being able to tweak the settings, and having defaults do
> > > > > things that
> > > > > introduce pep8 errors, seems like a non-starter.
> > > > > 
> > > > > And as mentioned elsewhere, introducing something like this to a long
> > > > > established code base has a lot of problems. Maybe new projects just
> > > > > starting
> > > > > off may want to investigate further, but running on most projects
> > > > > could be a
> > > > > nightmare.
> > > > 
> > > > I agree.
> > > > 
> > > > I actually looked at black a little while ago for openstacksdk -
> > > > because I do like me some strict style rules. The long-line-length
> > > > sucked, although making a tox env that passes a reasonable line-length
> > > > worked around that.
> > > > 
> > > > The biggest problem is that, even in a pretty clean codebase that
> > > > already tries to follow a lot of what black likes (line breaks after
> > > > brackets - yes please!) - the churn was MASSIVE and really just not
> > > > worth it.
> > > > 
> > > > If we were starting OpenStack from-scratch today, I'd recommend we
> > > > adopt it. But we're not.
> > > > 
> > > > Also - if new projects decided to adopt black, we'd wind up with two
> > > > conflicting codestyles across OpenStack, which is one of the things
> > > > our long-standing gating on pep8 is supposed to prevent. I don't think
> > > > it's a good idea for OpenStack to _partially_ adopt black.
> > > 
> > > ++
> > > 
> > > Conflicting code styles is just going to raise the cognitive bar for
> > > contributors. If black's conventions are too restrictive, but we still
> > > want more consistency, someone can drive an effort to start writing down
> > > conventions we, as in OpenStack, think are important. Maybe our desired
> > > conventions are closer to black's than we originally anticipated. Maybe
> > > they're not.
> > > 
> > > Regardless, it seems the underlying issue is applying any convention to
> > > a large codebase.
> > 
> > I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are
> > rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't
> > arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always
> > format the code the way I (or you) want it.
> > 
> > Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other.
> 
> Won't it make OpenStack code more surprising for outside contributors? I think 
> if something is worth following, it is PEP-8, since it's a Python standard.
pep8 is a set of guidelines that are intened for developers to use themsevels
to improve the readablity of there own code. it was never intended to be something
to force on others and it very clearly give peopel the fredom to not follow all of it.
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

having some divergence might be unfamilar but we already diverge today.
also pep8 leave several ways to do some things

def func(arg1, arg2, arg3):
    pass


def func(arg1, 
         arg2,
         arg3):
    pass

def func(
    arg1, arg2, arg3):
    pass

all 3 of those are pep8 complient functions

black say the last two are dumb becasue you are wasting virticl space making diffs bigger
and will handel the wraping as need to also stay withind the default of 88 charaters.
you can override it to 79 if we wanted too  but even pep8 says up to 99 charater is fine
if that is what teams agree too.
https://www.python.org/dev/peps/pep-0008/#maximum-line-length

> 

That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we
probably don't want to have inconsistent rules across repos.

Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when
Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid
needing to incur massive churn all at once.

This can become a big issue, actually. We'd probably have to pin Black to an 
exact version (excluding it from global-requirements).


Clark






From smooney at redhat.com  Thu Apr 18 17:40:37 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 18:40:37 +0100
Subject: The python black project.
In-Reply-To: <2b3e890e-1ec2-4315-8f9c-3e1d35c4b39e@gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <85519d6b-7266-f969-d7a3-570a4b8fbb56@redhat.com>
 <6B626ECB-8AD7-4C8C-8EFD-87EF33651079@redhat.com>
 <40b89343-7777-bb4f-96a3-82862629f6d7@redhat.com>
 <20190418134541.GA19784@sm-workstation>
 <e5811b9f-3043-383b-9a05-c5d07834431e@inaugust.com>
 <d563b563-1a0c-af53-c755-e646bc6f8486@gmail.com>
 <2b3e890e-1ec2-4315-8f9c-3e1d35c4b39e@gmail.com>
Message-ID: <cfb79a232d99e946f4252b26bc96da4cddcf867f.camel@redhat.com>

On Thu, 2019-04-18 at 12:26 -0500, Matt Riedemann wrote:
> On 4/18/2019 11:08 AM, Lance Bragstad wrote:
> > If black's conventions are too restrictive, but we still
> > want more consistency, someone can drive an effort to start writing down
> > conventions we, as in OpenStack, think are important.
> 
> Seems we've all forgotten openstack already has a project to do this:
> 
> http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst
hacking was in the back of my mind too 
> 
> It's just that people probably don't do many new hacking checks in their 
> projects anymore, or they don't think about "upstreaming" them to the 
> hacking library and then percolating those rules out to all other projects.
> 
> Also, each project can pick and choose which hacking checks they want to 
> adopt, and enforce them gradually rather than all at once - which is one 
> of the knocks I'm reading about Black in this thread.
they can but hacking unless i missed it cant reformat your code to make it complient.
i spend a non trivial amount of time just getting pep8 to be happy and even then i often
miss things. i which that could be automated away but it seam apparent that unless
that can be dont incremetally its not going to happen in nova.





From alifshit at redhat.com  Thu Apr 18 18:04:53 2019
From: alifshit at redhat.com (Artom Lifshitz)
Date: Thu, 18 Apr 2019 14:04:53 -0400
Subject: [nova] Running multinode resize tests in the gate
Message-ID: <CACqyMieRt4ONj6wU=Q2K-vxVeqduoTmvWY2VtroE7drFHHAcvg@mail.gmail.com>

Yo Novans,

In trying to understand why my partial fix to bug 1813789 [1] -
specifically the part where reverting  a resize fails because we get
the network-vif-plugged event from Neutron before we start listening
for it - I noticed that we don't test multinode resize (and revert) in
the gate. As far as I can tell, the only place where the revert tests
are run are in tempest-full-py3, and that's on an allinone single
node.

In order to test a theory of mine about revert resize on the same node
vs source to dest and back again, I do have a DNM patch up [2] to run
the resize tests in the nova-live-migration job - I think that's the
only multinode tempest job we have, right? I think that job also runs
evacuation tests [3], correct? So, should we just rename it
nova-multinode and add resize to the list of tests it runs?

[1] https://bugs.launchpad.net/nova/+bug/1813789
[2] https://review.openstack.org/#/c/653498/
[3] https://github.com/openstack/nova/blob/54d8b40471e6f7b36dbe45966c1c605f94d49182/playbooks/legacy/nova-live-migration/run.yaml#L52


From snikitin at mirantis.com  Thu Apr 18 18:50:12 2019
From: snikitin at mirantis.com (Sergey Nikitin)
Date: Thu, 18 Apr 2019 22:50:12 +0400
Subject: [stackalytics] Moving stackalytics configuration file to github repo
Message-ID: <CABURL_mWTC6rZfrfHJs_v0UYjMVez_9ag9+Yzt88A1QRsx4a4w@mail.gmail.com>

Hello everyone,

Every day Stackalytics team works on new features.
One of these features is a statistics collecting for non OpenStack
projects. For example Kubernetes [1].
Stackalytics project has configuration file (default_data.json), which
contains a lot of data, including user properties. Such as name, launchpad
ID, github ID, email and companies.

It's a usual situation when a contributor change his/her email or find a
better job in new company.
To do not loose stats which were pinned with old email or to point that
he/she now work in new company contributor must add/modify his/her record
in default_data.json config file.

This config file was in `etc` directory in stackalytics repo [2].
But we moved this file to new github repository [3].
It was made to do not force non OpenStack contributors use OpenStack Gerrit
to update their stackalytics profiles.

>From this moment if you want to update your stackalytics profile you must
create a pull request to the new github repo [3]. The new data will be
applied within 12 hours after pull request merge.

All current patches with user data changes from stackalytics gerrit [4] are
still valid and will be applied and moved to [3] after approve. So do not
worry about them.

More information about user data updating you can find in Stackalytics Wiki
page [5].

If you have any questions we will be glad to answer.

Stackalytics team.

[1] https://www.stackalytics.com/cncf?project_type=kubernetes
[2]
https://github.com/openstack/stackalytics/blob/master/etc/default_data.json
[3] https://github.com/stackalytics/default_data
[4]
https://review.openstack.org/#/q/project:openstack/stackalytics+status:open
[5] https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation

-- 
Best Regards,
Sergey Nikitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/e54beee1/attachment.html>

From clint at fewbar.com  Thu Apr 18 19:04:10 2019
From: clint at fewbar.com (Clint Byrum)
Date: Thu, 18 Apr 2019 12:04:10 -0700
Subject: The python black project.
In-Reply-To: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
Message-ID: <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>

Quoting Natal Ngétal (2019-04-18 01:51:47)
> Hi everyone,
> 
> Black is project to format Python code. It's more and more used by the python
> community. That can save time and harmonize the code. For example, simple quote
> versus double quote, that was not checked by pep8.i It's just an example of
> what make  black With a pre-hook commit hook this will be also avoid to lose
> time with pep8 errors.
> 
> Two links to see more:
> 
> https://github.com/ambv/black
> https://www.mattlayman.com/blog/2018/python-code-black/
> 
> I think it can be very interesting to start to use Black on OpenStack. What
> do you thinks about that? For example, we can introduce it on some projects, I
> would volunteer to try on TripleO.

I've read the arguments in the thread, and I really appreciate
everyone's thoughtfulness here.

I just wanted to add that I have been using black for some internal
projects, and it is an absolute joy to forget about code formatting.
This is different than the pep8 checks. The git hook just does it, and
our CI confirms that you do it, and there's no more "oops I forgot
pep8".

I believe that the whitespace churn that folks are bringing up is being
overblown. This is a single, automatically produced diff, that while it
might hurt a little in git annotate and conflicts with in-flight patches
now, there is value, and there are mitigations, that make it worth it in
some cases.

The main value is that using an automatic formatter will ultimately lead
to less wasted test runs, less wasted developer time, and better diffs
with less conflicts later.

So while I appreciate the desire to not rock the boat, it might be that
the boat would go faster after some dead weight is dropped overboard,
and that new energy is applied to forward progress instead of "darn it,
now I have to think about how to fit this into 80 chars and parenthesis
and ..."

Basically, weigh the one time cost vs. the ongoing savings, rather than
considering them separately.


From msm at redhat.com  Thu Apr 18 19:23:52 2019
From: msm at redhat.com (Michael McCune)
Date: Thu, 18 Apr 2019 15:23:52 -0400
Subject: The python black project.
In-Reply-To: <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
Message-ID: <CADE+ktTh9bq7enRWXsskak9PoM14VuvoJ3-KxerFN-A4Ur6wqQ@mail.gmail.com>

in general, i tend to think that adding more tooling to help the code
become more consistent is a good thing for the community and
especially people who are new to a project. there is one point i'd
like to mention in response to something that Clint said.

On Thu, Apr 18, 2019 at 3:10 PM Clint Byrum <clint at fewbar.com> wrote:
> I just wanted to add that I have been using black for some internal
> projects, and it is an absolute joy to forget about code formatting.
> This is different than the pep8 checks. The git hook just does it, and
> our CI confirms that you do it, and there's no more "oops I forgot
> pep8".

i think having this be automated is something that throws my personal
workflow off, and i hope that if it does become enshrined as a commit
hook that we give developers the tooling to test locally before
pushing for review. i like to be able to test all my changes locally
before i push for review, if there is a tool in between me and the
review and that changes my code then i /definitely/ want to be able to
test these changes before i go to review.

i imagine this is not a big deal, others have mentioned adding a tox
target or similar. i just wanted to bring it up as a point to consider
in this process.

peace o/


From openstack at fried.cc  Thu Apr 18 19:56:03 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 18 Apr 2019 14:56:03 -0500
Subject: [nova][ptg] Privsep is not giving us any security
In-Reply-To: <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
References: <CAEkQehfun+80Mcb4=Jd8n5Vdugm5TC7RyJdFho3ia5_VDX=szw@mail.gmail.com>
 <CAEd1pt56chcD7SnvG9jxULfiYWu-mmex=FOcFBqWOVysKW6aeA@mail.gmail.com>
 <99f73d03-5c21-d346-4611-12f87c4ac124@openstack.org>
 <CAEd1pt646h02niEA9nsad+xoHaJRY7hdFsBEQyZRyJo+Vs-7PA@mail.gmail.com>
 <CAEkQehfgDA8gAVBkawfeFfuBSbqwBbFbVBXbR0pLJew-iCuaEQ@mail.gmail.com>
 <231d6fbe-705e-a6e8-ae05-ede5bf4e37e9@nemebean.com>
 <CAEd1pt4LJq8xHBUm8ke=Qvw+=cn1iFjSBw=SkmJ=xHhjc8M5ig@mail.gmail.com>
 <dc6730a7-a78e-d868-3bc3-73eb8ca526f2@nemebean.com>
 <8d4f19ea-0a95-2f4a-31e4-03bc03ba5511@openstack.org>
 <b0fb4292-5bf8-a316-5862-e2735cfec033@fried.cc>
Message-ID: <878ce236-20c7-8823-a1ef-d9dca67218df@fried.cc>

Scrubbing the Nova PTG agenda (hence added [ptg] subject tag), and this
is currently on it.

>> 1- introduce privsep
>> 2- change rootwrap calls into generic privsep functions
>> 3- start refactoring calling code so that generic privsep functions can
>> be replaced by narrow, context-aware functions

Based on the discussion in this thread, it sounds to me like nobody
disagrees about what should be done; it's going to be a matter of
getting mikal's series (2 above, [A] below) finished up and then finding
one or more bodies to throw at the next step (3 above).

Can I ask someone (perhaps Mr. Booth?) to file a blueprint to track this?

Is there any part of 3 that we expect to be able to start/finish in Train?

And other than that, is there anything further to discuss, or can we
strike this from the PTG agenda?

> [A]
> https://review.openstack.org/#/q/topic:my-own-personal-alternative-universe+(status:open+OR+status:merged)
> [B] Note that that series has been in flight for quite a while. The
> patch that actually removes rootwrap
> (https://review.openstack.org/#/c/554438/) was first proposed right
> about a year ago. I'm hoping this email thread gets the series some more
> review attention.

Thanks,
efried
.


From dpeacock at redhat.com  Thu Apr 18 20:42:05 2019
From: dpeacock at redhat.com (David Peacock)
Date: Thu, 18 Apr 2019 16:42:05 -0400
Subject: The python black project.
In-Reply-To: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
Message-ID: <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>

I had my concerns when I saw Python Black promoted in other quite some time
ago, and the same concern strikes me now I revisited it.

I strongly oppose Python Black adoption for this reason:

https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length

88 char line lengths is a table stakes deal breaker for me (and I suspect
others), and since the black project relies on no exceptions or discussions
about details, this makes it a non-starter.

-1 for me.

David.

On Thu, Apr 18, 2019 at 4:52 AM Natal Ngétal <natal at redhat.com> wrote:

> Hi everyone,
>
> Black is project to format Python code. It's more and more used by the
> python
> community. That can save time and harmonize the code. For example, simple
> quote
> versus double quote, that was not checked by pep8.i It's just an example of
> what make  black With a pre-hook commit hook this will be also avoid to
> lose
> time with pep8 errors.
>
> Two links to see more:
>
> https://github.com/ambv/black
> https://www.mattlayman.com/blog/2018/python-code-black/
>
> I think it can be very interesting to start to use Black on OpenStack. What
> do you thinks about that? For example, we can introduce it on some
> projects, I
> would volunteer to try on TripleO.
>
> My best regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/472a0015/attachment-0001.html>

From smooney at redhat.com  Thu Apr 18 21:11:59 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 18 Apr 2019 22:11:59 +0100
Subject: The python black project.
In-Reply-To: <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>
Message-ID: <c9d659df6aa2ffcc55a3291140bec1202db93767.camel@redhat.com>

On Thu, 2019-04-18 at 16:42 -0400, David Peacock wrote:
> I had my concerns when I saw Python Black promoted in other quite some time
> ago, and the same concern strikes me now I revisited it.
> 
> I strongly oppose Python Black adoption for this reason:
> 
> https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length
> 
> 88 char line lengths is a table stakes deal breaker for me (and I suspect
> others), and since the black project relies on no exceptions or discussions
> about details, this makes it a non-starter.
> 
> -1 for me.
so i have mentioned this in the thread before but you can change there default

if you drop a pyproject.toml file into the root of the repo black will read its defaults
from there
so we can set something like the following

[tool.black]
line-length = 79
target_version = ['py27']
skip-string-normalization = true
include = '\.pyi?$'
exclude = '''
(
  /(
      \.eggs         # exclude a few common directories in the
    | \.git          # root of the project
    | \.tox
    | \.venv
    | \docs
    | \releasenotes
  )/
)
'''

that will disable the "" to '' normalisation and it will keep the line-length at 79
yapf is more configurable but black allows you to set the 2 things that most people
take issue with. the line lenght and stings.
> 
David.

On Thu, Apr 18, 2019 at 4:52 AM Natal Ngétal <natal at redhat.com> wrote:

Hi everyone,

Black is project to format Python code. It's more and more used by the
python
community. That can save time and harmonize the code. For example, simple
quote
versus double quote, that was not checked by pep8.i It's just an example of
what make  black With a pre-hook commit hook this will be also avoid to
lose
time with pep8 errors.

Two links to see more:

https://github.com/ambv/black
https://www.mattlayman.com/blog/2018/python-code-black/

I think it can be very interesting to start to use Black on OpenStack. What
do you thinks about that? For example, we can introduce it on some
projects, I
would volunteer to try on TripleO.

My best regards





From openstack at fried.cc  Thu Apr 18 21:33:15 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 18 Apr 2019 16:33:15 -0500
Subject: [openstack-dev] [nova][xenapi][ptg] can we deprecate the
 xenapi-specific 'nova-console' service?
In-Reply-To: <0233724203a34d82a08b567a79a1f4a5@AMSPEX02CL01.citrite.net>
Message-ID: <4b9db37c-e60b-3ebe-95cc-0de568800a6c@fried.cc>

Scrubbing the Nova PTG agenda (hence addition of [ptg] subject tag), and
this is on it:

================
Can we remove the nova-console service? (mriedem)
The nova-console service is xenapi-specific and was deprecated in stein:
https://review.openstack.org/#/c/610075/
There are, however, REST APIs for it:
https://developer.openstack.org/api-ref/compute/#server-consoles-servers-os-consoles-os-console-auth-tokens
So if we drop the nova-console service, the APIs would no longer work.
It seems our options are:
Delete the nova-console service and obsolete the REST APIs (410 response
on all microversions like what we're doingwith nova-cells and
nova-network APIs)
Deprecate the REST APIs on a new microversion but continue to support
older microversions - this means the nova-console service would live
forever.
Are people still using the nova-console service? Are there
alternatives/replacements for xen users? BobBall seemed to suggest there
was
http://lists.openstack.org/pipermail/openstack-dev/2018-October/135422.html
but it's not clear to me.
================

I'm looking for any excuse to remove things from the agenda, and this
seems like a good candidate, because we don't really stand to gain
anything by bringing it up at the PTG.

Does anyone a) object to removing the nova-console service; or b) think
we need to discuss it at the PTG?

Thanks,
efried
.



From sean.mcginnis at gmx.com  Thu Apr 18 21:55:50 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Thu, 18 Apr 2019 16:55:50 -0500
Subject: [docs] Documenting CLI references (openstack-auto-commands)
Message-ID: <20190418215550.GA29937@sm-workstation>

Hey everyone,

Hoping someone has discussed this and has a recommended course of action.

Back when we had the awesome support of the openstack-docs team, there was a
command called openstack-auto-commands that would load up client commands and
generate help output for all commands. With the resource constraints that hit
the team, there were less folks to support tools like this. Docs moved into
each team's repos and, for the most part, I think that has worked out well.

Some of the automatic syncing stopped happening with this move to in-repo docs.
One of them was CLI docs. But it would appear there are at least a few teams
that now have not updated these docs since that move happened several releases
ago:

http://codesearch.openstack.org/?q=This%20file%20is%20tool-generated&i=nope&files=&repos=

There are others that appear to have used the last automatically generated
version and have been (varying degrees of) successful at just manually updating
the doc as things change.

When the tool was removed (https://review.openstack.org/#/c/509402/) it was
stated that it wasn't needed because cliff has sphinx integration to do the
equivalent automatically. That's all well and good... if you are using cliff.
But I think many of our legacy clients are not.

So looking for recommendations on ways to best keep these docs up to date now.
Migrate to cliff? Other in-repo automation tools?

(and yeah, I know, "drop the CLI and move to openstackclient)

Thanks for any suggestions!

Sean


From miguel at mlavalle.com  Thu Apr 18 22:18:18 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Thu, 18 Apr 2019 17:18:18 -0500
Subject: [neutron] Cancelling drivers meeting
Message-ID: <CAEzGLDj_E=FWA_4MUNY+a+fcgUEGUtGhO=cj+_m8K+rDftrDPQ@mail.gmail.com>

Dear Neutrinos,

We don't have RFEs lined up for discussion for tomorrow's meeting. So we
are cancelling it this week

Best regards

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/bc2813da/attachment.html>

From mriedemos at gmail.com  Thu Apr 18 22:35:58 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 18 Apr 2019 17:35:58 -0500
Subject: [openstack-dev] [nova][xenapi][ptg] can we deprecate the
 xenapi-specific 'nova-console' service?
In-Reply-To: <4b9db37c-e60b-3ebe-95cc-0de568800a6c@fried.cc>
References: <4b9db37c-e60b-3ebe-95cc-0de568800a6c@fried.cc>
Message-ID: <58aaf740-0c76-22b8-f377-a920318cc602@gmail.com>

On 4/18/2019 4:33 PM, Eric Fried wrote:
> Scrubbing the Nova PTG agenda (hence addition of [ptg] subject tag), and
> this is on it:
> 
> ================
> Can we remove the nova-console service? (mriedem)
> The nova-console service is xenapi-specific and was deprecated in stein:
> https://review.openstack.org/#/c/610075/
> There are, however, REST APIs for it:
> https://developer.openstack.org/api-ref/compute/#server-consoles-servers-os-consoles-os-console-auth-tokens
> So if we drop the nova-console service, the APIs would no longer work.
> It seems our options are:
> Delete the nova-console service and obsolete the REST APIs (410 response
> on all microversions like what we're doingwith nova-cells and
> nova-network APIs)
> Deprecate the REST APIs on a new microversion but continue to support
> older microversions - this means the nova-console service would live
> forever.

Sorting out the course here is why I had it on the PTG agenda, but we 
can't really answer that until we have answers to the other questions below.

> Are people still using the nova-console service? Are there
> alternatives/replacements for xen users? BobBall seemed to suggest there
> was
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/135422.html
> but it's not clear to me.
> ================
> 
> I'm looking for any excuse to remove things from the agenda, and this
> seems like a good candidate, because we don't really stand to gain
> anything by bringing it up at the PTG.
> 
> Does anyone a) object to removing the nova-console service; or b) think
> we need to discuss it at the PTG?

(a) I'd like to remove it if no one is using it and there are 
alternatives but I need xen ops/users/devs to answer that definitively.

(b) No, I don't expect xen people to be at the PTG so ML is a better venue.

-- 

Thanks,

Matt


From openstack at fried.cc  Thu Apr 18 22:42:19 2019
From: openstack at fried.cc (Eric Fried)
Date: Thu, 18 Apr 2019 17:42:19 -0500
Subject: [nova][ptg] Stein retrospective
Message-ID: <413d3dd3-7622-8a52-a0c8-4a0ac74b7b81@fried.cc>

All-

I have seeded an etherpad for Nova Stein nostalgia [1]. Please populate it.

Following tradition, I'm putting this first on the schedule.

Unless this etherpad gets just huge, I'm going to time box the
discussion to 30 minutes. Make it count.

Thanks,
efried

[1] https://etherpad.openstack.org/p/nova-ptg-train-retrospective


From mordred at inaugust.com  Thu Apr 18 23:05:38 2019
From: mordred at inaugust.com (Monty Taylor)
Date: Thu, 18 Apr 2019 23:05:38 +0000
Subject: The python black project.
In-Reply-To: <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
Message-ID: <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>



On 4/18/19 7:04 PM, Clint Byrum wrote:
> Quoting Natal Ngétal (2019-04-18 01:51:47)
>> Hi everyone,
>>
>> Black is project to format Python code. It's more and more used by the python
>> community. That can save time and harmonize the code. For example, simple quote
>> versus double quote, that was not checked by pep8.i It's just an example of
>> what make  black With a pre-hook commit hook this will be also avoid to lose
>> time with pep8 errors.
>>
>> Two links to see more:
>>
>> https://github.com/ambv/black
>> https://www.mattlayman.com/blog/2018/python-code-black/
>>
>> I think it can be very interesting to start to use Black on OpenStack. What
>> do you thinks about that? For example, we can introduce it on some projects, I
>> would volunteer to try on TripleO.
> 
> I've read the arguments in the thread, and I really appreciate
> everyone's thoughtfulness here.
> 
> I just wanted to add that I have been using black for some internal
> projects, and it is an absolute joy to forget about code formatting.
> This is different than the pep8 checks. The git hook just does it, and
> our CI confirms that you do it, and there's no more "oops I forgot
> pep8".
> 
> I believe that the whitespace churn that folks are bringing up is being
> overblown. This is a single, automatically produced diff, that while it
> might hurt a little in git annotate and conflicts with in-flight patches
> now, there is value, and there are mitigations, that make it worth it in
> some cases.
> 
> The main value is that using an automatic formatter will ultimately lead
> to less wasted test runs, less wasted developer time, and better diffs
> with less conflicts later.
> 
> So while I appreciate the desire to not rock the boat, it might be that
> the boat would go faster after some dead weight is dropped overboard,
> and that new energy is applied to forward progress instead of "darn it,
> now I have to think about how to fit this into 80 chars and parenthesis
> and ..." >
> Basically, weigh the one time cost vs. the ongoing savings, rather than
> considering them separately.

I think it's useful to point fingers at concrete things if we're going 
to weigh costs vs savings.

Here is a patch:

https://review.openstack.org/653876

That runs openstacksdk through black and adds it to the pep8 tox env. I 
had to make two manual code changes, and add two pep8 exclusions.

I also did -l 79 - because it's important.

I'd get so many stackalytics points for the +55540, -39832 :)

Monty


From morgan.fainberg at gmail.com  Fri Apr 19 00:44:14 2019
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 18 Apr 2019 17:44:14 -0700
Subject: The python black project.
In-Reply-To: <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
Message-ID: <CAGnj6asa9ZATTM1+j9zidpBzOkEv9EyVqAw5Y-kZFYBTzc5rYg@mail.gmail.com>

On Thu, Apr 18, 2019 at 4:07 PM Monty Taylor <mordred at inaugust.com> wrote:

>
>
> On 4/18/19 7:04 PM, Clint Byrum wrote:
> > Quoting Natal Ngétal (2019-04-18 01:51:47)
> >> Hi everyone,
> >>
> >> Black is project to format Python code. It's more and more used by the
> python
> >> community. That can save time and harmonize the code. For example,
> simple quote
> >> versus double quote, that was not checked by pep8.i It's just an
> example of
> >> what make  black With a pre-hook commit hook this will be also avoid to
> lose
> >> time with pep8 errors.
> >>
> >> Two links to see more:
> >>
> >> https://github.com/ambv/black
> >> https://www.mattlayman.com/blog/2018/python-code-black/
> >>
> >> I think it can be very interesting to start to use Black on OpenStack.
> What
> >> do you thinks about that? For example, we can introduce it on some
> projects, I
> >> would volunteer to try on TripleO.
> >
> > I've read the arguments in the thread, and I really appreciate
> > everyone's thoughtfulness here.
> >
> > I just wanted to add that I have been using black for some internal
> > projects, and it is an absolute joy to forget about code formatting.
> > This is different than the pep8 checks. The git hook just does it, and
> > our CI confirms that you do it, and there's no more "oops I forgot
> > pep8".
> >
> > I believe that the whitespace churn that folks are bringing up is being
> > overblown. This is a single, automatically produced diff, that while it
> > might hurt a little in git annotate and conflicts with in-flight patches
> > now, there is value, and there are mitigations, that make it worth it in
> > some cases.
> >
> > The main value is that using an automatic formatter will ultimately lead
> > to less wasted test runs, less wasted developer time, and better diffs
> > with less conflicts later.
> >
> > So while I appreciate the desire to not rock the boat, it might be that
> > the boat would go faster after some dead weight is dropped overboard,
> > and that new energy is applied to forward progress instead of "darn it,
> > now I have to think about how to fit this into 80 chars and parenthesis
> > and ..." >
> > Basically, weigh the one time cost vs. the ongoing savings, rather than
> > considering them separately.
>
> I think it's useful to point fingers at concrete things if we're going
> to weigh costs vs savings.
>
> Here is a patch:
>
> https://review.openstack.org/653876
>
> That runs openstacksdk through black and adds it to the pep8 tox env. I
> had to make two manual code changes, and add two pep8 exclusions.
>
> I also did -l 79 - because it's important.
>
> I'd get so many stackalytics points for the +55540, -39832 :)
>
> Monty


>

I think that the generated code is generally about as easy to read as the
rest of the SDK project. That being said, it looks like black takes some of
the guess work out of the picture. I'd support using it. Personally, I am a
fan of the ~88 line length, but as long as black comes close to a
consistent 79 (note  -l 79, according to the docs, does not guarantee no
lines longer than 79, but that it will make an attempt as long as no other
rules are violated) to make sure the folks who are more opinionated (hard
-1/-2 for a line-length change) are happy with using black, it should be
fine.

The change will be high-ish impact for backports (or require stable
branches to receive the same treatment) and could impact in-flight patches.
These are all things we've dealt with over and over in OpenStack.

Less guessing about code style and consistency is good in my opinion. It
tends to lead towards an easier to maintain code base. I also *really*
appreciate the simplicity of it being either a hook or baked into the pep8
check when run locally. I would advise that if black were to be run in the
gate as part of the pep8 check, it should raise an error if the code
changed between pre-black and post-black (change should always be done
local to the developer, before hitting gerrit unless we can have hooks in
gerrit to ensure consistency).

I vote monty get all the stackalytics points for all of the repos 1st run
of black commit (or maybe the openstack proposal bot if assigning it all to
Monty doesn't work.)

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/82af064d/attachment.html>

From mizuno.shintaro at lab.ntt.co.jp  Fri Apr 19 00:49:52 2019
From: mizuno.shintaro at lab.ntt.co.jp (Shintaro Mizuno)
Date: Fri, 19 Apr 2019 09:49:52 +0900
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3, 2019-9-4
 NYC
In-Reply-To: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
Message-ID: <3eeacfd2-2593-e036-b2a8-b95b2a6d4f21@lab.ntt.co.jp>

Thank you Chris and thank you Bloomberg for a great offer!

Shintaro

On 2019/04/17 5:45, Chris Morgan wrote:
> Hello All,
>   My employer Bloomberg LP would like to offer to host the next
> OpenStack Ops meetup here in NYC in early September this year. Please see
>
> https://etherpad.openstack.org/p/ops-meetup-2nd-2019
>
> for some early details on this.
>
> All hosting offers are subject to scrutiny by the ops meetups team and
> the overal community for content, location, timing etc and then approved
> via a mix of consensus gathering and (if there are multiple offers)
> voting, see https://wiki.openstack.org/wiki/Ops_Meetups_Team
> and https://wiki.openstack.org/wiki/Operations/Meetups
>
> Thanks,
>
> Chris
> --
> Chris Morgan <mihalis68 at gmail.com <mailto:mihalis68 at gmail.com>>


-- 
Shintaro MIZUNO (水野伸太郎)
NTT Software Innovation Center
TEL: 0422-59-4977
E-mail: mizuno.shintaro at lab.ntt.co.jp (Expires on 2019.6）
New E-mail：shintaro.mizuno.gt at hco.ntt.co.jp
※メールアドレスが変わります



From mrhillsman at gmail.com  Fri Apr 19 00:54:42 2019
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Thu, 18 Apr 2019 19:54:42 -0500
Subject: [ops] offer to host next OpenStack Ops meetup 2019-9-3,
 2019-9-4 NYC
In-Reply-To: <3eeacfd2-2593-e036-b2a8-b95b2a6d4f21@lab.ntt.co.jp>
References: <CA+NmNoNo=eKsviRcsvW+E7=-6zbsa5X+5kf0oR_qB2E02JCnqA@mail.gmail.com>
 <3eeacfd2-2593-e036-b2a8-b95b2a6d4f21@lab.ntt.co.jp>
Message-ID: <CAMVtB2HA-tJgNue1R4k09wAvtbLY-=er-6RtKEa95eL=yedL-w@mail.gmail.com>

+1

New York was first I attended and the facilities were great. Also the food
and fun just as awesome.

On Thu, Apr 18, 2019, 7:51 PM Shintaro Mizuno <mizuno.shintaro at lab.ntt.co.jp>
wrote:

> Thank you Chris and thank you Bloomberg for a great offer!
>
> Shintaro
>
> On 2019/04/17 5:45, Chris Morgan wrote:
> > Hello All,
> >   My employer Bloomberg LP would like to offer to host the next
> > OpenStack Ops meetup here in NYC in early September this year. Please see
> >
> > https://etherpad.openstack.org/p/ops-meetup-2nd-2019
> >
> > for some early details on this.
> >
> > All hosting offers are subject to scrutiny by the ops meetups team and
> > the overal community for content, location, timing etc and then approved
> > via a mix of consensus gathering and (if there are multiple offers)
> > voting, see https://wiki.openstack.org/wiki/Ops_Meetups_Team
> > and https://wiki.openstack.org/wiki/Operations/Meetups
> >
> > Thanks,
> >
> > Chris
> > --
> > Chris Morgan <mihalis68 at gmail.com <mailto:mihalis68 at gmail.com>>
>
>
> --
> Shintaro MIZUNO (水野伸太郎)
> NTT Software Innovation Center
> TEL: 0422-59-4977
> E-mail: mizuno.shintaro at lab.ntt.co.jp (Expires on 2019.6）
> New E-mail：shintaro.mizuno.gt at hco.ntt.co.jp
> ※メールアドレスが変わります
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/ce4afb29/attachment.html>

From emilien at redhat.com  Fri Apr 19 01:47:54 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Thu, 18 Apr 2019 21:47:54 -0400
Subject: [tripleo] Scale up/down Ansible tasks
In-Reply-To: <CAOjEBNqa6-hPD4_atej7Onc==o8va=UQUL=WXTT_96bX5_mV9Q@mail.gmail.com>
References: <CACu=hysZycm57nB_Fm8k8vqjaqxeG8WM3ogn-2E5hf07acPt4A@mail.gmail.com>
 <CAOjEBNq8k3pvbR6EnuDyXPBNys=Vcfvm5SZgCq-_DTRf9ETtEA@mail.gmail.com>
 <CACu=hytKrzZMeSsw540t6GsWbdq3OrOnEECJB6AMgcvHxERQqg@mail.gmail.com>
 <CAOjEBNqa6-hPD4_atej7Onc==o8va=UQUL=WXTT_96bX5_mV9Q@mail.gmail.com>
Message-ID: <CACu=hyumsMBmCKRvcN4bQiLZq9E9Q4p3_zN16+mx16758w+QVg@mail.gmail.com>

On Thu, Apr 11, 2019 at 8:28 AM Martin Schuppert <mschuppert at redhat.com>
wrote:

>
>
> On Thu, Apr 11, 2019 at 2:20 PM Emilien Macchi <emilien at redhat.com> wrote:
>
>> On Thu, Apr 11, 2019 at 3:23 AM Martin Schuppert <mschuppert at redhat.com>
>> wrote:
>>
>>> For nova/neutron it would be to disable the service/agent:
>>>
>>> (overcloud) $ openstack compute service list
>>> (overcloud) $ openstack compute service set [hostname] nova-compute
>>> --disable
>>>
>>> (overcloud) $ openstack network agent list
>>> (overcloud) $ openstack network agent set --disable
>>> [openvswitch-agent-id]
>>>
>>> After service is stopped/or host delete
>>> (overcloud) $ openstack compute service delete [service-id]
>>> (overcloud) $ openstack network agent delete [openvswitch-agent-id]
>>>
>>
>> Ok so these commands would need to be executed from the Undercloud in the
>> mistral_container, since they do nothing on local nodes but just do CLI
>> against APIs.
>> I take note and will make sure it's possible.
>>
>> Do you folks already have some playbooks doing these things or should we
>> start from scratch?
>>
>
> No, right now those are manual tasks, but Rajesh could help on this.
>

I'm prototyping it on https://review.openstack.org/#/c/653893/ - I'll
iterate on that patch and once it works I'll tackle Neutron. Feedback is
welcome!
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/a5da4d49/attachment-0001.html>

From dangtrinhnt at gmail.com  Fri Apr 19 01:59:48 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Fri, 19 Apr 2019 10:59:48 +0900
Subject: [searchlight] Searchlight planning for Train
Message-ID: <CADJ6S4F_2yX7jcb5ObE2M3kC4OuJHYf33Lm3eY0j5oYt2FW-mg@mail.gmail.com>

Hi team,

We just released Searchlight for Stein last week successfully.
Congratulations to all of you who have contributed to the project. We did
it!!!!

So now the Train cycle started [1]. I would like to plan for the things
that we would want to accomplish in this new cycle. Please have a look at
the etherpad [2] and put your ideas or comment on existing ones.

[1] https://releases.openstack.org/train/schedule.html
[2] https://etherpad.openstack.org/p/searchlight-train

Yours,



-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/0169e32b/attachment.html>

From mizuno.shintaro at lab.ntt.co.jp  Fri Apr 19 02:34:56 2019
From: mizuno.shintaro at lab.ntt.co.jp (Shintaro Mizuno)
Date: Fri, 19 Apr 2019 11:34:56 +0900
Subject: [Forum][Ops] Ops War Stories Lightning Talk session
Message-ID: <7cd875d6-8db2-40be-06c4-433101827c1d@lab.ntt.co.jp>

Hi

There is a Forum session for the operators [1] at the Denver Summit,  
which I want to shed some light on before the Summit.

This session is a Lightning Talk session for the operators to share  
their war stories and architectures.
It will be a short 5 min slot and slides are not required (you can have  
them if you want).

If you have stories to share, please put your name and a title of your  
talk to the etherpad below.

[1] https://etherpad.openstack.org/p/DEN-ops-war-stories-LT

Hope to see you in Denver!

Best regards,
Shintaro
-- 
Shintaro MIZUNO
NTT Software Innovation Center
TEL: 0422-59-4977
E-mail: mizuno.shintaro at lab.ntt.co.jp (Expires on 2019.6）
New E-mail：shintaro.mizuno.gt at hco.ntt.co.jp




From hongbin034 at gmail.com  Fri Apr 19 03:54:14 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Thu, 18 Apr 2019 23:54:14 -0400
Subject: [qa][zun][kuryr][k8s]
Message-ID: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>

Hi all,

Right now, we have a devstack plugin [1] to install container engine (i.e.
docker, cri-o). The plugin is currently used by Zun and Kuryr and under the
governance of QA team.

I am working on a patch [2] to enable k8s installation via devstack. Zun
needs this feature to setup the CI for the virtual kubelet provider, and I
heard Kuryr also interest to leverage it.

The original idea is to incorporate k8s installation into
devstack-plugin-container, so that we can avoid the overhead to bootstrap
and maintain a separated plugin. However, the feedback I received so far
gave preference to a separated plugin for k8s, so I sent out this email to
collect more opinions.

Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the
existing container plugin for this purpose?

[1] https://github.com/openstack/devstack-plugin-container
[2] https://review.openstack.org/#/c/646018/

Best regards,
Hongbin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/dc6eff00/attachment.html>

From snikitin at mirantis.com  Thu Apr 18 17:27:27 2019
From: snikitin at mirantis.com (Sergey Nikitin)
Date: Thu, 18 Apr 2019 21:27:27 +0400
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <C84F43F3-0E68-49A2-961D-3B22C8E23E8D@mirantis.com>
References: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
 <CAOHrpwGRjb_3fMONsuS-vFs98SARLcMp=G28LPKzmzB4fjV-tA@mail.gmail.com>
 <CAEvYov3wpSeR90eZxxhM7PqXcHXuLQqTOCu3_Hhxm+i2-w8GrA@mail.gmail.com>
 <C84F43F3-0E68-49A2-961D-3B22C8E23E8D@mirantis.com>
Message-ID: <CABURL_ndQ318-nOvgtLcqnjdckOtAK1c2zNHWN9NRoFvuoL4mg@mail.gmail.com>

Hello everyone,

Yesterday we've finished stackalytics migration.
Thank you for patience and for notifications about the problem. Now all
stats must be accurate.

We are working hard to keep stackalytics.com a trusted storage of OpenStack
statistics.
So if you will find some problems with data again, please tell as and we
will fix it ASAP.

Sergey

On Wed, Apr 17, 2019 at 7:37 AM Edward Ionel <eionel at mirantis.com> wrote:

> Hello All,
>
>
> I first want to thank each and everyone of you for reaching out
> and sharing the inaccuracies you all have found within Stackalytics, this
> has helped us tremendously with the efforts to correct these flaws.
>
>
> I am writing this email to directly address each individual that has
> reached out and shared their concerns with our Stackalytics data.
>
>
> Mark Goddard
>
> Michael Johnson
>
> Julia Kreger
>
> Collen Murphy
>
> Clark Boylan
>
> Sean Mooney
>
> Thierry Carrez
>
> Jermey Stanley
>
> Arkady Kanvesky
>
> (Hopefully, I did not miss anyone)
>
>
> I want to insure everyone that the team is working hard
> to fix the inaccuracies in some of our data. We are still very much
> involved in OpenStack and we do read each and
> every message regarding Stackalytics.
>
>
> As Boris and Sergey mentioned, we found that this occurred due to an
> outdated production environment. We are currently in
> the progress of migrating to a new environment, and the data should
> be corrected.
>
>
> The team and I are sorry for these discrepancies and appreciate you all
> for bringing this to our attention.
>
> Thank you all, for providing links and examples of the inaccuracies. This
> has helped our efforts greatly in correcting the current issues. It would
> be great if
> the community can continue reviewing Stackalytics data and help us provide a better service
> to all.
>
>
>
> Once again, we are all very sorry for this and will continue to fix these
> issues.
>
>
> Cheers,
>
> Edward
>
> On Apr 16, 2019, at 4:05 PM, Edward Ionel <eionel at mirantis.com> wrote:
>
>
>
> On Tue, Apr 16, 2019 at 2:56 PM Boris Renski <brenski at mirantis.com> wrote:
>
>> Folks - more specifically, we plan to roll out an update by tomorrow
>> mid-day PT which should fix all the numbers + add aggregate details on
>> Airship project contributions.
>>
>> Would really appreciate the help of the community to poke around tomorrow
>> afternoon and see if there are still discrepancies.
>>
>> Sorry about this and thank you for catching it and brining it to our
>> attention.
>>
>> -Boris
>>
>> On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin at mirantis.com>
>> wrote:
>>
>>> Hello everyone,
>>> As you mentioned there are some inaccuracies in stats on
>>> stackalytics.com. It happened because of outdated Prod env. At this
>>> moment we are in a process of migration to the new env. All data on this
>>> env is fresh and accurate. So the problem will be solved soon.
>>>
>>> --
>>> Best Regards,
>>> Sergey Nikitin
>>>
>>
>
> --
>
> Edward Ionel
>
> Marketing Operations Manager
>
> Mirantis, Inc.
>
> 900 E Hamilton Ave, Suite 650
>
> Campbell, CA 95008
>
> Eionel at mirantis.com
>
> www.mirantis.com
>
>

-- 
Best Regards,
Sergey Nikitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/a0724e9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mirantis-logo-2color-rgb-transparent.png
Type: image/png
Size: 31598 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/a0724e9a/attachment-0001.png>

From mihalis68 at gmail.com  Thu Apr 18 19:19:38 2019
From: mihalis68 at gmail.com (Chris Morgan)
Date: Thu, 18 Apr 2019 15:19:38 -0400
Subject: [OpenStack-sigs][publiccloud-wg][Action Required] help most
 needed for SIGs and WGs
In-Reply-To: <CA+WCyyoeiYhmL9rtvbn43nakO-dsQyTZa=PUw8YJh2RjNB+0zg@mail.gmail.com>
References: <CA+WCyyoeiYhmL9rtvbn43nakO-dsQyTZa=PUw8YJh2RjNB+0zg@mail.gmail.com>
Message-ID: <CA+NmNoM0TXHmkX0jo3Krc2RozfnQGxqCrLd3wgz8peQMJS7E=A@mail.gmail.com>

   - What's your team's name

https://wiki.openstack.org/wiki/Operation_Docs_SIG

   - Who's leading or active in this team

Sean McGinnis, Chris Morgan, Erik McCormick

   - What's this team recently plan or doing

This SIG is just getting going. The first task was to adopt some orphaned
docs so they have a home for code changes and a way to publish. That has
been done (Sean M).

Next we want to significantly improve those documents (operators guide, HA
guide, arch guide). HA guide is under heavy rewrite by Adam Speirs. The
others we have only got as far as minor tweaks so far. We have been
discussing breaking the install instructions part of the operators guide
into a separate document since that's an extremely broad and somewhat
controversal topic all by itself.

Another urgent thing is to improve the getting started info, as the
instructions on how to have  development environment "merely" for the
openstack doc tools is a bit summarised and assumes some technical
expertise. We want to make it obvious how to build and modify these
documents if you have never touched any of the key tools before.

   - How people can join this team?

We've handled this within the Ops Meetups team meetings and in person at
meetups and summits so far since it's mostly the same people. We have
discussed having a separate regular meeting but have not set one up so far.
So, for now, join the IRC meeting or reach out via the openstack-discuss
mailing list.

   - What's your most needed help interns of actions or technical features?

Contributions to the above mentioned documents. We did get expressions of
interest in this work at the Berlin ops meetup.


   - Which team (or who) you think that have a part in above help request
   (high potentially is fine)?

The core docs team and the translations team have been helping and that is
appreciated,

   - Anything else you wish to share to attendees?

Nothing at this time.

On Tue, Mar 26, 2019 at 12:44 AM Rico Lin <rico.lin.guanyu at gmail.com> wrote:

> Dear all SIG and WG members
>
> I would like to ask for three favors from each group. Thank you for your
> kindly help.
>
> tl;dr:
>     1. As an action from [3], we will have a forum `Help most needed for
> SIGs and WGs` [4]. And would like to ask each group kindly provide me the
> following help most needed information, including
>
>    - What's your team's name
>    - Who's leading or active in this team
>    - What's this team recently plan or doing
>    - How people can join this team?
>    - What's your most needed help interns of actions or technical
>    features?
>    - Which team (or who) you think that have a part in above help request
>    (high potentially is fine)?
>    - Anything else you wish to share to attendees?
>
>     2. update help most needed section in [1]. So anyone can understand
> what help your group needs. Also, TCs and UCs will have a better view of
> how group effort been working in the community and how community priority
> should be if regarding SIGs and WGs.
>     3. Also, consider your needs as a community goal? Add it in [2] now.
>
> -------------------------------------------longer
> version---------------------------------------------------
> ( don't worry, not like I can do a super long readable article, but under
> the power of line-counting this is longer and still readable for sure!)
>
>     1. Back in the last summit, we have a forum [3] to talk about how can
> we help to expose SIGs and WGs.
> As an action, We will host a forum in coming Denver summit, to talk about
> `Help most needed for SIGs and WGs` [4].
> This forum will present the most needed help from SIGs and WGs. By plan to
> also invite everyone (will try to invite people from each team and group)
> in the community to join this forum.
> We might get attention from people and potentially helpers:). Therefore, I
> do wish to have participants from every group.
> Please kindly provide me the following help most needed information,
> including
>
>    - What's your team's name
>    - Who's leading or active in this team
>    - What's this team recently plan or doing
>    - How people can join this team?
>    - What's your most needed help interns of actions or technical
>    features?
>    - Which team (or who) you think that have a part in above help request
>    (high potentially is fine)?
>    - Anything else you wish to share to attendees?
>
> I will try to reach out to each team too, but if you already have answers
> to the above questions, that will be super! Since we might get around 16
> groups, will try to get to the ` most needed help` part for everyone. But
> hopefully, we can still give some time if any attendee is really interested
> in helping. We gonna get more focus on what's the needs and how we can help
> to make progress of it, so it won't be like another BoF or Project update
> for you. Also, it's a forum so I won't give my hope to have a video
> recorder, which makes the second part more essential.
>
>     2. Update help most needed section in [1]. So anyone can understand
> what help you need. Also, TCs and UCs will have a better view of how group
> effort been working in the community and how community priority should be.
> Possibly and hopefully organizations/users/people might find matching their
> inner plan and sending people to help. Now if your group are willing to
> help with the forum, this action should be easy. And as I mention we're
> going to have a forum [4], It will be benefit to have such a document ready
> for anyone who's not coming to summit.
>
>     3. Is this needed suitable as a community goal [2]? Since we're also
> discussing community goal in #openstack-tc and ML, I think this might be a
> good chance to raise your needs into suggestion as our goal [2] if you find
> it fit with community goal definition.
>
>
> As one of the Meta SIG chairs, I will try hard to make all SIG's life
> easier. So let me know if above action doesn't fit with your group or if
> you find it hard with making progress with your SIG mission.
>
> [1]
> https://github.com/openstack/governance/blob/master/reference/help-most-needed.rst
> [2] https://etherpad.openstack.org/p/community-goals
> [3] https://etherpad.openstack.org/p/expose-sigs-and-wgs
> [4]
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23612/help-most-needed-for-sigs-and-wgs
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/750a4cf2/attachment.html>

From iain.macdonnell at oracle.com  Fri Apr 19 06:27:37 2019
From: iain.macdonnell at oracle.com (iain.macdonnell at oracle.com)
Date: Thu, 18 Apr 2019 23:27:37 -0700
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
Message-ID: <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>


Hi Damien,

Thanks for the response! This definitely sounds similar enough that it 
has to be the same root problem.

I didn't make too much progress today. Whilst using strace to try to 
compare Rocky and Stein, I noticed that TCP connections seem to be 
handled somewhat differently. This applies to mysql as well as AMQP. In 
the Rocky case, I see repeated fcntl() calls to F_SETFL O_RDWR between 
sendto() and recvfrom():


[pid 32427] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 19
[pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 32427] fcntl(19, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 32427] connect(19, {sa_family=AF_INET, sin_port=htons(3306), 
sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in 
progress)
[pid 32427] poll([{fd=19, events=POLLOUT}], 1, 10000) = 1 ([{fd=19, 
revents=POLLOUT}])
[pid 32427] getsockopt(19, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
[pid 32427] setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 32427] fcntl(19, F_GETFL)          = 0x802 (flags O_RDWR|O_NONBLOCK)
[pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
[pid 32427] setsockopt(19, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
[pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
[pid 32427] recvfrom(19, 
"J\0\0\0\n5.7.25\0\f\r\0\0#\4;;\n)\0309\0\377\377\10\2\0\377\301"..., 
8192, 0, NULL, NULL) = 78
[pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
[pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
[pid 32427] sendto(19, 
"\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
150, 0, NULL, 0) = 150
[pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
[pid 32427] recvfrom(19, ",\0\0\2\376mysql_native_password\0#\4;;\n"..., 
8192, 0, NULL, NULL) = 48


whereas in the Stein case, I see recvfrom() calls that get EAGAIN, 
followed by epoll before a successful recvfrom():

[pid 17895] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 28
[pid 17895] fcntl(28, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 17895] fcntl(28, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306), 
sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in 
progress)
[pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28, 
{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}}) = 0
[pid 17895] epoll_wait(26, [{EPOLLOUT, {u32=28, 
u64=6398156018563416092}}], 1023, 1992) = 1
[pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f7440) = 0
[pid 17895] getsockopt(28, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
[pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306), 
sin_addr=inet_addr("10.241.154.33")}, 16) = 0
[pid 17895] setsockopt(28, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 17895] setsockopt(28, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
[pid 17895] recvfrom(28, 
"J\0\0\0\n5.7.25\0(!\0\0\10w@\v-~)D\0\377\377\10\2\0\377\301"..., 8192, 
0, NULL, NULL) = 78
[pid 17895] sendto(28, 
"\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
150, 0, NULL, 0) = 150
[pid 17895] recvfrom(28, 0x7fb5d401e340, 8192, 0, NULL, NULL) = -1 
EAGAIN (Resource temporarily unavailable)
[pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28, 
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}}) = 0
[pid 17895] epoll_wait(26, [{EPOLLIN, {u32=28, 
u64=6398156018563416092}}], 1023, 1991) = 1
[pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f6530) = 0
[pid 17895] recvfrom(28, 
",\0\0\2\376mysql_native_password\0\10w@\v-"..., 8192, 0, NULL, NULL) = 48


Not sure if this is related to the problem or not, but it's what jumped 
out first, and I wasn't able to figure out what's causing the change in 
behaviour before I ran out of enthusiasm today.

Please let me know if you discover anything further or/and if there are 
any discussions (IRC?) that I should be participating in .. although I'm 
guessing that that's happening during the EU work day.

Thanks!

     ~iain





On 4/18/19 12:48 AM, Damien Ciabrini wrote:
> 
> 
> On Thu, Apr 18, 2019 at 7:51 AM <iain.macdonnell at oracle.com 
> <mailto:iain.macdonnell at oracle.com>> wrote:
> 
> 
>     Is anyone running Stein nova-api under uWSGI? I'm trying to do this, in
>     exactly the same way as I did with Rocky, but encountering a new
>     problem...
> 
> 
> This sounds similar to a problem that we're currently debugging with John
> Eckersberg and Michele Baldessari (in CC) in Stein, but when nova-api runs
> under Apache mod_wsgi.
> 
> The symptoms for us seem similar: sometimes the scheduling of the AMQP
> heartbeat greenlet seems heratic (no run for 75 seconds), RabbitMQ
> drops the connection to the client during this idle period, and next time
> nova-api needs to communicate over AMQP it logs a "connection reset
> by peer" and reestablish a new connection.
> 
> This is fresh news from yesterday so this is still to be 
> confirmed/disproved;
> but currently we're investigating how eventlet schedules recurring tasks
> such as the AMQP heartbeat greenlet under Apache mod_wsgi's execution
> model.
> 
> Once the AMQP heartbeat greenlet has sent its heartbeat, it sleeps for a
> fixed amount of time; i.e. it suspends its execution, eventlet registers 
> a timer
> for this greenlet, and continues scheduling other greenlets. Once the timer
> expires, eventlet marks the heartbeat greenlet as "eligible for scheduling"
> and eventually this greenlet resumes its execution.
> For that mechanism to work, eventlet regularly watches for all the timers
> that are registered in its event loop (with select/epoll/whatnot).
> 
> Now, Apache mod_wsgi embeds its own Python interpreter, and calls it
> whenever there's an API call to process. It seems that - the precise course
> of event is unclear to me yet - once the API call is processed, the Python
> Interpreter returns a result to mod_wsgi and stops its execution even if
> some timers were still registered in eventlet.
> 
> The state of the Python Interpreter is conserved though, and next time
> mod_wsgi receives an API call, it resumes the execution of the Python
> Interpreter: eventlet resumes its execution and process every timer
> that were registered previously. So ultimately, the AMQP heartbeat
> greenlet is rescheduled, but that might be a long time already since the
> last AMQP heartbeat.
> 
> So I have the feeling that when there's no traffic, mod_wsgi doesn't execute
> the Python interpreter, which prevents eventlet from running, watching for
> timers, and triggering the AMQP heartbeat greenlet. So far, the evidences
> in favour of this theory are:
>    . When there's no traffic for nova-api running under mod_wsgi, and I use
>      gdb to dump the call stack of the mod_wsgi process, I see no CPython
>      interpreter in the stack. Whereas when there's traffic, I see many 
> CPython
>      stack frames.
>    . When there's no traffic to nova-api and the AMQP heartbeat greenlet 
> seem
>      to be unscheduled for a long time, running a simple 'nova list' command
>      seems to unblock everything and trigger a AMQP heartbeat.
> 
> This would also explain why running the nova-api service in standalone works
> just fine as you said. because the Python interpreter is never stopped 
> in this
> execution model.
> 
> I'm still trying to figure out when the Python interpreter returns to 
> mod_wsgi
> to make sure what I'm saying makes sense. And I also need to double check
> that running in standalone works fine for me as well.
> 
>     The symptom is intermittent failure of API operations that involve RPC
>     calls - notably getting the noVNC console URL for an instance. The
>     nova-api log shows RPC timeouts and "connection reset by peer" for
>     AMQP.
>     I've ruled out environmental issues, as a Rocky installation on the
>     same
>     hosts works fine. With oslo debug enabled, I see that the first API
>     call
>     causes a AMQP connections to be established, and the RPC call gets its
>     reply, and all is well... but there are no heartbeats logged after
>     that.
>     3 minutes later, rabbitmq-server reports that it has received no
>     heartbeats, and drops the connection. On a subsequent API call (but not
>     before), nova-api logging "connection reset by peer" and the RPC call
>     times out. With the Rocky code, once the first API call causes the AMQP
>     connections to be established, regular heartbeats start happening, the
>     connections are maintained, and subsequent API calls work as expected.
> 
>     It seems like a lockup in a thread that's supposed to maintain the AMQP
>     connection, or something. I tried to use SIGUSR2 to trigger guru
>     meditation, but it seems that uWSGI has its own interpretation of
>     SIGUSR2, so nova-api never sees it (anyone know a way around this?).
> 
>     Running nova-api as a standalone service, instead of under uWSGI, the
>     problem does not occur (I see the heartbeats, and everything works
>     fine).
> 
>     I've tried updating oslo-messaging (and python-amqp) on a Rocky
>     installation to the Stein version, but the problem does not reproduce.
> 
>     Ideas?
> 
>           ~iain
> 
> 
> 
> 
> 
> -- 
> Damien


From tony at bakeyournoodle.com  Fri Apr 19 09:22:55 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Fri, 19 Apr 2019 19:22:55 +1000
Subject: [release] Release countdown for week R-26 and R-25, April 15-26
Message-ID: <20190419092254.GA26225@thor.bakeyournoodle.com>

Here we go again! The Train cycle will about normal at 26 weeks.  Please take a
couple of minutes to look over the schedule for this release:

    https://releases.openstack.org/train/schedule.html

We also have the same data available as an ics:

    https://releases.openstack.org/train/schedule.ics

it's a good idea for interested parties (for example PTLs and liaisons)
to subscribe to it so upcoming deadlines are visible.

Development Focus
-----------------

Focus should be on optimizing the time at the PTG and following up after the
event to jump start Train development and spec planning

Action Required
---------------

PTLs will receive a direct email from me establishing contact and setting
communication expectations.  Be on the lookout!

General Information
-------------------

All teams should review their release liaison information and make sure it is
up to date [1].

While reviewing liaisons, this would also be a good time to make sure your
declared release model matches the project's plans for Train (e.g. [2]). This
should be done prior to the first milestone and can be done by proposing a
change to the Stein deliverable file for the project(s) affected [3].


Now would be a good time to start brainstorming Forum topics while some of the
PTG discussions are fresh. Just a couple months until the Summit and Forum in
Berlin.

Upcoming Deadlines & Dates
--------------------------

Train-1 milestone: Jun 03  (R-19 week)
Forum at OpenInfrastructure Summit in Denver: April 29 - May 1
PTG right after the OpenInfrastructure Summit in Denver: May 2 - 4


Yours Tony  (tonyb).

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons
[2] https://opendev.org/openstack/releases/src/branch/master/deliverables/train/keystone.yaml#L3
[3] https://opendev.org/openstack/releases/src/branch/master/deliverables/train


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/d12b797b/attachment.sig>

From thierry at openstack.org  Fri Apr 19 09:25:20 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 19 Apr 2019 11:25:20 +0200
Subject: Call for help! 'U' Release name Mandarin speakers
In-Reply-To: <20190214021836.GD12795@thor.bakeyournoodle.com>
References: <20190214021836.GD12795@thor.bakeyournoodle.com>
Message-ID: <a6fe65e2-358a-a87b-9383-71cad58df6ce@openstack.org>

Tony Breeds wrote, back in February:
>      Now that we know when and where the 'U' summit will be[1] we can
> pick the name for the U release.  I'm happy to act as coordinator but
> given the location I'd really like a native speaker (or 2) to help with
> assessing the names against the criteria, defining the geographic
> region and translating the civs POLL when we get there.
> 
> Yours Tony.
> 
> [1] https://www.openstack.org/summit/shanghai-2019

Now that we are in the Train (that name just keeps on giving) there is 
more pressure to name 'U'...

Do we have people from China interested in helping with that process ?

As a reminder, the rules are described at:
https://governance.openstack.org/tc/reference/release-naming.html

-- 
Thierry Carrez (ttx)


From natal at redhat.com  Fri Apr 19 10:34:53 2019
From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=)
Date: Fri, 19 Apr 2019 12:34:53 +0200
Subject: The python black project.
In-Reply-To: <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>
Message-ID: <CAF+jc3UYVLbMA_UrdNFnYwhnifHJ92mDV1aFDZG-nZ=o=cynHg@mail.gmail.com>

On Thu, Apr 18, 2019 at 10:42 PM David Peacock <dpeacock at redhat.com> wrote:
>
> I had my concerns when I saw Python Black promoted in other quite some time ago, and the same concern strikes me now I revisited it.
>
> I strongly oppose Python Black adoption for this reason:
>
> https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length
>
> 88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter.
Sorry but for me is not a good argument. This default behaviour can be
change easily. I also prefer 79 character per line, pep8 change, but I
still to continue to prefer 79 character per line. However I can use
black for my project, because I can change this behaviour.


From mdulko at redhat.com  Fri Apr 19 10:59:03 2019
From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko)
Date: Fri, 19 Apr 2019 12:59:03 +0200
Subject: [qa][zun][kuryr][k8s]
In-Reply-To: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>
References: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>
Message-ID: <5fcb1c08b3349eaaa897cf4b775e01f06f7a2ef5.camel@redhat.com>

On Thu, 2019-04-18 at 23:54 -0400, Hongbin Lu wrote:
> Hi all,
> 
> Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team.
> 
> I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it.
> 
> The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions.
> 
> Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose?

I looked through the proposed code again and I think I'll soften my
stance here. If we'll keep the code in a separated file and do not mix
the settings of two too much (note that some dependency is necessary -
we do that in kuryr-kubernetes DevStack plugin in regards to e.g.
CONTAINER_ENGINE), then we should be easily able to extract it in the
future if needed. My only concern is that if any future OpenStack
project wanted to deploy K8s on its DevStack, devstack-plugin-container 
would certainly not be first place they would look at.

Anyway let's just start with something and see where it carries us.
It'll definitely need a lot of work to develop the plugin to the point
it could be used by kuryr-kubernetes, so it's just a start.



From Arkady.Kanevsky at dell.com  Fri Apr 19 13:15:16 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Fri, 19 Apr 2019 13:15:16 +0000
Subject: [stackalytics] Moving stackalytics configuration file to github
 repo
In-Reply-To: <CABURL_mWTC6rZfrfHJs_v0UYjMVez_9ag9+Yzt88A1QRsx4a4w@mail.gmail.com>
References: <CABURL_mWTC6rZfrfHJs_v0UYjMVez_9ag9+Yzt88A1QRsx4a4w@mail.gmail.com>
Message-ID: <bc6c9a5079374263b77f90f444a7566f@AUSX13MPS308.AMER.DELL.COM>

Sergey,
Thanks for detailed guidance.
Arkady

From: Sergey Nikitin <snikitin at mirantis.com>
Sent: Thursday, April 18, 2019 1:50 PM
To: openstack-discuss at lists.openstack.org
Cc: Edward Ionel; Boris Renski; Jim Phillips
Subject: [stackalytics] Moving stackalytics configuration file to github repo


[EXTERNAL EMAIL]
Hello everyone,

Every day Stackalytics team works on new features.
One of these features is a statistics collecting for non OpenStack projects. For example Kubernetes [1].
Stackalytics project has configuration file (default_data.json), which contains a lot of data, including user properties. Such as name, launchpad ID, github ID, email and companies.

It's a usual situation when a contributor change his/her email or find a better job in new company.
To do not loose stats which were pinned with old email or to point that he/she now work in new company contributor must add/modify his/her record in default_data.json config file.

This config file was in `etc` directory in stackalytics repo [2].
But we moved this file to new github repository [3].
It was made to do not force non OpenStack contributors use OpenStack Gerrit to update their stackalytics profiles.

From this moment if you want to update your stackalytics profile you must create a pull request to the new github repo [3]. The new data will be applied within 12 hours after pull request merge.

All current patches with user data changes from stackalytics gerrit [4] are still valid and will be applied and moved to [3] after approve. So do not worry about them.

More information about user data updating you can find in Stackalytics Wiki page [5].

If you have any questions we will be glad to answer.

Stackalytics team.

[1] https://www.stackalytics.com/cncf?project_type=kubernetes
[2] https://github.com/openstack/stackalytics/blob/master/etc/default_data.json
[3] https://github.com/stackalytics/default_data
[4] https://review.openstack.org/#/q/project:openstack/stackalytics+status:open
[5] https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation

--
Best Regards,
Sergey Nikitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/1e820b73/attachment-0001.html>

From akamyshnikova at mirantis.com  Fri Apr 19 13:15:34 2019
From: akamyshnikova at mirantis.com (Anna Taraday)
Date: Fri, 19 Apr 2019 17:15:34 +0400
Subject: [octavia][taskflow] Adaption of persistence/jobboard (taskflow expert
 review needed)
Message-ID: <CAOBv_t+S=YWT0PUqpGcz_Lwg2NAR-tqAUG+PQOqMevqDSaFFpA@mail.gmail.com>

Hello everyone!

I was looking at the topic of usage taskflow persistence and jobboard in
Octavia [1].
I created a simple PoC to check what should be done to enable this
functionality [2] .

>From what I see, taskflow expects that data, which will be stored in
persitence backend/jobboard backend, is a dict or an object easily
converted to dicts [3] (error [3.1])
Also functions that creates flow should be importable [4] (error [4.1]).

These two points lead to refactor required for Octavia to enable taskflow
persistence and jobboard:
1) Convert data which is passed between flows in dicts, at this moment it
is db objects with links to other db objects.
2) Create importable flow functions.

As far as I see the only OpenStack project which adapted taskflow
persistence is poppy [5]

I'm looking for taskflow expect to take a look at all this and give some
comments - whether I am correct or missing something.

Thank you for your time in advance!

[1] - https://storyboard.openstack.org/#!/story/2005072
[2] - https://review.openstack.org/#/c/647406
[3] -
https://github.com/openstack/taskflow/blob/master/taskflow/persistence/backends/impl_sqlalchemy.py#L458
[3.1] - http://paste.openstack.org/show/749530/
[4] -
https://docs.openstack.org/taskflow/latest/_modules/taskflow/engines/helpers.html#save_factory_details
[4.1] - http://paste.openstack.org/show/749527/
[5] - https://github.com/openstack/poppy


-- 
Regards,
Ann Taraday
Mirantis, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/8f34fa92/attachment.html>

From manuel.sb at garvan.org.au  Fri Apr 19 13:16:01 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Fri, 19 Apr 2019 13:16:01 +0000
Subject: shelve server taking too long
Message-ID: <9D8A2486E35F0941A60430473E29F15B017EA57DAB@mxdb2.ad.garvan.unsw.edu.au>

Dear Openstack community,

I am trying to shelve a server but the process seems to be stuck in shelving_image_pending_upload state.

is it normal for the shelve process to take several hours?

thank you
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/6c0bf9cb/attachment.html>

From mriedemos at gmail.com  Fri Apr 19 13:22:04 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 08:22:04 -0500
Subject: [nova] Nasty new gate regression as of 4/15 - bug 1825435
Message-ID: <5fdb2a1b-8212-4df7-fee0-209011cd1206@gmail.com>

I spotted this yesterday [1] and according to logstash it showed up 
around 4/15. It's only hitting on nova unit tests, and I think is 
somehow related to the TestRPC unit tests, or maybe those just stall out 
as a result when we hit the stack overflow.

I don't think it's due to any new oslo.config or oslo.messaging versions 
because there haven't been any, and it hits on both the 
lower-constraints and py36 jobs (so different versions of those packages).

I've looked through the nova changes that merged since around 4/14 but 
nothing is jumping out at me that might be causing this stack overflow 
in the oslo.config code, but the cells v1 removal patches are pretty big 
and I'm wondering if something snuck through there - the cells v1 unit 
tests were doing some RPC stuff as I recall so maybe that's related.

We need all eyes on this since it's a high failure rate and we're 
already experiencing really slow turnaround times in the gate.

[1] https://bugs.launchpad.net/nova/+bug/1825435

-- 

Thanks,

Matt


From mriedemos at gmail.com  Fri Apr 19 13:25:46 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 08:25:46 -0500
Subject: [nova] Re: shelve server taking too long
In-Reply-To: <9D8A2486E35F0941A60430473E29F15B017EA57DAB@mxdb2.ad.garvan.unsw.edu.au>
References: <9D8A2486E35F0941A60430473E29F15B017EA57DAB@mxdb2.ad.garvan.unsw.edu.au>
Message-ID: <b4578b93-8aa3-1170-9075-0f107e4f1318@gmail.com>

On 4/19/2019 8:16 AM, Manuel Sopena Ballesteros wrote:
> I am trying to shelve a server but the process seems to be stuck in 
> shelving_image_pending_upload state.
> 
> is it normal for the shelve process to take several hours?

Well, it's trying to snapshot the server's root disk and upload the 
snapshot image to glance. Have you debugged to determine if it's doing a 
live snapshot or a cold snapshot - the libvirt driver should log 
something about that. Do the compute logs say that it's uploading the 
image? Are there errors or anything else in the glance logs? I'm not 
sure if there is a hard timeout on the actual image upload itself, but 
the user token would eventually timeout and should trigger a failure 
(unless you've configured service user tokens [1]).

[1] 
https://docs.openstack.org/nova/latest/admin/support-compute.html#user-token-times-out-during-long-running-operations

-- 

Thanks,

Matt


From mriedemos at gmail.com  Fri Apr 19 13:35:29 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 08:35:29 -0500
Subject: The python black project.
In-Reply-To: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
Message-ID: <6c3cd375-81b4-01cc-f146-9271c139db8e@gmail.com>

On 4/18/2019 3:51 AM, Natal Ngétal wrote:
> Black is project to format Python code. It's more and more used by the python
> community. That can save time and harmonize the code. For example, simple quote
> versus double quote, that was not checked by pep8.i It's just an example of
> what make  black With a pre-hook commit hook this will be also avoid to lose
> time with pep8 errors.
> 
> Two links to see more:
> 
> https://github.com/ambv/black
> https://www.mattlayman.com/blog/2018/python-code-black/
> 
> I think it can be very interesting to start to use Black on OpenStack. What
> do you thinks about that? For example, we can introduce it on some projects, I
> would volunteer to try on TripleO.

I'd be a -2 on this if proposed for nova. Screwing up git blame in a 
10-year old project is a non-starter for me, not to mention the issues 
it would cause for backporting fixes to stable branch (which is already 
hard enough given the rate of change we have in the project). Drive by 
contributors might not care about that kind of thing but as a maintainer 
of the project it's pretty critical to me.

I also can't buy the argument made elsewhere in this thread that this is 
an issue turning away new contributors. Are there any new contributors 
that can really stand up here and say they are leaving openstack 
development because of code style/formatting inconsistencies? If this is 
really an issue about reviewers -1ing changes for code style, then let's 
call out those reviewers specifically and have a talk with them about 
what is and isn't appropriate for a -1 on a review in openstack. We've 
had these same nit pick review flame wars so may times over the years, 
isn't there anything better for people to be worried about? How about 
the gate burning down every few weeks? We don't have to care about code 
style if we can't merge the beautifully auto-formatted code anyway.

-- 

Thanks,

Matt


From miguel at mlavalle.com  Fri Apr 19 15:03:09 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Fri, 19 Apr 2019 10:03:09 -0500
Subject: Scuba Diving at the Denver Summit
In-Reply-To: <9cd4d330-5812-0b12-b783-017d23b2fd66@inaugust.com>
References: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
 <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>
 <9cd4d330-5812-0b12-b783-017d23b2fd66@inaugust.com>
Message-ID: <CAEzGLDhEp+5SadZy9fB1Sc20v1ud85ybtooaTXY_HhtKC2RJTw@mail.gmail.com>

Hi,

I get to Denver on Sunday 28th in the morning, so I booked the shark dive
for that day. In case others want to join me, as of April 19th at 1700UTC
there are still 5 spots available.

See you there!

On Thu, Apr 18, 2019 at 11:11 AM Monty Taylor <mordred at inaugust.com> wrote:

> Hey folks!
>
> So - I have good news and bad news. I'll start with the bad news.
>
> The bad news is that there wasn't enough interest to justify booking a
> private dive. (There was also *no* interest in homestead crater) So
> we're down to just booking slots in their regularly scheduled dives on
> the weekend.
>
> The good news is that there are still spaces available for booking. So I
> recommend going to:
>
> https://a1scubastore.com/product/dive-with-the-fish/
> https://a1scubastore.com/product/dive-with-the-sharks/
>
> and booking a dive directly.
>
> Sandy and I booked dive with the fish for Saturday (because I've got a
> board meeting on Sunday) Dive with the Fish is also now full (we got the
> last slots)
>
> I sent a message to the dive shop to see if it's possible for us to
> _also_ do the shark dive on the same day. It is - so if any of you are
> interested in doing the Saturday shark dive, let me know and I'll book
> spots for Sandy and I for the shark dive as well. But go ahead and book
> yourself a spot - so we can make sure you get to dive before we book a
> second spot.
>
> If that doesn't work for people, or if you prefer to do the fish dive on
> Sunday - don't worry about us.
>
> Monty
>
> On 4/18/19 7:05 AM, Rico Lin wrote:
> > We usually need to reraise important stuff before Summit. So bump this
> > one!:) Can't wait!
> >
> > On Wed, Jan 23, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com
> > <mailto:mordred at inaugust.com>> wrote:
> >
> >     Hey everybody!
> >
> >     tl;dr - Let me know if you'd like to go diving in the Rocky
> Mountains.
> >
> >     Of all of the places we've had a Summit where one might reasonably
> >     expect there to be a possibility of Scuba Diving, the Denver Summit
> is
> >     probably REALLY low on the list.
> >
> >     But it turns out that there is a Dive Shop that does dives at the
> >     Denver
> >     Aquarium [0] (with all the fish and sharks and whatnot) The Denver
> >     Aquarium is also very close to the Convention Center.
> >
> >     I'm going to see about putting together a private group dive event
> for
> >     those of us who think that sounds like a fun idea. Due to
> >     cross-contamination concerns for the health and safety of the fish,
> the
> >     dive shop provides all equipment - so you don't have to bring gear.
> >     They
> >     will allow bringing your own mask - and I'm assuming if a
> well-scrubbed
> >     mask is ok then a well-scrubbed dive computer would be ok - but I'll
> be
> >     checking with them when I call to arrange things.
> >
> >     If you are Open Water certified and would like to join, please send
> >     me a
> >     response back (reply directly to me rather than the list is fine) so
> I
> >     can judge general interest level when talking to the lovely humans.
> >
> >     If you are **NOT** Open Water certified but are thinking to yourself
> >     "wow, that sounds like fun" - the dive shop does certification dives
> at
> >     the aquarium on the weekends. That's a bit out of scope for me to
> >     arrange, but if you want to show up in Denver early and do an Open
> >     Water
> >     class then join us, that's awesome. You can also get certified at
> home
> >     before coming ... but you'll need an Open Water certification to
> >     join us.
> >
> >     BUT WAIT - THERE'S MORE!
> >
> >     There is another interesting diving opportunity in the general
> Mountain
> >     West area - although not immediately **close** to Denver - that Sandy
> >     and I are going to be going to before the Summit - Homestead Crater.
> >     We're arranging to meet a Scuba instructor there to do our second
> >     Altitude cert dive, and also to do a 2-dive "Hot Springs Diver"
> >     specialty. We'd be happy to have folks join us.
> >
> >     Homestead Crater [1] is outside of Salt Lake City. It's a hot spring
> -
> >     the water is 96F/35.5C and it's also an altitude dive. If people are
> >     interested, we can meet at the crater on Thursday morning pre-summit,
> >     dive the crater, then drive to Denver on Friday/Saturday.
> >
> >     ** If only a small number of people are interested in any of this -
> >     we'll likely just do the Denver dives the weekend before during one
> of
> >     the normally scheduled dive times instead of arranging a group
> outing,
> >     and shift Homestead, if anyone is interested, a few days earlier **
> >
> >     I will not have space enough in my car to get you from the crater to
> >     Denver, so if you want to fly in to SLC ahead of time and meet there,
> >     awesome.
> >
> >     Unlike Denver, the crater will require you have equipment, including
> >     scuba tanks. For anyone interested in coming, there are dive shops in
> >     Salt Lake where you can rent gear. There is a dive shop at the
> >     crater to
> >     do air fills.
> >
> >     Anyway - if anyone is interested in some or all of these things, let
> me
> >     know this week so I can get a headcount and then we can talk more
> >     off-list about logistics and figure out how to deal with things for
> >     people coming from far off (carpools, equipment, etc)
> >
> >     Monty
> >
> >     PS. If any of you aren't already using Subsurface for dive logging,
> >     I'll
> >     be happy to help you get set up.
> >
> >     [0] https://divedowntown.com/
> >     [1]
> >
> https://homesteadresort.com/utah-resort-things-to-do/homestead-crater/
> >
> >
> >
> > --
> > May The Force of OpenStack Be With You,
> > */Rico Lin
> > /*irc: ricolin
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/8813cf14/attachment-0001.html>

From mrhillsman at gmail.com  Fri Apr 19 15:18:04 2019
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Fri, 19 Apr 2019 10:18:04 -0500
Subject: Scuba Diving at the Denver Summit
In-Reply-To: <CAEzGLDhEp+5SadZy9fB1Sc20v1ud85ybtooaTXY_HhtKC2RJTw@mail.gmail.com>
References: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
 <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>
 <9cd4d330-5812-0b12-b783-017d23b2fd66@inaugust.com>
 <CAEzGLDhEp+5SadZy9fB1Sc20v1ud85ybtooaTXY_HhtKC2RJTw@mail.gmail.com>
Message-ID: <CAMVtB2G=6VAirJE=i=QGz-6pUhLd7gzcB=Fsi6bhtCF752cVuA@mail.gmail.com>

I wish I would have saw this earlier, sounds like fun. Will not be able to
make it but hope it is a great experience for you all.

On Fri, Apr 19, 2019 at 10:05 AM Miguel Lavalle <miguel at mlavalle.com> wrote:

> Hi,
>
> I get to Denver on Sunday 28th in the morning, so I booked the shark dive
> for that day. In case others want to join me, as of April 19th at 1700UTC
> there are still 5 spots available.
>
> See you there!
>
> On Thu, Apr 18, 2019 at 11:11 AM Monty Taylor <mordred at inaugust.com>
> wrote:
>
>> Hey folks!
>>
>> So - I have good news and bad news. I'll start with the bad news.
>>
>> The bad news is that there wasn't enough interest to justify booking a
>> private dive. (There was also *no* interest in homestead crater) So
>> we're down to just booking slots in their regularly scheduled dives on
>> the weekend.
>>
>> The good news is that there are still spaces available for booking. So I
>> recommend going to:
>>
>> https://a1scubastore.com/product/dive-with-the-fish/
>> https://a1scubastore.com/product/dive-with-the-sharks/
>>
>> and booking a dive directly.
>>
>> Sandy and I booked dive with the fish for Saturday (because I've got a
>> board meeting on Sunday) Dive with the Fish is also now full (we got the
>> last slots)
>>
>> I sent a message to the dive shop to see if it's possible for us to
>> _also_ do the shark dive on the same day. It is - so if any of you are
>> interested in doing the Saturday shark dive, let me know and I'll book
>> spots for Sandy and I for the shark dive as well. But go ahead and book
>> yourself a spot - so we can make sure you get to dive before we book a
>> second spot.
>>
>> If that doesn't work for people, or if you prefer to do the fish dive on
>> Sunday - don't worry about us.
>>
>> Monty
>>
>> On 4/18/19 7:05 AM, Rico Lin wrote:
>> > We usually need to reraise important stuff before Summit. So bump this
>> > one!:) Can't wait!
>> >
>> > On Wed, Jan 23, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com
>> > <mailto:mordred at inaugust.com>> wrote:
>> >
>> >     Hey everybody!
>> >
>> >     tl;dr - Let me know if you'd like to go diving in the Rocky
>> Mountains.
>> >
>> >     Of all of the places we've had a Summit where one might reasonably
>> >     expect there to be a possibility of Scuba Diving, the Denver Summit
>> is
>> >     probably REALLY low on the list.
>> >
>> >     But it turns out that there is a Dive Shop that does dives at the
>> >     Denver
>> >     Aquarium [0] (with all the fish and sharks and whatnot) The Denver
>> >     Aquarium is also very close to the Convention Center.
>> >
>> >     I'm going to see about putting together a private group dive event
>> for
>> >     those of us who think that sounds like a fun idea. Due to
>> >     cross-contamination concerns for the health and safety of the fish,
>> the
>> >     dive shop provides all equipment - so you don't have to bring gear.
>> >     They
>> >     will allow bringing your own mask - and I'm assuming if a
>> well-scrubbed
>> >     mask is ok then a well-scrubbed dive computer would be ok - but
>> I'll be
>> >     checking with them when I call to arrange things.
>> >
>> >     If you are Open Water certified and would like to join, please send
>> >     me a
>> >     response back (reply directly to me rather than the list is fine)
>> so I
>> >     can judge general interest level when talking to the lovely humans.
>> >
>> >     If you are **NOT** Open Water certified but are thinking to yourself
>> >     "wow, that sounds like fun" - the dive shop does certification
>> dives at
>> >     the aquarium on the weekends. That's a bit out of scope for me to
>> >     arrange, but if you want to show up in Denver early and do an Open
>> >     Water
>> >     class then join us, that's awesome. You can also get certified at
>> home
>> >     before coming ... but you'll need an Open Water certification to
>> >     join us.
>> >
>> >     BUT WAIT - THERE'S MORE!
>> >
>> >     There is another interesting diving opportunity in the general
>> Mountain
>> >     West area - although not immediately **close** to Denver - that
>> Sandy
>> >     and I are going to be going to before the Summit - Homestead Crater.
>> >     We're arranging to meet a Scuba instructor there to do our second
>> >     Altitude cert dive, and also to do a 2-dive "Hot Springs Diver"
>> >     specialty. We'd be happy to have folks join us.
>> >
>> >     Homestead Crater [1] is outside of Salt Lake City. It's a hot
>> spring -
>> >     the water is 96F/35.5C and it's also an altitude dive. If people are
>> >     interested, we can meet at the crater on Thursday morning
>> pre-summit,
>> >     dive the crater, then drive to Denver on Friday/Saturday.
>> >
>> >     ** If only a small number of people are interested in any of this -
>> >     we'll likely just do the Denver dives the weekend before during one
>> of
>> >     the normally scheduled dive times instead of arranging a group
>> outing,
>> >     and shift Homestead, if anyone is interested, a few days earlier **
>> >
>> >     I will not have space enough in my car to get you from the crater to
>> >     Denver, so if you want to fly in to SLC ahead of time and meet
>> there,
>> >     awesome.
>> >
>> >     Unlike Denver, the crater will require you have equipment, including
>> >     scuba tanks. For anyone interested in coming, there are dive shops
>> in
>> >     Salt Lake where you can rent gear. There is a dive shop at the
>> >     crater to
>> >     do air fills.
>> >
>> >     Anyway - if anyone is interested in some or all of these things,
>> let me
>> >     know this week so I can get a headcount and then we can talk more
>> >     off-list about logistics and figure out how to deal with things for
>> >     people coming from far off (carpools, equipment, etc)
>> >
>> >     Monty
>> >
>> >     PS. If any of you aren't already using Subsurface for dive logging,
>> >     I'll
>> >     be happy to help you get set up.
>> >
>> >     [0] https://divedowntown.com/
>> >     [1]
>> >
>> https://homesteadresort.com/utah-resort-things-to-do/homestead-crater/
>> >
>> >
>> >
>> > --
>> > May The Force of OpenStack Be With You,
>> > */Rico Lin
>> > /*irc: ricolin
>> >
>> >
>>
>>

-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/19b20a24/attachment.html>

From Arkady.Kanevsky at dell.com  Fri Apr 19 15:28:07 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Fri, 19 Apr 2019 15:28:07 +0000
Subject: https://review.openstack.org is down?
Message-ID: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/1ae2a7b2/attachment.html>

From marios at redhat.com  Fri Apr 19 15:31:07 2019
From: marios at redhat.com (Marios Andreou)
Date: Fri, 19 Apr 2019 18:31:07 +0300
Subject: https://review.openstack.org is down?
In-Reply-To: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
References: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
Message-ID: <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>

o/ Hi Arkady see
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005268.html


On Fri, Apr 19, 2019 at 6:29 PM <Arkady.Kanevsky at dell.com> wrote:

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/992166e9/attachment.html>

From andr.kurilin at gmail.com  Fri Apr 19 17:20:56 2019
From: andr.kurilin at gmail.com (Andrey Kurilin)
Date: Fri, 19 Apr 2019 20:20:56 +0300
Subject: [docs] Documenting CLI references (openstack-auto-commands)
In-Reply-To: <20190418215550.GA29937@sm-workstation>
References: <20190418215550.GA29937@sm-workstation>
Message-ID: <CAOv_6pfH-TcTEfeNbmUhTcowgiuW8GtGrZft_geMS0NWkQ2PKg@mail.gmail.com>

Hi Seam!

Rally CLI is implemented on top of argparse library. Our CLI looks like
`rally <category> <command>`.
As for documentation, I wrote a sphinx extension for auto-constructing CLI
references.
It contains some rally-specific stuff, but not too much. Maybe, it can be
helpful for you.

Refs:
1) extension itself:
https://github.com/openstack/rally/blob/1.4.1/doc/ext/cli_reference.py
2) place to display cli ref:
https://raw.githubusercontent.com/openstack/rally/1.4.1/doc/source/cli_reference.rst
3) result at rtd: https://rally.readthedocs.io/en/latest/cli_reference.html
4) result at docs.o.o using an old openstack theme -
https://docs.openstack.org/rally/latest/cli_reference.html

пт, 19 апр. 2019 г. в 01:01, Sean McGinnis <sean.mcginnis at gmx.com>:

> Hey everyone,
>
> Hoping someone has discussed this and has a recommended course of action.
>
> Back when we had the awesome support of the openstack-docs team, there was
> a
> command called openstack-auto-commands that would load up client commands
> and
> generate help output for all commands. With the resource constraints that
> hit
> the team, there were less folks to support tools like this. Docs moved into
> each team's repos and, for the most part, I think that has worked out well.
>
> Some of the automatic syncing stopped happening with this move to in-repo
> docs.
> One of them was CLI docs. But it would appear there are at least a few
> teams
> that now have not updated these docs since that move happened several
> releases
> ago:
>
>
> http://codesearch.openstack.org/?q=This%20file%20is%20tool-generated&i=nope&files=&repos=
>
> There are others that appear to have used the last automatically generated
> version and have been (varying degrees of) successful at just manually
> updating
> the doc as things change.
>
> When the tool was removed (https://review.openstack.org/#/c/509402/) it
> was
> stated that it wasn't needed because cliff has sphinx integration to do the
> equivalent automatically. That's all well and good... if you are using
> cliff.
> But I think many of our legacy clients are not.
>
> So looking for recommendations on ways to best keep these docs up to date
> now.
> Migrate to cliff? Other in-repo automation tools?
>
> (and yeah, I know, "drop the CLI and move to openstackclient)
>
> Thanks for any suggestions!
>
> Sean
>
>

-- 
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/332514b4/attachment-0001.html>

From sean.mcginnis at gmx.com  Fri Apr 19 19:26:36 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 19 Apr 2019 14:26:36 -0500
Subject: [docs] Documenting CLI references (openstack-auto-commands)
In-Reply-To: <CAOv_6pfH-TcTEfeNbmUhTcowgiuW8GtGrZft_geMS0NWkQ2PKg@mail.gmail.com>
References: <20190418215550.GA29937@sm-workstation>
 <CAOv_6pfH-TcTEfeNbmUhTcowgiuW8GtGrZft_geMS0NWkQ2PKg@mail.gmail.com>
Message-ID: <20190419192635.GA7285@sm-workstation>

On Fri, Apr 19, 2019 at 08:20:56PM +0300, Andrey Kurilin wrote:
> Hi Seam!
>
> Rally CLI is implemented on top of argparse library. Our CLI looks like
> `rally <category> <command>`.
> As for documentation, I wrote a sphinx extension for auto-constructing CLI
> references.
> It contains some rally-specific stuff, but not too much. Maybe, it can be
> helpful for you.
>
> Refs:
> 1) extension itself:
> https://github.com/openstack/rally/blob/1.4.1/doc/ext/cli_reference.py
> 2) place to display cli ref:
> https://raw.githubusercontent.com/openstack/rally/1.4.1/doc/source/cli_reference.rst
> 3) result at rtd: https://rally.readthedocs.io/en/latest/cli_reference.html
> 4) result at docs.o.o using an old openstack theme -
> https://docs.openstack.org/rally/latest/cli_reference.html
>

This looks very useful. Thanks Andrey!


From mriedemos at gmail.com  Fri Apr 19 19:34:10 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 14:34:10 -0500
Subject: [placement][tripleo][kolla] Update on placement extraction from nova
Message-ID: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>

I put together an etherpad [1] for a Forum session at the upcoming 
summit to go over what happened with placement extraction in Stein and 
the plan for Train.

With help I was able to figure out where the extracted placement 
packages are so it's good to know those exist.

Mohammed also gave me the status on OpenStack-Ansible but I'm less clear 
on TripleO and Kolla.

I thought TripleO was supporting fresh installs with extracted placement 
but gerrit is down and Lee is out today so I'm not sure, and I'm not 
seeing anything about it in TripleO release notes.

I did find that the Kolla release notes say they support extracted 
placement [2] but I'm not sure to what extent - is it just install from 
source (pypi?) or also some package support? How about upgrades, i.e. 
the data migration from placement-in-nova to extracted placement?

So if people from the TripleO and Kolla teams can reply here and clarify 
I can get that back into the etherpad before the Forum session.

[1] 
https://etherpad.openstack.org/p/DEN-update-on-placement-extraction-from-nova
[2] https://docs.openstack.org/releasenotes/kolla/stein.html

-- 

Thanks,

Matt


From giorgis at acmac.uoc.gr  Fri Apr 19 19:47:23 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Fri, 19 Apr 2019 22:47:23 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
Message-ID: <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>

 Hello again and apologies for my absence!

 First of all let me express my gratitude for your valuable feedback.
 I understand what all of you are saying and I will try what Sean 
 suggested by setting the values for CPUs and Disk to something beyond 
 the default.

 Meanwhile what I 've though was to change the "weight_classes" 
 parameter to use only the "RAM" weight instead of all, since initially 
 this is what I would like to be based and then move on from there.
 Unfortunately I haven't found a way to properly set it and no matter 
 what I 've tried I always ended up with an error in nova-scheduler.log 
 saying "ERROR nova ValueError: Empty module name"

 Any ideas on how to set it based on the available weights? It seems 
 that it needs a list format but how?

 Best,

 G.

> On Wed, 2019-04-17 at 18:24 -0700, melanie witt wrote:
>> On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney <smooney at redhat.com> 
>> wrote:
>> > On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
>> > > On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
>> > > <giorgis at acmac.uoc.gr> wrote:
>> > > > Shouldn’t that be the correct behavior and place the new VM on 
>> the host with the smaller weight? Isn’t that what
>> > > > the
>> > > > negative value for “ram_weight_multiplier” does ?
>> > >
>> > > No, it's the opposite, higher weights win. That's why you have 
>> to use a
>> > > negative value for ram_weight_multiplier if you want hosts with 
>> _less_
>> > > RAM to win over hosts with more RAM (stacking).
>> > >
>> > > > Please let me know how I can provide to you more debug 
>> info....
>> > >
>> > > One thing I noticed from your log is on the second request, 
>> 'cpu1' has
>> > > io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1] 
>> will
>> > > prefer hosts with fewer io_iops by default. Note that's only one 
>> piece
>> > > of the ending weight -- the weighing process will take a sum of 
>> all of
>> > > the weights each weigher returns. So the weight returned from 
>> RamWeigher
>> > > is added to the weight returned from IoOpsWeigher is added the 
>> weight
>> > > returned from CPUWeigher, and so on.
>> > >
>> > > So, as Matt said, we're a bit in the dark now as far as what 
>> each
>> > > weigher is returning and we don't currently have debug logging 
>> per
>> > > weigher the way we do for filters. That would be an enhancement 
>> we could
>> > > make to aid in debugging issues like this one. You could hack 
>> something
>> > > up locally to log/print the returned weight in each weight class 
>> under
>> > > the nova/scheduler/weights/ directory, if you want to dig into 
>> that.
>> > >
>> > > Another thing I noticed is that there are probably some new 
>> weighers
>> > > available by default that did not exist in the previous version 
>> of nova
>> > > that you were using in the past. By default, the config option 
>> for weighers:
>> > >
>> > > [filter_scheduler]weight_classes = 
>> ["nova.scheduler.weights.all_weighers"]
>> > >
>> > > will pick up all weigher classes in the nova/scheduler/weights/ 
>> code
>> > > directory. You might take a look at these and see if any are 
>> ones you
>> > > should exclude in your environment. For example, the CPUWeigher 
>> [1] (new
>> > > in Rocky) will spread VMs based on available CPU by default.
>> >
>> > most of the weighers spread by default so the cpu weigher may be a 
>> factor but
>> > the the disk weigher tends to all hevily impact the choice.
>> >
>> > we do not normalise any of the values retured by the different 
>> weighers
>> > the disk wighter is basically  host_state.free_disk_mb * 
>> disk_weight_multiplier
>>
>> Hm, I thought we do based on this code:
>>
>> 
>> https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135
>>
>> which normalizes the weight to a value between 0.0 and 1.0.
> yes we do but that is witnin the same resouce type.
>
> we do not normalise between resoucser types.
> on a typical host you will have between 2GB and 8GB of ram per cpu 
> core
> and you will have between 10G and 100G of local disk typically.
>
> so we dont look at the capasity of each resouce and renomalise 
> between them.
> if you want achive that you have to carefully tweek the weights to do
> that manually.
>
> that said i have not sat down and worked out the math to do that in
> about 3-4 years
> but i think i used to run my dev clouster with the
> disk_weight_multiplier around 0.04
> and i think i used to set the ram_weight_multiplier to 2.0
>
> anyway that is just my personal experience and i was trying to tweek
> the spreading behavior
> to spread based on ram then cpus then disk rather then pack based on
> ram but spread based on the rest.
> so i dont know if this is relvent or correct for this usecase.
>
>>
>> If the multiplier is large though, that could make the considered 
>> value
>>  > 1.0 (as is the case with the default 
>> build_failure_weight_multiplier:
>>
>> 
>> https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501
>>
>> -melanie
>>
>> > althoer host_state.free_disk_mb is actully disk_available_least.
>> >
>> > as a result the disk filter will weigh cpu1 19456 height then cpu2
>> > the dela between the cpu1 and cpu2 based on the ram weigher is 
>> only 2048
>> >
>> > if you want the ram filter to take presedence over teh disk filter 
>> you will
>> > need to scale the disk filter down to be in a similar value range
>> >
>> > i woudl suggest setting disk_weight_multiplier=0.001
>> >
>> > > This
>> > > weigher might be contributing to the VM spreading you're seeing. 
>> You
>> > > might try playing with the '[filter_scheduler]weight_classes' 
>> config
>> > > option to select only the weighers you want or alternatively you 
>> could
>> > > set the weighers multipliers the way you prefer.
>> > >
>> > > -melanie
>> > >
>> > > [1] 
>> https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
>> > >
>> > > > > > On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>> > > > > > And here is the new log where spawning of 2 VMs can be 
>> seen with a few seconds of difference:
>> > > > > > https://pastebin.com/Xy2FL2KL
>> > > > > > Initially both hosts are of weight 1.0 then the one with 
>> one VM already running has negative weight but the
>> > > > > > new
>> > > > > > VM is placed on the other host.
>> > > > > > Really-really strange why this is happening...
>> > > > >
>> > > > > < 2019-04-17 23:26:18.770 157355 DEBUG 
>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>> > > > > 377b3d37bff9
>> > > > > 6a4c2e32919e4a6fa5c5d956beb68eef 
>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2, 
>> cpu2)
>> > > > > ram:
>> > > > > 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1) 
>> ram: 32153MB disk: 1906688MB io_ops: 0 instances:
>> > > > > 0]
>> > > > > _get_sorted_hosts 
>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>> > > > >
>> > > > > < 2019-04-17 23:26:18.771 157355 DEBUG 
>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>> > > > > 377b3d37bff9
>> > > > > 6a4c2e32919e4a6fa5c5d956beb68eef 
>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed 
>> [WeighedHost
>> > > > > [host:
>> > > > > (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 
>> instances: 0, weight: 1.0], WeighedHost [host: (cpu2,
>> > > > > cpu2)
>> > > > > ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight: 
>> -0.00900862553213]] _get_sorted_hosts
>> > > > > 
>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>> > > > >
>> > > > > cpu1 is definitely getting weighed higher but I'm not sure 
>> why. We likely need some debug logging on the
>> > > > > result of
>> > > > > each weigher like we have for each filter to figure out 
>> what's going on with the weighers.
>> > > > >
>> > > > > --
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Matt
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>>
>>


From mriedemos at gmail.com  Fri Apr 19 20:39:17 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 15:39:17 -0500
Subject: [nova] Running multinode resize tests in the gate
In-Reply-To: <CACqyMieRt4ONj6wU=Q2K-vxVeqduoTmvWY2VtroE7drFHHAcvg@mail.gmail.com>
References: <CACqyMieRt4ONj6wU=Q2K-vxVeqduoTmvWY2VtroE7drFHHAcvg@mail.gmail.com>
Message-ID: <cab46f13-d51b-ebc6-1a8a-1952780228f9@gmail.com>

On 4/18/2019 1:04 PM, Artom Lifshitz wrote:
> Yo Novans,
> 
> In trying to understand why my partial fix to bug 1813789 [1] -
> specifically the part where reverting  a resize fails because we get
> the network-vif-plugged event from Neutron before we start listening
> for it - I noticed that we don't test multinode resize (and revert) in
> the gate. As far as I can tell, the only place where the revert tests
> are run are in tempest-full-py3, and that's on an allinone single
> node.
> 
> In order to test a theory of mine about revert resize on the same node
> vs source to dest and back again, I do have a DNM patch up [2] to run
> the resize tests in the nova-live-migration job - I think that's the
> only multinode tempest job we have, right? I think that job also runs
> evacuation tests [3], correct? So, should we just rename it
> nova-multinode and add resize to the list of tests it runs?
> 
> [1]https://bugs.launchpad.net/nova/+bug/1813789
> [2]https://review.openstack.org/#/c/653498/
> [3]https://github.com/openstack/nova/blob/54d8b40471e6f7b36dbe45966c1c605f94d49182/playbooks/legacy/nova-live-migration/run.yaml#L52

We used to run tempest-multinode-full until recently [1].

That's probably what you're looking for, but I don't really want to add 
that job back for the reasons mentioned in the commit message and 
associated mailing list thread.

We could make nova-next multinode but then we start having overlap with 
nova-live-migration (minus the evacuate testing) and tempest-slow. The 
tempest-slow job is also multinode but apparently there aren't any 
resize tests marked slow so those don't get run in that job.

So...enabling resize tests in nova-live-migration is probably the best 
option at this point, and yeah likely means renaming it as well (since 
it's already confusingly named nova-live-migration but also runs 
evacuate tests too via a post-test hook). The only thing I worry about 
with that one is needing to keep a regex of tempest tests we run, but 
technically we're already doing that for the live migration tests [2].

Maybe it's time to bite the bullet and use a real rc file like we have 
for some other jobs, e.g. [3].

[1] 
https://github.com/openstack/nova/commit/95e782dfd86caa4201d28ee86ba2bb475e0a409f#diff-7415f5ff7beee2cdf9ffe31e12e4c086
[2] 
https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/nova/tests/live_migration/hooks/run_tests.sh#L29
[3] 
https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/devstack/tempest-dsvm-lvm-rc

-- 

Thanks,

Matt


From mriedemos at gmail.com  Fri Apr 19 20:40:01 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 19 Apr 2019 15:40:01 -0500
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
 <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
Message-ID: <34e68074-2324-312a-72eb-7925ef79ee49@gmail.com>

On 4/19/2019 2:47 PM, Georgios Dimitrakakis wrote:
> Meanwhile what I 've though was to change the "weight_classes" parameter 
> to use only the "RAM" weight instead of all, since initially this is 
> what I would like to be based and then move on from there.
> Unfortunately I haven't found a way to properly set it and no matter 
> what I 've tried I always ended up with an error in nova-scheduler.log 
> saying "ERROR nova ValueError: Empty module name"
> 
> Any ideas on how to set it based on the available weights? It seems that 
> it needs a list format but how?

You should be able to specify this in your nova.conf:

[filter_scheduler]
weight_classes = nova.scheduler.weights.ram.RAMWeigher

Does that not work?

-- 

Thanks,

Matt


From ekcs.openstack at gmail.com  Fri Apr 19 20:40:34 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Fri, 19 Apr 2019 13:40:34 -0700
Subject: Call for help! 'U' Release name Mandarin speakers
In-Reply-To: <a6fe65e2-358a-a87b-9383-71cad58df6ce@openstack.org>
References: <20190214021836.GD12795@thor.bakeyournoodle.com>
 <a6fe65e2-358a-a87b-9383-71cad58df6ce@openstack.org>
Message-ID: <D8DF7E66.C446C%ekcs.openstack@gmail.com>

I am a native mandarin speaker. I'm happy to work with Tony in this
process.

Eric Kao

On 4/19/19, 2:25 AM, "Thierry Carrez" <thierry at openstack.org> wrote:

>Tony Breeds wrote, back in February:
>>      Now that we know when and where the 'U' summit will be[1] we can
>> pick the name for the U release.  I'm happy to act as coordinator but
>> given the location I'd really like a native speaker (or 2) to help with
>> assessing the names against the criteria, defining the geographic
>> region and translating the civs POLL when we get there.
>> 
>> Yours Tony.
>> 
>> [1] https://www.openstack.org/summit/shanghai-2019
>
>Now that we are in the Train (that name just keeps on giving) there is
>more pressure to name 'U'...
>
>Do we have people from China interested in helping with that process ?
>
>As a reminder, the rules are described at:
>https://governance.openstack.org/tc/reference/release-naming.html
>
>-- 
>Thierry Carrez (ttx)
>




From melwittt at gmail.com  Fri Apr 19 21:03:15 2019
From: melwittt at gmail.com (melanie witt)
Date: Fri, 19 Apr 2019 14:03:15 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
 <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
Message-ID: <fa6b66c9-1893-67b9-11f5-78c64b6776fe@gmail.com>

On Fri, 19 Apr 2019 22:47:23 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
>   Hello again and apologies for my absence!
> 
>   First of all let me express my gratitude for your valuable feedback.
>   I understand what all of you are saying and I will try what Sean
>   suggested by setting the values for CPUs and Disk to something beyond
>   the default.
> 
>   Meanwhile what I 've though was to change the "weight_classes"
>   parameter to use only the "RAM" weight instead of all, since initially
>   this is what I would like to be based and then move on from there.
>   Unfortunately I haven't found a way to properly set it and no matter
>   what I 've tried I always ended up with an error in nova-scheduler.log
>   saying "ERROR nova ValueError: Empty module name"
> 
>   Any ideas on how to set it based on the available weights? It seems
>   that it needs a list format but how?

Did you try:

weight_classes = ['nova.scheduler.weights.ram.RAMWeigher']

That's what should work, based on the code I see here:

https://github.com/openstack/nova/blob/stable/rocky/nova/loadables.py#L98

-melanie

>> On Wed, 2019-04-17 at 18:24 -0700, melanie witt wrote:
>>> On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney <smooney at redhat.com>
>>> wrote:
>>>> On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
>>>>> On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
>>>>> <giorgis at acmac.uoc.gr> wrote:
>>>>>> Shouldn’t that be the correct behavior and place the new VM on
>>> the host with the smaller weight? Isn’t that what
>>>>>> the
>>>>>> negative value for “ram_weight_multiplier” does ?
>>>>>
>>>>> No, it's the opposite, higher weights win. That's why you have
>>> to use a
>>>>> negative value for ram_weight_multiplier if you want hosts with
>>> _less_
>>>>> RAM to win over hosts with more RAM (stacking).
>>>>>
>>>>>> Please let me know how I can provide to you more debug
>>> info....
>>>>>
>>>>> One thing I noticed from your log is on the second request,
>>> 'cpu1' has
>>>>> io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1]
>>> will
>>>>> prefer hosts with fewer io_iops by default. Note that's only one
>>> piece
>>>>> of the ending weight -- the weighing process will take a sum of
>>> all of
>>>>> the weights each weigher returns. So the weight returned from
>>> RamWeigher
>>>>> is added to the weight returned from IoOpsWeigher is added the
>>> weight
>>>>> returned from CPUWeigher, and so on.
>>>>>
>>>>> So, as Matt said, we're a bit in the dark now as far as what
>>> each
>>>>> weigher is returning and we don't currently have debug logging
>>> per
>>>>> weigher the way we do for filters. That would be an enhancement
>>> we could
>>>>> make to aid in debugging issues like this one. You could hack
>>> something
>>>>> up locally to log/print the returned weight in each weight class
>>> under
>>>>> the nova/scheduler/weights/ directory, if you want to dig into
>>> that.
>>>>>
>>>>> Another thing I noticed is that there are probably some new
>>> weighers
>>>>> available by default that did not exist in the previous version
>>> of nova
>>>>> that you were using in the past. By default, the config option
>>> for weighers:
>>>>>
>>>>> [filter_scheduler]weight_classes =
>>> ["nova.scheduler.weights.all_weighers"]
>>>>>
>>>>> will pick up all weigher classes in the nova/scheduler/weights/
>>> code
>>>>> directory. You might take a look at these and see if any are
>>> ones you
>>>>> should exclude in your environment. For example, the CPUWeigher
>>> [1] (new
>>>>> in Rocky) will spread VMs based on available CPU by default.
>>>>
>>>> most of the weighers spread by default so the cpu weigher may be a
>>> factor but
>>>> the the disk weigher tends to all hevily impact the choice.
>>>>
>>>> we do not normalise any of the values retured by the different
>>> weighers
>>>> the disk wighter is basically  host_state.free_disk_mb *
>>> disk_weight_multiplier
>>>
>>> Hm, I thought we do based on this code:
>>>
>>>
>>> https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135
>>>
>>> which normalizes the weight to a value between 0.0 and 1.0.
>> yes we do but that is witnin the same resouce type.
>>
>> we do not normalise between resoucser types.
>> on a typical host you will have between 2GB and 8GB of ram per cpu
>> core
>> and you will have between 10G and 100G of local disk typically.
>>
>> so we dont look at the capasity of each resouce and renomalise
>> between them.
>> if you want achive that you have to carefully tweek the weights to do
>> that manually.
>>
>> that said i have not sat down and worked out the math to do that in
>> about 3-4 years
>> but i think i used to run my dev clouster with the
>> disk_weight_multiplier around 0.04
>> and i think i used to set the ram_weight_multiplier to 2.0
>>
>> anyway that is just my personal experience and i was trying to tweek
>> the spreading behavior
>> to spread based on ram then cpus then disk rather then pack based on
>> ram but spread based on the rest.
>> so i dont know if this is relvent or correct for this usecase.
>>
>>>
>>> If the multiplier is large though, that could make the considered
>>> value
>>>   > 1.0 (as is the case with the default
>>> build_failure_weight_multiplier:
>>>
>>>
>>> https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501
>>>
>>> -melanie
>>>
>>>> althoer host_state.free_disk_mb is actully disk_available_least.
>>>>
>>>> as a result the disk filter will weigh cpu1 19456 height then cpu2
>>>> the dela between the cpu1 and cpu2 based on the ram weigher is
>>> only 2048
>>>>
>>>> if you want the ram filter to take presedence over teh disk filter
>>> you will
>>>> need to scale the disk filter down to be in a similar value range
>>>>
>>>> i woudl suggest setting disk_weight_multiplier=0.001
>>>>
>>>>> This
>>>>> weigher might be contributing to the VM spreading you're seeing.
>>> You
>>>>> might try playing with the '[filter_scheduler]weight_classes'
>>> config
>>>>> option to select only the weighers you want or alternatively you
>>> could
>>>>> set the weighers multipliers the way you prefer.
>>>>>
>>>>> -melanie
>>>>>
>>>>> [1]
>>> https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
>>>>>
>>>>>>>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>>>>>>>> And here is the new log where spawning of 2 VMs can be
>>> seen with a few seconds of difference:
>>>>>>>> https://pastebin.com/Xy2FL2KL
>>>>>>>> Initially both hosts are of weight 1.0 then the one with
>>> one VM already running has negative weight but the
>>>>>>>> new
>>>>>>>> VM is placed on the other host.
>>>>>>>> Really-really strange why this is happening...
>>>>>>>
>>>>>>> < 2019-04-17 23:26:18.770 157355 DEBUG
>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>> 377b3d37bff9
>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered [(cpu2,
>>> cpu2)
>>>>>>> ram:
>>>>>>> 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1)
>>> ram: 32153MB disk: 1906688MB io_ops: 0 instances:
>>>>>>> 0]
>>>>>>> _get_sorted_hosts
>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>>>>>>>
>>>>>>> < 2019-04-17 23:26:18.771 157355 DEBUG
>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>> 377b3d37bff9
>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed
>>> [WeighedHost
>>>>>>> [host:
>>>>>>> (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0
>>> instances: 0, weight: 1.0], WeighedHost [host: (cpu2,
>>>>>>> cpu2)
>>>>>>> ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight:
>>> -0.00900862553213]] _get_sorted_hosts
>>>>>>>
>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>>>>>>>
>>>>>>> cpu1 is definitely getting weighed higher but I'm not sure
>>> why. We likely need some debug logging on the
>>>>>>> result of
>>>>>>> each weigher like we have for each filter to figure out
>>> what's going on with the weighers.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Matt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>






From gmann at ghanshyammann.com  Fri Apr 19 21:06:04 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 19 Apr 2019 16:06:04 -0500
Subject: [qa] [ptg] QA Stein Retrospective Etherpad
Message-ID: <16a376bab33.121375826106573.1711256811763934029@ghanshyammann.com>

Hi All,

I have started an etherpad for Stein cycle QA retrospective
 - https://etherpad.openstack.org/p/qa-stein-retrospective 

This will be discussed in PTG on Thursday 9.00-09.30 AM, so please add your
feedback/comment before that.

-gmann




From giorgis at acmac.uoc.gr  Fri Apr 19 21:17:38 2019
From: giorgis at acmac.uoc.gr (Georgios Dimitrakakis)
Date: Sat, 20 Apr 2019 00:17:38 +0300
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <fa6b66c9-1893-67b9-11f5-78c64b6776fe@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <130b5e42e8466ef9c7cc0d6e91a95142@acmac.uoc.gr>
 <5ed21acd-8aa9-5829-50f1-2885000cff8d@gmail.com>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
 <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
 <fa6b66c9-1893-67b9-11f5-78c64b6776fe@gmail.com>
Message-ID: <f6fea7852b361e5d6b9ea062bb41f248@acmac.uoc.gr>

> On Fri, 19 Apr 2019 22:47:23 +0300, Georgios Dimitrakakis
> <giorgis at acmac.uoc.gr> wrote:
>>   Hello again and apologies for my absence!
>> First of all let me express my gratitude for your valuable feedback.
>>   I understand what all of you are saying and I will try what Sean
>>   suggested by setting the values for CPUs and Disk to something 
>> beyond
>>   the default.
>> Meanwhile what I 've though was to change the "weight_classes"
>>   parameter to use only the "RAM" weight instead of all, since 
>> initially
>>   this is what I would like to be based and then move on from there.
>>   Unfortunately I haven't found a way to properly set it and no 
>> matter
>>   what I 've tried I always ended up with an error in 
>> nova-scheduler.log
>>   saying "ERROR nova ValueError: Empty module name"
>> Any ideas on how to set it based on the available weights? It seems
>>   that it needs a list format but how?
>
> Did you try:
>
> weight_classes = ['nova.scheduler.weights.ram.RAMWeigher']
>
> That's what should work, based on the code I see here:
>
> 
> https://github.com/openstack/nova/blob/stable/rocky/nova/loadables.py#L98
>
> -melanie

 I 'll try that ASAP and get back to you. I believe I have failed to 
 properly use CAPS letters.

 Meanwhile, what I 've done is that by using Sean's suggestions about 
 RAM, CPU and Disk like below:

 ram_weight_multiplier=-1.0
 cpu_weight_multiplier=-1.0
 disk_weight_multiplier=0.001

 I have managed to stack VMs on one node.
 VM stacking with the above is working correctly as long as no IOPS are 
 involved because when they do weights are messed and VMs spread. But I 
 assume that this can be dealt by playing with "io_ops_weight_multiplier" 
 value.

 So far so good if there wasn't for the following huge problem which is 
 that stacking never stops even when resources are exceeded.

 To explain what I mean I will give you an introduction of my hardware. 
 My Compute Node has 1x Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8 core 
 or 16 threads and 32GB of RAM.

 Furthermore on nova.conf I have set:

 cpu_allocation_ratio=1.0
 ram_allocation_ratio=1.0

 With the above settings I have been able to stack on this node 20 VMs 
 with 2vCPUs each and 2GB of RAM. See the following excerpt (when 
 spawning the 20th VM) from the scheduler log:


 2019-04-19 23:26:42.322 379112 DEBUG nova.scheduler.filter_scheduler 
 [req-73ddffc1-8cd2-4060-bd4c-786ba00793d1 
 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
 default default] Weighed [WeighedHost [host: (cpu2, cpu2) ram: -6759MB 
 disk: 1536000MB io_ops: 0 instances: 19, weight: 0.000805585392052], 
 WeighedHost [host: (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0 
 instances: 0, weight: -1.999]] _get_sorted_hosts 
 /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454


 To me is very clear that the aforementioned ratio settings are ignored 
 and haven't tried what the limit would be (the final number of VMs that 
 can be spawned).


 Additionally I did try to perform this again but this time I set the 
 following:

 enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter


 This time only 15 VMs went to one compute node because on the 16th 
 attempt the RAMFilter returned just one node (see log below):

 2019-04-19 23:59:34.170 383851 DEBUG nova.filters 
 [req-9cdd3c15-5bd8-4e06-bf0b-eb2d4d26d66d 
 6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 - 
 default default] Filter RamFilter returned 1 host(s) 
 get_filtered_objects 
 /usr/lib/python2.7/site-packages/nova/filters.py:104


 Melanie told me earlier on this thread that setting "enabled_filters" 
 shouldn't make any difference but it is obvious from the above behavior 
 that this is not the case.

 In any case this is not a correct behavior since 15VMs x 2vCPUs/VM = 
 30vCPUs which is almost double the available 16cores, don't forget that 
 I have ratio 1:1 for both CPU and RAM.

 Does it seem logical to you?

 Best,

 G.






>
>>> On Wed, 2019-04-17 at 18:24 -0700, melanie witt wrote:
>>>> On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney 
>>>> <smooney at redhat.com>
>>>> wrote:
>>>>> On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
>>>>>> On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
>>>>>> <giorgis at acmac.uoc.gr> wrote:
>>>>>>> Shouldn’t that be the correct behavior and place the new VM on
>>>> the host with the smaller weight? Isn’t that what
>>>>>>> the
>>>>>>> negative value for “ram_weight_multiplier” does ?
>>>>>>
>>>>>> No, it's the opposite, higher weights win. That's why you have
>>>> to use a
>>>>>> negative value for ram_weight_multiplier if you want hosts with
>>>> _less_
>>>>>> RAM to win over hosts with more RAM (stacking).
>>>>>>
>>>>>>> Please let me know how I can provide to you more debug
>>>> info....
>>>>>>
>>>>>> One thing I noticed from your log is on the second request,
>>>> 'cpu1' has
>>>>>> io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1]
>>>> will
>>>>>> prefer hosts with fewer io_iops by default. Note that's only one
>>>> piece
>>>>>> of the ending weight -- the weighing process will take a sum of
>>>> all of
>>>>>> the weights each weigher returns. So the weight returned from
>>>> RamWeigher
>>>>>> is added to the weight returned from IoOpsWeigher is added the
>>>> weight
>>>>>> returned from CPUWeigher, and so on.
>>>>>>
>>>>>> So, as Matt said, we're a bit in the dark now as far as what
>>>> each
>>>>>> weigher is returning and we don't currently have debug logging
>>>> per
>>>>>> weigher the way we do for filters. That would be an enhancement
>>>> we could
>>>>>> make to aid in debugging issues like this one. You could hack
>>>> something
>>>>>> up locally to log/print the returned weight in each weight class
>>>> under
>>>>>> the nova/scheduler/weights/ directory, if you want to dig into
>>>> that.
>>>>>>
>>>>>> Another thing I noticed is that there are probably some new
>>>> weighers
>>>>>> available by default that did not exist in the previous version
>>>> of nova
>>>>>> that you were using in the past. By default, the config option
>>>> for weighers:
>>>>>>
>>>>>> [filter_scheduler]weight_classes =
>>>> ["nova.scheduler.weights.all_weighers"]
>>>>>>
>>>>>> will pick up all weigher classes in the nova/scheduler/weights/
>>>> code
>>>>>> directory. You might take a look at these and see if any are
>>>> ones you
>>>>>> should exclude in your environment. For example, the CPUWeigher
>>>> [1] (new
>>>>>> in Rocky) will spread VMs based on available CPU by default.
>>>>>
>>>>> most of the weighers spread by default so the cpu weigher may be 
>>>>> a
>>>> factor but
>>>>> the the disk weigher tends to all hevily impact the choice.
>>>>>
>>>>> we do not normalise any of the values retured by the different
>>>> weighers
>>>>> the disk wighter is basically  host_state.free_disk_mb *
>>>> disk_weight_multiplier
>>>>
>>>> Hm, I thought we do based on this code:
>>>>
>>>>
>>>> 
>>>> https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135
>>>>
>>>> which normalizes the weight to a value between 0.0 and 1.0.
>>> yes we do but that is witnin the same resouce type.
>>>
>>> we do not normalise between resoucser types.
>>> on a typical host you will have between 2GB and 8GB of ram per cpu
>>> core
>>> and you will have between 10G and 100G of local disk typically.
>>>
>>> so we dont look at the capasity of each resouce and renomalise
>>> between them.
>>> if you want achive that you have to carefully tweek the weights to 
>>> do
>>> that manually.
>>>
>>> that said i have not sat down and worked out the math to do that in
>>> about 3-4 years
>>> but i think i used to run my dev clouster with the
>>> disk_weight_multiplier around 0.04
>>> and i think i used to set the ram_weight_multiplier to 2.0
>>>
>>> anyway that is just my personal experience and i was trying to 
>>> tweek
>>> the spreading behavior
>>> to spread based on ram then cpus then disk rather then pack based 
>>> on
>>> ram but spread based on the rest.
>>> so i dont know if this is relvent or correct for this usecase.
>>>
>>>>
>>>> If the multiplier is large though, that could make the considered
>>>> value
>>>>   > 1.0 (as is the case with the default
>>>> build_failure_weight_multiplier:
>>>>
>>>>
>>>> 
>>>> https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501
>>>>
>>>> -melanie
>>>>
>>>>> althoer host_state.free_disk_mb is actully disk_available_least.
>>>>>
>>>>> as a result the disk filter will weigh cpu1 19456 height then 
>>>>> cpu2
>>>>> the dela between the cpu1 and cpu2 based on the ram weigher is
>>>> only 2048
>>>>>
>>>>> if you want the ram filter to take presedence over teh disk 
>>>>> filter
>>>> you will
>>>>> need to scale the disk filter down to be in a similar value range
>>>>>
>>>>> i woudl suggest setting disk_weight_multiplier=0.001
>>>>>
>>>>>> This
>>>>>> weigher might be contributing to the VM spreading you're seeing.
>>>> You
>>>>>> might try playing with the '[filter_scheduler]weight_classes'
>>>> config
>>>>>> option to select only the weighers you want or alternatively you
>>>> could
>>>>>> set the weighers multipliers the way you prefer.
>>>>>>
>>>>>> -melanie
>>>>>>
>>>>>> [1]
>>>> 
>>>> https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
>>>>>>
>>>>>>>>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>>>>>>>>> And here is the new log where spawning of 2 VMs can be
>>>> seen with a few seconds of difference:
>>>>>>>>> https://pastebin.com/Xy2FL2KL
>>>>>>>>> Initially both hosts are of weight 1.0 then the one with
>>>> one VM already running has negative weight but the
>>>>>>>>> new
>>>>>>>>> VM is placed on the other host.
>>>>>>>>> Really-really strange why this is happening...
>>>>>>>>
>>>>>>>> < 2019-04-17 23:26:18.770 157355 DEBUG
>>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>>> 377b3d37bff9
>>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered 
>>>> [(cpu2,
>>>> cpu2)
>>>>>>>> ram:
>>>>>>>> 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1)
>>>> ram: 32153MB disk: 1906688MB io_ops: 0 instances:
>>>>>>>> 0]
>>>>>>>> _get_sorted_hosts
>>>> 
>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>>>>>>>>
>>>>>>>> < 2019-04-17 23:26:18.771 157355 DEBUG
>>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>>> 377b3d37bff9
>>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed
>>>> [WeighedHost
>>>>>>>> [host:
>>>>>>>> (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0
>>>> instances: 0, weight: 1.0], WeighedHost [host: (cpu2,
>>>>>>>> cpu2)
>>>>>>>> ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight:
>>>> -0.00900862553213]] _get_sorted_hosts
>>>>>>>>
>>>> 
>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>>>>>>>>
>>>>>>>> cpu1 is definitely getting weighed higher but I'm not sure
>>>> why. We likely need some debug logging on the
>>>>>>>> result of
>>>>>>>> each weigher like we have for each filter to figure out
>>>> what's going on with the weighers.
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Matt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>


From pabelanger at redhat.com  Fri Apr 19 21:28:34 2019
From: pabelanger at redhat.com (Paul Belanger)
Date: Fri, 19 Apr 2019 17:28:34 -0400
Subject: [stackalytics] Moving stackalytics configuration file to github
 repo
In-Reply-To: <CABURL_mWTC6rZfrfHJs_v0UYjMVez_9ag9+Yzt88A1QRsx4a4w@mail.gmail.com>
References: <CABURL_mWTC6rZfrfHJs_v0UYjMVez_9ag9+Yzt88A1QRsx4a4w@mail.gmail.com>
Message-ID: <20190419212834.GA22630@localhost.localdomain>

On Thu, Apr 18, 2019 at 10:50:12PM +0400, Sergey Nikitin wrote:
> Hello everyone,
> 
> Every day Stackalytics team works on new features.
> One of these features is a statistics collecting for non OpenStack
> projects. For example Kubernetes [1].
> Stackalytics project has configuration file (default_data.json), which
> contains a lot of data, including user properties. Such as name, launchpad
> ID, github ID, email and companies.
> 
> It's a usual situation when a contributor change his/her email or find a
> better job in new company.
> To do not loose stats which were pinned with old email or to point that
> he/she now work in new company contributor must add/modify his/her record
> in default_data.json config file.
> 
> This config file was in `etc` directory in stackalytics repo [2].
> But we moved this file to new github repository [3].
> It was made to do not force non OpenStack contributors use OpenStack Gerrit
> to update their stackalytics profiles.
> 
> From this moment if you want to update your stackalytics profile you must
> create a pull request to the new github repo [3]. The new data will be
> applied within 12 hours after pull request merge.
> 
I'd much rather see default_data split so openstack related info can
continue to be hosted on gerrit (opendev) and others github. Asking the
openstack community to now use github when gerrit works just as well is
a pretty large ask.

- Paul

> All current patches with user data changes from stackalytics gerrit [4] are
> still valid and will be applied and moved to [3] after approve. So do not
> worry about them.
> 
> More information about user data updating you can find in Stackalytics Wiki
> page [5].
> 
> If you have any questions we will be glad to answer.
> 
> Stackalytics team.
> 
> [1] https://www.stackalytics.com/cncf?project_type=kubernetes
> [2]
> https://github.com/openstack/stackalytics/blob/master/etc/default_data.json
> [3] https://github.com/stackalytics/default_data
> [4]
> https://review.openstack.org/#/q/project:openstack/stackalytics+status:open
> [5] https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation
> 
> -- 
> Best Regards,
> Sergey Nikitin


From melwittt at gmail.com  Fri Apr 19 21:38:26 2019
From: melwittt at gmail.com (melanie witt)
Date: Fri, 19 Apr 2019 14:38:26 -0700
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <f6fea7852b361e5d6b9ea062bb41f248@acmac.uoc.gr>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <BA4D4BF3-1FFB-41F4-9E09-A18480EE64C3@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
 <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
 <fa6b66c9-1893-67b9-11f5-78c64b6776fe@gmail.com>
 <f6fea7852b361e5d6b9ea062bb41f248@acmac.uoc.gr>
Message-ID: <dad08583-2aaa-580c-089f-2a013aaa09b6@gmail.com>

On Sat, 20 Apr 2019 00:17:38 +0300, Georgios Dimitrakakis 
<giorgis at acmac.uoc.gr> wrote:
>> On Fri, 19 Apr 2019 22:47:23 +0300, Georgios Dimitrakakis
>> <giorgis at acmac.uoc.gr> wrote:
>>>    Hello again and apologies for my absence!
>>> First of all let me express my gratitude for your valuable feedback.
>>>    I understand what all of you are saying and I will try what Sean
>>>    suggested by setting the values for CPUs and Disk to something
>>> beyond
>>>    the default.
>>> Meanwhile what I 've though was to change the "weight_classes"
>>>    parameter to use only the "RAM" weight instead of all, since
>>> initially
>>>    this is what I would like to be based and then move on from there.
>>>    Unfortunately I haven't found a way to properly set it and no
>>> matter
>>>    what I 've tried I always ended up with an error in
>>> nova-scheduler.log
>>>    saying "ERROR nova ValueError: Empty module name"
>>> Any ideas on how to set it based on the available weights? It seems
>>>    that it needs a list format but how?
>>
>> Did you try:
>>
>> weight_classes = ['nova.scheduler.weights.ram.RAMWeigher']
>>
>> That's what should work, based on the code I see here:
>>
>>
>> https://github.com/openstack/nova/blob/stable/rocky/nova/loadables.py#L98
>>
>> -melanie
> 
>   I 'll try that ASAP and get back to you. I believe I have failed to
>   properly use CAPS letters.
> 
>   Meanwhile, what I 've done is that by using Sean's suggestions about
>   RAM, CPU and Disk like below:
> 
>   ram_weight_multiplier=-1.0
>   cpu_weight_multiplier=-1.0
>   disk_weight_multiplier=0.001
> 
>   I have managed to stack VMs on one node.
>   VM stacking with the above is working correctly as long as no IOPS are
>   involved because when they do weights are messed and VMs spread. But I
>   assume that this can be dealt by playing with "io_ops_weight_multiplier"
>   value.
> 
>   So far so good if there wasn't for the following huge problem which is
>   that stacking never stops even when resources are exceeded.
> 
>   To explain what I mean I will give you an introduction of my hardware.
>   My Compute Node has 1x Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8 core
>   or 16 threads and 32GB of RAM.
> 
>   Furthermore on nova.conf I have set:
> 
>   cpu_allocation_ratio=1.0
>   ram_allocation_ratio=1.0
> 
>   With the above settings I have been able to stack on this node 20 VMs
>   with 2vCPUs each and 2GB of RAM. See the following excerpt (when
>   spawning the 20th VM) from the scheduler log:
> 
> 
>   2019-04-19 23:26:42.322 379112 DEBUG nova.scheduler.filter_scheduler
>   [req-73ddffc1-8cd2-4060-bd4c-786ba00793d1
>   6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>   default default] Weighed [WeighedHost [host: (cpu2, cpu2) ram: -6759MB
>   disk: 1536000MB io_ops: 0 instances: 19, weight: 0.000805585392052],
>   WeighedHost [host: (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0
>   instances: 0, weight: -1.999]] _get_sorted_hosts
>   /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
> 
> 
>   To me is very clear that the aforementioned ratio settings are ignored
>   and haven't tried what the limit would be (the final number of VMs that
>   can be spawned).
> 
> 
>   Additionally I did try to perform this again but this time I set the
>   following:
> 
>   enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter
> 
> 
>   This time only 15 VMs went to one compute node because on the 16th
>   attempt the RAMFilter returned just one node (see log below):
> 
>   2019-04-19 23:59:34.170 383851 DEBUG nova.filters
>   [req-9cdd3c15-5bd8-4e06-bf0b-eb2d4d26d66d
>   6a4c2e32919e4a6fa5c5d956beb68eef 9f22e9bfa7974e14871d58bbb62242b2 -
>   default default] Filter RamFilter returned 1 host(s)
>   get_filtered_objects
>   /usr/lib/python2.7/site-packages/nova/filters.py:104
> 
> 
>   Melanie told me earlier on this thread that setting "enabled_filters"
>   shouldn't make any difference but it is obvious from the above behavior
>   that this is not the case.
> 
>   In any case this is not a correct behavior since 15VMs x 2vCPUs/VM =
>   30vCPUs which is almost double the available 16cores, don't forget that
>   I have ratio 1:1 for both CPU and RAM.
> 
>   Does it seem logical to you?

I agree it sounds like your overcommit settings are not being honored. 
Placement will filter hosts taking overcommit into account, and if it 
doesn't have the values you set, then it will return more hosts than the 
RamFilter would filter, causing the difference in behavior.

To debug this further, you need to start looking at what values 
placement has for the allocation ratios. You can do this by installing 
the osc-placement plugin [1] for the openstackclient. Once installed, 
you can do 'openstack resource provider inventory list <compute host 
UUID>' to see what allocation ratios are being used on a given compute 
host. If they're not 1.0, that would explain why it's returning too many 
hosts. If that's the case, next step would be trying to figure out why 
the values you're setting in nova.conf on the compute host (I assume you 
made sure to restart nova-compute after setting) are not being 
transferred to placement like they should be.

-melanie

[1] https://docs.openstack.org/osc-placement/rocky/cli
> 
> 
> 
> 
> 
> 
>>
>>>> On Wed, 2019-04-17 at 18:24 -0700, melanie witt wrote:
>>>>> On Thu, 18 Apr 2019 01:38:17 +0100, Sean Mooney
>>>>> <smooney at redhat.com>
>>>>> wrote:
>>>>>> On Wed, 2019-04-17 at 15:30 -0700, melanie witt wrote:
>>>>>>> On Thu, 18 Apr 2019 01:13:42 +0300, Georgios Dimitrakakis
>>>>>>> <giorgis at acmac.uoc.gr> wrote:
>>>>>>>> Shouldn’t that be the correct behavior and place the new VM on
>>>>> the host with the smaller weight? Isn’t that what
>>>>>>>> the
>>>>>>>> negative value for “ram_weight_multiplier” does ?
>>>>>>>
>>>>>>> No, it's the opposite, higher weights win. That's why you have
>>>>> to use a
>>>>>>> negative value for ram_weight_multiplier if you want hosts with
>>>>> _less_
>>>>>>> RAM to win over hosts with more RAM (stacking).
>>>>>>>
>>>>>>>> Please let me know how I can provide to you more debug
>>>>> info....
>>>>>>>
>>>>>>> One thing I noticed from your log is on the second request,
>>>>> 'cpu1' has
>>>>>>> io_ops: 0 whereas 'cpu2' has io_ops: 1 and the IoOpsWeigher [1]
>>>>> will
>>>>>>> prefer hosts with fewer io_iops by default. Note that's only one
>>>>> piece
>>>>>>> of the ending weight -- the weighing process will take a sum of
>>>>> all of
>>>>>>> the weights each weigher returns. So the weight returned from
>>>>> RamWeigher
>>>>>>> is added to the weight returned from IoOpsWeigher is added the
>>>>> weight
>>>>>>> returned from CPUWeigher, and so on.
>>>>>>>
>>>>>>> So, as Matt said, we're a bit in the dark now as far as what
>>>>> each
>>>>>>> weigher is returning and we don't currently have debug logging
>>>>> per
>>>>>>> weigher the way we do for filters. That would be an enhancement
>>>>> we could
>>>>>>> make to aid in debugging issues like this one. You could hack
>>>>> something
>>>>>>> up locally to log/print the returned weight in each weight class
>>>>> under
>>>>>>> the nova/scheduler/weights/ directory, if you want to dig into
>>>>> that.
>>>>>>>
>>>>>>> Another thing I noticed is that there are probably some new
>>>>> weighers
>>>>>>> available by default that did not exist in the previous version
>>>>> of nova
>>>>>>> that you were using in the past. By default, the config option
>>>>> for weighers:
>>>>>>>
>>>>>>> [filter_scheduler]weight_classes =
>>>>> ["nova.scheduler.weights.all_weighers"]
>>>>>>>
>>>>>>> will pick up all weigher classes in the nova/scheduler/weights/
>>>>> code
>>>>>>> directory. You might take a look at these and see if any are
>>>>> ones you
>>>>>>> should exclude in your environment. For example, the CPUWeigher
>>>>> [1] (new
>>>>>>> in Rocky) will spread VMs based on available CPU by default.
>>>>>>
>>>>>> most of the weighers spread by default so the cpu weigher may be
>>>>>> a
>>>>> factor but
>>>>>> the the disk weigher tends to all hevily impact the choice.
>>>>>>
>>>>>> we do not normalise any of the values retured by the different
>>>>> weighers
>>>>>> the disk wighter is basically  host_state.free_disk_mb *
>>>>> disk_weight_multiplier
>>>>>
>>>>> Hm, I thought we do based on this code:
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/openstack/nova/blob/stable/rocky/nova/weights.py#L135
>>>>>
>>>>> which normalizes the weight to a value between 0.0 and 1.0.
>>>> yes we do but that is witnin the same resouce type.
>>>>
>>>> we do not normalise between resoucser types.
>>>> on a typical host you will have between 2GB and 8GB of ram per cpu
>>>> core
>>>> and you will have between 10G and 100G of local disk typically.
>>>>
>>>> so we dont look at the capasity of each resouce and renomalise
>>>> between them.
>>>> if you want achive that you have to carefully tweek the weights to
>>>> do
>>>> that manually.
>>>>
>>>> that said i have not sat down and worked out the math to do that in
>>>> about 3-4 years
>>>> but i think i used to run my dev clouster with the
>>>> disk_weight_multiplier around 0.04
>>>> and i think i used to set the ram_weight_multiplier to 2.0
>>>>
>>>> anyway that is just my personal experience and i was trying to
>>>> tweek
>>>> the spreading behavior
>>>> to spread based on ram then cpus then disk rather then pack based
>>>> on
>>>> ram but spread based on the rest.
>>>> so i dont know if this is relvent or correct for this usecase.
>>>>
>>>>>
>>>>> If the multiplier is large though, that could make the considered
>>>>> value
>>>>>    > 1.0 (as is the case with the default
>>>>> build_failure_weight_multiplier:
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/openstack/nova/blob/stable/rocky/nova/conf/scheduler.py#L501
>>>>>
>>>>> -melanie
>>>>>
>>>>>> althoer host_state.free_disk_mb is actully disk_available_least.
>>>>>>
>>>>>> as a result the disk filter will weigh cpu1 19456 height then
>>>>>> cpu2
>>>>>> the dela between the cpu1 and cpu2 based on the ram weigher is
>>>>> only 2048
>>>>>>
>>>>>> if you want the ram filter to take presedence over teh disk
>>>>>> filter
>>>>> you will
>>>>>> need to scale the disk filter down to be in a similar value range
>>>>>>
>>>>>> i woudl suggest setting disk_weight_multiplier=0.001
>>>>>>
>>>>>>> This
>>>>>>> weigher might be contributing to the VM spreading you're seeing.
>>>>> You
>>>>>>> might try playing with the '[filter_scheduler]weight_classes'
>>>>> config
>>>>>>> option to select only the weighers you want or alternatively you
>>>>> could
>>>>>>> set the weighers multipliers the way you prefer.
>>>>>>>
>>>>>>> -melanie
>>>>>>>
>>>>>>> [1]
>>>>>
>>>>> https://docs.openstack.org/nova/rocky/user/filter-scheduler.html#weights
>>>>>>>
>>>>>>>>>> On 4/17/2019 3:50 PM, Georgios Dimitrakakis wrote:
>>>>>>>>>> And here is the new log where spawning of 2 VMs can be
>>>>> seen with a few seconds of difference:
>>>>>>>>>> https://pastebin.com/Xy2FL2KL
>>>>>>>>>> Initially both hosts are of weight 1.0 then the one with
>>>>> one VM already running has negative weight but the
>>>>>>>>>> new
>>>>>>>>>> VM is placed on the other host.
>>>>>>>>>> Really-really strange why this is happening...
>>>>>>>>>
>>>>>>>>> < 2019-04-17 23:26:18.770 157355 DEBUG
>>>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>>>> 377b3d37bff9
>>>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Filtered
>>>>> [(cpu2,
>>>>> cpu2)
>>>>>>>>> ram:
>>>>>>>>> 30105MB disk: 1887232MB io_ops: 1 instances: 1, (cpu1, cpu1)
>>>>> ram: 32153MB disk: 1906688MB io_ops: 0 instances:
>>>>>>>>> 0]
>>>>>>>>> _get_sorted_hosts
>>>>>
>>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:435
>>>>>>>>>
>>>>>>>>> < 2019-04-17 23:26:18.771 157355 DEBUG
>>>>> nova.scheduler.filter_scheduler [req-14c666e4-3ff4-4d88-947e-
>>>>>>>>> 377b3d37bff9
>>>>>>>>> 6a4c2e32919e4a6fa5c5d956beb68eef
>>>>> 9f22e9bfa7974e14871d58bbb62242b2 - default default] Weighed
>>>>> [WeighedHost
>>>>>>>>> [host:
>>>>>>>>> (cpu1, cpu1) ram: 32153MB disk: 1906688MB io_ops: 0
>>>>> instances: 0, weight: 1.0], WeighedHost [host: (cpu2,
>>>>>>>>> cpu2)
>>>>>>>>> ram: 30105MB disk: 1887232MB io_ops: 1 instances: 1, weight:
>>>>> -0.00900862553213]] _get_sorted_hosts
>>>>>>>>>
>>>>>
>>>>> /usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py:454
>>>>>>>>>
>>>>>>>>> cpu1 is definitely getting weighed higher but I'm not sure
>>>>> why. We likely need some debug logging on the
>>>>>>>>> result of
>>>>>>>>> each weigher like we have for each filter to figure out
>>>>> what's going on with the weighers.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>






From natal at redhat.com  Fri Apr 19 22:15:52 2019
From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=)
Date: Sat, 20 Apr 2019 00:15:52 +0200
Subject: https://review.openstack.org is down?
In-Reply-To: <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>
References: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
 <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>
Message-ID: <CAF+jc3Vu9Z7qPNffMUBhYmLXZGuBhpKx9DEOdZ3Y6FemipY+HA@mail.gmail.com>

On Fri, Apr 19, 2019 at 5:32 PM Marios Andreou <marios at redhat.com> wrote:
> o/ Hi Arkady see http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005268.html
Just a quick question, do you have any idea of the time that going
take? It's still down at the moment.


From cboylan at sapwetik.org  Fri Apr 19 22:20:28 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Fri, 19 Apr 2019 18:20:28 -0400
Subject: https://review.openstack.org is down?
In-Reply-To: <CAF+jc3Vu9Z7qPNffMUBhYmLXZGuBhpKx9DEOdZ3Y6FemipY+HA@mail.gmail.com>
References: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
 <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>
 <CAF+jc3Vu9Z7qPNffMUBhYmLXZGuBhpKx9DEOdZ3Y6FemipY+HA@mail.gmail.com>
Message-ID: <cf1cfa43-bea4-4eac-b22b-8334b0b388f4@www.fastmail.com>

On Fri, Apr 19, 2019, at 3:16 PM, Natal Ngétal wrote:
> On Fri, Apr 19, 2019 at 5:32 PM Marios Andreou <marios at redhat.com> wrote:
> > o/ Hi Arkady see http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005268.html
> Just a quick question, do you have any idea of the time that going
> take? It's still down at the moment.
> 
>

We are still in the process of safely bringing it up. We unfortunately ran into a few gitea bugs around redirection (and we promised everyone working redirection) that took some time to figure out. We are about to bring it up without external access so that it can replicate then we can run config management to convert the server from review.openstack.org to review.opendev.org (also with redirects).

Once we are satisfied with that we will need to restart gerrit one last time then it should be up and running.

Clark



From iain.macdonnell at oracle.com  Fri Apr 19 22:20:44 2019
From: iain.macdonnell at oracle.com (iain.macdonnell at oracle.com)
Date: Fri, 19 Apr 2019 15:20:44 -0700
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
Message-ID: <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>


Today I discovered that this problem appears to be caused by eventlet 
monkey-patching. I've created a bug for it:

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

     ~iain



On 4/18/19 11:27 PM, iain.macdonnell at oracle.com wrote:
> 
> Hi Damien,
> 
> Thanks for the response! This definitely sounds similar enough that it 
> has to be the same root problem.
> 
> I didn't make too much progress today. Whilst using strace to try to 
> compare Rocky and Stein, I noticed that TCP connections seem to be 
> handled somewhat differently. This applies to mysql as well as AMQP. In 
> the Rocky case, I see repeated fcntl() calls to F_SETFL O_RDWR between 
> sendto() and recvfrom():
> 
> 
> [pid 32427] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 19
> [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> [pid 32427] connect(19, {sa_family=AF_INET, sin_port=htons(3306), 
> sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in 
> progress)
> [pid 32427] poll([{fd=19, events=POLLOUT}], 1, 10000) = 1 ([{fd=19, 
> revents=POLLOUT}])
> [pid 32427] getsockopt(19, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> [pid 32427] setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> [pid 32427] fcntl(19, F_GETFL)          = 0x802 (flags O_RDWR|O_NONBLOCK)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> [pid 32427] setsockopt(19, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> [pid 32427] recvfrom(19, 
> "J\0\0\0\n5.7.25\0\f\r\0\0#\4;;\n)\0309\0\377\377\10\2\0\377\301"..., 
> 8192, 0, NULL, NULL) = 78
> [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> [pid 32427] sendto(19, 
> "\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
> 150, 0, NULL, 0) = 150
> [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> [pid 32427] recvfrom(19, ",\0\0\2\376mysql_native_password\0#\4;;\n"..., 
> 8192, 0, NULL, NULL) = 48
> 
> 
> whereas in the Stein case, I see recvfrom() calls that get EAGAIN, 
> followed by epoll before a successful recvfrom():
> 
> [pid 17895] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 28
> [pid 17895] fcntl(28, F_GETFL)          = 0x2 (flags O_RDWR)
> [pid 17895] fcntl(28, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> [pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306), 
> sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in 
> progress)
> [pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28, 
> {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}}) = 0
> [pid 17895] epoll_wait(26, [{EPOLLOUT, {u32=28, 
> u64=6398156018563416092}}], 1023, 1992) = 1
> [pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f7440) = 0
> [pid 17895] getsockopt(28, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> [pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306), 
> sin_addr=inet_addr("10.241.154.33")}, 16) = 0
> [pid 17895] setsockopt(28, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> [pid 17895] setsockopt(28, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> [pid 17895] recvfrom(28, 
> "J\0\0\0\n5.7.25\0(!\0\0\10w@\v-~)D\0\377\377\10\2\0\377\301"..., 8192, 
> 0, NULL, NULL) = 78
> [pid 17895] sendto(28, 
> "\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
> 150, 0, NULL, 0) = 150
> [pid 17895] recvfrom(28, 0x7fb5d401e340, 8192, 0, NULL, NULL) = -1 
> EAGAIN (Resource temporarily unavailable)
> [pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28, 
> {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}}) 
> = 0
> [pid 17895] epoll_wait(26, [{EPOLLIN, {u32=28, 
> u64=6398156018563416092}}], 1023, 1991) = 1
> [pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f6530) = 0
> [pid 17895] recvfrom(28, 
> ",\0\0\2\376mysql_native_password\0\10w@\v-"..., 8192, 0, NULL, NULL) = 48
> 
> 
> Not sure if this is related to the problem or not, but it's what jumped 
> out first, and I wasn't able to figure out what's causing the change in 
> behaviour before I ran out of enthusiasm today.
> 
> Please let me know if you discover anything further or/and if there are 
> any discussions (IRC?) that I should be participating in .. although I'm 
> guessing that that's happening during the EU work day.
> 
> Thanks!
> 
>      ~iain
> 
> 
> 
> 
> 
> On 4/18/19 12:48 AM, Damien Ciabrini wrote:
>>
>>
>> On Thu, Apr 18, 2019 at 7:51 AM <iain.macdonnell at oracle.com 
>> <mailto:iain.macdonnell at oracle.com>> wrote:
>>
>>
>>     Is anyone running Stein nova-api under uWSGI? I'm trying to do 
>> this, in
>>     exactly the same way as I did with Rocky, but encountering a new
>>     problem...
>>
>>
>> This sounds similar to a problem that we're currently debugging with John
>> Eckersberg and Michele Baldessari (in CC) in Stein, but when nova-api 
>> runs
>> under Apache mod_wsgi.
>>
>> The symptoms for us seem similar: sometimes the scheduling of the AMQP
>> heartbeat greenlet seems heratic (no run for 75 seconds), RabbitMQ
>> drops the connection to the client during this idle period, and next time
>> nova-api needs to communicate over AMQP it logs a "connection reset
>> by peer" and reestablish a new connection.
>>
>> This is fresh news from yesterday so this is still to be 
>> confirmed/disproved;
>> but currently we're investigating how eventlet schedules recurring tasks
>> such as the AMQP heartbeat greenlet under Apache mod_wsgi's execution
>> model.
>>
>> Once the AMQP heartbeat greenlet has sent its heartbeat, it sleeps for a
>> fixed amount of time; i.e. it suspends its execution, eventlet 
>> registers a timer
>> for this greenlet, and continues scheduling other greenlets. Once the 
>> timer
>> expires, eventlet marks the heartbeat greenlet as "eligible for 
>> scheduling"
>> and eventually this greenlet resumes its execution.
>> For that mechanism to work, eventlet regularly watches for all the timers
>> that are registered in its event loop (with select/epoll/whatnot).
>>
>> Now, Apache mod_wsgi embeds its own Python interpreter, and calls it
>> whenever there's an API call to process. It seems that - the precise 
>> course
>> of event is unclear to me yet - once the API call is processed, the 
>> Python
>> Interpreter returns a result to mod_wsgi and stops its execution even if
>> some timers were still registered in eventlet.
>>
>> The state of the Python Interpreter is conserved though, and next time
>> mod_wsgi receives an API call, it resumes the execution of the Python
>> Interpreter: eventlet resumes its execution and process every timer
>> that were registered previously. So ultimately, the AMQP heartbeat
>> greenlet is rescheduled, but that might be a long time already since the
>> last AMQP heartbeat.
>>
>> So I have the feeling that when there's no traffic, mod_wsgi doesn't 
>> execute
>> the Python interpreter, which prevents eventlet from running, watching 
>> for
>> timers, and triggering the AMQP heartbeat greenlet. So far, the evidences
>> in favour of this theory are:
>>    . When there's no traffic for nova-api running under mod_wsgi, and 
>> I use
>>      gdb to dump the call stack of the mod_wsgi process, I see no CPython
>>      interpreter in the stack. Whereas when there's traffic, I see 
>> many CPython
>>      stack frames.
>>    . When there's no traffic to nova-api and the AMQP heartbeat 
>> greenlet seem
>>      to be unscheduled for a long time, running a simple 'nova list' 
>> command
>>      seems to unblock everything and trigger a AMQP heartbeat.
>>
>> This would also explain why running the nova-api service in standalone 
>> works
>> just fine as you said. because the Python interpreter is never stopped 
>> in this
>> execution model.
>>
>> I'm still trying to figure out when the Python interpreter returns to 
>> mod_wsgi
>> to make sure what I'm saying makes sense. And I also need to double check
>> that running in standalone works fine for me as well.
>>
>>     The symptom is intermittent failure of API operations that involve 
>> RPC
>>     calls - notably getting the noVNC console URL for an instance. The
>>     nova-api log shows RPC timeouts and "connection reset by peer" for
>>     AMQP.
>>     I've ruled out environmental issues, as a Rocky installation on the
>>     same
>>     hosts works fine. With oslo debug enabled, I see that the first API
>>     call
>>     causes a AMQP connections to be established, and the RPC call gets 
>> its
>>     reply, and all is well... but there are no heartbeats logged after
>>     that.
>>     3 minutes later, rabbitmq-server reports that it has received no
>>     heartbeats, and drops the connection. On a subsequent API call 
>> (but not
>>     before), nova-api logging "connection reset by peer" and the RPC call
>>     times out. With the Rocky code, once the first API call causes the 
>> AMQP
>>     connections to be established, regular heartbeats start happening, 
>> the
>>     connections are maintained, and subsequent API calls work as 
>> expected.
>>
>>     It seems like a lockup in a thread that's supposed to maintain the 
>> AMQP
>>     connection, or something. I tried to use SIGUSR2 to trigger guru
>>     meditation, but it seems that uWSGI has its own interpretation of
>>     SIGUSR2, so nova-api never sees it (anyone know a way around this?).
>>
>>     Running nova-api as a standalone service, instead of under uWSGI, the
>>     problem does not occur (I see the heartbeats, and everything works
>>     fine).
>>
>>     I've tried updating oslo-messaging (and python-amqp) on a Rocky
>>     installation to the Stein version, but the problem does not 
>> reproduce.
>>
>>     Ideas?
>>
>>           ~iain
>>
>>
>>
>>
>>
>> -- 
>> Damien
> 


From amodi at redhat.com  Fri Apr 19 22:33:43 2019
From: amodi at redhat.com (Archit Modi)
Date: Fri, 19 Apr 2019 18:33:43 -0400
Subject: https://review.openstack.org is down?
In-Reply-To: <cf1cfa43-bea4-4eac-b22b-8334b0b388f4@www.fastmail.com>
References: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
 <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>
 <CAF+jc3Vu9Z7qPNffMUBhYmLXZGuBhpKx9DEOdZ3Y6FemipY+HA@mail.gmail.com>
 <cf1cfa43-bea4-4eac-b22b-8334b0b388f4@www.fastmail.com>
Message-ID: <CANnpN_2N-Fzx0QsdsKpi76a+0gxW4K2ERpz3-gF5Y-fjn+Yp+g@mail.gmail.com>

Thanks Clark, can you please let us know as soon its back online :)

-Archit

On Fri, Apr 19, 2019 at 6:23 PM Clark Boylan <cboylan at sapwetik.org> wrote:

> On Fri, Apr 19, 2019, at 3:16 PM, Natal Ngétal wrote:
> > On Fri, Apr 19, 2019 at 5:32 PM Marios Andreou <marios at redhat.com>
> wrote:
> > > o/ Hi Arkady see
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005268.html
> > Just a quick question, do you have any idea of the time that going
> > take? It's still down at the moment.
> >
> >
>
> We are still in the process of safely bringing it up. We unfortunately ran
> into a few gitea bugs around redirection (and we promised everyone working
> redirection) that took some time to figure out. We are about to bring it up
> without external access so that it can replicate then we can run config
> management to convert the server from review.openstack.org to
> review.opendev.org (also with redirects).
>
> Once we are satisfied with that we will need to restart gerrit one last
> time then it should be up and running.
>
> Clark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/36687a97/attachment.html>

From colleen at gazlene.net  Fri Apr 19 23:10:36 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 19 Apr 2019 19:10:36 -0400
Subject: [dev][keystone] Keystone Team Update - Week of 15 April 2019
Message-ID: <eae661b6-9c01-4e5b-96ab-ea2657f9b00e@www.fastmail.com>

# Keystone Team Update - Week of 15 April 2019

## News

This week has been mostly about Forum and PTG preparation. Please review the PTG agenda[1] and come prepared to discuss the proposed topics. According to the team dinner poll[2] it looks like Wednesday is the best day for us to go out as a team, so I will find somewhere to make a reservation for the ~8 of us.

[1] https://etherpad.openstack.org/p/keystone-train-ptg
[2] https://framadate.org/BHNNU9S3f9N3lasH

## Open Specs

Train specs: https://bit.ly/2uZ2tRl

Ongoing specs: https://bit.ly/2OyDLTh

I would like to start prioritizing and committing to these specs soon after the PTG so please review the proposals and/or prepare and update your own proposals for this cycle. If a spec is proposed under ongoing/ but it should be completed this cycle, please repropose it under train/.

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

Gerrit is under maintenance right now so I don't have stats at the moment ;)

## Changes that need Attention

Search query: https://bit.ly/2tymTje

Same here.

## Bugs

This week we opened 2 new bugs and closed none. At first glance the two new bugs appear to be issues with the new Stein packages on Ubuntu.

Bug #1825111 (keystone:Undecided) opened by Robert Holling https://bugs.launchpad.net/keystone/+bug/1825111 
Bug #1825214 (keystone:Undecided) opened by Joseph Beale https://bugs.launchpad.net/keystone/+bug/1825214 

## Milestone Outlook

https://releases.openstack.org/train/schedule.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter


From amodi at redhat.com  Sat Apr 20 03:32:25 2019
From: amodi at redhat.com (Archit Modi)
Date: Fri, 19 Apr 2019 23:32:25 -0400
Subject: https://review.openstack.org is down?
In-Reply-To: <CANnpN_2N-Fzx0QsdsKpi76a+0gxW4K2ERpz3-gF5Y-fjn+Yp+g@mail.gmail.com>
References: <f809af449d5e4a1d973175aec6335752@AUSX13MPS308.AMER.DELL.COM>
 <CAM51kHUG4=uzM248_1GB_UFYxh6axTbRH3ns_qaU_3djx597tw@mail.gmail.com>
 <CAF+jc3Vu9Z7qPNffMUBhYmLXZGuBhpKx9DEOdZ3Y6FemipY+HA@mail.gmail.com>
 <cf1cfa43-bea4-4eac-b22b-8334b0b388f4@www.fastmail.com>
 <CANnpN_2N-Fzx0QsdsKpi76a+0gxW4K2ERpz3-gF5Y-fjn+Yp+g@mail.gmail.com>
Message-ID: <CANnpN_3jF1enfDDZYQ35V-NJEr991qk3VUGnGuCe7r9VnXjy4g@mail.gmail.com>

I can see its back online now :)

On Fri, Apr 19, 2019 at 6:33 PM Archit Modi <amodi at redhat.com> wrote:

> Thanks Clark, can you please let us know as soon its back online :)
>
> -Archit
>
> On Fri, Apr 19, 2019 at 6:23 PM Clark Boylan <cboylan at sapwetik.org> wrote:
>
>> On Fri, Apr 19, 2019, at 3:16 PM, Natal Ngétal wrote:
>> > On Fri, Apr 19, 2019 at 5:32 PM Marios Andreou <marios at redhat.com>
>> wrote:
>> > > o/ Hi Arkady see
>> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005268.html
>> > Just a quick question, do you have any idea of the time that going
>> > take? It's still down at the moment.
>> >
>> >
>>
>> We are still in the process of safely bringing it up. We unfortunately
>> ran into a few gitea bugs around redirection (and we promised everyone
>> working redirection) that took some time to figure out. We are about to
>> bring it up without external access so that it can replicate then we can
>> run config management to convert the server from review.openstack.org to
>> review.opendev.org (also with redirects).
>>
>> Once we are satisfied with that we will need to restart gerrit one last
>> time then it should be up and running.
>>
>> Clark
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190419/46d511d8/attachment.html>

From cboylan at sapwetik.org  Sat Apr 20 04:09:29 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sat, 20 Apr 2019 00:09:29 -0400
Subject: Migrating git repos to OpenDev
In-Reply-To: <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
Message-ID: <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>

On Tue, Apr 16, 2019, at 5:13 PM, Clark Boylan wrote:
> 
> The infra/OpenDev team continues to make good progress towards this 
> transition and plans to perform the transition on April 19, 2019 as 
> previously scheduled.  We will begin the transition at 15:00UTC and 
> users should plan for intermittent Gerrit and git repo outages through 
> the day. We expect most of those will be closer to 15:00UTC than 
> 23:00UTC.
> 
> Fungi has generated a master list of project renames for the openstack 
> namespaces: http://paste.openstack.org/show/749402/. If you have a 
> moment please quickly review these planned renames for any obvious 
> errors or issues.
> 
> For the airship, starlingx, and zuul repo renames the repositories 
> listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org were 
> used placing repos in airship/, starlingx/ and zuul/ namespaces. Any 
> repo name prefix (like stx- and airship-) is dropped.
> 

Hello everyone!

The Infra team, no, OpenDev Infra team, has completed the initial work to migrate to a more flexible git hosting platform. Gerrit is now hosted at review.opendev.org (with redirects from review.openstack.org in place). Our git mirroring has transitioned from git.openstack.org, git.airshipit.org, git.starlingx.io, and git.zuul-ci.org to http(s)://opendev.org. We have put in place redirects from these old domains to the new domain. If you see James Blair at the summit and appreciate these redirects: buy him a beverage.

As part of this transition we've also moved git repos around. Airship, Zuul, OpenDev, StarlingX and others now have their own top level "orgs" which we hope cuts down on confusion over what is or isn't part of a certain project. You will likely want to update your git remotes to the new canonical locations (where ever you get redirected to using the old urls) in the near future.

For unofficial projects that were hosted under openstack/ the OpenStack TC decided to move them out into a different org (namespace). The chosen namespace was x/ because it is short and doesn't convey any particular meaning. In time we can continue to use more meaningful namespaces, but for now I think we want to stabilize after the recent moves.

The Zuul tenant configs report no errors (Jeremy Stanley gets the beverages for this); however, that does not mean all jobs will be happy. We will be around to help work people through job failures related to this migration. Please reach out and we'll go from there.

On the infrastructure side of things we will also need to work to get our continuous deployment running again. This was a bit of an inception move for us as we do all our work through Gerrit and we had to take Gerrit down and "move" it.

Finally thank you all for your patience today and thank you to everyone that helped make this possible.

Clark


From michele at acksyn.org  Sat Apr 20 06:38:50 2019
From: michele at acksyn.org (Michele Baldessari)
Date: Sat, 20 Apr 2019 08:38:50 +0200
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
Message-ID: <20190420063850.GA18527@holtby.speedport.ip>

On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
> 
> Today I discovered that this problem appears to be caused by eventlet
> monkey-patching. I've created a bug for it:
> 
> https://bugs.launchpad.net/nova/+bug/1825584

Hi,

just for completeness we see this very same issue also with
mistral (actually it was the first service where we noticed the missed
heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
although I have not personally observed it there yet.

cheers,
Michele

> 
>     ~iain
> 
> 
> 
> On 4/18/19 11:27 PM, iain.macdonnell at oracle.com wrote:
> > 
> > Hi Damien,
> > 
> > Thanks for the response! This definitely sounds similar enough that it
> > has to be the same root problem.
> > 
> > I didn't make too much progress today. Whilst using strace to try to
> > compare Rocky and Stein, I noticed that TCP connections seem to be
> > handled somewhat differently. This applies to mysql as well as AMQP. In
> > the Rocky case, I see repeated fcntl() calls to F_SETFL O_RDWR between
> > sendto() and recvfrom():
> > 
> > 
> > [pid 32427] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 19
> > [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > [pid 32427] connect(19, {sa_family=AF_INET, sin_port=htons(3306),
> > sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in
> > progress)
> > [pid 32427] poll([{fd=19, events=POLLOUT}], 1, 10000) = 1 ([{fd=19,
> > revents=POLLOUT}])
> > [pid 32427] getsockopt(19, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> > [pid 32427] setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > [pid 32427] fcntl(19, F_GETFL)          = 0x802 (flags O_RDWR|O_NONBLOCK)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> > [pid 32427] setsockopt(19, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> > [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> > [pid 32427] recvfrom(19,
> > "J\0\0\0\n5.7.25\0\f\r\0\0#\4;;\n)\0309\0\377\377\10\2\0\377\301"...,
> > 8192, 0, NULL, NULL) = 78
> > [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> > [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> > [pid 32427] sendto(19, "\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> > 150, 0, NULL, 0) = 150
> > [pid 32427] fcntl(19, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 32427] fcntl(19, F_SETFL, O_RDWR)  = 0
> > [pid 32427] recvfrom(19, ",\0\0\2\376mysql_native_password\0#\4;;\n"...,
> > 8192, 0, NULL, NULL) = 48
> > 
> > 
> > whereas in the Stein case, I see recvfrom() calls that get EAGAIN,
> > followed by epoll before a successful recvfrom():
> > 
> > [pid 17895] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 28
> > [pid 17895] fcntl(28, F_GETFL)          = 0x2 (flags O_RDWR)
> > [pid 17895] fcntl(28, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> > [pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306),
> > sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in
> > progress)
> > [pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28,
> > {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}}) = 0
> > [pid 17895] epoll_wait(26, [{EPOLLOUT, {u32=28,
> > u64=6398156018563416092}}], 1023, 1992) = 1
> > [pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f7440) = 0
> > [pid 17895] getsockopt(28, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> > [pid 17895] connect(28, {sa_family=AF_INET, sin_port=htons(3306),
> > sin_addr=inet_addr("10.241.154.33")}, 16) = 0
> > [pid 17895] setsockopt(28, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > [pid 17895] setsockopt(28, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> > [pid 17895] recvfrom(28,
> > "J\0\0\0\n5.7.25\0(!\0\0\10w@\v-~)D\0\377\377\10\2\0\377\301"..., 8192,
> > 0, NULL, NULL) = 78
> > [pid 17895] sendto(28, "\222\0\0\1\17\242:\0\377\377\377\0!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> > 150, 0, NULL, 0) = 150
> > [pid 17895] recvfrom(28, 0x7fb5d401e340, 8192, 0, NULL, NULL) = -1
> > EAGAIN (Resource temporarily unavailable)
> > [pid 17895] epoll_ctl(26, EPOLL_CTL_ADD, 28,
> > {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=28, u64=6398156018563416092}})
> > = 0
> > [pid 17895] epoll_wait(26, [{EPOLLIN, {u32=28,
> > u64=6398156018563416092}}], 1023, 1991) = 1
> > [pid 17895] epoll_ctl(26, EPOLL_CTL_DEL, 28, 0x7fb5ed1f6530) = 0
> > [pid 17895] recvfrom(28,
> > ",\0\0\2\376mysql_native_password\0\10w@\v-"..., 8192, 0, NULL, NULL) =
> > 48
> > 
> > 
> > Not sure if this is related to the problem or not, but it's what jumped
> > out first, and I wasn't able to figure out what's causing the change in
> > behaviour before I ran out of enthusiasm today.
> > 
> > Please let me know if you discover anything further or/and if there are
> > any discussions (IRC?) that I should be participating in .. although I'm
> > guessing that that's happening during the EU work day.
> > 
> > Thanks!
> > 
> >      ~iain
> > 
> > 
> > 
> > 
> > 
> > On 4/18/19 12:48 AM, Damien Ciabrini wrote:
> > > 
> > > 
> > > On Thu, Apr 18, 2019 at 7:51 AM <iain.macdonnell at oracle.com
> > > <mailto:iain.macdonnell at oracle.com>> wrote:
> > > 
> > > 
> > >     Is anyone running Stein nova-api under uWSGI? I'm trying to do
> > > this, in
> > >     exactly the same way as I did with Rocky, but encountering a new
> > >     problem...
> > > 
> > > 
> > > This sounds similar to a problem that we're currently debugging with John
> > > Eckersberg and Michele Baldessari (in CC) in Stein, but when
> > > nova-api runs
> > > under Apache mod_wsgi.
> > > 
> > > The symptoms for us seem similar: sometimes the scheduling of the AMQP
> > > heartbeat greenlet seems heratic (no run for 75 seconds), RabbitMQ
> > > drops the connection to the client during this idle period, and next time
> > > nova-api needs to communicate over AMQP it logs a "connection reset
> > > by peer" and reestablish a new connection.
> > > 
> > > This is fresh news from yesterday so this is still to be
> > > confirmed/disproved;
> > > but currently we're investigating how eventlet schedules recurring tasks
> > > such as the AMQP heartbeat greenlet under Apache mod_wsgi's execution
> > > model.
> > > 
> > > Once the AMQP heartbeat greenlet has sent its heartbeat, it sleeps for a
> > > fixed amount of time; i.e. it suspends its execution, eventlet
> > > registers a timer
> > > for this greenlet, and continues scheduling other greenlets. Once
> > > the timer
> > > expires, eventlet marks the heartbeat greenlet as "eligible for
> > > scheduling"
> > > and eventually this greenlet resumes its execution.
> > > For that mechanism to work, eventlet regularly watches for all the timers
> > > that are registered in its event loop (with select/epoll/whatnot).
> > > 
> > > Now, Apache mod_wsgi embeds its own Python interpreter, and calls it
> > > whenever there's an API call to process. It seems that - the precise
> > > course
> > > of event is unclear to me yet - once the API call is processed, the
> > > Python
> > > Interpreter returns a result to mod_wsgi and stops its execution even if
> > > some timers were still registered in eventlet.
> > > 
> > > The state of the Python Interpreter is conserved though, and next time
> > > mod_wsgi receives an API call, it resumes the execution of the Python
> > > Interpreter: eventlet resumes its execution and process every timer
> > > that were registered previously. So ultimately, the AMQP heartbeat
> > > greenlet is rescheduled, but that might be a long time already since the
> > > last AMQP heartbeat.
> > > 
> > > So I have the feeling that when there's no traffic, mod_wsgi doesn't
> > > execute
> > > the Python interpreter, which prevents eventlet from running,
> > > watching for
> > > timers, and triggering the AMQP heartbeat greenlet. So far, the evidences
> > > in favour of this theory are:
> > >    . When there's no traffic for nova-api running under mod_wsgi,
> > > and I use
> > >      gdb to dump the call stack of the mod_wsgi process, I see no CPython
> > >      interpreter in the stack. Whereas when there's traffic, I see
> > > many CPython
> > >      stack frames.
> > >    . When there's no traffic to nova-api and the AMQP heartbeat
> > > greenlet seem
> > >      to be unscheduled for a long time, running a simple 'nova list'
> > > command
> > >      seems to unblock everything and trigger a AMQP heartbeat.
> > > 
> > > This would also explain why running the nova-api service in
> > > standalone works
> > > just fine as you said. because the Python interpreter is never
> > > stopped in this
> > > execution model.
> > > 
> > > I'm still trying to figure out when the Python interpreter returns
> > > to mod_wsgi
> > > to make sure what I'm saying makes sense. And I also need to double check
> > > that running in standalone works fine for me as well.
> > > 
> > >     The symptom is intermittent failure of API operations that
> > > involve RPC
> > >     calls - notably getting the noVNC console URL for an instance. The
> > >     nova-api log shows RPC timeouts and "connection reset by peer" for
> > >     AMQP.
> > >     I've ruled out environmental issues, as a Rocky installation on the
> > >     same
> > >     hosts works fine. With oslo debug enabled, I see that the first API
> > >     call
> > >     causes a AMQP connections to be established, and the RPC call
> > > gets its
> > >     reply, and all is well... but there are no heartbeats logged after
> > >     that.
> > >     3 minutes later, rabbitmq-server reports that it has received no
> > >     heartbeats, and drops the connection. On a subsequent API call
> > > (but not
> > >     before), nova-api logging "connection reset by peer" and the RPC call
> > >     times out. With the Rocky code, once the first API call causes
> > > the AMQP
> > >     connections to be established, regular heartbeats start
> > > happening, the
> > >     connections are maintained, and subsequent API calls work as
> > > expected.
> > > 
> > >     It seems like a lockup in a thread that's supposed to maintain
> > > the AMQP
> > >     connection, or something. I tried to use SIGUSR2 to trigger guru
> > >     meditation, but it seems that uWSGI has its own interpretation of
> > >     SIGUSR2, so nova-api never sees it (anyone know a way around this?).
> > > 
> > >     Running nova-api as a standalone service, instead of under uWSGI, the
> > >     problem does not occur (I see the heartbeats, and everything works
> > >     fine).
> > > 
> > >     I've tried updating oslo-messaging (and python-amqp) on a Rocky
> > >     installation to the Stein version, but the problem does not
> > > reproduce.
> > > 
> > >     Ideas?
> > > 
> > >           ~iain
> > > 
> > > 
> > > 
> > > 
> > > 
> > > -- 
> > > Damien
> > 
> 

-- 
Michele Baldessari            <michele at acksyn.org>
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D


From skaplons at redhat.com  Sat Apr 20 07:21:31 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Sat, 20 Apr 2019 09:21:31 +0200
Subject: [Neutron][TripleO] Avoid dangling sidecars containers - add hook
 support
In-Reply-To: <19517c9e-c198-a4d9-abf9-b3a078beb044@redhat.com>
References: <19517c9e-c198-a4d9-abf9-b3a078beb044@redhat.com>
Message-ID: <D76BF5D2-A50D-49AD-A985-8AD5A619F001@redhat.com>

Hi,

IMO this is good idea and You should propose it as RFE on lauchpad.
It can also help address our current issue with including python process in rootwrap kill filters as it would be maybe not necessary anymore.
Also, from quick look I think that external_process.ProcessMonitor is ready for something like that as it has possibility to pass „get_stop_command” callback as an argument - see [1]. So maybe it would be not very hard to implement :)

[1] https://github.com/openstack/neutron/blob/master/neutron/agent/linux/external_process.py#L98

> Wiadomość napisana przez Cédric Jeanneret <cjeanner at redhat.com> w dniu 17.04.2019, o godz. 13:09:
> 
> Dear List,
> 
> While doing some validations on an "in-use" node, we detected a
> container being Exited with status 137. After some researches and
> discussions, it appears this container is launched from a Neutron
> container, as a sidecar, and then the service is killed:
> 
> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/external_process.py#L98
> 
> While the "kill" is fine outside of a container, it leads to some issues
> in a containerized world:
> - dangling container is here, with a failed state
> - validating container state is therefore complicated
> - might lead to false assumption if we don't know that "kill" process
> - might lead to disk space issues
> 
> In order to sort that bad situation out, and prevent disk space issues
> and the like, I propose to discuss about some "hook" addition in that
> "external_process.py" (or wherever is more suited for that usage)
> 
> There is apparently something like that for the service launch, since
> there are wrapper scripts in /var/lib/neutron.
> In my idea, that wrapper script could generate a new wrapper used in
> order to actually delete the container (instead of kill -9 <pid>).
> 
> The neutron code could be modified in a simple way, something like:
> ###############
> if os.path.exists(<wrapper-file>):
>  utils.execute(['bash', <wrapper-file>])
> else:
> # current way to handle things
> ###############
> 
> The <wrapper-file> might have "something" in its name in order to ensure
> we're actually killing the right process/container.
> self.pid, or maybe some specific string that neutron is aware of... you
> get the idea.
> 
> Even outside of a container, that might be used in order to clean
> temporary configurations/files, and ensure we're actually facing a clean
> environment.
> It's really something more like "hooks" than "container-centric thingy"
> 
> Would you consider that kind of new feature?
> 
> Thank you for your time and consideration!
> 
> Cheers,
> 
> C.
> 
> -- 
> Cédric Jeanneret
> Software Engineer
> DFG:DF
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From vladimir.blando at gmail.com  Sat Apr 20 08:02:44 2019
From: vladimir.blando at gmail.com (vladimir franciz blando)
Date: Sat, 20 Apr 2019 16:02:44 +0800
Subject: [kolla] Instance unable to contact outside network
Message-ID: <CALZCvAoHxhnLJ8xpCzC_j3PTms0gO9rBXj6hAN_MrigsJuQ+tQ@mail.gmail.com>

Hi All,

Deploying an OpenStack Rocky (1 controller+ceph, 1 compute+ceph)
environment on Packet.net  using kolla-ansible 7.1.0.  Everything works
except Instance connectivity going out.

controller1 network http://paste.openstack.org/show/749565/
compute1 network http://paste.openstack.org/show/749566/
openvswitch show http://paste.openstack.org/show/749567/

1. Instance to Instance PING  via it's private IP = success
2. Instance to Instance PING via floating IP = success
3. Instance to gateway ping = success
4. Instance to outside world (ex. 8.8.8.8 or google.com) = failed
5. PINGing the instance from the controller node using the floating IP =
failed

Here is my global.yml file
http://paste.openstack.org/show/lpAGgrEm8rNe43WeB8Uo/
Here is my multinode file
http://paste.openstack.org/show/DL7l1WG2xotH5KziwuyL/
Here is my init-runounce file http://paste.openstack.org/show/749568/

- Vlad
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190420/16add598/attachment.html>

From hongbin034 at gmail.com  Sat Apr 20 15:54:49 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Sat, 20 Apr 2019 11:54:49 -0400
Subject: [qa][zun][kuryr][k8s]
In-Reply-To: <5fcb1c08b3349eaaa897cf4b775e01f06f7a2ef5.camel@redhat.com>
References: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>
 <5fcb1c08b3349eaaa897cf4b775e01f06f7a2ef5.camel@redhat.com>
Message-ID: <CAFNUc+R5HMkRLC2YYPzOf5Nz6XwuPbGpxXyKVg5EHyU_K5KqFA@mail.gmail.com>

On Fri, Apr 19, 2019 at 6:59 AM Michał Dulko <mdulko at redhat.com> wrote:

> On Thu, 2019-04-18 at 23:54 -0400, Hongbin Lu wrote:
> > Hi all,
> >
> > Right now, we have a devstack plugin [1] to install container engine
> (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and
> under the governance of QA team.
> >
> > I am working on a patch [2] to enable k8s installation via devstack. Zun
> needs this feature to setup the CI for the virtual kubelet provider, and I
> heard Kuryr also interest to leverage it.
> >
> > The original idea is to incorporate k8s installation into
> devstack-plugin-container, so that we can avoid the overhead to bootstrap
> and maintain a separated plugin. However, the feedback I received so far
> gave preference to a separated plugin for k8s, so I sent out this email to
> collect more opinions.
> >
> > Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse
> the existing container plugin for this purpose?
>
> I looked through the proposed code again and I think I'll soften my
> stance here. If we'll keep the code in a separated file and do not mix
> the settings of two too much (note that some dependency is necessary -
> we do that in kuryr-kubernetes DevStack plugin in regards to e.g.
> CONTAINER_ENGINE), then we should be easily able to extract it in the
> future if needed. My only concern is that if any future OpenStack
> project wanted to deploy K8s on its DevStack, devstack-plugin-container
> would certainly not be first place they would look at.
>
> Anyway let's just start with something and see where it carries us.
> It'll definitely need a lot of work to develop the plugin to the point
> it could be used by kuryr-kubernetes, so it's just a start.
>

Sure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190420/60b3e794/attachment.html>

From gmann at ghanshyammann.com  Sat Apr 20 16:12:25 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Sat, 20 Apr 2019 11:12:25 -0500
Subject: [qa][zun][kuryr][k8s]
In-Reply-To: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>
References: <CAFNUc+RwridY-Mcbk4a1ifEa8qpKCVX=3d9gnPn0jQKDqs-eJQ@mail.gmail.com>
Message-ID: <16a3b85320c.d877c2bb114008.2493604200832186795@ghanshyammann.com>

 ---- On Thu, 18 Apr 2019 22:54:14 -0500 Hongbin Lu <hongbin034 at gmail.com> wrote ----
 > Hi all,
 > Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team.
 > I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it.
 > The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions.
 > Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose?
 > [1] https://github.com/openstack/devstack-plugin-container[2] https://review.openstack.org/#/c/646018/

I agree on this, it makes more sense to keep it in existing 'devstack-plugin-container' plugin. As you mentioned clearly in your patch about
'how to enable the k8s' and what is default is enough for the user to use it in either way. 

-gmann

 > Best regards,Hongbin 



From cboylan at sapwetik.org  Sat Apr 20 18:09:07 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sat, 20 Apr 2019 14:09:07 -0400
Subject: Post OpenDev Repo Migration Issues
Message-ID: <18186ef5-2e6e-406e-9e24-d240486463b3@www.fastmail.com>

Hello,

There are two quick things we want to point out that we've noticed after the OpenDev Gerrit manuevers.

First, any commit Depends-On footers for unmerged changes will need to use https://review.opendev.org urls instead of https://review.openstack.org urls. This is due to a limitation in Zuul and how it sees the Gerrit server. Any Depends-On footers that  use https://review.openstack.org are currently non-functional and they will not enforce the dependency relationship.

Second, while we have fairly robust http(s) redirects in place for old urls (including those from cgit to gitea) any ssh repo urls will need to be updated to use the new canonical paths if a repo has moved. We are unable to redirect incoming ssh requests against Gerrit. If you need to know what the canonical path is go to the corresponding https repo url and the resulting destination is the canonical location.

Again thank you for your patience,
Clark


From smooney at redhat.com  Sat Apr 20 19:35:27 2019
From: smooney at redhat.com (Sean Mooney)
Date: Sat, 20 Apr 2019 20:35:27 +0100
Subject: The python black project.
In-Reply-To: <6c3cd375-81b4-01cc-f146-9271c139db8e@gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <6c3cd375-81b4-01cc-f146-9271c139db8e@gmail.com>
Message-ID: <750bce385aa3a8b3febd424532aa12c88b0f25fd.camel@redhat.com>

On Fri, 2019-04-19 at 08:35 -0500, Matt Riedemann wrote:
> On 4/18/2019 3:51 AM, Natal Ngétal wrote:
> > Black is project to format Python code. It's more and more used by the python
> > community. That can save time and harmonize the code. For example, simple quote
> > versus double quote, that was not checked by pep8.i It's just an example of
> > what make  black With a pre-hook commit hook this will be also avoid to lose
> > time with pep8 errors.
> > 
> > Two links to see more:
> > 
> > https://github.com/ambv/black
> > https://www.mattlayman.com/blog/2018/python-code-black/
> > 
> > I think it can be very interesting to start to use Black on OpenStack. What
> > do you thinks about that? For example, we can introduce it on some projects, I
> > would volunteer to try on TripleO.
> 
> I'd be a -2 on this if proposed for nova. Screwing up git blame in a 
> 10-year old project is a non-starter for me, not to mention the issues 
> it would cause for backporting fixes to stable branch (which is already 
> hard enough given the rate of change we have in the project). Drive by 
> contributors might not care about that kind of thing but as a maintainer 
> of the project it's pretty critical to me.
> 
> I also can't buy the argument made elsewhere in this thread that this is 
> an issue turning away new contributors. Are there any new contributors 
> that can really stand up here and say they are leaving openstack 
> development because of code style/formatting inconsistencies? If this is 
> really an issue about reviewers -1ing changes for code style, then let's 
> call out those reviewers specifically and have a talk with them about 
> what is and isn't appropriate for a -1 on a review in openstack. We've 
> had these same nit pick review flame wars so may times over the years, 
> isn't there anything better for people to be worried about? How about 
> the gate burning down every few weeks? We don't have to care about code 
> style if we can't merge the beautifully auto-formatted code anyway.
so i tried using black over the last two days hacking on a personal project
and after trying it out my personal feeling on the topic have changed.
in comparison to lanagues such as c# c++ and go where indention is not
important at the lanague level the usefulness of black is severly limited by
the fact we use indentation instead of braces to denote scope.

in c++ i can write something totally unreadable but vaild like this

void dostuff ( int i){/* this is a function that returns the invocation of an inline lambda*/ return [&](){ return "this
is a string form a lambda";}(); }

and ill get back something that looks like this when i press ctrl+shift+i

LLVM style (my prefeffred style for c++)

void dostuff(int i) { /* this is a function that returns the invocation of an
                         inline lambda*/
  return [&]() { return "this is a string form a lambda"; }();
}

FILE style (this looks more like java to me or c)

void dostuff(int i)
{ /* this is a function that returns the invocation of an
     inline lambda*/
    return [&]()
    {
   
     return "this is a string form a lambda";
    }();
}


when i was using black however i kept typeing stuff that is valid python and
it just did not fix it at all and gave no warnings. so i found my self still having
to think about indention at which point it was more or less just simpeler to fix it myeslf.

so i think tools like autopep8 that dont really mess with formating but just fix pep8 violations and
nothing else are actully more uesful then black. im going to continue
to try it a bit more form my own stuff but honestly i ended up coming 180 on this topic after useing
it an i dont think it will help fix my personal issue with pep8 so i dont think it will add value
that can compensate for the negitive impacts on the git history.

> 



From mnaser at vexxhost.com  Sat Apr 20 21:09:25 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Sat, 20 Apr 2019 17:09:25 -0400
Subject: [tc] project-update exception for 654057
Message-ID: <CAEs876ieKGeApMyAn8CocbkQKq4KCFW3=4yjTv1vHagRsqo4fQ@mail.gmail.com>

Hi everyone:

As chair, I'm making an exception to the usual timeline for the
project-update housekeeping rules for change #654057 based on the
following reasons:

- This has no governing change, the only change is pointing to the
correct deliverable repository as part of this.
- The reasonable possible objection is the prefix/rename of a
repository, however, this is already done.  If there is any concerns
about any specific renames, we can work with infra. to rename them and
update the projects.yaml afterwards.
- This helps unblock the (hard working) infrastructure team at
cleaning up their work.  It is impacting our openstack/openstack
submodules repo.

If anyone has any objects, you're free to propose a full (or partial)
revert with your concerns.

Have a good weekend!

Regards,
Mohammed

-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From mriedemos at gmail.com  Sat Apr 20 22:17:41 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Sat, 20 Apr 2019 17:17:41 -0500
Subject: [nova][scheduler] - Stack VMs based on RAM
In-Reply-To: <dad08583-2aaa-580c-089f-2a013aaa09b6@gmail.com>
References: <65a1cb30238e58e88fd2850098c30de5@acmac.uoc.gr>
 <565df5d2-343e-2dc3-87cf-518d8bc98bab@gmail.com>
 <7d9b8e24-0601-1430-9c68-983a104fe007@gmail.com>
 <a4ba2afcce14a947efed8c384facdd34@acmac.uoc.gr>
 <5f0dae14-c734-0525-e90c-c93cdaa0f38a@gmail.com>
 <ecc5deb07e87ec11138b01851e5c4561@acmac.uoc.gr>
 <df1f2d9d-d1f3-d7f8-c97a-cf4defc4e298@gmail.com>
 <c6b00f23-9ff5-0975-e5cb-a700c04d6439@gmail.com>
 <aea6f1b082e8b555dd81037e3e5957ee@acmac.uoc.gr>
 <d84f412a-127c-6d06-1c02-216418b2372b@gmail.com>
 <BA7F4BEC-4438-4934-BDAC-A7D7BC9BE012@acmac.uoc.gr>
 <a600d7e2-45bc-5dcc-4b2d-c5db9042ed89@gmail.com>
 <081da7c606d35ac3e1fa2bab270adbd303a109d8.camel@redhat.com>
 <35ff34c8-cf12-79db-51ca-b98e5416568d@gmail.com>
 <e0e4d5adb4fb24baadda55809e0e710fb088e7c6.camel@redhat.com>
 <eec4e53fde87674c80cf55cf7ef5242a@acmac.uoc.gr>
 <fa6b66c9-1893-67b9-11f5-78c64b6776fe@gmail.com>
 <f6fea7852b361e5d6b9ea062bb41f248@acmac.uoc.gr>
 <dad08583-2aaa-580c-089f-2a013aaa09b6@gmail.com>
Message-ID: <3e368539-a793-5d05-3241-f0fa335e9291@gmail.com>

On 4/19/2019 4:38 PM, melanie witt wrote:
> I agree it sounds like your overcommit settings are not being honored. 
> Placement will filter hosts taking overcommit into account, and if it 
> doesn't have the values you set, then it will return more hosts than the 
> RamFilter would filter, causing the difference in behavior.
> 
> To debug this further, you need to start looking at what values 
> placement has for the allocation ratios. You can do this by installing 
> the osc-placement plugin [1] for the openstackclient. Once installed, 
> you can do 'openstack resource provider inventory list <compute host 
> UUID>' to see what allocation ratios are being used on a given compute 
> host. If they're not 1.0, that would explain why it's returning too many 
> hosts. If that's the case, next step would be trying to figure out why 
> the values you're setting in nova.conf on the compute host (I assume you 
> made sure to restart nova-compute after setting) are not being 
> transferred to placement like they should be.

Some more background on how placement is involved here:

https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#allocation-ratios

https://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/initial-allocation-ratios.html

-- 

Thanks,

Matt


From mriedemos at gmail.com  Sat Apr 20 22:30:35 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Sat, 20 Apr 2019 17:30:35 -0500
Subject: Post OpenDev Repo Migration Issues
In-Reply-To: <18186ef5-2e6e-406e-9e24-d240486463b3@www.fastmail.com>
References: <18186ef5-2e6e-406e-9e24-d240486463b3@www.fastmail.com>
Message-ID: <ef6d97a1-d63e-b9f4-8bd3-8930a0471cec@gmail.com>

On 4/20/2019 1:09 PM, Clark Boylan wrote:
> First, any commit Depends-On footers for unmerged changes will need to usehttps://review.opendev.org  urls instead ofhttps://review.openstack.org  urls. This is due to a limitation in Zuul and how it sees the Gerrit server. Any Depends-On footers that  usehttps://review.openstack.org  are currently non-functional and they will not enforce the dependency relationship.

How about Depends-On with a change id, is that still OK?

-- 

Thanks,

Matt


From cboylan at sapwetik.org  Sat Apr 20 22:39:15 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sat, 20 Apr 2019 18:39:15 -0400
Subject: Post OpenDev Repo Migration Issues
In-Reply-To: <ef6d97a1-d63e-b9f4-8bd3-8930a0471cec@gmail.com>
References: <18186ef5-2e6e-406e-9e24-d240486463b3@www.fastmail.com>
 <ef6d97a1-d63e-b9f4-8bd3-8930a0471cec@gmail.com>
Message-ID: <bd795f72-9d69-4ff2-9b3a-548e95926524@www.fastmail.com>

On Sat, Apr 20, 2019, at 3:30 PM, Matt Riedemann wrote:
> On 4/20/2019 1:09 PM, Clark Boylan wrote:
> > First, any commit Depends-On footers for unmerged changes will need to usehttps://review.opendev.org  urls instead ofhttps://review.openstack.org  urls. This is due to a limitation in Zuul and how it sees the Gerrit server. Any Depends-On footers that  usehttps://review.openstack.org  are currently non-functional and they will not enforce the dependency relationship.
> 
> How about Depends-On with a change id, is that still OK?

Yes, Depends-On with a change id are ok.

Clark


From priyankasangtani at gmail.com  Sun Apr 21 14:47:07 2019
From: priyankasangtani at gmail.com (Priyanka Sangtani)
Date: Sun, 21 Apr 2019 10:47:07 -0400
Subject: [dev] Queries regarding migration through Openstack
Message-ID: <CAJ5T=n-d4+CHG4SEKCZa7Ue1_s+9YhL80y-HLD1ZYZkDfvnthg@mail.gmail.com>

Hi All,

I'm currently working on a project which requires me to understand the live
migration and cold migration process in Openstack.

I have the following questions:

1. In case of live migration with shared storage, how is the current
downtime set through update_downtime used? Like when does it know that it
needs to pause the VM on the source and perform the stop and copy phase?
It would be great if you could point me to the code base where this is
happening. Is this handled by QEMU?

2. In case of cold migrate, how does it select the destination host? As per
the code, I saw that it generates a sorted list of hosts based on filtering
and weighing but then we also perform randomization. I'm confused as to how
this works.

Thank you so much for your time.

Regards,
Priyanka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190421/12c5ec52/attachment.html>

From jaypipes at gmail.com  Sun Apr 21 15:16:53 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 11:16:53 -0400
Subject: [placement][nova][ptg] Shared resource providers for shared disk
 on compute hosts
In-Reply-To: <alpine.OSX.2.21.1904101304550.12309@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904101304550.12309@cdent-a01.vmware.com>
Message-ID: <46b9b357-38f1-1ceb-75ea-3910fc71f23a@gmail.com>

On 04/10/2019 08:14 AM, Chris Dent wrote:
> This topic is from the cross project etherpad [1]
> 
> There's a spec in progress for this: 
> https://review.openstack.org/#/c/650188/
> 
> It does a pretty good job of explaining some of the corner cases. We
> need to make sure we have a good awareness of all the corners
> because when we try to do (or even think about) this feature we
> discover a problem that derails the work.
> 
> Which is unfortunate because supporting shared disk is one of the
> principles on which placement was sold. All the necessary
> functionality is already there in placement, so making it work is
> mostly on the nova side, a lot of it in nova-compute. Much of the
> challenge is associated with dealing with move operations.
> 
> A question I posed on the spec is whether it is possible to make
> this happen without having to rely on additional config. It seems
> like something where it would be super nice (but perhaps not
> possible) for a virtdriver to be able to turn on and manage itself.
> 
> So the discussion surrounding this topic is perhaps around:
> 
> * teasing out the dark corners as much as possible so we don't
>    stumble again
> 
> * nailing the issues with moves
> 
> * exploring the options for making it as hands-free as possible

I commented on the review. I'm +1 on it, though I do recognize the dark 
corners here. We've tried numerous times to support shared storage and 
every time we seem to revert various patches because of (live) migration 
issues.

Not sure that we will ever get to a point where all the corner cases are 
fully covered, frankly. At some point, the community must decide whether 
they want accurate reporting of disk resources or whether they are happy 
to continue with the inaccurate reporting (when using shared instance 
storage) in order to continue supporting live migration and 
evacuate/rebuild-to-different-host operations' corner cases.

-jay


From whayutin at redhat.com  Sun Apr 21 19:00:54 2019
From: whayutin at redhat.com (Wesley Hayutin)
Date: Sun, 21 Apr 2019 13:00:54 -0600
Subject: Post OpenDev Repo Migration Issues
In-Reply-To: <bd795f72-9d69-4ff2-9b3a-548e95926524@www.fastmail.com>
References: <18186ef5-2e6e-406e-9e24-d240486463b3@www.fastmail.com>
 <ef6d97a1-d63e-b9f4-8bd3-8930a0471cec@gmail.com>
 <bd795f72-9d69-4ff2-9b3a-548e95926524@www.fastmail.com>
Message-ID: <CAOHJT4+kGprj5vBvCsA3Yrt53349-511gM7dwHTHa6SHqXjQOQ@mail.gmail.com>

FYI..
TripleO had a minor issue in a TripleO owned zuul playbook [1].
Just raising attention to it here in case folks from TripleO are looking
for info.
Should be fixed by [2]

Thanks

[1] https://bugs.launchpad.net/tripleo/+bug/1825732
[2] https://review.opendev.org/#/c/654258

On Sat, Apr 20, 2019 at 4:46 PM Clark Boylan <cboylan at sapwetik.org> wrote:

> On Sat, Apr 20, 2019, at 3:30 PM, Matt Riedemann wrote:
> > On 4/20/2019 1:09 PM, Clark Boylan wrote:
> > > First, any commit Depends-On footers for unmerged changes will need to
> usehttps://review.opendev.org  urls instead ofhttps://review.openstack.org
> urls. This is due to a limitation in Zuul and how it sees the Gerrit
> server. Any Depends-On footers that  usehttps://review.openstack.org  are
> currently non-functional and they will not enforce the dependency
> relationship.
> >
> > How about Depends-On with a change id, is that still OK?
>
> Yes, Depends-On with a change id are ok.
>
> Clark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190421/e196cb21/attachment-0001.html>

From jaypipes at gmail.com  Sun Apr 21 22:20:23 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 18:20:23 -0400
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
Message-ID: <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>

On 04/09/2019 09:00 AM, Chris Dent wrote:
>  From the etherpad [1]:
> 
> * Last PTG for Stein, we decided the following policies and have done so 
> in Stein
> 
>      A) Aggregate on root spans whole tree for ``members_of=``
>         requests in 'GET /allocation_candidates'
>      B) This spanning policy doesn't apply to granular requests
>         ``members_of<N>=`` or to requests in 'GET /resource_providers'
>      C) This change is a bug fix without microversion
> 
>    However, I now feel the policy B is weird. Consider a case where
>    only granular requests are used in the request. If operator puts
>    aggA on root, aggA applies the child or not depends on cases how
>    you created the request. That's very difficult for operators to
>    debug...
> 
> This is from Tetsuro, so perhaps he can add some additional info,
> but basically I think what's being requested here is some discussion
> on whether changing B is warranted.

We have a similar issue with traits.

I actually think there should be a single "apply membership or traits 
using self-and-children" policy. I've been unable to think of any use 
case that would *not* be serviced by this policy.

Providers that are matched for a particular request group's resources 
should THEN have any member_of constraints applied to them and their 
children. Same for traits, IMHO.

In other words, the algorithm for matching allocation candidates should 
do the following in order for each request group:

1) Find the provider IDs having capacity for the resources contained in 
the request group
2) If there is a member_of constraint in this request group, reduce the 
matched set to only those providers that are associated (or have any 
children associated) with the aggregates listed in the member_of constraint
3) If there is a required trait constraint in this request group, reduce 
the matched set to only those providers that have the required trait(s) 
or where their children have the required traits
4) If there is a forbidden trait constraint in this request group, 
remove from the matched set any providers that have the forbidden 
trait(s) or where their children have the forbidden traits

Repeat for each request group, applying whatever group_policy=isolate 
constraint when >1 granular request group.

Best,
-jay


From amy at demarco.com  Sun Apr 21 22:48:04 2019
From: amy at demarco.com (Amy Marrich)
Date: Sun, 21 Apr 2019 17:48:04 -0500
Subject: Diversity Events
Message-ID: <CAFs83Qqa52keFXZNOtpig23cDJafora44W3j=cKWFQjye0q=8A@mail.gmail.com>

Summit is a week away and I wanted to point out a few Diversity related
sessions and events taking place.

Thanks,

Amy (spotz)

Monday:
12:20-1:40 - Speed Mentoring Lunch sponsored by Intel - RSVP required
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23757/rsvp-required-speed-mentoring-lunch-sponsored-by-intel

Tuesday:
12:20-1:40 - Diversity Networking Lunch sponsored by IBM - RSVP required
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23756/rsvp-required-diversity-networking-lunch-sponsored-by-ibm
1:40-2:20 - The Results are in for the D&I Survey. This is a first review
of the data collected.
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23692/the-results-are-in-for-the-d-and-i-survey

Wednesday:
10:50-11:30 - Diversity WG BoF - looking for help with the Mentoring Program
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23745/diversity-working-group-bof
11:40-12:20 - Diversity and Inclusion  WG
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23746/diversity-and-inclusion-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190421/bb9b3139/attachment.html>

From jaypipes at gmail.com  Sun Apr 21 23:11:22 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 19:11:22 -0400
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
Message-ID: <7031b112-0bb0-6974-ddbc-b22f472c6558@gmail.com>

On 04/10/2019 10:31 AM, Eric Fried wrote:
>> It is on my TODO list to create a story for it in placement and move
>> the spec to the placement repo. I don't know when I will reach this
>> item on my list, sorry.
> 
> I was getting ready to volunteer (again) to help move the ball on this
> because it's really important that we get this done.
> 
> But then I started thinking, is it really? The workarounds we have in
> the client-side code right now are pretty sucky, but they work. The
> effort of $subject is an optimization and suck-reducer, but is it
> crucial? Probably not. Though I would like to hear from Cyborg before we
> decide we can live without it for Train.
> 
>> When I move the spec I can add the open questions from the nova spec
>> review to the placement spec directly to help continuity. Is that OK?
> 
> WFM.
> 
>> Pinging Cyborg folks. Does Cyborg needs something similar?
> 
> I know for sure this is a yes (somewhere around [6]?), but I won't be
> able to express the details as well as Sundar.
> 
>> I can own the first alternative in the spec [3].
> 
> I'll champion the one I described in the third comment at [4], where we
> add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
> because it's per "allocations" rather than per "allocations.$rp".

After considering the alternatives, this is my preference as well. 
Having a "mappings" key in each element of the "allocation_requests" 
array makes sense to me: We are providing information *about that 
particular allocation request's request group to provider mapping* and 
therefore I feel this is the best location for it to be.

Best,
-jay


From jaypipes at gmail.com  Sun Apr 21 23:27:25 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 19:27:25 -0400
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <alpine.OSX.2.11.1904111156530.33106@seed.local>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
 <alpine.OSX.2.11.1904111156530.33106@seed.local>
Message-ID: <76a8323c-42d1-3aee-ac44-98d6668a091a@gmail.com>

On 04/11/2019 07:38 AM, Chris Dent wrote:
> A moment to riff on one the points of having these conversations in
> the expanse of email:
> 
> To my internal unfettered brain the above sort-of-mess is yet more
> evidence that nested is a nightmare and gosh I wish we had never
> done: it, request groups, provider trees on the nova side, and pretty
> much all the stuff that's in progress related to enhanced platform
> awareness. It makes me squirm, see bad smells everywhere, and
> facepalm multiple times per day.

I share your frustration in many ways.

The many "features" added to Nova around NUMA, virtual guest CPU 
topologies, PCI device management/tuning, realtime support, and the 
proposed integration of RMD et al have each eroded the abstraction that 
Nova originally served as: abstraction layer *above* the hardware and 
hypervisor.

Ironically, the hierarchical and shared resource providers modeling was 
intended to *ensure* and *promote* a structured, consistent, 
easy-to-reason-about model for resource management.

In other words, the whole idea of placement -- including the addition of 
hierachical and shared providers -- was to provide relief from the 
free-for-all Wild West frontier that still exists in the Nova PCI 
manager, hardware.py module, NUMATopologyFilter, and all that. It was 
supposed to provide us a path out of that quagmire.

I take it as a personal failure that we've yet to be able to take 
advantage of the more consistent and structured data model in placement 
for these more "advanced" resource classes :(

The road to hell is paved with good intentions, I guess.

Best,
-jay


From tony at bakeyournoodle.com  Sun Apr 21 23:50:46 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 22 Apr 2019 09:50:46 +1000
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
Message-ID: <20190421235046.GB26225@thor.bakeyournoodle.com>

On Wed, Apr 17, 2019 at 09:51:03AM -0500, Jay Bryant wrote:
> Team,
> 
> I would like to propose Brian Rosmaita for Cinder core.
> 
> His participation in Cinder has been steadily increasing during the Stein
> release.  He attended the mid-cycle meeting in Raleigh and was able to
> provide great insight and input using his experience from Glance.
> 
> His review activity has been consistent during Stein.  He has helped get
> backports to our stable branches and subsequently has ensured that we do
> timely releases of Cinder's components.
> 
> Considering the broad range of activity Brian has demonstrated and his years
> of experience in OpenStack I think he will serve as an excellent addition to
> our core team.
> 
> If I do not hear any concerns with this nomination I will make Brian core on
> 4/24.

I don't really get a vote but if I did it'd be +1 :)

I do get more of a say on stable stuff and I'd endorse Brian be added
to cinder-stable-core at the same time.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/9bdecce2/attachment.sig>

From tony at bakeyournoodle.com  Sun Apr 21 23:53:01 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 22 Apr 2019 09:53:01 +1000
Subject: Call for help! 'U' Release name Mandarin speakers
In-Reply-To: <D8DF7E66.C446C%ekcs.openstack@gmail.com>
References: <20190214021836.GD12795@thor.bakeyournoodle.com>
 <a6fe65e2-358a-a87b-9383-71cad58df6ce@openstack.org>
 <D8DF7E66.C446C%ekcs.openstack@gmail.com>
Message-ID: <20190421235301.GC26225@thor.bakeyournoodle.com>

On Fri, Apr 19, 2019 at 01:40:34PM -0700, Eric K wrote:
> I am a native mandarin speaker. I'm happy to work with Tony in this
> process.

Great!  Are you going to be in Denver?  If so lets start the ball
rolling while we're there

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/076539c5/attachment-0001.sig>

From Arkady.Kanevsky at dell.com  Mon Apr 22 00:34:34 2019
From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com)
Date: Mon, 22 Apr 2019 00:34:34 +0000
Subject: Migrating git repos to OpenDev
In-Reply-To: <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
Message-ID: <75c5dfa5c6cc40d6b41938a8cea63ed3@AUSX13MPS308.AMER.DELL.COM>

Thanks Clark.

-----Original Message-----
From: Clark Boylan <cboylan at sapwetik.org> 
Sent: Friday, April 19, 2019 11:09 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: Migrating git repos to OpenDev


[EXTERNAL EMAIL] 

On Tue, Apr 16, 2019, at 5:13 PM, Clark Boylan wrote:
> 
> The infra/OpenDev team continues to make good progress towards this 
> transition and plans to perform the transition on April 19, 2019 as 
> previously scheduled.  We will begin the transition at 15:00UTC and 
> users should plan for intermittent Gerrit and git repo outages through 
> the day. We expect most of those will be closer to 15:00UTC than 
> 23:00UTC.
> 
> Fungi has generated a master list of project renames for the openstack
> namespaces: http://paste.openstack.org/show/749402/. If you have a 
> moment please quickly review these planned renames for any obvious 
> errors or issues.
> 
> For the airship, starlingx, and zuul repo renames the repositories 
> listed at git.airshipit.org, git.starlingx.io, and git.zuul-ci.org 
> were used placing repos in airship/, starlingx/ and zuul/ namespaces. 
> Any repo name prefix (like stx- and airship-) is dropped.
> 

Hello everyone!

The Infra team, no, OpenDev Infra team, has completed the initial work to migrate to a more flexible git hosting platform. Gerrit is now hosted at review.opendev.org (with redirects from review.openstack.org in place). Our git mirroring has transitioned from git.openstack.org, git.airshipit.org, git.starlingx.io, and git.zuul-ci.org to http(s)://opendev.org. We have put in place redirects from these old domains to the new domain. If you see James Blair at the summit and appreciate these redirects: buy him a beverage.

As part of this transition we've also moved git repos around. Airship, Zuul, OpenDev, StarlingX and others now have their own top level "orgs" which we hope cuts down on confusion over what is or isn't part of a certain project. You will likely want to update your git remotes to the new canonical locations (where ever you get redirected to using the old urls) in the near future.

For unofficial projects that were hosted under openstack/ the OpenStack TC decided to move them out into a different org (namespace). The chosen namespace was x/ because it is short and doesn't convey any particular meaning. In time we can continue to use more meaningful namespaces, but for now I think we want to stabilize after the recent moves.

The Zuul tenant configs report no errors (Jeremy Stanley gets the beverages for this); however, that does not mean all jobs will be happy. We will be around to help work people through job failures related to this migration. Please reach out and we'll go from there.

On the infrastructure side of things we will also need to work to get our continuous deployment running again. This was a bit of an inception move for us as we do all our work through Gerrit and we had to take Gerrit down and "move" it.

Finally thank you all for your patience today and thank you to everyone that helped make this possible.

Clark



From doug at doughellmann.com  Mon Apr 22 00:50:16 2019
From: doug at doughellmann.com (Doug Hellmann)
Date: Sun, 21 Apr 2019 20:50:16 -0400
Subject: Migrating git repos to OpenDev
In-Reply-To: <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
Message-ID: <m2o94y983b.fsf@doughellmann.com>

"Clark Boylan" <cboylan at sapwetik.org> writes:

> Hello everyone!
>
> The Infra team, no, OpenDev Infra team, has completed the initial work
> to migrate to a more flexible git hosting platform. Gerrit is now
> hosted at review.opendev.org (with redirects from review.openstack.org
> in place). Our git mirroring has transitioned from git.openstack.org,
> git.airshipit.org, git.starlingx.io, and git.zuul-ci.org to
> http(s)://opendev.org. We have put in place redirects from these old
> domains to the new domain. If you see James Blair at the summit and
> appreciate these redirects: buy him a beverage.

So does that mean that old git:// URLs in remotes will need to be
updated in local copies? For example, in a local working copy I have
this output:

$ git remote -v
gerrit ssh://doug-hellmann at review.openstack.org:29418/openstack/releases.git (fetch)
gerrit ssh://doug-hellmann at review.openstack.org:29418/openstack/releases.git (push)
origin git://git.openstack.org/openstack/releases (fetch)
origin git://git.openstack.org/openstack/releases (push)

$ git remote update
Fetching origin
fatal: unable to connect to git.openstack.org:
git.openstack.org[0: 23.253.125.17]: errno=No route to host
git.openstack.org[1: 2001:4800:7817:103:be76:4eff:fe04:e3e3]:
errno=Network is unreachable

error: Could not fetch origin
Fetching gerrit
remote: Counting objects: 185, done
remote: Finding sources: 100% (127/127)
remote: Total 127 (delta 75), reused 103 (delta 75)
Receiving objects: 100% (127/127), 54.07 KiB | 1.00 MiB/s, done.
Resolving deltas: 100% (75/75), completed with 33 local objects.
>From ssh://review.openstack.org:29418/openstack/releases
   7f9656b69..b32f07138  master     -> gerrit/master

So the gerrit remote works using review.openstack.org but the origin
remote does not work using git.openstack.org.

If I change the URL for the origin remote to
https://opendev.org/openstack/releases it works fine. Before I do that
in all of my sandboxes, do I need to, or are those old URLs expected to
work?

-- 
Doug


From fungi at yuggoth.org  Mon Apr 22 01:05:04 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 22 Apr 2019 01:05:04 +0000
Subject: Migrating git repos to OpenDev
In-Reply-To: <m2o94y983b.fsf@doughellmann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
Message-ID: <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>

On 2019-04-21 20:50:16 -0400 (-0400), Doug Hellmann wrote:
[...]
> So does that mean that old git:// URLs in remotes will need to be
> updated in local copies?
[...]

Yes, Gitea doesn't support traditional Git protocol, only Git over
HTTP/HTTPS. And even if it had, there's no built-in redirect
functionality with that protocol anyway.

> If I change the URL for the origin remote to
> https://opendev.org/openstack/releases it works fine. Before I do that
> in all of my sandboxes, do I need to, or are those old URLs expected to
> work?

Simply switching the git:// to https:// (or http://) should work,
courtesy of the redirect sites we've built for git.openstack.org and
friends.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/5c3cb59b/attachment.sig>

From tony at bakeyournoodle.com  Mon Apr 22 02:19:50 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 22 Apr 2019 12:19:50 +1000
Subject: Migrating git repos to OpenDev
In-Reply-To: <m2o94y983b.fsf@doughellmann.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
Message-ID: <20190422021949.GD26225@thor.bakeyournoodle.com>

On Sun, Apr 21, 2019 at 08:50:16PM -0400, Doug Hellmann wrote:
> "Clark Boylan" <cboylan at sapwetik.org> writes:
> 
> > Hello everyone!
> >
> > The Infra team, no, OpenDev Infra team, has completed the initial work
> > to migrate to a more flexible git hosting platform. Gerrit is now
> > hosted at review.opendev.org (with redirects from review.openstack.org
> > in place). Our git mirroring has transitioned from git.openstack.org,
> > git.airshipit.org, git.starlingx.io, and git.zuul-ci.org to
> > http(s)://opendev.org. We have put in place redirects from these old
> > domains to the new domain. If you see James Blair at the summit and
> > appreciate these redirects: buy him a beverage.
> 
> So does that mean that old git:// URLs in remotes will need to be
> updated in local copies? For example, in a local working copy I have
> this output:

Yup.  I hit this also.  I wrote:

    https://github.com/tbreeds/opendev-git-update

with the help of OpenDev Infra.

It will workout where the project landed if there was a namespace
change, and switch to using https instead of git for origin urls.  It
avoids the need to re-clone repos.  It also *tries* to do the right
thing for current stable branches.  It meets my needs but isn't quality
software ;P

Pull-requests welcome.

It used stopped part way through so I really recommend grabbing the
current master before you run it.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/77a40884/attachment.sig>

From miguel at mlavalle.com  Mon Apr 22 03:01:30 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Sun, 21 Apr 2019 22:01:30 -0500
Subject: [neutron] Cancelling performance sub-team meeting
Message-ID: <CAEzGLDh8XmuuepBYt-DpTWdk2sT5FSYW-mXoyVi2CqADUQiJWw@mail.gmail.com>

Hi Neutrinos,

Some members of this sub-team are on vacation / holiday on the 22nd.
Besides, we are going to discuss Neutron performance and scalability in
Denver. As a consequence, we will cancel the meeting.

Best regards

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190421/4e4781c5/attachment.html>

From jaypipes at gmail.com  Mon Apr 22 03:07:12 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 23:07:12 -0400
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <DM6PR11MB3180EF7CAB85C01517AF49C2CA2E0@DM6PR11MB3180.namprd11.prod.outlook.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
 <DM6PR11MB3180EF7CAB85C01517AF49C2CA2E0@DM6PR11MB3180.namprd11.prod.outlook.com>
Message-ID: <43163072-dda5-6631-2eb5-35d5f9a9b3ea@gmail.com>

My apologies for the late response, Jason. Comments inline.

On 04/10/2019 11:24 AM, Jason Anderson wrote:
>     On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
>     > On 4/9/19 7:20 PM, Jay Pipes wrote:
>     >> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>     >>>  From ironic perspective there is no issue, but there is a critical
>     >>> question to decide: when Ironic+Placement is used, which of them acts
>     >>> as the final authority? If Ironic, then we need to teach Placement to
>     >>> talk to its Allocation API when allocating a bare metal node. If
>     >>> Placement, then we need to support Allocation API talking to
>     >>> Placement. I suspect the latter is saner, but I'd like to hear more
>     >>> opinions.
>     >>
>     >> Ironic (scheduler?) would request candidates from the placement
>     >> service using the GET /allocation_candidates API. Ironic (scheduler?)
>     >> would then claim the resources on a provider (a baremetal node) by
>     >> calling the POST /allocations API.
>     >
>     > Okay, this matches my expectation.
>     >
>     > My concern will be with Blazar and reservations. If reservations happen
>     > through Placement only, how will ironic know about them? I guess we need
>     > to teach Blazar to talk to Ironic, which in turn will talk to Placement.
> 
>     Hmm. So, here's the problem: placement has no concept of time. [1]
> 
>     Placement only knows about one period of time: now. Placement doesn't
>     have any concept of an allocation or an inventory existing at some
>     point
>     in the future or in the past.
> 
> Just to play devil's advocate... what about changing/adding this? What 
> if Placement did support an inventory having different states depending 
> on time frame requested?

After 3+ years with the placement modeling, I've come to realize it was 
a fundamental mistake to not include a temporal aspect to both the 
inventories and allocations table schemas.

While I would *not* support a schema that had different "states" for an 
inventory depending on the time frame requested, I *do* think that 
adding a claim_time and release_time column to the allocations table and 
a start_time and end_time column to the inventories table would allow 
Placement to fulfill a simple reservation system using the same 
transactional logic it currently uses.

> In my mind this would enable a more ideal division of
> responsibility:
> 
>   * Placement manages the availability of resources and maintains the
>     single source of truth for inventory at a given time.

++

>   * Blazar uses Placement as its default inventory backend. Blazar's
>     main role now is business logic around quota and handling
>     allocation/deallocation when a lease starts/ends.

Yes on Blazar handling the release of resources when the lease ends.

No on Blazar handling the acquisition of resources when the lease starts 
(that would fundamentally be accomplished by Placement if Placement had 
a temporal dimension to its allocations and inventories table schemas).

No on Blazar handling quota. Quota is a giant pain in the behind, 
frankly. Trust me, you want no part of it ;) No matter how many 
"dimensions" of quota slicing and dicing are made available, operators 
will always want to add yet another dimension. If it's not quota 
"classes", then it's different quotas per region, then different quotas 
per AZ, then different quotas per aggregate, and on and on.

Never mind the whole "we confused quotas with rate-limiting" and "here 
is a type of quota that is not consistently measurable" problems...

Anyway, my advice would be leave quotas alone if you can :)

>       o But, Blazar could optionally use a different inventory backend,
>         to allow standalone use (?)

Not sure why you'd want to do this. But, as Dima remarked in another 
sub-thread of this conversation, the question about "which things should 
a standalone service depend on" is a religious debate. (and a debate I 
no longer have the energy to participate in)

>   * Ironic uses Placement as its default inventory backend.
>       o But, Ironic could optionally also manage its own inventory, to
>         allow standalone use (?)
> 
> To further tease out the relationships here, we should think about what 
> makes the most sense for baremetal reservations done via Blazar. Should 
> Blazar always go to Ironic for this, ignoring Nova entirely? Or should 
> it go through Nova if Nova is being used? I believe Blazar still will 
> always have to go through Nova for instance reservations at minimum.

Certainly Blazar will have to go through Nova *in its current 
implementation*, since Blazar currently relies on host aggregates and 
special aggregate and flavor metadata to "reserve" compute nodes.

> Keep in mind that Blazar is designed to integrate with arbitrary 
> external services; currently it has integrations with Neutron (for 
> provisioning Floating IPs as part of a lease), and it could support any 
> number of other resources, like bandwidth on an uplink.

The flexibility for close integration with arbitrary services often 
comes with a high price: complexity and potential code rot.

> Having learned more about Placement's design as a result of these 
> threads, I'm excited about how it could make some things cleaner if it 
> truly could handle the generic inventory management problem that 
> advanced reservations pose.

If you will be in Denver, I'm happy to outline some ideas I had that 
would pave a way for adding a temporal dimension to Placement's database 
schema. I won't be able to implement these ideas, but I'm happy to share 
them with you if you're interested.

Best,
-jay

>     Therefore, Blazar must unfortunately keep all of the temporal state
>     about reservations in its own data store. So, Ironic would actually
>     have
>     to talk to Blazar to create a reservation of some amount of resources
>     and Blazar will need to call Placement to manage the state of resource
>     inventory and allocations over time; as reservations are activated,
>     Blazar will either create or swap allocation records in Placement to
>     consume the Ironic resources for a tenant that made the reservation.
> 
>     Best,
>     -jay
>     ​
>     [1] this was a mistake for which I take full responsibility.
> 
> 
> Cheers,
> /Jason


From jaypipes at gmail.com  Mon Apr 22 03:32:15 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sun, 21 Apr 2019 23:32:15 -0400
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
Message-ID: <3bd5fe3c-6312-2215-966b-84c48a019200@gmail.com>

On 04/09/2019 08:36 AM, Chris Dent wrote:
> Spec: https://review.openstack.org/650476
> 
>  From the commit message:
> 
>      To support NUMA and similar concepts, this proposes the ability
>      to request resources from different providers nested under a
>      common subtree (below the root provider).
> 
> There's much in the feature described by the spec and the surrounding
> context that is frequently a source of contention in the placement
> group, so working through this spec is probably going to require
> some robust discussion. Doing most of that before the PTG will help
> make sure we're not going in circles in person.k
> 
> Some of the areas of potential contention:
> 
> * Adequate for limited but maybe not all use case solutions
> * Strict trait constructionism
> * Evolving the complexity of placement solely for the satisfaction
>    of hardware representation in Nova
> * Inventory-less resource providers
> * Developing new features in placement before existing features are
>    fully used in client services
> * Others?
> 
> I list this not because they are deal breakers or the only thing
> that matters, but because they have presented stumbling blocks in
> the past and we may as well work to address them (or make an
> agreement to punt them until later) otherwise there will be
> lingering dread.
> 
> And, beyond all that squishy stuff, there is the necessary
> discussion over the solution described in the spec. There are
> several alternatives listed in the spec, and a few more in the
> comments. We'd like to figure out the best solution that can
> actually be done in a reasonable amount of time, not the best
> solution in the absolute.

How about making the API something like this?

  GET /allocation_candidates?resources1=PCPU:2,MEMORY_MB:2048\
    &resources2=SRIOV_NET_VF:1\
    &group_resources=2:1

the &group_resources query parameter would indicate the request group 
identifiers to group resources with. For example, group_resources=2:1 
means "the providers of resources in request group '2' should be in the 
same tree as providers of resources in request group '1'"

No traits needed at all and the API call has more imperative clarity, 
since the caller is saying exactly how they expect the placement service 
to group related resources.

For "anti-affinity", just add a ! before the group identifier. For example:

  GET /allocation_candidates?resources1=PCPU:2,MEMORY_MB:2048\
    &resources2=SRIOV_NET_VF:1\
    &group_resources=2:!1

Would mean "the providers of resources in request group '2' should NOT 
be in the same tree as providers of resources in request group '1'"

Best,
-jay

[0] Also, there's a single regex that currently mandates that a request 
group identifier needs to be a number:

https://github.com/openstack/placement/blob/master/placement/lib.py#L30-L32

We could easily change that and allow named identifiers instead of 
numbers so that we could do, for example:

  GET /allocation_candidates?resources_compute=PCPU:2,MEMORY_MB:2048\
    &resources_network=SRIOV_NET_VF:1\
    &group_resources=_compute:_network


From ifatafekn at gmail.com  Mon Apr 22 05:23:18 2019
From: ifatafekn at gmail.com (Ifat Afek)
Date: Mon, 22 Apr 2019 08:23:18 +0300
Subject: [vitrage] The next two IRC meetings are canceled
Message-ID: <CALxdkcw2xEg0SKbNkF++BpPfq+QvVtfJhH=_0CguVCL835j-iQ@mail.gmail.com>

Hi,

The next two IRC meetings are canceled. This week most of Vitrage
contributors are on vacation, and next week we have the summit.

We will meet again on Wednesday, May 8th.

Br,
Ifat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/294b57ff/attachment.html>

From dangtrinhnt at gmail.com  Mon Apr 22 05:46:30 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Mon, 22 Apr 2019 14:46:30 +0900
Subject: [searchlight] Next 2 meetings cancelled
Message-ID: <CADJ6S4GcvgZ5eeXHpRJDYwrW4OBV4noQonPZ2hWMHqW4rvKemw@mail.gmail.com>

Hi team,

We will cancel the next 2 meetings (today and 6 May) to prepare for Denver
summit and vacation after that. I'll be on IRC most of the time so please
ping me there.

Yours,

-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/ed050311/attachment.html>

From haoqf at linux.vnet.ibm.com  Mon Apr 22 05:49:59 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Mon, 22 Apr 2019 13:49:59 +0800
Subject: Where is rpm-packaging spec for openstack placement?
Message-ID: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>

Hi,
I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
Thanks!

-- 
Regards
QingFeng Hao



From haoqf at linux.vnet.ibm.com  Mon Apr 22 05:56:22 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Mon, 22 Apr 2019 13:56:22 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
Message-ID: <b86a1743-7365-af8a-4d13-6b20a9a76e8b@linux.vnet.ibm.com>


Hi,
I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
Thanks!

-- 
Regards
QingFeng Hao



From haoqf at linux.vnet.ibm.com  Mon Apr 22 05:56:22 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Mon, 22 Apr 2019 13:56:22 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
Message-ID: <b86a1743-7365-af8a-4d13-6b20a9a76e8b@linux.vnet.ibm.com>


Hi,
I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
Thanks!

-- 
Regards
QingFeng Hao



From yikunkero at gmail.com  Mon Apr 22 08:35:12 2019
From: yikunkero at gmail.com (Yikun Jiang)
Date: Mon, 22 Apr 2019 16:35:12 +0800
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
Message-ID: <CAArz_dAs5QnkwzM-hhqzzK=_VYBeOtwRNq4KzroL6Sv_bj2D_g@mail.gmail.com>

+1, and thanks for your great work Brian


Jay Bryant <jungleboyj at gmail.com> 于2019年4月17日周三 下午10:57写道：

> Team,
>
> I would like to propose Brian Rosmaita for Cinder core.
>
> His participation in Cinder has been steadily increasing during the
> Stein release.  He attended the mid-cycle meeting in Raleigh and was
> able to provide great insight and input using his experience from Glance.
>
> His review activity has been consistent during Stein.  He has helped get
> backports to our stable branches and subsequently has ensured that we do
> timely releases of Cinder's components.
>
> Considering the broad range of activity Brian has demonstrated and his
> years of experience in OpenStack I think he will serve as an excellent
> addition to our core team.
>
> If I do not hear any concerns with this nomination I will make Brian
> core on 4/24.
>
> Thank you!
>
> Jay
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/f6e05a79/attachment-0001.html>

From haoqf at linux.vnet.ibm.com  Mon Apr 22 10:58:33 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Mon, 22 Apr 2019 18:58:33 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
Message-ID: <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>

I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
hope it can work. thanks!

在 2019/4/22 13:49, QingFeng Hao 写道:
> Hi,
> I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
> but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
> Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
> Thanks!
> 

-- 
Regards
QingFeng Hao



From ykarel at redhat.com  Mon Apr 22 11:38:40 2019
From: ykarel at redhat.com (Yatin Karel)
Date: Mon, 22 Apr 2019 17:08:40 +0530
Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed
In-Reply-To: <CACu=hyshXNSOfesNTwgHPxFwoetHQsSGN=aaD=BsjCEbQijeQg@mail.gmail.com>
References: <E1hH8ad-0001UV-6m@zuul01.openstack.org>
 <CACu=hyshXNSOfesNTwgHPxFwoetHQsSGN=aaD=BsjCEbQijeQg@mail.gmail.com>
Message-ID: <CAPU8nTE9V=WY=tqZ85_bS-zW-4gzhAO-bA-n=okBR96+Jj=nDQ@mail.gmail.com>

On Thu, Apr 18, 2019 at 9:31 PM Emilien Macchi <emilien at redhat.com> wrote:
>
> fixed by https://review.openstack.org/#/c/653796/ and https://review.openstack.org/#/c/653795/
>
so a new puppet-tripleo release(10.4.1) will also be pushed via
openstack/releases, right? we need it to build package:-
https://review.rdoproject.org/r/#/c/20327/

> On Thu, Apr 18, 2019 at 11:04 AM <zuul at openstack.org> wrote:
>>
>> Build failed.
>>
>> - release-openstack-puppet http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/release/release-openstack-puppet/6e769d5/ : POST_FAILURE in 3m 18s
>> - announce-release announce-release : SKIPPED
>>
>> _______________________________________________
>> Release-job-failures mailing list
>> Release-job-failures at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
>
>
> --
> Emilien Macchi


From sean.mcginnis at gmx.com  Mon Apr 22 11:46:59 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 22 Apr 2019 06:46:59 -0500
Subject: [Third Party CI][Cinder] Changes from review.openstack.org to
 review.opedev.org
Message-ID: <20190422114658.GA22166@sm-xps>

Attention operators of third party CI. It may have been easy to miss some of
the changes that have been done last week to migrate from our Gerrit instance
from review.openstack.org to review.opendev.org.

For a lot of things, this should be seamless as there are pretty robust HHTP(s)
redirects in place, making it easy to not even notice right away that things
have changed.

One thing that may impact third party CI operators though, is there is no way
to automatically redirect SSH traffic.

http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005423.html

I think many CI systems SSH in and watch the event stream with something like:

>> ssh -p 24198 review.openstack.org gerrit stream-events

That will now fail with the move to opendev.org. Please make sure your CI
configuration is updated to change that to review.opendev.org to continue to
capture the event stream for triggering job execution.

Thanks!
Sean


From ramishra at redhat.com  Mon Apr 22 12:10:34 2019
From: ramishra at redhat.com (Rabi Mishra)
Date: Mon, 22 Apr 2019 17:40:34 +0530
Subject: [Tripleo][Octavia][OVN] Overcloud deployment Issues with Octavia
Message-ID: <CABJHmF55FWJw4VhrS+oOs8HwYVAJBmD-o+AyGRy_hFmkTnw0fA@mail.gmail.com>

Hi All,

For some Octavia testing with heat, I tried deploying 3+1 node overcloud
with Octavia environment and THT master. As expected, deployment finished
successfully. However, when trying to do some Octavia API calls (ex. list
laodbalancers etc), it was returning (503) Service Unavailable error.
Checking the logs of octavia_api container (though the container was
running), it was in a continous loop.

I have captured some of these issues (as described below) in
https://bugs.launchpad.net/tripleo/+bug/1825146 too. The intent of this
mail is to bring it to the notice of the respective teams and understand
the best possible way to fix these.

1. Incorrect config setting for provider_drivers.

As of
https://github.com/openstack/puppet-tripleo/commit/97c46ca76803fb238279d24544e8aba9c5685632,
we added OVN provider driver support for Octavia. However, the config
option seems to be set incorrectly which resulted in octavia-api failing to
start.

2. ovn_nb_connection not in octavia config

It seems ovn provider driver (part of networking-ovn) connects to ovn nb
database as part of initialization. However, we don't seem to configure
connection string in octavia.conf and it tries to connect to 127.0.0.1 and
fails.

I've already proposed a few patches[1] to fix the above two issues.

3. Missing Octavia Driver Agent

Octavia had added a driver-agent controller process in Stein (for provider
drivers to communicate with the octavia for status and stats update). This
process is expected to be collocated with octavia-api and creates a pair of
unix domain sockets for communication that the drivers use.

We don't seem to have this implemented in THT yet. Is this something
planned and someone working on it?  AFAICT, we can't enable/use the OVN
provider driver without adding this service/container?

Adding support for this in THT also seems little complex and probably can
be done in few different ways. Is there a standard design pattern we use
for these kind of requirements in Tripleo?  If we already have an agreed
plan on how to do it, please ignore below.

I can only think of the few options below.  Probably there are better ones
too:)

a. New OctivaDriverAgent Service.

As the process is expected to be co-llocated with octavia-api to share the
domain sockets (we can share /var/run/octavia from host on both
containers), I'm not sure if this would be a good design though.

b. As a sidecar of octavia_api

Not a new service, but as a sidecar container for octavia-api (started when
api starts, do we've something like this already there for other services?).

Ideas/comments welcome:)

[1]
https://review.opendev.org/#/q/status:open+branch:master+topic:bug/1825146

-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/5f59227f/attachment.html>

From emilien at redhat.com  Mon Apr 22 12:32:40 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Mon, 22 Apr 2019 08:32:40 -0400
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
Message-ID: <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>

On Fri, Apr 19, 2019 at 3:38 PM Matt Riedemann <mriedemos at gmail.com> wrote:
[...]

> So if people from the TripleO and Kolla teams can reply here and clarify
> I can get that back into the etherpad before the Forum session.
>

As far I know, Piotr (in copy) has taken over Lee's work and the plan is to
get it merged after the PTG, before Placement is removed in Nova.
The work is highly prioritized in the our compute team.

Step 1. (after PTG and before it's removed in Nova) Rebase TripleO work,
make it pass CI & reviewed by TripleO Core, land it. Target is Train
Milestone 1.

Step 2. Clean up TripleO and removing old references to Nova Placement
service. Target is Train Milestone 2.

I'll let the compute folks to give more details if needed but I hope it
answers your question.
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/9c8e93a8/attachment.html>

From emilien at redhat.com  Mon Apr 22 12:36:10 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Mon, 22 Apr 2019 08:36:10 -0400
Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed
In-Reply-To: <CAPU8nTE9V=WY=tqZ85_bS-zW-4gzhAO-bA-n=okBR96+Jj=nDQ@mail.gmail.com>
References: <E1hH8ad-0001UV-6m@zuul01.openstack.org>
 <CACu=hyshXNSOfesNTwgHPxFwoetHQsSGN=aaD=BsjCEbQijeQg@mail.gmail.com>
 <CAPU8nTE9V=WY=tqZ85_bS-zW-4gzhAO-bA-n=okBR96+Jj=nDQ@mail.gmail.com>
Message-ID: <CACu=hyuXO7e6GpQc3Om-Zuj4X143THuOZCqg4PeALED4LA2Ufg@mail.gmail.com>

On Mon, Apr 22, 2019 at 7:39 AM Yatin Karel <ykarel at redhat.com> wrote:

> so a new puppet-tripleo release(10.4.1) will also be pushed via
> openstack/releases, right? we need it to build package:-
> https://review.rdoproject.org/r/#/c/20327/
>

Yes, done: https://review.opendev.org/654439
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/939dfe77/attachment-0001.html>

From ed at leafe.com  Mon Apr 22 13:00:54 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 22 Apr 2019 08:00:54 -0500
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
 <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
Message-ID: <57A16D59-2C99-4649-9A5B-865F837A0012@leafe.com>

On Apr 21, 2019, at 5:20 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> On 04/09/2019 09:00 AM, Chris Dent wrote:
>> From the etherpad [1]:
>> * Last PTG for Stein, we decided the following policies and have done so in Stein
>>     A) Aggregate on root spans whole tree for ``members_of=``
>>        requests in 'GET /allocation_candidates'
>>     B) This spanning policy doesn't apply to granular requests
>>        ``members_of<N>=`` or to requests in 'GET /resource_providers'
>>     C) This change is a bug fix without microversion
>>   However, I now feel the policy B is weird. Consider a case where
>>   only granular requests are used in the request. If operator puts
>>   aggA on root, aggA applies the child or not depends on cases how
>>   you created the request. That's very difficult for operators to
>>   debug...
>> This is from Tetsuro, so perhaps he can add some additional info,
>> but basically I think what's being requested here is some discussion
>> on whether changing B is warranted.
> 
> We have a similar issue with traits.
> 
> I actually think there should be a single "apply membership or traits using self-and-children" policy. I've been unable to think of any use case that would *not* be serviced by this policy.

Not only that, but I can’t imagine a scenario where we would want membership of one RP but forbid membership by a child. That would be… strange.



-- Ed Leafe







From ed at leafe.com  Mon Apr 22 13:11:21 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 22 Apr 2019 08:11:21 -0500
Subject: The python black project.
In-Reply-To: <CAF+jc3UYVLbMA_UrdNFnYwhnifHJ92mDV1aFDZG-nZ=o=cynHg@mail.gmail.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <CAK6G-fL=iBQGYQQbz1G9JasfON41O3MuEH0D0tDHksLiCLqOpQ@mail.gmail.com>
 <CAF+jc3UYVLbMA_UrdNFnYwhnifHJ92mDV1aFDZG-nZ=o=cynHg@mail.gmail.com>
Message-ID: <3A2714BC-C9E9-4458-BAA5-9D384EE7A039@leafe.com>

On Apr 19, 2019, at 5:34 AM, Natal Ngétal <natal at redhat.com> wrote:
> 
>> 88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter.
> Sorry but for me is not a good argument. This default behaviour can be
> change easily. I also prefer 79 character per line, pep8 change, but I
> still to continue to prefer 79 character per line. However I can use
> black for my project, because I can change this behaviour.

Black is a strongly opinionated tool. You either buy into its opinions or you don’t.

If you start out assuming that you are going to diverge from the author’s opinions, you really shouldn’t be using the tool.


-- Ed Leafe







From dmellado at redhat.com  Mon Apr 22 13:12:38 2019
From: dmellado at redhat.com (Daniel Mellado)
Date: Mon, 22 Apr 2019 15:12:38 +0200
Subject: [kuryr] No meetings today nor next week
Message-ID: <329d1881-a46c-29fb-9ba3-41c2b54e5415@redhat.com>

Hi Kuryrs,

We're canceling today's meeting due to Easter and next one due to the
Open Infrastructure Summit being held.

Should you need anything feel free to reach out to us at #openstack-kuryr.

Happy Easter!

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x13DDF774E05F5B85.asc
Type: application/pgp-keys
Size: 2208 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/585cbb77/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/585cbb77/attachment.sig>

From jaypipes at gmail.com  Mon Apr 22 13:24:36 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 22 Apr 2019 09:24:36 -0400
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <57A16D59-2C99-4649-9A5B-865F837A0012@leafe.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
 <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
 <57A16D59-2C99-4649-9A5B-865F837A0012@leafe.com>
Message-ID: <a0c4f4bb-d3f3-0a63-68be-76f72928bebe@gmail.com>

On 04/22/2019 09:00 AM, Ed Leafe wrote:
> On Apr 21, 2019, at 5:20 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 04/09/2019 09:00 AM, Chris Dent wrote:
>>>  From the etherpad [1]:
>>> * Last PTG for Stein, we decided the following policies and have done so in Stein
>>>      A) Aggregate on root spans whole tree for ``members_of=``
>>>         requests in 'GET /allocation_candidates'
>>>      B) This spanning policy doesn't apply to granular requests
>>>         ``members_of<N>=`` or to requests in 'GET /resource_providers'
>>>      C) This change is a bug fix without microversion
>>>    However, I now feel the policy B is weird. Consider a case where
>>>    only granular requests are used in the request. If operator puts
>>>    aggA on root, aggA applies the child or not depends on cases how
>>>    you created the request. That's very difficult for operators to
>>>    debug...
>>> This is from Tetsuro, so perhaps he can add some additional info,
>>> but basically I think what's being requested here is some discussion
>>> on whether changing B is warranted.
>>
>> We have a similar issue with traits.
>>
>> I actually think there should be a single "apply membership or traits using self-and-children" policy. I've been unable to think of any use case that would *not* be serviced by this policy.
> 
> Not only that, but I can’t imagine a scenario where we would want membership of one RP but forbid membership by a child. That would be… strange.

Yuup. +100.

-jay


From fungi at yuggoth.org  Mon Apr 22 13:28:01 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 22 Apr 2019 13:28:01 +0000
Subject: [Third Party CI][Cinder] Changes from review.openstack.org to
 review.opedev.org
In-Reply-To: <20190422114658.GA22166@sm-xps>
References: <20190422114658.GA22166@sm-xps>
Message-ID: <20190422132801.qhkaahmzt7bkkjg5@yuggoth.org>

On 2019-04-22 06:46:59 -0500 (-0500), Sean McGinnis wrote:
[...]
> I think many CI systems SSH in and watch the event stream with something like:
> 
> >> ssh -p 24198 review.openstack.org gerrit stream-events
> 
> That will now fail with the move to opendev.org. Please make sure your CI
> configuration is updated to change that to review.opendev.org to continue to
> capture the event stream for triggering job execution.

Any idea why this is failing? While SSH isn't exactly "redirected"
in this case, the old and new hostnames go to the exact same server
so we fully expect event streaming to work as before. What we
*can't* solve with SSH is Git remotes for projects whose namespaces
changed during the move, so we've seen some questions from
third-party CI operators about failures associated with
incorporating unofficial repositories which moved from the
"openstack" namespace to the "x" namespace into their jobs.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/bc9a7bf8/attachment.sig>

From alifshit at redhat.com  Mon Apr 22 13:32:51 2019
From: alifshit at redhat.com (Artom Lifshitz)
Date: Mon, 22 Apr 2019 09:32:51 -0400
Subject: [FYI][all] PySnooper, a poor man's debugger
Message-ID: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>

tl;dr Instead of debugging with LOG.debug and/or print() statements
all over the place, use the pysnooper decorator [1].

I came across this on Hacker News this morning - if you're like me and
are too lazy to invest in learning a real debugger, and instead do it
with LOG.debug/print()s all over the place, pysnooper might be useful
to you. This line from the README feels particularly relevant to me ;)

> What makes PySnooper stand out from all other code intelligence tools?
> You can use it in your sh***y, sprawling enterprise codebase without having
> to do any setup.

I tried it out with a random Nova unit test by decorating the function
being tested, and it gave me the expected analysis of how the function
executed.

Just sharing this, I hope it might be useful to someone :)

[1] https://github.com/cool-RR/pysnooper


From mriedemos at gmail.com  Mon Apr 22 13:41:34 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 22 Apr 2019 08:41:34 -0500
Subject: [nova][dev] Pike Extended Maintenance coming soon
In-Reply-To: <cabd1716-ae37-44b7-1f3c-d1da76b60652@gmail.com>
References: <a15eae55-5843-49aa-62e3-ef578db2ea12@gmail.com>
 <cabd1716-ae37-44b7-1f3c-d1da76b60652@gmail.com>
Message-ID: <0eca4237-a861-022c-a362-d7c26c3c8881@gmail.com>

On 4/18/2019 11:12 AM, Matt Riedemann wrote:
> I'm tracking the final push to nova's pike extended maintenance here:
> 
> https://etherpad.openstack.org/p/nova-stable-pike-em

Just a quick update that [1] is all I'm waiting on now before we do a 
final pike release and create the pike-em branch.

[1] 
https://review.opendev.org/#/q/Iefab05e84ccc0bf8f15bdbbf515a290d282dbc5d+status:open

-- 

Thanks,

Matt


From hongbin.lu at huawei.com  Mon Apr 22 14:33:14 2019
From: hongbin.lu at huawei.com (Hongbin Lu)
Date: Mon, 22 Apr 2019 14:33:14 +0000
Subject: [neutron] Bug deputy report - April 15 - 21
Message-ID: <0957CD8F4B55C0418161614FEC580D6B30A03FC0@yyzeml704-chm.china.huawei.com>

Hi,

I was on bug deputy last week. Below is my bug deputy report:

Confirmed bugs:
* https://bugs.launchpad.net/neutron/+bug/1824788 installed neutron, but no provider network exists
* https://bugs.launchpad.net/neutron/+bug/1824799 neutron dhcp agent looks for external pid unexpectedly
* https://bugs.launchpad.net/neutron/+bug/1824802 dhcp agent dnsmasq process mgmt race condition between launch and operations (Important: HIGH)
* https://bugs.launchpad.net/neutron/+bug/1824911 [scale issue] the bottleneck lock will multiply increase processing time of agent resources
* https://bugs.launchpad.net/neutron/+bug/1825088 [port forwarding] should not process port forwarding if snat node only run DHCP
* https://bugs.launchpad.net/neutron/+bug/1825152 [scale issue] the root rootwrap deamon causes l3 agent router procssing very very slow
* https://bugs.launchpad.net/neutron/+bug/1825205 when the last vm of a network in a compute is live-migrated with DVR enable, the qrouter namespace is not deleted
* https://bugs.launchpad.net/neutron/+bug/1825291 TypeError: unhashable type: 'dict' in neutron-vpnaas while deleting routers
* https://bugs.launchpad.net/neutron/+bug/1825456 [VPNaaS] Add missing unit test for vpn agent

RFEs:
* https://bugs.launchpad.net/neutron/+bug/1824856 [RFE] Add new state "ERROR" for HA routers
* https://bugs.launchpad.net/neutron/+bug/1825336 [RFE] Tag based policy
* https://bugs.launchpad.net/neutron/+bug/1825345 [RFE] admin-state-down doesn't evacuate bindings in the dhcp_agent_id column

Invalid:
* https://bugs.launchpad.net/neutron/+bug/1824988 updating multisegment network segmentation id does not raise error and although the update succeeds it doesn't work
* https://bugs.launchpad.net/neutron/+bug/1825295 The openflow won't be deleted when we reboot and migrate the instance

Duplicated:
* https://bugs.launchpad.net/neutron/+bug/1825147 ovs flooding packets, not learning MAC addresses

Best regards,
Hongbin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/b15a30ee/attachment.html>

From senrique at redhat.com  Mon Apr 22 15:15:41 2019
From: senrique at redhat.com (Sofia Enriquez)
Date: Mon, 22 Apr 2019 12:15:41 -0300
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <CAArz_dAs5QnkwzM-hhqzzK=_VYBeOtwRNq4KzroL6Sv_bj2D_g@mail.gmail.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
 <CAArz_dAs5QnkwzM-hhqzzK=_VYBeOtwRNq4KzroL6Sv_bj2D_g@mail.gmail.com>
Message-ID: <CANtmtpF2VE4iuOUQdXSOGVKfEh4N0rCdVuSEpstNxjq2vsa6Ew@mail.gmail.com>

+1


On Mon, Apr 22, 2019 at 5:46 AM Yikun Jiang <yikunkero at gmail.com> wrote:

> +1, and thanks for your great work Brian
>
>
> Jay Bryant <jungleboyj at gmail.com> 于2019年4月17日周三 下午10:57写道：
>
>> Team,
>>
>> I would like to propose Brian Rosmaita for Cinder core.
>>
>> His participation in Cinder has been steadily increasing during the
>> Stein release.  He attended the mid-cycle meeting in Raleigh and was
>> able to provide great insight and input using his experience from Glance.
>>
>> His review activity has been consistent during Stein.  He has helped get
>> backports to our stable branches and subsequently has ensured that we do
>> timely releases of Cinder's components.
>>
>> Considering the broad range of activity Brian has demonstrated and his
>> years of experience in OpenStack I think he will serve as an excellent
>> addition to our core team.
>>
>> If I do not hear any concerns with this nomination I will make Brian
>> core on 4/24.
>>
>> Thank you!
>>
>> Jay
>>
>>
>>
>>

-- 

Sofia Enriquez

Associate Software Engineer
Red Hat PnT <https://www.redhat.com>

Ingeniero Butty 240, Piso 14

(C1001AFB) Buenos Aires - Argentina
+541143297471 (8426471)

senrique at redhat.com
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/6182afc5/attachment.html>

From openstack at nemebean.com  Mon Apr 22 16:24:47 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 11:24:47 -0500
Subject: [release] Release countdown for week R-26 and R-25, April 15-26
In-Reply-To: <20190419092254.GA26225@thor.bakeyournoodle.com>
References: <20190419092254.GA26225@thor.bakeyournoodle.com>
Message-ID: <0648b8dc-7b64-8b8b-e230-d4c92e8346bf@nemebean.com>



On 4/19/19 4:22 AM, Tony Breeds wrote:
> Here we go again! The Train cycle will about normal at 26 weeks.  Please take a
> couple of minutes to look over the schedule for this release:
> 
>      https://releases.openstack.org/train/schedule.html
> 
> We also have the same data available as an ics:
> 
>      https://releases.openstack.org/train/schedule.ics
> 
> it's a good idea for interested parties (for example PTLs and liaisons)
> to subscribe to it so upcoming deadlines are visible.
> 
> Development Focus
> -----------------
> 
> Focus should be on optimizing the time at the PTG and following up after the
> event to jump start Train development and spec planning
> 
> Action Required
> ---------------
> 
> PTLs will receive a direct email from me establishing contact and setting
> communication expectations.  Be on the lookout!
> 
> General Information
> -------------------
> 
> All teams should review their release liaison information and make sure it is
> up to date [1].
> 
> While reviewing liaisons, this would also be a good time to make sure your
> declared release model matches the project's plans for Train (e.g. [2]). This
> should be done prior to the first milestone and can be done by proposing a
> change to the Stein deliverable file for the project(s) affected [3].
> 
> 
> Now would be a good time to start brainstorming Forum topics while some of the
> PTG discussions are fresh. Just a couple months until the Summit and Forum in
> Berlin.

I think your email template needs updating. ;-)

> 
> Upcoming Deadlines & Dates
> --------------------------
> 
> Train-1 milestone: Jun 03  (R-19 week)
> Forum at OpenInfrastructure Summit in Denver: April 29 - May 1
> PTG right after the OpenInfrastructure Summit in Denver: May 2 - 4
> 
> 
> Yours Tony  (tonyb).
> 
> [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons
> [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/train/keystone.yaml#L3
> [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/train
> 
> 


From openstack at nemebean.com  Mon Apr 22 16:36:09 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 11:36:09 -0500
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
Message-ID: <1a7a1adf-ad30-a001-a2b8-ddcfa16fa6e6@nemebean.com>



On 4/22/19 5:58 AM, QingFeng Hao wrote:
> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
> hope it can work. thanks!

I think that's probably a Github mirror of the main RDO repo: 
https://review.rdoproject.org/r/#/admin/projects/openstack/placement-distgit 


That's where you would need to go if you wanted to propose changes to 
the spec.

> 
> 在 2019/4/22 13:49, QingFeng Hao 写道:
>> Hi,
>> I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
>> but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
>> Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
>> Thanks!
>>
> 


From rosmaita.fossdev at gmail.com  Mon Apr 22 16:36:47 2019
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Mon, 22 Apr 2019 12:36:47 -0400
Subject: [dev][cinder][stable-maint] python-cinderclient
Message-ID: <e809fbd0-4ef4-eee3-fec1-0277c7b36fe9@gmail.com>

At last week's Cinder weekly meeting, we discussed 3 patches to master
that should be merged and then backported to stable/stein and
stable/rocky (fixes for the "cinderclient can communicate with higher
microversions than it thinks it can" bug).

These patches still require approval (can be approved by any cinder core):
* https://review.opendev.org/#/c/653473/
* https://review.opendev.org/#/c/653472/
* https://review.opendev.org/#/c/653471/

After those are approved, all 3 will need to be backported to
stable/stein, and then the stein backport of
https://review.opendev.org/#/c/653471/ will need to be backported to
stable/rocky.


cheers,
brian



From openstack at nemebean.com  Mon Apr 22 16:51:49 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 11:51:49 -0500
Subject: [FYI][all] PySnooper, a poor man's debugger
In-Reply-To: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>
References: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>
Message-ID: <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>



On 4/22/19 8:32 AM, Artom Lifshitz wrote:
> tl;dr Instead of debugging with LOG.debug and/or print() statements
> all over the place, use the pysnooper decorator [1].
> 
> I came across this on Hacker News this morning - if you're like me and
> are too lazy to invest in learning a real debugger, and instead do it
> with LOG.debug/print()s all over the place, pysnooper might be useful
> to you. This line from the README feels particularly relevant to me ;)

I'm going to mildly object to the characterization of print and log 
debugging as "lazy". I've spent plenty of time in debuggers over the 
years and in many cases I just prefer a simple print over stepping 
through a huge number of lines of code. Both debugging techniques have 
their place and nobody should feel bad because they chose one over the 
other.

> 
>> What makes PySnooper stand out from all other code intelligence tools?
>> You can use it in your sh***y, sprawling enterprise codebase without having
>> to do any setup.
> 
> I tried it out with a random Nova unit test by decorating the function
> being tested, and it gave me the expected analysis of how the function
> executed.
> 
> Just sharing this, I hope it might be useful to someone :)

I've starred it. It looks a bit like bash's xtrace on steroids, which is 
something I use quite a lot when debugging bash scripts.

> 
> [1] https://github.com/cool-RR/pysnooper
> 


From openstack at nemebean.com  Mon Apr 22 17:24:28 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 12:24:28 -0500
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <20190420063850.GA18527@holtby.speedport.ip>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
Message-ID: <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>



On 4/20/19 1:38 AM, Michele Baldessari wrote:
> On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
>>
>> Today I discovered that this problem appears to be caused by eventlet
>> monkey-patching. I've created a bug for it:
>>
>> https://bugs.launchpad.net/nova/+bug/1825584
> 
> Hi,
> 
> just for completeness we see this very same issue also with
> mistral (actually it was the first service where we noticed the missed
> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
> although I have not personally observed it there yet.

Is Mistral also mixing eventlet monkeypatching and WSGI?


From jungleboyj at gmail.com  Mon Apr 22 17:38:59 2019
From: jungleboyj at gmail.com (Jay Bryant)
Date: Mon, 22 Apr 2019 12:38:59 -0500
Subject: [cinder] Proposing Brian Rosmaita for Core ...
In-Reply-To: <20190421235046.GB26225@thor.bakeyournoodle.com>
References: <e69c3ec7-0fe7-b693-3a97-57a872729ccb@gmail.com>
 <20190421235046.GB26225@thor.bakeyournoodle.com>
Message-ID: <71114d43-cd6c-c34b-33fb-73597cbb46da@gmail.com>

Tony,

This is a good point.  I think you are right that we should do both at once.

Thank you for your input!

Jay

On 4/21/2019 6:50 PM, Tony Breeds wrote:
> On Wed, Apr 17, 2019 at 09:51:03AM -0500, Jay Bryant wrote:
>> Team,
>>
>> I would like to propose Brian Rosmaita for Cinder core.
>>
>> His participation in Cinder has been steadily increasing during the Stein
>> release.  He attended the mid-cycle meeting in Raleigh and was able to
>> provide great insight and input using his experience from Glance.
>>
>> His review activity has been consistent during Stein.  He has helped get
>> backports to our stable branches and subsequently has ensured that we do
>> timely releases of Cinder's components.
>>
>> Considering the broad range of activity Brian has demonstrated and his years
>> of experience in OpenStack I think he will serve as an excellent addition to
>> our core team.
>>
>> If I do not hear any concerns with this nomination I will make Brian core on
>> 4/24.
> I don't really get a vote but if I did it'd be +1 :)
>
> I do get more of a say on stable stuff and I'd endorse Brian be added
> to cinder-stable-core at the same time.
>
> Yours Tony.


From aschultz at redhat.com  Mon Apr 22 17:53:41 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Mon, 22 Apr 2019 11:53:41 -0600
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
Message-ID: <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>

On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <openstack at nemebean.com> wrote:
>
>
>
> On 4/20/19 1:38 AM, Michele Baldessari wrote:
> > On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
> >>
> >> Today I discovered that this problem appears to be caused by eventlet
> >> monkey-patching. I've created a bug for it:
> >>
> >> https://bugs.launchpad.net/nova/+bug/1825584
> >
> > Hi,
> >
> > just for completeness we see this very same issue also with
> > mistral (actually it was the first service where we noticed the missed
> > heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
> > although I have not personally observed it there yet.
>
> Is Mistral also mixing eventlet monkeypatching and WSGI?
>

Looks like there is monkey patching, however we noticed it with the
engine/executor. So it's likely not just wsgi.  I think I also saw it
in the ironic-conductor, though I'd have to try it out again.  I'll
spin up an undercloud today and see if I can get a more complete list
of affected services. It was pretty easy to reproduce.

Thanks,
-Alex


From ekcs.openstack at gmail.com  Mon Apr 22 18:16:39 2019
From: ekcs.openstack at gmail.com (Eric K)
Date: Mon, 22 Apr 2019 11:16:39 -0700
Subject: Call for help! 'U' Release name Mandarin speakers
In-Reply-To: <20190421235301.GC26225@thor.bakeyournoodle.com>
References: <20190214021836.GD12795@thor.bakeyournoodle.com>
 <a6fe65e2-358a-a87b-9383-71cad58df6ce@openstack.org>
 <D8DF7E66.C446C%ekcs.openstack@gmail.com>
 <20190421235301.GC26225@thor.bakeyournoodle.com>
Message-ID: <CAOakLUOCC+Ut2N1=Zzs_FD8r7ZR0RUaKLMLgsyxGu6RyLspzvg@mail.gmail.com>

On Sun, Apr 21, 2019 at 4:53 PM Tony Breeds <tony at bakeyournoodle.com> wrote:
>
> On Fri, Apr 19, 2019 at 01:40:34PM -0700, Eric K wrote:
> > I am a native mandarin speaker. I'm happy to work with Tony in this
> > process.
>
> Great!  Are you going to be in Denver?  If so lets start the ball
> rolling while we're there
>
> Yours Tony.

Great! I'll be there.


From openstack at nemebean.com  Mon Apr 22 18:21:03 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 13:21:03 -0500
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
Message-ID: <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>



On 4/22/19 12:53 PM, Alex Schultz wrote:
> On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <openstack at nemebean.com> wrote:
>>
>>
>>
>> On 4/20/19 1:38 AM, Michele Baldessari wrote:
>>> On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
>>>>
>>>> Today I discovered that this problem appears to be caused by eventlet
>>>> monkey-patching. I've created a bug for it:
>>>>
>>>> https://bugs.launchpad.net/nova/+bug/1825584
>>>
>>> Hi,
>>>
>>> just for completeness we see this very same issue also with
>>> mistral (actually it was the first service where we noticed the missed
>>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
>>> although I have not personally observed it there yet.
>>
>> Is Mistral also mixing eventlet monkeypatching and WSGI?
>>
> 
> Looks like there is monkey patching, however we noticed it with the
> engine/executor. So it's likely not just wsgi.  I think I also saw it
> in the ironic-conductor, though I'd have to try it out again.  I'll
> spin up an undercloud today and see if I can get a more complete list
> of affected services. It was pretty easy to reproduce.

Okay, I asked because if there's no WSGI/Eventlet combination then this 
may be different from the Nova issue that prompted this thread. It 
sounds like that was being caused by a bad interaction between WSGI and 
some Eventlet timers. If there's no WSGI involved then I wouldn't expect 
that to happen.

I guess we'll see what further investigation turns up, but based on the 
preliminary information there may be two bugs here.


From amy at demarco.com  Mon Apr 22 18:36:23 2019
From: amy at demarco.com (Amy Marrich)
Date: Mon, 22 Apr 2019 13:36:23 -0500
Subject: Diversity Events - Updated
In-Reply-To: <CAFs83Qqa52keFXZNOtpig23cDJafora44W3j=cKWFQjye0q=8A@mail.gmail.com>
References: <CAFs83Qqa52keFXZNOtpig23cDJafora44W3j=cKWFQjye0q=8A@mail.gmail.com>
Message-ID: <CAFs83Qq_MpND=Ld_HwvsvReNbp4Qj=gidv0MqUL3iW2Kn6NVKw@mail.gmail.com>

I noticed that one event on Tuesday (Chasing Grace Screening) was a
conflict with the Survey Results so please note the following updated
information:

Tuesday:
1:40-2:20 - Chasing Grace Episode 2 screening
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23602/chasing-grace-episode-2-screening-progress-and-the-power-of-community

Wednesday:
2:30 - 3:10 - The Results are in for the D&I Survey. This is a first review
of the data collected.
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23692/the-results-are-in-for-the-d-and-i-survey

I would also like to add if anyone would like to touch base at summit about
anything Diversity related or otherwise, please feel free to hit me up via
email, IRC (spotz), or Twitter (spotzz_) to schedule time.

Thanks,

Amy (spotz)


On Sun, Apr 21, 2019 at 5:48 PM Amy Marrich <amy at demarco.com> wrote:

> Summit is a week away and I wanted to point out a few Diversity related
> sessions and events taking place.
>
> Thanks,
>
> Amy (spotz)
>
> Monday:
> 12:20-1:40 - Speed Mentoring Lunch sponsored by Intel - RSVP required
>
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23757/rsvp-required-speed-mentoring-lunch-sponsored-by-intel
>
> Tuesday:
> 12:20-1:40 - Diversity Networking Lunch sponsored by IBM - RSVP required
>
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23756/rsvp-required-diversity-networking-lunch-sponsored-by-ibm
> 1:40-2:20 - The Results are in for the D&I Survey. This is a first review
> of the data collected.
>
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23692/the-results-are-in-for-the-d-and-i-survey
>
> Wednesday:
> 10:50-11:30 - Diversity WG BoF - looking for help with the Mentoring
> Program
>
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23745/diversity-working-group-bof
> 11:40-12:20 - Diversity and Inclusion  WG
>
> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23746/diversity-and-inclusion-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/2ee342a9/attachment-0001.html>

From sean.mcginnis at gmx.com  Mon Apr 22 18:56:45 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Mon, 22 Apr 2019 13:56:45 -0500
Subject: [Third Party CI][Cinder] Changes from review.openstack.org to
 review.opedev.org
In-Reply-To: <20190422132801.qhkaahmzt7bkkjg5@yuggoth.org>
References: <20190422114658.GA22166@sm-xps>
 <20190422132801.qhkaahmzt7bkkjg5@yuggoth.org>
Message-ID: <20190422185645.GA30522@sm-workstation>

>
> Any idea why this is failing? While SSH isn't exactly "redirected"
> in this case, the old and new hostnames go to the exact same server
> so we fully expect event streaming to work as before. What we
> *can't* solve with SSH is Git remotes for projects whose namespaces
> changed during the move, so we've seen some questions from
> third-party CI operators about failures associated with
> incorporating unofficial repositories which moved from the
> "openstack" namespace to the "x" namespace into their jobs.
> --
> Jeremy Stanley

Ah, sorry. Maybe it was just that in combination with a host config issue I had
on another machine. I'm probably just crying wolf then.

Mainly, I just wanted to make sure third party CI operators had seen that this
transition work had been done and fix any issues with new host names and
things. If it is not actually an issue for most, please just consider this
another avenue for getting the word out about the great work the OpenDev Infra
team did over Friday and the weekend to get everything working as seamless as
possible. ;)

Sean


From mriedemos at gmail.com  Mon Apr 22 19:10:43 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Mon, 22 Apr 2019 14:10:43 -0500
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
 <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>
Message-ID: <3f425a31-4760-4ea4-18d1-ca7a5c38355e@gmail.com>

On 4/22/2019 7:32 AM, Emilien Macchi wrote:
> Step 1. (after PTG and before it's removed in Nova)

Be aware that the current plan from the nova team is to remove the 
placement code from nova *during* the PTG, after the aforementioned 
Forum session. That might change as a result of the Forum session or 
people saying at the PTG that we shouldn't do that, but just FYI that 
it's the current plan.

-- 

Thanks,

Matt


From smooney at redhat.com  Mon Apr 22 19:21:36 2019
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 22 Apr 2019 20:21:36 +0100
Subject: [FYI][all] PySnooper, a poor man's debugger
In-Reply-To: <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>
References: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>
 <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>
Message-ID: <a8c29e1c5d197e506955ac60645911087da81af7.camel@redhat.com>

On Mon, 2019-04-22 at 11:51 -0500, Ben Nemec wrote:
> 
> On 4/22/19 8:32 AM, Artom Lifshitz wrote:
> > tl;dr Instead of debugging with LOG.debug and/or print() statements
> > all over the place, use the pysnooper decorator [1].
> > 
> > I came across this on Hacker News this morning - if you're like me and
> > are too lazy to invest in learning a real debugger, and instead do it
> > with LOG.debug/print()s all over the place, pysnooper might be useful
> > to you. This line from the README feels particularly relevant to me ;)
> 
> I'm going to mildly object to the characterization of print and log 
> debugging as "lazy". I've spent plenty of time in debuggers over the 
> years and in many cases I just prefer a simple print over stepping 
> through a huge number of lines of code. Both debugging techniques have 
> their place and nobody should feel bad because they chose one over the 
> other.

yep i agree :)

i started programming on windows so i have alway had good grapical debugger
avaiable so when i started working on openstack the fact that eventlets
breaks debugging used to kill me so i got to be more ok with print/log debbuging
as i often had to fight with it less. recently eventlets is less of an issue
as gevent support was developed by the pycharm folks in there debugger.

that said i when i need to debug more involved code i do still pull out pycharm
vs code. having a handy decorator that i can use when im coding in nano/emacs
is also nice to have in my tool box. as i dont always want to have to install
an ide in a vm i create to test a random thing.

> 
> > 
> > > What makes PySnooper stand out from all other code intelligence tools?
> > > You can use it in your sh***y, sprawling enterprise codebase without having
> > > to do any setup.
> > 
> > I tried it out with a random Nova unit test by decorating the function
> > being tested, and it gave me the expected analysis of how the function
> > executed.
> > 
> > Just sharing this, I hope it might be useful to someone :)
> 
> I've starred it. It looks a bit like bash's xtrace on steroids, which is 
> something I use quite a lot when debugging bash scripts.
> 
> > 
> > [1] https://github.com/cool-RR/pysnooper
> > 
> 
> 



From jaypipes at gmail.com  Mon Apr 22 19:23:20 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 22 Apr 2019 15:23:20 -0400
Subject: [placement][nova][ptg] Resourceless trait filters
In-Reply-To: <63118B69-94C6-41D0-9DEE-9ED331DBBD25@leafe.com>
References: <alpine.OSX.2.21.1904091814370.93787@cdent-a01.vmware.com>
 <63118B69-94C6-41D0-9DEE-9ED331DBBD25@leafe.com>
Message-ID: <8d868dcd-e194-6346-efab-f43dba6e2e2f@gmail.com>

On 04/10/2019 12:51 PM, Ed Leafe wrote:
> On Apr 9, 2019, at 12:22 PM, Chris Dent <cdent+os at anticdent.org> wrote:
>>
>>         * (My brain hurts from the concept for a provider that
>>           provides nothing. Perhaps it provides something we aren't
>>           remembering to count?)
> 
> This was a big bone of contention back when Traits were first being discussed: they can only be applied to RPs. So if you had a single physical PCI device that provided virtual functions, and some of those VFs were, say, private net and the others were public, you had to create intermediary RPs between the PCI RP and the VFs so that you could tag those RPs with the correct trait to distinguish them.
> 
> That brain hurt is very much why I argued against this restriction back then. But it's what we ended up with, so those "virtual" RPs are with us for good. If it helps, think of them as not providing resources, but providing other resource providers.
> 
> Does that hurt a little less?

Note that if we used a single "apply aggregate association and trait 
constraints in a self-and-children manner" policy, everything would be 
much easier to reason and think about.

-jay


From skaplons at redhat.com  Mon Apr 22 19:25:50 2019
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Mon, 22 Apr 2019 21:25:50 +0200
Subject: [FYI][all] PySnooper, a poor man's debugger
In-Reply-To: <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>
References: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>
 <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>
Message-ID: <20190422192550.64cftvrje2tbm43q@skaplons-mac>

Hi,

Thanks. It looks really interesting :)

On Mon, Apr 22, 2019 at 11:51:49AM -0500, Ben Nemec wrote:
> 
> 
> On 4/22/19 8:32 AM, Artom Lifshitz wrote:
> > tl;dr Instead of debugging with LOG.debug and/or print() statements
> > all over the place, use the pysnooper decorator [1].
> > 
> > I came across this on Hacker News this morning - if you're like me and
> > are too lazy to invest in learning a real debugger, and instead do it
> > with LOG.debug/print()s all over the place, pysnooper might be useful
> > to you. This line from the README feels particularly relevant to me ;)
> 
> I'm going to mildly object to the characterization of print and log
> debugging as "lazy". I've spent plenty of time in debuggers over the years
> and in many cases I just prefer a simple print over stepping through a huge
> number of lines of code. Both debugging techniques have their place and
> nobody should feel bad because they chose one over the other.
> 

Exactly. Imagine debugging e.g. some race condition issue. Using simple prints
may be much better in such case to find out what is going on wrong there :)

> > 
> > > What makes PySnooper stand out from all other code intelligence tools?
> > > You can use it in your sh***y, sprawling enterprise codebase without having
> > > to do any setup.
> > 
> > I tried it out with a random Nova unit test by decorating the function
> > being tested, and it gave me the expected analysis of how the function
> > executed.
> > 
> > Just sharing this, I hope it might be useful to someone :)
> 
> I've starred it. It looks a bit like bash's xtrace on steroids, which is
> something I use quite a lot when debugging bash scripts.
> 
> > 
> > [1] https://github.com/cool-RR/pysnooper
> > 
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat


From bodenvmw at gmail.com  Mon Apr 22 19:32:13 2019
From: bodenvmw at gmail.com (Boden Russell)
Date: Mon, 22 Apr 2019 13:32:13 -0600
Subject: OpenStack Hound code search with OpenDev repos
Message-ID: <a87a4a5a-1430-d84a-c333-73d237d7d624@gmail.com>

Maybe I missed this, but are there some changes necessary for the
OpenStack Hound (code search) service [1] to work with OpenDev git repos?

As of right now Hound [1] doesn't seem to be finding any repos; click
the "Advanced" option and see the empty list of repos.

Thanks

[1] http://codesearch.openstack.org/


From nate.johnston at redhat.com  Mon Apr 22 19:59:28 2019
From: nate.johnston at redhat.com (Nate Johnston)
Date: Mon, 22 Apr 2019 15:59:28 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when supplied
 attribute equals the default
Message-ID: <20190422195928.5i2ld3o4exk3fmv7@bishop>

API SIG and Neutron communities,

TL;DR
-----------------------
For API requests that specify boolean attributes to the request, we
check "are you allowed to specify this attribute" before we check "would
specifying this argument make any difference".  I am proposing to change
that so users can specify things forbidden by policy as long as the
attribute specified equals the default and therefore the result would be
the same as if it had not been specified.  Are there any security
problems with that?

Long-winded explanation
-----------------------
I would like your opinion on the potential security impact of a change I
am proposing to the Neutron mechanism for assertion of oslo.policy.  In
response to an operator concern I proposed a change [1] that would
exempt oslo.policy checks under one specific condition: if the request
specifies a boolean attribute that matches a configured default.

The way Neutron is currently coded, API requests have the oslo.policy
check - "are you allowed to ask for X" before anything else about the
request is processed.  For those not familiar with it, oslo.polcy
additionally provides the ability to control arguments within that
request, so that you can permit only some users to use those arguments.
For example, usually permissions to create a network are pretty broad
but you must me admin to create a network and specify if it will be
shared.  

The feedback that I got was that this was frustrating for users and some
operators.  The distinction that we make as programmers - asserting the
policy check before the processing of the request - is counterintuitive
from a user perspective.  The preferred behavior is to say "if supplying
the argument results in the same end condition as not supplying any
argument (because the argument supplied is the default anyway) then
allow it".  

Proposed change
-----------------------
The proposed change I submitted to neutron is to bypass oslo.policy
checks for method arguments when all boolean method arguments equal the
configured default.  If any boolean arguments differ from the default,
or if there are any other arguments specified that are controlled by
policy, then execute the oslo.policy checks as normal.  Here are a few
examples:

- Regular project user creates a network specifying shared=false.  
    - Current behavior: regular user cannot specify the shared
      attribute, denied.
    - Proposed behavior: "shared=false" is the default when creating
      networks, so allow it.
- Regular project user creates a router specifying that it be non-HA.
    - Current behavior: regular user cannot specify the "ha" attribute,
      denied.
    - Proposed behavior: "ha=false" is the default when creating
      routers, so allow it.

In neutron the oslo.policy check is done in the API base [2] almost
immediately upon receipt of an API request, not as a decorator in the
keystone style.  So comparison of supplied boolean attributes against
defaults could be done at that point centrally.

The Concern
-----------------------
The concern raised - and what I hope to get the API SIG's guidance on -
is whether this raises any kind of security concern.  I don't think it
will.  Since we are comparing equivalence of the user supplied attribute 
to the default, the end result of a request permitted by this proposal
should always be the same as a request where the user did not supply
that argument.  But your wisdom would be appreciated in validating that
assumption.

Thanks for your feedback,

Nate

[1] https://bugs.launchpad.net/neutron/+bug/1821208
[2] https://opendev.org/openstack/neutron/src/branch/master/neutron/api/v2/base.py#L468


From jeremyfreudberg at gmail.com  Mon Apr 22 20:02:26 2019
From: jeremyfreudberg at gmail.com (Jeremy Freudberg)
Date: Mon, 22 Apr 2019 16:02:26 -0400
Subject: OpenStack Hound code search with OpenDev repos
In-Reply-To: <a87a4a5a-1430-d84a-c333-73d237d7d624@gmail.com>
References: <a87a4a5a-1430-d84a-c333-73d237d7d624@gmail.com>
Message-ID: <CAFntmSjKQrBc_G2DiWi9H3DTD4om0ZNpkH97qHE_bD2HaMAGqQ@mail.gmail.com>

Hi Boden,

I'm aware of https://opendev.org/explore/code , at the very least.

Hope this helps,
Jeremy

On Mon, Apr 22, 2019 at 3:32 PM Boden Russell <bodenvmw at gmail.com> wrote:
>
> Maybe I missed this, but are there some changes necessary for the
> OpenStack Hound (code search) service [1] to work with OpenDev git repos?
>
> As of right now Hound [1] doesn't seem to be finding any repos; click
> the "Advanced" option and see the empty list of repos.
>
> Thanks
>
> [1] http://codesearch.openstack.org/
>


From emilien at redhat.com  Mon Apr 22 20:13:09 2019
From: emilien at redhat.com (Emilien Macchi)
Date: Mon, 22 Apr 2019 16:13:09 -0400
Subject: [tripleo] Summit / PTG link
Message-ID: <CACu=hyuOXozmPqG_2v02PY7iHW8jtTpOoVKHa9c8LpU1=Wp_mg@mail.gmail.com>

All (or almost) what you need to know about TripleO at Open Infra summit &
PTG:

I created a Google Calendar for TripleO related sessions (including PTG):
web format:
https://calendar.google.com/calendar/embed?src=es78vnjv5galctjgo1vsi3d7bo%40group.calendar.google.com
ical format:
https://calendar.google.com/calendar/ical/es78vnjv5galctjgo1vsi3d7bo%40group.calendar.google.com/public/basic.ics

Our PTG etherpads are here (topics + agenda)
https://etherpad.openstack.org/p/tripleo-train-topics
https://etherpad.openstack.org/p/tripleo-ptg-train

Don't miss the team picture on Thursday, 11am.

Safe travels, and see you next week!
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190422/2e2ea61a/attachment.html>

From ltoscano at redhat.com  Mon Apr 22 20:30:29 2019
From: ltoscano at redhat.com (Luigi Toscano)
Date: Mon, 22 Apr 2019 22:30:29 +0200
Subject: OpenStack Hound code search with OpenDev repos
In-Reply-To: <CAFntmSjKQrBc_G2DiWi9H3DTD4om0ZNpkH97qHE_bD2HaMAGqQ@mail.gmail.com>
References: <a87a4a5a-1430-d84a-c333-73d237d7d624@gmail.com>
 <CAFntmSjKQrBc_G2DiWi9H3DTD4om0ZNpkH97qHE_bD2HaMAGqQ@mail.gmail.com>
Message-ID: <2067474.1hjfSypTln@whitebase.usersys.redhat.com>

On Monday, 22 April 2019 22:02:26 CEST Jeremy Freudberg wrote:
> Hi Boden,
> 
> I'm aware of https://opendev.org/explore/code , at the very least.
> 

Last time I checked there were still some issues with it, see:
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.
2019-03-26.log.html#t2019-03-26T21:38:09

I guess that fixing the search is on the -infra TODO, if codesearch is going 
to be replaced.

Ciao
-- 
Luigi




From openstack at nemebean.com  Mon Apr 22 20:30:44 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 22 Apr 2019 15:30:44 -0500
Subject: [oslo] No meeting next two weeks
Message-ID: <6630b4e8-a339-107e-d71e-c6028f5ea14a@nemebean.com>

God dag, Norsk. As discussed in the meeting this morning, there will be 
no Oslo meeting for the next two weeks (Apr. 29 and May 6). The former 
is during Summit, and the latter will be the first work day after the PTG.

As always, if anything comes up during that time you don't have to wait 
for a meeting to bring it to our attention. The mailing list is always open.

-Ben


From msm at redhat.com  Mon Apr 22 20:49:38 2019
From: msm at redhat.com (Michael McCune)
Date: Mon, 22 Apr 2019 16:49:38 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <20190422195928.5i2ld3o4exk3fmv7@bishop>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
Message-ID: <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>

hey Nate,

thanks for the very detailed description, it helped =)

On Mon, Apr 22, 2019 at 4:04 PM Nate Johnston <nate.johnston at redhat.com> wrote:
<snip>
> The Concern
> -----------------------
> The concern raised - and what I hope to get the API SIG's guidance on -
> is whether this raises any kind of security concern.  I don't think it
> will.  Since we are comparing equivalence of the user supplied attribute
> to the default, the end result of a request permitted by this proposal
> should always be the same as a request where the user did not supply
> that argument.  But your wisdom would be appreciated in validating that
> assumption.

i have a couple questions.

will the user in question's permission be checked either way
regardless of how they specify the parameters?

this change might give a lower privileged user (eg a user who cannot
specify "ha") the ability to sniff around for the defaults, but i'm
not sure if that information represents a security risk in this case.
are there any defaults that a potential snooper might leverage for
nefarious behavior? (only asking because i am not familiar with
neutron internals)

assuming there is nothing harmful that could be leaked from the
defaults, your reasoning is sound to me. these parameters will take
the defaults either way, the only thing that seems to be different is
that as a user i might not immediately know which specific parameters
i have access to change.

peace o/


From openstack at fried.cc  Mon Apr 22 21:05:48 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 22 Apr 2019 16:05:48 -0500
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
Message-ID: <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>

> this change might give a lower privileged user (eg a user who cannot
> specify "ha") the ability to sniff around for the defaults,

This was the only thing I could think of.

> but i'm
> not sure if that information represents a security risk in this case.

Because they could also find that out by looking at the source code?

efried
.


From msm at redhat.com  Mon Apr 22 22:42:50 2019
From: msm at redhat.com (Michael McCune)
Date: Mon, 22 Apr 2019 18:42:50 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
Message-ID: <CADE+ktQhnbu4ish7pQ+MhVN=tuhN1nVJ7qyB1monBL3GAoO4Gg@mail.gmail.com>

On Mon, Apr 22, 2019 at 5:10 PM Eric Fried <openstack at fried.cc> wrote:
> Because they could also find that out by looking at the source code?

exactly... /me chuckles =)

peace o/


From aschultz at redhat.com  Mon Apr 22 22:56:55 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Mon, 22 Apr 2019 16:56:55 -0600
Subject: =?UTF-8?Q?Re=3A_=5Btripleo=5D_Nominate_C=C3=A9dric_Jeanneret_=28Tengu=29_for?=
 =?UTF-8?Q?_tripleo=2Dvalidations_core?=
In-Reply-To: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
References: <20190418102939.heykaeyphydgocq4@olivia.strider.local>
Message-ID: <CAFsb3b69=r+HsJ-Sr+01AeLFkGP=vsH+wzNkq5s1+L0E_DoqzQ@mail.gmail.com>

+1

On Thu, Apr 18, 2019 at 4:33 AM Gaël Chamoulaud <gchamoul at redhat.com> wrote:
>
> Hi TripleO devs,
>
> The new Validation Framework is a big step further for the tripleo-validations
> project. In many ways, it improves the way of detecting & reporting potential
> issues during a TripleO deployment. As the mastermind of this new framework,
> Cédric brought a new lease of life to the tripleo-validations project. That's
> why we would highly benefit from his addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Cédric to the core team next
> week.
>
> Thanks, Cédric, for your excellent work!
>
> =Gaël


From aschultz at redhat.com  Mon Apr 22 23:17:47 2019
From: aschultz at redhat.com (Alex Schultz)
Date: Mon, 22 Apr 2019 17:17:47 -0600
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
Message-ID: <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>

On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec <openstack at nemebean.com> wrote:
>
>
>
> On 4/22/19 12:53 PM, Alex Schultz wrote:
> > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <openstack at nemebean.com> wrote:
> >>
> >>
> >>
> >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
> >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
> >>>>
> >>>> Today I discovered that this problem appears to be caused by eventlet
> >>>> monkey-patching. I've created a bug for it:
> >>>>
> >>>> https://bugs.launchpad.net/nova/+bug/1825584
> >>>
> >>> Hi,
> >>>
> >>> just for completeness we see this very same issue also with
> >>> mistral (actually it was the first service where we noticed the missed
> >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
> >>> although I have not personally observed it there yet.
> >>
> >> Is Mistral also mixing eventlet monkeypatching and WSGI?
> >>
> >
> > Looks like there is monkey patching, however we noticed it with the
> > engine/executor. So it's likely not just wsgi.  I think I also saw it
> > in the ironic-conductor, though I'd have to try it out again.  I'll
> > spin up an undercloud today and see if I can get a more complete list
> > of affected services. It was pretty easy to reproduce.
>
> Okay, I asked because if there's no WSGI/Eventlet combination then this
> may be different from the Nova issue that prompted this thread. It
> sounds like that was being caused by a bad interaction between WSGI and
> some Eventlet timers. If there's no WSGI involved then I wouldn't expect
> that to happen.
>
> I guess we'll see what further investigation turns up, but based on the
> preliminary information there may be two bugs here.
>

So I wasn't able to reproduce the ironic issues yet. But it's the
mistral executor and nova-api which exhibit the issue on the
undercloud.

mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR
oslo.messaging._drivers.impl_rabbit [-]
[b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on
undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno 104]
Connection reset by peer. Trying again in 1 seconds.:
ConnectionResetError: [Errno 104] Connection reset by peer


nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR
oslo.messaging._drivers.impl_rabbit
[req-d7767aed-e32d-43db-96a8-c0509bfb1cfe
9ac89090d2d24949b9a1e01b1afb14cc 7becac88cbae4b3b962ecccaf536effe -
default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP server on
undercloud-0.ctlplane.localdomain:5672 is unreachable: Server
unexpectedly closed connection. Trying again in 1 seconds.: OSError:
Server unexpectedly closed connection

The errors being thrown are different perhaps it is two different problems.

Thanks,
-Alex


From ykarel at redhat.com  Tue Apr 23 02:52:37 2019
From: ykarel at redhat.com (Yatin Karel)
Date: Tue, 23 Apr 2019 08:22:37 +0530
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
Message-ID: <CAPU8nTHssKB_6t9tgsKEf11XJJL0bQEkEENJBAj1+zT_X8kcxw@mail.gmail.com>

On Mon, Apr 22, 2019 at 11:52 PM Ben Nemec <openstack at nemebean.com> wrote:
>
>
>
> On 4/22/19 12:53 PM, Alex Schultz wrote:
> > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <openstack at nemebean.com> wrote:
> >>
> >>
> >>
> >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
> >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com wrote:
> >>>>
> >>>> Today I discovered that this problem appears to be caused by eventlet
> >>>> monkey-patching. I've created a bug for it:
> >>>>
> >>>> https://bugs.launchpad.net/nova/+bug/1825584
> >>>
> >>> Hi,
> >>>
> >>> just for completeness we see this very same issue also with
> >>> mistral (actually it was the first service where we noticed the missed
> >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
> >>> although I have not personally observed it there yet.
> >>
> >> Is Mistral also mixing eventlet monkeypatching and WSGI?
> >>
> >
> > Looks like there is monkey patching, however we noticed it with the
> > engine/executor. So it's likely not just wsgi.  I think I also saw it
> > in the ironic-conductor, though I'd have to try it out again.  I'll
> > spin up an undercloud today and see if I can get a more complete list
> > of affected services. It was pretty easy to reproduce.
>
> Okay, I asked because if there's no WSGI/Eventlet combination then this
> may be different from the Nova issue that prompted this thread. It
> sounds like that was being caused by a bad interaction between WSGI and
> some Eventlet timers. If there's no WSGI involved then I wouldn't expect
> that to happen.
>
Just to update(since Error(RPC) being discussed here and in the
mistral bug(SSL+python3+wsgi) are different) this Thread that mistral
mixes eventlet and wsgi, i filled few months back
https://bugs.launchpad.net/mistral/+bug/1808953

> I guess we'll see what further investigation turns up, but based on the
> preliminary information there may be two bugs here.
>


From ykarel at redhat.com  Tue Apr 23 04:45:48 2019
From: ykarel at redhat.com (Yatin Karel)
Date: Tue, 23 Apr 2019 10:15:48 +0530
Subject: [release-openstack-python][release pipeline] POST_FAILURE since last
 couple of hours, already known and being fixed?
Message-ID: <CAPU8nTGOEXBMHTMj_M69vK38qeuQajyhLAaU1GgtE7wqZ24J1Q@mail.gmail.com>

Hi all,

release-openstack-python[1] job is failing since last couple of hours,
is this already known and worked upon?
If it's not being fixed yet good to hold other releases until it's fixed.

The job failing at ansible task: ensure-twine : Ensure twine is
installed  with Error:- Can not perform a '--user' install. User
site-packages are not visible in this virtualenv.
Example log:- http://logs.openstack.org/c0/c09c5676b549b6705e7286ee6d1d7e000b9e756f/release/release-openstack-python/192aed5/job-output.txt.gz#_2019-04-22_21_41_50_563080


Actually i tried to reach via IRC at #openstack-release but seems
release team in other time zone, posting on mailing list so it can be
followed up.

Noticed the issue when found tarballs missing when building the
released projects in RDO [2].


[1] http://zuul.openstack.org/builds?job_name=release-openstack-python
[2] https://logs.rdoproject.org/97/20397/1/check/distgit-cbs-validate/7bd5d70/job-output.txt.gz#_2019-04-22_19_30_59_874132



Thanks and Regards
Yatin Karel


From dharmendra.kushwaha at india.nec.com  Tue Apr 23 05:39:19 2019
From: dharmendra.kushwaha at india.nec.com (Dharmendra Kushwaha)
Date: Tue, 23 Apr 2019 05:39:19 +0000
Subject: [Tacker] Weekly meeting and vPTG
Message-ID: <OSBPR01MB3783E734AC912B210049122BA2230@OSBPR01MB3783.jpnprd01.prod.outlook.com>

Hi Team,

Due to the summit, most of members busy in travel things, so canceling today's and next week IRC meeting.
We will resume Tacker weekly meeting on 7th May.

Due to U.S. visa issue, I am not able to travel this time, so as we agreed to cancel physical PTG, and will finalize vPTG schedule in weekly meeting of 7th May.

I Will be available on Tacker channel, feel free to ping me for any discussion.

Thanks & Regards
Dharmendra Kushwaha


From haoqf at linux.vnet.ibm.com  Tue Apr 23 07:04:58 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Tue, 23 Apr 2019 15:04:58 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <1a7a1adf-ad30-a001-a2b8-ddcfa16fa6e6@nemebean.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
 <1a7a1adf-ad30-a001-a2b8-ddcfa16fa6e6@nemebean.com>
Message-ID: <8e57202d-e006-c88b-625d-b7d37ae5421d@linux.vnet.ibm.com>



在 2019/4/23 0:36, Ben Nemec 写道:
> 
> 
> On 4/22/19 5:58 AM, QingFeng Hao wrote:
>> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
>> hope it can work. thanks!
> 
> I think that's probably a Github mirror of the main RDO repo: https://review.rdoproject.org/r/#/admin/projects/openstack/placement-distgit
Thanks, and I saw there was some tiny changes on the version and history in spec file on stein-rdo branch.
Anyway, placement seems depend on os-resource-classes and oslo.upgradecheck which I am also building with rdo spec.
> 
> That's where you would need to go if you wanted to propose changes to the spec.
> 
>>
>> 在 2019/4/22 13:49, QingFeng Hao 写道:
>>> Hi,
>>> I am trying to build openstack placement rpms on stein, I can find its related sources in https://tarballs.openstack.org/placement/,
>>> but I can't find its spec file in https://github.com/openstack/rpm-packaging, and I can only find nova.spec.j2 includes placement-api which I think isn't the case.
>>> Wher can I find placement's spec file please as from my understanding it is a seperated service in stein? Any tip is appreciated.
>>> Thanks!
>>>
>>
> 

-- 
Regards
QingFeng Hao



From tbechtold at suse.com  Tue Apr 23 07:08:55 2019
From: tbechtold at suse.com (Thomas Bechtold)
Date: Tue, 23 Apr 2019 09:08:55 +0200
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
Message-ID: <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>

Hi,

On 4/22/19 12:58 PM, QingFeng Hao wrote:
> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
> hope it can work. thanks!

That's the package from RDO (which is Fedora/RedHat specific afaik). 
rpm-packaging currently has no placement package yet.

Best,


Tom



From skaplons at redhat.com  Tue Apr 23 07:14:00 2019
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 23 Apr 2019 09:14:00 +0200
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
Message-ID: <20190423071400.biqzdeewowm2wtmg@skaplons-mac>

Hi,

On Mon, Apr 22, 2019 at 04:05:48PM -0500, Eric Fried wrote:
> > this change might give a lower privileged user (eg a user who cannot
> > specify "ha") the ability to sniff around for the defaults,
> 
> This was the only thing I could think of.
> 
> > but i'm
> > not sure if that information represents a security risk in this case.
> 
> Because they could also find that out by looking at the source code?

But in some corner case it might be even patched and defaults can be different
in some specific cloud.
Maybe for such case we can make this new behaviour configurable? So there would
be some config option which operator can use to disable accepting default values
for forbidden parameters.

> 
> efried
> .
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat


From cgoncalves at redhat.com  Tue Apr 23 07:15:51 2019
From: cgoncalves at redhat.com (Carlos Goncalves)
Date: Tue, 23 Apr 2019 08:15:51 +0100
Subject: [Tripleo][Octavia][OVN] Overcloud deployment Issues with Octavia
In-Reply-To: <CABJHmF55FWJw4VhrS+oOs8HwYVAJBmD-o+AyGRy_hFmkTnw0fA@mail.gmail.com>
References: <CABJHmF55FWJw4VhrS+oOs8HwYVAJBmD-o+AyGRy_hFmkTnw0fA@mail.gmail.com>
Message-ID: <CAM7b86jMeb-d-paeYG4Ni0r92tB_-QOpZ3Q8vMB8iFcsgxo0mA@mail.gmail.com>

Hi Rabi,

Thanks a lot for trying Octavia + OVN provider driver and sharing all
these goodies! Both Octavia and networking-ovn teams have been
actively working to integrate the Octavia OVN driver in TripleO. Your
input will greatly help.

On Mon, Apr 22, 2019 at 1:12 PM Rabi Mishra <ramishra at redhat.com> wrote:
>
> Hi All,
>
> For some Octavia testing with heat, I tried deploying 3+1 node overcloud with Octavia environment and THT master. As expected, deployment finished successfully. However, when trying to do some Octavia API calls (ex. list laodbalancers etc), it was returning (503) Service Unavailable error. Checking the logs of octavia_api container (though the container was running), it was in a continous loop.
>
> I have captured some of these issues (as described below) in https://bugs.launchpad.net/tripleo/+bug/1825146 too. The intent of this mail is to bring it to the notice of the respective teams and understand the best possible way to fix these.
>
> 1. Incorrect config setting for provider_drivers.
>
> As of https://github.com/openstack/puppet-tripleo/commit/97c46ca76803fb238279d24544e8aba9c5685632, we added OVN provider driver support for Octavia. However, the config option seems to be set incorrectly which resulted in octavia-api failing to start.

In case the container is still restarting, you might be hitting
another issue that got fixed by
https://review.opendev.org/#/q/I53610f1c9e3d10bb6b532dd7d43139854c0861b7

>
> 2. ovn_nb_connection not in octavia config
>
> It seems ovn provider driver (part of networking-ovn) connects to ovn nb database as part of initialization. However, we don't seem to configure connection string in octavia.conf and it tries to connect to 127.0.0.1 and fails.
>
> I've already proposed a few patches[1] to fix the above two issues.

Thanks!

>
> 3. Missing Octavia Driver Agent
>
> Octavia had added a driver-agent controller process in Stein (for provider drivers to communicate with the octavia for status and stats update). This process is expected to be collocated with octavia-api and creates a pair of unix domain sockets for communication that the drivers use.
>
> We don't seem to have this implemented in THT yet. Is this something planned and someone working on it?  AFAICT, we can't enable/use the OVN provider driver without adding this service/container?

Yes, it is. Brent plans to work on this at some point in the next
weeks. Our goal is to have a reasonable integration state in Stein.
You'd be more than welcome to help out should you want. Let us know
for better coordination.

>
> Adding support for this in THT also seems little complex and probably can be done in few different ways. Is there a standard design pattern we use for these kind of requirements in Tripleo?  If we already have an agreed plan on how to do it, please ignore below.
>
> I can only think of the few options below.  Probably there are better ones too:)
>
> a. New OctivaDriverAgent Service.
>
> As the process is expected to be co-llocated with octavia-api to share the domain sockets (we can share /var/run/octavia from host on both containers), I'm not sure if this would be a good design though.
>
> b. As a sidecar of octavia_api
>
> Not a new service, but as a sidecar container for octavia-api (started when api starts, do we've something like this already there for other services?).

Brent and I are of the same idea of having the driver agent as a
sidecar container, yes.

>
> Ideas/comments welcome:)
>
> [1] https://review.opendev.org/#/q/status:open+branch:master+topic:bug/1825146
>
> --
> Regards,
> Rabi Mishra


From haoqf at linux.vnet.ibm.com  Tue Apr 23 07:25:47 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Tue, 23 Apr 2019 15:25:47 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
 <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>
Message-ID: <493b1096-e929-1a04-b405-77ecf515fd07@linux.vnet.ibm.com>



在 2019/4/23 15:08, Thomas Bechtold 写道:
> Hi,
> 
> On 4/22/19 12:58 PM, QingFeng Hao wrote:
>> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
>> hope it can work. thanks!
> 
> That's the package from RDO (which is Fedora/RedHat specific afaik). rpm-packaging currently has no placement package yet.
> 
> Best,
> 
Thanks Tom for your tip! I think after I built placement rpm, nova can consume it through '# WSGI apache config for nova-placement-api'
in nova.spec.j2, right?
> 
> Tom
> 

-- 
Regards
QingFeng Hao



From cjeanner at redhat.com  Tue Apr 23 08:42:27 2019
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Tue, 23 Apr 2019 10:42:27 +0200
Subject: [Neutron][TripleO] Avoid dangling sidecars containers - add hook
 support
In-Reply-To: <D76BF5D2-A50D-49AD-A985-8AD5A619F001@redhat.com>
References: <19517c9e-c198-a4d9-abf9-b3a078beb044@redhat.com>
 <D76BF5D2-A50D-49AD-A985-8AD5A619F001@redhat.com>
Message-ID: <b1eb68a3-c02e-1ba9-b38d-fb41bf84028e@redhat.com>

Hey :)

On 4/20/19 9:21 AM, Slawomir Kaplonski wrote:
> Hi,
> 
> IMO this is good idea and You should propose it as RFE on lauchpad.

I've created it in Neutron namespace:
https://bugs.launchpad.net/neutron/+bug/1825943

> It can also help address our current issue with including python process in rootwrap kill filters as it would be maybe not necessary anymore.
> Also, from quick look I think that external_process.ProcessMonitor is ready for something like that as it has possibility to pass „get_stop_command” callback as an argument - see [1]. So maybe it would be not very hard to implement :)

That's good to know then :). Hopefully we'll be able to see that coming
quickly - dangling containers aren't good ^^'.

Cheers,

C.

> 
> [1] https://github.com/openstack/neutron/blob/master/neutron/agent/linux/external_process.py#L98
> 
>> Wiadomość napisana przez Cédric Jeanneret <cjeanner at redhat.com> w dniu 17.04.2019, o godz. 13:09:
>>
>> Dear List,
>>
>> While doing some validations on an "in-use" node, we detected a
>> container being Exited with status 137. After some researches and
>> discussions, it appears this container is launched from a Neutron
>> container, as a sidecar, and then the service is killed:
>>
>> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/external_process.py#L98
>>
>> While the "kill" is fine outside of a container, it leads to some issues
>> in a containerized world:
>> - dangling container is here, with a failed state
>> - validating container state is therefore complicated
>> - might lead to false assumption if we don't know that "kill" process
>> - might lead to disk space issues
>>
>> In order to sort that bad situation out, and prevent disk space issues
>> and the like, I propose to discuss about some "hook" addition in that
>> "external_process.py" (or wherever is more suited for that usage)
>>
>> There is apparently something like that for the service launch, since
>> there are wrapper scripts in /var/lib/neutron.
>> In my idea, that wrapper script could generate a new wrapper used in
>> order to actually delete the container (instead of kill -9 <pid>).
>>
>> The neutron code could be modified in a simple way, something like:
>> ###############
>> if os.path.exists(<wrapper-file>):
>>  utils.execute(['bash', <wrapper-file>])
>> else:
>> # current way to handle things
>> ###############
>>
>> The <wrapper-file> might have "something" in its name in order to ensure
>> we're actually killing the right process/container.
>> self.pid, or maybe some specific string that neutron is aware of... you
>> get the idea.
>>
>> Even outside of a container, that might be used in order to clean
>> temporary configurations/files, and ensure we're actually facing a clean
>> environment.
>> It's really something more like "hooks" than "container-centric thingy"
>>
>> Would you consider that kind of new feature?
>>
>> Thank you for your time and consideration!
>>
>> Cheers,
>>
>> C.
>>
>> -- 
>> Cédric Jeanneret
>> Software Engineer
>> DFG:DF
>>
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/efd88831/attachment.sig>

From thierry at openstack.org  Tue Apr 23 09:13:03 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 23 Apr 2019 11:13:03 +0200
Subject: [release-openstack-python][release pipeline] POST_FAILURE since
 last couple of hours, already known and being fixed?
In-Reply-To: <CAPU8nTGOEXBMHTMj_M69vK38qeuQajyhLAaU1GgtE7wqZ24J1Q@mail.gmail.com>
References: <CAPU8nTGOEXBMHTMj_M69vK38qeuQajyhLAaU1GgtE7wqZ24J1Q@mail.gmail.com>
Message-ID: <d72e247c-8d97-21fe-0551-101eb764623f@openstack.org>

Yatin Karel wrote:
> release-openstack-python[1] job is failing since last couple of hours,
> is this already known and worked upon?
> If it's not being fixed yet good to hold other releases until it's fixed.

We had random occurrences of that bug last week (see [1]), but it now 
seems to be systematically failing. I'll have a look and follow up on 
the original thread.

[1] 
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005255.html

-- 
Thierry Carrez (ttx)


From thierry at openstack.org  Tue Apr 23 09:29:58 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 23 Apr 2019 11:29:58 +0200
Subject: [Release-job-failures] Release of openstack/solum failed
In-Reply-To: <415605cf-ba81-d4ed-a76b-63ad1fb44a64@openstack.org>
References: <E1hGaDR-0007Uq-Bx@zuul01.openstack.org>
 <415605cf-ba81-d4ed-a76b-63ad1fb44a64@openstack.org>
Message-ID: <45617e64-e442-9ff5-afde-dbb17dc52afd@openstack.org>

Thierry Carrez wrote:
> zuul at openstack.org wrote:
>> Build failed.
>>
>> - release-openstack-python 
>> http://logs.openstack.org/19/19a7574237f44807b16c37e0983223ff57340ba3/release/release-openstack-python/769f856/ 
>> : POST_FAILURE in 4m 40s
>> - announce-release announce-release : SKIPPED
>> - propose-update-constraints propose-update-constraints : SKIPPED
> 
> Solum release post-job (triggered by stable/pike 5.4.1 tagging) failed 
> with the following error:
> 
> Ensure twine is installed:
> [
>      "python3",
>      "-m",
>      "pip",
>      "install",
>      "twine!=1.12.0",
>      "readme_renderer[md]!=23.0",
>      "requests-toolbelt!=0.9.0",
>      "--user"
> ]
> Can not perform a '--user' install. User site-packages are not visible 
> in this virtualenv.
> 
> http://logs.openstack.org/19/19a7574237f44807b16c37e0983223ff57340ba3/release/release-openstack-python/769f856/ara-report/result/163bcef4-584f-4f51-8b40-6c45d4e2282a/ 
> 
> 
> This seems to be a new error hitting us recently (also happened for 
> networking-arista, which the release management team does not directly 
> handle). It is weird since the job (exact same command) worked in 
> subsequent runs:
> 
> http://logs.openstack.org/d0/d0d2089455efb6d01a1158bad597f42cf2306c30/release/release-openstack-python/3e92184/ara-report/result/6f1ee497-f721-4f01-80f0-14ea0835cebe/ 

We seem to be hitting the issue more systematically now, with several 
Pike release fails:

horizon 12.0.4
networking-hyperv 5.0.1
os-win 2.2.1
freezer-api 5.0.1
freezer 5.0.1
freezer-web-ui 5.0.1
designate 5.0.3
designate-dashboard 5.0.2
python-freezerclient 1.5.1
python-designateclient 2.7.1
python-ironic-inspector-client 2.1.1
ironic-lib 2.10.2
ironic-python-agent 2.2.4
ironic-ui 3.0.4
ironic 9.1.7
python-ironicclient 1.17.2
freezer-dr 5.0.1

For all of those the tag was pushed, but the job to generate and upload 
a tarball failed, so links on releases.o.o are 404 until we reenqueue them.

-- 
Thierry Carrez (ttx)


From info at dantalion.nl  Tue Apr 23 09:50:37 2019
From: info at dantalion.nl (info at dantalion.nl)
Date: Tue, 23 Apr 2019 11:50:37 +0200
Subject: [Watcher] tomorrows meeting and agenda
Message-ID: <669c74c4-b7bf-ee40-ece5-b7aef7eac95b@dantalion.nl>

Hello everyone,

Tomorrow Watcher will have a meeting again at 08:00 UTC in the
#openstack-meeting-alt channel. This is a reminder since we only
recently started to have meetings again.

The agenda is available on
https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add
any additional items.

Kind Regards,
Corne Lukken (Dantali0n)


From ekuvaja at redhat.com  Tue Apr 23 11:26:46 2019
From: ekuvaja at redhat.com (Erno Kuvaja)
Date: Tue, 23 Apr 2019 12:26:46 +0100
Subject: [Glance] Weekly meetings
Message-ID: <CAKwVDDPySnwBa2ks8Pj1qdp9ucqqFxsvcBNzOYCq+eDG6gGaug@mail.gmail.com>

Hi all,

It's the Summit/PTG disruptions again. So This week Glance will be
having weekly meeting normally at Thu (25th) 14:00, next week we will
be having our meeting face to face in Denver so IRC will be quiet, the
week after Summit, I might not be available to chair meeting if one is
needed but I'll see if Abhishek or Brian can cover me. From Thu 16th
of May you can again expect business as usual from us.

Best,
Erno


From aspiers at suse.com  Tue Apr 23 11:37:11 2019
From: aspiers at suse.com (Adam Spiers)
Date: Tue, 23 Apr 2019 12:37:11 +0100
Subject: Migrating git repos to OpenDev
In-Reply-To: <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
 <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
Message-ID: <20190423113711.naxzsvyrzdtyk4jr@pacific.linksys.moosehall>

Jeremy Stanley <fungi at yuggoth.org> wrote:
>On 2019-04-21 20:50:16 -0400 (-0400), Doug Hellmann wrote:
>[...]
>> So does that mean that old git:// URLs in remotes will need to be
>> updated in local copies?
>[...]
>
>Yes, Gitea doesn't support traditional Git protocol, only Git over
>HTTP/HTTPS. And even if it had, there's no built-in redirect
>functionality with that protocol anyway.
>
>> If I change the URL for the origin remote to
>> https://opendev.org/openstack/releases it works fine. Before I do that
>> in all of my sandboxes, do I need to, or are those old URLs expected to
>> work?
>
>Simply switching the git:// to https:// (or http://) should work,
>courtesy of the redirect sites we've built for git.openstack.org and
>friends.

One quick and easy way to achieve that is:

git config --global url.https://git.openstack.org/.insteadof git://git.openstack.org/


From sombrafam at gmail.com  Tue Apr 23 12:09:30 2019
From: sombrafam at gmail.com (Erlon Cruz)
Date: Tue, 23 Apr 2019 09:09:30 -0300
Subject: [Third Party CI][Cinder] Changes from review.openstack.org to
 review.opedev.org
In-Reply-To: <20190422185645.GA30522@sm-workstation>
References: <20190422114658.GA22166@sm-xps>
 <20190422132801.qhkaahmzt7bkkjg5@yuggoth.org>
 <20190422185645.GA30522@sm-workstation>
Message-ID: <CAF+CadtC-G1PhEMWEhdjr1MsyRwOs++GRtNjUX9yc8adtpAB2g@mail.gmail.com>

Hi Sean,

Thanks for informing. We had noticed that as our CI stopped working. Stream
events still is
working for us, only git clone via ssh is not working.

Erlon

Em seg, 22 de abr de 2019 às 15:59, Sean McGinnis <sean.mcginnis at gmx.com>
escreveu:

> >
> > Any idea why this is failing? While SSH isn't exactly "redirected"
> > in this case, the old and new hostnames go to the exact same server
> > so we fully expect event streaming to work as before. What we
> > *can't* solve with SSH is Git remotes for projects whose namespaces
> > changed during the move, so we've seen some questions from
> > third-party CI operators about failures associated with
> > incorporating unofficial repositories which moved from the
> > "openstack" namespace to the "x" namespace into their jobs.
> > --
> > Jeremy Stanley
>
> Ah, sorry. Maybe it was just that in combination with a host config issue
> I had
> on another machine. I'm probably just crying wolf then.
>
> Mainly, I just wanted to make sure third party CI operators had seen that
> this
> transition work had been done and fix any issues with new host names and
> things. If it is not actually an issue for most, please just consider this
> another avenue for getting the word out about the great work the OpenDev
> Infra
> team did over Friday and the weekend to get everything working as seamless
> as
> possible. ;)
>
> Sean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/bf8326b5/attachment.html>

From lucioseki at gmail.com  Tue Apr 23 12:52:02 2019
From: lucioseki at gmail.com (Lucio Seki)
Date: Tue, 23 Apr 2019 09:52:02 -0300
Subject: Migrating git repos to OpenDev
In-Reply-To: <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
 <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
Message-ID: <CADSUBKp_6+VPQ24rcd9Bq+zaRJutQ_NTvqZDvM0cKRgQ=_QYaQ@mail.gmail.com>

>
> Simply switching the git:// to https:// (or http://) should work,
> courtesy of the redirect sites we've built for git.openstack.org and
> friends.
>
>
For how long will this redirect work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/388843f8/attachment.html>

From ionut at fleio.com  Tue Apr 23 13:01:12 2019
From: ionut at fleio.com (Ionut Biru)
Date: Tue, 23 Apr 2019 16:01:12 +0300
Subject: [octavia][openstack-ansible] network layout example
Message-ID: <CALE96NAtx0DbBD-iouesNVoxQgVHv3sLOKQ5=qe3SPwY_=-W+Q@mail.gmail.com>

Hello guys,

I have hard time understanding how to create the right layout
infrastructure of octavia.
Does anyone have octavia running in production with OSA?

For now I have created a new tagged interface. Is this the right approach?

auto bond0.40
iface bond0.40 inet manual
    vlan-raw-device bond0

auto br-lbaas
iface br-lbaas inet manual
    bridge_stp off
    bridge_waitport 0
    bridge_fd 0
    pre-up ip link add  br-lbaas-veth type veth peer name eth14 || true
    pre-up ip link set br-lbaas-veth up
    pre-up ip link set eth14 up
    post-down ip link del br-lbaas-veth || true
    bridge_ports bond0.40 br-lbaas-veth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/e5a23bff/attachment.html>

From mbooth at redhat.com  Tue Apr 23 13:08:50 2019
From: mbooth at redhat.com (Matthew Booth)
Date: Tue, 23 Apr 2019 14:08:50 +0100
Subject: [nova][cinder] An API to replace volume-update (aka swap-volume)
Message-ID: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>

Consider this a straw-man proposal for the upcoming cross-project
discussion at PTG. I'm not (currently, at any rate) proposing to do
this work myself, which is also why I haven't put this in a spec.

Volume-update is a problematic interface. There are likely many more
than this, but problems which come to mind are:

* It shares state between cinder and nova while running. A failure of
either leaves an inconsistent state which is not easily recoverable.
* It is fragile: it requires an instance is running. Stopping an
instance while it is in progress is undefined at best. It will fail if
an instance is not running.
* It is mis-used by end-users to copy data between different volumes,
which results in an unsupportable strange instance state.
* It is slow.
* It results in data corruption for multiattached volumes

I'd like to propose the following api as a replacement. I'll describe
the contract up top and put some example implementations below. This
new flow for volume migration would be driven entirely by cinder, with
no callbacks from nova, so all of the following are new nova apis.

* volume-migration-start(src_attachment_id)

After returning, nova will not write any data to src until completion
or cancelled. Nova will return an error if it is not able to suspend
writes to src.

Start is a synchronous operation. Nova will not return until it can
guarantee that there will be no further writes to src.

* volume-migration-cancel(src_attachment_id)

Nova will resume writing to src. A subsequent complete call will
return an error.

cancel is an asynchronous operation. Nova assumes it can resume
writing to src immediately, but does not guarantee when it will finish
the cancel operation. This has no impact on cinder, but nova instance
operations may continue to be restricted until the cancel completes.

* volume-migration-complete(src_attachment_id, dst_attachment_id)

Nova expects that dst is a copy of src at the time that
volume-migration-start() was called. Nova will detach from src and
attach dst in its place. Nova will resume reading and writing to dst
immediately.

Nova will not return until it is safe for cinder to remove src, but
the complete operation is not guaranteed to have finished at this
time. This has no impact on cinder, but nova instance operations may
continue to be restricted until it completes asynchronously.

The implementation on the cinder side would be:

volume-migration-start(src_attachment_id)
copy(src, dst)
volume-migration-complete(src, dst)

Cinder doesn't need to be concerned with whether the instance or
running or not, and it always does the copy itself. Using
driver-specific optimisations this has the potential to be very fast,
but even the fallback implementation of a full copy between 2 arrays
should be substantially faster than a qemu block job on the compute
host.

It is entirely up to cinder to ensure this operation is safe wrt
multiattach. I expect 'safe' here to mean it will refuse to do the
operation.

There may also be details to be worked out wrt who creates the dst
attachment. If at all possible, I don't want to expose to nova the
quirk that under cinder's covers a new volume is created which
temporarily has the wrong volume id. I'd prefer that, from nova's POV,
the operation is just a managed switch between 2 attachments to
apparently the same volume.

2 possible implementations on the Nova side:

1. Hypervisor does not support live storage migration
Summary: instance must be shutdown.

volume-migration-start() returns success iff the instance is shutdown.
Nova will set a task state such that instance cannot be started until
cancel or complete.

volume-migration-complete() reconfigures the specific volume
attachment and unsets the task state so the instance can be started.

2. libvirt driver
Summary: libvirt allows writes to continue during the copy by sending
them to a local snapshot, which it commits to dst on complete().

volume-migration-start() sets task state such that instance cannot be
started or stopped until cancel or completion.

If instance is not running, does nothing else.

If instance is running, creates local writeable qcow2 backed by
read-only src volume. Swaps volume to local qcow2.

volume-migration-cancel() does nothing if instance is not running
except unset task state. If instance is running returns success to
cinder immediately before commiting qcow2 to src volume and then
unsetting task state.

volume-migration-complete() updates instance to dst if it's not
running, unsets task state and returns immediately. If instance is
running, rebases local qcow2 from src to dst (cinder guarantees us
that these are identical), then returns success to cinder because src
can now be released. Nova starts a job to commit qcow2 to dst. On
completion it updates instance to use dst and unsets task state.

This API does not handle the case where the hypervisor is only capable
of live storage migration where it manages the entire copy itself. If
we had a requirement to support this we might change
volume-migration-start() to return something indicating that nova will
do the copy, or perhaps indicating that cinder should try again with a
different entry point. However, I believe this approach will always be
slower than a cinder-native copy, and I can't see any way around it
requiring a callback to cinder on completion of the copy. I'd very
much like some feedback from non-libvirt hypervisor folks around
whether they're interested in this functionality at all, and if so
what their capabilities are.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)


From fungi at yuggoth.org  Tue Apr 23 13:19:30 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 13:19:30 +0000
Subject: Migrating git repos to OpenDev
In-Reply-To: <20190423113711.naxzsvyrzdtyk4jr@pacific.linksys.moosehall>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
 <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
 <20190423113711.naxzsvyrzdtyk4jr@pacific.linksys.moosehall>
Message-ID: <20190423131929.odb2ebxw2blv2vwz@yuggoth.org>

On 2019-04-23 12:37:11 +0100 (+0100), Adam Spiers wrote:
> Jeremy Stanley <fungi at yuggoth.org> wrote:
[...]
> > Simply switching the git:// to https:// (or http://) should work,
> > courtesy of the redirect sites we've built for git.openstack.org and
> > friends.
> 
> One quick and easy way to achieve that is:
> 
> git config --global url.https://git.openstack.org/.insteadof git://git.openstack.org/

Great idea. I always forget about git's "insteadof" mapping ability.
It's quite versatile. Thanks for pointing out that option!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/1bcfa51f/attachment-0001.sig>

From fungi at yuggoth.org  Tue Apr 23 13:24:39 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 13:24:39 +0000
Subject: Migrating git repos to OpenDev
In-Reply-To: <CADSUBKp_6+VPQ24rcd9Bq+zaRJutQ_NTvqZDvM0cKRgQ=_QYaQ@mail.gmail.com>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
 <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
 <CADSUBKp_6+VPQ24rcd9Bq+zaRJutQ_NTvqZDvM0cKRgQ=_QYaQ@mail.gmail.com>
Message-ID: <20190423132439.jn6zzt4cq7vcggkj@yuggoth.org>

On 2019-04-23 09:52:02 -0300 (-0300), Lucio Seki wrote:
> >
> > Simply switching the git:// to https:// (or http://) should work,
> > courtesy of the redirect sites we've built for git.openstack.org and
> > friends.
> >
> 
> For how long will this redirect work?

We haven't decided on a sunset date for the git.airshipit.org,
git.openstack.org, git.starlingx.io and git.zuul-ci.org redirects to
opendev.org, nor the review.openstack.org redirect to
review.opendev.org. The maintenance cost for these is minimal, so I
would fully expect it could be on the order of years. There's plenty
of released software out there with references to these old
hostnames, so we have a strong incentive to keep them around and not
break users.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/d7d0b000/attachment.sig>

From lyarwood at redhat.com  Tue Apr 23 13:27:15 2019
From: lyarwood at redhat.com (Lee Yarwood)
Date: Tue, 23 Apr 2019 14:27:15 +0100
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
 <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>
Message-ID: <20190423132715.d5a4e6nlr572qvhg@lyarwood.usersys.redhat.com>

On 22-04-19 08:32:40, Emilien Macchi wrote:
> On Fri, Apr 19, 2019 at 3:38 PM Matt Riedemann <mriedemos at gmail.com> wrote:
> [...]
> 
> > So if people from the TripleO and Kolla teams can reply here and clarify
> > I can get that back into the etherpad before the Forum session.
> >
> 
> As far I know, Piotr (in copy) has taken over Lee's work and the plan is to
> get it merged after the PTG, before Placement is removed in Nova.
> The work is highly prioritized in the our compute team.
> 
> Step 1. (after PTG and before it's removed in Nova) Rebase TripleO work,
> make it pass CI & reviewed by TripleO Core, land it. Target is Train
> Milestone 1.

https://review.opendev.org/#/q/topic:tripleo-placement-extraction+(status:open+OR+status:merged)

FWIW the plan was to land this prior to PTG and thanks to Martin,
Emilien and Alex it actually landed on Friday. All Train based TripleO
deployments should default to using an extracted Placement service.

> Step 2. Clean up TripleO and removing old references to Nova Placement
> service. Target is Train Milestone 2.

https://review.opendev.org/#/q/topic:tripleo-nova-placement-removal+(status:open+OR+status:merged)

With the initial extraction now landed we should be able to land some of
the cleanups ahead of the PTG. I'll help Piotr rebase these and the
various RDO changes now.

> I'll let the compute folks to give more details if needed but I hope it
> answers your question.

https://review.opendev.org/#/q/topic:tripleo-placement-upgrade-from-nova-placement+(status:open++OR+status:merged)

There's additional WIP work to support upgrades from nova-placement in
Stein to an extracted service in Train covered by the above topic. I
don't expect this to be ready by PTG but we will try to have something
running in CI that shows our intent at least.

Cheers,

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/4201932c/attachment.sig>

From dtantsur at redhat.com  Tue Apr 23 13:29:09 2019
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Tue, 23 Apr 2019 15:29:09 +0200
Subject: The python black project.
In-Reply-To: <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
Message-ID: <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>

On 4/19/19 1:05 AM, Monty Taylor wrote:
> 
> 
> On 4/18/19 7:04 PM, Clint Byrum wrote:
>> Quoting Natal Ngétal (2019-04-18 01:51:47)
>>> Hi everyone,
>>>
>>> Black is project to format Python code. It's more and more used by the python
>>> community. That can save time and harmonize the code. For example, simple quote
>>> versus double quote, that was not checked by pep8.i It's just an example of
>>> what make  black With a pre-hook commit hook this will be also avoid to lose
>>> time with pep8 errors.
>>>
>>> Two links to see more:
>>>
>>> https://github.com/ambv/black
>>> https://www.mattlayman.com/blog/2018/python-code-black/
>>>
>>> I think it can be very interesting to start to use Black on OpenStack. What
>>> do you thinks about that? For example, we can introduce it on some projects, I
>>> would volunteer to try on TripleO.
>>
>> I've read the arguments in the thread, and I really appreciate
>> everyone's thoughtfulness here.
>>
>> I just wanted to add that I have been using black for some internal
>> projects, and it is an absolute joy to forget about code formatting.
>> This is different than the pep8 checks. The git hook just does it, and
>> our CI confirms that you do it, and there's no more "oops I forgot
>> pep8".
>>
>> I believe that the whitespace churn that folks are bringing up is being
>> overblown. This is a single, automatically produced diff, that while it
>> might hurt a little in git annotate and conflicts with in-flight patches
>> now, there is value, and there are mitigations, that make it worth it in
>> some cases.
>>
>> The main value is that using an automatic formatter will ultimately lead
>> to less wasted test runs, less wasted developer time, and better diffs
>> with less conflicts later.
>>
>> So while I appreciate the desire to not rock the boat, it might be that
>> the boat would go faster after some dead weight is dropped overboard,
>> and that new energy is applied to forward progress instead of "darn it,
>> now I have to think about how to fit this into 80 chars and parenthesis
>> and ..." >
>> Basically, weigh the one time cost vs. the ongoing savings, rather than
>> considering them separately.
> 
> I think it's useful to point fingers at concrete things if we're going to weigh 
> costs vs savings.
> 
> Here is a patch:
> 
> https://review.openstack.org/653876
> 
> That runs openstacksdk through black and adds it to the pep8 tox env. I had to 
> make two manual code changes, and add two pep8 exclusions.

I quite hate some of the changes it made, e.g. 
https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/_proxy.py at 296 is 
a horrible waste of screen space, while 
https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/node.py at 267 also 
looks pretty weird to me.

> 
> I also did -l 79 - because it's important.
> 
> I'd get so many stackalytics points for the +55540, -39832 :)
> 
> Monty
> 



From msm at redhat.com  Tue Apr 23 13:33:59 2019
From: msm at redhat.com (Michael McCune)
Date: Tue, 23 Apr 2019 09:33:59 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
 <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
Message-ID: <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>

On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski <skaplons at redhat.com> wrote:
> But in some corner case it might be even patched and defaults can be different
> in some specific cloud.

after replying to Nate last night, this was the only corner case i
could think of as well. there /could/ exist a situation  where an
operator has modified the defaults such that they are not in the
upstream source, in this case the "default hunting" could be seen as
an exposure of information. whether that information is useful or not,
i am still not sure about but it's worth noting. good observation =)

> Maybe for such case we can make this new behaviour configurable? So there would
> be some config option which operator can use to disable accepting default values
> for forbidden parameters.

this sounds nice, my concern here would be that it is over-complicated
for operators but maybe i'm just getting too close to the bike shed ;)

peace o/


From ionut at fleio.com  Tue Apr 23 13:47:24 2019
From: ionut at fleio.com (Ionut Biru)
Date: Tue, 23 Apr 2019 16:47:24 +0300
Subject: [magnum] kubernests cinder deploying wordpress
In-Reply-To: <CALE96ND6vKsHNA9vkaQCsabvS_XHq05fdb0t4B=x03DKzHLJTw@mail.gmail.com>
References: <CALE96ND6vKsHNA9vkaQCsabvS_XHq05fdb0t4B=x03DKzHLJTw@mail.gmail.com>
Message-ID: <CALE96NB1RtqV2VV1AUe+eiMx-AryFoXty2a7BG+u+O-DR4EMbg@mail.gmail.com>

Hello,

I did found out how to resolve this issue. In Rocky the default versions
for kubernets and cloud manager are pretty old. I fixed it by creating a
template with the following labels:
--labels kube_tag=v1.13.4,cloud_provider_tag=1.13.1,kube_version=v1.13.4


On Thu, Apr 11, 2019 at 2:14 PM Ionut Biru <ionut at fleio.com> wrote:

> Hello,
>
>
> I'm trying to deploy a simple wordpress installation following the
> documentation from kubernets.
>
> https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
>
> kubernets was deployed using magnum on openstack rocky using the following
> template:
> https://paste.xinu.at/sRk/
>
> Then i'm using the cinder storage class that is described in kubernets
> documentation:
>
> https://kubernetes.io/docs/concepts/storage/storage-classes/#openstack-cinder
> and I also made it default.
>
> I did the following test:
> cinder volume created before hand and used in pod directly with the id,
> the volume is attached and mounted correctly like is described here:
> https://docs.openstack.org/magnum/latest/user/#storage
>
> Now if I try to deploy wordpress using the first link  or other helms that
> use volume claim,  the volume is created automatically by kubernets but
> they are never attached or mounted to the instances.
>
> On master I see the following error:
>
> pv_protection_controller.go:116] PV
> pvc-48fed935-5b61-11e9-9901-fa163e5ebeae failed with : Operation cannot be
> fulfilled on persistentvolumes "pvc-48fed935-5b61-11e9-9901-fa163e5ebea>
> the object has been modified; please apply your changes to the latest
> version and try again
>
> Is there something I miss? I'm using the wrong version of fedora-atomic?
> It's the latest version available for download.
>
> I did find that someone else had this error but not with cinder:
> https://github.com/kubernetes/kubernetes/issues/72905
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/efc5000b/attachment.html>

From sean.mcginnis at gmx.com  Tue Apr 23 13:55:21 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Tue, 23 Apr 2019 08:55:21 -0500
Subject: [nova][cinder] An API to replace volume-update (aka swap-volume)
In-Reply-To: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>
References: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>
Message-ID: <20190423135520.GA16498@sm-workstation>

>
> I'd like to propose the following api as a replacement. I'll describe
> the contract up top and put some example implementations below. This
> new flow for volume migration would be driven entirely by cinder, with
> no callbacks from nova, so all of the following are new nova apis.
>

Overall I really like this proposal from a high level. Some additional data
points below that folks need to keep in mind as we think through how this could
work.

>
> Nova expects that dst is a copy of src at the time that
> volume-migration-start() was called. Nova will detach from src and
> attach dst in its place. Nova will resume reading and writing to dst
> immediately.
>

You actually mean volume-migration-complete, right?

>
> The implementation on the cinder side would be:
>
> volume-migration-start(src_attachment_id)
> copy(src, dst)
> volume-migration-complete(src, dst)
>
> Cinder doesn't need to be concerned with whether the instance or
> running or not, and it always does the copy itself.

This could be problematic.

This works great if the migration is from one volume to another volume on the
same backend. In that case it could be very fast (for some backends almost
instantaneous).

If the migration needs to take place between two different backends, then we
could have a problem. In that case, both the source and destination volumes
would need to be mounted on some host to perform basically a dd from one to the
other.

The Nova host already has access to the volume, so doing it there avoids the
need to set up any other access to the volumes. Otherwise we need to mount both
volumes to the c-vol host to do the copy, putting Cinder in the data path.

We have some existing gotchas with things like image copy for this that we've
considered creating some kind of c-data data mover service that could be scaled
out to multiple nodes and support different protocols. The biggest issue today
is ensuring the Cinder node supports the storage transport protocol needed to
access the volume - fibre channel HBAs or network connectivity for iSCSI.

Not saying this is a showstopper. I'm just making sure folks are aware of it so
we don't start off under any assumptions that having Cinder take care of the
migration is going to be a no brainer.



From openstack at nemebean.com  Tue Apr 23 13:57:55 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Tue, 23 Apr 2019 08:57:55 -0500
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
 <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
 <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>
Message-ID: <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>



On 4/23/19 8:33 AM, Michael McCune wrote:
> On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski <skaplons at redhat.com> wrote:
>> But in some corner case it might be even patched and defaults can be different
>> in some specific cloud.
> 
> after replying to Nate last night, this was the only corner case i
> could think of as well. there /could/ exist a situation  where an
> operator has modified the defaults such that they are not in the
> upstream source, in this case the "default hunting" could be seen as
> an exposure of information. whether that information is useful or not,
> i am still not sure about but it's worth noting. good observation =)

Assuming you have permission to make the API call in the first place, 
wouldn't you be able to determine the defaults based on the results of 
the API call anyway? As in, I create a network and don't pass any value 
for the shared attribute, then I look at the created network and see 
that shared is False by default.

Maybe there are defaults that aren't so easily observable, but in 
general I wouldn't consider them sensitive data. However, I am not a 
security guru so take my opinion for what it's worth.

> 
>> Maybe for such case we can make this new behaviour configurable? So there would
>> be some config option which operator can use to disable accepting default values
>> for forbidden parameters.
> 
> this sounds nice, my concern here would be that it is over-complicated
> for operators but maybe i'm just getting too close to the bike shed ;)
> 
> peace o/
> 


From mbooth at redhat.com  Tue Apr 23 14:00:40 2019
From: mbooth at redhat.com (Matthew Booth)
Date: Tue, 23 Apr 2019 15:00:40 +0100
Subject: [nova][cinder] An API to replace volume-update (aka swap-volume)
In-Reply-To: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>
References: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>
Message-ID: <CAEkQehfN5EOPxQMt1Rg88x5xCyW=chx0ZCVYGbKuwHb=Sgh4eQ@mail.gmail.com>

There's something I didn't mention below, which is which interface to
use to make the rpc calls described. We currently use the
public-facing rest api, which is a problem when users call it in ways
we didn't intend. This isn't really an end-user feature, though, so if
there were some other private rpc mechanism that would be good to
explore. Matt Riedemann mentioned os-server-external-events in IRC,
which we use for volume extend. I haven't looked into this yet, but my
first thought is that it sounds like an asynchronous notification
mechanism. If so we unfortunately wouldn't be able to use it for the
proposal below, as we would need something synchronous. For example,
in the proposal below cinder needs to call start() *and wait for nova
to return success* before it is safe to start the data copy. This
isn't the case for volume extend, where cinder simply notifies nova on
completion and no further coordination is required.

However, if there is any way to use os-server-external-events, or any
other non-public rpc mechanism, it would be good to discuss that.

Matt

On Tue, 23 Apr 2019 at 14:08, Matthew Booth <mbooth at redhat.com> wrote:
>
> Consider this a straw-man proposal for the upcoming cross-project
> discussion at PTG. I'm not (currently, at any rate) proposing to do
> this work myself, which is also why I haven't put this in a spec.
>
> Volume-update is a problematic interface. There are likely many more
> than this, but problems which come to mind are:
>
> * It shares state between cinder and nova while running. A failure of
> either leaves an inconsistent state which is not easily recoverable.
> * It is fragile: it requires an instance is running. Stopping an
> instance while it is in progress is undefined at best. It will fail if
> an instance is not running.
> * It is mis-used by end-users to copy data between different volumes,
> which results in an unsupportable strange instance state.
> * It is slow.
> * It results in data corruption for multiattached volumes
>
> I'd like to propose the following api as a replacement. I'll describe
> the contract up top and put some example implementations below. This
> new flow for volume migration would be driven entirely by cinder, with
> no callbacks from nova, so all of the following are new nova apis.
>
> * volume-migration-start(src_attachment_id)
>
> After returning, nova will not write any data to src until completion
> or cancelled. Nova will return an error if it is not able to suspend
> writes to src.
>
> Start is a synchronous operation. Nova will not return until it can
> guarantee that there will be no further writes to src.
>
> * volume-migration-cancel(src_attachment_id)
>
> Nova will resume writing to src. A subsequent complete call will
> return an error.
>
> cancel is an asynchronous operation. Nova assumes it can resume
> writing to src immediately, but does not guarantee when it will finish
> the cancel operation. This has no impact on cinder, but nova instance
> operations may continue to be restricted until the cancel completes.
>
> * volume-migration-complete(src_attachment_id, dst_attachment_id)
>
> Nova expects that dst is a copy of src at the time that
> volume-migration-start() was called. Nova will detach from src and
> attach dst in its place. Nova will resume reading and writing to dst
> immediately.
>
> Nova will not return until it is safe for cinder to remove src, but
> the complete operation is not guaranteed to have finished at this
> time. This has no impact on cinder, but nova instance operations may
> continue to be restricted until it completes asynchronously.
>
> The implementation on the cinder side would be:
>
> volume-migration-start(src_attachment_id)
> copy(src, dst)
> volume-migration-complete(src, dst)
>
> Cinder doesn't need to be concerned with whether the instance or
> running or not, and it always does the copy itself. Using
> driver-specific optimisations this has the potential to be very fast,
> but even the fallback implementation of a full copy between 2 arrays
> should be substantially faster than a qemu block job on the compute
> host.
>
> It is entirely up to cinder to ensure this operation is safe wrt
> multiattach. I expect 'safe' here to mean it will refuse to do the
> operation.
>
> There may also be details to be worked out wrt who creates the dst
> attachment. If at all possible, I don't want to expose to nova the
> quirk that under cinder's covers a new volume is created which
> temporarily has the wrong volume id. I'd prefer that, from nova's POV,
> the operation is just a managed switch between 2 attachments to
> apparently the same volume.
>
> 2 possible implementations on the Nova side:
>
> 1. Hypervisor does not support live storage migration
> Summary: instance must be shutdown.
>
> volume-migration-start() returns success iff the instance is shutdown.
> Nova will set a task state such that instance cannot be started until
> cancel or complete.
>
> volume-migration-complete() reconfigures the specific volume
> attachment and unsets the task state so the instance can be started.
>
> 2. libvirt driver
> Summary: libvirt allows writes to continue during the copy by sending
> them to a local snapshot, which it commits to dst on complete().
>
> volume-migration-start() sets task state such that instance cannot be
> started or stopped until cancel or completion.
>
> If instance is not running, does nothing else.
>
> If instance is running, creates local writeable qcow2 backed by
> read-only src volume. Swaps volume to local qcow2.
>
> volume-migration-cancel() does nothing if instance is not running
> except unset task state. If instance is running returns success to
> cinder immediately before commiting qcow2 to src volume and then
> unsetting task state.
>
> volume-migration-complete() updates instance to dst if it's not
> running, unsets task state and returns immediately. If instance is
> running, rebases local qcow2 from src to dst (cinder guarantees us
> that these are identical), then returns success to cinder because src
> can now be released. Nova starts a job to commit qcow2 to dst. On
> completion it updates instance to use dst and unsets task state.
>
> This API does not handle the case where the hypervisor is only capable
> of live storage migration where it manages the entire copy itself. If
> we had a requirement to support this we might change
> volume-migration-start() to return something indicating that nova will
> do the copy, or perhaps indicating that cinder should try again with a
> different entry point. However, I believe this approach will always be
> slower than a cinder-native copy, and I can't see any way around it
> requiring a callback to cinder on completion of the copy. I'd very
> much like some feedback from non-libvirt hypervisor folks around
> whether they're interested in this functionality at all, and if so
> what their capabilities are.
>
> Matt
> --
> Matthew Booth
> Red Hat OpenStack Engineer, Compute DFG
>
> Phone: +442070094448 (UK)



-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)


From msm at redhat.com  Tue Apr 23 14:22:27 2019
From: msm at redhat.com (Michael McCune)
Date: Tue, 23 Apr 2019 10:22:27 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
 <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
 <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>
 <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>
Message-ID: <CADE+ktQYEUwhUze9G+62Hb9EHS4=0xBp14a8Svzc5uTtBXwOdw@mail.gmail.com>

On Tue, Apr 23, 2019 at 10:05 AM Ben Nemec <openstack at nemebean.com> wrote:
> Assuming you have permission to make the API call in the first place,
> wouldn't you be able to determine the defaults based on the results of
> the API call anyway? As in, I create a network and don't pass any value
> for the shared attribute, then I look at the created network and see
> that shared is False by default.
>

that makes reasonable sense to me, and i would imagine something similar.

> Maybe there are defaults that aren't so easily observable, but in
> general I wouldn't consider them sensitive data. However, I am not a
> security guru so take my opinion for what it's worth.

yeah, for me this is where i would rather a neutron expert respond. i
would like to agree with your reasoning as it makes good sense, and i
think this is a relatively minor issue, but i am just not fully aware
of the extent.

i don't want to make this into a bigger issue than it is, i'm just
pointing it out for greater inspection. it sounds like this is a minor
issue and most likely won't cause any security risk.

peace o/


From rico.lin.guanyu at gmail.com  Tue Apr 23 14:26:27 2019
From: rico.lin.guanyu at gmail.com (Rico Lin)
Date: Tue, 23 Apr 2019 22:26:27 +0800
Subject: Scuba Diving at the Denver Summit
In-Reply-To: <CAMVtB2G=6VAirJE=i=QGz-6pUhLd7gzcB=Fsi6bhtCF752cVuA@mail.gmail.com>
References: <1a05abf3-edb5-c9c9-708e-b24e12cab8be@inaugust.com>
 <CA+WCyyoGX3yzJtQvvcXQrQ0oKFdxAiirWp2j533Ts6Y+FYSrHQ@mail.gmail.com>
 <9cd4d330-5812-0b12-b783-017d23b2fd66@inaugust.com>
 <CAEzGLDhEp+5SadZy9fB1Sc20v1ud85ybtooaTXY_HhtKC2RJTw@mail.gmail.com>
 <CAMVtB2G=6VAirJE=i=QGz-6pUhLd7gzcB=Fsi6bhtCF752cVuA@mail.gmail.com>
Message-ID: <CA+WCyyp+2G7F7f9GxJVoCa-1UsQh1i48o83RVacB6v-TkPuZdg@mail.gmail.com>

For your information,

We're also going to have a dive with sharks on 27, April.
So if you're interested in join and like to have some company (there still
2 in stock for that day), here's the link
https://www.a1scuba.com/product/dive-with-the-sharks/

On Fri, Apr 19, 2019 at 11:21 PM Melvin Hillsman <mrhillsman at gmail.com>
wrote:

> I wish I would have saw this earlier, sounds like fun. Will not be able to
> make it but hope it is a great experience for you all.
>
> On Fri, Apr 19, 2019 at 10:05 AM Miguel Lavalle <miguel at mlavalle.com>
> wrote:
>
>> Hi,
>>
>> I get to Denver on Sunday 28th in the morning, so I booked the shark dive
>> for that day. In case others want to join me, as of April 19th at 1700UTC
>> there are still 5 spots available.
>>
>> See you there!
>>
>> On Thu, Apr 18, 2019 at 11:11 AM Monty Taylor <mordred at inaugust.com>
>> wrote:
>>
>>> Hey folks!
>>>
>>> So - I have good news and bad news. I'll start with the bad news.
>>>
>>> The bad news is that there wasn't enough interest to justify booking a
>>> private dive. (There was also *no* interest in homestead crater) So
>>> we're down to just booking slots in their regularly scheduled dives on
>>> the weekend.
>>>
>>> The good news is that there are still spaces available for booking. So I
>>> recommend going to:
>>>
>>> https://a1scubastore.com/product/dive-with-the-fish/
>>> https://a1scubastore.com/product/dive-with-the-sharks/
>>>
>>> and booking a dive directly.
>>>
>>> Sandy and I booked dive with the fish for Saturday (because I've got a
>>> board meeting on Sunday) Dive with the Fish is also now full (we got the
>>> last slots)
>>>
>>> I sent a message to the dive shop to see if it's possible for us to
>>> _also_ do the shark dive on the same day. It is - so if any of you are
>>> interested in doing the Saturday shark dive, let me know and I'll book
>>> spots for Sandy and I for the shark dive as well. But go ahead and book
>>> yourself a spot - so we can make sure you get to dive before we book a
>>> second spot.
>>>
>>> If that doesn't work for people, or if you prefer to do the fish dive on
>>> Sunday - don't worry about us.
>>>
>>> Monty
>>>
>>> On 4/18/19 7:05 AM, Rico Lin wrote:
>>> > We usually need to reraise important stuff before Summit. So bump this
>>> > one!:) Can't wait!
>>> >
>>> > On Wed, Jan 23, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com
>>> > <mailto:mordred at inaugust.com>> wrote:
>>> >
>>> >     Hey everybody!
>>> >
>>> >     tl;dr - Let me know if you'd like to go diving in the Rocky
>>> Mountains.
>>> >
>>> >     Of all of the places we've had a Summit where one might reasonably
>>> >     expect there to be a possibility of Scuba Diving, the Denver
>>> Summit is
>>> >     probably REALLY low on the list.
>>> >
>>> >     But it turns out that there is a Dive Shop that does dives at the
>>> >     Denver
>>> >     Aquarium [0] (with all the fish and sharks and whatnot) The Denver
>>> >     Aquarium is also very close to the Convention Center.
>>> >
>>> >     I'm going to see about putting together a private group dive event
>>> for
>>> >     those of us who think that sounds like a fun idea. Due to
>>> >     cross-contamination concerns for the health and safety of the
>>> fish, the
>>> >     dive shop provides all equipment - so you don't have to bring gear.
>>> >     They
>>> >     will allow bringing your own mask - and I'm assuming if a
>>> well-scrubbed
>>> >     mask is ok then a well-scrubbed dive computer would be ok - but
>>> I'll be
>>> >     checking with them when I call to arrange things.
>>> >
>>> >     If you are Open Water certified and would like to join, please send
>>> >     me a
>>> >     response back (reply directly to me rather than the list is fine)
>>> so I
>>> >     can judge general interest level when talking to the lovely humans.
>>> >
>>> >     If you are **NOT** Open Water certified but are thinking to
>>> yourself
>>> >     "wow, that sounds like fun" - the dive shop does certification
>>> dives at
>>> >     the aquarium on the weekends. That's a bit out of scope for me to
>>> >     arrange, but if you want to show up in Denver early and do an Open
>>> >     Water
>>> >     class then join us, that's awesome. You can also get certified at
>>> home
>>> >     before coming ... but you'll need an Open Water certification to
>>> >     join us.
>>> >
>>> >     BUT WAIT - THERE'S MORE!
>>> >
>>> >     There is another interesting diving opportunity in the general
>>> Mountain
>>> >     West area - although not immediately **close** to Denver - that
>>> Sandy
>>> >     and I are going to be going to before the Summit - Homestead
>>> Crater.
>>> >     We're arranging to meet a Scuba instructor there to do our second
>>> >     Altitude cert dive, and also to do a 2-dive "Hot Springs Diver"
>>> >     specialty. We'd be happy to have folks join us.
>>> >
>>> >     Homestead Crater [1] is outside of Salt Lake City. It's a hot
>>> spring -
>>> >     the water is 96F/35.5C and it's also an altitude dive. If people
>>> are
>>> >     interested, we can meet at the crater on Thursday morning
>>> pre-summit,
>>> >     dive the crater, then drive to Denver on Friday/Saturday.
>>> >
>>> >     ** If only a small number of people are interested in any of this -
>>> >     we'll likely just do the Denver dives the weekend before during
>>> one of
>>> >     the normally scheduled dive times instead of arranging a group
>>> outing,
>>> >     and shift Homestead, if anyone is interested, a few days earlier **
>>> >
>>> >     I will not have space enough in my car to get you from the crater
>>> to
>>> >     Denver, so if you want to fly in to SLC ahead of time and meet
>>> there,
>>> >     awesome.
>>> >
>>> >     Unlike Denver, the crater will require you have equipment,
>>> including
>>> >     scuba tanks. For anyone interested in coming, there are dive shops
>>> in
>>> >     Salt Lake where you can rent gear. There is a dive shop at the
>>> >     crater to
>>> >     do air fills.
>>> >
>>> >     Anyway - if anyone is interested in some or all of these things,
>>> let me
>>> >     know this week so I can get a headcount and then we can talk more
>>> >     off-list about logistics and figure out how to deal with things for
>>> >     people coming from far off (carpools, equipment, etc)
>>> >
>>> >     Monty
>>> >
>>> >     PS. If any of you aren't already using Subsurface for dive logging,
>>> >     I'll
>>> >     be happy to help you get set up.
>>> >
>>> >     [0] https://divedowntown.com/
>>> >     [1]
>>> >
>>> https://homesteadresort.com/utah-resort-things-to-do/homestead-crater/
>>> >
>>> >
>>> >
>>> > --
>>> > May The Force of OpenStack Be With You,
>>> > */Rico Lin
>>> > /*irc: ricolin
>>> >
>>> >
>>>
>>>
>
> --
> Kind regards,
>
> Melvin Hillsman
> mrhillsman at gmail.com
> mobile: (832) 264-2646
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/2c24f323/attachment-0001.html>

From mriedemos at gmail.com  Tue Apr 23 14:33:11 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 23 Apr 2019 09:33:11 -0500
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <20190423132715.d5a4e6nlr572qvhg@lyarwood.usersys.redhat.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
 <CACu=hyt8GNsV3Azk82vC6X7kjcQPe=4FEXKMsCz3-NhqMUzi=A@mail.gmail.com>
 <20190423132715.d5a4e6nlr572qvhg@lyarwood.usersys.redhat.com>
Message-ID: <2d974c22-0753-6b0f-3005-4738faa7c52b@gmail.com>

On 4/23/2019 8:27 AM, Lee Yarwood wrote:
>> As far I know, Piotr (in copy) has taken over Lee's work and the plan is to
>> get it merged after the PTG, before Placement is removed in Nova.
>> The work is highly prioritized in the our compute team.
>>
>> Step 1. (after PTG and before it's removed in Nova) Rebase TripleO work,
>> make it pass CI & reviewed by TripleO Core, land it. Target is Train
>> Milestone 1.
> https://review.opendev.org/#/q/topic:tripleo-placement-extraction+(status:open+OR+status:merged)
> 
> FWIW the plan was to land this prior to PTG and thanks to Martin,
> Emilien and Alex it actually landed on Friday. All Train based TripleO
> deployments should default to using an extracted Placement service.
> 
>> Step 2. Clean up TripleO and removing old references to Nova Placement
>> service. Target is Train Milestone 2.
> https://review.opendev.org/#/q/topic:tripleo-nova-placement-removal+(status:open+OR+status:merged)
> 
> With the initial extraction now landed we should be able to land some of
> the cleanups ahead of the PTG. I'll help Piotr rebase these and the
> various RDO changes now.
> 
>> I'll let the compute folks to give more details if needed but I hope it
>> answers your question.
> https://review.opendev.org/#/q/topic:tripleo-placement-upgrade-from-nova-placement+(status:open++OR+status:merged)
> 
> There's additional WIP work to support upgrades from nova-placement in
> Stein to an extracted service in Train covered by the above topic. I
> don't expect this to be ready by PTG but we will try to have something
> running in CI that shows our intent at least.

Thanks Lee, this is great detail. I've updated the Forum etherpad.

-- 

Thanks,

Matt


From smooney at redhat.com  Tue Apr 23 14:39:48 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 15:39:48 +0100
Subject: The python black project.
In-Reply-To: <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
Message-ID: <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>

On Tue, 2019-04-23 at 15:29 +0200, Dmitry Tantsur wrote:
> On 4/19/19 1:05 AM, Monty Taylor wrote:
> > 
> > 
> > On 4/18/19 7:04 PM, Clint Byrum wrote:
> > > Quoting Natal Ngétal (2019-04-18 01:51:47)
> > > > Hi everyone,
> > > > 
> > > > Black is project to format Python code. It's more and more used by the python
> > > > community. That can save time and harmonize the code. For example, simple quote
> > > > versus double quote, that was not checked by pep8.i It's just an example of
> > > > what make  black With a pre-hook commit hook this will be also avoid to lose
> > > > time with pep8 errors.
> > > > 
> > > > Two links to see more:
> > > > 
> > > > https://github.com/ambv/black
> > > > https://www.mattlayman.com/blog/2018/python-code-black/
> > > > 
> > > > I think it can be very interesting to start to use Black on OpenStack. What
> > > > do you thinks about that? For example, we can introduce it on some projects, I
> > > > would volunteer to try on TripleO.
> > > 
> > > I've read the arguments in the thread, and I really appreciate
> > > everyone's thoughtfulness here.
> > > 
> > > I just wanted to add that I have been using black for some internal
> > > projects, and it is an absolute joy to forget about code formatting.
> > > This is different than the pep8 checks. The git hook just does it, and
> > > our CI confirms that you do it, and there's no more "oops I forgot
> > > pep8".
> > > 
> > > I believe that the whitespace churn that folks are bringing up is being
> > > overblown. This is a single, automatically produced diff, that while it
> > > might hurt a little in git annotate and conflicts with in-flight patches
> > > now, there is value, and there are mitigations, that make it worth it in
> > > some cases.
> > > 
> > > The main value is that using an automatic formatter will ultimately lead
> > > to less wasted test runs, less wasted developer time, and better diffs
> > > with less conflicts later.
> > > 
> > > So while I appreciate the desire to not rock the boat, it might be that
> > > the boat would go faster after some dead weight is dropped overboard,
> > > and that new energy is applied to forward progress instead of "darn it,
> > > now I have to think about how to fit this into 80 chars and parenthesis
> > > and ..." >
> > > Basically, weigh the one time cost vs. the ongoing savings, rather than
> > > considering them separately.
> > 
> > I think it's useful to point fingers at concrete things if we're going to weigh 
> > costs vs savings.
> > 
> > Here is a patch:
> > 
> > https://review.openstack.org/653876
> > 
> > That runs openstacksdk through black and adds it to the pep8 tox env. I had to 
> > make two manual code changes, and add two pep8 exclusions.
> 
> I quite hate some of the changes it made, e.g. 
> https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/_proxy.py at 296 is 
> a horrible waste of screen space, while 
> https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/node.py at 267 also 
> looks pretty weird to me.

  ya i think i could get more behind autopep8 or yapf.
  running   autopep8  on nova https://review.opendev.org/#/c/655171/ has very little change

  litrally adding 1 empty new line to  to 102 files that 
  with almost 0 other code curn.
  using autopep8 however would fix any actul pep8 issue in new patches automatically
  without the downsides of black.

> 
> > 
> > I also did -l 79 - because it's important.
> > 
> > I'd get so many stackalytics points for the +55540, -39832 :)
> > 
> > Monty
> > 
> 
> 



From mbooth at redhat.com  Tue Apr 23 14:43:50 2019
From: mbooth at redhat.com (Matthew Booth)
Date: Tue, 23 Apr 2019 15:43:50 +0100
Subject: [nova][cinder] An API to replace volume-update (aka swap-volume)
In-Reply-To: <20190423135520.GA16498@sm-workstation>
References: <CAEkQehewsr8o7t5U+T_byd2ebqcJLoEd19GNR=0wAXsi9+0=ZQ@mail.gmail.com>
 <20190423135520.GA16498@sm-workstation>
Message-ID: <CAEkQehd3ybAiLnP-FzfZJ0uiXKZBfjLv_ZFJYyaWEG4+8xntoA@mail.gmail.com>

On Tue, 23 Apr 2019 at 14:55, Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>
> >
> > I'd like to propose the following api as a replacement. I'll describe
> > the contract up top and put some example implementations below. This
> > new flow for volume migration would be driven entirely by cinder, with
> > no callbacks from nova, so all of the following are new nova apis.
> >
>
> Overall I really like this proposal from a high level. Some additional data
> points below that folks need to keep in mind as we think through how this could
> work.
>
> >
> > Nova expects that dst is a copy of src at the time that
> > volume-migration-start() was called. Nova will detach from src and
> > attach dst in its place. Nova will resume reading and writing to dst
> > immediately.
> >
>
> You actually mean volume-migration-complete, right?

No. src goes read-only after start(), then cinder copies it to dst. So
at the time cinder calls complete(), dst is going to be a copy of src
from the time start() was called. cinder doesn't know (or need to
know) anything about the overlay nova created locally. All cinder
cares about is that nothing writes to src after it calls start(), and
it must copy this data to dst.

>
> >
> > The implementation on the cinder side would be:
> >
> > volume-migration-start(src_attachment_id)
> > copy(src, dst)
> > volume-migration-complete(src, dst)
> >
> > Cinder doesn't need to be concerned with whether the instance or
> > running or not, and it always does the copy itself.
>
> This could be problematic.
>
> This works great if the migration is from one volume to another volume on the
> same backend. In that case it could be very fast (for some backends almost
> instantaneous).
>
> If the migration needs to take place between two different backends, then we
> could have a problem. In that case, both the source and destination volumes
> would need to be mounted on some host to perform basically a dd from one to the
> other.
>
> The Nova host already has access to the volume, so doing it there avoids the
> need to set up any other access to the volumes. Otherwise we need to mount both
> volumes to the c-vol host to do the copy, putting Cinder in the data path.
>
> We have some existing gotchas with things like image copy for this that we've
> considered creating some kind of c-data data mover service that could be scaled
> out to multiple nodes and support different protocols. The biggest issue today
> is ensuring the Cinder node supports the storage transport protocol needed to
> access the volume - fibre channel HBAs or network connectivity for iSCSI.

Right, I was assuming there would be a fallback, and it would
basically be as slow and ugly as if nova did it. The difference is
that if nova does it it's always going to be slow as we can never take
advantage of backend features, and it's always going to be ugly
because storage isn't our thing, and we have no plans for an n-data
data mover service ;)

> Not saying this is a showstopper. I'm just making sure folks are aware of it so
> we don't start off under any assumptions that having Cinder take care of the
> migration is going to be a no brainer.

Understood.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)


From haleyb.dev at gmail.com  Tue Apr 23 15:01:36 2019
From: haleyb.dev at gmail.com (Brian Haley)
Date: Tue, 23 Apr 2019 11:01:36 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
 <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
 <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>
 <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>
Message-ID: <ef9c0632-3f7e-f8b6-50b5-4d2af0262d90@gmail.com>

On 4/23/19 9:57 AM, Ben Nemec wrote:
> 
> 
> On 4/23/19 8:33 AM, Michael McCune wrote:
>> On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski <skaplons at redhat.com> 
>> wrote:
>>> But in some corner case it might be even patched and defaults can be 
>>> different
>>> in some specific cloud.
>>
>> after replying to Nate last night, this was the only corner case i
>> could think of as well. there /could/ exist a situation  where an
>> operator has modified the defaults such that they are not in the
>> upstream source, in this case the "default hunting" could be seen as
>> an exposure of information. whether that information is useful or not,
>> i am still not sure about but it's worth noting. good observation =)
> 
> Assuming you have permission to make the API call in the first place, 
> wouldn't you be able to determine the defaults based on the results of 
> the API call anyway? As in, I create a network and don't pass any value 
> for the shared attribute, then I look at the created network and see 
> that shared is False by default.

Maybe an example would make it clearer.  If as an admin I want to enable 
DVR and L3-HA, I make some changes in neutron.conf to set that as the 
default.  When a user creates a router there will be many objects 
created and extra daemons spawned, as opposed to the case when there is 
just centralized routing.  An 'openstack router show routerX' won't 
return the distributed or ha values in the API response unless you are 
the admin user, so there isn't a way to determine the defaults.

> Maybe there are defaults that aren't so easily observable, but in 
> general I wouldn't consider them sensitive data. However, I am not a 
> security guru so take my opinion for what it's worth.

In the above case, is knowledge of the router type sensitive data? 
Probably not, if I'm remembering correctly I think we kept them hidden 
since it's the admin that made the decision on the deployment, and users 
might get confused.  But if you knew your router was distributed then 
you'd know there was something local to your hypervisor (router 
namespace), instead of only on a remote controller node.  Again, 
probably not an issue, but it does let you know what additional agents 
might be running where your instance is.

Nate - I'm assuming your changes wouldn't allow users to figure 
something like this out based on making a series of API calls?

-Brian


From alifshit at redhat.com  Tue Apr 23 15:41:49 2019
From: alifshit at redhat.com (Artom Lifshitz)
Date: Tue, 23 Apr 2019 11:41:49 -0400
Subject: [nova] Running multinode resize tests in the gate
In-Reply-To: <cab46f13-d51b-ebc6-1a8a-1952780228f9@gmail.com>
References: <CACqyMieRt4ONj6wU=Q2K-vxVeqduoTmvWY2VtroE7drFHHAcvg@mail.gmail.com>
 <cab46f13-d51b-ebc6-1a8a-1952780228f9@gmail.com>
Message-ID: <CACqyMif7vBhAE2XraDY=sf-fs-1OxzuizS5z8nU+kFRy9pjT3A@mail.gmail.com>

 in h

On Fri, Apr 19, 2019 at 4:42 PM Matt Riedemann <mriedemos at gmail.com> wrote:
> So...enabling resize tests in nova-live-migration is probably the best
> option at this point, and yeah likely means renaming it as well (since
> it's already confusingly named nova-live-migration but also runs
> evacuate tests too via a post-test hook). The only thing I worry about
> with that one is needing to keep a regex of tempest tests we run, but
> technically we're already doing that for the live migration tests [2].
>
> Maybe it's time to bite the bullet and use a real rc file like we have
> for some other jobs, e.g. [3].

I don't think that's going to be possible, given that we do things
like change Tempest settings [4] and start Glance [5], and then the
evacuate tests force down a compute [6]. But maybe the resize tests
can at least use a real rc file. I'll re-work the patch [7] and un-DNM
it.

[4] https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/nova/tests/live_migration/hooks/run_tests.sh#L35
[5] https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/nova/tests/live_migration/hooks/run_tests.sh#L51
[6] https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/gate/test_evacuate.sh#L59
[7] https://review.openstack.org/#/c/653498/

>
> [1]
> https://github.com/openstack/nova/commit/95e782dfd86caa4201d28ee86ba2bb475e0a409f#diff-7415f5ff7beee2cdf9ffe31e12e4c086
> [2]
> https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/nova/tests/live_migration/hooks/run_tests.sh#L29
> [3]
> https://github.com/openstack/nova/blob/95e782dfd86caa4201d28ee86ba2bb475e0a409f/devstack/tempest-dsvm-lvm-rc
>
> --
>
> Thanks,
>
> Matt


From nate.johnston at redhat.com  Tue Apr 23 15:47:59 2019
From: nate.johnston at redhat.com (Nate Johnston)
Date: Tue, 23 Apr 2019 11:47:59 -0400
Subject: [api-sig][neutron] Question on oslo policy assertion when
 supplied attribute equals the default
In-Reply-To: <ef9c0632-3f7e-f8b6-50b5-4d2af0262d90@gmail.com>
References: <20190422195928.5i2ld3o4exk3fmv7@bishop>
 <CADE+ktQasc_7etRQ+0mkPrn2tgozy+TZfVSvqgpf_8wpzuE8ig@mail.gmail.com>
 <332076ec-f746-b5a9-5a8d-3dde424162f9@fried.cc>
 <20190423071400.biqzdeewowm2wtmg@skaplons-mac>
 <CADE+ktSP3V7mPgZ4r3WBsfB1kdm4rPWFTf1jNcZzE5nHDgcSmg@mail.gmail.com>
 <aa9b69b6-7c8f-0f26-2ce1-4ca86d54b945@nemebean.com>
 <ef9c0632-3f7e-f8b6-50b5-4d2af0262d90@gmail.com>
Message-ID: <20190423154759.xqtrvyqqmtu5dutw@bishop>

On Tue, Apr 23, 2019 at 11:01:36AM -0400, Brian Haley wrote:
> On 4/23/19 9:57 AM, Ben Nemec wrote:
> > 
> > 
> > On 4/23/19 8:33 AM, Michael McCune wrote:
> > > On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski
> > > <skaplons at redhat.com> wrote:
> > > > But in some corner case it might be even patched and defaults
> > > > can be different
> > > > in some specific cloud.
> > > 
> > > after replying to Nate last night, this was the only corner case i
> > > could think of as well. there /could/ exist a situation  where an
> > > operator has modified the defaults such that they are not in the
> > > upstream source, in this case the "default hunting" could be seen as
> > > an exposure of information. whether that information is useful or not,
> > > i am still not sure about but it's worth noting. good observation =)

Chatting with amotoki on IRC I realized that "defaults" is a somewhat
ambiguous term - there are the defaults set in code when we release
OpenStack, and then there are the values that an operation defaults to
while running, which can be influenced by the configuration of the
running cloud.  Just to be clear, I meant the latter when I referred to
"defaults".

In other words, if the sent value had not been sent, what would have
been applied for that action?  I.e. if I sent a create route request
without "ha" specified, then is the resulting router created with
ha=false?  Then the value to pass through is ha=false.

For example, anyone can create a port but only an admin or network owner
can create a port with port security specified.  Here is the result
matrix for a create port request by a non-admin user that does not own
the network in an environment where ports are created with port security
enabled by default.

                  |   without proposal    |  with proposal       |
port_security     |                       |                      |
requested         |                       |                      |
------------------|-----------------------|----------------------|
enabled           |  Denied by policy     | OK (same as default) | 
------------------|-----------------------|----------------------|
disabled          |  Denied by policy     | Denied by policy     |
------------------|-----------------------|----------------------|

> > Assuming you have permission to make the API call in the first place,
> > wouldn't you be able to determine the defaults based on the results of
> > the API call anyway? As in, I create a network and don't pass any value
> > for the shared attribute, then I look at the created network and see
> > that shared is False by default.
> 
> Maybe an example would make it clearer.  If as an admin I want to enable DVR
> and L3-HA, I make some changes in neutron.conf to set that as the default.
> When a user creates a router there will be many objects created and extra
> daemons spawned, as opposed to the case when there is just centralized
> routing.  An 'openstack router show routerX' won't return the distributed or
> ha values in the API response unless you are the admin user, so there isn't
> a way to determine the defaults.
>
> > Maybe there are defaults that aren't so easily observable, but in
> > general I wouldn't consider them sensitive data. However, I am not a
> > security guru so take my opinion for what it's worth.
> 
> In the above case, is knowledge of the router type sensitive data? Probably
> not, if I'm remembering correctly I think we kept them hidden since it's the
> admin that made the decision on the deployment, and users might get
> confused.  But if you knew your router was distributed then you'd know there
> was something local to your hypervisor (router namespace), instead of only
> on a remote controller node.  Again, probably not an issue, but it does let
> you know what additional agents might be running where your instance is.

I'm not sure how such knowledge would be usable without breaking the
containment of the instance; if such knowledge is exploitable I think it
would warrant a CVE.  

> Nate - I'm assuming your changes wouldn't allow users to figure something
> like this out based on making a series of API calls?

Yes, it would allow a user to determine the defaults.  Since I scoped my
proposal to boolean fields, in fact it would take at most two to check.
As you mentioned before, my understanding is that we did not share some
of the back-end implementation details for usability concerns - not
confusing users - as opposed to a security/separation of concerns
approach.  If there are fields where the defaults should not be
detectable by this kind of inspection then I definitely want to know,
but I cannot think of any at this time.

What does it benefit an attacker to know that ports are created with
port security on by default, or that networks are created as not shared
by default, or routers are or are not HA by default?  I am hoping that
by airing this in the community, perhaps others will see angles I
cannot.

Thanks,

Nate


From bcafarel at redhat.com  Tue Apr 23 16:06:16 2019
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Tue, 23 Apr 2019 18:06:16 +0200
Subject: [FYI][all] PySnooper, a poor man's debugger
In-Reply-To: <20190422192550.64cftvrje2tbm43q@skaplons-mac>
References: <CACqyMif+jLwuXmrjTN+hpJ1Jqj8eHiquwJsD2ks_=CN9GnAcnQ@mail.gmail.com>
 <6b7aaa1c-5d8c-3e5b-a455-2f04ab5b06ae@nemebean.com>
 <20190422192550.64cftvrje2tbm43q@skaplons-mac>
Message-ID: <CABHdKwob_4usDJSNC8781_6a+Aof=64+RYJ3XgWdbmLdStpTaw@mail.gmail.com>

On Mon, 22 Apr 2019 at 21:26, Slawek Kaplonski <skaplons at redhat.com> wrote:

> Hi,
>
> Thanks. It looks really interesting :)
>
> On Mon, Apr 22, 2019 at 11:51:49AM -0500, Ben Nemec wrote:
> >
> >
> > On 4/22/19 8:32 AM, Artom Lifshitz wrote:
> > > tl;dr Instead of debugging with LOG.debug and/or print() statements
> > > all over the place, use the pysnooper decorator [1].
> > >
> > > I came across this on Hacker News this morning - if you're like me and
> > > are too lazy to invest in learning a real debugger, and instead do it
> > > with LOG.debug/print()s all over the place, pysnooper might be useful
> > > to you. This line from the README feels particularly relevant to me ;)
> >
> > I'm going to mildly object to the characterization of print and log
> > debugging as "lazy". I've spent plenty of time in debuggers over the
> years
> > and in many cases I just prefer a simple print over stepping through a
> huge
> > number of lines of code. Both debugging techniques have their place and
> > nobody should feel bad because they chose one over the other.
> >
>
> Exactly. Imagine debugging e.g. some race condition issue. Using simple
> prints
> may be much better in such case to find out what is going on wrong there :)
>
Which is exactly what I was looking for a few days ago, when trying to
track down what could end in a (rare) test failure.
It looks very interesting indeed, and seems to work fine on first tests!

>
> > >
> > > > What makes PySnooper stand out from all other code intelligence
> tools?
> > > > You can use it in your sh***y, sprawling enterprise codebase without
> having
> > > > to do any setup.
> > >
> > > I tried it out with a random Nova unit test by decorating the function
> > > being tested, and it gave me the expected analysis of how the function
> > > executed.
> > >
> > > Just sharing this, I hope it might be useful to someone :)
> >
> > I've starred it. It looks a bit like bash's xtrace on steroids, which is
> > something I use quite a lot when debugging bash scripts.
> >
> > >
> > > [1] https://github.com/cool-RR/pysnooper
> > >
> >
>
> --
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>

-- 
Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/0d1b457d/attachment.html>

From sfinucan at redhat.com  Tue Apr 23 16:54:40 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Tue, 23 Apr 2019 17:54:40 +0100
Subject: [dev] oslosphinx Sphinx theme is EOL
In-Reply-To: <87b67b74c18d653255e12805bd0ea7f67cb20e5d.camel@redhat.com>
References: <87b67b74c18d653255e12805bd0ea7f67cb20e5d.camel@redhat.com>
Message-ID: <0fce559dcfe16a7476787ff9622ac711fac31957.camel@redhat.com>

This project has now been retired. As noted below, anyone still
oslosphinx should prioritize moving away from it as it's currently
broken with Sphinx 2.0 and the issues it has will only get worse with
time. Please reach out on #openstack-doc if you're having difficulties
with this migration.

Stephen

On Fri, 2019-03-29 at 15:32 +0000, Stephen Finucane wrote:
> Just a quick pointer that the oslosphinx theme does not work with
> Sphinx 2.0, which was released yesterday, failing with the following
> error:
> 
>    Exception occurred:
>      File "/home/zuul/src/git.openstack.org/openstack/nova-specs/.tox/docs/lib/python3.6/site-packages/oslosphinx/__init__.py", line 76, in builder_inited
>        app.info('Using openstack theme from %s' % theme_dir)
>     AttributeError: 'Sphinx' object has no attribute 'info'
> 
> The oslo team have decided not to fix these issues, given that
> oslosphinx is EOL since Pike, and we suggest that people instead
> migrate to openstackdocstheme [1] (for projects that are able to use
> the OpenStack brand [2]) or something else (for projects that are not).
> For the former, I suggest follow the openstackdocstheme [1] or look at
> what we've done in nova-specs [3] for an existing example. If you have
> issues, please reach out on #openstack-doc and one of us will try our
> best to help you migrate.
> 
> I'll work with infra to get the repo shuttered and avoid any further
> confusion with this theme going forward.
> 
> Stephen
> 
> [1] https://docs.openstack.org/openstackdocstheme/latest/
> [2] https://www.openstack.org/brand
> [3] https://review.openstack.org/#/c/648670/
> 




From gagehugo at gmail.com  Tue Apr 23 17:21:45 2019
From: gagehugo at gmail.com (Gage Hugo)
Date: Tue, 23 Apr 2019 12:21:45 -0500
Subject: [Security][Security SIG] Weekly Meeting Schedule
Message-ID: <CAE4Awf_o6h-Ux31pmtauPXJUbMUYCqgodwkNKjJBfxm+3Wxw8w@mail.gmail.com>

With the Summit/PTG next week, the Security SIG meeting for May 2nd will be
cancelled due to people attending the Summit/PTG.  The following week I
will not be available to chair, so the meeting for May 9th will be
preemptively canceled, however if there is a need for discussion, please
feel free to host at the usual time.

We will be back to regularly scheduled meetings again on the 16th,

Safe travels everyone attending the Summit/PTG!
- Gage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/fad1dac1/attachment.html>

From gagehugo at gmail.com  Tue Apr 23 17:22:18 2019
From: gagehugo at gmail.com (Gage Hugo)
Date: Tue, 23 Apr 2019 12:22:18 -0500
Subject: [Security][Security SIG] Weekly Meeting Schedule
Message-ID: <CAE4Awf9aU4hizrYEfZgZSoDh7YvCZ76XSs4Qxn9zZuX9Lh0XHQ@mail.gmail.com>

With the Summit/PTG next week, the Security SIG meeting for May 2nd will be
cancelled due to people attending the Summit/PTG.  The following week I
will not be available to chair, so the meeting for May 9th will be
preemptively canceled, however if there is a need for discussion, please
feel free to host at the usual time.

We will be back to regularly scheduled meetings again on the 16th,

Safe travels everyone attending the Summit/PTG!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/5f78bab7/attachment.html>

From colleen at gazlene.net  Tue Apr 23 17:41:57 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Tue, 23 Apr 2019 13:41:57 -0400
Subject: [keystone] No meeting next two weeks
Message-ID: <10a84781-61e6-42d1-9ccd-883fdd2e4aca@www.fastmail.com>

As discussed in today's meeting[1], we'll be cancelling next week's meeting (30 April) due to the summit, as well as the following week's meeting (7 May) for recovery. 

Colleen

[1] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-04-23-16.00.log.html


From arbermejo0417 at gmail.com  Tue Apr 23 18:29:11 2019
From: arbermejo0417 at gmail.com (Alejandro Ruiz Bermejo)
Date: Tue, 23 Apr 2019 14:29:11 -0400
Subject: Openstack LXC
Message-ID: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>

Hi everyone,

I have a fresh Openstack installation and i need to use LXC to launch
instances
I made the deployment manually, currently i have one controller node, one
compute node, one block storage node and one object storage node.

I already made the necessary configurations in the nova.conf file as
appears on the official documentation site

compute_driver = libvirt.LibvirtDriver
[libvirt]virt_type = lxc


and i have installed the nova-compute-lxc package and the nbd-server
package.

i created a new ubuntu 18 image for the container with the following
command:

openstack image create --public --container-format=bare --disk-format=raw
--file bionic-server-cloudimg-amd64.tar.gz ubuntu18

and the flavor:

openstack flavor create --ram 2048 --vcpus 1 --disk 5 lxc.test

then when i try to launch an instance:

openstack server create --flavor lxc.test --image ubuntu18 --nic
net-id=d0f6cc99-565b-484f-a5ab-fcb1c3af456d --security-group
1160755e-1312-43c6-8ebb-b12b92d35e51 --key-name mykey lxc6

I get the following Error

cat /var/log/nova/nova-*.log | grep 269d2480-4477-4382-b09c-9c686ab7a17c

2019-04-23 17:59:26.846 3949 INFO nova.osapi_compute.wsgi.server
[req-1dbeb432-67f0-4305-b91c-6548dde49bee a16c6ef0319b4643a4ec8e56a1d025cb
59065d8f970b467aa94ef7b35f1edab5 - default default] 10.8.9.54 "GET
/v2.1/servers/269d2480-4477-4382-b09c-9c686ab7a17c HTTP/1.1" status: 200
len: 1737 time: 0.6656921

2019-04-23 17:59:33.076 3944 INFO
nova.api.openstack.compute.server_external_events
[req-206e8ace-90e3-4a95-8274-4a9091c174c0 c2657fa5083f4d5c932d53d6bf094604
18337c70d397424f8895cd4f1ae7450e - default default] Creating event
network-changed:818d6adc-252e-4d47-9275-009cff55c716 for instance
269d2480-4477-4382-b09c-9c686ab7a17c on compute

2019-04-23 17:59:37.663 3926 *ERROR* nova.scheduler.utils
[req-abd32ef2-3a19-4154-a7da-893f3d2b2aef a16c6ef0319b4643a4ec8e56a1d025cb
59065d8f970b467aa94ef7b35f1edab5 - default default] [instance:
269d2480-4477-4382-b09c-9c686ab7a17c] Error from last host: compute (node
compute.cujae.edu.cu): [u'Traceback (most recent call last):\n', u'  File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1841, in
_do_build_and_run_instance\n    filter_properties, request_spec)\n', u'
File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2121,
in _build_and_run_instance\n    instance_uuid=instance.uuid,
reason=six.text_type(e))\n', u'RescheduledException: Build of instance
269d2480-4477-4382-b09c-9c686ab7a17c was re-scheduled: mount() takes
exactly 4 arguments (3 given)\n']

Is this error a bug or something fixable??
Has anyone accomplished this kind of environment or used lxc without
problems?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/dc2949b2/attachment-0001.html>

From fungi at yuggoth.org  Tue Apr 23 18:39:41 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 18:39:41 +0000
Subject: The python black project.
In-Reply-To: <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
Message-ID: <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>

On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
[...]
> ya i think i could get more behind autopep8 or yapf. running
> autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> little change
> 
> litrally adding 1 empty new line to  to 102 files that with almost
> 0 other code curn. using autopep8 however would fix any actul pep8
> issue in new patches automatically without the downsides of black.
[...]

I'm more concerned with the implementation logistics, honestly. How
do you propose going about this? If you want to use a Git commit or
pre-commit hook then you can do it already--go for it. If you want
everyone proposing changes to the same repository to use the same
commit hook, that becomes a distribution/enforcement challenge to
solve. If you want it somehow enforced on the receiving end of the
push, say with a receive hook, that's brittle and will have side
effects such as invalidating signed commits (which we're able to
support at the moment).

Basically the only friendly and reliable way to enforce this
centrally is to have the desired style conventions validated upon
receipt by the code review system and the results reported back to
the committer. This is exactly what we already do today. There are
of course also ways to reject the change with a push error so that
the committer has to amend and push again, but that's not easy to
manage across different projects and also doesn't solve your desire
to "not need to think about code style" (paraphrased).

There is also the possibility that you simply run a periodic
autopep8 job against the codebase and have that job propose a commit
to the repository to apply code style changes if there are any, but
that's a bit of a messy hack as well.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/d7080a60/attachment.sig>

From smooney at redhat.com  Tue Apr 23 19:04:04 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 20:04:04 +0100
Subject: Openstack LXC
In-Reply-To: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>
References: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>
Message-ID: <a8e1a2883e7b6552a6bbc8c623d3b63b9a10d1f5.camel@redhat.com>

On Tue, 2019-04-23 at 14:29 -0400, Alejandro Ruiz Bermejo wrote:
> Hi everyone,
> 
> I have a fresh Openstack installation and i need to use LXC to launch
> instances
> I made the deployment manually, currently i have one controller node, one
> compute node, one block storage node and one object storage node.
> 
> I already made the necessary configurations in the nova.conf file as
> appears on the official documentation site
> 
> compute_driver = libvirt.LibvirtDriver
> [libvirt]virt_type = lxc
> 
> 
> and i have installed the nova-compute-lxc package and the nbd-server
> package.
> 
> i created a new ubuntu 18 image for the container with the following
> command:
> 
> openstack image create --public --container-format=bare --disk-format=raw
> --file bionic-server-cloudimg-amd64.tar.gz ubuntu18
> 
> and the flavor:
> 
> openstack flavor create --ram 2048 --vcpus 1 --disk 5 lxc.test
> 
> then when i try to launch an instance:
> 
> openstack server create --flavor lxc.test --image ubuntu18 --nic
> net-id=d0f6cc99-565b-484f-a5ab-fcb1c3af456d --security-group
> 1160755e-1312-43c6-8ebb-b12b92d35e51 --key-name mykey lxc6
> 
> I get the following Error
> 
> cat /var/log/nova/nova-*.log | grep 269d2480-4477-4382-b09c-9c686ab7a17c
> 
> 2019-04-23 17:59:26.846 3949 INFO nova.osapi_compute.wsgi.server
> [req-1dbeb432-67f0-4305-b91c-6548dde49bee a16c6ef0319b4643a4ec8e56a1d025cb
> 59065d8f970b467aa94ef7b35f1edab5 - default default] 10.8.9.54 "GET
> /v2.1/servers/269d2480-4477-4382-b09c-9c686ab7a17c HTTP/1.1" status: 200
> len: 1737 time: 0.6656921
> 
> 2019-04-23 17:59:33.076 3944 INFO
> nova.api.openstack.compute.server_external_events
> [req-206e8ace-90e3-4a95-8274-4a9091c174c0 c2657fa5083f4d5c932d53d6bf094604
> 18337c70d397424f8895cd4f1ae7450e - default default] Creating event
> network-changed:818d6adc-252e-4d47-9275-009cff55c716 for instance
> 269d2480-4477-4382-b09c-9c686ab7a17c on compute
> 
> 2019-04-23 17:59:37.663 3926 *ERROR* nova.scheduler.utils
> [req-abd32ef2-3a19-4154-a7da-893f3d2b2aef a16c6ef0319b4643a4ec8e56a1d025cb
> 59065d8f970b467aa94ef7b35f1edab5 - default default] [instance:
> 269d2480-4477-4382-b09c-9c686ab7a17c] Error from last host: compute (node
> compute.cujae.edu.cu): [u'Traceback (most recent call last):\n', u'  File
> "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1841, in
> _do_build_and_run_instance\n    filter_properties, request_spec)\n', u'
> File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2121,
> in _build_and_run_instance\n    instance_uuid=instance.uuid,
> reason=six.text_type(e))\n', u'RescheduledException: Build of instance
> 269d2480-4477-4382-b09c-9c686ab7a17c was re-scheduled: mount() takes
> exactly 4 arguments (3 given)\n']
the libvirt lxc dirver is not tested upstream in the gate so this could
be a latent bug. its hard to tell but it might be this mount function
https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/privsep/fs.py#L32-L40

being called here 
https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/disk/mount/api.py#L250-L251
where only 3 args are passed instead of the 4 that are needed
the options arg is missing.
but if thats the issue its been broken for years.
since https://github.com/openstack/nova/commit/7ad72b092201f87530674a245e2904c6401d567c

> 
> Is this error a bug or something fixable??
> Has anyone accomplished this kind of environment or used lxc without
> problems?




From Kevin.Fox at pnnl.gov  Tue Apr 23 19:06:30 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Tue, 23 Apr 2019 19:06:30 +0000
Subject: The python black project.
In-Reply-To: <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>,
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>

I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in.

Thanks,
Kevin
________________________________________
From: Jeremy Stanley [fungi at yuggoth.org]
Sent: Tuesday, April 23, 2019 11:39 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: The python black project.

On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
[...]
> ya i think i could get more behind autopep8 or yapf. running
> autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> little change
>
> litrally adding 1 empty new line to  to 102 files that with almost
> 0 other code curn. using autopep8 however would fix any actul pep8
> issue in new patches automatically without the downsides of black.
[...]

I'm more concerned with the implementation logistics, honestly. How
do you propose going about this? If you want to use a Git commit or
pre-commit hook then you can do it already--go for it. If you want
everyone proposing changes to the same repository to use the same
commit hook, that becomes a distribution/enforcement challenge to
solve. If you want it somehow enforced on the receiving end of the
push, say with a receive hook, that's brittle and will have side
effects such as invalidating signed commits (which we're able to
support at the moment).

Basically the only friendly and reliable way to enforce this
centrally is to have the desired style conventions validated upon
receipt by the code review system and the results reported back to
the committer. This is exactly what we already do today. There are
of course also ways to reject the change with a push error so that
the committer has to amend and push again, but that's not easy to
manage across different projects and also doesn't solve your desire
to "not need to think about code style" (paraphrased).

There is also the possibility that you simply run a periodic
autopep8 job against the codebase and have that job propose a commit
to the repository to apply code style changes if there are any, but
that's a bit of a messy hack as well.
--
Jeremy Stanley


From smooney at redhat.com  Tue Apr 23 19:18:52 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 20:18:52 +0100
Subject: The python black project.
In-Reply-To: <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
Message-ID: <1ae6d8a6626d629b7e754163508a9b444184a22d.camel@redhat.com>

On Tue, 2019-04-23 at 18:39 +0000, Jeremy Stanley wrote:
> On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> [...]
> > ya i think i could get more behind autopep8 or yapf. running
> > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > little change
> > 
> > litrally adding 1 empty new line to  to 102 files that with almost
> > 0 other code curn. using autopep8 however would fix any actul pep8
> > issue in new patches automatically without the downsides of black.
> 
> [...]
> 
> I'm more concerned with the implementation logistics, honestly. How
> do you propose going about this? If you want to use a Git commit or
> pre-commit hook then you can do it already--go for it.
i honestly have been a little reluctanet to do that in the past jsut because
it might cause unrelated changes and peopel will nit pick them as such.
>  If you want
> everyone proposing changes to the same repository to use the same
> commit hook, that becomes a distribution/enforcement challenge to
> solve. If you want it somehow enforced on the receiving end of the
> push, say with a receive hook, that's brittle and will have side
> effects such as invalidating signed commits (which we're able to
> support at the moment).
> 
> Basically the only friendly and reliable way to enforce this
> centrally is to have the desired style conventions validated upon
> receipt by the code review system and the results reported back to
> the committer. This is exactly what we already do today. There are
> of course also ways to reject the change with a push error so that
> the committer has to amend and push again, but that's not easy to
> manage across different projects and also doesn't solve your desire
> to "not need to think about code style" (paraphrased).
well looking at autopep8 again its much less invasive then i had assumed it would
be so i might start using it locally personally.
> 
> There is also the possibility that you simply run a periodic
> autopep8 job against the codebase and have that job propose a commit
> to the repository to apply code style changes if there are any, but
> that's a bit of a messy hack as well.
honestly i was thinking if we went with autopep8 we just add it to the pep8 tox env.
so you run pep8 locally/in the gate and it fixes everythign it can and if there are any failure
you can jsut fix them youself.

the fact that auto pep8 seams to be really concervitve and only fix pep8 issues which flake8 would
not allow anyway is a saving grace as it mean there will be very litte code churn.

also autopep8 is the default formater for python in vscode and other ids support it too so
for those that use them its pretty trivial to use by pressing ctrl+shift+i to format the current file.
that said it dose not help me when im using nano/emacs but i run tox -e pep8 anyway before i push.
if that auto fixed pep8 issue too when it could that would be nice.

one thing that i think is important however is that the authorship of the change not be effected so
in the gate if autopep8 would casuse a code chagne i would want the job to fail.

maybe haveign the two be seperate woudl actully be better e.g. have an autopep8 tox env jsut for running it.
im honestly getting burt out by this topic but i thin this could be a nice middle ground.
that or stay as we are but my inital exciment over maybe useing black has been extinguished by
actully using it and this thread.




From smooney at redhat.com  Tue Apr 23 19:22:04 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 20:22:04 +0100
Subject: The python black project.
In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 , <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
Message-ID: <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>

On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the
> generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the
> formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it.
so pre-commit hook runs an autopep8 tox env.
if the tox run modifies any files fail the commit.
in the gate we also assert the same thing in the pep8 job.
and retrun the diff in the logs somewhere

anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from
scratch.

> 
> Thanks,
> Kevin
> ________________________________________
> From: Jeremy Stanley [fungi at yuggoth.org]
> Sent: Tuesday, April 23, 2019 11:39 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.
> 
> On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> [...]
> > ya i think i could get more behind autopep8 or yapf. running
> > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > little change
> > 
> > litrally adding 1 empty new line to  to 102 files that with almost
> > 0 other code curn. using autopep8 however would fix any actul pep8
> > issue in new patches automatically without the downsides of black.
> 
> [...]
> 
> I'm more concerned with the implementation logistics, honestly. How
> do you propose going about this? If you want to use a Git commit or
> pre-commit hook then you can do it already--go for it. If you want
> everyone proposing changes to the same repository to use the same
> commit hook, that becomes a distribution/enforcement challenge to
> solve. If you want it somehow enforced on the receiving end of the
> push, say with a receive hook, that's brittle and will have side
> effects such as invalidating signed commits (which we're able to
> support at the moment).
> 
> Basically the only friendly and reliable way to enforce this
> centrally is to have the desired style conventions validated upon
> receipt by the code review system and the results reported back to
> the committer. This is exactly what we already do today. There are
> of course also ways to reject the change with a push error so that
> the committer has to amend and push again, but that's not easy to
> manage across different projects and also doesn't solve your desire
> to "not need to think about code style" (paraphrased).
> 
> There is also the possibility that you simply run a periodic
> autopep8 job against the codebase and have that job propose a commit
> to the repository to apply code style changes if there are any, but
> that's a bit of a messy hack as well.
> --
> Jeremy Stanley
> 



From fungi at yuggoth.org  Tue Apr 23 19:37:30 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 19:37:30 +0000
Subject: The python black project.
In-Reply-To: <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
Message-ID: <20190423193729.n42dclk5qss5nnx6@yuggoth.org>

On 2019-04-23 20:22:04 +0100 (+0100), Sean Mooney wrote:
> On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> > On Tue, 2019-04-23 at 15:39 +0000, Jeremy Stanley wrote:
[...]
> > > If you want to use a Git commit or pre-commit hook then you
> > > can do it already--go for it. If you want everyone proposing
> > > changes to the same repository to use the same commit hook,
> > > that becomes a distribution/enforcement challenge to solve.
[...]
> > I've wondered for a while if you could automate the automation.
> > So, like, run the autoformatter and feed back the generated
> > patch back to the developer in a way they can easily accept it.
> > Like, making a pr against their pr with the formatting fixes, so
> > that they can easily merge it in.
> 
> well you can with a pre-commit hook + a job chagne to enforce it.
> so pre-commit hook runs an autopep8 tox env. if the tox run
> modifies any files fail the commit. in the gate we also assert the
> same thing in the pep8 job. and retrun the diff in the logs
> somewhere
[...]

That's basically exactly what I said up-thread... there's nothing
stopping you from setting your environment up to run your diff
through autopep8 before committing, for example via a local Git
hook. If you want others to do the same, you need to solve the hook
distribution and installation problem. We already refuse to merge
changes which fail our pep8 CI jobs, so that's effectively the same
as running autopep8 in a job and returning a diff in the logs (but
harder to do things like start taking advantage of Zuul's
recently-added ability to leave inline review comments, since you'd
no longer have the line-oriented reports flake8 gives you, though I
guess the same job could *also* run autopep8, it's not like it would
add much to the job duration).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/af2472a7/attachment-0001.sig>

From Kevin.Fox at pnnl.gov  Tue Apr 23 19:56:39 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Tue, 23 Apr 2019 19:56:39 +0000
Subject: The python black project.
In-Reply-To: <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>	,
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>,
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>

Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs and the like, as well as git history for someone pushing vs pulling I think?

Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break other things?

Thanks,
Kevin
________________________________________
From: Sean Mooney [smooney at redhat.com]
Sent: Tuesday, April 23, 2019 12:22 PM
To: Fox, Kevin M; Jeremy Stanley; openstack-discuss at lists.openstack.org
Subject: Re: The python black project.

On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the
> generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the
> formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it.
so pre-commit hook runs an autopep8 tox env.
if the tox run modifies any files fail the commit.
in the gate we also assert the same thing in the pep8 job.
and retrun the diff in the logs somewhere

anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from
scratch.

>
> Thanks,
> Kevin
> ________________________________________
> From: Jeremy Stanley [fungi at yuggoth.org]
> Sent: Tuesday, April 23, 2019 11:39 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.
>
> On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> [...]
> > ya i think i could get more behind autopep8 or yapf. running
> > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > little change
> >
> > litrally adding 1 empty new line to  to 102 files that with almost
> > 0 other code curn. using autopep8 however would fix any actul pep8
> > issue in new patches automatically without the downsides of black.
>
> [...]
>
> I'm more concerned with the implementation logistics, honestly. How
> do you propose going about this? If you want to use a Git commit or
> pre-commit hook then you can do it already--go for it. If you want
> everyone proposing changes to the same repository to use the same
> commit hook, that becomes a distribution/enforcement challenge to
> solve. If you want it somehow enforced on the receiving end of the
> push, say with a receive hook, that's brittle and will have side
> effects such as invalidating signed commits (which we're able to
> support at the moment).
>
> Basically the only friendly and reliable way to enforce this
> centrally is to have the desired style conventions validated upon
> receipt by the code review system and the results reported back to
> the committer. This is exactly what we already do today. There are
> of course also ways to reject the change with a push error so that
> the committer has to amend and push again, but that's not easy to
> manage across different projects and also doesn't solve your desire
> to "not need to think about code style" (paraphrased).
>
> There is also the possibility that you simply run a periodic
> autopep8 job against the codebase and have that job propose a commit
> to the repository to apply code style changes if there are any, but
> that's a bit of a messy hack as well.
> --
> Jeremy Stanley
>



From smooney at redhat.com  Tue Apr 23 20:13:06 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 21:13:06 +0100
Subject: The python black project.
In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 , <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 ,<d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
Message-ID: <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>

On Tue, 2019-04-23 at 19:56 +0000, Fox, Kevin M wrote:
> Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs
> and the like, as well as git history for someone pushing vs pulling I think?
> 
> Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better
> middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break
> other things?
well what i was thinking was we would use the return code of autopep8 as the job sucess

 --exit-code           change to behavior of exit code. default behavior of
                        return value, 0 is no differences, 1 is error exit.
                        return 2 when add this option. 2 is exists
                        differences.

so in the gate we coudl invoke 

"tox -e autopep8 -- --diff > result.diff"

and just use the execode to know if it woudl change somehting.

if it exeits 0 then the job passes if it exits 1 
then  it fails and the the user can grab the diff an apply it  or they coudl just run

"tox -e autopep8 -- --in-place"

then in either case the locally  git add and git commit --amend and resubmit to make sure authership is preserved.


the autopep8 tox enve could also automate runing it on only the files changed in the current commit to minimise chrun
like the fast8 env does. that would allow use to fix things incrementlaly as we go.

i might just code this up but i dont really want to waste time on it if it  will never merge.


> 
> Thanks,
> Kevin
> ________________________________________
> From: Sean Mooney [smooney at redhat.com]
> Sent: Tuesday, April 23, 2019 12:22 PM
> To: Fox, Kevin M; Jeremy Stanley; openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.
> 
> On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> > I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the
> > generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with
> > the
> > formatting fixes, so that they can easily merge it in.
> 
> well you can with a pre-commit hook + a job chagne to enforce it.
> so pre-commit hook runs an autopep8 tox env.
> if the tox run modifies any files fail the commit.
> in the gate we also assert the same thing in the pep8 job.
> and retrun the diff in the logs somewhere
> 
> anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from
> scratch.
> 
> > 
> > Thanks,
> > Kevin
> > ________________________________________
> > From: Jeremy Stanley [fungi at yuggoth.org]
> > Sent: Tuesday, April 23, 2019 11:39 AM
> > To: openstack-discuss at lists.openstack.org
> > Subject: Re: The python black project.
> > 
> > On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> > [...]
> > > ya i think i could get more behind autopep8 or yapf. running
> > > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > > little change
> > > 
> > > litrally adding 1 empty new line to  to 102 files that with almost
> > > 0 other code curn. using autopep8 however would fix any actul pep8
> > > issue in new patches automatically without the downsides of black.
> > 
> > [...]
> > 
> > I'm more concerned with the implementation logistics, honestly. How
> > do you propose going about this? If you want to use a Git commit or
> > pre-commit hook then you can do it already--go for it. If you want
> > everyone proposing changes to the same repository to use the same
> > commit hook, that becomes a distribution/enforcement challenge to
> > solve. If you want it somehow enforced on the receiving end of the
> > push, say with a receive hook, that's brittle and will have side
> > effects such as invalidating signed commits (which we're able to
> > support at the moment).
> > 
> > Basically the only friendly and reliable way to enforce this
> > centrally is to have the desired style conventions validated upon
> > receipt by the code review system and the results reported back to
> > the committer. This is exactly what we already do today. There are
> > of course also ways to reject the change with a push error so that
> > the committer has to amend and push again, but that's not easy to
> > manage across different projects and also doesn't solve your desire
> > to "not need to think about code style" (paraphrased).
> > 
> > There is also the possibility that you simply run a periodic
> > autopep8 job against the codebase and have that job propose a commit
> > to the repository to apply code style changes if there are any, but
> > that's a bit of a messy hack as well.
> > --
> > Jeremy Stanley
> > 
> 
> 



From Kevin.Fox at pnnl.gov  Tue Apr 23 20:26:10 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Tue, 23 Apr 2019 20:26:10 +0000
Subject: The python black project.
In-Reply-To: <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
References: <CAF+jc3V44Cvh4jkGbHvfO09KsOz-YgPZ4qWXOpmDhQcpG+U3xA@mail.gmail.com>
 <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>		,
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 ,<d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>,
 <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>

Are you still thinking precommit hook there? I usually prefer server side hooks as then I don't have to deploy all the developer tools all of the random repos I contribute to require all the time. If it can be made server side somehow, thats vastly easier to deal with by folks like me or other drive by contributors.

I'm thinking more along the line of, we have a bunch of gate blocking tests that ensure some amount of code quality going in. But what if we could take it to the next level and have those tests actually feed back quality enhancements too, not just saying no and without the developer to install extra tools?

Thanks,
Kevin
________________________________________
From: Sean Mooney [smooney at redhat.com]
Sent: Tuesday, April 23, 2019 1:13 PM
To: Fox, Kevin M; Jeremy Stanley; openstack-discuss at lists.openstack.org
Subject: Re: The python black project.

On Tue, 2019-04-23 at 19:56 +0000, Fox, Kevin M wrote:
> Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs
> and the like, as well as git history for someone pushing vs pulling I think?
>
> Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better
> middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break
> other things?
well what i was thinking was we would use the return code of autopep8 as the job sucess

 --exit-code           change to behavior of exit code. default behavior of
                        return value, 0 is no differences, 1 is error exit.
                        return 2 when add this option. 2 is exists
                        differences.

so in the gate we coudl invoke

"tox -e autopep8 -- --diff > result.diff"

and just use the execode to know if it woudl change somehting.

if it exeits 0 then the job passes if it exits 1
then  it fails and the the user can grab the diff an apply it  or they coudl just run

"tox -e autopep8 -- --in-place"

then in either case the locally  git add and git commit --amend and resubmit to make sure authership is preserved.


the autopep8 tox enve could also automate runing it on only the files changed in the current commit to minimise chrun
like the fast8 env does. that would allow use to fix things incrementlaly as we go.

i might just code this up but i dont really want to waste time on it if it  will never merge.


>
> Thanks,
> Kevin
> ________________________________________
> From: Sean Mooney [smooney at redhat.com]
> Sent: Tuesday, April 23, 2019 12:22 PM
> To: Fox, Kevin M; Jeremy Stanley; openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.
>
> On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
> > I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the
> > generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with
> > the
> > formatting fixes, so that they can easily merge it in.
>
> well you can with a pre-commit hook + a job chagne to enforce it.
> so pre-commit hook runs an autopep8 tox env.
> if the tox run modifies any files fail the commit.
> in the gate we also assert the same thing in the pep8 job.
> and retrun the diff in the logs somewhere
>
> anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from
> scratch.
>
> >
> > Thanks,
> > Kevin
> > ________________________________________
> > From: Jeremy Stanley [fungi at yuggoth.org]
> > Sent: Tuesday, April 23, 2019 11:39 AM
> > To: openstack-discuss at lists.openstack.org
> > Subject: Re: The python black project.
> >
> > On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote:
> > [...]
> > > ya i think i could get more behind autopep8 or yapf. running
> > > autopep8  on nova https://review.opendev.org/#/c/655171/ has very
> > > little change
> > >
> > > litrally adding 1 empty new line to  to 102 files that with almost
> > > 0 other code curn. using autopep8 however would fix any actul pep8
> > > issue in new patches automatically without the downsides of black.
> >
> > [...]
> >
> > I'm more concerned with the implementation logistics, honestly. How
> > do you propose going about this? If you want to use a Git commit or
> > pre-commit hook then you can do it already--go for it. If you want
> > everyone proposing changes to the same repository to use the same
> > commit hook, that becomes a distribution/enforcement challenge to
> > solve. If you want it somehow enforced on the receiving end of the
> > push, say with a receive hook, that's brittle and will have side
> > effects such as invalidating signed commits (which we're able to
> > support at the moment).
> >
> > Basically the only friendly and reliable way to enforce this
> > centrally is to have the desired style conventions validated upon
> > receipt by the code review system and the results reported back to
> > the committer. This is exactly what we already do today. There are
> > of course also ways to reject the change with a push error so that
> > the committer has to amend and push again, but that's not easy to
> > manage across different projects and also doesn't solve your desire
> > to "not need to think about code style" (paraphrased).
> >
> > There is also the possibility that you simply run a periodic
> > autopep8 job against the codebase and have that job propose a commit
> > to the repository to apply code style changes if there are any, but
> > that's a bit of a messy hack as well.
> > --
> > Jeremy Stanley
> >
>
>



From fungi at yuggoth.org  Tue Apr 23 20:49:57 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 20:49:57 +0000
Subject: The python black project.
In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>
References: <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
 <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>
Message-ID: <20190423204957.mqxubmqdys2sc34a@yuggoth.org>

On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote:
[...]
> I usually prefer server side hooks as then I don't have to deploy
> all the developer tools all of the random repos I contribute to
> require all the time. If it can be made server side somehow, thats
> vastly easier to deal with by folks like me or other drive by
> contributors.

Server-side hooks are fine for rejecting a push (if somewhat
inflexible and hard to manage across projects, and in most ways
inferior to equivalent CI jobs), but you don't want them altering
commits as that invalidates any commit signing (in the git commit
-S/--gpg-sign sense, not the -s/--signoff sense) the original
committer may have performed.

> I'm thinking more along the line of, we have a bunch of gate
> blocking tests that ensure some amount of code quality going in.
> But what if we could take it to the next level and have those
> tests actually feed back quality enhancements too, not just saying
> no and without the developer to install extra tools?
[...]

The suggestion to have automation push a revision to a patch you
propose while it's still under review is an interesting one, though
it does bear some resemblance to the server-side hooks problem. The
commit which would be approved and merged at that point isn't
identified as yours. Some attempt could be made to have the
automation masquerade as your identity insofar as forging the
committer details to match the prior patch, but it wouldn't be able
to reproduce your cryptographic signature so *if* you're keen on
OpenPGP-signing your commits, you'll lose that when the auto-revised
version ends up merging instead of your original.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/66913f09/attachment.sig>

From Kevin.Fox at pnnl.gov  Tue Apr 23 21:09:30 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Tue, 23 Apr 2019 21:09:30 +0000
Subject: The python black project.
In-Reply-To: <20190423204957.mqxubmqdys2sc34a@yuggoth.org>
References: <155561425007.20372.16594690474726077598@clint-ThinkPad-X1-Carbon-6th>
 <294f8063-3263-0064-10a4-86f727fa91e2@inaugust.com>
 <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
 <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>,
 <20190423204957.mqxubmqdys2sc34a@yuggoth.org>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C30800F@EX10MBOX03.pnnl.gov>

Yeah, pushing a patch following the patch going in for review is more what I was thinking. So, a patch that fixes the previous patch, not actually rewriting the patch.

Is it a problem for the commit to "come from" and be "signed off" by the automation itself?

It surfaces the cleanup patches as just cleanup patches. And in the very end of the ps, we squash the pr on merge anyway? If the user wants, they can also just flatten the PS themselves and it would automatically merge in the automation provided patches.

Thanks,
Kevin
________________________________________
From: Jeremy Stanley [fungi at yuggoth.org]
Sent: Tuesday, April 23, 2019 1:49 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: The python black project.

On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote:
[...]
> I usually prefer server side hooks as then I don't have to deploy
> all the developer tools all of the random repos I contribute to
> require all the time. If it can be made server side somehow, thats
> vastly easier to deal with by folks like me or other drive by
> contributors.

Server-side hooks are fine for rejecting a push (if somewhat
inflexible and hard to manage across projects, and in most ways
inferior to equivalent CI jobs), but you don't want them altering
commits as that invalidates any commit signing (in the git commit
-S/--gpg-sign sense, not the -s/--signoff sense) the original
committer may have performed.

> I'm thinking more along the line of, we have a bunch of gate
> blocking tests that ensure some amount of code quality going in.
> But what if we could take it to the next level and have those
> tests actually feed back quality enhancements too, not just saying
> no and without the developer to install extra tools?
[...]

The suggestion to have automation push a revision to a patch you
propose while it's still under review is an interesting one, though
it does bear some resemblance to the server-side hooks problem. The
commit which would be approved and merged at that point isn't
identified as yours. Some attempt could be made to have the
automation masquerade as your identity insofar as forging the
committer details to match the prior patch, but it wouldn't be able
to reproduce your cryptographic signature so *if* you're keen on
OpenPGP-signing your commits, you'll lose that when the auto-revised
version ends up merging instead of your original.
--
Jeremy Stanley


From fungi at yuggoth.org  Tue Apr 23 21:45:58 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 23 Apr 2019 21:45:58 +0000
Subject: The python black project.
In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C30800F@EX10MBOX03.pnnl.gov>
References: <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
 <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>
 <20190423204957.mqxubmqdys2sc34a@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C30800F@EX10MBOX03.pnnl.gov>
Message-ID: <20190423214558.2apvrd5xf3pm647b@yuggoth.org>

On 2019-04-23 21:09:30 +0000 (+0000), Fox, Kevin M wrote:
> Yeah, pushing a patch following the patch going in for review is
> more what I was thinking. So, a patch that fixes the previous
> patch, not actually rewriting the patch.

Sure, that's essentially another of the options I mentioned in an
earlier message:

> > There is also the possibility that you simply run a periodic
> > autopep8 job against the codebase and have that job propose a
> > commit to the repository to apply code style changes if there
> > are any, but that's a bit of a messy hack as well.

The main reasons I consider it a "messy hack" is that it runs the
potential of increasing the number of commits in the repository
significantly depending on whether and how often you batch up the
autofixes, and makes it harder to `git blame` effectively since a
lot of changes are immediately followed by changes to those same
lines by a generic automation account. It also means we give up on
whatever benefits we might hope to gain from having consistency of
style in proposed changes, as folks can propose code in any old
format they like without regard for readability and it only gets
cleaned up and made readable after it's been reviewed and approved.
This strikes me as a slippery slope towards "it's okay if your code
has obvious errors, we can find and fix them after it's merged."

> Is it a problem for the commit to "come from" and be "signed off"
> by the automation itself?

No, we have automation propose other sorts of changes already. From
a legal standpoint nobody's ever complained that the machine hasn't
agreed to the ICLA or acknowledged the DCO. I think once we're
successful enough with artificial intelligence for our computers to
start filing patent infringement claims against us for the work
they've written, we can revisit that position.

If we wanted to have our existing auto-proposed changes use `git
commit --gpg-sign` I think that would be able to take advantage of
much of the same automated signing infrastructure we already
leverage for our Git tags and related release artifacts. That much
seems to me like it could be a good idea, if someone wants to do the
work to add it. It would in theory allow any observer to confirm
that the patches which claim to have originated within our
automation actually have.

> It surfaces the cleanup patches as just cleanup patches. And in
> the very end of the ps, we squash the pr on merge anyway? If the
> user wants, they can also just flatten the PS themselves and it
> would automatically merge in the automation provided patches.
[...]

Now it's starting to sound like you're suggesting auto-proposing
follow-up changes to each user-proposed change while it's still
under review. I think it's probably technically possible, though
likely to ~double our overall change volume insofar as review and
testing go (especially when folks inevitably ignore them and so they
get rebased and updated every time the parent change is updated).
And before you say "it's okay to skip running CI jobs on those" it's
really not, since we're not likely to blindly trust autopep8 not to
propose a subtly broken modification.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/d57394a6/attachment.sig>

From mriedemos at gmail.com  Tue Apr 23 21:50:40 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Tue, 23 Apr 2019 16:50:40 -0500
Subject: Openstack LXC
In-Reply-To: <a8e1a2883e7b6552a6bbc8c623d3b63b9a10d1f5.camel@redhat.com>
References: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>
 <a8e1a2883e7b6552a6bbc8c623d3b63b9a10d1f5.camel@redhat.com>
Message-ID: <56bb5e5d-d9f2-be48-6cfd-ae16b1719138@gmail.com>

On 4/23/2019 2:04 PM, Sean Mooney wrote:
>> 2019-04-23 17:59:37.663 3926*ERROR*  nova.scheduler.utils
>> [req-abd32ef2-3a19-4154-a7da-893f3d2b2aef a16c6ef0319b4643a4ec8e56a1d025cb
>> 59065d8f970b467aa94ef7b35f1edab5 - default default] [instance:
>> 269d2480-4477-4382-b09c-9c686ab7a17c] Error from last host: compute (node
>> compute.cujae.edu.cu): [u'Traceback (most recent call last):\n', u'  File
>> "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1841, in
>> _do_build_and_run_instance\n    filter_properties, request_spec)\n', u'
>> File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2121,
>> in _build_and_run_instance\n    instance_uuid=instance.uuid,
>> reason=six.text_type(e))\n', u'RescheduledException: Build of instance
>> 269d2480-4477-4382-b09c-9c686ab7a17c was re-scheduled: mount() takes
>> exactly 4 arguments (3 given)\n']
> the libvirt lxc dirver is not tested upstream in the gate so this could
> be a latent bug. its hard to tell but it might be this mount function
> https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/privsep/fs.py#L32-L40
> 
> being called here
> https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/disk/mount/api.py#L250-L251
> where only 3 args are passed instead of the 4 that are needed
> the options arg is missing.
> but if thats the issue its been broken for years.
> sincehttps://github.com/openstack/nova/commit/7ad72b092201f87530674a245e2904c6401d567c
> 

Yup it's a latent bug. Feel free to report a bug and post a patch, but 
you're likely building your house on sand because as noted the 
libvirt+lxc driver doesn't get integration testing. I used to try to 
make a CI job work for that configuration but it was extremely flaky and 
it was never sorted out what the underlying issues were (and no one 
cared enough to take it up).

-- 

Thanks,

Matt


From smooney at redhat.com  Tue Apr 23 22:27:08 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 23:27:08 +0100
Subject: Openstack LXC
In-Reply-To: <56bb5e5d-d9f2-be48-6cfd-ae16b1719138@gmail.com>
References: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>
 <a8e1a2883e7b6552a6bbc8c623d3b63b9a10d1f5.camel@redhat.com>
 <56bb5e5d-d9f2-be48-6cfd-ae16b1719138@gmail.com>
Message-ID: <9d2596bd9d6d6e6c6ed4958c83d3d0592d80caae.camel@redhat.com>

On Tue, 2019-04-23 at 16:50 -0500, Matt Riedemann wrote:
> On 4/23/2019 2:04 PM, Sean Mooney wrote:
> > > 2019-04-23 17:59:37.663 3926*ERROR*  nova.scheduler.utils
> > > [req-abd32ef2-3a19-4154-a7da-893f3d2b2aef a16c6ef0319b4643a4ec8e56a1d025cb
> > > 59065d8f970b467aa94ef7b35f1edab5 - default default] [instance:
> > > 269d2480-4477-4382-b09c-9c686ab7a17c] Error from last host: compute (node
> > > compute.cujae.edu.cu): [u'Traceback (most recent call last):\n', u'  File
> > > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1841, in
> > > _do_build_and_run_instance\n    filter_properties, request_spec)\n', u'
> > > File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2121,
> > > in _build_and_run_instance\n    instance_uuid=instance.uuid,
> > > reason=six.text_type(e))\n', u'RescheduledException: Build of instance
> > > 269d2480-4477-4382-b09c-9c686ab7a17c was re-scheduled: mount() takes
> > > exactly 4 arguments (3 given)\n']
> > 
> > the libvirt lxc dirver is not tested upstream in the gate so this could
> > be a latent bug. its hard to tell but it might be this mount function
> > https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/privsep/fs.py#L32-L40
> > 
> > being called here
> > 
https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/disk/mount/api.py#L250-L251
> > where only 3 args are passed instead of the 4 that are needed
> > the options arg is missing.
> > but if thats the issue its been broken for years.
> > sincehttps://github.com/openstack/nova/commit/7ad72b092201f87530674a245e2904c6401d567c
> > 
> 
> Yup it's a latent bug. Feel free to report a bug and post a patch, but 
> you're likely building your house on sand because as noted the 
> libvirt+lxc driver doesn't get integration testing.
i think the lxc backend was original a focus of canonical but they pivoted to nova lxd instead.
if you want lxc container using nova-lxd it probably better tested but its also not in the gate.
> I used to try to 
> make a CI job work for that configuration but it was extremely flaky and 
> it was never sorted out what the underlying issues were (and no one 
> cared enough to take it up).
i can proably try to fix this issue and if i figure out how to deploy and test it with devstack i might be able
to get a gate job working but is this something peopel want fixed? from what i can tell this looks like its been
busted for 2 years so it seams like this does not get used by anyone who is active upstream at least.

the fix iteself whoudl eb relitivly simple but the fact this was not caguht by any of your unit tests indicate we
likely dont have any for this code or it not asserting the mocks are called correctly.

i might try following https://docs.openstack.org/devstack/latest/guides/lxc.html but that likely is jsut as well
maintined and tested...
> 



From smooney at redhat.com  Tue Apr 23 22:30:37 2019
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 23 Apr 2019 23:30:37 +0100
Subject: Openstack LXC
In-Reply-To: <9d2596bd9d6d6e6c6ed4958c83d3d0592d80caae.camel@redhat.com>
References: <CAOJ6YErR6k=2hdeVofuBUzZ-20zhyWh4Vr2UCKZ4=1RAP2otHg@mail.gmail.com>
 <a8e1a2883e7b6552a6bbc8c623d3b63b9a10d1f5.camel@redhat.com>
 <56bb5e5d-d9f2-be48-6cfd-ae16b1719138@gmail.com>
 <9d2596bd9d6d6e6c6ed4958c83d3d0592d80caae.camel@redhat.com>
Message-ID: <8eec1b22122636c34f94bbe644c8798de1b20c35.camel@redhat.com>

On Tue, 2019-04-23 at 23:27 +0100, Sean Mooney wrote:
> On Tue, 2019-04-23 at 16:50 -0500, Matt Riedemann wrote:
> > On 4/23/2019 2:04 PM, Sean Mooney wrote:
> > > > 2019-04-23 17:59:37.663 3926*ERROR*  nova.scheduler.utils
> > > > [req-abd32ef2-3a19-4154-a7da-893f3d2b2aef a16c6ef0319b4643a4ec8e56a1d025cb
> > > > 59065d8f970b467aa94ef7b35f1edab5 - default default] [instance:
> > > > 269d2480-4477-4382-b09c-9c686ab7a17c] Error from last host: compute (node
> > > > compute.cujae.edu.cu): [u'Traceback (most recent call last):\n', u'  File
> > > > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1841, in
> > > > _do_build_and_run_instance\n    filter_properties, request_spec)\n', u'
> > > > File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2121,
> > > > in _build_and_run_instance\n    instance_uuid=instance.uuid,
> > > > reason=six.text_type(e))\n', u'RescheduledException: Build of instance
> > > > 269d2480-4477-4382-b09c-9c686ab7a17c was re-scheduled: mount() takes
> > > > exactly 4 arguments (3 given)\n']
> > > 
> > > the libvirt lxc dirver is not tested upstream in the gate so this could
> > > be a latent bug. its hard to tell but it might be this mount function
> > > https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/privsep/fs.py#L32-L40
> > > 
> > > being called here
> > > 
> 
> https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/disk/mount/api.py#L250-L251
> > > where only 3 args are passed instead of the 4 that are needed
> > > the options arg is missing.
> > > but if thats the issue its been broken for years.
> > > sincehttps://github.com/openstack/nova/commit/7ad72b092201f87530674a245e2904c6401d567c
> > > 
> > 
> > Yup it's a latent bug. Feel free to report a bug and post a patch, but 
> > you're likely building your house on sand because as noted the 
> > libvirt+lxc driver doesn't get integration testing.
> 
> i think the lxc backend was original a focus of canonical but they pivoted to nova lxd instead.
> if you want lxc container using nova-lxd it probably better tested but its also not in the gate.
> > I used to try to 
> > make a CI job work for that configuration but it was extremely flaky and 
> > it was never sorted out what the underlying issues were (and no one 
> > cared enough to take it up).
> 
> i can proably try to fix this issue and if i figure out how to deploy and test it with devstack i might be able
> to get a gate job working but is this something peopel want fixed? from what i can tell this looks like its been
> busted for 2 years so it seams like this does not get used by anyone who is active upstream at least.
> 
> the fix iteself whoudl eb relitivly simple but the fact this was not caguht by any of your unit tests indicate we
> likely dont have any for this code or it not asserting the mocks are called correctly.
> 
> i might try following https://docs.openstack.org/devstack/latest/guides/lxc.html but that likely is jsut as well
> maintined and tested...
oh thats devstack in lxc but looking at https://docs.openstack.org/ocata/config-reference/compute/hypervisor-lxc.html
its faily simple i just need to get  a valid lxc compatibale image to use with it once deployed.
> > 
> 
> 



From openstack at fried.cc  Tue Apr 23 22:38:47 2019
From: openstack at fried.cc (Eric Fried)
Date: Tue, 23 Apr 2019 17:38:47 -0500
Subject: [nova][ptg] Draft Agenda
Message-ID: <fff151f5-efa8-4665-57c9-0f4cb8ba23fe@fried.cc>

Nova PTGers-

I have drafted an agenda at the bottom of the main etherpad [1]. It is
subject to change for the next week for various reasons, but I expect
mainly a) for scheduling conflicts and the like (see below) and b)
things falling off because resolved (e.g. I expect the SEV spec to merge
in the next couple of days).

Please review the agenda, **especially if your schedule isn't "I'm
present all three days, and glued to the nova team"** and contact me [2]
if you:

- have a scheduling conflict for a topic you own **or** a topic you care
about and want to be present for.
- feel I've prioritized your topic unjustly.
- feel I've allocated too little or too much time [3] to your topic.
- think I've committed some other glaring error or omission.

Because we're short on time, I'll be strict about sticking to the
schedule in whatever form it solidifies into. I've allocated some time
at the end [4] to resume discussions that have to be chopped off early
as a result.

Thanks,
efried

P.S. Please be gentle with me. I've tried to be fair, accommodate
scheduling issues I know about, and allocate reasonable chunks of time
for topics even when I barely understand them. If I've made a mistake,
assume it's out of ignorance, not malice or prejudice.

[1] https://etherpad.openstack.org/p/nova-ptg-train
[2] via email or IRC. Please do not edit the agenda on the etherpad.
[3] seriously, including "we don't actually need to talk about this at
the PTG".
[4] I know it sucks that it's on Saturday afternoon; my working theory
is that that's better than some topics not getting any floor time at all.


From colleen at gazlene.net  Tue Apr 23 22:57:57 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Tue, 23 Apr 2019 18:57:57 -0400
Subject: [keystone] Team dinner in Denver
In-Reply-To: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
References: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
Message-ID: <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>

On Mon, Apr 15, 2019, at 09:45, Colleen Murphy wrote:
> Berlin feels like it was ages ago, so let's organize a team dinner in 
> Denver. Poll here:
> 
> https://framadate.org/BHNNU9S3f9N3lasH
> 
> If you have strong feelings or even mild inclinations about where to 
> go, please comment on the poll or in the brainstorming etherpad[1] 
> because otherwise I am pretty much just going to throw a dart.
> 
> Colleen
> 
> [1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
> 
>

No one voiced any opinion about restaurant or food choices so  I made a reservation for 7pm on Wednesday, May 1 here:

https://otravezcantina.com/

based on it being close by, rated as good for groups, not too expensive, and having vegetarian and gluten-sensitive options (no one explicitly informed me they had such a requirement but I'm playing it safe). I made the reservation for 8 people based on the poll results but if anyone else would like to join we can just modify the reservation.

Colleen


From morgan.fainberg at gmail.com  Tue Apr 23 23:03:43 2019
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Tue, 23 Apr 2019 16:03:43 -0700
Subject: [keystone] Team dinner in Denver
In-Reply-To: <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
References: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
 <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
Message-ID: <CAGnj6auEZW2W=G1Yzb7_0zkBpeNCZJ9EzNz7Vj8MFeZOcKJL3w@mail.gmail.com>

Delicious choice! I wont be there though. Someone eat something yummy for
me.

On Tue, Apr 23, 2019 at 4:01 PM Colleen Murphy <colleen at gazlene.net> wrote:

> On Mon, Apr 15, 2019, at 09:45, Colleen Murphy wrote:
> > Berlin feels like it was ages ago, so let's organize a team dinner in
> > Denver. Poll here:
> >
> > https://framadate.org/BHNNU9S3f9N3lasH
> >
> > If you have strong feelings or even mild inclinations about where to
> > go, please comment on the poll or in the brainstorming etherpad[1]
> > because otherwise I am pretty much just going to throw a dart.
> >
> > Colleen
> >
> > [1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
> >
> >
>
> No one voiced any opinion about restaurant or food choices so  I made a
> reservation for 7pm on Wednesday, May 1 here:
>
> https://otravezcantina.com/
>
> based on it being close by, rated as good for groups, not too expensive,
> and having vegetarian and gluten-sensitive options (no one explicitly
> informed me they had such a requirement but I'm playing it safe). I made
> the reservation for 8 people based on the poll results but if anyone else
> would like to join we can just modify the reservation.
>
> Colleen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/9783182f/attachment.html>

From miguel at mlavalle.com  Tue Apr 23 23:22:51 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Tue, 23 Apr 2019 18:22:51 -0500
Subject: [openstack-dev] [neutron] Cancelling the L3 meeting on April 24
Message-ID: <CAEzGLDhp6GWWM9yqJN60UiS9Pb9bN5d99SJr+CXZzi_XoMoRHw@mail.gmail.com>

Hi Neutrinos,

Since we are meeting next week in Denver to discuss, among other things, L3
topics, we are cancelling this week's meeting.

Safe travels to everybody!

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/80c6cc02/attachment.html>

From emccormick at cirrusseven.com  Tue Apr 23 23:23:15 2019
From: emccormick at cirrusseven.com (Erik McCormick)
Date: Tue, 23 Apr 2019 19:23:15 -0400
Subject: [keystone] Team dinner in Denver
In-Reply-To: <CAGnj6auEZW2W=G1Yzb7_0zkBpeNCZJ9EzNz7Vj8MFeZOcKJL3w@mail.gmail.com>
References: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
 <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
 <CAGnj6auEZW2W=G1Yzb7_0zkBpeNCZJ9EzNz7Vj8MFeZOcKJL3w@mail.gmail.com>
Message-ID: <CAHUi5cP1nrcWeCiPbWv2_WhXVTEk3Aw5vVZhk5qEztFU1Q3Lbg@mail.gmail.com>

Not part of the team but +1 for the place. Excellent choice

On Tue, Apr 23, 2019, 7:05 PM Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> Delicious choice! I wont be there though. Someone eat something yummy for
> me.
>
> On Tue, Apr 23, 2019 at 4:01 PM Colleen Murphy <colleen at gazlene.net>
> wrote:
>
>> On Mon, Apr 15, 2019, at 09:45, Colleen Murphy wrote:
>> > Berlin feels like it was ages ago, so let's organize a team dinner in
>> > Denver. Poll here:
>> >
>> > https://framadate.org/BHNNU9S3f9N3lasH
>> >
>> > If you have strong feelings or even mild inclinations about where to
>> > go, please comment on the poll or in the brainstorming etherpad[1]
>> > because otherwise I am pretty much just going to throw a dart.
>> >
>> > Colleen
>> >
>> > [1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
>> >
>> >
>>
>> No one voiced any opinion about restaurant or food choices so  I made a
>> reservation for 7pm on Wednesday, May 1 here:
>>
>> https://otravezcantina.com/
>>
>> based on it being close by, rated as good for groups, not too expensive,
>> and having vegetarian and gluten-sensitive options (no one explicitly
>> informed me they had such a requirement but I'm playing it safe). I made
>> the reservation for 8 people based on the poll results but if anyone else
>> would like to join we can just modify the reservation.
>>
>> Colleen
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/b70b2765/attachment.html>

From Kevin.Fox at pnnl.gov  Wed Apr 24 00:11:04 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Wed, 24 Apr 2019 00:11:04 +0000
Subject: The python black project.
In-Reply-To: <20190423214558.2apvrd5xf3pm647b@yuggoth.org>
References: <eac54cd9-d939-a021-54b0-a3f22c43ed44@redhat.com>
 <d93acfd50117e4c12df6485014e38b8fe8f51c6b.camel@redhat.com>
 <20190423183940.3cqvmgkxn7ku2h5k@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C307EC1@EX10MBOX03.pnnl.gov>
 <d33feb8c0a1bffd569d1f80a9f43341677292e00.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F27@EX10MBOX03.pnnl.gov>
 <57d9ffcb8686ca3a543d6fe766c9da557b083d67.camel@redhat.com>
 <1A3C52DFCD06494D8528644858247BF01C307F76@EX10MBOX03.pnnl.gov>
 <20190423204957.mqxubmqdys2sc34a@yuggoth.org>
 <1A3C52DFCD06494D8528644858247BF01C30800F@EX10MBOX03.pnnl.gov>,
 <20190423214558.2apvrd5xf3pm647b@yuggoth.org>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C308113@EX10MBOX03.pnnl.gov>


> From: Jeremy Stanley [fungi at yuggoth.org]
> Sent: Tuesday, April 23, 2019 2:45 PM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: The python black project.

*SNIP*

> Now it's starting to sound like you're suggesting auto-proposing
> follow-up changes to each user-proposed change while it's still
> under review.

That was what I was trying to explain and failing. That is what I am proposing. :)

> I think it's probably technically possible, though
l> ikely to ~double our overall change volume insofar as review and
> testing go (especially when folks inevitably ignore them and so they
> get rebased and updated every time the parent change is updated).
> And before you say "it's okay to skip running CI jobs on those" it's
> really not, since we're not likely to blindly trust autopep8 not to
> propose a subtly broken modification.

Yeah, I wouldn't recommend blindly trusting it either... it could short circuit all the other tests though, like:
do the linting tests before any other tests. if it fails, end review of the whole PS and submit back a cleanup patch. Then start over with the testing. So test wise, it wouldn't be too expensive. But it could easily double the number of reviews like you point out, if that is an issue.

> Jeremy Stanley

Thanks,
Kevin

From johnsomor at gmail.com  Wed Apr 24 01:24:34 2019
From: johnsomor at gmail.com (Michael Johnson)
Date: Tue, 23 Apr 2019 18:24:34 -0700
Subject: [octavia][taskflow] Adaption of persistence/jobboard (taskflow
 expert review needed)
In-Reply-To: <CAOBv_t+S=YWT0PUqpGcz_Lwg2NAR-tqAUG+PQOqMevqDSaFFpA@mail.gmail.com>
References: <CAOBv_t+S=YWT0PUqpGcz_Lwg2NAR-tqAUG+PQOqMevqDSaFFpA@mail.gmail.com>
Message-ID: <CAMH0MgLk7ML8=bWVj0B9TbGyn1KfmpJ2M_SFLYRAndKGFQH3ow@mail.gmail.com>

Thank you Ann for working on this. It has been on our roadmap[1] for some time.

Using Taskflow JobBoard would bring huge value to Octavia by allowing
sub-flow resumption of tasks.

I inquired about this in the oslo team meeting a few weeks ago and
sadly it seems that most if not all of the taskflow experts are no
longer working on OpenStack. This may mean "we" are the current
Taskflow experts....

I also inquired about adding etcd as an option for the jobs engine
implementation. Currently only Zookeeper and Redis are implemented.
Etcd is attractive as it provides similar functionality (to my limited
knowledge of what Taskflow needs) and is already an OpenStack base
service[2]. This may be an additional chunk of work to make this a
viable option.

The refactor of the flow data storage from oslo.db/sqlalchemy data
models aligns with some of the work we need to do to make the amphora
driver a proper Octavia driver. Currently it doesn't fully use the
provider driver interface data passing. This work could resolve two
issues at the same time.

It also looks like you have found a reasonable solution to the
importable flows issue.

I did include this on the topic list for the PTG[3] expecting we would
need to discuss it there. I think we have a number of questions to
answer on this topic.

1. Do we have resources to work on this?
2. Is Taskflow JobBoard the right solution? Is there alternative we
could implement without the overhead of JobBoard? Maybe a hybrid
approach is the right answer.
3. Are we ok with requiring either Zookeeper or Redis for this
functionality? Do we need to implement a TaskFlow driver for etcd?
4. Should this be implemented as an alternate controller driver to the
current implementation? (yes, even the controller is a driver in
Octavia.)

Are you planning to attend the PTG? If so we can work through these
questions there, it is already on the agenda.
If not, we should figure out either how to include you in that
discussion, or continue the discussion on the mailing list.

Michael

[1] https://wiki.openstack.org/wiki/Octavia/Roadmap
[2] https://governance.openstack.org/tc/reference/base-services.html
[3] https://etherpad.openstack.org/p/octavia-train-ptg

On Fri, Apr 19, 2019 at 6:16 AM Anna Taraday <akamyshnikova at mirantis.com> wrote:
>
> Hello everyone!
>
> I was looking at the topic of usage taskflow persistence and jobboard in Octavia [1].
> I created a simple PoC to check what should be done to enable this functionality [2] .
>
> From what I see, taskflow expects that data, which will be stored in persitence backend/jobboard backend, is a dict or an object easily converted to dicts [3] (error [3.1])
> Also functions that creates flow should be importable [4] (error [4.1]).
>
> These two points lead to refactor required for Octavia to enable taskflow persistence and jobboard:
> 1) Convert data which is passed between flows in dicts, at this moment it is db objects with links to other db objects.
> 2) Create importable flow functions.
>
> As far as I see the only OpenStack project which adapted taskflow persistence is poppy [5]
>
> I'm looking for taskflow expect to take a look at all this and give some comments - whether I am correct or missing something.
>
> Thank you for your time in advance!
>
> [1] - https://storyboard.openstack.org/#!/story/2005072
> [2] - https://review.openstack.org/#/c/647406
> [3] - https://github.com/openstack/taskflow/blob/master/taskflow/persistence/backends/impl_sqlalchemy.py#L458
> [3.1] - http://paste.openstack.org/show/749530/
> [4] - https://docs.openstack.org/taskflow/latest/_modules/taskflow/engines/helpers.html#save_factory_details
> [4.1] - http://paste.openstack.org/show/749527/
> [5] - https://github.com/openstack/poppy
>
>
> --
> Regards,
> Ann Taraday
> Mirantis, Inc


From matt at oliver.net.au  Wed Apr 24 01:51:36 2019
From: matt at oliver.net.au (Matthew Oliver)
Date: Wed, 24 Apr 2019 11:51:36 +1000
Subject: [First Contact] [SIG] [PTL] Project Liaisons Update
Message-ID: <CAEQe3ekyNpyDx9FbYDr8fU+rih+8V6maqVDmd_k=RbeWTMZHkQ@mail.gmail.com>

Hey PTLs,

Now that the new PTL election season is over and you all should be coming
to grips with your life choices. It's time to update the First contact
project liaison list[0].

What are first contact liaisons do I hear you ask? We at the first contact
SIG strive to be a point of call for new contributors. When they do contact
or we find a new contributors first patch, we try and connect them with the
project. This could be as simple a adding the liaison to the review or
providing and introduction.

Anyone can be a liaison for a project, so you're welcome to delegate,
however we do default to PTLs. Further given that we live on a globe,
tracking and having multiple liaisons on each project from different
timezones would also be a big win.

For those of you who have already delegated previously and/or are
continuing to PTL, you don't get off too easily. The world has finished
it's summertime/daylight saving dance, so is time to update your timezone's
too.

I know the summit/PTG is just around the corner, so while your updating
your etherpad and wiki's what's one more ;)

Regards,
Matt

[0] https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/8e657e81/attachment-0001.html>

From corvus at inaugust.com  Wed Apr 24 02:58:24 2019
From: corvus at inaugust.com (James E. Blair)
Date: Tue, 23 Apr 2019 19:58:24 -0700
Subject: Announcing Gertty 1.6.0
Message-ID: <87d0lckt2n.fsf@meyer.lemoncheese.net>

Announcing Gertty 1.6.0
=======================

Gertty is a console-based interface to the Gerrit Code Review system.

Gertty is designed to support a workflow similar to reading network
news or mail.  It syncs information from Gerrit to local storage to
support disconnected operation and easy manipulation of local git
repos.  It is fast and efficient at dealing with large numbers of
changes and projects.

The full README may be found here:

  https://opendev.org/ttygroup/gertty/src/branch/master/README.rst

Changes since 1.5.0:
====================

* The default config file location is now
  ~/.config/gertty/gertty.yaml (but Gertty will fall back on the
  previous default of ~/.gertty.yaml if it is not found)

* The source code is now hosted in OpenDev (https://opendev.org)

* Gertty supports (and should be run with) python3

* Added tab display support

* Reviewkeys are enabled in diffs

* Added a new option (off by default) to close the change after reviewing

* Added inline comments to the change overview screen

* The size column graph is more configurable

* Reviewkeys now support sending a message

* Added more example configurations

As well as several bug fixes and stability improvements.

Thanks to the following people whose changes are included in this
release:

Clint Byrum
Dominique Martinet
Doug Wiegley
Emilien Macchi
Ian Wienand
John L. Villalovos
Logan V
Major Hayden
Masayuki Igawa
Matthias Runge
Natal Ngétal
Nate Johnston
Nguyen Hung Phuong
Robert Collins
Tobias Henkel
Tristan Cacqueray


From manuel.sb at garvan.org.au  Tue Apr 23 07:32:33 2019
From: manuel.sb at garvan.org.au (Manuel Sopena Ballesteros)
Date: Tue, 23 Apr 2019 07:32:33 +0000
Subject: vm missing psi-passthrough device if cpu pinning is in place
Message-ID: <9D8A2486E35F0941A60430473E29F15B017EA5D1FA@mxdb2.ad.garvan.unsw.edu.au>

Dear Openstack community,

I am trying to setup a vm with bith pci-passthrough and cpu pinning.

This is my flavor:

[root at openstack-deployment ~]# openstack flavor show kudu.test.dedicated.tiny
+----------------------------+--------------------------------------------------------------+
| Field                      | Value                                                        |
+----------------------------+--------------------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False                                                        |
| OS-FLV-EXT-DATA:ephemeral  | 0                                                            |
| access_project_ids         | None                                                         |
| disk                       | 10                                                           |
| id                         | 7e241e94-1c50-4a92-9ce6-8abb272d79d8                         |
| name                       | kudu.test.dedicated.tiny                                     |
| os-flavor-access:is_public | True                                                         |
| properties                 | hw:cpu_policy='dedicated', hw:pci_passthrough:alias='nvme:1' |
| ram                        | 4096                                                         |
| rxtx_factor                | 1.0                                                          |
| swap                       |                                                              |
| vcpus                      | 2                                                            |
+----------------------------+--------------------------------------------------------------+

And this is how I create the vm:

[root at openstack-deployment ~]# openstack server create --flavor kudu.test.dedicated.tiny --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-53.localdomain kudu-test-3-1

The problem is that the vm does not have the nvme pci device attached to it.

[root at zeus-53 test]# docker exec -it nova_libvirt virsh dumpxml instance-000000ad
<domain type='kvm' id='9'>
  <name>instance-000000ad</name>
  <uuid>5d8f6cc1-e716-4f4d-ac55-df24d4cffd38</uuid>
  <metadata>
    <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0">
      <nova:package version="18.2.0-1.el7"/>
      <nova:name>kudu-test-3-1</nova:name>
      <nova:creationTime>2019-04-17 05:17:02</nova:creationTime>
      <nova:flavor name="kudu.test.dedicated.tiny">
        <nova:memory>4096</nova:memory>
        <nova:disk>10</nova:disk>
        <nova:swap>0</nova:swap>
        <nova:ephemeral>0</nova:ephemeral>
        <nova:vcpus>2</nova:vcpus>
      </nova:flavor>
      <nova:owner>
        <nova:user uuid="91e83343e9834c8ba0172ff369c8acac">admin</nova:user>
        <nova:project uuid="b91520cff5bd45c59a8de07c38641582">admin</nova:project>
      </nova:owner>
      <nova:root type="image" uuid="5ec18792-05f2-4bce-b5d8-cb3480cbb35a"/>
    </nova:instance>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <cputune>
    <shares>2048</shares>
    <vcpupin vcpu='0' cpuset='9'/>
    <vcpupin vcpu='1' cpuset='37'/>
    <emulatorpin cpuset='9,37'/>
  </cputune>
  <numatune>
    <memory mode='strict' nodeset='0'/>
    <memnode cellid='0' mode='strict' nodeset='0'/>
  </numatune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>RDO</entry>
      <entry name='product'>OpenStack Compute</entry>
      <entry name='version'>18.2.0-1.el7</entry>
      <entry name='serial'>00000000-0000-0000-0000-0cc47aa482cc</entry>
      <entry name='uuid'>5d8f6cc1-e716-4f4d-ac55-df24d4cffd38</entry>
      <entry name='family'>Virtual Machine</entry>
    </system>
  </sysinfo>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.6.0'>hvm</type>
    <boot dev='hd'/>
    <smbios mode='sysinfo'/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Skylake-Client-IBRS</model>
    <vendor>Intel</vendor>
    <topology sockets='1' cores='1' threads='2'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='stibp'/>
    <feature policy='require' name='ssbd'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='disable' name='mpx'/>
    <feature policy='disable' name='xsavec'/>
    <feature policy='disable' name='xgetbv1'/>
    <numa>
      <cell id='0' cpus='0-1' memory='4194304' unit='KiB'/>
    </numa>
  </cpu>
  <clock offset='utc'>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/nova/instances/5d8f6cc1-e716-4f4d-ac55-df24d4cffd38/disk'/>
      <backingStore type='file' index='1'>
        <format type='raw'/>
        <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='piix3-uhci'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <interface type='bridge'>
      <mac address='fa:16:3e:45:ba:a1'/>
      <source bridge='qbr2a0abb35-29'/>
      <target dev='tap2a0abb35-29'/>
      <model type='virtio'/>
      <mtu size='1500'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/14'/>
      <log file='/var/lib/nova/instances/5d8f6cc1-e716-4f4d-ac55-df24d4cffd38/console.log' append='off'/>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/14'>
      <source path='/dev/pts/14'/>
      <log file='/var/lib/nova/instances/5d8f6cc1-e716-4f4d-ac55-df24d4cffd38/console.log' append='off'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <input type='tablet' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'>
      <alias name='input1'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input2'/>
    </input>
    <graphics type='vnc' port='5901' autoport='yes' listen='192.168.1.53'>
      <listen type='address' address='192.168.1.53'/>
    </graphics>
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <stats period='10'/>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+42436:+42436</label>
    <imagelabel>+42436:+42436</imagelabel>
  </seclabel>
</domain>

However I do can see the nvme if I use a flavor without cpu pinning.

Has anyone seen this before?

Thank you
NOTICE
Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/835449b8/attachment-0001.html>

From zhangchi at szzt.com.cn  Wed Apr 24 03:42:23 2019
From: zhangchi at szzt.com.cn (zhangchi at szzt.com.cn)
Date: Wed, 24 Apr 2019 11:42:23 +0800
Subject: [tricircle] Today's Topics (2019-04-24)
Message-ID: <862e9f20995a9b63850425a2faf38dc9@szzt.com.cn>

Today's topic is:

1.  [tricircle] The bug is now being tracking: Tricircle some unit tests 
can not pass since neutron Stein introduced network_segment_ranges
      https://bugs.launchpad.net/neutron/+bug/1821567  pr have been 
submitted
2. [tricircle] tricircle unitests is being added aims at Use case 
coverage over 80% (in progress)
3. [tricircle] Make Tricircle work with zuul v3  (planned)
4. [tricircle] deploying containers in tricircle environments  (started 
and writing sepc)
5. [tricircle] finish the pr "ipv6_address_mode" not found in unit test 
(planning)
6. [tricircle] meeting will move back to IRC (openStack-meeting channel) 
every two weeks since next Wednesday (2019-05-08) UTC 1:00
7. [tricircle] learning the 9th Open Source Cloud Hackathon


From tetsuro.nakamura.bc at hco.ntt.co.jp  Wed Apr 24 04:48:05 2019
From: tetsuro.nakamura.bc at hco.ntt.co.jp (Tetsuro Nakamura)
Date: Wed, 24 Apr 2019 13:48:05 +0900
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <43163072-dda5-6631-2eb5-35d5f9a9b3ea@gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <d890bee0-58b9-450e-841e-8520233624c0@redhat.com>
 <2e1c2181-053c-326e-e01a-d970d1e70995@gmail.com>
 <b051cfe2-007f-47a8-42a2-cad6fed351ec@redhat.com>
 <ba9c760f-fd36-cdf2-010c-e0d8407d2c74@gmail.com>
 <DM6PR11MB3180EF7CAB85C01517AF49C2CA2E0@DM6PR11MB3180.namprd11.prod.outlook.com>
 <43163072-dda5-6631-2eb5-35d5f9a9b3ea@gmail.com>
Message-ID: <1041d057-f864-a91d-87e5-5085aacefdb5@hco.ntt.co.jp>

Sorry for the late response.

To be on the same page, this is how now blazar works today for the 
instance reservation

 1. User makes a reservation with start-end time via Blazar API
 2. Blazar looks up/its own DB/to pick up a host to schedule the
    instance using/its own scheduler/
 3. When the reservation time starts,
     1. Blazar gives an inventory of that reservation resource class to
        the child resource provider of the compute node resource
        provider Blazar has picked up
     2. Blazar makes a flavor which requests/consumes that reservation
        resource class and expose it to the user who made that reservation
 4. The user boots an instance with that flavor, and placement will
    schedule that instance to the compute node blazar has picked since
    the compute node is only a resource provider which has that
    reservation class inventory (in its child resource provider)

Since I’m not familiar with Ironic I’m not sure what will be the pain 
point (technical blocker) to use the same mechanism for Ironic driver.


The pain point for Blazar itself so far is the second part of the above 
sequence, that said Blazer’s mini scheduler doesn’t consider traits or 
even the overcommitting ratio in placement :(


Jay’s idea, I think, enables Blazar to offload to and rely on Placement 
only that second sequence task, solving those pain points. That sounds 
attractive to me, but on the other hand, I also don’t want every user to 
go through the new “temporal” searching path since it is useless for 
I-don’t-care-about-time users, So the point, IMO, is if we can (or 
really should?) skip the temporal stuff if not needed and if we can 
centralize the code for time in implementation since developers don’t 
want to always be aware of dealing time?



On 2019/04/22 12:07, Jay Pipes wrote:
> My apologies for the late response, Jason. Comments inline.
>
> On 04/10/2019 11:24 AM, Jason Anderson wrote:
>>     On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
>>     > On 4/9/19 7:20 PM, Jay Pipes wrote:
>>     >> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>>     >>>  From ironic perspective there is no issue, but there is a 
>> critical
>>     >>> question to decide: when Ironic+Placement is used, which of 
>> them acts
>>     >>> as the final authority? If Ironic, then we need to teach 
>> Placement to
>>     >>> talk to its Allocation API when allocating a bare metal node. If
>>     >>> Placement, then we need to support Allocation API talking to
>>     >>> Placement. I suspect the latter is saner, but I'd like to 
>> hear more
>>     >>> opinions.
>>     >>
>>     >> Ironic (scheduler?) would request candidates from the placement
>>     >> service using the GET /allocation_candidates API. Ironic 
>> (scheduler?)
>>     >> would then claim the resources on a provider (a baremetal 
>> node) by
>>     >> calling the POST /allocations API.
>>     >
>>     > Okay, this matches my expectation.
>>     >
>>     > My concern will be with Blazar and reservations. If 
>> reservations happen
>>     > through Placement only, how will ironic know about them? I 
>> guess we need
>>     > to teach Blazar to talk to Ironic, which in turn will talk to 
>> Placement.
>>
>>     Hmm. So, here's the problem: placement has no concept of time. [1]
>>
>>     Placement only knows about one period of time: now. Placement 
>> doesn't
>>     have any concept of an allocation or an inventory existing at some
>>     point
>>     in the future or in the past.
>>
>> Just to play devil's advocate... what about changing/adding this? 
>> What if Placement did support an inventory having different states 
>> depending on time frame requested?
>
> After 3+ years with the placement modeling, I've come to realize it 
> was a fundamental mistake to not include a temporal aspect to both the 
> inventories and allocations table schemas.
>
> While I would *not* support a schema that had different "states" for 
> an inventory depending on the time frame requested, I *do* think that 
> adding a claim_time and release_time column to the allocations table 
> and a start_time and end_time column to the inventories table would 
> allow Placement to fulfill a simple reservation system using the same 
> transactional logic it currently uses.
>
>> In my mind this would enable a more ideal division of
>> responsibility:
>>
>>   * Placement manages the availability of resources and maintains the
>>     single source of truth for inventory at a given time.
>
> ++
>
>>   * Blazar uses Placement as its default inventory backend. Blazar's
>>     main role now is business logic around quota and handling
>>     allocation/deallocation when a lease starts/ends.
>
> Yes on Blazar handling the release of resources when the lease ends.
>
> No on Blazar handling the acquisition of resources when the lease 
> starts (that would fundamentally be accomplished by Placement if 
> Placement had a temporal dimension to its allocations and inventories 
> table schemas).
>
> No on Blazar handling quota. Quota is a giant pain in the behind, 
> frankly. Trust me, you want no part of it ;) No matter how many 
> "dimensions" of quota slicing and dicing are made available, operators 
> will always want to add yet another dimension. If it's not quota 
> "classes", then it's different quotas per region, then different 
> quotas per AZ, then different quotas per aggregate, and on and on.
>
> Never mind the whole "we confused quotas with rate-limiting" and "here 
> is a type of quota that is not consistently measurable" problems...
>
> Anyway, my advice would be leave quotas alone if you can :)
>
>>       o But, Blazar could optionally use a different inventory backend,
>>         to allow standalone use (?)
>
> Not sure why you'd want to do this. But, as Dima remarked in another 
> sub-thread of this conversation, the question about "which things 
> should a standalone service depend on" is a religious debate. (and a 
> debate I no longer have the energy to participate in)
>
>>   * Ironic uses Placement as its default inventory backend.
>>       o But, Ironic could optionally also manage its own inventory, to
>>         allow standalone use (?)
>>
>> To further tease out the relationships here, we should think about 
>> what makes the most sense for baremetal reservations done via Blazar. 
>> Should Blazar always go to Ironic for this, ignoring Nova entirely? 
>> Or should it go through Nova if Nova is being used? I believe Blazar 
>> still will always have to go through Nova for instance reservations 
>> at minimum.
>
> Certainly Blazar will have to go through Nova *in its current 
> implementation*, since Blazar currently relies on host aggregates and 
> special aggregate and flavor metadata to "reserve" compute nodes.
>
>> Keep in mind that Blazar is designed to integrate with arbitrary 
>> external services; currently it has integrations with Neutron (for 
>> provisioning Floating IPs as part of a lease), and it could support 
>> any number of other resources, like bandwidth on an uplink.
>
> The flexibility for close integration with arbitrary services often 
> comes with a high price: complexity and potential code rot.
>
>> Having learned more about Placement's design as a result of these 
>> threads, I'm excited about how it could make some things cleaner if 
>> it truly could handle the generic inventory management problem that 
>> advanced reservations pose.
>
> If you will be in Denver, I'm happy to outline some ideas I had that 
> would pave a way for adding a temporal dimension to Placement's 
> database schema. I won't be able to implement these ideas, but I'm 
> happy to share them with you if you're interested.
>
> Best,
> -jay
>
>>     Therefore, Blazar must unfortunately keep all of the temporal state
>>     about reservations in its own data store. So, Ironic would actually
>>     have
>>     to talk to Blazar to create a reservation of some amount of 
>> resources
>>     and Blazar will need to call Placement to manage the state of 
>> resource
>>     inventory and allocations over time; as reservations are activated,
>>     Blazar will either create or swap allocation records in Placement to
>>     consume the Ironic resources for a tenant that made the reservation.
>>
>>     Best,
>>     -jay
>>     ​
>>     [1] this was a mistake for which I take full responsibility.
>>
>>
>> Cheers,
>> /Jason
>
>

-- 
Tetsuro Nakamura <nakamura.tetsuro at lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/14afb91b/attachment-0001.html>

From mizuno.shintaro at lab.ntt.co.jp  Wed Apr 24 05:31:31 2019
From: mizuno.shintaro at lab.ntt.co.jp (Shintaro Mizuno)
Date: Wed, 24 Apr 2019 14:31:31 +0900
Subject: [Forum][Ops] Ops War Stories Lightning Talk session
In-Reply-To: <7cd875d6-8db2-40be-06c4-433101827c1d@lab.ntt.co.jp>
References: <7cd875d6-8db2-40be-06c4-433101827c1d@lab.ntt.co.jp>
Message-ID: <0bde915a-949b-8ae9-d7f4-0b61b13c49f9@lab.ntt.co.jp>

Hi

Just wanted to add that the attendees will vote +1 to the talks they  
liked and the winner will get a free Summit pass for one of the next two  
Summits (Shanghai or the next one)!

We still have a few days before the Summit, so bring your story with you!

https://etherpad.openstack.org/p/DEN-ops-war-stories-LT

Best
Shintaro

On 2019/04/19 11:34, Shintaro Mizuno wrote:
> Hi
>
> There is a Forum session for the operators [1] at the Denver Summit,
> which I want to shed some light on before the Summit.
>
> This session is a Lightning Talk session for the operators to share
> their war stories and architectures.
> It will be a short 5 min slot and slides are not required (you can have
> them if you want).
>
> If you have stories to share, please put your name and a title of your
> talk to the etherpad below.
>
> [1] https://etherpad.openstack.org/p/DEN-ops-war-stories-LT
>
> Hope to see you in Denver!
>
> Best regards,
> Shintaro


-- 
Shintaro MIZUNO (水野伸太郎)
NTT Software Innovation Center
TEL: 0422-59-4977
E-mail: mizuno.shintaro at lab.ntt.co.jp (Expires on 2019.6）
New E-mail：shintaro.mizuno.gt at hco.ntt.co.jp
※メールアドレスが変わります



From zhangchi at szzt.com.cn  Wed Apr 24 07:37:13 2019
From: zhangchi at szzt.com.cn (zhangchi at szzt.com.cn)
Date: Wed, 24 Apr 2019 15:37:13 +0800
Subject: [tricircle] Bi-weekly meeting brief note (2019-04-24)
Message-ID: <c4da3e428dc0b86d477d39579f528ce4@szzt.com.cn>

Hi, All,
 
Here is today bi-weekly meeting brief note. We’ve previously decided to 
move back the Tricircle bi-weekly meeting back to community IRC channel, 
and this week some of tricircle team members facing trouble of 
registering IRC account so that we have to use wechat group for this 
week meeting again. Startling from next week, we will move back the 
meeting to IRC, when all team members having their IRC accounts ready.
 
Below is a brief note of what we discussed today,
 
1. [tricircle] This bug is now being tracked: Tricircle some unit tests 
can not pass since neutron Stein introduced network_segment_ranges
https://bugs.launchpad.net/neutron/+bug/1821567. PR has been submitted.
2. [tricircle] tricircle unit tests development is in progress, 
targeting to have 80% user case coverage.
3. [tricircle] Integrate Tricircle to work with zuul v3  (this is under 
planning)
4. [tricircle] Deploy containers in tricircle environment  (discussion 
started and currently team is working on writing spec)
5. [tricircle] Finish the PR "ipv6_address_mode" not found in unit test 
(planning)
6. [tricircle] meeting will move back to IRC (openStack-meeting channel) 
every two weeks starting from next Wednesday (2019-05-08) UTC 1:00
7. [tricircle] Haoyang shared 9th Open Source Hackathon summary held in 
Shenzhen last week to catch up latest OpenStack activity in China.


From Arvind.Kumar at ril.com  Wed Apr 24 07:51:26 2019
From: Arvind.Kumar at ril.com (Arvind Kumar)
Date: Wed, 24 Apr 2019 07:51:26 +0000
Subject: [Ceilometer]: cpu_util meter not being calculated as expected leading
 to delay in scaling
Message-ID: <BMXPR01MB08074E60CECBEFE65592E35A8A3C0@BMXPR01MB0807.INDPRD01.PROD.OUTLOOK.COM>

Hi,
A design issue is observed in ceilometer service of Openstack. Setup include multiple compute nodes and 3 controller nodes. Meters from each compute node are sent to all the 3 ceilometer instances via RabbitMQ in round robin fashion at an interval of 10 min. After transformation of cumulative cpu  meter data, cpu_util is generated by ceilometer instance at controller node and is published to the http address configured in ceilometer pipeline configuration. cpu_util is used by the application to take the decision if scaling of VM needs to be triggered or not.
Ceilometer instance calculates cpu_util for a VM from the difference between cumulative cpu usage of VM at two timestamp divided by the timestamp difference. Let's say 1 compute node send the cumulative cpu usage of a VM (C1, C2, C3, C4) at timestamp T1, T2, T3, T4 (difference between any two timestamp is 10 min). Now (C1,T1) & (C4,T4) tuple is received by ceilometer instance 1, (C2,T2) by instance 2, (C3,T3) by instance 3. Here even if CPU usage of VM is increased between T1 & T2, cpu_util is calculated for 30 min duration (T1 & T4) rather than as expected for 10 min. This leads to scaling getting triggered after T4 that too when CPU usage is consistently above the threshold between T1 and T4.
Please suggest how could this issue could be resolved. Do we have any solution to bind VM or compute node meter data to specific ceilometer instance for processing?
Regards,
Arvind.
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/3f7166d5/attachment.html>

From chkumar246 at gmail.com  Wed Apr 24 07:52:18 2019
From: chkumar246 at gmail.com (Chandan kumar)
Date: Wed, 24 Apr 2019 13:22:18 +0530
Subject: [tripleo][openstack-ansible] collaboration on os_tempest role update
 XX - Apr 24, 2019
Message-ID: <CAMzQOd=x2J2s1KQ5CVxUTsQzpWnzO-qfDpCZCxyQg8DJdytK=g@mail.gmail.com>

Hello,

Here is the 20th update (Apr 17 to Apr 23, 2019) on collaboration
on os_tempest[1] role between TripleO and OpenStack-Ansible projects.

Highlights of the week:
* os_tempest got support of novajoin tempest plugin.
* During stein branching on OSA side, we found that tempest_git_repo
is not defined
  thanks to Jesse Pretorius (odyssey4me) and mnaser for fixing it.

Things got merged:
os_tempest:
* Enable support for novajoin tempest plugin -
https://review.openstack.org/652986
* Only add tempest/tempestconf git constraints *_git_repo is defined -
https://review.opendev.org/653690

Things in Progress:
os_tempest:
* Make smoke tests as a default whitelist tests -
https://review.openstack.org/652060
* Update openstack.org -> opendev.org - https://review.opendev.org/654942

tripleo:
* Enable os_tempest in baremetal-full-overcloud-validate playbook -
https://review.openstack.org/652983
* Run novajoin tempest tests in all TLS job using os_tempest -
https://review.openstack.org/639324
* Add documentation for consuming os_tempest role -
https://review.opendev.org/#/c/654406/

What is coming?
On TripleO side, we will be working on porting all upstream standalone tripleo
jobs to os_tempest.
We will be continue working on current os_tempest patches.

Here is the 19th update [2]. Have queries, Feel free to ping us on
#tripleo or #openstack-ansible channel.

Links:
[1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest
[2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005256.html

Thanks,

Chandan Kumar


From witold.bedyk at suse.com  Wed Apr 24 08:48:27 2019
From: witold.bedyk at suse.com (Witek Bedyk)
Date: Wed, 24 Apr 2019 10:48:27 +0200
Subject: [openstack-ansible][monasca][zaqar][watcher][searchlight]
 Retirement of unused OpenStack Ansible roles
In-Reply-To: <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>
References: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
 <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>
Message-ID: <c6115dc0-3cf4-c6e6-fef1-855ccef6999c@suse.com>

Hi Guilherme and Mohammed,

I'm wondering if it's worth asking for help on maintaining these roles 
during the Summit/PTG next week, e.g. as part of Project Update session.

I could confirm that Monasca roles are up-to-date as of Rocky release.

Cheers
Witek


On 4/11/19 12:12 PM, Witek Bedyk wrote:
> Hi Guilherme,
> 
> I've added relevant project tags to the subject.
> 
> For the Monasca roles, they should be quite up-to-date right? They've 
> been updated last year. It would be great to have someone maintain them.
> 
> Cheers
> Witek
> 
> 
> On 4/5/19 5:07 AM, Guilherme Steinmüller wrote:
>> Hello all,
>>
>> We have been discussing about some of our roles that are not 
>> maintained for a while, some of them are not even integrated with our 
>> main repository. In order to the team to focus on performance and 
>> stability of the roles that has been actively used, we are discussing 
>> about retiring the unused ones.
>>
>> The roles are the following:
>>
>>      openstack-ansible-os_monasca
>>      openstack-ansible-os_monasca-agent
>>      openstack-ansible-os_zaqar
>>      openstack-ansible-os_watcher
>>      openstack-ansible-os_almanach
>>      openstack-ansible-os_molteniron
>>      openstack-ansible-os_searchlight
>>
>> We would love to help if someone wants to pick one or some of them to 
>> keep our variety of roles.  If we don't hear back, we'll retire those 
>> roles out of OpenStack Ansible.
>>
>> Thank you
>> Guilherme Steinmüller
> 
> 


From florian.engelmann at everyware.ch  Wed Apr 24 09:17:20 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Wed, 24 Apr 2019 11:17:20 +0200
Subject: kube_cluster_deploy fails
In-Reply-To: <c23b496c-bfe0-d850-bf9f-0bd58abdc8f5@catalyst.net.nz>
References: <0f00a092-1f7d-e85b-9ce4-da38cfd2c9da@everyware.ch>
 <fa4c513a-a773-2ec8-2643-ea4534a449f2@everyware.ch>
 <c23b496c-bfe0-d850-bf9f-0bd58abdc8f5@catalyst.net.nz>
Message-ID: <5080c19a-3c98-8c13-eec1-49706d3e591c@everyware.ch>

Hi Feilong,

I will answer in behalf of Pawel.

[root at kubernetes-cluster2-sdpti5674ukb-master-0 ~]# tail -n 25 
/var/log/cloud-init-output.log
Copying blob 
sha256:fb6ed010e89e8064d698019532ef87719e61ed83f10801b0ed0dee56cf46a988
  240 B / 240 B  0s
Copying config 
sha256:c1f47e73da637994ed9348a99dd25c5f66980ff887c9b2657ef48c8e481528a3
  5.83 KB / 5.83 KB  0s
Writing manifest to image destination
Storing signatures
Extracting to /var/lib/containers/atomic/heat-container-agent.0
systemctl daemon-reload
systemd-tmpfiles --create /etc/tmpfiles.d/heat-container-agent.conf
systemctl enable heat-container-agent
+ systemctl start heat-container-agent
starting services
activating service etcd
activating service docker
activating service kube-apiserver
activating service kube-controller-manager
activating service kube-scheduler
activating service kubelet
activating service kube-proxy
creating /usr/local/bin/flannel-config
Created symlink 
/etc/systemd/system/multi-user.target.wants/flannel-config.service → 
/etc/systemd/system/flannel-config.service.
activating service flanneld
activating service flanneld
Cloud-init v. 0.7.9 running 'modules:final' at Wed, 24 Apr 2019 08:20:43 
+0000. Up 18.36 seconds.
Cloud-init v. 0.7.9 finished at Wed, 24 Apr 2019 08:24:38 +0000. 
Datasource DataSourceOpenStack [net,ver=2].  Up 253.24 seconds

What is the heat task

   kube_cluster_deploy:
     type: OS::Heat::SoftwareDeployment
     properties:
       actions: ['CREATE']
       signal_transport: HEAT_SIGNAL
       config:
         get_resource: kube_cluster_config
       server:
         get_attr: [kube_masters, resource.0]


ment to do?

Is it starting the scripts listed under kube_cluster_config?

   kube_cluster_config:
     type: OS::Heat::SoftwareConfig
     properties:
       group: script
       config:
         list_join:
           - "\n"
           -
             - get_file: 
../../common/templates/kubernetes/fragments/kube-apiserver-to-kubelet-role.sh
             - str_replace:
                 template: {get_file: 
../../common/templates/kubernetes/fragments/enable-cert-api-manager.sh}
                 params:
                   "$CA_KEY": {get_param: ca_key}
             - get_file: 
../../common/templates/kubernetes/fragments/core-dns-service.sh
             - str_replace:
                 template: {get_file: 
../../common/templates/kubernetes/fragments/enable-prometheus-monitoring.sh}
                 params:
                   "$ADMIN_PASSWD": {get_param: grafana_admin_passwd}
             - get_file: 
../../common/templates/kubernetes/fragments/calico-service.sh
             - str_replace:
                 params:
                   $enable-ingress-traefik: {get_file: 
../../common/templates/kubernetes/fragments/enable-ingress-traefik.sh}
                 template: {get_file: 
../../common/templates/kubernetes/fragments/enable-ingress-controller.sh}
             - get_file: 
../../common/templates/kubernetes/fragments/kube-dashboard-service.sh

All the best,
Florian

Am 4/16/19 um 12:09 AM schrieb Feilong Wang:
> Hi Pawel,
> 
> Firstly, please remove the tls-disabled param which it's a known issue.
> And m1.small is a bit small for master which 30mins timout maybe not
> enough. Please address them and try again, then if you still see error,
> pls provied the log /var/log/cloud-init-output.log on your master node.
> Cheers.
> 
> 
> On 16/04/19 2:02 AM, Pawel Konczalski wrote:
>> Hi,
>>
>> i try to deploy a kubernetes cluster on OpenStack rocky with Magnum.
>> All Heat steps runs fine except for the last one "kube_cluster_deploy":
>>
>> kube_cluster_deploy    c3a79e96-87d8-442e-83f1-91d7a1acd896    1
>> minute    Create Failed    CREATE aborted (Task create from
>> SoftwareDeployment "kube_cluster_deploy" Stack
>> "kubernetes-cluster9-l4ol4ger3key"
>> [b17bfab3-f46a-477b-921f-4719bfd8df06] Timed out)
>>
>> The cluster contains three control / compute nodes, Octavia is also
>> installed and works fine as far as I can see.
>>
>> Atomic Image:
>> https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.raw.xz
>>
>>
>> The command was:
>> openstack coe cluster template create kubernetes-cluster-template \
>>    --image fedora-atomic-latest \
>>    --external-network public \
>>    --dns-nameserver 8.8.8.8 \
>>    --master-flavor m1.small \
>>    --flavor m1.large \
>>    --coe kubernetes \
>>    --docker-volume-size 10 \
>>    --tls-disabled \
>>    --floating-ip-enabled
>>
>> openstack coe cluster create kubernetes-cluster \
>>    --cluster-template kubernetes-cluster-template \
>>    --master-count 1 \
>>    --node-count 1 \
>>    --timeout 30 \
>>    --keypair mykey
>>
>> Did someone run also into this Problem or know how to fix it?
>>
>> BR
>>
>> Pawel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/8fbda13c/attachment-0001.bin>

From doka.ua at gmx.com  Wed Apr 24 09:46:34 2019
From: doka.ua at gmx.com (Volodymyr Litovka)
Date: Wed, 24 Apr 2019 12:46:34 +0300
Subject: [octavia] Octavia 4.x for Rocky?
Message-ID: <70a12451-df6b-2573-95a1-7d36ab2fa528@gmx.com>

Dear colleagues,

whether Octavia 4.x can be used with Rocky? Whether it makes sense (I
mean, whether Octavia's new features are tied to Stein's features)?

Thank you.

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison



From thierry at openstack.org  Wed Apr 24 09:56:39 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 24 Apr 2019 11:56:39 +0200
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
References: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
Message-ID: <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>

zuul at openstack.org wrote:
> Build failed.
> 
> - tag-releases http://logs.openstack.org/76/762e357c0d821c35b0373ac344d697807be031bf/release-post/tag-releases/283c414/ : FAILURE in 3m 35s
> - publish-tox-docs-static publish-tox-docs-static : SKIPPED

Error during release-post job processing 
https://opendev.org/openstack/releases/commit/22a2d440f0abddff4ba8d9e3cb8a17ee06791edc

The tags went through, but the Launchpad comment-adding script failed with:

python3 -u /home/zuul/scripts/release-tools/launchpad_add_comment.py 
'--subject=Fix included in openstack/panko 3.1.1' '--content=This issue 
was fixed in the openstack/panko 3.1.1 release.' 1710812
Connecting to Launchpad at 'production' using credentials in 
'/home/zuul/.launchpadlib/creds'...
Adding comment to #1710812... ERROR during save ! (HTTP Error 401: 
Unauthorized
Response headers:
---
content-length: 60
content-type: text/plain
date: Wed, 24 Apr 2019 05:17:10 GMT
server: zope.server.http (HTTP)
status: 401
x-lazr-oopsid: OOPS-f5382a2ee4e917c314954fb63ea98c61
x-powered-by: Zope (www.zope.org), Python (www.python.org)
---
Response body:
---
b'Unknown consumer (System-wide: Ubuntu (review.opendev.org)).'
---
)

We might have to reestablish credentials for that to work again...

Impact: Bugs were not commented on (job failed), and the release website 
was not refreshed (job skipped).

-- 
Thierry Carrez (ttx)


From skaplons at redhat.com  Wed Apr 24 09:58:31 2019
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 24 Apr 2019 11:58:31 +0200
Subject: [neutron] CI meeting next week
Message-ID: <20190424095831.t6rhdnyb5prvpfvn@skaplons-mac>

Hi,

As most of us will be on summit next week, CI meeting from 30.04 is cancelled.
We will have next meeting on 7.05.
See You in Denver next week :)

-- 
Slawek Kaplonski
Senior software engineer
Red Hat


From mark at stackhpc.com  Wed Apr 24 10:29:06 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 24 Apr 2019 11:29:06 +0100
Subject: [Kolla-Ansible] Support for LXC
In-Reply-To: <CAKLnnCsRkODbcVd-ZCocULfJK3bk7xm7caWa4gcKM5CZVStxew@mail.gmail.com>
References: <CAKLnnCsRkODbcVd-ZCocULfJK3bk7xm7caWa4gcKM5CZVStxew@mail.gmail.com>
Message-ID: <CAFHSqWr0TM7r5bap-jdw68puO5BifT3yTjSA5AzePK6QADyGew@mail.gmail.com>

On Thu, 18 Apr 2019 at 16:01, Amit Kumar <ebiibe82 at gmail.com> wrote:

> Hello All,
>
> We have deployed OpenStack multinode using Kolla-Ansible. We are able to
> create VMs, Docker Containers (using Zun). However, we also want to launch
> LXCs, but we couldn't find any such option in globals.yaml to enable this
> support.
>
> Is there any plan to provide it out-of-box? If anybody has enabled LXC
> using Kolla-Ansible by themselves, then also please let us know.
>

Hi Amit,

Kolla-ansible does not have explicit support for LXC-based nova instances.
I'm not aware of anyone with plans to add support for this, although if you
would like to do this work we would be happy to take it upstream.

I have not used LXC as a nova virt driver before. Do you have a feel for
what is required to make this work? Does nova use libvirt to manage the LXC
containers? If so we could probably make use of the existing libvirt image.

Regards,
Mark

Thanks.
> Regards,
> Amit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/bc19dd2b/attachment.html>

From mark at stackhpc.com  Wed Apr 24 10:36:07 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 24 Apr 2019 11:36:07 +0100
Subject: [kolla] Instance unable to contact outside network
In-Reply-To: <CALZCvAoHxhnLJ8xpCzC_j3PTms0gO9rBXj6hAN_MrigsJuQ+tQ@mail.gmail.com>
References: <CALZCvAoHxhnLJ8xpCzC_j3PTms0gO9rBXj6hAN_MrigsJuQ+tQ@mail.gmail.com>
Message-ID: <CAFHSqWpQsJaYQBnQwz_6jJ4iLznRhiqo=eEhyf+E74xtSeSkJg@mail.gmail.com>

On Sat, 20 Apr 2019 at 09:03, vladimir franciz blando <
vladimir.blando at gmail.com> wrote:

> Hi All,
>
> Deploying an OpenStack Rocky (1 controller+ceph, 1 compute+ceph)
> environment on Packet.net  using kolla-ansible 7.1.0.  Everything works
> except Instance connectivity going out.
>
> controller1 network http://paste.openstack.org/show/749565/
> compute1 network http://paste.openstack.org/show/749566/
> openvswitch show http://paste.openstack.org/show/749567/
>
> 1. Instance to Instance PING  via it's private IP = success
> 2. Instance to Instance PING via floating IP = success
> 3. Instance to gateway ping = success
> 4. Instance to outside world (ex. 8.8.8.8 or google.com) = failed
> 5. PINGing the instance from the controller node using the floating IP =
> failed
>
> Here is my global.yml file
> http://paste.openstack.org/show/lpAGgrEm8rNe43WeB8Uo/
> Here is my multinode file
> http://paste.openstack.org/show/DL7l1WG2xotH5KziwuyL/
> Here is my init-runounce file http://paste.openstack.org/show/749568/
>
> - Vlad
>

Hi Vlad,

I see you're using DVR. I'm not too familiar with it, but it sounds like
your external networking on the controller node is not setup properly. They
need to have external network access. There should be a network namespace
for the neutron router, and this should also have external network
connectivity in order to allow SNAT to work (try using ip netns exec <ns>
<command>).

Regards,
Mark

> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/2bef3abd/attachment.html>

From stig.openstack at telfer.org  Wed Apr 24 10:40:05 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Wed, 24 Apr 2019 11:40:05 +0100
Subject: [scientific-sig] No IRC meeting today
Message-ID: <0E9698DA-B005-41F0-BE94-9227C0011D38@telfer.org>

Hi All - 

Apologies, no Scientific SIG meeting today.  We have plenty going on besides in preparation for Denver next week, and I hope to see you there.

Cheers,
Stig



From mark at stackhpc.com  Wed Apr 24 10:45:53 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 24 Apr 2019 11:45:53 +0100
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
Message-ID: <CAFHSqWrDDYLVCL8fEaAgbH3DDjJtK9OHbPZaAieW+RknOUBtmQ@mail.gmail.com>

On Fri, 19 Apr 2019 at 20:35, Matt Riedemann <mriedemos at gmail.com> wrote:

> I put together an etherpad [1] for a Forum session at the upcoming
> summit to go over what happened with placement extraction in Stein and
> the plan for Train.
>
> With help I was able to figure out where the extracted placement
> packages are so it's good to know those exist.
>
> Mohammed also gave me the status on OpenStack-Ansible but I'm less clear
> on TripleO and Kolla.
>

Kolla added a placement-api image during the Stein cycle:
https://review.opendev.org/#/c/613589/

Kolla-ansible Stein release will add support for fresh deploys and
upgrades, including migration from existing nova-placement:
https://review.opendev.org/#/c/613629/

Thanks to Eduardo Gonzalez and Lee Yarwood for getting this done.


> I thought TripleO was supporting fresh installs with extracted placement
> but gerrit is down and Lee is out today so I'm not sure, and I'm not
> seeing anything about it in TripleO release notes.
>
> I did find that the Kolla release notes say they support extracted
> placement [2] but I'm not sure to what extent - is it just install from
> source (pypi?) or also some package support? How about upgrades, i.e.
> the data migration from placement-in-nova to extracted placement?
>
> So if people from the TripleO and Kolla teams can reply here and clarify
> I can get that back into the etherpad before the Forum session.
>
> [1]
>
> https://etherpad.openstack.org/p/DEN-update-on-placement-extraction-from-nova
> [2] https://docs.openstack.org/releasenotes/kolla/stein.html
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/33ceebf0/attachment-0001.html>

From jean-philippe at evrard.me  Wed Apr 24 11:12:46 2019
From: jean-philippe at evrard.me (Jean-Philippe Evrard)
Date: Wed, 24 Apr 2019 07:12:46 -0400
Subject: =?UTF-8?Q?Re:_[openstack-ansible][monasca][zaqar][watcher][searchlight]_?=
 =?UTF-8?Q?Retirement_of_unused_OpenStack_Ansible_roles?=
In-Reply-To: <c6115dc0-3cf4-c6e6-fef1-855ccef6999c@suse.com>
References: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
 <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>
 <c6115dc0-3cf4-c6e6-fef1-855ccef6999c@suse.com>
Message-ID: <236ef912-21c5-4345-98ce-067499921af1@www.fastmail.com>

I am not sure this follows our documented retirement process, and it seems very early to do so for some roles.
I think we should discuss role retirement at the next PTG (if we want to change that process).

In the meantime, I encourage people from the monasca/zaqar/watcher/searchlight community interested deploying with openstack-ansible to step up and take over their respective role's maintainance.

Regards,
Jean-Philippe Evrard (evrardjp).


From thierry at openstack.org  Wed Apr 24 11:18:25 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 24 Apr 2019 13:18:25 +0200
Subject: [ptg] ptgbot HOWTO
Message-ID: <90a0bc65-e6c6-7226-4fb5-4d25dcea9fbb@openstack.org>

Hi everyone,

In a few days, some contributor teams will meet in Denver for the 5th 
Project Teams Gathering. The event is organized around separate 'tracks' 
(generally tied to a specific team/group).

Topics of discussion are loosely scheduled in those tracks, based on the 
needs of the attendance. This allows to maximize attendee productivity, 
but the downside is that it can make the event a bit confusing to 
navigate. To mitigate that issue, we are using an IRC bot to expose 
what's happening currently at the event at the following page:

http://ptg.openstack.org/ptg.html

It is therefore useful to have a volunteer in each room who makes use of 
the PTG bot to communicate what's happening. This is done by joining the 
#openstack-ptg IRC channel on Freenode and voicing commands to the bot.

Usage of the bot is of course optional, but in past editions it was 
really useful to help attendees successfully navigate this dynamic event.


How to keep attendees informed of what's being discussed in your room
---------------------------------------------------------------------

To indicate what's currently being discussed, you will use the track 
name hashtag (found in the "Scheduled tracks" section on the above 
page), with the 'now' command:

#TRACK now <what's currently being discussed>

Example:
#swift now brainstorming improvements to the ring

You can also mention other track names to make sure to get people 
attention when the topic is transverse:

#ops-meetup now discussing #cinder pain points

There can only be one 'now' entry for a given track at a time. To
indicate what will be discussed next, you can enter one or more 'next'
commands:

#TRACK next <what will be discussed and when>

Example:
#api-sig next at 2pm we'll be discussing pagination woes

Note that in order to keep content current, entering a new 'now' command
for a track will automatically erase any 'next' entry for that track.

Finally, if you want to clear all 'now' and 'next' entries for your
track, you can issue the 'clean' command:

#TRACK clean

Example:
#ironic clean


How to book reservable rooms
----------------------------

Like at every PTG, in Denver we will have additional reservable space 
for extra un-scheduled discussions. Two of those rooms (Ballroom 4 and 
Room 112) are equipped with a projector, so if your discussion would 
benefit from projection, you can also book time there. Finally, some of 
the smaller teams do not have any pre-scheduled space, and will solely 
be relying on this feature to book the time that makes the most sense 
for them. Those teams are the OpenStack release management team 
(#release-management) and requirements team (#requirements), the 
Extended Maintenance SIG (#extended-maint-sig), the Security SIG 
(#security-sig), the Bare Metal SIG (#baremetal-sig) and the 
Interoperability working group (#interop-wg).

The PTG bot page shows which track is allocated to which room, as well 
as available reservable space, with a slot code (room name - time slot) 
that you can use to issue a 'book' command to the PTG bot:

#TRACK book <slot code>

Example:
#release-management book Room 112-ThuA1

Any track can book additional space and time using this system. All
slots are 1h45-long. If your topic of discussion does not fall into an 
existing track, it is easy to add a track on the fly. Just ask PTG bot 
admins (ttx, diablo_rojo...) on the channel to create a track for you 
(which they can do by getting op rights and issuing a ~add <TRACK> command).


For more information on the bot commands, please see:
https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

Let me know if you have any additional questions.

-- 
Thierry Carrez (ttx)


From cgoncalves at redhat.com  Wed Apr 24 11:51:33 2019
From: cgoncalves at redhat.com (Carlos Goncalves)
Date: Wed, 24 Apr 2019 13:51:33 +0200
Subject: [octavia] Octavia 4.x for Rocky?
In-Reply-To: <70a12451-df6b-2573-95a1-7d36ab2fa528@gmx.com>
References: <70a12451-df6b-2573-95a1-7d36ab2fa528@gmx.com>
Message-ID: <CAM7b86iv2mWyOZ7A6cDuYXtV_ATNTQ8EYJBRH9tgaTZbu48h9A@mail.gmail.com>

On Wed, Apr 24, 2019 at 11:48 AM Volodymyr Litovka <doka.ua at gmx.com> wrote:
>
> Dear colleagues,
>
> whether Octavia 4.x can be used with Rocky? Whether it makes sense (I
> mean, whether Octavia's new features are tied to Stein's features)?

It should work. I don't recall any new feature added in Octavia Stein
that depends on other OpenStack projects in Stein.

Be sure to read the release notes [1] and test such configuration in a
stating environment before going into production.

[1]  https://docs.openstack.org/releasenotes/octavia/stein.html

>
> Thank you.
>
> --
> Volodymyr Litovka
>    "Vision without Execution is Hallucination." -- Thomas Edison
>
>


From jean-philippe at evrard.me  Wed Apr 24 12:13:29 2019
From: jean-philippe at evrard.me (Jean-Philippe Evrard)
Date: Wed, 24 Apr 2019 08:13:29 -0400
Subject: [placement][ptg] Containers/dockerfiles
In-Reply-To: <alpine.OSX.2.21.1904161709430.4039@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091303250.93787@cdent-a01.vmware.com>
 <a6f718ce-bd72-4197-741c-a8009f32a08a@inaugust.com>
 <DF3E4736-AF29-49F7-A10B-567A07742710@leafe.com>
 <76c1870b-aff9-6789-1569-8175568f82e1@gmail.com>
 <alpine.OSX.2.21.1904161709430.4039@cdent-a01.vmware.com>
Message-ID: <fe96a204-1d23-4a51-ace2-e4323f857f39@www.fastmail.com>

Sorry for the late answer here.

As a deployer, I would prefer using the "official placement" build processes and artifacts.

Therefore:
1) I like the idea of building images using openstack-infra zuul pipelines inside placement project scope.
2) I believe the helm charts should be discussed with the openstack-helm team, as they can probably share the best practices and/or can carry this for you (with your help).

I would be happy to discuss this with you during PTG.


From jean-philippe at evrard.me  Wed Apr 24 12:15:12 2019
From: jean-philippe at evrard.me (Jean-Philippe Evrard)
Date: Wed, 24 Apr 2019 08:15:12 -0400
Subject: =?UTF-8?Q?Re:_[openstack-helm]_Office_hours_-_20:00-21:00UTC_Wednesdays_?=
 =?UTF-8?Q?in_#openstack-helm?=
In-Reply-To: <CALR0ytAJHw8M4mBCcBhg2HOR=h04xLvy_n2yaPUib2ZCtHX_jA@mail.gmail.com>
References: <CALR0ytAJHw8M4mBCcBhg2HOR=h04xLvy_n2yaPUib2ZCtHX_jA@mail.gmail.com>
Message-ID: <631f7318-aa7a-4131-bd3e-9cc7776ca554@www.fastmail.com>

I know two weeks might be very early for feedback, but how are office hours going at that time?
I am sorry I can't attend.

Regards,
Jean-Philippe Evrard (evrardjp)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/34399172/attachment.html>

From jean-philippe at evrard.me  Wed Apr 24 12:18:51 2019
From: jean-philippe at evrard.me (Jean-Philippe Evrard)
Date: Wed, 24 Apr 2019 08:18:51 -0400
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
Message-ID: <173013b6-1df9-49f5-a264-f93d6d816597@www.fastmail.com>



On Mon, Apr 15, 2019, at 23:04, Matt Riedemann wrote:
> Now that Stein is GA I figured I'd write up a quick retrospective for 
> the upgrade-checkers goal [1].
>  (snipped)
> 
> Another next step is to get deployment projects to build in a call to 
> each project's upgrade check command because without deployment projects 
> using the tool it doesn't serve much purpose. Let me note that this does 
> not need to be driven by the deployment projects either - developers 
> from each project can integrate their check into a deployment project of 
> choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment 
> project dev teams would appreciate the service project teams driving 
> this work.

Thanks Matt for leading this work, and for the work to bring the upgrade checks in OSA. It was indeed very appreciated, with our low resources.

Regards,
Jean-Philippe Evrard (evrardjp)


From gsteinmuller at vexxhost.com  Wed Apr 24 12:53:01 2019
From: gsteinmuller at vexxhost.com (=?UTF-8?Q?Guilherme_Steinm=C3=BCller?=)
Date: Wed, 24 Apr 2019 09:53:01 -0300
Subject: [openstack-ansible][monasca][zaqar][watcher][searchlight]
 Retirement of unused OpenStack Ansible roles
In-Reply-To: <236ef912-21c5-4345-98ce-067499921af1@www.fastmail.com>
References: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
 <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>
 <c6115dc0-3cf4-c6e6-fef1-855ccef6999c@suse.com>
 <236ef912-21c5-4345-98ce-067499921af1@www.fastmail.com>
Message-ID: <CAFszKC5TWd_9VXkzuDeQ92obQGNpNpKRTzrKLOA3HyiH5XOUyQ@mail.gmail.com>

Hello Witek and Jean-Philippe.

I will hold off the retirement process until the end of PTG.

Just for your information, that's what we have until now
https://review.opendev.org/#/q/topic:retire-osa-unused-roles+(status:open+OR+status:merged)
.

I just -w the monsca roles as they were the only roles someone manifested
interest.

Regards

On Wed, Apr 24, 2019 at 8:14 AM Jean-Philippe Evrard <
jean-philippe at evrard.me> wrote:

> I am not sure this follows our documented retirement process, and it seems
> very early to do so for some roles.
> I think we should discuss role retirement at the next PTG (if we want to
> change that process).
>
> In the meantime, I encourage people from the
> monasca/zaqar/watcher/searchlight community interested deploying with
> openstack-ansible to step up and take over their respective role's
> maintainance.
>
> Regards,
> Jean-Philippe Evrard (evrardjp).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/483bd1e6/attachment-0001.html>

From fungi at yuggoth.org  Wed Apr 24 13:06:32 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 24 Apr 2019 13:06:32 +0000
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>
References: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
 <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>
Message-ID: <20190424130632.m5445vsl3m5iryc5@yuggoth.org>

On 2019-04-24 11:56:39 +0200 (+0200), Thierry Carrez wrote:
[...]
> Unknown consumer (System-wide: Ubuntu (review.opendev.org)).
[...]
> We might have to reestablish credentials for that to work again...
> 
> Impact: Bugs were not commented on (job failed), and the release
> website was not refreshed (job skipped).

This is almost certainly the result of my job configuration updates
during The Great OpenDev Migration. I won't link the commit because
Gitea does a not-so-great job of displaying commits which touch
hundreds of files, but suffice to say here the hostname of the
Gerrit server was changed in the consumer_key:

https://opendev.org/openstack/project-config/src/commit/aca4bbb9009dfd49ec8c7f5a3e478e9354982c99/zuul.d/secrets.yaml#L545

I think we have a couple of viable options. We can either generate
and replace the secret there with new LP access credentials now, or
we can switch the consumer_key back to its pre-maintenance value for
now.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/a7c63557/attachment.sig>

From sean.mcginnis at gmx.com  Wed Apr 24 13:11:34 2019
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Wed, 24 Apr 2019 08:11:34 -0500
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <20190424130632.m5445vsl3m5iryc5@yuggoth.org>
References: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
 <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>
 <20190424130632.m5445vsl3m5iryc5@yuggoth.org>
Message-ID: <20190424131133.GA3368@sm-workstation>

> >
> > Impact: Bugs were not commented on (job failed), and the release
> > website was not refreshed (job skipped).
>
> This is almost certainly the result of my job configuration updates
> during The Great OpenDev Migration. I won't link the commit because
> Gitea does a not-so-great job of displaying commits which touch
> hundreds of files, but suffice to say here the hostname of the
> Gerrit server was changed in the consumer_key:
>
> https://opendev.org/openstack/project-config/src/commit/aca4bbb9009dfd49ec8c7f5a3e478e9354982c99/zuul.d/secrets.yaml#L545
>
> I think we have a couple of viable options. We can either generate
> and replace the secret there with new LP access credentials now, or
> we can switch the consumer_key back to its pre-maintenance value for
> now.
> --
> Jeremy Stanley

Either option sounds fine to me. Who can actually perform these operations?



From akamyshnikova at mirantis.com  Wed Apr 24 13:15:36 2019
From: akamyshnikova at mirantis.com (Anna Taraday)
Date: Wed, 24 Apr 2019 17:15:36 +0400
Subject: [octavia][taskflow] Adaption of persistence/jobboard (taskflow
 expert review needed)
In-Reply-To: <CAMH0MgLk7ML8=bWVj0B9TbGyn1KfmpJ2M_SFLYRAndKGFQH3ow@mail.gmail.com>
References: <CAOBv_t+S=YWT0PUqpGcz_Lwg2NAR-tqAUG+PQOqMevqDSaFFpA@mail.gmail.com>
 <CAMH0MgLk7ML8=bWVj0B9TbGyn1KfmpJ2M_SFLYRAndKGFQH3ow@mail.gmail.com>
Message-ID: <CAOBv_tLQ93_Nz1g1bKeVu4RKCDdh141K-zdfyFEXZaBX_rCa1Q@mail.gmail.com>

Thanks for your feedback!

The good thing about implementation of taskflow approach is that backend
type is set in configs and does not affect code. We can create config
settings in a flexible way, so that operators could choose which backend is
preferable for their cloud. Just have one option as default for devstack,
testing, etc.
Having etcd seems to be a good option, I did some experiments with it
several years ago. But my concern here, if we do not have taskflow experts
it may take a lot of time to implement it properly in taskflow.

It is good to hear that some of refactor could be align with other
activities and won't just disrupt the main course of work.
Implementing all of this as an alternative controller driver is a great
idea! In this case we can have it as experimental feature to gather some
user feedback.

Unfortunately, I'm not attending PTG, but I hope we will find a find to
discuss this in IRC.

On Wed, Apr 24, 2019 at 5:24 AM Michael Johnson <johnsomor at gmail.com> wrote:

> Thank you Ann for working on this. It has been on our roadmap[1] for some
> time.
>
> Using Taskflow JobBoard would bring huge value to Octavia by allowing
> sub-flow resumption of tasks.
>
> I inquired about this in the oslo team meeting a few weeks ago and
> sadly it seems that most if not all of the taskflow experts are no
> longer working on OpenStack. This may mean "we" are the current
> Taskflow experts....
>
> I also inquired about adding etcd as an option for the jobs engine
> implementation. Currently only Zookeeper and Redis are implemented.
> Etcd is attractive as it provides similar functionality (to my limited
> knowledge of what Taskflow needs) and is already an OpenStack base
> service[2]. This may be an additional chunk of work to make this a
> viable option.
>
> The refactor of the flow data storage from oslo.db/sqlalchemy data
> models aligns with some of the work we need to do to make the amphora
> driver a proper Octavia driver. Currently it doesn't fully use the
> provider driver interface data passing. This work could resolve two
> issues at the same time.
>
> It also looks like you have found a reasonable solution to the
> importable flows issue.
>
> I did include this on the topic list for the PTG[3] expecting we would
> need to discuss it there. I think we have a number of questions to
> answer on this topic.
>
> 1. Do we have resources to work on this?
> 2. Is Taskflow JobBoard the right solution? Is there alternative we
> could implement without the overhead of JobBoard? Maybe a hybrid
> approach is the right answer.
> 3. Are we ok with requiring either Zookeeper or Redis for this
> functionality? Do we need to implement a TaskFlow driver for etcd?
> 4. Should this be implemented as an alternate controller driver to the
> current implementation? (yes, even the controller is a driver in
> Octavia.)
>
> Are you planning to attend the PTG? If so we can work through these
> questions there, it is already on the agenda.
> If not, we should figure out either how to include you in that
> discussion, or continue the discussion on the mailing list.
>
> Michael
>
> [1] https://wiki.openstack.org/wiki/Octavia/Roadmap
> [2] https://governance.openstack.org/tc/reference/base-services.html
> [3] https://etherpad.openstack.org/p/octavia-train-ptg
>
> On Fri, Apr 19, 2019 at 6:16 AM Anna Taraday <akamyshnikova at mirantis.com>
> wrote:
> >
> > Hello everyone!
> >
> > I was looking at the topic of usage taskflow persistence and jobboard in
> Octavia [1].
> > I created a simple PoC to check what should be done to enable this
> functionality [2] .
> >
> > From what I see, taskflow expects that data, which will be stored in
> persitence backend/jobboard backend, is a dict or an object easily
> converted to dicts [3] (error [3.1])
> > Also functions that creates flow should be importable [4] (error [4.1]).
> >
> > These two points lead to refactor required for Octavia to enable
> taskflow persistence and jobboard:
> > 1) Convert data which is passed between flows in dicts, at this moment
> it is db objects with links to other db objects.
> > 2) Create importable flow functions.
> >
> > As far as I see the only OpenStack project which adapted taskflow
> persistence is poppy [5]
> >
> > I'm looking for taskflow expect to take a look at all this and give some
> comments - whether I am correct or missing something.
> >
> > Thank you for your time in advance!
> >
> > [1] - https://storyboard.openstack.org/#!/story/2005072
> > [2] - https://review.openstack.org/#/c/647406
> > [3] -
> https://github.com/openstack/taskflow/blob/master/taskflow/persistence/backends/impl_sqlalchemy.py#L458
> > [3.1] - http://paste.openstack.org/show/749530/
> > [4] -
> https://docs.openstack.org/taskflow/latest/_modules/taskflow/engines/helpers.html#save_factory_details
> > [4.1] - http://paste.openstack.org/show/749527/
> > [5] - https://github.com/openstack/poppy
> >
> >
> > --
> > Regards,
> > Ann Taraday
> > Mirantis, Inc
>


-- 
Regards,
Ann Taraday
Mirantis, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/ae8ccebc/attachment.html>

From mark at stackhpc.com  Wed Apr 24 13:21:49 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 24 Apr 2019 14:21:49 +0100
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
Message-ID: <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>

On Mon, 15 Apr 2019 at 22:01, Matt Riedemann <mriedemos at gmail.com> wrote:

> Now that Stein is GA I figured I'd write up a quick retrospective for
> the upgrade-checkers goal [1].
>
> Statistics
> ----------
>
>  From the tasks in the story [2]:
>
> - There were 52 total tasks.
> - Merged: 40
> - Review: 4 (still open)
> - Invalid: 8* (not applicable or opted out)
>
> Excluding Invalid tasks, the overall completion percentage of the goal
> was 91% which is pretty good. Granted, the majority of projects just
> added the placeholder framework for the upgrade check command which is
> not very useful for operators, but it's a start for those projects to
> build in real checks later.
>
> *5 of the Invalid tasks were for deployment projects which were not a
> target for the goal [3]. The others were for swift, telemetry and panko.
>
> oslo library
> ------------
>
> To ease development, Ben Nemec extracted the framework of the nova check
> code into the oslo.upgradecheck library [4]. This made getting the
> framework in place for all projects much easier and ensures a high level
> of consistency in the command structure which is really important with
> this type of thing. Thanks again Ben!
>
> Not universal
> -------------
>
> As mentioned above, not all projects implemented the command since it
> maybe didn't make sense for those projects (swift, mistral and adjutant
> are good examples) and other projects just aren't in a place
> development-wise to put much priority in the goal (telemetry and panko).
>
> Extension points
> ----------------
>
> Neutron created an extension point for their upgrade checks to support
> stadium projects and have already been using it. This was not something
> I thought about when we started the goal so it was cool that the neutron
> team embraced this and put their own spin on it.
>
> Contributions from NEC developers
> ---------------------------------
>
> Akhil Jain and Rajat Dhasmana from NEC volunteered to add the framework
> of the command in most projects which was extremely helpful. Thank you
> Akhil and Rajat, and NEC for providing development resources to work on
> a cross-community goal like this.
>
> Next
> ----
>
> While most projects have the framework in place for upgrade checks, a
> lot of projects released Stein with a simple placeholder check. A few
> projects have started adding real checks to aid in upgrades to Stein,
> which is great. I'm hopeful that other projects will add real checks as
> they encounter upgrade issues during Train development and need a way to
> signal those changes to operators in an automated way. Remember: if
> you're adding an upgrades release note, consider if you can automate
> that note.
>
> Another next step is to get deployment projects to build in a call to
> each project's upgrade check command because without deployment projects
> using the tool it doesn't serve much purpose. Let me note that this does
> not need to be driven by the deployment projects either - developers
> from each project can integrate their check into a deployment project of
> choice, like I did for OpenStack-Ansible [5]. I'm sure the deployment
> project dev teams would appreciate the service project teams driving
> this work.
>

I put together a patch for kolla-ansible with support for upgrade checks
for some projects: https://review.opendev.org/644528. It's on the
backburner at the moment but I plan to return to it during the Train cycle.
Perhaps you could clarify a few things about expected usage.

1. Should the tool be run using the new code? I would assume so.
2. How would you expect this to be run with multiple projects? I was
thinking of adding a new command that performs upgrade checks for all
projects that would be read-only, then also performing the check again as
part of the upgrade procedure.
3. For the warnings, would you recommend a -Werror style argument that
optionally flags up warnings as errors? Reporting non-fatal errors is quite
difficult in Ansible.


> [1] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
> [2] https://storyboard.openstack.org/#!/story/2003657
> [3] See the note:
>
> https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html#completion-criteria
> [4] https://docs.openstack.org/oslo.upgradecheck/latest/
> [5] https://review.openstack.org/#/c/575125/
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/7fbe5037/attachment-0001.html>

From knikolla at icloud.com  Wed Apr 24 13:53:16 2019
From: knikolla at icloud.com (Kristi Nikolla)
Date: Wed, 24 Apr 2019 09:53:16 -0400
Subject: [keystone] Team dinner in Denver
In-Reply-To: <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
References: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
 <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
Message-ID: <0BADC141-AADA-43B7-B30C-0B471DBBC20E@icloud.com>

Thanks for organizing this and picking an awesome choice. Looking forward to meeting meeting with the team after a longer than usual cycle.

Kristi

> On Apr 23, 2019, at 6:57 PM, Colleen Murphy <colleen at gazlene.net> wrote:
> 
> On Mon, Apr 15, 2019, at 09:45, Colleen Murphy wrote:
>> Berlin feels like it was ages ago, so let's organize a team dinner in 
>> Denver. Poll here:
>> 
>> https://framadate.org/BHNNU9S3f9N3lasH
>> 
>> If you have strong feelings or even mild inclinations about where to 
>> go, please comment on the poll or in the brainstorming etherpad[1] 
>> because otherwise I am pretty much just going to throw a dart.
>> 
>> Colleen
>> 
>> [1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
>> 
>> 
> 
> No one voiced any opinion about restaurant or food choices so  I made a reservation for 7pm on Wednesday, May 1 here:
> 
> https://otravezcantina.com/
> 
> based on it being close by, rated as good for groups, not too expensive, and having vegetarian and gluten-sensitive options (no one explicitly informed me they had such a requirement but I'm playing it safe). I made the reservation for 8 people based on the poll results but if anyone else would like to join we can just modify the reservation.
> 
> Colleen
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3893 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/6492b1d6/attachment.bin>

From gagehugo at gmail.com  Wed Apr 24 14:13:22 2019
From: gagehugo at gmail.com (Gage Hugo)
Date: Wed, 24 Apr 2019 09:13:22 -0500
Subject: [keystone] Team dinner in Denver
In-Reply-To: <0BADC141-AADA-43B7-B30C-0B471DBBC20E@icloud.com>
References: <e10f9135-b62f-46a0-b0c9-5e4dafd8089c@www.fastmail.com>
 <9aa303b2-6c0d-490a-94ad-7b89aac3a619@www.fastmail.com>
 <0BADC141-AADA-43B7-B30C-0B471DBBC20E@icloud.com>
Message-ID: <CAE4Awf8OKj-HiiBPyJqFF3UhdbBP+dfZVFpXs2P-xuKZ00XkKA@mail.gmail.com>

++

On Wed, Apr 24, 2019 at 8:53 AM Kristi Nikolla <knikolla at icloud.com> wrote:

> Thanks for organizing this and picking an awesome choice. Looking forward
> to meeting meeting with the team after a longer than usual cycle.
>
> Kristi
>
> > On Apr 23, 2019, at 6:57 PM, Colleen Murphy <colleen at gazlene.net> wrote:
> >
> > On Mon, Apr 15, 2019, at 09:45, Colleen Murphy wrote:
> >> Berlin feels like it was ages ago, so let's organize a team dinner in
> >> Denver. Poll here:
> >>
> >> https://framadate.org/BHNNU9S3f9N3lasH
> >>
> >> If you have strong feelings or even mild inclinations about where to
> >> go, please comment on the poll or in the brainstorming etherpad[1]
> >> because otherwise I am pretty much just going to throw a dart.
> >>
> >> Colleen
> >>
> >> [1] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
> >>
> >>
> >
> > No one voiced any opinion about restaurant or food choices so  I made a
> reservation for 7pm on Wednesday, May 1 here:
> >
> > https://otravezcantina.com/
> >
> > based on it being close by, rated as good for groups, not too expensive,
> and having vegetarian and gluten-sensitive options (no one explicitly
> informed me they had such a requirement but I'm playing it safe). I made
> the reservation for 8 people based on the poll results but if anyone else
> would like to join we can just modify the reservation.
> >
> > Colleen
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/52ca3c87/attachment.html>

From doka at ytechteam.com  Wed Apr 24 09:32:36 2019
From: doka at ytechteam.com (Volodymyr Litovka)
Date: Wed, 24 Apr 2019 12:32:36 +0300
Subject: [octavia] Octavia 4.x for Rocky?
Message-ID: <70db5480-d095-96ca-fd85-c671814ae0eb@ytechteam.com>

Dear colleagues,

whether Octavia 4.x can be used with Rocky? Whether it makes sense (I 
mean, whether Octavia's new features are tied to Stein's features)?

Thank you.

-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison



From fungi at yuggoth.org  Wed Apr 24 14:29:19 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 24 Apr 2019 14:29:19 +0000
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <20190424131133.GA3368@sm-workstation>
References: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
 <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>
 <20190424130632.m5445vsl3m5iryc5@yuggoth.org>
 <20190424131133.GA3368@sm-workstation>
Message-ID: <20190424142919.eishptwc62lmulxb@yuggoth.org>

On 2019-04-24 08:11:34 -0500 (-0500), Sean McGinnis wrote:
[...]
> > This is almost certainly the result of my job configuration updates
> > during The Great OpenDev Migration. I won't link the commit because
> > Gitea does a not-so-great job of displaying commits which touch
> > hundreds of files, but suffice to say here the hostname of the
> > Gerrit server was changed in the consumer_key:
> >
> > https://opendev.org/openstack/project-config/src/commit/aca4bbb9009dfd49ec8c7f5a3e478e9354982c99/zuul.d/secrets.yaml#L545
> >
> > I think we have a couple of viable options. We can either generate
> > and replace the secret there with new LP access credentials now, or
> > we can switch the consumer_key back to its pre-maintenance value for
> > now.
> 
> Either option sounds fine to me. Who can actually perform these operations?

Anyone can propose a change for the second option (just replace
"opendev" with "openstack" in that line). The first option requires
access to log into Launchpad with the account in question and create
a new API token, I think (if I've ever done that it's been a while
and will need a bit of poking around in the UI/docs), so probably
has to be an Infra root sysadmin with access to the LP credentials
to do that.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/c3d1c726/attachment.sig>

From thierry at openstack.org  Wed Apr 24 14:47:44 2019
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 24 Apr 2019 16:47:44 +0200
Subject: [Release-job-failures] release-post job for openstack/releases
 failed
In-Reply-To: <20190424142919.eishptwc62lmulxb@yuggoth.org>
References: <E1hJAI8-0001nX-PP@zuul01.openstack.org>
 <03021c79-28ae-32f8-76a0-fd9fa2e2dcde@openstack.org>
 <20190424130632.m5445vsl3m5iryc5@yuggoth.org>
 <20190424131133.GA3368@sm-workstation>
 <20190424142919.eishptwc62lmulxb@yuggoth.org>
Message-ID: <8023f658-0816-f1ab-8f60-8b0d585fc654@openstack.org>

Jeremy Stanley wrote:
> On 2019-04-24 08:11:34 -0500 (-0500), Sean McGinnis wrote:
> [...]
>>> This is almost certainly the result of my job configuration updates
>>> during The Great OpenDev Migration. I won't link the commit because
>>> Gitea does a not-so-great job of displaying commits which touch
>>> hundreds of files, but suffice to say here the hostname of the
>>> Gerrit server was changed in the consumer_key:
>>>
>>> https://opendev.org/openstack/project-config/src/commit/aca4bbb9009dfd49ec8c7f5a3e478e9354982c99/zuul.d/secrets.yaml#L545
>>>
>>> I think we have a couple of viable options. We can either generate
>>> and replace the secret there with new LP access credentials now, or
>>> we can switch the consumer_key back to its pre-maintenance value for
>>> now.
>>
>> Either option sounds fine to me. Who can actually perform these operations?
> 
> Anyone can propose a change for the second option (just replace
> "opendev" with "openstack" in that line). The first option requires
> access to log into Launchpad with the account in question and create
> a new API token, I think (if I've ever done that it's been a while
> and will need a bit of poking around in the UI/docs), so probably
> has to be an Infra root sysadmin with access to the LP credentials
> to do that.

I'll submit a patch for the second option. IIRC the steps for the first 
option were a bit tricky.

-- 
Thierry Carrez (ttx)


From lbragstad at gmail.com  Wed Apr 24 15:15:14 2019
From: lbragstad at gmail.com (Lance Bragstad)
Date: Wed, 24 Apr 2019 10:15:14 -0500
Subject: [dev][tc][all] Train Goal Schedule and Update
In-Reply-To: <a3ba268f-493f-444a-dbd8-4bf22091e2ed@gmail.com>
References: <c3f69c1f-d6f2-dc7a-45f8-295fc0d36564@gmail.com>
 <a3ba268f-493f-444a-dbd8-4bf22091e2ed@gmail.com>
Message-ID: <1fcfd071-4a40-2923-c593-4ecabc3ce89c@gmail.com>

Hi all,

Updating this thread again with a summary of recent goal selection activity.

We have two proposals that are still under review but they seem like
feasible goals and have champions. The first is adding the ability
generate PDFs of our documentation [0]. The second formally adds IPv6
testing support in the gate for OpenStack services [1]. The authors of
both have been diligently responding to feedback, especially under tight
time constraints with the PTG fast approaching.

There is still an opportunity to weigh-in on each and I encourage you to
do so if you haven't already. We're still optimistic that we can merge
these goals before the PTG starts next week.

Thanks,

Lance

[0] https://review.opendev.org/#/c/647712/
<https://review.opendev.org/#/c/647712/8>
[1] https://review.opendev.org/#/c/653545/

On 4/17/19 3:15 PM, Lance Bragstad wrote:
> Sending a quick follow-up here. We now have a proposal for ipv6
> testing support as a community goal [0]. Thanks to gmann for writing
> it up!
>
> I encourage folks to have a look if you have time before the PTG.
>
> [0] https://review.openstack.org/653545
>
> On 4/3/19 11:59 AM, Lance Bragstad wrote:
>> Hi all,
>>
>> Since the community goal selection process has taken a turn, we
>> wanted to send  an update regarding the current goals. We originally
>> wanted to have the goals for Train be merged by this point to give
>> project teams ample time to plan for them accordingly in their PTG
>> scheduled. Due to discussions raised in each [0][1], it doesn't sound
>> like either will be making it into Train as a feasible community
>> goal. Fortunately, a couple of last minute goals might be a perfect
>> fit for Train, instead of having a release without any community goals.
>>
>> The first one suggested is to render documentation as PDFs [2]. The
>> second goal, which still needs to be proposed, is for IPv6 support.
>> The advantage is that both of these goals are much smaller in scope,
>> but still useful. We're running up against the clock on getting goals
>> selected for Train, but we still have an opportunity to come to
>> agreement on the new proposals before the PTG.
>>
>> We'd like to ask TC and members of the community to review the
>> proposed goals at their earliest convenience. Additionally, if
>> someone wants help write up the IPv6 support goal [3][4], please
>> reach out gmann and mnaser. Even though we were originally trying to
>> make sure we had firm goals well before the PTG, the reduced scope of
>> the new goals should make them easier to talk about in impromptu
>> sessions or the hallway track.
>>
>> Thanks,
>>
>> JP & Lance
>>
>> [0] https://review.openstack.org/#/c/639376/
>> [1] https://review.openstack.org/#/c/639010/
>> [2] https://review.openstack.org/#/c/647712/
>> [3] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-03-28.log.html#t2019-03-28T15:10:36
>> [4] Note that this goal is for testing IPv6 networking setups in all
>> projects. We already have a tempest full ipv6 job, it would be a
>> matter of making these jobs passing and voting in the future.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/857f1abb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/857f1abb/attachment-0001.sig>

From openstack at nemebean.com  Wed Apr 24 15:42:52 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 24 Apr 2019 10:42:52 -0500
Subject: =?UTF-8?Q?=5boslo=5d_Proposing_Herv=c3=a9_Beraud_for_Oslo_Core?=
Message-ID: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>

Hi,

Hervé has been working on Oslo for a while now and in that time has 
shown tremendous growth in his understanding of Oslo and OpenStack. I 
think he would make a good addition to the general Oslo core team. 
Existing Oslo team members (+Keystone, Castellan, and anyone else we 
co-own libraries with) please respond with +1/-1. If there are no 
objections I'll add him to the ACL next week and we can celebrate in 
person. :-)

Thanks.

-Ben


From davanum at gmail.com  Wed Apr 24 15:46:26 2019
From: davanum at gmail.com (Davanum Srinivas)
Date: Wed, 24 Apr 2019 11:46:26 -0400
Subject: =?UTF-8?Q?Re=3A_=5Boslo=5D_Proposing_Herv=C3=A9_Beraud_for_Oslo_Core?=
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <CANw6fcEhxyTsiH0x=ua9ZkgSyye2FF+Bc_TFHkqfoKzy5zm_uA@mail.gmail.com>

+1 from me.

On Wed, Apr 24, 2019 at 11:43 AM Ben Nemec <openstack at nemebean.com> wrote:

> Hi,
>
> Hervé has been working on Oslo for a while now and in that time has
> shown tremendous growth in his understanding of Oslo and OpenStack. I
> think he would make a good addition to the general Oslo core team.
> Existing Oslo team members (+Keystone, Castellan, and anyone else we
> co-own libraries with) please respond with +1/-1. If there are no
> objections I'll add him to the ACL next week and we can celebrate in
> person. :-)
>
> Thanks.
>
> -Ben
>
>

-- 
Davanum Srinivas :: https://twitter.com/dims
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/7e446e7f/attachment.html>

From natal at redhat.com  Wed Apr 24 15:57:20 2019
From: natal at redhat.com (=?UTF-8?Q?Natal_Ng=C3=A9tal?=)
Date: Wed, 24 Apr 2019 17:57:20 +0200
Subject: =?UTF-8?Q?Re=3A_=5Boslo=5D_Proposing_Herv=C3=A9_Beraud_for_Oslo_Core?=
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <CAF+jc3XQP2dn2fEuV8xWHv4NGDMVW2N8hiB=+hxcPoLLw=o7qA@mail.gmail.com>

On Wed, Apr 24, 2019 at 5:43 PM Ben Nemec <openstack at nemebean.com> wrote:
> Hervé has been working on Oslo for a while now and in that time has
> shown tremendous growth in his understanding of Oslo and OpenStack. I
> think he would make a good addition to the general Oslo core team.
> Existing Oslo team members (+Keystone, Castellan, and anyone else we
> co-own libraries with) please respond with +1/-1. If there are no
> objections I'll add him to the ACL next week and we can celebrate in
> person. :-)
Also +1 for me. Congratulation in advance and enjoy celebration


From moguimar at redhat.com  Wed Apr 24 15:57:36 2019
From: moguimar at redhat.com (Moises Guimaraes de Medeiros)
Date: Wed, 24 Apr 2019 17:57:36 +0200
Subject: =?UTF-8?Q?Re=3A_=5Boslo=5D_Proposing_Herv=C3=A9_Beraud_for_Oslo_Core?=
In-Reply-To: <CANw6fcEhxyTsiH0x=ua9ZkgSyye2FF+Bc_TFHkqfoKzy5zm_uA@mail.gmail.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
 <CANw6fcEhxyTsiH0x=ua9ZkgSyye2FF+Bc_TFHkqfoKzy5zm_uA@mail.gmail.com>
Message-ID: <CAG_6SUDYxF-_tW+9Y3FNNTDc5cqtk+86dJZ-6-o2a0kbzED3oA@mail.gmail.com>

I'd +2 if you haven't specifically asked for a +1 ;D

Em qua, 24 de abr de 2019 às 17:47, Davanum Srinivas <davanum at gmail.com>
escreveu:

> +1 from me.
>
> On Wed, Apr 24, 2019 at 11:43 AM Ben Nemec <openstack at nemebean.com> wrote:
>
>> Hi,
>>
>> Hervé has been working on Oslo for a while now and in that time has
>> shown tremendous growth in his understanding of Oslo and OpenStack. I
>> think he would make a good addition to the general Oslo core team.
>> Existing Oslo team members (+Keystone, Castellan, and anyone else we
>> co-own libraries with) please respond with +1/-1. If there are no
>> objections I'll add him to the ACL next week and we can celebrate in
>> person. :-)
>>
>> Thanks.
>>
>> -Ben
>>
>>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>


-- 
Thanks,
Moisés Guimarães
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/4ce42596/attachment.html>

From mriedemos at gmail.com  Wed Apr 24 15:57:51 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Wed, 24 Apr 2019 10:57:51 -0500
Subject: [placement][tripleo][kolla] Update on placement extraction from
 nova
In-Reply-To: <CAFHSqWrDDYLVCL8fEaAgbH3DDjJtK9OHbPZaAieW+RknOUBtmQ@mail.gmail.com>
References: <d006903a-c42b-f689-c7b8-f67057dda6ce@gmail.com>
 <CAFHSqWrDDYLVCL8fEaAgbH3DDjJtK9OHbPZaAieW+RknOUBtmQ@mail.gmail.com>
Message-ID: <923af80e-aa84-c7bb-5506-1a0974e6d829@gmail.com>

On 4/24/2019 5:45 AM, Mark Goddard wrote:
> Kolla added a placement-api image during the Stein cycle: 
> https://review.opendev.org/#/c/613589/
> 
> Kolla-ansible Stein release will add support for fresh deploys and 
> upgrades, including migration from existing nova-placement: 
> https://review.opendev.org/#/c/613629/
> 
> Thanks to Eduardo Gonzalez and Lee Yarwood for getting this done.

Great, thanks. I've updated the etherpad.

-- 

Thanks,

Matt


From openstack at fried.cc  Wed Apr 24 16:02:44 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 24 Apr 2019 11:02:44 -0500
Subject: [nova] No meeting the week of the PTG
Message-ID: <cbae7676-c870-7859-5c22-3fec001009e7@fried.cc>

The Nova meeting that would have been held on 5/2 is canceled due to the
PTG.

efried
.


From hberaud at redhat.com  Wed Apr 24 16:02:57 2019
From: hberaud at redhat.com (Herve Beraud)
Date: Wed, 24 Apr 2019 18:02:57 +0200
Subject: =?UTF-8?Q?Re=3A_=5Boslo=5D_Proposing_Herv=C3=A9_Beraud_for_Oslo_Core?=
In-Reply-To: <CAF+jc3XQP2dn2fEuV8xWHv4NGDMVW2N8hiB=+hxcPoLLw=o7qA@mail.gmail.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
 <CAF+jc3XQP2dn2fEuV8xWHv4NGDMVW2N8hiB=+hxcPoLLw=o7qA@mail.gmail.com>
Message-ID: <CAFDq9gUPVhL6YDRjzNx2B+4bDvPK3Vq3fDZtfkpQ0US8tTVraw@mail.gmail.com>

Hi all!

Thank you guys I'm really honored!

Cheers!!!

Le mer. 24 avr. 2019 à 18:00, Natal Ngétal <natal at redhat.com> a écrit :

> On Wed, Apr 24, 2019 at 5:43 PM Ben Nemec <openstack at nemebean.com> wrote:
> > Hervé has been working on Oslo for a while now and in that time has
> > shown tremendous growth in his understanding of Oslo and OpenStack. I
> > think he would make a good addition to the general Oslo core team.
> > Existing Oslo team members (+Keystone, Castellan, and anyone else we
> > co-own libraries with) please respond with +1/-1. If there are no
> > objections I'll add him to the ACL next week and we can celebrate in
> > person. :-)
> Also +1 for me. Congratulation in advance and enjoy celebration
>
>

-- 
Hervé Beraud
Senior Software Engineer
Red Hat - Openstack Oslo
irc: hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/47265e64/attachment-0001.html>

From kgiusti at gmail.com  Wed Apr 24 16:54:31 2019
From: kgiusti at gmail.com (Ken Giusti)
Date: Wed, 24 Apr 2019 12:54:31 -0400
Subject: =?UTF-8?Q?Re=3A_=5Boslo=5D_Proposing_Herv=C3=A9_Beraud_for_Oslo_Core?=
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <CAJoCO=Miwd8wE8=xPjODJeC5ihCpY2Ve3kt++YPbR5ry1ppWYw@mail.gmail.com>

Yay Hervé!
+1

On Wed, Apr 24, 2019 at 11:50 AM Ben Nemec <openstack at nemebean.com> wrote:

> Hi,
>
> Hervé has been working on Oslo for a while now and in that time has
> shown tremendous growth in his understanding of Oslo and OpenStack. I
> think he would make a good addition to the general Oslo core team.
> Existing Oslo team members (+Keystone, Castellan, and anyone else we
> co-own libraries with) please respond with +1/-1. If there are no
> objections I'll add him to the ACL next week and we can celebrate in
> person. :-)
>
> Thanks.
>
> -Ben
>
>

-- 
Ken Giusti  (kgiusti at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/660e0bc1/attachment.html>

From amy at demarco.com  Wed Apr 24 18:01:44 2019
From: amy at demarco.com (Amy Marrich)
Date: Wed, 24 Apr 2019 13:01:44 -0500
Subject: Mentoring at Summit
Message-ID: <CAFs83QpuhWsYcr9gDzNT3uT0cGTgOU-+D90Y5GUw=c_iok66Lw@mail.gmail.com>

For those of you going to summit next week I wanted to point out a few
mentoring related sessions.

Thanks,

Amy (spotz)

Sunday:
9:00 - 5:50 OpenStack Upstream Institute sponsored by Lenovo
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23607/openstack-upstream-institute-sponsored-by-lenovo-rsvp-required

Monday:
12:20-1:40 - Speed Mentoring Lunch sponsored by Intel - RSVP required
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23757/rsvp-required-speed-mentoring-lunch-sponsored-by-intel

Tuesday:
4:20 - 5:00 - Welcoming New Contributors State of the Union
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23659/welcoming-new-contributors-state-of-the-union-and-deduplication-of-efforts

Wednesday:
10:50-11:30 - Diversity WG BoF - looking for help with the Mentoring Program
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23745/diversity-working-group-bof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/a34c9459/attachment.html>

From johfulto at redhat.com  Wed Apr 24 19:09:53 2019
From: johfulto at redhat.com (John Fulton)
Date: Wed, 24 Apr 2019 15:09:53 -0400
Subject: [tripleo] default ceph migrating from luminous to nautilus
Message-ID: <CAE66OMDOxZeS3KynnG_wwB06QLBDq8O8f5WwnYf589AhmY08HA@mail.gmail.com>

We're going to be making some updates in TripleO and RDO so that the
default version of Ceph in Stein is Nautilus. Part of this involves
temporarily disabling the standalone 001/004 jobs. Our reviews are
lined up and linked with additional details on the TripleO Integration
Squad etherpad [1]. We'll be waiting until the 3rd party checks are
green [2] before we start merging.

  John

[1] https://etherpad.openstack.org/p/tripleo-integration-squad-status
[2] https://etherpad.openstack.org/p/ruckroversprint9


From openstack at nemebean.com  Wed Apr 24 19:45:49 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 24 Apr 2019 14:45:49 -0500
Subject: [oslo] Project Update Slides
Message-ID: <9f75939f-d4c2-25d6-6470-d5a791bdadf7@nemebean.com>

First draft here: 
https://docs.google.com/presentation/d/1flIiDiXdE-M4kiL5QkvceqgkqarCm42yc8ijwK51aU8/edit?usp=sharing

If I missed anything or anything looks wrong let me know ASAP. I'll 
probably be tweaking them slightly between now and the actual session, 
but this is pretty much what I plan to present.

Thanks.

-Ben


From kennelson11 at gmail.com  Wed Apr 24 20:14:47 2019
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 24 Apr 2019 13:14:47 -0700
Subject: [storyboard] sessions at the Summit/Forum + PTG
Message-ID: <CAJ6yrQjbEubETyqG0d9qp334AANrjTvZBQ6OX07yg925heVtvg@mail.gmail.com>

Hello!

Interested in StoryBoard? Got questions? Want to join us in the development?

Well!

We have one Forum session on Monday from 3:50pm to 4:30pm [1]. The focus of
the session is to gather pain points people are encountering as we've
continued to move forward through our backlog. Please come and share
feedback with us!

We are also planning on convening in during the PTG in the infra room
Thursday morning. We will focus on a complete triage and overhaul and
prioritization of all the open stories in Storyboard. If you're interested
in helping out, come join us! We will book/update the PTGbot accordingly
next week.

-Kendall (diablo_rojo)

[1]
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23658/ibuprofen-for-your-storyboard-pain-points
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/f8859c55/attachment.html>

From mnaser at vexxhost.com  Wed Apr 24 20:47:23 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 24 Apr 2019 16:47:23 -0400
Subject: [openstack-ansible][monasca][zaqar][watcher][searchlight]
 Retirement of unused OpenStack Ansible roles
In-Reply-To: <CAFszKC5TWd_9VXkzuDeQ92obQGNpNpKRTzrKLOA3HyiH5XOUyQ@mail.gmail.com>
References: <CAFszKC7VotrcSQeScxaivGhOccRZiFXxqNUS_OB3543qMm_RyA@mail.gmail.com>
 <a1d93b06-ba4e-83cc-fc43-6009bb410399@suse.com>
 <c6115dc0-3cf4-c6e6-fef1-855ccef6999c@suse.com>
 <236ef912-21c5-4345-98ce-067499921af1@www.fastmail.com>
 <CAFszKC5TWd_9VXkzuDeQ92obQGNpNpKRTzrKLOA3HyiH5XOUyQ@mail.gmail.com>
Message-ID: <CAEs876geskLkLrYgz_N26e9AocP+yaME456ZkT_cdx0kucg7RA@mail.gmail.com>

Hi,

These roles have been broken for over a year now, some are not even
integrated with the OpenStack Ansible integrated repository.

I think it's safe to say that for the most part, they have no users or
consumers unless someone has integrated it downstream somewhere and
didn't push that back out. It is a lot of overhead to maintain roles,
we're a small team that has to manage a huge amount of roles and their
integration, while on paper, I'd love for someone to step in and help,
but no one has for over a year.

If someone wants to step in and get those roles to catch up on all the
technical debt they've accumulated (because when we'd do fixes across
all roles, we would always leave them.. because they always failed
tests..) then we're one revert away from it.  I have some thoughts on
how we can resolve this for the future, but they're much more long
term, but for now, the additional workload on our very short resourced
team is a lot.

Thanks,
Mohammed

On Wed, Apr 24, 2019 at 8:56 AM Guilherme Steinmüller
<gsteinmuller at vexxhost.com> wrote:
>
> Hello Witek and Jean-Philippe.
>
> I will hold off the retirement process until the end of PTG.
>
> Just for your information, that's what we have until now https://review.opendev.org/#/q/topic:retire-osa-unused-roles+(status:open+OR+status:merged).
>
> I just -w the monsca roles as they were the only roles someone manifested interest.
>
> Regards
>
> On Wed, Apr 24, 2019 at 8:14 AM Jean-Philippe Evrard <jean-philippe at evrard.me> wrote:
>>
>> I am not sure this follows our documented retirement process, and it seems very early to do so for some roles.
>> I think we should discuss role retirement at the next PTG (if we want to change that process).
>>
>> In the meantime, I encourage people from the monasca/zaqar/watcher/searchlight community interested deploying with openstack-ansible to step up and take over their respective role's maintainance.
>>
>> Regards,
>> Jean-Philippe Evrard (evrardjp).
>>


-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From zbitter at redhat.com  Wed Apr 24 21:38:32 2019
From: zbitter at redhat.com (Zane Bitter)
Date: Wed, 24 Apr 2019 17:38:32 -0400
Subject: =?UTF-8?Q?Re=3a_=5boslo=5d_Proposing_Herv=c3=a9_Beraud_for_Oslo_Cor?=
 =?UTF-8?Q?e?=
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <eddc9763-436d-5c68-223d-fefe1b18c9f8@redhat.com>

On 24/04/19 11:42 AM, Ben Nemec wrote:
> Hi,
> 
> Hervé has been working on Oslo for a while now and in that time has 
> shown tremendous growth in his understanding of Oslo and OpenStack. I 
> think he would make a good addition to the general Oslo core team. 
> Existing Oslo team members (+Keystone, Castellan, and anyone else we 
> co-own libraries with) please respond with +1/-1. If there are no 
> objections I'll add him to the ACL next week and we can celebrate in 
> person. :-)

+1

- ZB


From aspiers at suse.com  Wed Apr 24 22:12:16 2019
From: aspiers at suse.com (Adam Spiers)
Date: Wed, 24 Apr 2019 23:12:16 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
 <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>
Message-ID: <20190424221216.hpdm3vga37xgwped@pacific.linksys.moosehall>

Eric Fried <openstack at fried.cc> wrote: 
>Adam Spiers <aspiers at suse.com> wrote: 
>>Well, there's still the small matter of where to include the Venn diagram. 

[snipped]

>>the idea of putting it at the bottom of 
>>   https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits 
>>
>>was already rejected, otherwise it would have been there already: 
>>   https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523 
>
>Oh, I see. I get Matt's point, though I'm not sure I agree. I suppose the diagram is most useful for developers rather than admins. If there's a way we can put it somewhere permanent (that doesn't have ads) we could link it from code comments? 

I really think it belongs in one of our repos rather than an external 
SaaS which we can't rely on long-term.  After all it's only a small 
SVG.  Code comments could of course refer to an SVG within the repo, 
but I suspect that would be too well hidden to be particularly useful. 
Perhaps at the PTG we can find somewhere appropriate within the 
developer docs.  In fact maybe this is a reasonable location? 

https://docs.openstack.org/nova/latest/reference/update-provider-tree.html 

>Or find the spec that talks about this and link it from there? 

I think I already did that but realistically I don't think that's 
discoverable enough to be useful to anyone except a tiny handful who 
are occasionally inclined to perform some archaeology ;-) 


From aspiers at suse.com  Wed Apr 24 22:20:03 2019
From: aspiers at suse.com (Adam Spiers)
Date: Wed, 24 Apr 2019 23:20:03 +0100
Subject: [self-healing][PTG][Forum] Self-healing SIG sessions at Denver Forum
 and PTG
Message-ID: <20190424222003.eeysttse6mul6ken@pacific.linksys.moosehall>

Hi there,

This is a last call for topics for discussion at either of the two
self-healing SIG sessions scheduled next week in Denver.  Everyone
is warmly invited to add topics they are interested in to the etherpad:

    https://etherpad.openstack.org/p/DEN-self-healing-SIG

As always, we are particularly interested to hear feedback from
operators:

  - Are you already implementing any self-healing functionality in your OpenStack clouds?
  - If so, how are you doing it, and what's working and not working?
  - What self-healing functionality would you like to see which is currently missing?

The Birds of a Feather session on Wednesday May 1, 9:50am-10:30am is
the best time to provide that feedback:

    https://www.openstack.org/summit/denver-2019/summit-schedule/events/23743/self-healing-bof-solutions-and-use-cases

However we also have a PTG session the whole afternoon of Thursday May 2nd:

    https://www.openstack.org/ptg#tab_schedule

and while it will certainly cover developer-oriented topics, operator
feedback is very welcome there too.

Looking forward to seeing you all!

Regards,
Adam and Eric


From doug at doughellmann.com  Wed Apr 24 22:20:59 2019
From: doug at doughellmann.com (Doug Hellmann)
Date: Wed, 24 Apr 2019 18:20:59 -0400
Subject: [oslo] Proposing =?utf-8?Q?Herv=C3=A9?= Beraud for Oslo Core
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <m2lfzz82pg.fsf@doughellmann.com>

Ben Nemec <openstack at nemebean.com> writes:

> Hi,
>
> Hervé has been working on Oslo for a while now and in that time has 
> shown tremendous growth in his understanding of Oslo and OpenStack. I 
> think he would make a good addition to the general Oslo core team. 
> Existing Oslo team members (+Keystone, Castellan, and anyone else we 
> co-own libraries with) please respond with +1/-1. If there are no 
> objections I'll add him to the ACL next week and we can celebrate in 
> person. :-)
>
> Thanks.
>
> -Ben
>

+1

-- 
Doug


From openstack at fried.cc  Wed Apr 24 22:54:53 2019
From: openstack at fried.cc (Eric Fried)
Date: Wed, 24 Apr 2019 17:54:53 -0500
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <20190424221216.hpdm3vga37xgwped@pacific.linksys.moosehall>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
 <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>
 <20190424221216.hpdm3vga37xgwped@pacific.linksys.moosehall>
Message-ID: <536fd3a5-c2ce-f7a8-66b6-1aac5334152d@fried.cc>

> In fact maybe this is a reasonable location?
> https://docs.openstack.org/nova/latest/reference/update-provider-tree.html

I'm not sure that's any more discoverable than the spec (you may be
overestimating the readership of our reference docs :), but sure.

And I don't see a problem putting the .svg file in-repo - is there an
issue with that, anyone?

efried
.


From gmann at ghanshyammann.com  Wed Apr 24 23:04:42 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 24 Apr 2019 18:04:42 -0500
Subject: [all][qa][forum] Etherpad for Users / Operators adoption of QA
 tools / plugins sessions
Message-ID: <16a51981643.d64acbe715037.6501160703887523016@ghanshyammann.com>

Hello Everyone,

I've created the etherpad for the QA feedback sessions[1] which is scheduled on Wednesday, May 1, 10:50am-11:30am.  

I have added a few basic feedback questions there and If you have any additional items to add or modify,
please feel free to do that. In case, you are not able to attend this session, you can still write your feedback
with your irc/name contact. 

Etherpad: https://etherpad.openstack.org/p/Den-forum-qa-ops-user-feedback  

[1] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23660/users-operators-adoption-of-qa-tools-plugins

-gmann




From gmann at ghanshyammann.com  Wed Apr 24 23:05:10 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 24 Apr 2019 18:05:10 -0500
Subject: [all][qa][ptg][forum] QA PTG Schedule and Related Forum Sessions
Message-ID: <16a51988258.107b1553c15039.1618547545742321606@ghanshyammann.com>

Hello Everyone,

I have prepared the QA schedule for Denver Open Infrastructure Summit and PTG.  We will be meeting
for two days in PTG which is divided into two parts 1. topic discussions for one and half days 2. Code Sprint & Open Discussion.

* PTG: QA 2nd May- 3rd May 2019: Room 105
PTG Scheduled is flexible and we can adjust it based on request. 

QA Stein PTG Schedule -
https://ethercalc.openstack.org/Train-PTG-QA-Schedule 

Details of each session can be found in this etherpad -
https://etherpad.openstack.org/p/qa-train-ptg 

* Summit: QA Forum sessions:
Along with project updates & onboarding sessions, QA team will host QA feedback sessions .  
1. OpenStack QA - Project Update:  Tuesday, April 30, 2:35pm-2:55pm [1]
2. OpenStack QA - Project Onboarding : Wednesday, May 1, 9:00am-9:40am [2]
3. Users / Operators adoption of QA tools / plugins : Wednesday, May 1, 10:50am-11:30am [3]

[1]  https://www.openstack.org/summit/denver-2019/summit-schedule/events/23703/openstack-qa-project-update 
[2] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23728/openstack-qa-project-onboarding  
[3] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23660/users-operators-adoption-of-qa-tools-plugins 

-gmann




From sundar.nadathur at intel.com  Thu Apr 25 00:14:38 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 25 Apr 2019 00:14:38 +0000
Subject: gitweb link broken after OpenDev migration
Message-ID: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>

The gitweb link seen in the diffs in review.openstack.org is broken - it still points to git.openstack.org in all the diffs I looked at, and that returns a 404.

E.g. https://drive.google.com/file/d/1XVEyLnDOeJ0UUY16EfmDmV8029Ktp6HS/view?usp=sharing

Regards,
Sundar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/f162a5d4/attachment.html>

From cboylan at sapwetik.org  Thu Apr 25 00:20:36 2019
From: cboylan at sapwetik.org (Clark Boylan)
Date: Wed, 24 Apr 2019 20:20:36 -0400
Subject: gitweb link broken after OpenDev migration
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
References: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
Message-ID: <3a35af58-686a-408f-825e-e1f34818bf56@www.fastmail.com>

On Wed, Apr 24, 2019, at 5:15 PM, Nadathur, Sundar wrote:
>  
> The gitweb link seen in the diffs in review.openstack.org is broken – 
> it still points to git.openstack.org in all the diffs I looked at, and 
> that returns a 404.
> 
> 
> E.g.  
> https://drive.google.com/file/d/1XVEyLnDOeJ0UUY16EfmDmV8029Ktp6HS/view?usp=sharing 
> 
> 
> Regards,
> 
> Sundar
> 
>

This is a known issue with a fix in place, we just need to restart Gerrit for it to take effect. Unfortunately, issues with test node network connectivity, cleaning up higher priority items after the opendev migration, and Summit/PTG prep have taken our time. Hopefully, we'll be able to restart Gerrit soon and these links will start working again.

Thank you for reporting this. Please feel free to keep sending these migration related issues that you notice and we'll do our best to keep up with fixing them.

Clark


From fungi at yuggoth.org  Thu Apr 25 00:21:43 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 25 Apr 2019 00:21:43 +0000
Subject: gitweb link broken after OpenDev migration
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
References: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
Message-ID: <20190425002143.x5zqbccynfvx5mll@yuggoth.org>

On 2019-04-25 00:14:38 +0000 (+0000), Nadathur, Sundar wrote:
> The gitweb link seen in the diffs in review.openstack.org is
> broken - it still points to git.openstack.org in all the diffs I
> looked at, and that returns a 404.
[...]

It works for changes which have already merged, but not those which
are still under review. Due to performance issues encountered in
earlier Gitea testing we decided initially not to replicate refs for
changes still being reviewed, though I think a pull request is in
progress for that problem as of a few minutes ago. In the meantime
we've merged https://review.opendev.org/655238 to use a local gitweb
service on the Gerrit server itself, which will take effect as soon
as we find a convenient moment to restart the Gerrit service.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/dd836673/attachment.sig>

From sundar.nadathur at intel.com  Thu Apr 25 00:42:04 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 25 Apr 2019 00:42:04 +0000
Subject: gitweb link broken after OpenDev migration
In-Reply-To: <20190425002143.x5zqbccynfvx5mll@yuggoth.org>
References: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
 <20190425002143.x5zqbccynfvx5mll@yuggoth.org>
Message-ID: <1CC272501B5BC543A05DB90AA509DED5275524B9@fmsmsx122.amr.corp.intel.com>

Just reporting the issue, not complaining. Thanks for all your efforts.

Regards,
Sundar

> -----Original Message-----
> From: Jeremy Stanley <fungi at yuggoth.org>
> Sent: Wednesday, April 24, 2019 5:22 PM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: gitweb link broken after OpenDev migration
> 
> On 2019-04-25 00:14:38 +0000 (+0000), Nadathur, Sundar wrote:
> > The gitweb link seen in the diffs in review.openstack.org is broken -
> > it still points to git.openstack.org in all the diffs I looked at, and
> > that returns a 404.
> [...]
> 
> It works for changes which have already merged, but not those which are still
> under review. Due to performance issues encountered in earlier Gitea testing
> we decided initially not to replicate refs for changes still being reviewed,
> though I think a pull request is in progress for that problem as of a few
> minutes ago. In the meantime we've merged
> https://review.opendev.org/655238 to use a local gitweb service on the Gerrit
> server itself, which will take effect as soon as we find a convenient moment to
> restart the Gerrit service.
> --
> Jeremy Stanley


From sundar.nadathur at intel.com  Thu Apr 25 00:49:06 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 25 Apr 2019 00:49:06 +0000
Subject: [cyborg] [ironic] [ptg] Cyborg-Ironic cross-project etherpad available
Message-ID: <1CC272501B5BC543A05DB90AA509DED5275524CC@fmsmsx122.amr.corp.intel.com>

Please see https://etherpad.openstack.org/p/ptg-train-xproj-ironic-cyborg .

It has been linked to:
      https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming Line 162
     https://etherpad.openstack.org/p/DEN-train-ironic-ptg Line 198
      https://etherpad.openstack.org/p/cyborg-ptg-train Line 20
      https://wiki.openstack.org/wiki/PTG/Train/Etherpads

Regards,
Sundar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/6df1d90f/attachment.html>

From smooney at redhat.com  Thu Apr 25 00:53:54 2019
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 25 Apr 2019 01:53:54 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <536fd3a5-c2ce-f7a8-66b6-1aac5334152d@fried.cc>
References: <alpine.OSX.2.21.1904091238200.93787@cdent-a01.vmware.com>
 <13e0a009-60d3-87fe-de55-d7db24e3df8a@fried.cc>
 <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
 <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>
 <20190424221216.hpdm3vga37xgwped@pacific.linksys.moosehall>
 <536fd3a5-c2ce-f7a8-66b6-1aac5334152d@fried.cc>
Message-ID: <9ba12331208089117b90459b433deb736b5dfbc7.camel@redhat.com>

On Wed, 2019-04-24 at 17:54 -0500, Eric Fried wrote:
> > In fact maybe this is a reasonable location?
> > https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
> 
> I'm not sure that's any more discoverable than the spec (you may be
> overestimating the readership of our reference docs :), but sure.
> 
> And I don't see a problem putting the .svg file in-repo - is there an
> issue with that, anyone?
we already have a bunch of them
https://github.com/openstack/nova/tree/master/doc/source/figures
> 
> efried
> .
> 



From fungi at yuggoth.org  Thu Apr 25 01:45:01 2019
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 25 Apr 2019 01:45:01 +0000
Subject: gitweb link broken after OpenDev migration
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED5275524B9@fmsmsx122.amr.corp.intel.com>
References: <1CC272501B5BC543A05DB90AA509DED52755246D@fmsmsx122.amr.corp.intel.com>
 <20190425002143.x5zqbccynfvx5mll@yuggoth.org>
 <1CC272501B5BC543A05DB90AA509DED5275524B9@fmsmsx122.amr.corp.intel.com>
Message-ID: <20190425014501.p4azdhnwnhh5gg7q@yuggoth.org>

On 2019-04-25 00:42:04 +0000 (+0000), Nadathur, Sundar wrote:
> Just reporting the issue, not complaining. Thanks for all your efforts.
[...]

Yep, not taken as a complaint, just wanted to keep everyone updated
on the current status there. Thanks for reporting!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/a3502d1f/attachment.sig>

From tony at bakeyournoodle.com  Thu Apr 25 01:55:38 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Thu, 25 Apr 2019 11:55:38 +1000
Subject: [release] Release countdown for week R-26 and R-25, April 15-26
In-Reply-To: <0648b8dc-7b64-8b8b-e230-d4c92e8346bf@nemebean.com>
References: <20190419092254.GA26225@thor.bakeyournoodle.com>
 <0648b8dc-7b64-8b8b-e230-d4c92e8346bf@nemebean.com>
Message-ID: <20190425015133.GB16106@thor.bakeyournoodle.com>

On Mon, Apr 22, 2019 at 11:24:47AM -0500, Ben Nemec wrote:

> > Now would be a good time to start brainstorming Forum topics while some of the
> > PTG discussions are fresh. Just a couple months until the Summit and Forum in
> > Berlin.
> 
> I think your email template needs updating. ;-)

I left that in to see who was paying attention[1].


Yours Tony.

[1] That's working right you totally believe me :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/1e316196/attachment.sig>

From zhipengh512 at gmail.com  Thu Apr 25 02:01:31 2019
From: zhipengh512 at gmail.com (Zhipeng Huang)
Date: Thu, 25 Apr 2019 10:01:31 +0800
Subject: [publiccloud]Bi-weekly Meeting Thursday Apr 25th
Message-ID: <CAHZqm+UuYevi294yuHG97Rz6y8ppxTwkiUy9XmvRDfkdZg03tw@mail.gmail.com>

Hi All,

We will have our bi-weekly meeting today starting UTC1400, please checkout
the agenda at https://etherpad.openstack.org/p/publiccloud-wg

Lokk forward to your

-- 
Zhipeng (Howard) Huang

Principle Engineer
OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service
Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/82ae2652/attachment-0001.html>

From tony at bakeyournoodle.com  Thu Apr 25 02:29:23 2019
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Thu, 25 Apr 2019 12:29:23 +1000
Subject: Migrating git repos to OpenDev
In-Reply-To: <20190423113711.naxzsvyrzdtyk4jr@pacific.linksys.moosehall>
References: <87lg1qtl2k.fsf@meyer.lemoncheese.net>
 <58b71b69-afa6-4ba6-b631-9aec9263b1f1@www.fastmail.com>
 <3733e7c6-8e0f-4173-bdb4-4e640dcca015@www.fastmail.com>
 <0223b1fe-f7d7-4ab8-9d5a-cf6abe134a5f@www.fastmail.com>
 <m2o94y983b.fsf@doughellmann.com>
 <20190422010503.7fvyoi5lkkejj3cx@yuggoth.org>
 <20190423113711.naxzsvyrzdtyk4jr@pacific.linksys.moosehall>
Message-ID: <20190425022922.GC16106@thor.bakeyournoodle.com>

On Tue, Apr 23, 2019 at 12:37:11PM +0100, Adam Spiers wrote:
 
> git config --global url.https://git.openstack.org/.insteadof git://git.openstack.org/

Wow I had no idea!

I kinda feel like by shell script was wasted time :(

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/bf7ece84/attachment.sig>

From dciabrin at redhat.com  Thu Apr 25 08:05:11 2019
From: dciabrin at redhat.com (Damien Ciabrini)
Date: Thu, 25 Apr 2019 10:05:11 +0200
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
 <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>
Message-ID: <CALJNG+gfL4rbGgmr-wt46pi1onbiQUz7xKardPEcqSH0dCWSLw@mail.gmail.com>

On Tue, Apr 23, 2019 at 1:18 AM Alex Schultz <aschultz at redhat.com> wrote:

> On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec <openstack at nemebean.com> wrote:
> >
> >
> >
> > On 4/22/19 12:53 PM, Alex Schultz wrote:
> > > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec <openstack at nemebean.com>
> wrote:
> > >>
> > >>
> > >>
> > >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
> > >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700, iain.macdonnell at oracle.com
> wrote:
> > >>>>
> > >>>> Today I discovered that this problem appears to be caused by
> eventlet
> > >>>> monkey-patching. I've created a bug for it:
> > >>>>
> > >>>> https://bugs.launchpad.net/nova/+bug/1825584
> > >>>
> > >>> Hi,
> > >>>
> > >>> just for completeness we see this very same issue also with
> > >>> mistral (actually it was the first service where we noticed the
> missed
> > >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic as well,
> > >>> although I have not personally observed it there yet.
> > >>
> > >> Is Mistral also mixing eventlet monkeypatching and WSGI?
> > >>
> > >
> > > Looks like there is monkey patching, however we noticed it with the
> > > engine/executor. So it's likely not just wsgi.  I think I also saw it
> > > in the ironic-conductor, though I'd have to try it out again.  I'll
> > > spin up an undercloud today and see if I can get a more complete list
> > > of affected services. It was pretty easy to reproduce.
> >
> > Okay, I asked because if there's no WSGI/Eventlet combination then this
> > may be different from the Nova issue that prompted this thread. It
> > sounds like that was being caused by a bad interaction between WSGI and
> > some Eventlet timers. If there's no WSGI involved then I wouldn't expect
> > that to happen.
> >
> > I guess we'll see what further investigation turns up, but based on the
> > preliminary information there may be two bugs here.
> >
>
> So I wasn't able to reproduce the ironic issues yet. But it's the
> mistral executor and nova-api which exhibit the issue on the
> undercloud.
>
> mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR
> oslo.messaging._drivers.impl_rabbit [-]
> [b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on
> undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno 104]
> Connection reset by peer. Trying again in 1 seconds.:
> ConnectionResetError: [Errno 104] Connection reset by peer
>
>
> nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR
> oslo.messaging._drivers.impl_rabbit
> [req-d7767aed-e32d-43db-96a8-c0509bfb1cfe
> 9ac89090d2d24949b9a1e01b1afb14cc 7becac88cbae4b3b962ecccaf536effe -
> default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP server on
> undercloud-0.ctlplane.localdomain:5672 is unreachable: Server
> unexpectedly closed connection. Trying again in 1 seconds.: OSError:
> Server unexpectedly closed connection
>
> The errors being thrown are different perhaps it is two different problems.
>
>
Correct, I think our original issue with erratic AMQP hearbeats and mod_wsgi
was due to a change in how we run healthcheck in Stein in TripleO-deployed
environments, so different to what Iain originally experienced it seems...

For the record, up to Rocky, we used to run healthcheck scripts
every 30 seconds, which guarantees that eventlet will wake up and
send an AMQP heartbeat packet if a service had no AMQP traffic in the last
15s. It also guarantees that any incoming AMQP heartbeat packet from
rabbitmq will be processed in at most 30s.

In Stein, our healthchecks are now triggered via systemd timers, and the
current time setting is too high to guarantee that mod_wsgi will always
wake up on time to send/receive AMQP heartbeats to/from rabbitmq
when there's no traffic.

The fix is being tracked in https://bugs.launchpad.net/tripleo/+bug/1826281


> Thanks,
> -Alex
>
>

-- 
Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/c0660c56/attachment.html>

From haoqf at linux.vnet.ibm.com  Thu Apr 25 09:45:19 2019
From: haoqf at linux.vnet.ibm.com (QingFeng Hao)
Date: Thu, 25 Apr 2019 17:45:19 +0800
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <493b1096-e929-1a04-b405-77ecf515fd07@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
 <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>
 <493b1096-e929-1a04-b405-77ecf515fd07@linux.vnet.ibm.com>
Message-ID: <6c814482-cd27-8385-575e-32fb847c2b33@linux.vnet.ibm.com>



在 2019/4/23 15:25, QingFeng Hao 写道:
> 
> 
> 在 2019/4/23 15:08, Thomas Bechtold 写道:
>> Hi,
>>
>> On 4/22/19 12:58 PM, QingFeng Hao wrote:
>>> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
>>> hope it can work. thanks!
>>
>> That's the package from RDO (which is Fedora/RedHat specific afaik). rpm-packaging currently has no placement package yet.
>>
>> Best,
>>
> Thanks Tom for your tip! I think after I built placement rpm, nova can consume it through '# WSGI apache config for nova-placement-api'
> in nova.spec.j2, right?
Moreover, I didn't see placement-uwsgi.ini is installed in the spec file, and placement-api service.

cat /etc/placement/placement-uwsgi.ini

[uwsgi]
chmod-socket = 666
socket = /var/run/uwsgi/placement-api.socket
lazy-apps = true
add-header = Connection: close
buffer-size = 65535
hook-master-start = unix_signal:15 gracefully_kill_them_all
thunder-lock = true
plugins = python
enable-threads = true
worker-reload-mercy = 90
exit-on-reload = false
die-on-term = true
master = true
processes = 2
wsgi-file = /usr/local/bin/placement-api

systemctl status devstack at placement-api
* devstack at placement-api.service - Devstack devstack at placement-api.service
   Loaded: loaded (/etc/systemd/system/devstack at placement-api.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-04-11 06:52:22 CEST; 2 weeks 0 days ago
 Main PID: 656 (uwsgi)
   Status: "uWSGI is ready"
    Tasks: 3 (limit: 9394)
   CGroup: /system.slice/system-devstack.slice/devstack at placement-api.service
           |-656 placementuWSGI master
           |-739 placementuWSGI worker 1
           `-740 placementuWSGI worker 2

So more work needs to be added into the spec file, right?
thanks!
>>
>> Tom
>>
> 

-- 
Regards
QingFeng Hao



From lyarwood at redhat.com  Thu Apr 25 10:04:09 2019
From: lyarwood at redhat.com (Lee Yarwood)
Date: Thu, 25 Apr 2019 11:04:09 +0100
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <6c814482-cd27-8385-575e-32fb847c2b33@linux.vnet.ibm.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
 <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>
 <493b1096-e929-1a04-b405-77ecf515fd07@linux.vnet.ibm.com>
 <6c814482-cd27-8385-575e-32fb847c2b33@linux.vnet.ibm.com>
Message-ID: <20190425100409.bv7ci3koxjy4n7h4@lyarwood.usersys.redhat.com>

On 25-04-19 17:45:19, QingFeng Hao wrote:
> 
> 
> 在 2019/4/23 15:25, QingFeng Hao 写道:
> > 
> > 
> > 在 2019/4/23 15:08, Thomas Bechtold 写道:
> >> Hi,
> >>
> >> On 4/22/19 12:58 PM, QingFeng Hao wrote:
> >>> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
> >>> hope it can work. thanks!
> >>
> >> That's the package from RDO (which is Fedora/RedHat specific afaik). rpm-packaging currently has no placement package yet.
> >>
> >> Best,
> >>
> > Thanks Tom for your tip! I think after I built placement rpm, nova can consume it through '# WSGI apache config for nova-placement-api'
> > in nova.spec.j2, right?
> Moreover, I didn't see placement-uwsgi.ini is installed in the spec file, and placement-api service.
> 
> cat /etc/placement/placement-uwsgi.ini
> 
> [uwsgi]
> chmod-socket = 666
> socket = /var/run/uwsgi/placement-api.socket
> lazy-apps = true
> add-header = Connection: close
> buffer-size = 65535
> hook-master-start = unix_signal:15 gracefully_kill_them_all
> thunder-lock = true
> plugins = python
> enable-threads = true
> worker-reload-mercy = 90
> exit-on-reload = false
> die-on-term = true
> master = true
> processes = 2
> wsgi-file = /usr/local/bin/placement-api
> 
> systemctl status devstack at placement-api
> * devstack at placement-api.service - Devstack devstack at placement-api.service
>    Loaded: loaded (/etc/systemd/system/devstack at placement-api.service; enabled; vendor preset: enabled)
>    Active: active (running) since Thu 2019-04-11 06:52:22 CEST; 2 weeks 0 days ago
>  Main PID: 656 (uwsgi)
>    Status: "uWSGI is ready"
>     Tasks: 3 (limit: 9394)
>    CGroup: /system.slice/system-devstack.slice/devstack at placement-api.service
>            |-656 placementuWSGI master
>            |-739 placementuWSGI worker 1
>            `-740 placementuWSGI worker 2
> 
> So more work needs to be added into the spec file, right?
> thanks!

Apologies for missing this thread. 

As others have already highlighted this is a RDO specific spec that
makes some very opinionated choices around using mod_wsgi. As a result I
don't think we would accept changes introducing uwsgi support, however
that shouldn't stop you from forking this off on your own.

Cheers,

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/b574649a/attachment.sig>

From tpb at dyncloud.net  Thu Apr 25 11:05:35 2019
From: tpb at dyncloud.net (Tom Barron)
Date: Thu, 25 Apr 2019 07:05:35 -0400
Subject: [manila][ptg] manila retrospective
Message-ID: <20190425110535.w7arcja5atvwtft2@barron.net>

We will kick off Manila PTG session next Thursday with
a retrospective on the Stein cycle -- what went well,
what we should improve, etc.  So I set up an etherpad [1]
that we will use to organize the discussion.

Please go ahead and add items to the etherpad as they occur to you.

Thanks,

-- Tom Barron (tbarron)

[1] https://etherpad.openstack.org/p/manila-stein-retrospective


From bence.romsics at gmail.com  Thu Apr 25 12:43:29 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Thu, 25 Apr 2019 14:43:29 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <8748D38C-4ACA-4823-9C24-52260AC8A058@redhat.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
 <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
 <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>
 <CAHeS+3-yeROwZkjSyQ93vjaECEfNsdC_hGEDC9BarNQ4tgOeNg@mail.gmail.com>
 <8748D38C-4ACA-4823-9C24-52260AC8A058@redhat.com>
Message-ID: <CAHeS+39faSoZOgB8qrNY0ZEpdDZCW7bB664wJBfZKbaVYreahg@mail.gmail.com>

FYI: I just managed to upload the first version of the Neutron RFE and
spec. All review is welcome.

RFE: https://bugs.launchpad.net/neutron/+bug/1826396
Spec: https://review.opendev.org/655680

The Heat blueprint is coming soon too.

--
Bence


From gilles.mocellin at nuagelibre.org  Thu Apr 25 12:57:12 2019
From: gilles.mocellin at nuagelibre.org (Gilles Mocellin)
Date: Thu, 25 Apr 2019 14:57:12 +0200
Subject: [ceilometer] Add Ceph disk usage for images and instances
Message-ID: <30b6dbeef4c6fb02dc4d59646dd7052e@nuagelibre.org>

Hello,

I've seen that it's possible to add polsters to ceilometer to gather 
additional metrics.
I need to measure storage usage of my users, specially image usage 
(instance snapshots), where we still cannot have quotas.

Does someone have already done something similar, where can I start to 
investigate ?
I've seen some documentation to add Ceph RadosGW usage to Ceilometer, 
but it's not adaptable to my use case.


From sfinucan at redhat.com  Thu Apr 25 14:24:55 2019
From: sfinucan at redhat.com (Stephen Finucane)
Date: Thu, 25 Apr 2019 15:24:55 +0100
Subject: [oslo] Proposing =?ISO-8859-1?Q?Herv=E9?= Beraud for Oslo Core
In-Reply-To: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
References: <75a2b34b-e46c-8361-1ab3-c910c95a6ecb@nemebean.com>
Message-ID: <fb72a09314c7eb8c858a0a72b7bb9d9a0aed03dc.camel@redhat.com>

On Wed, 2019-04-24 at 10:42 -0500, Ben Nemec wrote:
> Hi,
> 
> Hervé has been working on Oslo for a while now and in that time has 
> shown tremendous growth in his understanding of Oslo and OpenStack. I 
> think he would make a good addition to the general Oslo core team. 
> Existing Oslo team members (+Keystone, Castellan, and anyone else we 
> co-own libraries with) please respond with +1/-1. If there are no 
> objections I'll add him to the ACL next week and we can celebrate in 
> person. :-)
> 
> Thanks.
> 
> -Ben
> 

No objections from me. +1




From mriedemos at gmail.com  Thu Apr 25 14:48:53 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 25 Apr 2019 09:48:53 -0500
Subject: [nova] Nasty new gate regression as of 4/15 - bug 1825435
In-Reply-To: <5fdb2a1b-8212-4df7-fee0-209011cd1206@gmail.com>
References: <5fdb2a1b-8212-4df7-fee0-209011cd1206@gmail.com>
Message-ID: <023d208d-4069-4e39-0102-d93aa2ef12fc@gmail.com>

On 4/19/2019 8:22 AM, Matt Riedemann wrote:
> I spotted this yesterday [1] and according to logstash it showed up 
> around 4/15. It's only hitting on nova unit tests, and I think is 
> somehow related to the TestRPC unit tests, or maybe those just stall out 
> as a result when we hit the stack overflow.
> 
> I don't think it's due to any new oslo.config or oslo.messaging versions 
> because there haven't been any, and it hits on both the 
> lower-constraints and py36 jobs (so different versions of those packages).
> 
> I've looked through the nova changes that merged since around 4/14 but 
> nothing is jumping out at me that might be causing this stack overflow 
> in the oslo.config code, but the cells v1 removal patches are pretty big 
> and I'm wondering if something snuck through there - the cells v1 unit 
> tests were doing some RPC stuff as I recall so maybe that's related.
> 
> We need all eyes on this since it's a high failure rate and we're 
> already experiencing really slow turnaround times in the gate.
> 
> [1] https://bugs.launchpad.net/nova/+bug/1825435

Just an update on this. Yes it's still happening and at a high rate [1].

I have a couple of debug patches up to try and recreate the nova unit 
test failure by detecting an infinite loop in oslo.config and then kill 
before we lose the useful part of the stacktrace [2]. The annoying thing 
is my previous attempts in the debug patch wouldn't recreate the failure 
(or if it did, it didn't dump the output from the oslo.config patch). So 
the latest version of those debug patches just makes oslo.config raise 
explicitly which should kill any nova unit test that's hitting it and 
produce a traceback in the console log output.

[1] http://status.openstack.org/elastic-recheck/#1825435
[2] https://review.opendev.org/#/q/topic:bug/1825435+status:open

-- 

Thanks,

Matt


From mriedemos at gmail.com  Thu Apr 25 14:56:13 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 25 Apr 2019 09:56:13 -0500
Subject: [nova][qa] nova-multi-cell job
Message-ID: <5ca82d09-8438-1eac-16d8-b223242b22a2@gmail.com>

We now have a working multi-cell CI job for nova proposed [1]. I've 
tried to fully document it both in the job definition and the commit 
message. I'd like this to be voting and gating as soon as possible given 
we've supported multi-cells since Pike so this has been a long-needed 
test environment for nova. However, if we want to be conservative we 
could make this non-voting in the check queue for awhile and then during 
or after the PTG make it voting and gating if people prefer.

Thoughts?

[1] https://review.opendev.org/#/c/655222/

-- 

Thanks,

Matt


From jim at jimrollenhagen.com  Thu Apr 25 14:59:15 2019
From: jim at jimrollenhagen.com (Jim Rollenhagen)
Date: Thu, 25 Apr 2019 10:59:15 -0400
Subject: [tc][all] Github mirroring (or lack thereof) for unofficial projects
Message-ID: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>

Hi,

Now that the great OpenDev migration is done, we have a number of projects
on Github which are no longer mirroring and becoming stale. This includes:

- most repositories at https://github.com/openstack-infra
- any repository in https://github.com/openstack which is no longer in
https://opendev.org/openstack
- I think that's it, but there could be others.

The OpenDev and OpenStack teams have no plans to continue mirroring these
projects to Github; primarily because we don't have a corresponding Github
organization to put them in. However, teams can easily set up a mirror to
any location they like on Github:
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html

The remaining question is what to do with the stale repos in the OpenStack
organization on Github. Right now, we plan to just archive them. This means
that the repository will be read-only, with a banner at the top saying it's
archived. If a project owner wants to transfer the project to another
Github organization, we can unarchive the project to do so, and they can
maintain the mirroring via Zuul.

If there's no wild objections to this plan, we'll go ahead with it soon.
Maybe the week after the Summit, unless someone in the OpenDev team has
spare cycles before that.

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/2148acfa/attachment.html>

From colleen at gazlene.net  Thu Apr 25 15:02:53 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Thu, 25 Apr 2019 11:02:53 -0400
Subject: Where is rpm-packaging spec for openstack placement?
In-Reply-To: <20190425100409.bv7ci3koxjy4n7h4@lyarwood.usersys.redhat.com>
References: <4b21e671-914e-ecff-715e-5eccb7a58508@linux.vnet.ibm.com>
 <7abd4cea-12aa-b449-4ba2-2eddaaa7ceec@linux.vnet.ibm.com>
 <c84d0974-53a0-ef3b-0a2d-963843f99986@suse.com>
 <493b1096-e929-1a04-b405-77ecf515fd07@linux.vnet.ibm.com>
 <6c814482-cd27-8385-575e-32fb847c2b33@linux.vnet.ibm.com>
 <20190425100409.bv7ci3koxjy4n7h4@lyarwood.usersys.redhat.com>
Message-ID: <0e67cd65-3e5f-4561-97b2-8bb47db6ad29@www.fastmail.com>

On Thu, Apr 25, 2019, at 03:05, Lee Yarwood wrote:
> On 25-04-19 17:45:19, QingFeng Hao wrote:
> > 
> > 
> > 在 2019/4/23 15:25, QingFeng Hao 写道:
> > > 
> > > 
> > > 在 2019/4/23 15:08, Thomas Bechtold 写道:
> > >> Hi,
> > >>
> > >> On 4/22/19 12:58 PM, QingFeng Hao wrote:
> > >>> I've found this here: https://github.com/rdo-packages/placement-distgit/blob/rpm-master/openstack-placement.spec
> > >>> hope it can work. thanks!
> > >>
> > >> That's the package from RDO (which is Fedora/RedHat specific afaik). rpm-packaging currently has no placement package yet.
> > >>
> > >> Best,
> > >>
> > > Thanks Tom for your tip! I think after I built placement rpm, nova can consume it through '# WSGI apache config for nova-placement-api'
> > > in nova.spec.j2, right?
> > Moreover, I didn't see placement-uwsgi.ini is installed in the spec file, and placement-api service.
> > 
> > cat /etc/placement/placement-uwsgi.ini
> > 
> > [uwsgi]
> > chmod-socket = 666
> > socket = /var/run/uwsgi/placement-api.socket
> > lazy-apps = true
> > add-header = Connection: close
> > buffer-size = 65535
> > hook-master-start = unix_signal:15 gracefully_kill_them_all
> > thunder-lock = true
> > plugins = python
> > enable-threads = true
> > worker-reload-mercy = 90
> > exit-on-reload = false
> > die-on-term = true
> > master = true
> > processes = 2
> > wsgi-file = /usr/local/bin/placement-api
> > 
> > systemctl status devstack at placement-api
> > * devstack at placement-api.service - Devstack devstack at placement-api.service
> >    Loaded: loaded (/etc/systemd/system/devstack at placement-api.service; enabled; vendor preset: enabled)
> >    Active: active (running) since Thu 2019-04-11 06:52:22 CEST; 2 weeks 0 days ago
> >  Main PID: 656 (uwsgi)
> >    Status: "uWSGI is ready"
> >     Tasks: 3 (limit: 9394)
> >    CGroup: /system.slice/system-devstack.slice/devstack at placement-api.service
> >            |-656 placementuWSGI master
> >            |-739 placementuWSGI worker 1
> >            `-740 placementuWSGI worker 2
> > 
> > So more work needs to be added into the spec file, right?
> > thanks!
> 
> Apologies for missing this thread. 
> 
> As others have already highlighted this is a RDO specific spec that
> makes some very opinionated choices around using mod_wsgi. As a result I
> don't think we would accept changes introducing uwsgi support, however
> that shouldn't stop you from forking this off on your own.

I think QingFeng's question was in response to Tom's mention of the rpm-packaging project[1], which maintains generic RPM spec templates, not the RDO-specific spec.

If you would like to contribute a placement spec file to rpm-packaging, we would welcome it. Currently the placement subpackage in nova comes with mod_wsgi support,  which may already meet your needs. If there  is a need to switch to uwsgi we can discuss that.

[1] https://opendev.org/openstack/rpm-packaging

Colleen

> 
> Cheers,
> 
> -- 
> Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
> 
> Attachments:
> * signature.asc


From juliaashleykreger at gmail.com  Thu Apr 25 15:07:23 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Thu, 25 Apr 2019 08:07:23 -0700
Subject: [ironic][ptg] Schedule/Team gathering
In-Reply-To: <CAF7gwdh9Bs_VQZ2Q4CMYsbOQSUPO0u2GHLJJXunuYNjRxMAWKQ@mail.gmail.com>
References: <CAF7gwdjhcDLzkrobA1-=0QrD5Prz_xd24M61SR8wAC69_mdXMQ@mail.gmail.com>
 <20e15025-d698-bd01-c117-f7d543f4d354@redhat.com>
 <CAF7gwdh9Bs_VQZ2Q4CMYsbOQSUPO0u2GHLJJXunuYNjRxMAWKQ@mail.gmail.com>
Message-ID: <CAF7gwdgVNYg-9ZJcjHz601tVJ0ycPbBKh7asEyjFcyZPxA5bjw@mail.gmail.com>

In discussion and agreement with several others, I've decided that
Ironic will not hold a group evening gathering given the mix of
community events, corporate gatherings/events, and varying travel
schedules.

That being said, I encourage everyone to reach out to 2-3 people who
you might not normally chat or interact with, and make plans to have a
cup of coffee, tea, or a beverage. Maybe go out and have a quiet
dinner. Chat about anything! Bonus points for about ironic! The key is
to socialize! To build our network of friendships! To relax and
recharge!

-Julia

On Thu, Apr 11, 2019 at 7:56 AM Julia Kreger
<juliaashleykreger at gmail.com> wrote:
>
> On Thu, Apr 11, 2019 at 3:34 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
> >
> > On 4/10/19 7:38 PM, Julia Kreger wrote:
> > > Greetings fellow ?Ironicans?
> > >
> > > I've posted a new etherpad[0] based upon our discussion in the
> > > planning etherpad[1]. Please review and if there are any scheduling
> > > issues please let me know.
> >
> > I suspect Community Sustainability will take longer than planned. Otherwise
> > looks great, thanks for composing it!
> >
>
> That was my fear as well, but I decided to error on the side of time
> boxing in a sense because we don't want to really create runaway
> conversations. I think it is also going to entirely depend on the mood
> and how much coffee is in the room. :)
>
> > >
> > > Also, we need to figure out an evening for a team gathering. I've
> > > posted a doodle[3]. Please submit it with-in the next few days and
> > > I'll begin looking around for someplace that might work.
> >
> > Do we know when the official events will take place? I'm only aware of the
> > marketplace event on Monday.
> >
>
> I think there is something on Tuesday night, but I'm not entirely
> sure. Ultimately I think we're going to have to avoid Monday/Tuesday.
>
> > >
> > > Thanks everyone!
> > >
> > > -Julia
> > > [0]: https://etherpad.openstack.org/p/DEN-train-ironic-ptg
> > > [1]: https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
> > > [2]: https://doodle.com/poll/e6q5e6pm72wbiwtz
> > >
> >
> >


From iain.macdonnell at oracle.com  Thu Apr 25 15:10:14 2019
From: iain.macdonnell at oracle.com (iain.macdonnell at oracle.com)
Date: Thu, 25 Apr 2019 08:10:14 -0700
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <CALJNG+gfL4rbGgmr-wt46pi1onbiQUz7xKardPEcqSH0dCWSLw@mail.gmail.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
 <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>
 <CALJNG+gfL4rbGgmr-wt46pi1onbiQUz7xKardPEcqSH0dCWSLw@mail.gmail.com>
Message-ID: <607fdf0d-7820-291f-5a21-202f167da5bc@oracle.com>



On 4/25/19 1:05 AM, Damien Ciabrini wrote:
> 
> 
> On Tue, Apr 23, 2019 at 1:18 AM Alex Schultz <aschultz at redhat.com 
> <mailto:aschultz at redhat.com>> wrote:
> 
>     On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec <openstack at nemebean.com
>     <mailto:openstack at nemebean.com>> wrote:
>      >
>      >
>      >
>      > On 4/22/19 12:53 PM, Alex Schultz wrote:
>      > > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec
>     <openstack at nemebean.com <mailto:openstack at nemebean.com>> wrote:
>      > >>
>      > >>
>      > >>
>      > >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
>      > >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700,
>     iain.macdonnell at oracle.com <mailto:iain.macdonnell at oracle.com> wrote:
>      > >>>>
>      > >>>> Today I discovered that this problem appears to be caused by
>     eventlet
>      > >>>> monkey-patching. I've created a bug for it:
>      > >>>>
>      > >>>> https://bugs.launchpad.net/nova/+bug/1825584
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_nova_-2Bbug_1825584&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=fpephoqJ2hzc-jFPr6Rtupc2U02HBjBRd-_Lq66zQBk&s=Vb1Yw7ZkrglH0AMBZSHNfuilS5gBwh9yF2o2trkXYyM&e=>
>      > >>>
>      > >>> Hi,
>      > >>>
>      > >>> just for completeness we see this very same issue also with
>      > >>> mistral (actually it was the first service where we noticed
>     the missed
>      > >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic
>     as well,
>      > >>> although I have not personally observed it there yet.
>      > >>
>      > >> Is Mistral also mixing eventlet monkeypatching and WSGI?
>      > >>
>      > >
>      > > Looks like there is monkey patching, however we noticed it with the
>      > > engine/executor. So it's likely not just wsgi.  I think I also
>     saw it
>      > > in the ironic-conductor, though I'd have to try it out again.  I'll
>      > > spin up an undercloud today and see if I can get a more
>     complete list
>      > > of affected services. It was pretty easy to reproduce.
>      >
>      > Okay, I asked because if there's no WSGI/Eventlet combination
>     then this
>      > may be different from the Nova issue that prompted this thread. It
>      > sounds like that was being caused by a bad interaction between
>     WSGI and
>      > some Eventlet timers. If there's no WSGI involved then I wouldn't
>     expect
>      > that to happen.
>      >
>      > I guess we'll see what further investigation turns up, but based
>     on the
>      > preliminary information there may be two bugs here.
>      >
> 
>     So I wasn't able to reproduce the ironic issues yet. But it's the
>     mistral executor and nova-api which exhibit the issue on the
>     undercloud.
> 
>     mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR
>     oslo.messaging._drivers.impl_rabbit [-]
>     [b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on
>     undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno 104]
>     Connection reset by peer. Trying again in 1 seconds.:
>     ConnectionResetError: [Errno 104] Connection reset by peer
> 
> 
>     nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR
>     oslo.messaging._drivers.impl_rabbit
>     [req-d7767aed-e32d-43db-96a8-c0509bfb1cfe
>     9ac89090d2d24949b9a1e01b1afb14cc 7becac88cbae4b3b962ecccaf536effe -
>     default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP server on
>     undercloud-0.ctlplane.localdomain:5672 is unreachable: Server
>     unexpectedly closed connection. Trying again in 1 seconds.: OSError:
>     Server unexpectedly closed connection
> 
>     The errors being thrown are different perhaps it is two different
>     problems.
> 
> 
> Correct, I think our original issue with erratic AMQP hearbeats and mod_wsgi
> was due to a change in how we run healthcheck in Stein in TripleO-deployed
> environments, so different to what Iain originally experienced it seems...
> 
> For the record, up to Rocky, we used to run healthcheck scripts
> every 30 seconds, which guarantees that eventlet will wake up and
> send an AMQP heartbeat packet if a service had no AMQP traffic in the last
> 15s. It also guarantees that any incoming AMQP heartbeat packet from
> rabbitmq will be processed in at most 30s.
> 
> In Stein, our healthchecks are now triggered via systemd timers, and the
> current time setting is too high to guarantee that mod_wsgi will always
> wake up on time to send/receive AMQP heartbeats to/from rabbitmq
> when there's no traffic.

If I'm reading this right, it sounds like the periodic healthcheck is 
working around the underlying issue of the heartbeats not happening by 
themselves (due to eventlet monkey-patching somehow interfering with 
threading). The whole point of the heartbeats is to continually maintain 
the connection while there's no real traffic.

     ~iain



From doug at doughellmann.com  Thu Apr 25 16:02:22 2019
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 25 Apr 2019 12:02:22 -0400
Subject: [tc][all] Github mirroring (or lack thereof) for unofficial
 projects
In-Reply-To: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
References: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
Message-ID: <m2imv2844x.fsf@doughellmann.com>

Jim Rollenhagen <jim at jimrollenhagen.com> writes:

> Hi,
>
> Now that the great OpenDev migration is done, we have a number of projects
> on Github which are no longer mirroring and becoming stale. This includes:
>
> - most repositories at https://github.com/openstack-infra
> - any repository in https://github.com/openstack which is no longer in
> https://opendev.org/openstack
> - I think that's it, but there could be others.
>
> The OpenDev and OpenStack teams have no plans to continue mirroring these
> projects to Github; primarily because we don't have a corresponding Github
> organization to put them in. However, teams can easily set up a mirror to
> any location they like on Github:
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
>
> The remaining question is what to do with the stale repos in the OpenStack
> organization on Github. Right now, we plan to just archive them. This means
> that the repository will be read-only, with a banner at the top saying it's
> archived. If a project owner wants to transfer the project to another
> Github organization, we can unarchive the project to do so, and they can
> maintain the mirroring via Zuul.
>
> If there's no wild objections to this plan, we'll go ahead with it soon.
> Maybe the week after the Summit, unless someone in the OpenDev team has
> spare cycles before that.
>
> // jim

+1

-- 
Doug


From tpb at dyncloud.net  Thu Apr 25 16:18:10 2019
From: tpb at dyncloud.net (Tom Barron)
Date: Thu, 25 Apr 2019 12:18:10 -0400
Subject: [manila] no meeting next week 2 May
Message-ID: <20190425161810.ypxkydopnh3i5nyk@barron.net>

Because we'll be doing PTG instead.  Check #openstack-manila on 
freenode starting at 1500 UTC on 2 May for remote attendance
instructions.

We'll have our regular meeting a week later on 9 May on 
#openstack-meeting-alt at 1500 UTC.

-- Tom Barron (tbarron)


From rony.khan at brilliant.com.bd  Thu Apr 25 16:43:08 2019
From: rony.khan at brilliant.com.bd (Md. Farhad Hasan Khan)
Date: Thu, 25 Apr 2019 22:43:08 +0600
Subject: OpenStack instance fail to boot after unexpected compute node shutdown
Message-ID: <009001d4fb85$f7696a50$e63c3ef0$@brilliant.com.bd>

Hi,

We are running Openstack Rocky version. Our instances are getting volume
from CEPH (mimic version).

Suddenly one of our compute node got shutdown due to RAM issue. So all
instances running on that compute node (linux/windows) got effected. After
starting the compute node all services up & running. But instances on that
compute node fail to boot. Instances are getting volume from CEPH storage &
CEPH is in Healthy state. Please see below log.

Requesting if anyone can help me to solve.

 

 

````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````

````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````

 

 

Welcome to [0;34mCentOS Linux 7 (Core) dracut-033-554.el7 (Initramfs)[0m!

 

[    2.543762] systemd[1]: Set hostname to <localhost.localdomain>.

[    2.601779] usb 1-1: new full-speed USB device number 2 using uhci_hcd

[    2.609813] random: systemd: uninitialized urandom read (16 bytes read)

[    2.616574] random: systemd: uninitialized urandom read (16 bytes read)

[    2.622966] random: systemd: uninitialized urandom read (16 bytes read)

[    2.628863] random: systemd: uninitialized urandom read (16 bytes read)

[    2.635771] random: systemd: uninitialized urandom read (16 bytes read)

[    2.641509] random: systemd: uninitialized urandom read (16 bytes read)

[    2.647362] random: systemd: uninitialized urandom read (16 bytes read)

[    2.660222] systemd[1]: Reached target Local File Systems.

[[32m  OK  [0m] Reached target Local File Systems.

[    2.668273] systemd[1]: Created slice Root Slice.

[[32m  OK  [0m] Created slice Root Slice.

[    2.674835] systemd[1]: Created slice System Slice.

[[32m  OK  [0m] Created slice System Slice.

[    2.681170] systemd[1]: Listening on udev Kernel Socket.

[[32m  OK  [0m] Listening on udev Kernel Socket.

[    2.687811] systemd[1]: Listening on Journal Socket.

[[32m  OK  [0m] Listening on Journal Socket.

[    2.694604] systemd[1]: Starting Create list of required static device
nodes for the current kernel...

         Starting Create list of required st... nodes for the current
kernel...

[    2.705069] systemd[1]: Starting Journal Service...

         Starting Journal Service...

[    2.710298] systemd[1]: Listening on udev Control Socket.

[[32m  OK  [0m] Listening on udev Control Socket.

[    2.715399] systemd[1]: Reached target Sockets.

[[32m  OK  [0m] Reached target Sockets.

[    2.720550] systemd[1]: Starting dracut cmdline hook...

         Starting dracut cmdline hook...

[    2.725277] systemd[1]: Reached target Slices.

[[32m  OK  [0m] Reached target Slices.

[    2.731319] systemd[1]: Starting Apply Kernel Variables...

         Starting Apply Kernel Variables...

[    2.738718] systemd[1]: Starting Setup Virtual Console...

         Starting Setup Virtual Console...

[    2.744446] systemd[1]: Reached target Timers.

[[32m  OK  [0m] Reached target Timers.

[    2.749668] systemd[1]: Reached target Swap.

[    2.781213] usb 1-1: New USB device found, idVendor=0627, idProduct=0001

[    2.781217] usb 1-1: New USB device strings: Mfr=1, Product=3,
SerialNumber=5

[    2.781220] usb 1-1: Product: QEMU USB Tablet

[    2.781222] usb 1-1: Manufacturer: QEMU

[    2.781225] usb 1-1: SerialNumber: 42

[    2.789965] input: QEMU QEMU USB Tablet as
/devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/input/input4

[    2.790189] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01
Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.2-1/input0

[[32m  OK  [0m] Reached target Swap.

[    2.887336] systemd[1]: Started Journal Service.

[[32m  OK  [0m] Started Journal Service.

[[32m  OK  [0m] Started Create list of required sta...ce nodes for the
current kernel.

[[32m  OK  [0m] Started Apply Kernel Variables.

[    2.903653] random: fast init done

         Starting Create Static Device Nodes in /dev...

[[32m  OK  [0m] Started Create Static Device Nodes in /dev.

[[32m  OK  [0m] Started dracut cmdline hook.

         Starting dracut pre-udev hook...

[[32m  OK  [0m] Started Setup Virtual Console.

[    2.962744] device-mapper: uevent: version 1.0.3

[    2.966701] device-mapper: ioctl: 4.37.1-ioctl (2018-04-03) initialised:
dm-devel at redhat.com <mailto:dm-devel at redhat.com> 

[[32m  OK  [0m] Started dracut pre-udev hook.

         Starting udev Kernel Device Manager...

[[32m  OK  [0m] Started udev Kernel Device Manager.

         Starting udev Coldplug all Devices...

[[32m  OK  [0m] Started udev Coldplug all Devices.

[[32m  OK  [0m] Reached target System Initialization.

        Starting Show Plymouth Boot Screen...

         Starting dracut initqueue hook...

[[32m  OK  [0m] Started Show Plymouth Boot Screen.

[[32m  OK  [0m] Reached target Paths.

[[32m  OK  [0m] Started Forward Password Requests to Plymouth Directory
Watch.

[[32m  OK  [0m] Reached target Basic System.

         Mounting Configuration File System...

[[32m  OK  [0m] Mounted Configuration File System.

[    3.278679] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10

[    3.284823] FDC 0 is a S82078B

[    3.346628] scsi host0: ata_piix

[    3.358340] scsi host1: ata_piix

[    3.363061] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0c0 irq 14

[    3.369572] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0c8 irq 15

[    3.413844] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10

%G[    3.489243] virtio_blk virtio1: [vda] 629145600 512-byte logical blocks
(322 GB/300 GiB)

[    3.489830]  vda: vda1 vda2 vda3

[    3.527229] ata1.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100

[    3.529577] ata1.00: configured for MWDMA2

[    3.542907] scsi 0:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM
2.5+ PQ: 0 ANSI: 5

[    3.622851] sr 0:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray

[    3.626938] cdrom: Uniform CD-ROM driver Revision: 3.20

[[32m  OK  [0m] Found device /dev/mapper/brilliant--centos--vg-root.

         Starting File System Check on
/dev/...er/brilliant--centos--vg-root...

[[32m  OK  [0m] Started File System Check on
/dev/mapper/brilliant--centos--vg-root.

[[32m  OK  [0m] Started dracut initqueue hook.

         Mounting /sysroot...

[[32m  OK  [0m] Reached target Remote File Systems (Pre).

[[32m  OK  [0m] Reached target Remote File Systems.

[    4.029336] SGI XFS with ACLs, security attributes, no debug enabled

[    4.035798] XFS (dm-0): Mounting V5 Filesystem

[    5.917747] blk_update_request: I/O error, dev vda, sector 13098937

[    5.922604] blk_update_request: I/O error, dev vda, sector 13099961

[    5.927008] blk_update_request: I/O error, dev vda, sector 13100985

[    5.931339] blk_update_request: I/O error, dev vda, sector 13102009

[    5.935231] XFS (dm-0): xfs_do_force_shutdown(0x1) called from line 1266
of file fs/xfs/xfs_buf.c.  Return address = 0xffffffffc02738cc

[    5.942478] XFS (dm-0): I/O Error Detected. Shutting down filesystem

[    5.946134] XFS (dm-0): Please umount the filesystem and rectify the
problem(s)

[    5.952283] XFS (dm-0): metadata I/O error: block 0x782fb9
("xlog_bwrite") error 5 numblks 8192

[    5.959663] XFS (dm-0): failed to locate log tail

[    5.963221] XFS (dm-0): log mount/recovery failed: error -5

[    5.967272] XFS (dm-0): log mount failed

[    5.979786] blk_update_request: I/O error, dev vda, sector 0

[    5.992687] blk_update_request: I/O error, dev vda, sector 0

[[1;31mFAILED[0m] Failed to mount /sysroot.

See 'systemctl status sysroot.mount' for details.

[[1;33mDEPEND[0m] Dependency failed for Initrd Root File System.

[[1;33mDEPEND[0m] Dependency failed for Reload Configuration from the Real
Root.

[[32m  OK  [0m] Stopped dracut pre-udev hook.

[[32m  OK  [0m] Stopped dracut cmdline hook.

[[32m  OK  [0m] Stopped target Basic System.

[[32m  OK  [0m] Stopped target System Initialization.

[[32m  OK  [0m] Started Emergency Shell.

[[32m  OK  [0m] Reached target Emergency Mode.

[[32m  OK  [0m] Stopped dracut initqueue hook.

[[32m  OK  [0m] Reached target Initrd File Systems.

 

Generating "/run/initramfs/rdsosreport.txt"

 

 

Entering emergency mode. Exit the shell to continue.

Type "journalctl" to view system logs.

You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
/boot

after mounting them and attach it to a bug report.

 

 

:/# [   12.851915] random: crng init done

 

````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````

````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````````````````````````
````````````````````````````````````````````````````````

 

 

Thanks & B'Rgds,

Rony

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/163017db/attachment-0001.html>

From kgiusti at gmail.com  Thu Apr 25 18:19:50 2019
From: kgiusti at gmail.com (Ken Giusti)
Date: Thu, 25 Apr 2019 14:19:50 -0400
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <607fdf0d-7820-291f-5a21-202f167da5bc@oracle.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
 <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>
 <CALJNG+gfL4rbGgmr-wt46pi1onbiQUz7xKardPEcqSH0dCWSLw@mail.gmail.com>
 <607fdf0d-7820-291f-5a21-202f167da5bc@oracle.com>
Message-ID: <CAJoCO=MrCZ5ZVRnApk4+vJ-Bb9yd13Hb7foaSnzDFSYwV9kVzw@mail.gmail.com>

On Thu, Apr 25, 2019 at 11:19 AM <iain.macdonnell at oracle.com> wrote:

>
>
> On 4/25/19 1:05 AM, Damien Ciabrini wrote:
> >
> >
> > On Tue, Apr 23, 2019 at 1:18 AM Alex Schultz <aschultz at redhat.com
> > <mailto:aschultz at redhat.com>> wrote:
> >
> >     On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec <openstack at nemebean.com
> >     <mailto:openstack at nemebean.com>> wrote:
> >      >
> >      >
> >      >
> >      > On 4/22/19 12:53 PM, Alex Schultz wrote:
> >      > > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec
> >     <openstack at nemebean.com <mailto:openstack at nemebean.com>> wrote:
> >      > >>
> >      > >>
> >      > >>
> >      > >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
> >      > >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700,
> >     iain.macdonnell at oracle.com <mailto:iain.macdonnell at oracle.com>
> wrote:
> >      > >>>>
> >      > >>>> Today I discovered that this problem appears to be caused by
> >     eventlet
> >      > >>>> monkey-patching. I've created a bug for it:
> >      > >>>>
> >      > >>>> https://bugs.launchpad.net/nova/+bug/1825584
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_nova_-2Bbug_1825584&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=fpephoqJ2hzc-jFPr6Rtupc2U02HBjBRd-_Lq66zQBk&s=Vb1Yw7ZkrglH0AMBZSHNfuilS5gBwh9yF2o2trkXYyM&e=
> >
> >      > >>>
> >      > >>> Hi,
> >      > >>>
> >      > >>> just for completeness we see this very same issue also with
> >      > >>> mistral (actually it was the first service where we noticed
> >     the missed
> >      > >>> heartbeats). iirc Alex Schultz mentioned seeing it in ironic
> >     as well,
> >      > >>> although I have not personally observed it there yet.
> >      > >>
> >      > >> Is Mistral also mixing eventlet monkeypatching and WSGI?
> >      > >>
> >      > >
> >      > > Looks like there is monkey patching, however we noticed it with
> the
> >      > > engine/executor. So it's likely not just wsgi.  I think I also
> >     saw it
> >      > > in the ironic-conductor, though I'd have to try it out again.
> I'll
> >      > > spin up an undercloud today and see if I can get a more
> >     complete list
> >      > > of affected services. It was pretty easy to reproduce.
> >      >
> >      > Okay, I asked because if there's no WSGI/Eventlet combination
> >     then this
> >      > may be different from the Nova issue that prompted this thread. It
> >      > sounds like that was being caused by a bad interaction between
> >     WSGI and
> >      > some Eventlet timers. If there's no WSGI involved then I wouldn't
> >     expect
> >      > that to happen.
> >      >
> >      > I guess we'll see what further investigation turns up, but based
> >     on the
> >      > preliminary information there may be two bugs here.
> >      >
> >
> >     So I wasn't able to reproduce the ironic issues yet. But it's the
> >     mistral executor and nova-api which exhibit the issue on the
> >     undercloud.
> >
> >     mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR
> >     oslo.messaging._drivers.impl_rabbit [-]
> >     [b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on
> >     undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno 104]
> >     Connection reset by peer. Trying again in 1 seconds.:
> >     ConnectionResetError: [Errno 104] Connection reset by peer
> >
> >
> >     nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR
> >     oslo.messaging._drivers.impl_rabbit
> >     [req-d7767aed-e32d-43db-96a8-c0509bfb1cfe
> >     9ac89090d2d24949b9a1e01b1afb14cc 7becac88cbae4b3b962ecccaf536effe -
> >     default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP server
> on
> >     undercloud-0.ctlplane.localdomain:5672 is unreachable: Server
> >     unexpectedly closed connection. Trying again in 1 seconds.: OSError:
> >     Server unexpectedly closed connection
> >
> >     The errors being thrown are different perhaps it is two different
> >     problems.
> >
> >
> > Correct, I think our original issue with erratic AMQP hearbeats and
> mod_wsgi
> > was due to a change in how we run healthcheck in Stein in
> TripleO-deployed
> > environments, so different to what Iain originally experienced it
> seems...
> >
> > For the record, up to Rocky, we used to run healthcheck scripts
> > every 30 seconds, which guarantees that eventlet will wake up and
> > send an AMQP heartbeat packet if a service had no AMQP traffic in the
> last
> > 15s. It also guarantees that any incoming AMQP heartbeat packet from
> > rabbitmq will be processed in at most 30s.
> >
> > In Stein, our healthchecks are now triggered via systemd timers, and the
> > current time setting is too high to guarantee that mod_wsgi will always
> > wake up on time to send/receive AMQP heartbeats to/from rabbitmq
> > when there's no traffic.
>
> If I'm reading this right, it sounds like the periodic healthcheck is
> working around the underlying issue of the heartbeats not happening by
> themselves (due to eventlet monkey-patching somehow interfering with
> threading). The whole point of the heartbeats is to continually maintain
> the connection while there's no real traffic.
>
>      ~iain
>
>
>
I would agree with Iain here - it sounds as if something in mod_wsgi (or
elsewhere)  is blocking in the os outside of the purview of eventlet.

FWIW here's the oslo.messaging thread responsible for sending heartbeats
from the RPC client:

https://opendev.org/openstack/oslo.messaging/src/branch/stable/stein/oslo_messaging/_drivers/impl_rabbit.py#L897

Can you verify that the event.wait() call at the bottom of the loop is not
waking up as per the passed in _heartbeat_wait_timeout?
thanks

-- 
Ken Giusti  (kgiusti at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/332a2f91/attachment.html>

From mriedemos at gmail.com  Thu Apr 25 20:23:49 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 25 Apr 2019 15:23:49 -0500
Subject: [nova] Stein regressions
In-Reply-To: <27a23eb0-b31b-0f25-db74-bdef81908939@gmail.com>
References: <27a23eb0-b31b-0f25-db74-bdef81908939@gmail.com>
Message-ID: <a7298b3d-d675-85c0-ebf3-30c04c4f1a09@gmail.com>

Here is an update on these.

On 4/16/2019 9:30 PM, Matt Riedemann wrote:
> 1. https://bugs.launchpad.net/nova/+bug/1822801
> 
> There is a patch being worked: https://review.openstack.org/#/c/649345/
> 

That's approved and needs to be backported to stable/stein. It's having 
a hard time merging because of [1].

> 
> 2. https://bugs.launchpad.net/nova/+bug/1824435
> 
> We have a re-create scenario for this in devstack (noted in the bug 
> report). I've been unable to recreate in a functional test, possibly 
> because of how sqlite deals with NULL values in unique constraints 
> differently from mysql. I would have thought this regression test [1] 
> would have hit it but it didn't.
> 
> There are some options for fixing this, some more hacky than others, e.g.:
> 
> https://review.openstack.org/#/c/653065/
> 
> Need some input from others on fixing that bug in maybe a less hacky way.

Still no solid fix for this yet and no one is actively working on it.

> 
> 3. https://bugs.launchpad.net/nova/+bug/1825034
> 

There is a functional recreate patch and fix patch proposed with +2s 
from gibi [2].

> 
> 4. https://bugs.launchpad.net/nova/+bug/1825020
> 

There is a series for this as well with +2s from Jay [3]. The bottom two 
are the recreate test patch and the fix, but rest in the series are just 
cleanups.

[1] http://status.openstack.org/elastic-recheck/#1825435
[2] 
https://review.opendev.org/#/q/topic:bug/1825034+(status:open+OR+status:merged)
[3] 
https://review.opendev.org/#/q/topic:bug/1825020+(status:open+OR+status:merged)

-- 

Thanks,

Matt


From openstack at nemebean.com  Thu Apr 25 21:22:36 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Thu, 25 Apr 2019 16:22:36 -0500
Subject: [oslo] PTG Schedule
Message-ID: <e9a2642d-b913-4da6-47e7-a35bf111d3c7@nemebean.com>

A quick reminder that Oslo will have a room Friday afternoon and 
Saturday morning. I'm expecting that we'll finish up our topics on 
Friday at this point, but we do have the option of Saturday if we need it.

I have a very tentative schedule proposed on 
https://etherpad.openstack.org/p/oslo-train-topics

I left several topics unscheduled for various reasons which are 
mentioned in the etherpad. We can fit them in whenever people are available.

Thanks.

-Ben


From zigo at debian.org  Thu Apr 25 21:58:42 2019
From: zigo at debian.org (Thomas Goirand)
Date: Thu, 25 Apr 2019 23:58:42 +0200
Subject: OpenStack instance fail to boot after unexpected compute node
 shutdown
In-Reply-To: <009001d4fb85$f7696a50$e63c3ef0$@brilliant.com.bd>
References: <009001d4fb85$f7696a50$e63c3ef0$@brilliant.com.bd>
Message-ID: <9fc19826-1b05-efd9-62fc-ca00a0cf9a5d@debian.org>

On 4/25/19 6:43 PM, Md. Farhad Hasan Khan wrote:
> Hi,
> 
> We are running Openstack Rocky version. Our instances are getting volume
> from CEPH (mimic version).
> 
> Suddenly one of our compute node got shutdown due to RAM issue. So all
> instances running on that compute node (linux/windows) got effected.
> After starting the compute node all services up & running. But instances
> on that compute node fail to boot. Instances are getting volume from
> CEPH storage& CEPH is in Healthy state. Please see below log.
> 
> Requesting if anyone can help me to solve.

Hi,

Make sure you have set in nova.conf:
resume_guests_state_on_host_boot=True

on each of your compute nodes.

Also, it's wise to have instance_usage_audit=True

I hope this helps,

Thomas Goirand (zigo)


From melwittt at gmail.com  Thu Apr 25 22:00:26 2019
From: melwittt at gmail.com (melanie witt)
Date: Thu, 25 Apr 2019 15:00:26 -0700
Subject: [nova][dev] broken periodic task to cleanup expired console token
 auths
Message-ID: <b1b949b9-ed37-c0f5-913e-72b3c08ac879@gmail.com>

Howdy all,

I'm looking for more opinions about how we should approach fixing the 
broken periodic task for cleaning up expired console token 
authorizations in the database:

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

It's broken because it filters the database token auth records for 
'host' when it goes to remove expired auths, but the 'host' used by the 
various types of consoles is not actually the hostname of the compute 
host, as the current [broken] code assumes. So the periodic task finds 
nothing for the compute manager's self.host and cleans up no token 
authorizations.

There's a proposed patch that begins fixing the bug:

https://review.opendev.org/637716

by iterating over a list of possible 'host' values based on the various 
console types. Each console type may use a different style of value for 
the 'host' which can also be driver dependent. That means we'd have to 
implement and expose 'get_<console>_host' methods for drivers that use a 
different host format for their console token auths.

When I reviewed this patch, I wondered whether we should go down that 
road to fix this problem, or if we should instead stop using the 
required 'host' filter via the 
console_auth_token_destroy_expired_by_host method in the database API 
and instead add a console_auth_token_destroy_expired_by_instance method 
and have the nova-compute periodic task call that method in batches, 
similar to how the _heal_instance_info_cache periodic task works today.

Can anyone else lend their thoughts on how we should move forward here?

Cheers,
-melanie


From mriedemos at gmail.com  Thu Apr 25 22:29:44 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 25 Apr 2019 17:29:44 -0500
Subject: [nova][qa] nova-multi-cell job
In-Reply-To: <5ca82d09-8438-1eac-16d8-b223242b22a2@gmail.com>
References: <5ca82d09-8438-1eac-16d8-b223242b22a2@gmail.com>
Message-ID: <b4a7de63-6361-9d49-0a92-f28c2b930ace@gmail.com>

On 4/25/2019 9:56 AM, Matt Riedemann wrote:
> We now have a working multi-cell CI job for nova proposed [1]. I've 
> tried to fully document it both in the job definition and the commit 
> message. I'd like this to be voting and gating as soon as possible given 
> we've supported multi-cells since Pike so this has been a long-needed 
> test environment for nova. However, if we want to be conservative we 
> could make this non-voting in the check queue for awhile and then during 
> or after the PTG make it voting and gating if people prefer.
> 
> Thoughts?
> 
> [1] https://review.opendev.org/#/c/655222/

The job has already uncovered at least one bug [1] so I've opted to take 
the conservative route and make it non-voting in the check queue for 
awhile to let us flush out any more intermittent bugs like this.

[1] https://bugs.launchpad.net/nova/+bug/1826472

-- 

Thanks,

Matt


From mriedemos at gmail.com  Thu Apr 25 22:50:09 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Thu, 25 Apr 2019 17:50:09 -0500
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
 <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
Message-ID: <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>

On 4/24/2019 8:21 AM, Mark Goddard wrote:
> I put together a patch for kolla-ansible with support for upgrade checks 
> for some projects: https://review.opendev.org/644528. It's on the 
> backburner at the moment but I plan to return to it during the Train 
> cycle. Perhaps you could clarify a few things about expected usage.

Cool. I'd probably try to pick one service (nova?) to start with before 
trying to bite off all of these in a single change (that review is kind 
of daunting).

Also, as part of the community wide goal I wrote up reference docs in 
the nova tree [1] which might answer your questions with links for more 
details.

> 
> 1. Should the tool be run using the new code? I would assume so.

Depends on what you mean by "new code". When nova introduced this in 
Ocata it was meant to be run in a venv or container after upgrading the 
newton schema and data migrations to ocata, but before restarting the 
services with the ocata code and that's how grenade uses it. But the 
checks should also be idempotent and can be run as a 
post-install/upgrade verify step, which is how OSA uses it (and is 
described in the nova install docs [2]).

> 2. How would you expect this to be run with multiple projects? I was 
> thinking of adding a new command that performs upgrade checks for all 
> projects that would be read-only, then also performing the check again 
> as part of the upgrade procedure.

Hmm, good question. This probably depends on each deployment tool and 
how they roll through services to do the upgrade. Obviously you'd want 
to run each project's checks as part of upgrading that service, but I 
guess you're looking for some kind of "should we even start this whole 
damn upgrade if we can detect early that there are going to be issues?". 
If the early run is read-only though - and I'm assuming by read-only you 
mean they won't cause a failure - how are you going to expose that there 
is a problem without failing? Would you make that configurable? 
Otherwise the checks themselves are supposed to be read-only and not 
change your data (they aren't the same thing as an online data migration 
routine for example).

> 3. For the warnings, would you recommend a -Werror style argument that 
> optionally flags up warnings as errors? Reporting non-fatal errors is 
> quite difficult in Ansible.

OSA fails on any return codes that aren't 0 (success) or 1 (warning). 
It's hard to say when warning should be considered an error really. When 
writing these checks I think of warning as a case where you might be OK 
but we don't really know for sure, so it can aid in debugging 
upgrade-related issues after the fact but might not necessarily mean you 
shouldn't upgrade. mnaser has brought up the idea in the past of making 
the output more machine readable so tooling could pick and choose which 
things it considers to be a failure (assuming the return code was 1). 
That's an interesting idea but one I haven't put a lot of thought into. 
It might be as simple as outputting a unique code per check per project, 
sort of like the error code concept in the API guidelines [3] which the 
placement project is using [4].

[1] https://docs.openstack.org/nova/latest/reference/upgrade-checks.html
[2] https://docs.openstack.org/nova/latest/install/verify.html
[3] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html
[4] 
https://opendev.org/openstack/placement/src/branch/master/placement/errors.py

-- 

Thanks,

Matt


From sundar.nadathur at intel.com  Thu Apr 25 23:57:08 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Thu, 25 Apr 2019 23:57:08 +0000
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
Message-ID: <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>

From: Alex Xu <soulxu at gmail.com>
Sent: Monday, April 15, 2019 4:50 PM
> The cyborg only needs to return un-numbered request group, then Nova will
> base on all the 'hw:xxx' extra specs and 'accel:device_profile.[numa node
> id]' to generate a placement request like above.

I am not quite following the idea(s) proposed here. Cyborg returns only the device-related request groups. The un-numbered request group in the flavor is not touched by Cyborg.

Secondly, if you use the ‘accel:’ stuff in the flavor to decide NUMA affinity, how will you pass that to Placement? This thread is about the syntax of the GET /a-c call.

> For example, if it is PCI device under first numa node, the extra spec will
> be 'accel:device_profile.0=<profile_name>' the cyborg can return a simple
> request 'resources=CYBORG_PCI_XX_DEVICE:1', then we merge this into the
> request group 'resources1=VCPU:2,MEMORY_MB:128,CYBORG_PCI_XX_DEVICE:1'. If
> the pci device has a special trait, then cyborg should return request group
> as 'resources1=CYBORG_PCI_XX_DEVICE:1&required=SOME_TRAIT', then nova merge
> this into placement request as 'resources1.1'.

Sorry, I don’t follow this either. The request groups have entries like ‘resources:CUSTOM_FOO=1’, not 'resources=CYBORG_PCI_XX_DEVICE:1'. So, I don’t see where to stick the NUMA node #.

Anyways, for Cyborg, it seems to me that there is a fairly straightforward scheme to address NUMA affinity: annotate the device’s nested RP with a trait indicating which NUMA node it belongs to (e.g. CUSTOM_NUMA_NODE_0), and use that to guide scheduling. This should be a valid use of traits because it expresses a property of the resource provider and is used for scheduling (only).

As for how the annotation is done, it could be automated. The operator’s tool that configures a device to affinitize with a NUMA node (by setting MSI-X vectors, etc.) also invokes a Cyborg API (yet to be written) with the NUMA node # -- that would identify the device RP and update Placement with that trait. The tool needs to ensure that the device has been discovered by Cyborg and updated in Placement before invoking the API.

Regards,
Sundar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/65a3ff07/attachment-0001.html>

From dangtrinhnt at gmail.com  Fri Apr 26 02:01:25 2019
From: dangtrinhnt at gmail.com (Trinh Nguyen)
Date: Fri, 26 Apr 2019 11:01:25 +0900
Subject: [Ceilometer]: cpu_util meter not being calculated as expected
 leading to delay in scaling
In-Reply-To: <BMXPR01MB08074E60CECBEFE65592E35A8A3C0@BMXPR01MB0807.INDPRD01.PROD.OUTLOOK.COM>
References: <BMXPR01MB08074E60CECBEFE65592E35A8A3C0@BMXPR01MB0807.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <CADJ6S4EJSski4maRknQcNiCkU-ts1gqwi2cSMn5-106XyAwMYg@mail.gmail.com>

Hi Arvind,

Could you please tell us which release of Ceilometer that you are referring
to?

Bests,

On Wed, Apr 24, 2019 at 4:55 PM Arvind Kumar <Arvind.Kumar at ril.com> wrote:

> Hi,
>
> A design issue is observed in ceilometer service of Openstack. Setup
> include multiple compute nodes and 3 controller nodes. Meters from each
> compute node are sent to all the 3 ceilometer instances via RabbitMQ in
> round robin fashion at an interval of 10 min. After transformation of
> cumulative cpu  meter data, cpu_util is generated by ceilometer instance at
> controller node and is published to the http address configured in
> ceilometer pipeline configuration. cpu_util is used by the application to
> take the decision if scaling of VM needs to be triggered or not.
>
> Ceilometer instance calculates cpu_util for a VM from the difference
> between cumulative cpu usage of VM at two timestamp divided by the
> timestamp difference. Let’s say 1 compute node send the cumulative cpu
> usage of a VM (C1, C2, C3, C4) at timestamp T1, T2, T3, T4 (difference
> between any two timestamp is 10 min). Now (C1,T1) & (C4,T4) tuple is
> received by ceilometer instance 1, (C2,T2) by instance 2, (C3,T3) by
> instance 3. Here even if CPU usage of VM is increased between T1 & T2,
> cpu_util is calculated for 30 min duration (T1 & T4) rather than as
> expected for 10 min. This leads to scaling getting triggered after T4 that
> too when CPU usage is consistently above the threshold between T1 and T4.
>
> Please suggest how could this issue could be resolved. Do we have any
> solution to bind VM or compute node meter data to specific ceilometer
> instance for processing?
>
> Regards,
>
> Arvind.
>
>
> "*Confidentiality Warning*: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, re-transmission, conversion to hard copy, copying,
> circulation or other use of this message and any attachments is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return email and delete this message and any attachments
> from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions to
> ensure no viruses are present in this email. The company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachment."
>


-- 
*Trinh Nguyen*
*www.edlab.xyz <https://www.edlab.xyz>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/217a2456/attachment.html>

From miguel at mlavalle.com  Fri Apr 26 04:03:01 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Thu, 25 Apr 2019 23:03:01 -0500
Subject: [neutron] Cancelling drivers meeting
Message-ID: <CAEzGLDjr0iu7baO+yfN7i5F=+DvRxdYHwaG9a4YUpZxQ23bJ_A@mail.gmail.com>

Dear Neutron drivers,

We have 4 RFEs in the pipeline, previous to their discussion in the drivers
meeting:

1) On three of them, I have left clarifying questions:
https://bugs.launchpad.net/neutron/+bug/1825345,
https://bugs.launchpad.net/neutron/+bug/1825336 and
https://bugs.launchpad.net/neutron/+bug/1825943. I encourage you to examine
them over the next few days and help clarify the proposals.

2) The fourth one, https://bugs.launchpad.net/neutron/+bug/1826396, comes
from Bence Romsics (rubasov). I had an email / irc exchange with him and
since he will be attending the PTG, we have agreed to discuss it in Denver

Given the above, we are cancelling the April 26th drivers meeting. For
those of you going to Denver, safe travels

Best Regards

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190425/ea6356b3/attachment.html>

From rony.khan at brilliant.com.bd  Fri Apr 26 04:28:59 2019
From: rony.khan at brilliant.com.bd (Md. Farhad Hasan Khan)
Date: Fri, 26 Apr 2019 10:28:59 +0600
Subject: OpenStack instance fail to boot after unexpected compute node
 shutdown
In-Reply-To: <9fc19826-1b05-efd9-62fc-ca00a0cf9a5d@debian.org>
References: <009001d4fb85$f7696a50$e63c3ef0$@brilliant.com.bd>
 <9fc19826-1b05-efd9-62fc-ca00a0cf9a5d@debian.org>
Message-ID: <01ec01d4fbe8$922aa600$b67ff200$@brilliant.com.bd>



-----Original Message-----
From: Thomas Goirand [mailto:zigo at debian.org] 
Sent: Friday, April 26, 2019 3:59 AM
To: rony.khan at brilliant.com.bd; openstack-discuss at lists.openstack.org
Subject: Re: OpenStack instance fail to boot after unexpected compute node
shutdown

On 4/25/19 6:43 PM, Md. Farhad Hasan Khan wrote:
> Hi,
> 
> We are running Openstack Rocky version. Our instances are getting 
> volume from CEPH (mimic version).
> 
> Suddenly one of our compute node got shutdown due to RAM issue. So all 
> instances running on that compute node (linux/windows) got effected.
> After starting the compute node all services up & running. But 
> instances on that compute node fail to boot. Instances are getting 
> volume from CEPH storage& CEPH is in Healthy state. Please see below log.
> 
> Requesting if anyone can help me to solve.

Hi,

Make sure you have set in nova.conf:
resume_guests_state_on_host_boot=True

on each of your compute nodes.

Also, it's wise to have instance_usage_audit=True

I hope this helps,

Thomas Goirand (zigo)



Hi,
Thanks a lot for your quick response. 

////////////////////// Make sure you have set in nova.conf:
resume_guests_state_on_host_boot=True

##### this settings we are not using. We shall check.


////////////////////// Also, it's wise to have instance_usage_audit=True

##### already configured.


Please help if there is any way to repair effected instances volume.


Thanks & B'Rgds,
Rony



From iain.macdonnell at oracle.com  Fri Apr 26 04:45:45 2019
From: iain.macdonnell at oracle.com (iain.macdonnell at oracle.com)
Date: Thu, 25 Apr 2019 21:45:45 -0700
Subject: [oslo][oslo-messaging][nova] Stein nova-api AMQP issue running
 under uWSGI
In-Reply-To: <CAJoCO=MrCZ5ZVRnApk4+vJ-Bb9yd13Hb7foaSnzDFSYwV9kVzw@mail.gmail.com>
References: <229a2a53-870f-44c3-5e0c-6cfa9d45d0c5@oracle.com>
 <CALJNG+gt9cT0BmjyRZ9pPtypfaD6Tc_L2kHO6BKLBDQOG61Wrg@mail.gmail.com>
 <3275304e-d717-8b89-557e-b650fc4f661a@oracle.com>
 <fdf38694-2fb0-255f-5d33-d66d217087f5@oracle.com>
 <20190420063850.GA18527@holtby.speedport.ip>
 <8b9cb0e4-b3a4-986a-be59-5bba6ae00f4e@nemebean.com>
 <CAFsb3b4bMos6-_4GTcFw96Ob80E4=R0me-kSAXGV1iNGhnuQCw@mail.gmail.com>
 <c0ab7ea6-4952-f2c2-aab6-f4466d6bd954@nemebean.com>
 <CAFsb3b75qM7DWPgm5_oSgJpTh586bGLRa6Zj_PKAAuqxTeQPdw@mail.gmail.com>
 <CALJNG+gfL4rbGgmr-wt46pi1onbiQUz7xKardPEcqSH0dCWSLw@mail.gmail.com>
 <607fdf0d-7820-291f-5a21-202f167da5bc@oracle.com>
 <CAJoCO=MrCZ5ZVRnApk4+vJ-Bb9yd13Hb7foaSnzDFSYwV9kVzw@mail.gmail.com>
Message-ID: <7632ddfa-1224-977b-d200-dd8ef30e2c90@oracle.com>



On 4/25/19 11:19 AM, Ken Giusti wrote:
> 
> 
> On Thu, Apr 25, 2019 at 11:19 AM <iain.macdonnell at oracle.com 
> <mailto:iain.macdonnell at oracle.com>> wrote:
> 
> 
> 
>     On 4/25/19 1:05 AM, Damien Ciabrini wrote:
>      >
>      >
>      > On Tue, Apr 23, 2019 at 1:18 AM Alex Schultz <aschultz at redhat.com
>     <mailto:aschultz at redhat.com>
>      > <mailto:aschultz at redhat.com <mailto:aschultz at redhat.com>>> wrote:
>      >
>      >     On Mon, Apr 22, 2019 at 12:25 PM Ben Nemec
>     <openstack at nemebean.com <mailto:openstack at nemebean.com>
>      >     <mailto:openstack at nemebean.com
>     <mailto:openstack at nemebean.com>>> wrote:
>      >      >
>      >      >
>      >      >
>      >      > On 4/22/19 12:53 PM, Alex Schultz wrote:
>      >      > > On Mon, Apr 22, 2019 at 11:28 AM Ben Nemec
>      >     <openstack at nemebean.com <mailto:openstack at nemebean.com>
>     <mailto:openstack at nemebean.com <mailto:openstack at nemebean.com>>> wrote:
>      >      > >>
>      >      > >>
>      >      > >>
>      >      > >> On 4/20/19 1:38 AM, Michele Baldessari wrote:
>      >      > >>> On Fri, Apr 19, 2019 at 03:20:44PM -0700,
>      > iain.macdonnell at oracle.com <mailto:iain.macdonnell at oracle.com>
>     <mailto:iain.macdonnell at oracle.com
>     <mailto:iain.macdonnell at oracle.com>> wrote:
>      >      > >>>>
>      >      > >>>> Today I discovered that this problem appears to be
>     caused by
>      >     eventlet
>      >      > >>>> monkey-patching. I've created a bug for it:
>      >      > >>>>
>      >      > >>>> https://bugs.launchpad.net/nova/+bug/1825584
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_nova_-2Bbug_1825584&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=yuWVlqvT-TMIF0OQxtByfrZjswKo56fkyrbKrvy9oHs&s=mJYdHr4mPQVjex9HrhekR_IvRsktOkvDNGQBnuB_ehI&e=>
>      >   
>       <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_nova_-2Bbug_1825584&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=fpephoqJ2hzc-jFPr6Rtupc2U02HBjBRd-_Lq66zQBk&s=Vb1Yw7ZkrglH0AMBZSHNfuilS5gBwh9yF2o2trkXYyM&e=>
>      >      > >>>
>      >      > >>> Hi,
>      >      > >>>
>      >      > >>> just for completeness we see this very same issue also
>     with
>      >      > >>> mistral (actually it was the first service where we
>     noticed
>      >     the missed
>      >      > >>> heartbeats). iirc Alex Schultz mentioned seeing it in
>     ironic
>      >     as well,
>      >      > >>> although I have not personally observed it there yet.
>      >      > >>
>      >      > >> Is Mistral also mixing eventlet monkeypatching and WSGI?
>      >      > >>
>      >      > >
>      >      > > Looks like there is monkey patching, however we noticed
>     it with the
>      >      > > engine/executor. So it's likely not just wsgi.  I think
>     I also
>      >     saw it
>      >      > > in the ironic-conductor, though I'd have to try it out
>     again.  I'll
>      >      > > spin up an undercloud today and see if I can get a more
>      >     complete list
>      >      > > of affected services. It was pretty easy to reproduce.
>      >      >
>      >      > Okay, I asked because if there's no WSGI/Eventlet combination
>      >     then this
>      >      > may be different from the Nova issue that prompted this
>     thread. It
>      >      > sounds like that was being caused by a bad interaction between
>      >     WSGI and
>      >      > some Eventlet timers. If there's no WSGI involved then I
>     wouldn't
>      >     expect
>      >      > that to happen.
>      >      >
>      >      > I guess we'll see what further investigation turns up, but
>     based
>      >     on the
>      >      > preliminary information there may be two bugs here.
>      >      >
>      >
>      >     So I wasn't able to reproduce the ironic issues yet. But it's the
>      >     mistral executor and nova-api which exhibit the issue on the
>      >     undercloud.
>      >
>      >     mistral/executor.log:2019-04-22 22:40:58.321 7 ERROR
>      >     oslo.messaging._drivers.impl_rabbit [-]
>      >     [b7b4bc40-767c-4de1-b77b-6a5822f6beed] AMQP server on
>      >     undercloud-0.ctlplane.localdomain:5672 is unreachable: [Errno
>     104]
>      >     Connection reset by peer. Trying again in 1 seconds.:
>      >     ConnectionResetError: [Errno 104] Connection reset by peer
>      >
>      >
>      >     nova/nova-api.log:2019-04-22 22:38:11.530 19 ERROR
>      >     oslo.messaging._drivers.impl_rabbit
>      >     [req-d7767aed-e32d-43db-96a8-c0509bfb1cfe
>      >     9ac89090d2d24949b9a1e01b1afb14cc
>     7becac88cbae4b3b962ecccaf536effe -
>      >     default default] [c0f3fe7f-db89-42c6-95bd-f367a4fbf680] AMQP
>     server on
>      >     undercloud-0.ctlplane.localdomain:5672 is unreachable: Server
>      >     unexpectedly closed connection. Trying again in 1 seconds.:
>     OSError:
>      >     Server unexpectedly closed connection
>      >
>      >     The errors being thrown are different perhaps it is two different
>      >     problems.
>      >
>      >
>      > Correct, I think our original issue with erratic AMQP hearbeats
>     and mod_wsgi
>      > was due to a change in how we run healthcheck in Stein in
>     TripleO-deployed
>      > environments, so different to what Iain originally experienced it
>     seems...
>      >
>      > For the record, up to Rocky, we used to run healthcheck scripts
>      > every 30 seconds, which guarantees that eventlet will wake up and
>      > send an AMQP heartbeat packet if a service had no AMQP traffic in
>     the last
>      > 15s. It also guarantees that any incoming AMQP heartbeat packet from
>      > rabbitmq will be processed in at most 30s.
>      >
>      > In Stein, our healthchecks are now triggered via systemd timers,
>     and the
>      > current time setting is too high to guarantee that mod_wsgi will
>     always
>      > wake up on time to send/receive AMQP heartbeats to/from rabbitmq
>      > when there's no traffic.
> 
>     If I'm reading this right, it sounds like the periodic healthcheck is
>     working around the underlying issue of the heartbeats not happening by
>     themselves (due to eventlet monkey-patching somehow interfering with
>     threading). The whole point of the heartbeats is to continually
>     maintain
>     the connection while there's no real traffic.
> 
>           ~iain
> 
> 
> 
> I would agree with Iain here - it sounds as if something in mod_wsgi (or 
> elsewhere)  is blocking in the os outside of the purview of eventlet.
> 
> FWIW here's the oslo.messaging thread responsible for sending heartbeats 
> from the RPC client:
> 
> https://opendev.org/openstack/oslo.messaging/src/branch/stable/stein/oslo_messaging/_drivers/impl_rabbit.py#L897 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_openstack_oslo.messaging_src_branch_stable_stein_oslo-5Fmessaging_-5Fdrivers_impl-5Frabbit.py-23L897&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=yuWVlqvT-TMIF0OQxtByfrZjswKo56fkyrbKrvy9oHs&s=dIFtanzYyLQXGnr8R9RMZLiIq-HaEn0BokQxsytq7ok&e=>
> 
> Can you verify that the event.wait() call at the bottom of the loop is 
> not waking up as per the passed in _heartbeat_wait_timeout?
> thanks

I added extra debug logging before and after the call to wait(). The 
"before" line gets logged, but the "after" one does not (when 
monkey-patching is in place).

Here's what it looks like with monkey-patching disabled:

http://paste.openstack.org/show/kUMhrSN8aiyleDgQ99EC/

and with it enabled:

http://paste.openstack.org/show/DlwG9iBjLvR7lX6NHlie/

In both cases, I had started the WSGI app, made an API call that 
required use of RPC, then waited for several minutes.

     ~iain




From sundar.nadathur at intel.com  Fri Apr 26 05:28:48 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Fri, 26 Apr 2019 05:28:48 +0000
Subject: [cyborg] No IRC or engineering meeting next week [EOM]
Message-ID: <1CC272501B5BC543A05DB90AA509DED527552C08@fmsmsx122.amr.corp.intel.com>



Regards,
Sundar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/55aaef70/attachment.html>

From jean-philippe at evrard.me  Fri Apr 26 07:00:16 2019
From: jean-philippe at evrard.me (Jean-Philippe Evrard)
Date: Fri, 26 Apr 2019 03:00:16 -0400
Subject: =?UTF-8?Q?Re:_[tc][all]_Github_mirroring_(or_lack_thereof)_for_unofficia?=
 =?UTF-8?Q?l_projects?=
In-Reply-To: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
References: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
Message-ID: <67b812b9-4cec-45e4-8fa5-6767dfa19282@www.fastmail.com>



On Thu, Apr 25, 2019, at 17:03, Jim Rollenhagen wrote:
> Hi,
> 
> Now that the great OpenDev migration is done, we have a number of projects on Github which are no longer mirroring and becoming stale. This includes:
> 
> - most repositories at https://github.com/openstack-infra
> - any repository in https://github.com/openstack which is no longer in https://opendev.org/openstack
> - I think that's it, but there could be others.
> 
> The OpenDev and OpenStack teams have no plans to continue mirroring these projects to Github; primarily because we don't have a corresponding Github organization to put them in. However, teams can easily set up a mirror to any location they like on Github: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
> 
> The remaining question is what to do with the stale repos in the OpenStack organization on Github. Right now, we plan to just archive them. This means that the repository will be read-only, with a banner at the top saying it's archived. If a project owner wants to transfer the project to another Github organization, we can unarchive the project to do so, and they can maintain the mirroring via Zuul.
> 
> If there's no wild objections to this plan, we'll go ahead with it soon. Maybe the week after the Summit, unless someone in the OpenDev team has spare cycles before that.
> 
> // jim

+1


From skaplons at redhat.com  Fri Apr 26 07:19:52 2019
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 26 Apr 2019 09:19:52 +0200
Subject: [neutron] Cancelling drivers meeting
In-Reply-To: <CAEzGLDjr0iu7baO+yfN7i5F=+DvRxdYHwaG9a4YUpZxQ23bJ_A@mail.gmail.com>
References: <CAEzGLDjr0iu7baO+yfN7i5F=+DvRxdYHwaG9a4YUpZxQ23bJ_A@mail.gmail.com>
Message-ID: <20190426071952.5gclfi4g3w3x7doc@skaplons-mac>

Hi,

Thx for info Miguel and see You all in Denver :)

On Thu, Apr 25, 2019 at 11:03:01PM -0500, Miguel Lavalle wrote:
> Dear Neutron drivers,
> 
> We have 4 RFEs in the pipeline, previous to their discussion in the drivers
> meeting:
> 
> 1) On three of them, I have left clarifying questions:
> https://bugs.launchpad.net/neutron/+bug/1825345,
> https://bugs.launchpad.net/neutron/+bug/1825336 and
> https://bugs.launchpad.net/neutron/+bug/1825943. I encourage you to examine
> them over the next few days and help clarify the proposals.
> 
> 2) The fourth one, https://bugs.launchpad.net/neutron/+bug/1826396, comes
> from Bence Romsics (rubasov). I had an email / irc exchange with him and
> since he will be attending the PTG, we have agreed to discuss it in Denver
> 
> Given the above, we are cancelling the April 26th drivers meeting. For
> those of you going to Denver, safe travels
> 
> Best Regards
> 
> Miguel

-- 
Slawek Kaplonski
Senior software engineer
Red Hat


From flux.adam at gmail.com  Fri Apr 26 07:31:45 2019
From: flux.adam at gmail.com (Adam Harwell)
Date: Fri, 26 Apr 2019 00:31:45 -0700
Subject: [octavia] Octavia 4.x for Rocky?
In-Reply-To: <70db5480-d095-96ca-fd85-c671814ae0eb@ytechteam.com>
References: <70db5480-d095-96ca-fd85-c671814ae0eb@ytechteam.com>
Message-ID: <CAHxXnhet2sJbcuHbcK0C8Vx=6S=JdtFU2Mta_7cAzrz9bA92cw@mail.gmail.com>

Octavia has never required any specific features that are newer than
approximately the Liberty release of Openstack. I can say that I have
successfully run Octavia from Rocky on an otherwise fully Liberty cloud.
So, it should work fine. I'm fact, I generally recommend running the newest
possible version of Octavia, regardless of the versions of the rest of your
services. :)

Note: Liberty is just my best guess based on experience, it's possible that
it would work on Juno or Kilo but this has not been tested (to my
knowledge).

    --Adam


On Wed, Apr 24, 2019, 07:22 Volodymyr Litovka <doka at ytechteam.com> wrote:

> Dear colleagues,
>
> whether Octavia 4.x can be used with Rocky? Whether it makes sense (I
> mean, whether Octavia's new features are tied to Stein's features)?
>
> Thank you.
>
> --
> Volodymyr Litovka
>    "Vision without Execution is Hallucination." -- Thomas Edison
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/acccd404/attachment.html>

From florian.engelmann at everyware.ch  Fri Apr 26 08:57:27 2019
From: florian.engelmann at everyware.ch (Florian Engelmann)
Date: Fri, 26 Apr 2019 10:57:27 +0200
Subject: kube_cluster_deploy fails
In-Reply-To: <5080c19a-3c98-8c13-eec1-49706d3e591c@everyware.ch>
References: <0f00a092-1f7d-e85b-9ce4-da38cfd2c9da@everyware.ch>
 <fa4c513a-a773-2ec8-2643-ea4534a449f2@everyware.ch>
 <c23b496c-bfe0-d850-bf9f-0bd58abdc8f5@catalyst.net.nz>
 <5080c19a-3c98-8c13-eec1-49706d3e591c@everyware.ch>
Message-ID: <497c1efd-a2af-6958-7e11-ae8e38eb4df9@everyware.ch>

This was fixed by adding:

[DEFAULT]
...
region_name_for_services = <region name>
...

to the heat configuration.



Am 4/24/19 um 11:17 AM schrieb Florian Engelmann:
> Hi Feilong,
> 
> I will answer in behalf of Pawel.
> 
> [root at kubernetes-cluster2-sdpti5674ukb-master-0 ~]# tail -n 25 
> /var/log/cloud-init-output.log
> Copying blob 
> sha256:fb6ed010e89e8064d698019532ef87719e61ed83f10801b0ed0dee56cf46a988
>   240 B / 240 B  0s
> Copying config 
> sha256:c1f47e73da637994ed9348a99dd25c5f66980ff887c9b2657ef48c8e481528a3
>   5.83 KB / 5.83 KB  0s
> Writing manifest to image destination
> Storing signatures
> Extracting to /var/lib/containers/atomic/heat-container-agent.0
> systemctl daemon-reload
> systemd-tmpfiles --create /etc/tmpfiles.d/heat-container-agent.conf
> systemctl enable heat-container-agent
> + systemctl start heat-container-agent
> starting services
> activating service etcd
> activating service docker
> activating service kube-apiserver
> activating service kube-controller-manager
> activating service kube-scheduler
> activating service kubelet
> activating service kube-proxy
> creating /usr/local/bin/flannel-config
> Created symlink 
> /etc/systemd/system/multi-user.target.wants/flannel-config.service → 
> /etc/systemd/system/flannel-config.service.
> activating service flanneld
> activating service flanneld
> Cloud-init v. 0.7.9 running 'modules:final' at Wed, 24 Apr 2019 08:20:43 
> +0000. Up 18.36 seconds.
> Cloud-init v. 0.7.9 finished at Wed, 24 Apr 2019 08:24:38 +0000. 
> Datasource DataSourceOpenStack [net,ver=2].  Up 253.24 seconds
> 
> What is the heat task
> 
>    kube_cluster_deploy:
>      type: OS::Heat::SoftwareDeployment
>      properties:
>        actions: ['CREATE']
>        signal_transport: HEAT_SIGNAL
>        config:
>          get_resource: kube_cluster_config
>        server:
>          get_attr: [kube_masters, resource.0]
> 
> 
> ment to do?
> 
> Is it starting the scripts listed under kube_cluster_config?
> 
>    kube_cluster_config:
>      type: OS::Heat::SoftwareConfig
>      properties:
>        group: script
>        config:
>          list_join:
>            - "\n"
>            -
>              - get_file: 
> ../../common/templates/kubernetes/fragments/kube-apiserver-to-kubelet-role.sh 
> 
>              - str_replace:
>                  template: {get_file: 
> ../../common/templates/kubernetes/fragments/enable-cert-api-manager.sh}
>                  params:
>                    "$CA_KEY": {get_param: ca_key}
>              - get_file: 
> ../../common/templates/kubernetes/fragments/core-dns-service.sh
>              - str_replace:
>                  template: {get_file: 
> ../../common/templates/kubernetes/fragments/enable-prometheus-monitoring.sh} 
> 
>                  params:
>                    "$ADMIN_PASSWD": {get_param: grafana_admin_passwd}
>              - get_file: 
> ../../common/templates/kubernetes/fragments/calico-service.sh
>              - str_replace:
>                  params:
>                    $enable-ingress-traefik: {get_file: 
> ../../common/templates/kubernetes/fragments/enable-ingress-traefik.sh}
>                  template: {get_file: 
> ../../common/templates/kubernetes/fragments/enable-ingress-controller.sh}
>              - get_file: 
> ../../common/templates/kubernetes/fragments/kube-dashboard-service.sh
> 
> All the best,
> Florian
> 
> Am 4/16/19 um 12:09 AM schrieb Feilong Wang:
>> Hi Pawel,
>>
>> Firstly, please remove the tls-disabled param which it's a known issue.
>> And m1.small is a bit small for master which 30mins timout maybe not
>> enough. Please address them and try again, then if you still see error,
>> pls provied the log /var/log/cloud-init-output.log on your master node.
>> Cheers.
>>
>>
>> On 16/04/19 2:02 AM, Pawel Konczalski wrote:
>>> Hi,
>>>
>>> i try to deploy a kubernetes cluster on OpenStack rocky with Magnum.
>>> All Heat steps runs fine except for the last one "kube_cluster_deploy":
>>>
>>> kube_cluster_deploy    c3a79e96-87d8-442e-83f1-91d7a1acd896    1
>>> minute    Create Failed    CREATE aborted (Task create from
>>> SoftwareDeployment "kube_cluster_deploy" Stack
>>> "kubernetes-cluster9-l4ol4ger3key"
>>> [b17bfab3-f46a-477b-921f-4719bfd8df06] Timed out)
>>>
>>> The cluster contains three control / compute nodes, Octavia is also
>>> installed and works fine as far as I can see.
>>>
>>> Atomic Image:
>>> https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-20180419.0/CloudImages/x86_64/images/Fedora-Atomic-27-20180419.0.x86_64.raw.xz 
>>>
>>>
>>>
>>> The command was:
>>> openstack coe cluster template create kubernetes-cluster-template \
>>>    --image fedora-atomic-latest \
>>>    --external-network public \
>>>    --dns-nameserver 8.8.8.8 \
>>>    --master-flavor m1.small \
>>>    --flavor m1.large \
>>>    --coe kubernetes \
>>>    --docker-volume-size 10 \
>>>    --tls-disabled \
>>>    --floating-ip-enabled
>>>
>>> openstack coe cluster create kubernetes-cluster \
>>>    --cluster-template kubernetes-cluster-template \
>>>    --master-count 1 \
>>>    --node-count 1 \
>>>    --timeout 30 \
>>>    --keypair mykey
>>>
>>> Did someone run also into this Problem or know how to fix it?
>>>
>>> BR
>>>
>>> Pawel
>>

-- 

EveryWare AG
Florian Engelmann
Senior UNIX Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: mailto:florian.engelmann at everyware.ch
web: http://www.everyware.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/488b75da/attachment-0001.bin>

From mark at stackhpc.com  Fri Apr 26 08:59:30 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Fri, 26 Apr 2019 09:59:30 +0100
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
 <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
 <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>
Message-ID: <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>

On Thu, 25 Apr 2019 at 23:50, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 4/24/2019 8:21 AM, Mark Goddard wrote:
> > I put together a patch for kolla-ansible with support for upgrade checks
> > for some projects: https://review.opendev.org/644528. It's on the
> > backburner at the moment but I plan to return to it during the Train
> > cycle. Perhaps you could clarify a few things about expected usage.
>
> Cool. I'd probably try to pick one service (nova?) to start with before
> trying to bite off all of these in a single change (that review is kind
> of daunting).
>
> Also, as part of the community wide goal I wrote up reference docs in
> the nova tree [1] which might answer your questions with links for more
> details.
>
> >
> > 1. Should the tool be run using the new code? I would assume so.
>
> Depends on what you mean by "new code". When nova introduced this in
> Ocata it was meant to be run in a venv or container after upgrading the
> newton schema and data migrations to ocata, but before restarting the
> services with the ocata code and that's how grenade uses it. But the
> checks should also be idempotent and can be run as a
> post-install/upgrade verify step, which is how OSA uses it (and is
> described in the nova install docs [2]).
>
>
In kolla land, I mean should I use the container image for the current
release or the target release to execute the nova-status command. It sounds
like it's the latter, which also implies we're using the target version of
kolla/kolla-ansible. I hadn't twigged that we'd need to perform the schema
upgrade and online migrations.


> > 2. How would you expect this to be run with multiple projects? I was
> > thinking of adding a new command that performs upgrade checks for all
> > projects that would be read-only, then also performing the check again
> > as part of the upgrade procedure.
>
> Hmm, good question. This probably depends on each deployment tool and
> how they roll through services to do the upgrade. Obviously you'd want
> to run each project's checks as part of upgrading that service, but I
> guess you're looking for some kind of "should we even start this whole
> damn upgrade if we can detect early that there are going to be issues?".
> If the early run is read-only though - and I'm assuming by read-only you
> mean they won't cause a failure - how are you going to expose that there
> is a problem without failing? Would you make that configurable?
> Otherwise the checks themselves are supposed to be read-only and not
> change your data (they aren't the same thing as an online data migration
> routine for example).
>
>
If we need to have run the schema upgrade and migrations before the upgrade
check, I think that reduces the usefulness of a separate check operation. I
was thinking you might be able to run the checks against the system prior
to making any upgrade changes, but it seems not. I guess a separate check
after the upgrade might still be useful for diagnosing upgrade issues from
warnings.


> > 3. For the warnings, would you recommend a -Werror style argument that
> > optionally flags up warnings as errors? Reporting non-fatal errors is
> > quite difficult in Ansible.
>
> OSA fails on any return codes that aren't 0 (success) or 1 (warning).
> It's hard to say when warning should be considered an error really. When
> writing these checks I think of warning as a case where you might be OK
> but we don't really know for sure, so it can aid in debugging
> upgrade-related issues after the fact but might not necessarily mean you
> shouldn't upgrade. mnaser has brought up the idea in the past of making
> the output more machine readable so tooling could pick and choose which
> things it considers to be a failure (assuming the return code was 1).
> That's an interesting idea but one I haven't put a lot of thought into.
> It might be as simple as outputting a unique code per check per project,
> sort of like the error code concept in the API guidelines [3] which the
> placement project is using [4].
>
>
Machine readable would be nice. Perhaps there's something we could do to
generate a report of the combined results.

> [1] https://docs.openstack.org/nova/latest/reference/upgrade-checks.html
> [2] https://docs.openstack.org/nova/latest/install/verify.html
> [3] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html
> [4]
>
> https://opendev.org/openstack/placement/src/branch/master/placement/errors.py
>
> --
>
> Thanks,
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/44f7e076/attachment.html>

From bence.romsics at gmail.com  Fri Apr 26 13:09:28 2019
From: bence.romsics at gmail.com (Bence Romsics)
Date: Fri, 26 Apr 2019 15:09:28 +0200
Subject: [heat][neutron] improving extraroute support
In-Reply-To: <CAHeS+39faSoZOgB8qrNY0ZEpdDZCW7bB664wJBfZKbaVYreahg@mail.gmail.com>
References: <CAHeS+3_bCoyd12CjdDJRSGDBLbJC=MrV_=YQJUZ2D+3jMQMSYA@mail.gmail.com>
 <CABJHmF5ppGZ4qKqQtspL198AcKhbRSjar6xNwzi+z0dAZz7wpA@mail.gmail.com>
 <CAHeS+3_aUFj-jaVnPW8B-ft_oYw3mk3F14W+fHY+pKmZiT6_4Q@mail.gmail.com>
 <8b4f8152-b6d0-2145-104b-300bfd479ca8@redhat.com>
 <E0AE7BE9-1DDF-432F-9889-93ED61EF495E@redhat.com>
 <7998fbfd-1262-237e-8c59-a96dec00f8eb@redhat.com>
 <CAHeS+3-yeROwZkjSyQ93vjaECEfNsdC_hGEDC9BarNQ4tgOeNg@mail.gmail.com>
 <8748D38C-4ACA-4823-9C24-52260AC8A058@redhat.com>
 <CAHeS+39faSoZOgB8qrNY0ZEpdDZCW7bB664wJBfZKbaVYreahg@mail.gmail.com>
Message-ID: <CAHeS+3_AukOqEXE+n2ikwg=wzO3vRmcBixUW=1TKCu7oh-qFug@mail.gmail.com>

And here's the Heat story and spec:

https://storyboard.openstack.org/#!/story/2005522
https://review.opendev.org/655892

--
Bence


From jungleboyj at gmail.com  Fri Apr 26 13:50:26 2019
From: jungleboyj at gmail.com (Jay Bryant)
Date: Fri, 26 Apr 2019 08:50:26 -0500
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <alpine.OSX.2.11.1904081713160.9091@seed.local>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
Message-ID: <9ee7c897-2a91-6dc5-2d30-25cdae07e8b2@gmail.com>

Chris,

Sorry for the slow reply here.

The team has talked about this a little bit in our team meetings.  We 
had previously talked to the placement team about how it could benefit 
Cinder and I think we had reach the conclusion that there wasn't really 
any benefit that Cinder could get from placement.

I think, however, the open item is if Placement can benefit from Cinder 
if we were to make available volume and storage backend information to 
Placement.  If so we would need to understand the work involved.

It might be worth planning some cross project time at the PTG just to 
sync up on where things are at.  Let me know if you are interested in 
doing this.

Thanks!

Jay


On 4/8/2019 11:16 AM, Chris Dent wrote:
>
> From the etherpad [1]
>
> * blazar
> * cinder
> * cyborg
> * ironic
> * neutron
>
> Who else?
>
> This is a bit of a catch-many topic. Despite being birthed in Nova,
> Placement is designed to be useful to lots of different services.
>
> There's already some time defined at the PTG to talk about the
> interaction of Ironic, Blazar, and Placement.
>
> What are the issues with that?
>
> What are the issues other services are experiencing with Placement?
> Preventing people from using Placement?
>
> What services are using Placement and the team doesn't know about
> it?
>
>
> [1] https://etherpad.openstack.org/p/placement-ptg-train
>


From e0ne at e0ne.info  Fri Apr 26 14:10:03 2019
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Fri, 26 Apr 2019 17:10:03 +0300
Subject: [horizon] No meetings next two weeks
Message-ID: <CAGocpaHOv+n1Lc=J+3K-CzrM9pQY41y1M0nE=5_ncx2ZDANRXA@mail.gmail.com>

Hi all,

During the last IRC meeting [1] we agreed to skip the next two meetings.

I hope to see you in Denver next week.


[1]
http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-04-24-15.01.log.html#l-91

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/0ab857fe/attachment.html>

From mriedemos at gmail.com  Fri Apr 26 14:21:27 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 26 Apr 2019 09:21:27 -0500
Subject: [placement][ptg] Enabling other projects to continue with
 placement or get started
In-Reply-To: <9ee7c897-2a91-6dc5-2d30-25cdae07e8b2@gmail.com>
References: <alpine.OSX.2.11.1904081713160.9091@seed.local>
 <9ee7c897-2a91-6dc5-2d30-25cdae07e8b2@gmail.com>
Message-ID: <d59f25c7-5fc7-adaa-9fd3-4d2b7e1883d4@gmail.com>

On 4/26/2019 8:50 AM, Jay Bryant wrote:
> The team has talked about this a little bit in our team meetings.  We 
> had previously talked to the placement team about how it could benefit 
> Cinder and I think we had reach the conclusion that there wasn't really 
> any benefit that Cinder could get from placement.
> 
> I think, however, the open item is if Placement can benefit from Cinder 
> if we were to make available volume and storage backend information to 
> Placement.  If so we would need to understand the work involved.
> 
> It might be worth planning some cross project time at the PTG just to 
> sync up on where things are at.  Let me know if you are interested in 
> doing this.

Modeling AZ affinity in a central location (placement) between compute 
nodes and volumes would likely benefit the wonky 
[cinder]/cross_az_attach and related config options in cinder. We have a 
class of bugs in nova when that is enforced (cross_az_attach=False) 
which maybe useful for HPC and Edge workloads, but isn't tested or 
supported very well at this time. Granted, it might be as simple as 
reporting volumes (or their backend pool) as a resource provider and 
then putting that provider and the compute node provider in a resource 
provider aggregate (sort of like how we model [but don't yet use] shared 
DISK_GB resources). My thinking is if you had that modeled and nova is 
configured with cross_az_attach=False, and a server is created with some 
pre-existing volumes, the nova scheduler translates that to a request to 
placement for compute nodes only in the aggregate with whatever storage 
backend is providing those volume resources (the same AZ essentially). 
But this is probably low priority and arguably re-inventing an already 
somewhat broken wheel. Would have to think about how doing this with 
placement would be superior to what we have today.

-- 

Thanks,

Matt


From mriedemos at gmail.com  Fri Apr 26 15:05:54 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 26 Apr 2019 10:05:54 -0500
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
 <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
 <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>
 <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
Message-ID: <e2596637-36d1-971b-228c-024320618904@gmail.com>

On 4/26/2019 3:59 AM, Mark Goddard wrote:
> I was thinking you might be able to run the checks against the system 
> prior to making any upgrade changes, but it seems not.

You can and it might produce a warning or error for some checks saying 
to run online data migrations, but not all checks are related to or 
remedied with online data migrations. You can look at the History of 
Checks for nova [1]. The cells v2 ones in Ocata were very much about the 
need to create cell mappings and such - something we (nova) don't do for 
you. There are other checks for the minimum API version on a dependent 
external service (like placement, and I have one for cinder here [2]).

[1] https://docs.openstack.org/nova/latest/cli/nova-status.html#upgrade
[2] https://review.opendev.org/#/c/649759/

-- 

Thanks,

Matt


From openstack at nemebean.com  Fri Apr 26 15:09:12 2019
From: openstack at nemebean.com (Ben Nemec)
Date: Fri, 26 Apr 2019 10:09:12 -0500
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
 <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
 <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>
 <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
Message-ID: <287edd03-c321-c75d-9782-b5c8ae31b0fa@nemebean.com>



On 4/26/19 3:59 AM, Mark Goddard wrote:
>      > 3. For the warnings, would you recommend a -Werror style argument
>     that
>      > optionally flags up warnings as errors? Reporting non-fatal
>     errors is
>      > quite difficult in Ansible.
> 
>     OSA fails on any return codes that aren't 0 (success) or 1 (warning).
>     It's hard to say when warning should be considered an error really.
>     When
>     writing these checks I think of warning as a case where you might be OK
>     but we don't really know for sure, so it can aid in debugging
>     upgrade-related issues after the fact but might not necessarily mean
>     you
>     shouldn't upgrade. mnaser has brought up the idea in the past of making
>     the output more machine readable so tooling could pick and choose which
>     things it considers to be a failure (assuming the return code was 1).
>     That's an interesting idea but one I haven't put a lot of thought into.
>     It might be as simple as outputting a unique code per check per
>     project,
>     sort of like the error code concept in the API guidelines [3] which the
>     placement project is using [4].
> 
> 
> Machine readable would be nice. Perhaps there's something we could do to 
> generate a report of the combined results.

Note that there's a todo[0] in the oslo.upgradecheck code to switch to 
cliff for the output. That would allow us to easily output in 
machine-readable formats.

0: 
https://github.com/openstack/oslo.upgradecheck/blob/master/oslo_upgradecheck/upgradecheck.py#L106


From gmann at ghanshyammann.com  Fri Apr 26 18:11:52 2019
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 26 Apr 2019 13:11:52 -0500
Subject: [qa] Canceling QA office hour for next 3 weeks
Message-ID: <16a5ad8b50a.11fe1751c8820.1629573637630456839@ghanshyammann.com>

Hello Everyone,

Most of us will be in Summit and PTG next week and I will be on leave after PTG for 2 weeks to visit India.
Due to that, I am cancelling the QA office hour for the next 3 weeks.

-gmann



From gr at ham.ie  Fri Apr 26 19:12:59 2019
From: gr at ham.ie (Graham Hayes)
Date: Fri, 26 Apr 2019 15:12:59 -0400
Subject: =?UTF-8?Q?Re:_[tc][all]_Github_mirroring_(or_lack_thereof)_for_unofficia?=
 =?UTF-8?Q?l_projects?=
In-Reply-To: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
References: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
Message-ID: <671c0c6c-253d-4182-a6d9-f5cff635eb2a@www.fastmail.com>

+1

On Thu, 25 Apr 2019, at 11:04, Jim Rollenhagen wrote:
> Hi,
> 
> Now that the great OpenDev migration is done, we have a number of projects on Github which are no longer mirroring and becoming stale. This includes:
> 
> - most repositories at https://github.com/openstack-infra
> - any repository in https://github.com/openstack which is no longer in https://opendev.org/openstack
> - I think that's it, but there could be others.
> 
> The OpenDev and OpenStack teams have no plans to continue mirroring these projects to Github; primarily because we don't have a corresponding Github organization to put them in. However, teams can easily set up a mirror to any location they like on Github: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
> 
> The remaining question is what to do with the stale repos in the OpenStack organization on Github. Right now, we plan to just archive them. This means that the repository will be read-only, with a banner at the top saying it's archived. If a project owner wants to transfer the project to another Github organization, we can unarchive the project to do so, and they can maintain the mirroring via Zuul.
> 
> If there's no wild objections to this plan, we'll go ahead with it soon. Maybe the week after the Summit, unless someone in the OpenDev team has spare cycles before that.
> 
> // jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/59616c62/attachment.html>

From rfolco at redhat.com  Fri Apr 26 19:41:54 2019
From: rfolco at redhat.com (Rafael Folco)
Date: Fri, 26 Apr 2019 16:41:54 -0300
Subject: [tripleo] TripleO CI Summary: Sprint 29
Message-ID: <CAOr2xH7i1b+VtqOc+oq3hT9oErcVfhFhfkd+kS-7wjn050AnEw@mail.gmail.com>

Greetings,

The TripleO CI team has just completed Sprint 29 / Unified Sprint 8 (Apr 04
thru Apr 24).  The following is a summary of completed work during this
sprint cycle:

   -

   Bootstrapped RDO and OSP jobs in the internal Software Factory instance.
   -

   Monitored stable/stein jobs for TripleO projects and added missing
   branchful job for stein.
   -

   Switched to buildah on containers build jobs upstream in check pipeline.
   -

   Improved docs and code comments in emit_releases file for upgrade jobs.
   -

   Moved the periodic standalone, standalone scenario 1-4 jobs to os-tempest
   -

   Promotion status: green on all branches


The planned work for the next sprint [1] are:

   -

   Continue testing and defining jobs in the internal instance of Software
   Factory to run RDO and OSP on RHEL as an attempt to approximate upstream
   and downstream config/tooling used in the promotion pipeline.


   -

   Create a separate repository for collect-logs role and move code for
   being reused from other projects.


   -

   Schedule a test day for the zuul reproducer to fix deployment issues,
   usability and upgrade use cases.
   -

   Onboarded performance baremetal hardware to the internal Software
   Factory in order to run jobs of the promotion pipeline.
   -

   Noting lower capacity due to Summit / PTG



The Ruck and Rover for this sprint are Rafael Folco (rfolco) and Sorin
Sbarnea (zbr). Please direct questions or queries to them regarding CI
status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on
their nick. Ruck/rover notes are being tracked in etherpad [2].

Thanks,

rfolco

[1]
https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-9

[2] https://etherpad.openstack.org/p/ruckroversprint9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/5186261f/attachment-0001.html>

From mriedemos at gmail.com  Fri Apr 26 20:54:45 2019
From: mriedemos at gmail.com (Matt Riedemann)
Date: Fri, 26 Apr 2019 15:54:45 -0500
Subject: [nova][dev] Pike Extended Maintenance coming soon
In-Reply-To: <0eca4237-a861-022c-a362-d7c26c3c8881@gmail.com>
References: <a15eae55-5843-49aa-62e3-ef578db2ea12@gmail.com>
 <cabd1716-ae37-44b7-1f3c-d1da76b60652@gmail.com>
 <0eca4237-a861-022c-a362-d7c26c3c8881@gmail.com>
Message-ID: <718a9892-b1e2-2e92-b32b-9b10addb1ae5@gmail.com>

On 4/22/2019 8:41 AM, Matt Riedemann wrote:
> Just a quick update that [1] is all I'm waiting on now before we do a 
> final pike release and create the pike-em branch.
> 
> [1] 
> https://review.opendev.org/#/q/Iefab05e84ccc0bf8f15bdbbf515a290d282dbc5d+status:open

stable/pike for nova-governed repos is now in extended maintenance mode:

https://review.opendev.org/#/c/652869/

-- 

Thanks,

Matt


From aspiers at suse.com  Fri Apr 26 21:55:51 2019
From: aspiers at suse.com (Adam Spiers)
Date: Fri, 26 Apr 2019 22:55:51 +0100
Subject: [placement][nova][ptg] Protecting driver-provided traits
In-Reply-To: <9ba12331208089117b90459b433deb736b5dfbc7.camel@redhat.com>
References: <alpine.OSX.2.11.1904111338040.33106@seed.local>
 <20190411141057.vkrvox3mwvizprzz@pacific.linksys.moosehall>
 <E549B5E8-78F9-4500-84D9-FFEB5449D390@leafe.com>
 <20190411175719.b3umfdrkexcujqj4@arabian.linksys.moosehall>
 <alpine.OSX.2.21.1904121110240.33229@cdent-a01.vmware.com>
 <20190412125731.bfu3ivkkggbxhblb@pacific.linksys.moosehall>
 <76010EE1-DF37-4C5C-88A2-CCEB39329AB6@fried.cc>
 <20190424221216.hpdm3vga37xgwped@pacific.linksys.moosehall>
 <536fd3a5-c2ce-f7a8-66b6-1aac5334152d@fried.cc>
 <9ba12331208089117b90459b433deb736b5dfbc7.camel@redhat.com>
Message-ID: <20190426215551.xhtvmgontklf4v62@pacific.linksys.moosehall>

Sean Mooney <smooney at redhat.com> wrote: 
>On Wed, 2019-04-24 at 17:54 -0500, Eric Fried wrote: 
>>>In fact maybe this is a reasonable location? 
>>>https://docs.openstack.org/nova/latest/reference/update-provider-tree.html 
>>
>>I'm not sure that's any more discoverable than the spec (you may be 
>>overestimating the readership of our reference docs :), but sure. 
>>
>>And I don't see a problem putting the .svg file in-repo - is there an 
>>issue with that, anyone? 
>
>we already have a bunch of them 
>https://github.com/openstack/nova/tree/master/doc/source/figures 

OK then, now submitted: 

https://review.opendev.org/#/c/656032/ 


From juliaashleykreger at gmail.com  Fri Apr 26 23:55:42 2019
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Fri, 26 Apr 2019 16:55:42 -0700
Subject: [tc][all] Github mirroring (or lack thereof) for unofficial
 projects
In-Reply-To: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
References: <CAJCXu8cXL+aN2ix0spKMxcaPu_zN6wvYyjbyxpxkT8r-O1be1A@mail.gmail.com>
Message-ID: <CAF7gwdheBSrWB8mkLb+eq=Dr-jioJkO3-ygUac3g7F441GiU-Q@mail.gmail.com>

On Thu, Apr 25, 2019 at 8:10 AM Jim Rollenhagen <jim at jimrollenhagen.com> wrote:
>
> Hi,
>
> Now that the great OpenDev migration is done, we have a number of projects on Github which are no longer mirroring and becoming stale. This includes:
>
> - most repositories at https://github.com/openstack-infra
> - any repository in https://github.com/openstack which is no longer in https://opendev.org/openstack
> - I think that's it, but there could be others.
>
> The OpenDev and OpenStack teams have no plans to continue mirroring these projects to Github; primarily because we don't have a corresponding Github organization to put them in. However, teams can easily set up a mirror to any location they like on Github: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005007.html
>
> The remaining question is what to do with the stale repos in the OpenStack organization on Github. Right now, we plan to just archive them. This means that the repository will be read-only, with a banner at the top saying it's archived. If a project owner wants to transfer the project to another Github organization, we can unarchive the project to do so, and they can maintain the mirroring via Zuul.
>
> If there's no wild objections to this plan, we'll go ahead with it soon. Maybe the week after the Summit, unless someone in the OpenDev team has spare cycles before that.
>
> // jim

+1


From colleen at gazlene.net  Sat Apr 27 00:30:51 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Fri, 26 Apr 2019 20:30:51 -0400
Subject: [dev][keystone] Keystone Team Update - Week of 22 April 2019
Message-ID: <e109bd71-58ba-453f-b3a3-c139a20606eb@www.fastmail.com>

# Keystone Team Update - Week of 22 April 2019

## News

### Keystone Ocata in Pike are in Extended Maintenance

The stable/ocata and stable/stein branches went into Extended Maintenance mode this month[1][2] in accordance with the new-ish maintenance phase procedure[3]. This means that those branches won't be released any more. However, they are still open to land backports. If and when those branches become too difficult to maintain, we will discuss putting them in the Unmaintained phase.

[1] https://review.opendev.org/650467
[2] https://review.opendev.org/652905
[3] https://docs.openstack.org/project-team-guide/stable-branches.html

### No meetings next two weeks

We agreed to skip the next two IRC meetings[4].

[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005531.html

### Forum Sessions and Summit Presentations

Forum sessions that you should be aware of if you're interested in the future of keystone:
    
    Keystone Application Credentials: Status and Planning: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23643/keystone-application-credentials-status-and-planning
    Keystone Operator Feedback: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23644/keystone-operator-feedback
    Change ownership of resources - followup: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23675/change-ownership-of-resources-followup
    Project Resource Cleanup - followup: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23674/project-resource-cleanup-followup
    Increasing API accessibility with granular policy and default roles: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/increasing-api-accessibility-with-granular-policy-and-default-roles
    Unified limits update and migration: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23641/unified-limits-update-and-migration
    
Presentations related to keystone that you may be interested in:
    
    You can't make a (Denver) omelette without breaking eggs: Using OpenStack policies for great good: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23535/you-cant-make-a-denver-omelette-without-breaking-eggs-using-openstack-policies-for-great-good
    Lessons learnt federating OpenStack powered Supercomputers: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23106/lessons-learnt-federating-openstack-powered-supercomputers
    Leveraging OpenStack Keystone for Multi-Tenancy Support in Kubernetes: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23673/leveraging-openstack-keystone-for-multi-tenancy-support-in-kubernetes
    Keystone - Project Update: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23710/keystone-project-update
    Bridging Clouds with Keystone to Keystone Federation: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23285/bridging-clouds-with-keystone-to-keystone-federation
    Keystone JWS Tokens: Past, Present, and Future: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23585/keystone-jws-tokens-past-present-and-future
    Keystone - Project Onboarding: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23730/keystone-project-onboarding
    
### PTG Agenda

I rearranged the PTG agenda[5] a bit now that we have scheduled some meetings with other teams. The schedule is still fluid and subject to change.

[5] https://etherpad.openstack.org/p/keystone-train-ptg

### Team Dinner

We're having out team dinner on Wednesday evening[6] in Denver. If you'd like to join us and haven't yet RSVP'd, please let me know, we'd be glad to have you.

[6] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005549.html

## Open Specs

Train specs: https://bit.ly/2uZ2tRl

Ongoing specs: https://bit.ly/2OyDLTh

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 8 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2tymTje

There are 27 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots.

## Bugs

This week we opened 2 new bugs and closed 0.

Bugs opened (2) 
Bug #1825867 (keystone:Undecided) opened by Abhishek Sharma M https://bugs.launchpad.net/keystone/+bug/1825867 
Bug #1826197 (python-keystoneclient:Undecided) opened by jacky06 https://bugs.launchpad.net/python-keystoneclient/+bug/1826197 

Bugs closed (0) 

Bugs fixed (0)

## Milestone Outlook

https://releases.openstack.org/train/schedule.html

The schedule for keystone has been posted. The next deadline is the spec proposal freeze at milestone 1 which is in a few weeks.

## Shout-outs

See many of you next week!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter


From soulxu at gmail.com  Sat Apr 27 00:49:01 2019
From: soulxu at gmail.com (Alex Xu)
Date: Fri, 26 Apr 2019 18:49:01 -0600
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
Message-ID: <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>

Nadathur, Sundar <sundar.nadathur at intel.com> 于2019年4月25日周四 下午5:59写道：

> *From:* Alex Xu <soulxu at gmail.com>
> *Sent:* Monday, April 15, 2019 4:50 PM
>
> > The cyborg only needs to return un-numbered request group, then Nova will
> > base on all the 'hw:xxx' extra specs and 'accel:device_profile.[numa node
> > id]' to generate a placement request like above.
>
> I am not quite following the idea(s) proposed here. Cyborg returns only
> the device-related request groups. The un-numbered request group in the
> flavor is not touched by Cyborg.
>
>
>
> Secondly, if you use the ‘accel:’ stuff in the flavor to decide NUMA
> affinity, how will you pass that to Placement? This thread is about the
> syntax of the GET /a-c call.
>

The point at here is about we need some way to enable cyborg tell nova that
the device will attach to which guest numa node. I don't think we should
code the device guest numa affinity info in the request group which Cyborg
returned. The nova's flavor is the one tell that, and pass to the affinity
requirement to the GET /a-c call.


>
> > For example, if it is PCI device under first numa node, the extra spec
> will
> > be 'accel:device_profile.0=<profile_name>' the cyborg can return a simple
> > request 'resources=CYBORG_PCI_XX_DEVICE:1', then we merge this into the
> > request group 'resources1=VCPU:2,MEMORY_MB:128,CYBORG_PCI_XX_DEVICE:1'.
> If
> > the pci device has a special trait, then cyborg should return request
> group
> > as 'resources1=CYBORG_PCI_XX_DEVICE:1&required=SOME_TRAIT', then nova
> merge
> > this into placement request as 'resources1.1'.
>
> Sorry, I don’t follow this either. The request groups have entries like
> ‘resources:CUSTOM_FOO=1’, not 'resources=CYBORG_PCI_XX_DEVICE:1'. So, I
> don’t see where to stick the NUMA node #.
>
>
>
> Anyways, for Cyborg, it seems to me that there is a fairly straightforward
> scheme to address NUMA affinity: annotate the device’s nested RP with a
> trait indicating which NUMA node it belongs to (e.g. CUSTOM_NUMA_NODE_0),
> and use that to guide scheduling. This should be a valid use of traits
> because it expresses a property of the resource provider and is used for
> scheduling (only).
>

I don't like the way of using trait to mark out the NUMA node.


>
>
> As for how the annotation is done, it could be automated. The operator’s
> tool that configures a device to affinitize with a NUMA node (by setting
> MSI-X vectors, etc.) also invokes a Cyborg API (yet to be written) with the
> NUMA node # -- that would identify the device RP and update Placement with
> that trait. The tool needs to ensure that the device has been discovered by
> Cyborg and updated in Placement before invoking the API.
>

What I'm talking about at here is about the virtual device attach to which
guest numa node. It isn't about the a physical device affinity to which
host numa node.


>
>
> Regards,
>
> Sundar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190426/01c9a630/attachment-0001.html>

From eumel at arcor.de  Sat Apr 27 01:10:13 2019
From: eumel at arcor.de (Frank Kloeker)
Date: Sat, 27 Apr 2019 03:10:13 +0200
Subject: [PTG][Docs][I18n] Planning and time schedule
Message-ID: <322628aed4a78de46e5a1847f1d5b404@arcor.de>

Dear fellow stackers,

PTG for Train will held next week in Denver. I'm alredy here and I 
wouldn't say, I miss the train from Stapleton Station with all the 
noice. But I wouldn't miss the Train PTG in this lovely town in the U.S.
It reminds me that diversity is still the greatest strength of our 
community.
Well, for the different reasons I do not expect many team members to 
attend onsite, but some should be still there. The scheduled Docs/I18n 
day is regarding timetable [1] Thursday, May 02 2019. Weather forecast 
says sunny with 16 degrees - so no snow do expect.
I've created an Etherpd and linked it on the main list [2]. Please feel 
free to add your name there and propose your topic. I spotted two things 
so far:
- Documentation PDF support which is an official main goal for train
- Migrate I18n translation platform back from Zanata
There is no full planned timetable yet. Maybe we have during the day an 
onsite discussion and want to sync with remote guys at 16:00? EU is 8 
hours ahead and Korea/Japan 15 hours [3].
Let me know your thoughts and ideas or write it to the Etherpad.

many thanks

Frank (previous PTL I18n)

[1] https://www.openstack.org/ptg/#tab_schedule
[2] https://wiki.openstack.org/wiki/PTG/Train/Etherpads
[3] 
https://www.timezones.de/time_conference_planner_timeszone/v2/1850147%2C2950159%2C5419384%2C1835848%2C2643741/5419384/02.05.2019+16%3A00



From james.page at canonical.com  Sat Apr 27 08:41:31 2019
From: james.page at canonical.com (James Page)
Date: Sat, 27 Apr 2019 09:41:31 +0100
Subject: [ptg][sig][upgrades] Train PTG Upgrades SIG session
Message-ID: <CAG1bqQpCfsjau9y5bV7qjd8o4d1TLrkeHHoD_jp+jPRH-xfcXg@mail.gmail.com>

Hi All

I've finally found time to create an etherpad for the Upgrades SIG session
at the upcoming PTG in Denver (on the train on my way to LHR to catch my
flight).

  https://etherpad.openstack.org/p/upgrade-sig-ptg-train

I've added a few proposed topics but if you're at the PTG (or summit) and
have anything upgrade related to discuss please add your topic to the
etherpad over the next few days - I'll then put together a rough schedule
for our half day of upgrades discussion on Thursday morning in room 201.

IRC meetings never really got restarted since the last PTG but I know that
the promise of getting together to discuss upgrade successes and challenges
generally appeals to us all based on prior sessions!

Thanks in advance and see you all in Denver!

Cheers

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190427/565f4177/attachment.html>

From mnaser at vexxhost.com  Sat Apr 27 10:53:13 2019
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Sat, 27 Apr 2019 06:53:13 -0400
Subject: [goals][upgrade-checkers] Retrospective
In-Reply-To: <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
References: <69f02a06-ed56-0cf4-396a-da050b307db6@gmail.com>
 <CAFHSqWrjMd=hF-goMQQ5sp_HeDpnr=5Psyz+=w_QXpSu=8dNMQ@mail.gmail.com>
 <701e5d25-0698-c57e-5f0a-2f64d711543d@gmail.com>
 <CAFHSqWom6d1rdtDE+QkiScHz4ZyVk8d1x4TJFbQmeH-cqGW=uQ@mail.gmail.com>
Message-ID: <CAEs876gE1YQQEgoTC55+dEgdg=0qJJ+jy4PfyifUV0BD+vjQJA@mail.gmail.com>

On Fri, Apr 26, 2019 at 5:03 AM Mark Goddard <mark at stackhpc.com> wrote:
>
>
>
> On Thu, 25 Apr 2019 at 23:50, Matt Riedemann <mriedemos at gmail.com> wrote:
>>
>> On 4/24/2019 8:21 AM, Mark Goddard wrote:
>> > I put together a patch for kolla-ansible with support for upgrade checks
>> > for some projects: https://review.opendev.org/644528. It's on the
>> > backburner at the moment but I plan to return to it during the Train
>> > cycle. Perhaps you could clarify a few things about expected usage.
>>
>> Cool. I'd probably try to pick one service (nova?) to start with before
>> trying to bite off all of these in a single change (that review is kind
>> of daunting).
>>
>> Also, as part of the community wide goal I wrote up reference docs in
>> the nova tree [1] which might answer your questions with links for more
>> details.
>>
>> >
>> > 1. Should the tool be run using the new code? I would assume so.
>>
>> Depends on what you mean by "new code". When nova introduced this in
>> Ocata it was meant to be run in a venv or container after upgrading the
>> newton schema and data migrations to ocata, but before restarting the
>> services with the ocata code and that's how grenade uses it. But the
>> checks should also be idempotent and can be run as a
>> post-install/upgrade verify step, which is how OSA uses it (and is
>> described in the nova install docs [2]).
>>
>
> In kolla land, I mean should I use the container image for the current release or the target release to execute the nova-status command. It sounds like it's the latter, which also implies we're using the target version of kolla/kolla-ansible. I hadn't twigged that we'd need to perform the schema upgrade and online migrations.
>
>>
>> > 2. How would you expect this to be run with multiple projects? I was
>> > thinking of adding a new command that performs upgrade checks for all
>> > projects that would be read-only, then also performing the check again
>> > as part of the upgrade procedure.
>>
>> Hmm, good question. This probably depends on each deployment tool and
>> how they roll through services to do the upgrade. Obviously you'd want
>> to run each project's checks as part of upgrading that service, but I
>> guess you're looking for some kind of "should we even start this whole
>> damn upgrade if we can detect early that there are going to be issues?".
>> If the early run is read-only though - and I'm assuming by read-only you
>> mean they won't cause a failure - how are you going to expose that there
>> is a problem without failing? Would you make that configurable?
>> Otherwise the checks themselves are supposed to be read-only and not
>> change your data (they aren't the same thing as an online data migration
>> routine for example).
>>
>
> If we need to have run the schema upgrade and migrations before the upgrade check, I think that reduces the usefulness of a separate check operation. I was thinking you might be able to run the checks against the system prior to making any upgrade changes, but it seems not. I guess a separate check after the upgrade might still be useful for diagnosing upgrade issues from warnings.
>
>>
>> > 3. For the warnings, would you recommend a -Werror style argument that
>> > optionally flags up warnings as errors? Reporting non-fatal errors is
>> > quite difficult in Ansible.
>>
>> OSA fails on any return codes that aren't 0 (success) or 1 (warning).
>> It's hard to say when warning should be considered an error really. When
>> writing these checks I think of warning as a case where you might be OK
>> but we don't really know for sure, so it can aid in debugging
>> upgrade-related issues after the fact but might not necessarily mean you
>> shouldn't upgrade. mnaser has brought up the idea in the past of making
>> the output more machine readable so tooling could pick and choose which
>> things it considers to be a failure (assuming the return code was 1).
>> That's an interesting idea but one I haven't put a lot of thought into.
>> It might be as simple as outputting a unique code per check per project,
>> sort of like the error code concept in the API guidelines [3] which the
>> placement project is using [4].
>>
>
> Machine readable would be nice. Perhaps there's something we could do to generate a report of the combined results.

Interesting you bring that up, I made an attempt a while back, but didn't have
the resources to drive it through.

https://review.opendev.org/#/c/576944/

>> [1] https://docs.openstack.org/nova/latest/reference/upgrade-checks.html
>> [2] https://docs.openstack.org/nova/latest/install/verify.html
>> [3] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html
>> [4]
>> https://opendev.org/openstack/placement/src/branch/master/placement/errors.py
>>
>> --
>>
>> Thanks,
>>
>> Matt



-- 
Mohammed Naser — vexxhost
-----------------------------------------------------
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
W. http://vexxhost.com


From colleen at gazlene.net  Sat Apr 27 14:10:01 2019
From: colleen at gazlene.net (Colleen Murphy)
Date: Sat, 27 Apr 2019 10:10:01 -0400
Subject: [dev][keystone] Keystone Team Update - Week of 22 April 2019
In-Reply-To: <e109bd71-58ba-453f-b3a3-c139a20606eb@www.fastmail.com>
References: <e109bd71-58ba-453f-b3a3-c139a20606eb@www.fastmail.com>
Message-ID: <4d112cda-e72f-4d70-abc7-76a93817d14d@www.fastmail.com>

On Fri, Apr 26, 2019, at 17:31, Colleen Murphy wrote:
> # Keystone Team Update - Week of 22 April 2019
> 
> ## News
> 
> ### Keystone Ocata in Pike are in Extended Maintenance
> 
> The stable/ocata and stable/stein branches went into Extended 

I meant stable/ocata and stable/pike here, of course! Apologies if I caused any confusion.

> Maintenance mode this month[1][2] in accordance with the new-ish 
> maintenance phase procedure[3]. This means that those branches won't be 
> released any more. However, they are still open to land backports. If 
> and when those branches become too difficult to maintain, we will 
> discuss putting them in the Unmaintained phase.
> 
> [1] https://review.opendev.org/650467
> [2] https://review.opendev.org/652905
> [3] https://docs.openstack.org/project-team-guide/stable-branches.html
> 


From jimmy at tipit.net  Wed Apr 24 14:31:10 2019
From: jimmy at tipit.net (Jimmy Mcarthur)
Date: Wed, 24 Apr 2019 09:31:10 -0500
Subject: OpenStack User Survey 2019
Message-ID: <5CC0732E.8020601@tipit.net>

It's time for the OpenStack User Survey 
<https://www.openstack.org/user-survey> [1]!  In an effort to create 
less work for our community, in 2018 we moved to an annual, rather than 
a bi-annual report.  If you run an OpenStack deployment, now is the time 
to share details about how you run the software and your thoughts on 
ways that the community can improve the software.  Your feedback matters 
and it's shared directly with the PTLs and community leaders that work 
to build OpenStack!

We had some good community feedback on the last survey and ended up with 
only minor updates from 2018.  Below you can see a list of changes that 
we've incorporated:

  * "Which new/emerging technologies are you interested in using or
    seeing integrated with OpenStack?"
      o Added options for "AI/ML" and "5G"
  * Deleted the question "Are you interested in helping our
    interoperability efforts by using RefStack to test your cloud
    capabilities?"
  * "Which tools are you using to deploy / manage this cluster?"
      o Added the word "manage" to the question as tools can be used for
        both
      o Add "TripleO" and "Container-based orchestration" as options
      o Created a new "Please specify" if "Other tools" is chosen
  * "Which container orchestration or Platform-as-a-Service (PaaS) tools
    are you using to manage applications on this OpenStack deployment?"
      o Added "container orchestration or " to question
  * "Which OpenStack Network (Neutron) drivers are you using?"
      o Add Calico as an answer
  * "Which compatibility APIs does this deployment support?"
      o Added the option "This deployment doesn't use compatibility APIs"
  * Please note: This year, we will not be including the hardware and
    software vendor questions in the report or analytics dashboard due
    to the potential for the data to be misinterpreted.

*
*In addition to the question modifications above, we reached out to PTLs 
to ask for their feedback and guidance on the project specific questions 
of the survey.  We've modified or added those questions as noted below:

*Keystone*
This will be a question where respondents can rank their choices and 
will follow their existing question:

  * Which of the following initiatives would be most beneficial for your
    deployment? You can rank items by priority with items at the top
    being most important and items at the bottom being least important.
      o Improved performance
      o Better support for synchronizing multiple keystone regions
      o Read-only RBAC roles
      o More flexible federated mappings
      o Improved fine-grained access control
      o Better support for domain administrators
      o Improved usability of keystone outside of an OpenStack environment

Glance
Changed existing question to:

  * "Multi back-ends feature will stay Experimental in Stein release.
    How badly this affect your deployment plans? Any details how
    you’re planning to use it would be helpful.”

*Ironic*
Changed existing question to:

  * "What would you find most useful if it was part of Ironic?"

*Swift*
Changed existing question to:

  * What features of Swift are you currently using (or have plans to use
    in the next 12 months)? (select all that apply
      o S3 compatibility
      o Dynamic Large Objects
      o Static Large Objects
      o Temporary URLs
      o Data-at-rest encryption
      o Multiple storage policies
      o Multi-region clusters
      o Explicit data placement (composite rings)
      o Container sync
      o Static websites or CORS
      o Symlinks
      o Quotas
      o Object versioning

If you have further questions, concerns, please let us know.

Cheers,
Jimmy and Allison

[1] https://www.openstack.org/user-survey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/d3815e1d/attachment-0001.html>

From jaypipes at gmail.com  Sat Apr 27 15:52:29 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Sat, 27 Apr 2019 11:52:29 -0400
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
Message-ID: <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>

On 04/26/2019 08:49 PM, Alex Xu wrote:
> Nadathur, Sundar <sundar.nadathur at intel.com 
>     Anyways, for Cyborg, it seems to me that there is a fairly
>     straightforward scheme to address NUMA affinity: annotate the
>     device’s nested RP with a trait indicating which NUMA node it
>     belongs to (e.g. CUSTOM_NUMA_NODE_0), and use that to guide
>     scheduling. This should be a valid use of traits because it
>     expresses a property of the resource provider and is used for
>     scheduling (only).
> 
> 
> I don't like the way of using trait to mark out the NUMA node.

Me neither. Traits are capabilities, not indicators of the relationship 
between one provider and another.

The structure of hierarchical resource providers is what provides 
topology information -- i.e. about how providers are related to each 
other within a tree organization, and this is what is appropriate for 
encoding NUMA topology information into placement.

The request should never ask for "NUMA Node 0". The reason is because 
the request shouldn't require that the user understand where the 
resources are.

It shouldn't matter *which* NUMA node a particular device that is 
providing some resources is affined to. The only thing that matters to a 
*request* is that the user is able to describe the nature of the affinity.

I propose using a "group_policy=same_tree:$GROUP_A:$GROUP_B" query 
parameter for enabling users to describe the affinity constraints for 
various resources involved in different RequestGroups in the request spec.

group_policy=same_tree:$A:$B would mean "ensure that the providers that 
match the constraints of request group $B are in the same inclusive tree 
that matched for request group $A"

So, let's say you have a flavor that will consume:

  2 dedicated host CPU processors
  4GB RAM
  1 context/handle for an accelerator running a crypto algorithm

Further, you want to ensure that the provider tree that is providing 
those dedicated CPUs and RAM will also provide the accelerator context 
-- in other words, you are requesting a low level of latency between the 
memory and the accelerator device itself.

The above request to GET /a_c would look like this:

  GET /a_c?
    resources1=PCPU:2&
    resources1=MEMORY_MB=4096&
    resources2=ACCELERATOR_CONTEXT&
    required2=CUSTOM_BITSTREAM_CRYPTO_4AC1&
    group_policy=same_tree:1:2

which would mean, in English, "get me an accelerator context from an 
FPGA that has been flashed with the 4AC1 crypto bitstream and is affined 
to the NUMA node that is providing 4G of main memory and 2 dedicated 
host processors".

Best,
-jay


From sundar.nadathur at intel.com  Sat Apr 27 18:26:59 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Sat, 27 Apr 2019 18:26:59 +0000
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
Message-ID: <1CC272501B5BC543A05DB90AA509DED5275531E5@fmsmsx122.amr.corp.intel.com>

Hi Jay and Alex,
    Thanks for the response. Please see below.

Regards,
Sundar

> -----Original Message-----
> From: Jay Pipes <jaypipes at gmail.com>
> Sent: Saturday, April 27, 2019 8:52 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [placement][nova][ptg] resource provider affinity
> 
> On 04/26/2019 08:49 PM, Alex Xu wrote:
> > Nadathur, Sundar <sundar.nadathur at intel.com
> >     Anyways, for Cyborg, it seems to me that there is a fairly
> >     straightforward scheme to address NUMA affinity: annotate the
> >     device’s nested RP with a trait indicating which NUMA node it
> >     belongs to (e.g. CUSTOM_NUMA_NODE_0), and use that to guide
> >     scheduling. This should be a valid use of traits because it
> >     expresses a property of the resource provider and is used for
> >     scheduling (only).
> >
> >
> > I don't like the way of using trait to mark out the NUMA node.
> 
> Me neither. Traits are capabilities, not indicators of the relationship between
> one provider and another.
> 
> The structure of hierarchical resource providers is what provides topology
> information -- i.e. about how providers are related to each other within a tree
> organization, and this is what is appropriate for encoding NUMA topology
> information into placement.
> 
> The request should never ask for "NUMA Node 0". The reason is because the
> request shouldn't require that the user understand where the resources are.

I agree with this for most use cases. However, there are specific cases where a reference architecture is laid out for a specific workload, which requires a specific number of VMs to be placed in each NUMA node, with specific number of devices (NICs or accelerators) assigned to them. The network bandwidth, computation load, etc. are all pre-calculated to fit the VM's size and device characteristics. Any departure from that may affect workload performance -- throughput, latency or jitter. However, if the request says, 'Give me a VM on _a_ NUMA node, I don't care which one', one may wind up with say 3 VMs on one NUMA node and 1 VM on the other, which is not the intended outcome.

One could argue that we should model all resources, such as PCIe lanes/bandwidth from a socket (not the same as NUMA node), to the point where we can influence the exact placement among NUMA nodes. This has several issues, IMHO:
* This is more tied to the hardware details.
* Many of these resources are not dedicated or partitionable among VMs, e.g. PCIe lanes. I don’t see how we can track and count them in Placement on per-VM basis.
* It is more complex for both developers and operators.

In this situation, the operator is willing (in my understanding) to phrase the request precisely to get the exact desired layout.

> It shouldn't matter *which* NUMA node a particular device that is providing
> some resources is affined to. The only thing that matters to a
> *request* is that the user is able to describe the nature of the affinity.
> 
> I propose using a "group_policy=same_tree:$GROUP_A:$GROUP_B" query
> parameter for enabling users to describe the affinity constraints for various
> resources involved in different RequestGroups in the request spec.
> 
> group_policy=same_tree:$A:$B would mean "ensure that the providers that
> match the constraints of request group $B are in the same inclusive tree that
> matched for request group $A"

Request groups from Neutron and Cyborg do not have any inherent group numbers; Nova assigns those group numbers before submission to Placement. So, the GET /a-c call could technically have such numbers, but how would Neutron or Cyborg express that affinity? 
 
> So, let's say you have a flavor that will consume:
> 
>   2 dedicated host CPU processors
>   4GB RAM
>   1 context/handle for an accelerator running a crypto algorithm
> 
> Further, you want to ensure that the provider tree that is providing those
> dedicated CPUs and RAM will also provide the accelerator context
> -- in other words, you are requesting a low level of latency between the
> memory and the accelerator device itself.
> 
> The above request to GET /a_c would look like this:
> 
>   GET /a_c?
>     resources1=PCPU:2&
>     resources1=MEMORY_MB=4096&
>     resources2=ACCELERATOR_CONTEXT&
>     required2=CUSTOM_BITSTREAM_CRYPTO_4AC1&
>     group_policy=same_tree:1:2
> 
> which would mean, in English, "get me an accelerator context from an FPGA
> that has been flashed with the 4AC1 crypto bitstream and is affined to the
> NUMA node that is providing 4G of main memory and 2 dedicated host
> processors".
> 
> Best,
> -jay


From johnsomor at gmail.com  Sat Apr 27 22:01:27 2019
From: johnsomor at gmail.com (Michael Johnson)
Date: Sat, 27 Apr 2019 15:01:27 -0700
Subject: OpenStack User Survey 2019
In-Reply-To: <5CC0732E.8020601@tipit.net>
References: <5CC0732E.8020601@tipit.net>
Message-ID: <CAMH0MgKv_0dQPiXY5mSdLtdH2aXd_c4Tkr4Zc8nK-NG9hUCSmg@mail.gmail.com>

Jimmy,

I am curious, how did you reach out the PTLs for project specific
questions?  The Octavia team didn't receive any e-mail from you or
Allison on the topic.

Michael


From allison at openstack.org  Sun Apr 28 00:11:08 2019
From: allison at openstack.org (Allison Price)
Date: Sat, 27 Apr 2019 18:11:08 -0600
Subject: OpenStack User Survey 2019
In-Reply-To: <CAMH0MgKv_0dQPiXY5mSdLtdH2aXd_c4Tkr4Zc8nK-NG9hUCSmg@mail.gmail.com>
References: <5CC0732E.8020601@tipit.net>
 <CAMH0MgKv_0dQPiXY5mSdLtdH2aXd_c4Tkr4Zc8nK-NG9hUCSmg@mail.gmail.com>
Message-ID: <74F9B988-972B-422F-94D1-E62A83FD87A7@openstack.org>

Hi Michael,

We reached out to all of the PTLs who had questions in the 2018 version of the survey to review and update their questions. If there is a project that was missed, we can add it and share anonymized results with the PTLs directly as well as the openstack-discsuss mailing list.

If there is a question from the Octavia team, please let us know and we can add it for the 2019 survey.

Cheers,
Allison



> On Apr 27, 2019, at 4:01 PM, Michael Johnson <johnsomor at gmail.com> wrote:
> 
> Jimmy,
> 
> I am curious, how did you reach out the PTLs for project specific
> questions?  The Octavia team didn't receive any e-mail from you or
> Allison on the topic.
> 
> Michael
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190427/e4c0a73b/attachment.html>

From geguileo at redhat.com  Sun Apr 28 05:59:54 2019
From: geguileo at redhat.com (Gorka Eguileor)
Date: Sun, 28 Apr 2019 07:59:54 +0200
Subject: [cinder][vendors][cinderlib] Validating Cinder driver for usage with
 cinderlib
Message-ID: <20190428055954.oyg63s2igx7nfo3d@localhost>

Hi,

This is a call to Storage vendors and application developers that, with
the excitement of the Stein release, may have missed the first cinderlib
release [1][2] under the OpenStack umbrella that happened on the 16th.
Cinderlib is doing cycle trailing releases.

Using Cinder drivers out of OpenStack has been a frequent request by
developers wanting to leverage Cinder's storage management capabilities
without all the extra features that Cinder provides, such as quotas,
replication, migrations, etc.

The answer from the Cinder team has been to create a Python library that
provides an object oriented abstraction around Cinder’s storage drivers
to allow their direct usage without running any of the Cinder services
(API, Scheduler, Volume) or surrounding services (KeyStone, MySQL,
RabbitMQ).

Even though cinderlib has just been released as a Tech Preview, there
are already 2 projects using it:

- oVirt: in the Managed Block Storage functionality [3]
- Ember-CSI: providing storage for Kubernetes, Mesos, Docker swarm,
  cloud foundry, etc. [4]

This means that with a single Cinder driver vendors can support multiple
platforms:

- OpenStack
- oVirt
- Containers: Kubernetes, Mesos, Docker swarm, cloud foundry, etc.

Cinderlib works around the limitations that prevented direct usage of
the drivers. One of these are driver "particularities", and that's why
we recommend vendors that want to ensure compatibility with the library
to run the cinderlib functional tests at the gate.  These tests take but
a minute to run.

We have some documentation under review [5] going over the process of
doing manual validation of a driver, running the tests as jobs of the
cinderlib project, or as an additional step of the Cinder tempest run.
The cinderlib project currently has 2 backends running the functional
tests, LVM and Ceph, and we have patches up to run them as part of the
LVM [6] and Ceph [7] Cinder jobs as well.

If you are interested in using project, validating your driver, or just
have some feedback or questions feel free to drop me an email or DM me
(twitter @geguileo) and I'll be more than happy help. If you are going
to the Open Infrastructure Summit we can meet in person, and if you feel
adventurous we can even do the manual validation.

Cheers,
Gorka.


[1]: https://docs.openstack.org/cinderlib/latest/index.html
[2]: https://pypi.org/project/cinderlib/
[3]: https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html
[4]: https://ember-csi.io
[5]: https://review.opendev.org/#/c/651880/
[6]: https://review.opendev.org/#/c/620671/
[7]: https://review.opendev.org/#/c/645182/


From openstack at medberry.net  Sun Apr 28 13:37:12 2019
From: openstack at medberry.net (David Medberry)
Date: Sun, 28 Apr 2019 07:37:12 -0600
Subject: [ops] OpenStack Operators & Beer
Message-ID: <CAJhvMSu7=G6b8ovkDH_WTcWtkxUB2CuETnzL7UN+M-0HrTaLEw@mail.gmail.com>

Reminder, Monday night at Open Infra Summit, OpenStack Ops are invited
to hangout at Wynkoop Brewery. Reservation under my name for 7:30pm.
This is a casual, unsponsored gathering (much as we have done at prior
Operator Meetups). There is dining on the first floor and there will
also be a pool table reserved on the second floor.

(This is all AFTER the Open Infra Marketplace kick-off.)

-dave

David Medberry
OpenStack Guy and Frisbee Flinger


From jungleboyj at gmail.com  Sun Apr 28 17:51:09 2019
From: jungleboyj at gmail.com (Jay Bryant)
Date: Sun, 28 Apr 2019 12:51:09 -0500
Subject: [cinder] Team Dinner Update ...
Message-ID: <532e5f51-8d2b-421d-af4b-71f8bfa14b4b@gmail.com>

Team,

A slight update to our team dinner plans.  I could not get a reservation 
for 6 due to an Avalanche game happening.  I was able to get a 
reservation for 7:15 instead.  I have updated the etherpad: 
https://etherpad.openstack.org/p/cinder-train-dinner-plan

Look forward to seeing you all there!

Jay



From amy at demarco.com  Sun Apr 28 20:34:07 2019
From: amy at demarco.com (Amy Marrich)
Date: Sun, 28 Apr 2019 14:34:07 -0600
Subject: [OpenStack-Ansible][OSA] Team Dinner Denver
Message-ID: <CAFs83Qoey8tsE1=x54a6wi=6XFRibiL+Vr3EZR=2Qr_M-dUrfg@mail.gmail.com>

We are looking at having our official team dinner Wednesday evening. Please
visit this etherpad:

https://etherpad.openstack.org/p/osa-team-dinner-plan

To add your name and vote on restaurants so I can get a head count and make
a reservation.

Thanks,

Amy (spotz)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190428/729b67b2/attachment.html>

From cdent+os at anticdent.org  Sun Apr 28 23:18:41 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Sun, 28 Apr 2019 17:18:41 -0600 (MDT)
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
 <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
Message-ID: <alpine.OSX.2.21.1904281714570.5457@cdent-a01.vmware.com>

On Sun, 21 Apr 2019, Jay Pipes wrote:

> In other words, the algorithm for matching allocation candidates should do 
> the following in order for each request group:
>
> 1) Find the provider IDs having capacity for the resources contained in the 
> request group
> 2) If there is a member_of constraint in this request group, reduce the 
> matched set to only those providers that are associated (or have any children 
> associated) with the aggregates listed in the member_of constraint
> 3) If there is a required trait constraint in this request group, reduce the 
> matched set to only those providers that have the required trait(s) or where 
> their children have the required traits
> 4) If there is a forbidden trait constraint in this request group, remove 
> from the matched set any providers that have the forbidden trait(s) or where 
> their children have the forbidden traits

Is this the same as or sort of the opposite of the "traits flow down" or
"everything is spanning" ideas discussed near

http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.html

?

Whichever it is, I think both have merit because they provide a
somewhat universal way to interpret trait and aggregate membership,
which will help make this stuff more clear.

I'm tending to think that resolving this question is the one main
things we should do at the PTG, but I'm not clear where to fit it in
the schedule without conflicting with a nova topic and also
being able to include Jay in the discussion.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Sun Apr 28 23:31:37 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Sun, 28 Apr 2019 17:31:37 -0600 (MDT)
Subject: [placement][nova][ptg] Resource provider - request group mapping
In-Reply-To: <76a8323c-42d1-3aee-ac44-98d6668a091a@gmail.com>
References: <alpine.OSX.2.21.1904091831490.93787@cdent-a01.vmware.com>
 <1554889000.14045.11@smtp.office365.com>
 <af85a705-313f-9457-4ec5-2c217ab271b1@fried.cc>
 <alpine.OSX.2.11.1904111156530.33106@seed.local>
 <76a8323c-42d1-3aee-ac44-98d6668a091a@gmail.com>
Message-ID: <alpine.OSX.2.21.1904281724490.5457@cdent-a01.vmware.com>

On Sun, 21 Apr 2019, Jay Pipes wrote:

> In other words, the whole idea of placement -- including the addition of 
> hierachical and shared providers -- was to provide relief from the 
> free-for-all Wild West frontier that still exists in the Nova PCI manager, 
> hardware.py module, NUMATopologyFilter, and all that. It was supposed to 
> provide us a path out of that quagmire.
>
> I take it as a personal failure that we've yet to be able to take advantage 
> of the more consistent and structured data model in placement for these more 
> "advanced" resource classes :(

I think we can still do it, but we need to get our mental models
arranged and aligned. Thus my drive for some kind of universal
theory of nested operation. Some simple heuristics that make it
easy to map goals to processes to code.

Things that allow us to say "we could do it that way, but that
upsets the model".

One area where we seem to be running into problems a lot lately is
situations where people want to make requests to placement that are
explicit and specific about an instance of a type of thing, rather
than just the type of thing. Placement is oriented towards the
latter and while we could do that level of specificity it requires a
much more detailed awareness of the cloud across all the tools that
are involved than is ideal. If you already have that much awareness,
placement isn't really what you need: you already know the place.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From cdent+os at anticdent.org  Sun Apr 28 23:45:07 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Sun, 28 Apr 2019 17:45:07 -0600 (MDT)
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
Message-ID: <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>

On Sat, 27 Apr 2019, Jay Pipes wrote:

> The request should never ask for "NUMA Node 0". The reason is because the 
> request shouldn't require that the user understand where the resources are.
>
> It shouldn't matter *which* NUMA node a particular device that is providing 
> some resources is affined to. The only thing that matters to a *request* is 
> that the user is able to describe the nature of the affinity.

Yes, very much yes to these two paragraphs. See also:
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005682.html

> I propose using a "group_policy=same_tree:$GROUP_A:$GROUP_B" query parameter 
> for enabling users to describe the affinity constraints for various resources 
> involved in different RequestGroups in the request spec.

At first glance this seems pretty reasonable. Does anyone hate it?


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From openstack at fried.cc  Mon Apr 29 00:01:40 2019
From: openstack at fried.cc (Eric Fried)
Date: Sun, 28 Apr 2019 19:01:40 -0500
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
Message-ID: <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>

>> I propose using a "group_policy=same_tree:$GROUP_A:$GROUP_B" query
>> parameter for enabling users to describe the affinity constraints for
>> various resources involved in different RequestGroups in the request
>> spec.
> 
> At first glance this seems pretty reasonable. Does anyone hate it?

We've talked about this previously. The two objections raised were:

a) It assumes the meaning of "same tree" is "one level down from the
root". This satisfies NUMA affinity, and also allows us to do things
like [1] (scroll down to the pretty picture where networking agents are
subtree roots). But it may prove too limiting in the future if, for
example, we need to represent sockets *under* NUMA nodes and do L3 cache
affinity. (Come to think of it, if we need to do [1] in the presence of
NUMA and need to affine the network devices to the CPUs, what would that
whole tree look like, and how would it affect this proposal?)

b) It assumes the various pieces of the request (flavor, image, port,
device profile) are able to know each others' request group numbers
ahead of time. Or we need provide some other mechanism for the scheduler
code that dynamically assigns the numbers [2] to understand which ones
need to be (sub)grouped together. IIUC this has been Sundar's main
objection.

efried

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005111.html
[2]
https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/utils.py#L478-L479


From johfulto at redhat.com  Mon Apr 29 01:50:15 2019
From: johfulto at redhat.com (John Fulton)
Date: Sun, 28 Apr 2019 21:50:15 -0400
Subject: [tripleo] default ceph migrating from luminous to nautilus
In-Reply-To: <CAE66OMDOxZeS3KynnG_wwB06QLBDq8O8f5WwnYf589AhmY08HA@mail.gmail.com>
References: <CAE66OMDOxZeS3KynnG_wwB06QLBDq8O8f5WwnYf589AhmY08HA@mail.gmail.com>
Message-ID: <CAE66OMAd3fEfmsZERk=HqgQVKqvNKva3q08y6F+YfjdYkwVB7Q@mail.gmail.com>

On Wed, Apr 24, 2019 at 3:09 PM John Fulton <johfulto at redhat.com> wrote:
>
> We're going to be making some updates in TripleO and RDO so that the
> default version of Ceph in Stein is Nautilus. Part of this involves
> temporarily disabling the standalone 001/004 jobs. Our reviews are
> lined up and linked with additional details on the TripleO Integration
> Squad etherpad [1]. We'll be waiting until the 3rd party checks are
> green [2] before we start merging.

This has been completed and standalone 001/004 jobs should now be
voting again [3]. Thanks to TripleO CI team for their help. --John

[3] https://review.opendev.org/#/c/655923/

> [1] https://etherpad.openstack.org/p/tripleo-integration-squad-status
> [2] https://etherpad.openstack.org/p/ruckroversprint9


From soulxu at gmail.com  Mon Apr 29 03:52:25 2019
From: soulxu at gmail.com (Alex Xu)
Date: Sun, 28 Apr 2019 21:52:25 -0600
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <1CC272501B5BC543A05DB90AA509DED5275531E5@fmsmsx122.amr.corp.intel.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <1CC272501B5BC543A05DB90AA509DED5275531E5@fmsmsx122.amr.corp.intel.com>
Message-ID: <CAH7mGav=hT_YNuYz=x6Db_RT57ByB-e-6WHs_6m2h8RkXZZ9HQ@mail.gmail.com>

Nadathur, Sundar <sundar.nadathur at intel.com> 于2019年4月27日周六 下午12:29写道：

> Hi Jay and Alex,
>     Thanks for the response. Please see below.
>
> Regards,
> Sundar
>
> > -----Original Message-----
> > From: Jay Pipes <jaypipes at gmail.com>
> > Sent: Saturday, April 27, 2019 8:52 AM
> > To: openstack-discuss at lists.openstack.org
> > Subject: Re: [placement][nova][ptg] resource provider affinity
> >
> > On 04/26/2019 08:49 PM, Alex Xu wrote:
> > > Nadathur, Sundar <sundar.nadathur at intel.com
> > >     Anyways, for Cyborg, it seems to me that there is a fairly
> > >     straightforward scheme to address NUMA affinity: annotate the
> > >     device’s nested RP with a trait indicating which NUMA node it
> > >     belongs to (e.g. CUSTOM_NUMA_NODE_0), and use that to guide
> > >     scheduling. This should be a valid use of traits because it
> > >     expresses a property of the resource provider and is used for
> > >     scheduling (only).
> > >
> > >
> > > I don't like the way of using trait to mark out the NUMA node.
> >
> > Me neither. Traits are capabilities, not indicators of the relationship
> between
> > one provider and another.
> >
> > The structure of hierarchical resource providers is what provides
> topology
> > information -- i.e. about how providers are related to each other within
> a tree
> > organization, and this is what is appropriate for encoding NUMA topology
> > information into placement.
> >
> > The request should never ask for "NUMA Node 0". The reason is because the
> > request shouldn't require that the user understand where the resources
> are.
>
> I agree with this for most use cases. However, there are specific cases
> where a reference architecture is laid out for a specific workload, which
> requires a specific number of VMs to be placed in each NUMA node, with
> specific number of devices (NICs or accelerators) assigned to them. The
> network bandwidth, computation load, etc. are all pre-calculated to fit the
> VM's size and device characteristics. Any departure from that may affect
> workload performance -- throughput, latency or jitter. However, if the
> request says, 'Give me a VM on _a_ NUMA node, I don't care which one', one
> may wind up with say 3 VMs on one NUMA node and 1 VM on the other, which is
> not the intended outcome.
>

We can control the number of available shared/dedicated vCPUs in a NUMA
node, so people will know how many VMs in each NUMA node. If you affinity
multiple VM into same NUMA node, that will be another thing, the affinity
between VM.


>
> One could argue that we should model all resources, such as PCIe
> lanes/bandwidth from a socket (not the same as NUMA node), to the point
> where we can influence the exact placement among NUMA nodes. This has
> several issues, IMHO:
> * This is more tied to the hardware details.
> * Many of these resources are not dedicated or partitionable among VMs,
> e.g. PCIe lanes. I don’t see how we can track and count them in Placement
> on per-VM basis.
> * It is more complex for both developers and operators.
>

I don't think that is the purpose of modeling socket in the placement.


> In this situation, the operator is willing (in my understanding) to phrase
> the request precisely to get the exact desired layout.
>
> > It shouldn't matter *which* NUMA node a particular device that is
> providing
> > some resources is affined to. The only thing that matters to a
> > *request* is that the user is able to describe the nature of the
> affinity.
> >
> > I propose using a "group_policy=same_tree:$GROUP_A:$GROUP_B" query
> > parameter for enabling users to describe the affinity constraints for
> various
> > resources involved in different RequestGroups in the request spec.
> >
> > group_policy=same_tree:$A:$B would mean "ensure that the providers that
> > match the constraints of request group $B are in the same inclusive tree
> that
> > matched for request group $A"
>
> Request groups from Neutron and Cyborg do not have any inherent group
> numbers; Nova assigns those group numbers before submission to Placement.
> So, the GET /a-c call could technically have such numbers, but how would
> Neutron or Cyborg express that affinity?
>

Yea, that is what I'm saying, it should be in the nova flavor.


>
> > So, let's say you have a flavor that will consume:
> >
> >   2 dedicated host CPU processors
> >   4GB RAM
> >   1 context/handle for an accelerator running a crypto algorithm
> >
> > Further, you want to ensure that the provider tree that is providing
> those
> > dedicated CPUs and RAM will also provide the accelerator context
> > -- in other words, you are requesting a low level of latency between the
> > memory and the accelerator device itself.
> >
> > The above request to GET /a_c would look like this:
> >
> >   GET /a_c?
> >     resources1=PCPU:2&
> >     resources1=MEMORY_MB=4096&
> >     resources2=ACCELERATOR_CONTEXT&
> >     required2=CUSTOM_BITSTREAM_CRYPTO_4AC1&
> >     group_policy=same_tree:1:2
> >
> > which would mean, in English, "get me an accelerator context from an FPGA
> > that has been flashed with the 4AC1 crypto bitstream and is affined to
> the
> > NUMA node that is providing 4G of main memory and 2 dedicated host
> > processors".
> >
> > Best,
> > -jay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190428/52d6f614/attachment.html>

From cdent+os at anticdent.org  Mon Apr 29 04:07:19 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Sun, 28 Apr 2019 22:07:19 -0600 (MDT)
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
Message-ID: <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>

On Sun, 28 Apr 2019, Eric Fried wrote:

> We've talked about this previously. The two objections raised were:
>
> a) It assumes the meaning of "same tree" is "one level down from the
> root".

Does it? I had casually interpreted
"group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is
somewhere within the tree rooted at $GROUP_A at any level' but it
could just as easily be interpreted a few different ways, including
what you say.

> b) It assumes the various pieces of the request (flavor, image, port,
> device profile) are able to know each others' request group numbers
> ahead of time. Or we need provide some other mechanism for the scheduler
> code that dynamically assigns the numbers [2] to understand which ones
> need to be (sub)grouped together. IIUC this has been Sundar's main
> objection.

As I understand things, this is going to be a problem in most of the
proposals, for at least one of the many participants in the
interactions that lead to a complex workload landing.

Jay suggested extending the JSON schema to allow groups that are
names like resources_compute, required_network. That might allow for
some conventions to emerge but still requires some measure of
knowledge from the participants.

I suspect some form of knowledge is going to be needed. Limiting it
would be good.

Also good is making sure that from placement's standpoint the
knowledge is merely symbolic.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From sundar.nadathur at intel.com  Mon Apr 29 04:56:00 2019
From: sundar.nadathur at intel.com (Nadathur, Sundar)
Date: Mon, 29 Apr 2019 04:56:00 +0000
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
Message-ID: <1CC272501B5BC543A05DB90AA509DED5275534DA@fmsmsx122.amr.corp.intel.com>

Hi Chris,
    Hope you saw my email in this thread on Sat. 

Using group numbers is not good because [1]:
* Request groups from Neutron for bw provider and from Cyborg device profiles will not have explicit group numbers.
* Neutron/Cyborg devices should be affined with VCPU/memory, but we shouldn't assume the number of the RG that asks for VCPU/memory.
* When those request groups are merged with those from the flavor, the flavor group numbering *could* change. To avoid that, Nova would have to make an explicit guarantee that the Neutron/Cyborg groups get added after the flavor RGs. I am not advocating this.

Also, we need some solution for directed affinitizing of specific number of VMs with NUMA nodes, as mentioned in my earlier email.

[1] Taken from my comment on https://review.opendev.org/#/c/650476/ 

Regards,
Sundar

> -----Original Message-----
> From: Chris Dent <cdent+os at anticdent.org>
> Sent: Sunday, April 28, 2019 10:07 PM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: [placement][nova][ptg] resource provider affinity
> 
> On Sun, 28 Apr 2019, Eric Fried wrote:
> 
> > We've talked about this previously. The two objections raised were:
> >
> > a) It assumes the meaning of "same tree" is "one level down from the
> > root".
> 
> Does it? I had casually interpreted
> "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is
> somewhere within the tree rooted at $GROUP_A at any level' but it could just
> as easily be interpreted a few different ways, including what you say.
> 
> > b) It assumes the various pieces of the request (flavor, image, port,
> > device profile) are able to know each others' request group numbers
> > ahead of time. Or we need provide some other mechanism for the
> > scheduler code that dynamically assigns the numbers [2] to understand
> > which ones need to be (sub)grouped together. IIUC this has been
> > Sundar's main objection.
> 
> As I understand things, this is going to be a problem in most of the proposals,
> for at least one of the many participants in the interactions that lead to a
> complex workload landing.
> 
> Jay suggested extending the JSON schema to allow groups that are names like
> resources_compute, required_network. That might allow for some
> conventions to emerge but still requires some measure of knowledge from the
> participants.
> 
> I suspect some form of knowledge is going to be needed. Limiting it would be
> good.
> 
> Also good is making sure that from placement's standpoint the knowledge is
> merely symbolic.
> 
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent

From soulxu at gmail.com  Mon Apr 29 05:02:57 2019
From: soulxu at gmail.com (Alex Xu)
Date: Sun, 28 Apr 2019 23:02:57 -0600
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
Message-ID: <CAH7mGatCkNTQ8Tvg6fb2H7K56VKR1f5kb-=kZAXOApjDyTi4VQ@mail.gmail.com>

Chris Dent <cdent+os at anticdent.org> 于2019年4月28日周日 下午10:14写道：

> On Sun, 28 Apr 2019, Eric Fried wrote:
>
> > We've talked about this previously. The two objections raised were:
> >
> > a) It assumes the meaning of "same tree" is "one level down from the
> > root".
>
> Does it? I had casually interpreted
> "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is
> somewhere within the tree rooted at $GROUP_A at any level' but it
> could just as easily be interpreted a few different ways, including
> what you say.
>
> > b) It assumes the various pieces of the request (flavor, image, port,
> > device profile) are able to know each others' request group numbers
> > ahead of time. Or we need provide some other mechanism for the scheduler
> > code that dynamically assigns the numbers [2] to understand which ones
> > need to be (sub)grouped together. IIUC this has been Sundar's main
> > objection.
>
> As I understand things, this is going to be a problem in most of the
> proposals, for at least one of the many participants in the
> interactions that lead to a complex workload landing.
>
> Jay suggested extending the JSON schema to allow groups that are
> names like resources_compute, required_network. That might allow for
> some conventions to emerge but still requires some measure of
> knowledge from the participants.
>

I thought the placement, cyborg, and neutron..etc doesn't what is building.
Placement doesn't know what it is building from 'GET /a_c', it just return
the right RP match the request. Cyborg and neutron only returns a device or
a port requirement. So only Nova knows we are building VM, then nova should
know the affinity of those resources.


>
> I suspect some form of knowledge is going to be needed. Limiting it
> would be good.
>
> Also good is making sure that from placement's standpoint the
> knowledge is merely symbolic.
>
> --
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190428/d1bd0882/attachment-0001.html>

From isanjayk5 at gmail.com  Mon Apr 29 09:18:20 2019
From: isanjayk5 at gmail.com (Sanjay K)
Date: Mon, 29 Apr 2019 14:48:20 +0530
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack stein
 setup
Message-ID: <CABq8x-vEmN4zcUQ7DTfXY7d5ctZ2QeaLZwHhPQNsQd6GXTJegA@mail.gmail.com>

Hi all,
I have been trying to setup Masakari in a 3 node setup - 1 controller + 2
computes with minimal openstack services installed using devstack
stable/stein version. All these 3 nodes are Ubuntu 16.04 VMs. I have
included Masakari plugin in controller's local.conf file and included
masakari-monitor in both compute node's local.conf file. I want to test out
VM/process failure in my test environment. To do so, when I kill one of the
qemu process created for one instance (cirros 256 flavor VMs) on one of the
compute with root user login, I did not see any notification under my
horizon/instance-ha section for this (I have already created Segments,
Hosts under instance-ha in horizon). Also the killed process is not
restarted by Masakari.

I have asked the same question in openstack forum, but not got a single
response.

masakari-notification-on-process-failure
<https://ask.openstack.org/en/question/121490/masakari-notification-on-process-failure/>

Whether any additional services related to Masakari need to be configured
on compute hosts to detect failures since I did not find exactly the
documentation related inside devstack for this.

Please let me know if I am missing anything my set up. Any helps and
pointers are most appreciated.

thank you for your reply.

best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/36823916/attachment.html>

From aaronzhu1121 at gmail.com  Mon Apr 29 11:47:25 2019
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Mon, 29 Apr 2019 19:47:25 +0800
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CABURL_ndQ318-nOvgtLcqnjdckOtAK1c2zNHWN9NRoFvuoL4mg@mail.gmail.com>
References: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
 <CAOHrpwGRjb_3fMONsuS-vFs98SARLcMp=G28LPKzmzB4fjV-tA@mail.gmail.com>
 <CAEvYov3wpSeR90eZxxhM7PqXcHXuLQqTOCu3_Hhxm+i2-w8GrA@mail.gmail.com>
 <C84F43F3-0E68-49A2-961D-3B22C8E23E8D@mirantis.com>
 <CABURL_ndQ318-nOvgtLcqnjdckOtAK1c2zNHWN9NRoFvuoL4mg@mail.gmail.com>
Message-ID: <CAN2nDNtFpvvxkehK1nfCx_SAvv5zzZ6AiC82TT1h_jVinhMr6g@mail.gmail.com>

Hi there,

Recently we found we lost a person's data from our company at the
stackalytics website.
You can check the merged patch from [0], but there no date from
the stackalytics website.

stackalytics info as below:
Company: ZTE Corporation
Launchpad: 578043796-b
Gerrit: gengchc2

Look forward to hearing from you!

[0]: https://review.opendev.org/#/q/owner:gengchc2,n,z



On Fri, Apr 19, 2019 at 12:16 PM Sergey Nikitin <snikitin at mirantis.com>
wrote:

> Hello everyone,
>
> Yesterday we've finished stackalytics migration.
> Thank you for patience and for notifications about the problem. Now all
> stats must be accurate.
>
> We are working hard to keep stackalytics.com a trusted storage of
> OpenStack statistics.
> So if you will find some problems with data again, please tell as and we
> will fix it ASAP.
>
> Sergey
>
> On Wed, Apr 17, 2019 at 7:37 AM Edward Ionel <eionel at mirantis.com> wrote:
>
>> Hello All,
>>
>>
>> I first want to thank each and everyone of you for reaching out
>> and sharing the inaccuracies you all have found within Stackalytics, this
>> has helped us tremendously with the efforts to correct these flaws.
>>
>>
>> I am writing this email to directly address each individual that has
>> reached out and shared their concerns with our Stackalytics data.
>>
>>
>> Mark Goddard
>>
>> Michael Johnson
>>
>> Julia Kreger
>>
>> Collen Murphy
>>
>> Clark Boylan
>>
>> Sean Mooney
>>
>> Thierry Carrez
>>
>> Jermey Stanley
>>
>> Arkady Kanvesky
>>
>> (Hopefully, I did not miss anyone)
>>
>>
>> I want to insure everyone that the team is working hard
>> to fix the inaccuracies in some of our data. We are still very much
>> involved in OpenStack and we do read each and
>> every message regarding Stackalytics.
>>
>>
>> As Boris and Sergey mentioned, we found that this occurred due to an
>> outdated production environment. We are currently in
>> the progress of migrating to a new environment, and the data should
>> be corrected.
>>
>>
>> The team and I are sorry for these discrepancies and appreciate you all
>> for bringing this to our attention.
>>
>> Thank you all, for providing links and examples of the inaccuracies. This
>> has helped our efforts greatly in correcting the current issues. It would
>> be great if
>> the community can continue reviewing Stackalytics data and help us provide a better service
>> to all.
>>
>>
>>
>> Once again, we are all very sorry for this and will continue to fix these
>> issues.
>>
>>
>> Cheers,
>>
>> Edward
>>
>> On Apr 16, 2019, at 4:05 PM, Edward Ionel <eionel at mirantis.com> wrote:
>>
>>
>>
>> On Tue, Apr 16, 2019 at 2:56 PM Boris Renski <brenski at mirantis.com>
>> wrote:
>>
>>> Folks - more specifically, we plan to roll out an update by tomorrow
>>> mid-day PT which should fix all the numbers + add aggregate details on
>>> Airship project contributions.
>>>
>>> Would really appreciate the help of the community to poke around
>>> tomorrow afternoon and see if there are still discrepancies.
>>>
>>> Sorry about this and thank you for catching it and brining it to our
>>> attention.
>>>
>>> -Boris
>>>
>>> On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin at mirantis.com>
>>> wrote:
>>>
>>>> Hello everyone,
>>>> As you mentioned there are some inaccuracies in stats on
>>>> stackalytics.com. It happened because of outdated Prod env. At this
>>>> moment we are in a process of migration to the new env. All data on this
>>>> env is fresh and accurate. So the problem will be solved soon.
>>>>
>>>> --
>>>> Best Regards,
>>>> Sergey Nikitin
>>>>
>>>
>>
>> --
>>
>> Edward Ionel
>>
>> Marketing Operations Manager
>>
>> Mirantis, Inc.
>>
>> 900 E Hamilton Ave, Suite 650
>>
>> Campbell, CA 95008
>>
>> Eionel at mirantis.com
>>
>> www.mirantis.com
>>
>>
>
> --
> Best Regards,
> Sergey Nikitin
>


-- 
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/b81f45fe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mirantis-logo-2color-rgb-transparent.png
Type: image/png
Size: 31598 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/b81f45fe/attachment-0001.png>

From snikitin at mirantis.com  Mon Apr 29 11:57:02 2019
From: snikitin at mirantis.com (Sergey Nikitin)
Date: Mon, 29 Apr 2019 15:57:02 +0400
Subject: [stackalytics] Reported numbers seem inaccurate
In-Reply-To: <CAN2nDNtFpvvxkehK1nfCx_SAvv5zzZ6AiC82TT1h_jVinhMr6g@mail.gmail.com>
References: <CABURL_=Adwkk+OzA8Cv+DsvcAuza1xka3dpDjCLM9qy61W+jDA@mail.gmail.com>
 <CAOHrpwGRjb_3fMONsuS-vFs98SARLcMp=G28LPKzmzB4fjV-tA@mail.gmail.com>
 <CAEvYov3wpSeR90eZxxhM7PqXcHXuLQqTOCu3_Hhxm+i2-w8GrA@mail.gmail.com>
 <C84F43F3-0E68-49A2-961D-3B22C8E23E8D@mirantis.com>
 <CABURL_ndQ318-nOvgtLcqnjdckOtAK1c2zNHWN9NRoFvuoL4mg@mail.gmail.com>
 <CAN2nDNtFpvvxkehK1nfCx_SAvv5zzZ6AiC82TT1h_jVinhMr6g@mail.gmail.com>
Message-ID: <CABURL_=HUsRfdtARNP_Ky_TRQaHCfswwfZRj1=3jOs7YXsbEXw@mail.gmail.com>

Thank you for information! I will take a look

On Mon, Apr 29, 2019 at 3:47 PM Rong Zhu <aaronzhu1121 at gmail.com> wrote:

> Hi there,
>
> Recently we found we lost a person's data from our company at the
> stackalytics website.
> You can check the merged patch from [0], but there no date from
> the stackalytics website.
>
> stackalytics info as below:
> Company: ZTE Corporation
> Launchpad: 578043796-b
> Gerrit: gengchc2
>
> Look forward to hearing from you!
>
> [0]: https://review.opendev.org/#/q/owner:gengchc2,n,z
>
>
>
> On Fri, Apr 19, 2019 at 12:16 PM Sergey Nikitin <snikitin at mirantis.com>
> wrote:
>
>> Hello everyone,
>>
>> Yesterday we've finished stackalytics migration.
>> Thank you for patience and for notifications about the problem. Now all
>> stats must be accurate.
>>
>> We are working hard to keep stackalytics.com a trusted storage of
>> OpenStack statistics.
>> So if you will find some problems with data again, please tell as and we
>> will fix it ASAP.
>>
>> Sergey
>>
>> On Wed, Apr 17, 2019 at 7:37 AM Edward Ionel <eionel at mirantis.com> wrote:
>>
>>> Hello All,
>>>
>>>
>>> I first want to thank each and everyone of you for reaching out
>>> and sharing the inaccuracies you all have found within Stackalytics, this
>>> has helped us tremendously with the efforts to correct these flaws.
>>>
>>>
>>> I am writing this email to directly address each individual that has
>>> reached out and shared their concerns with our Stackalytics data.
>>>
>>>
>>> Mark Goddard
>>>
>>> Michael Johnson
>>>
>>> Julia Kreger
>>>
>>> Collen Murphy
>>>
>>> Clark Boylan
>>>
>>> Sean Mooney
>>>
>>> Thierry Carrez
>>>
>>> Jermey Stanley
>>>
>>> Arkady Kanvesky
>>>
>>> (Hopefully, I did not miss anyone)
>>>
>>>
>>> I want to insure everyone that the team is working hard
>>> to fix the inaccuracies in some of our data. We are still very much
>>> involved in OpenStack and we do read each and
>>> every message regarding Stackalytics.
>>>
>>>
>>> As Boris and Sergey mentioned, we found that this occurred due to an
>>> outdated production environment. We are currently in
>>> the progress of migrating to a new environment, and the data should
>>> be corrected.
>>>
>>>
>>> The team and I are sorry for these discrepancies and appreciate you all
>>> for bringing this to our attention.
>>>
>>> Thank you all, for providing links and examples of
>>> the inaccuracies. This has helped our efforts greatly in correcting the
>>> current issues. It would be great if
>>> the community can continue reviewing Stackalytics data and help us provide a better service
>>> to all.
>>>
>>>
>>>
>>> Once again, we are all very sorry for this and will continue to fix
>>> these issues.
>>>
>>>
>>> Cheers,
>>>
>>> Edward
>>>
>>> On Apr 16, 2019, at 4:05 PM, Edward Ionel <eionel at mirantis.com> wrote:
>>>
>>>
>>>
>>> On Tue, Apr 16, 2019 at 2:56 PM Boris Renski <brenski at mirantis.com>
>>> wrote:
>>>
>>>> Folks - more specifically, we plan to roll out an update by tomorrow
>>>> mid-day PT which should fix all the numbers + add aggregate details on
>>>> Airship project contributions.
>>>>
>>>> Would really appreciate the help of the community to poke around
>>>> tomorrow afternoon and see if there are still discrepancies.
>>>>
>>>> Sorry about this and thank you for catching it and brining it to our
>>>> attention.
>>>>
>>>> -Boris
>>>>
>>>> On Tue, Apr 16, 2019 at 1:33 PM Sergey Nikitin <snikitin at mirantis.com>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>> As you mentioned there are some inaccuracies in stats on
>>>>> stackalytics.com. It happened because of outdated Prod env. At this
>>>>> moment we are in a process of migration to the new env. All data on this
>>>>> env is fresh and accurate. So the problem will be solved soon.
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>> Sergey Nikitin
>>>>>
>>>>
>>>
>>> --
>>>
>>> Edward Ionel
>>>
>>> Marketing Operations Manager
>>>
>>> Mirantis, Inc.
>>>
>>> 900 E Hamilton Ave, Suite 650
>>>
>>> Campbell, CA 95008
>>>
>>> Eionel at mirantis.com
>>>
>>> www.mirantis.com
>>>
>>>
>>
>> --
>> Best Regards,
>> Sergey Nikitin
>>
>
>
> --
> Thanks,
> Rong Zhu
>


-- 
Best Regards,
Sergey Nikitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/f5de0c6f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mirantis-logo-2color-rgb-transparent.png
Type: image/png
Size: 31598 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/f5de0c6f/attachment-0001.png>

From koteswara.kelam at hpe.com  Mon Apr 29 12:33:49 2019
From: koteswara.kelam at hpe.com (Kelam, Koteswara Rao)
Date: Mon, 29 Apr 2019 12:33:49 +0000
Subject: ["Neutron"] Create subnet gives ERROR "Body contains invalid data"
Message-ID: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>

Tried to create a subnet with following curl command
$ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $AUTH_TOKEN" -d '{'subnet': {'name': '8c7993a8-905e-4ad4-be3b-11c692e38317', 'network_id': '8f5f7cff-a320-40ba-9903-0c4e6dd80c0c', 'ip_version': 4, 'cidr': '169.254.3.1/32', 'enable_dhcp': 'false'}}'

And got following ERROR:

{"NeutronError": {"message": "Body contains invalid data", "type": "HTTPBadRequest", "detail": ""}}

But when I tried with DOUBLE quotes in the body it got succeeded.

$ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $AUTH_TOKEN" -d '{"subnet": {"name": "8c7993a8-905e-4ad4-be3b-11c692e38317", "network_id": "8f5f7cff-a320-40ba-9903-0c4e6dd80c0c", "ip_version": 4, "cidr": "169.254.3.1/32", "enable_dhcp": 'false'}}'

{"subnet":{"description":"","enable_dhcp":false,"tags":[],"network_id":"8f5f7cff-a320-40ba-9903-0c4e6dd80c0c","tenant_id":"39f81bc21a9f4eb7b87586d983b6ec3d","created_at":"2019-04-29T11:56:57Z","segment_id":null,"dns_nameservers":[],"updated_at":"2019-04-29T11:56:57Z","gateway_ip":"169.254.3.2","ipv6_ra_mode":null,"allocation_pools":[{"start":"169.254.3.1","end":"169.254.3.1"}],"host_routes":[],"revision_number":0,"ip_version":4,"ipv6_address_mode":null,"cidr":"169.254.3.1/32","project_id":"39f81bc21a9f4eb7b87586d983b6ec3d","id":"33de75fb-fa10-460a-9123-577ae62a771a","subnetpool_id":null,"name":"8c7993a8-905e-4ad4-be3b-11c692e38317"}}

Single quotes not allowed in requested body? Only double quotes allowed??
Single quotes also used to work for me with older versions on neutron.

-Koteswar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/60c2a042/attachment.html>

From skaplons at redhat.com  Mon Apr 29 13:05:26 2019
From: skaplons at redhat.com (Slawomir Kaplonski)
Date: Mon, 29 Apr 2019 07:05:26 -0600
Subject: ["Neutron"] Create subnet gives ERROR "Body contains invalid data"
In-Reply-To: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
References: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <703436DC-AEA7-4912-B851-7A759BF56048@redhat.com>

Hi,

Can You send also neutron-server log (with debug=True) with error which You have there?

> Wiadomość napisana przez Kelam, Koteswara Rao <koteswara.kelam at hpe.com> w dniu 29.04.2019, o godz. 06:33:
> 
> Tried to create a subnet with following curl command
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $AUTH_TOKEN" -d '{'subnet': {'name': '8c7993a8-905e-4ad4-be3b-11c692e38317', 'network_id': '8f5f7cff-a320-40ba-9903-0c4e6dd80c0c', 'ip_version': 4, 'cidr': '169.254.3.1/32', 'enable_dhcp': 'false'}}'
>  
> And got following ERROR:
>  
> {"NeutronError": {"message": "Body contains invalid data", "type": "HTTPBadRequest", "detail": ""}}
>  
> But when I tried with DOUBLE quotes in the body it got succeeded.
>  
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: $AUTH_TOKEN" -d '{"subnet": {"name": "8c7993a8-905e-4ad4-be3b-11c692e38317", "network_id": "8f5f7cff-a320-40ba-9903-0c4e6dd80c0c", "ip_version": 4, "cidr": "169.254.3.1/32", "enable_dhcp": 'false'}}'
>  
> {"subnet":{"description":"","enable_dhcp":false,"tags":[],"network_id":"8f5f7cff-a320-40ba-9903-0c4e6dd80c0c","tenant_id":"39f81bc21a9f4eb7b87586d983b6ec3d","created_at":"2019-04-29T11:56:57Z","segment_id":null,"dns_nameservers":[],"updated_at":"2019-04-29T11:56:57Z","gateway_ip":"169.254.3.2","ipv6_ra_mode":null,"allocation_pools":[{"start":"169.254.3.1","end":"169.254.3.1"}],"host_routes":[],"revision_number":0,"ip_version":4,"ipv6_address_mode":null,"cidr":"169.254.3.1/32","project_id":"39f81bc21a9f4eb7b87586d983b6ec3d","id":"33de75fb-fa10-460a-9123-577ae62a771a","subnetpool_id":null,"name":"8c7993a8-905e-4ad4-be3b-11c692e38317"}}
>  
> Single quotes not allowed in requested body? Only double quotes allowed??
> Single quotes also used to work for me with older versions on neutron.
>  
> -Koteswar

— 
Slawek Kaplonski
Senior software engineer
Red Hat



From bodenvmw at gmail.com  Mon Apr 29 13:11:31 2019
From: bodenvmw at gmail.com (Boden Russell)
Date: Mon, 29 Apr 2019 07:11:31 -0600
Subject: [neutron] Bug deputy report April 22 - 28
Message-ID: <80b5fda0-df77-04a0-2a16-07b726d996ba@gmail.com>

Below is a summary of bugs from last week.
Based on the rotation list [1], Nate is up this week.
Thanks


Confirmed/In-Progress:
- https://bugs.launchpad.net/neutron/+bug/1826726 [L3] stale
device/process remain in network node after router removed
- https://bugs.launchpad.net/neutron/+bug/1826695 [L3][QoS] cache does
not removed when router is down or deleted
- https://bugs.launchpad.net/neutron/+bug/1826570 Error in
"tc_lib._handle_from_hex_to_string" formatting
- https://bugs.launchpad.net/neutron/+bug/1826565
"tc_lib.add_tc_policy_class" must always assign a default value to
"min_kbps"
- https://bugs.launchpad.net/neutron/+bug/1826480  High latency on
delete_subnets with increasing load and concurrency
- https://bugs.launchpad.net/neutron/+bug/1825787  [L3][HA] agent HA
router count should not include dvr local router

Under investigation:
- https://bugs.launchpad.net/neutron/+bug/1826644 ha router goes to
standby mode only when they are created by heat
- https://bugs.launchpad.net/neutron/+bug/1826419  dhcp agent configured
with mismatching domain and host entries

Incomplete:
- https://bugs.launchpad.net/neutron/+bug/1826066 Iptables rules for
unbound ports removed during agent sync

RFE:
- https://bugs.launchpad.net/neutron/+bug/1826396  [RFE] Atomic
Extraroute API
- https://bugs.launchpad.net/neutron/+bug/1825943  [RFE] Implement "stop
agent" hook script support in Neutron


[1] https://wiki.openstack.org/wiki/Network/Meetings


From jaypipes at gmail.com  Mon Apr 29 13:29:06 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 29 Apr 2019 09:29:06 -0400
Subject: ["Neutron"] Create subnet gives ERROR "Body contains invalid data"
In-Reply-To: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
References: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <173df60f-85a5-b065-ad87-672b955e0efb@gmail.com>

Single quotes are not valid JSON delimiters for string elements.

http://www.json.org/

"A string is a sequence of zero or more Unicode characters, wrapped in 
double quotes, using backslash escapes. A character is represented as a 
single character string. A string is very much like a C or Java string."

My guess is that when you were previously working with Neutron using 
single quotes, you were running your payload through something that was 
correcting the single quotes to double quotes.

Best,
-jay

On 04/29/2019 08:33 AM, Kelam, Koteswara Rao wrote:
> Tried to create a subnet with following curl command
> 
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: 
> application/json" -H "Accept: application/json" -H "X-Auth-Token: 
> $AUTH_TOKEN" -d '{'subnet': {'name': 
> '8c7993a8-905e-4ad4-be3b-11c692e38317', 'network_id': 
> '8f5f7cff-a320-40ba-9903-0c4e6dd80c0c', 'ip_version': 4, 'cidr': 
> '169.254.3.1/32', 'enable_dhcp': 'false'}}'
> 
> And got following ERROR:
> 
> {"NeutronError": {"message": "Body contains invalid data", "type": 
> "HTTPBadRequest", "detail": ""}}
> 
> But when I tried with DOUBLE quotes in the body it got succeeded.
> 
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type: 
> application/json" -H "Accept: application/json" -H "X-Auth-Token: 
> $AUTH_TOKEN" -d '{"subnet": {"name": 
> "8c7993a8-905e-4ad4-be3b-11c692e38317", "network_id": 
> "8f5f7cff-a320-40ba-9903-0c4e6dd80c0c", "ip_version": 4, "cidr": 
> "169.254.3.1/32", "enable_dhcp": 'false'}}'
> 
> {"subnet":{"description":"","enable_dhcp":false,"tags":[],"network_id":"8f5f7cff-a320-40ba-9903-0c4e6dd80c0c","tenant_id":"39f81bc21a9f4eb7b87586d983b6ec3d","created_at":"2019-04-29T11:56:57Z","segment_id":null,"dns_nameservers":[],"updated_at":"2019-04-29T11:56:57Z","gateway_ip":"169.254.3.2","ipv6_ra_mode":null,"allocation_pools":[{"start":"169.254.3.1","end":"169.254.3.1"}],"host_routes":[],"revision_number":0,"ip_version":4,"ipv6_address_mode":null,"cidr":"169.254.3.1/32","project_id":"39f81bc21a9f4eb7b87586d983b6ec3d","id":"33de75fb-fa10-460a-9123-577ae62a771a","subnetpool_id":null,"name":"8c7993a8-905e-4ad4-be3b-11c692e38317"}}
> 
> Single quotes not allowed in requested body? Only double quotes allowed??
> 
> Single quotes also used to work for me with older versions on neutron.
> 
> -Koteswar
> 


From jaypipes at gmail.com  Mon Apr 29 13:30:46 2019
From: jaypipes at gmail.com (Jay Pipes)
Date: Mon, 29 Apr 2019 09:30:46 -0400
Subject: [placement][ptg] Aggregate on root spans whole tree policy:
In-Reply-To: <alpine.OSX.2.21.1904281714570.5457@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091357460.93787@cdent-a01.vmware.com>
 <31cb2640-2471-8027-a15d-fe1aa452fa42@gmail.com>
 <alpine.OSX.2.21.1904281714570.5457@cdent-a01.vmware.com>
Message-ID: <f33fe485-c903-6c9f-39f9-cb2c681371e4@gmail.com>

On 04/28/2019 07:18 PM, Chris Dent wrote:
> On Sun, 21 Apr 2019, Jay Pipes wrote:
>> In other words, the algorithm for matching allocation candidates 
>> should do the following in order for each request group:
>>
>> 1) Find the provider IDs having capacity for the resources contained 
>> in the request group
>> 2) If there is a member_of constraint in this request group, reduce 
>> the matched set to only those providers that are associated (or have 
>> any children associated) with the aggregates listed in the member_of 
>> constraint
>> 3) If there is a required trait constraint in this request group, 
>> reduce the matched set to only those providers that have the required 
>> trait(s) or where their children have the required traits
>> 4) If there is a forbidden trait constraint in this request group, 
>> remove from the matched set any providers that have the forbidden 
>> trait(s) or where their children have the forbidden traits
> 
> Is this the same as or sort of the opposite of the "traits flow down" or
> "everything is spanning" ideas discussed near
> 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.html 

It represents the same idea as "traits flow down".

Best,
-jay


From whayutin at redhat.com  Mon Apr 29 13:52:45 2019
From: whayutin at redhat.com (Wesley Hayutin)
Date: Mon, 29 Apr 2019 07:52:45 -0600
Subject: [tripleo] default ceph migrating from luminous to nautilus
In-Reply-To: <CAE66OMAd3fEfmsZERk=HqgQVKqvNKva3q08y6F+YfjdYkwVB7Q@mail.gmail.com>
References: <CAE66OMDOxZeS3KynnG_wwB06QLBDq8O8f5WwnYf589AhmY08HA@mail.gmail.com>
 <CAE66OMAd3fEfmsZERk=HqgQVKqvNKva3q08y6F+YfjdYkwVB7Q@mail.gmail.com>
Message-ID: <CAOHJT4+6=DbE1HDvWiAuFXFuYGUX9ON+=ekyG6YNEFej62C=5A@mail.gmail.com>

On Sun, Apr 28, 2019 at 7:51 PM John Fulton <johfulto at redhat.com> wrote:

> On Wed, Apr 24, 2019 at 3:09 PM John Fulton <johfulto at redhat.com> wrote:
> >
> > We're going to be making some updates in TripleO and RDO so that the
> > default version of Ceph in Stein is Nautilus. Part of this involves
> > temporarily disabling the standalone 001/004 jobs. Our reviews are
> > lined up and linked with additional details on the TripleO Integration
> > Squad etherpad [1]. We'll be waiting until the 3rd party checks are
> > green [2] before we start merging.
>
> This has been completed and standalone 001/004 jobs should now be
> voting again [3]. Thanks to TripleO CI team for their help. --John
>
> [3] https://review.opendev.org/#/c/655923/


Thanks John, Giulio, Yatin for making so easy to knock out and merge
quickly!


>
>
> > [1] https://etherpad.openstack.org/p/tripleo-integration-squad-status
> > [2] https://etherpad.openstack.org/p/ruckroversprint9
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/a3c4dcbe/attachment.html>

From nate.johnston at redhat.com  Mon Apr 29 14:14:38 2019
From: nate.johnston at redhat.com (Nate Johnston)
Date: Mon, 29 Apr 2019 10:14:38 -0400
Subject: [neutron] Bug deputy report April 22 - 28
In-Reply-To: <80b5fda0-df77-04a0-2a16-07b726d996ba@gmail.com>
References: <80b5fda0-df77-04a0-2a16-07b726d996ba@gmail.com>
Message-ID: <20190429141438.zgf3oyqaftfropnh@bishop>

On Mon, Apr 29, 2019 at 07:11:31AM -0600, Boden Russell wrote:
> Below is a summary of bugs from last week.
> Based on the rotation list [1], Nate is up this week.

Thanks Boden, I'm on deck.

Nate


From massimo.sgaravatto at gmail.com  Mon Apr 29 14:43:08 2019
From: massimo.sgaravatto at gmail.com (Massimo Sgaravatto)
Date: Mon, 29 Apr 2019 16:43:08 +0200
Subject: [glance] [ops] Issue sharing an image with another project (something
 related to get_image_location)
Message-ID: <CALaZjRE-KtZDZekbuiFeF0GtCRzEDS4q_Yy4qrBgg9F3G9pmiw@mail.gmail.com>

I have a small Rocky installation where Glance is configured with 2
backends (old images use the 'file' backend while new ones use the rbd
backend, which is the default)


show_multiple_locations  is true but I have these settings in policy.json:

# grep _image_location /etc/glance/policy.json
    "delete_image_location": "role:admin",
    "get_image_location": "role:admin",
    "set_image_location": "role:admin",

This was done because of:
https://wiki.openstack.org/wiki/OSSN/OSSN-0065


If an unpriv user tries to share a private image:

$ openstack image add project 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6
e81df4c0b493439abb8b85bfd4cbe071
403 Forbidden: Not allowed to create members for image
3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6. (HTTP 403)

In the log file it looks like that the problem is related to the
get_image_location operation:

/var/log/glance/api.log:2019-04-29 16:06:54.523 8220 WARNING
glance.api.v2.image_members [req-dd93cdc9-767d-4c51-8e5a-edf746c02264
ab573ba3ea014b778193b6922ffffe6d ee1865a76440481cbcff08544c7d580a - default
default] Not allowed to create members for image
3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6.: Forbidden: You are not authorized to
complete get_image_location action.


But actually the sharing operation succeeded:

$ glance member-list --image-id 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6
+--------------------------------------+----------------------------------+---------+
| Image ID                             | Member ID                        |
Status  |
+--------------------------------------+----------------------------------+---------+
| 3194a04b-ffc8-4aaf-b6c8-adc24e3d3fe6 | e81df4c0b493439abb8b85bfd4cbe071 |
pending |
+--------------------------------------+----------------------------------+---------+


Cheers, Massimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/f90f104a/attachment.html>

From ed at leafe.com  Mon Apr 29 17:40:55 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 29 Apr 2019 11:40:55 -0600
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <CAH7mGatCkNTQ8Tvg6fb2H7K56VKR1f5kb-=kZAXOApjDyTi4VQ@mail.gmail.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <CAH7mGatCkNTQ8Tvg6fb2H7K56VKR1f5kb-=kZAXOApjDyTi4VQ@mail.gmail.com>
Message-ID: <66C675A1-785A-40E3-B256-391E8C092472@leafe.com>

On Apr 28, 2019, at 11:02 PM, Alex Xu <soulxu at gmail.com> wrote:
> 
> I thought the placement, cyborg, and neutron..etc doesn't what is building. Placement doesn't know what it is building from 'GET /a_c', it just return the right RP match the request. 

This is an important point that seems to get pushed aside in order to “get feature X done”. 


-- Ed Leafe







From blair.bethwaite at gmail.com  Mon Apr 29 17:50:20 2019
From: blair.bethwaite at gmail.com (Blair Bethwaite)
Date: Mon, 29 Apr 2019 11:50:20 -0600
Subject: [scientific-sig] Denver BoF lightning talks today!
Message-ID: <CA+z5DszNWtZwLbp_urB10cWNWCNUSw94fE-9wUDAy14ewbZeCA@mail.gmail.com>

Hi all,

There's still space available for extra lightning talks in the Scientific
SIG BoF today, so if you've a quick story to tell please add your name to
the etherpad here:
https://etherpad.openstack.org/p/scientific-sig-denver19-bof

-- 
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/3fe336fa/attachment.html>

From ed at leafe.com  Mon Apr 29 19:48:10 2019
From: ed at leafe.com (Ed Leafe)
Date: Mon, 29 Apr 2019 13:48:10 -0600
Subject: [placement][ptg] Envisioning other technologies
In-Reply-To: <alpine.OSX.2.21.1904091401170.93787@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091401170.93787@cdent-a01.vmware.com>
Message-ID: <54AC00D3-A14F-4C53-BF40-2827E6896ECD@leafe.com>

On Apr 9, 2019, at 7:04 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> 
> * Perhaps we might try some parallel development, where resources
>  are modeled in both relational and graph DBs. Then we might be
>  able to compare the different solutions to complex queries on the
>  same data sets.

Listening today to the problems Nova will be facing getting nested providers, NUMA affinity, shared providers, RP distance, and a few others, it was sad because those issues have already been solved using a graph database instead of a relational database. So rather than continue to preach into the void, I’d like to propose a challenge.

Come up with a scenario involving any of the above concerns that is currently not doable in Nova/Placement, and I will come up with a demo that shows how it can be solved using Neo4j and py2neo. My goal isn’t to show off some cool technology; my goal is to convert those of you who are skeptics about anything that isn’t MySQL into believers. So I need an example case for the demo that if you saw it working in action, would convince you to at least take the idea of a graph database solution for placement seriously. And pointing out potential hurdles, such as Neo4j on OpenJDK, or data migrations, or anything else really isn’t helpful right now. I just want to knock your socks off.

In case you missed this last year, here’s some background.
Link to my original demo: https://blog.leafe.com/placement-graph-examples/
Follow-up post to Jay Pipes’s questions: https://blog.leafe.com/graph-database-follow-up/


-- Ed Leafe







From arbermejo0417 at gmail.com  Mon Apr 29 20:50:35 2019
From: arbermejo0417 at gmail.com (Alejandro Ruiz Bermejo)
Date: Mon, 29 Apr 2019 16:50:35 -0400
Subject: [Zun] deploying zun error at kuryr installation
Message-ID: <CAOJ6YEq18f72XyMyECm7qbuZqRveBDbaxVa+Y1QkWnGxiGMF7w@mail.gmail.com>

Hi i've installed Openstack Queens on Ubuntu 18.04 and i'm following the
Zun Installation Guide to deploy a container infrastructure. I'm following
the steps to install kuryr-libnetwork (I've already installed docker on the
compute node and it's working fine). The kuryr installation process had no
errors but when i try to verify the operation as it's said in the guide

docker network create --driver kuryr --ipam-driver kuryr \
      --subnet 10.10.0.0/16 --gateway=10.10.0.1 test_net

I'm Getting this error
*Error* response from daemon: legacy plugin: Post
http://10.8.9.54:23750/Plugin.Activate: dial tcp 10.8.9.54:23750: connect:
connection refused

I tryed to find the error wit **journalctl -u kuryr-libnetwork

Apr 27 13:11:12 compute systemd[1]: Started Kuryr-libnetwork - Docker
network plugin for Neutron.

Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.273 10736
*WARNING* keystoneauth.identity.generic.base [-] Failed to discover
available identity versions when contacting http://controller:35357.
Attempting to parse version from URL.: ConnectFailure: Unable to establish
connection to  http://controller:35357:
HTTPConnectionPool(host='controller', port=35357):
MTTPConnectionPool(host='controller', port=35357): Max retries exceeded
with url: / (Caused by
NewConnectionError('<urllib3.connection.HTTPConnection object at
0x7fecef1a8090>: Failed to establish a new connection: [Errno 111]
Connection refused',))

Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.274 10736
*CRITICAL* kuryr [-] Unhandled error: DiscoveryFailure: Could not determine
a  suitable URL for the plugin

Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.274 10736
*ERROR* kuryr Traceback (most recent call last):


This is the relevant content of my /etc/kuryr/kuryr.conf

*[DEFAULT]*

bindir = /usr/local/libexec/kuryr

*[neutron]*

www_authenticate_uri = http://controller:5000

auth_url = http://controller:35357

username = kuryr

user_domain_name = default

password = 123

project_name = service

project_domain_name = default

auth_type = password


And this is the one at /usr/lib/docker/plugins/kuryr/kuryr.spec:

http://conrtoller:23750


Btw compute node have connectivity with controller. I already have worked
with the environment and launched kvm VMs on it

Can someone help troubleshoot this error??


*UPDATE1*
I checked open ports on controller node and 23750 isn't open. I followed
the directions at the guide, any recommendation?

Also in the compute node when i run systemctl status kuryr-libnetwork this
is the output

● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for
Neutron
   Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled;
vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2019-04-27 16:06:21 UTC;
2min 39s ago
  Process: 17450 ExecStart=/usr/local/bin/kuryr-server --config-file
/etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE)
 Main PID: 17450 (code=exited, status=1/FAILURE)

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr   File
"/usr/lib/python2.7/dist-packages/keystoneauth1/identity/base.py", line
134, in get_access

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr     self.auth_ref = self.get_auth_ref(session)

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr   File
"/usr/lib/python2.7/dist-packages/keystoneauth1/identity/generic/base.py",
line 199, in get_auth_ref

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr     self._plugin = self._do_create_plugin(session)

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr   File
"/usr/lib/python2.7/dist-packages/keystoneauth1/identity/generic/base.py",
line 194, in _do_create_plugin

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr     raise exceptions.DiscoveryFailure('Could not determine a
suiable URL '

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr DiscoveryFailure: Could not determine a suitable URL for the
plugin

Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
ERROR kuryr

Apr 27 16:06:21 compute systemd[1]: kuryr-libnetwork.service: Main process
exited, code=exited, status=1/FAILURE

Apr 27 16:06:21 compute systemd[1]: kuryr-libnetwork.service: Failed with
result 'exit-code'.

*UPDATE2*

I tried the recommendations given by **hongbin034** and confirm that i had
a problem with Keystone.
when i run openstack token issue after exporting the neutron environment
varibles i get the following output

Failed to discover available identity versions when contacting
http://controller:35357. Attempting to parse version from URL.
Could not determine a suitable URL for the plugin

I checked and the port 35357 isn't even open at the controller node. But at
the controller node installation there isn't any step configuring such port
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/74976b1c/attachment-0001.html>

From corvus at inaugust.com  Mon Apr 29 20:51:01 2019
From: corvus at inaugust.com (James E. Blair)
Date: Mon, 29 Apr 2019 13:51:01 -0700
Subject: Third party CI and Zuul at OpenInfra Summit
Message-ID: <87zho8bkne.fsf@meyer.lemoncheese.net>

Hi,

I'd like to invite any third-party CI operators as well as anyone else
running Zuul or interested in running Zuul to join us in a discussion
about reusing Zuul jobs in a downstream context at the Zuul working
group session on Tuesday:

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23736/zuul-wg-session

-Jim


From jeremyfreudberg at gmail.com  Mon Apr 29 21:19:29 2019
From: jeremyfreudberg at gmail.com (Jeremy Freudberg)
Date: Mon, 29 Apr 2019 17:19:29 -0400
Subject: [sahara][all] Sahara Train Virtual PTG is SCHEDULED
Message-ID: <CAFntmSj-ubVHqmhv9oqS=B50UKc-n8UbWENtnGQcE-9RTX9uxw@mail.gmail.com>

Hi all,

Sahara will have a virtual PTG on Monday, May 6, beginning at 15:00
UTC. Best guess is that it will run two hours. Come and go as you need
to.

The etherpad is here: https://etherpad.openstack.org/p/sahara-train-ptg
Please take a moment to add some topics, and, if you plan to attend, your name.

The session will be hosted by Bluejeans: https://bluejeans.com/6304900378
(Take a moment to make sure your browser and peripherals are configured nicely)

All interested parties are welcome. Outcomes will appear on
openstack-discuss and on the etherpad itself.

Till then,
Jeremy


From stig.openstack at telfer.org  Mon Apr 29 21:38:09 2019
From: stig.openstack at telfer.org (Stig Telfer)
Date: Mon, 29 Apr 2019 15:38:09 -0600
Subject: [scientific-sig] ROOM CHANGE - SIG session at 3:50pm moved to 4E/4F
Message-ID: <3556A0A5-E042-4BD7-9512-2889F10D8F55@telfer.org>

Hi All - 

To get us a projector for our SIG session, we are moving from 507 to 4E/4F 

Sorry for the late notice!

Cheers,
Stig



From openstack at fried.cc  Mon Apr 29 21:38:08 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 29 Apr 2019 16:38:08 -0500
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
Message-ID: <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>

>> a) It assumes the meaning of "same tree" is "one level down from the
>> root".
> 
> Does it? I had casually interpreted
> "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is
> somewhere within the tree rooted at $GROUP_A at any level' but it
> could just as easily be interpreted a few different ways, including
> what you say.

If I interpret that ^ correctly, it would require $GROUP_A (the subtree
root) to provide resources, a scenario for which we have at least one
counterexample (the one with network agents as resourceless providers).

> Jay suggested extending the JSON schema to allow groups that are
> names like resources_compute, required_network. That might allow for
> some conventions to emerge but still requires some measure of
> knowledge from the participants.

I think this is a good idea to pursue, because it gives us a way to
predefine (by convention) what the groups are called, as opposed to
having them be automatically, arbitrarily, unpredictably numbered. It'll
still break down in more complex scenarios where, say, there's more than
one device_group with different affinity requirements; but it could work
for the simpler setups.

> Also good is making sure that from placement's standpoint the
> knowledge is merely symbolic.

Sure. Just like the group numbers, the names would be just as
arbitrary/symbolic as the group numbers are today. And since we're
talking about reporting group_num/resource_provider association, those
symbols need to survive for the duration of the GET /a_c operation, but
no longer than that.

efried
.


From Tushar.Patil at nttdata.com  Mon Apr 29 21:54:52 2019
From: Tushar.Patil at nttdata.com (Patil, Tushar)
Date: Mon, 29 Apr 2019 21:54:52 +0000
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack
 stein setup
In-Reply-To: <CABq8x-vEmN4zcUQ7DTfXY7d5ctZ2QeaLZwHhPQNsQd6GXTJegA@mail.gmail.com>
References: <CABq8x-vEmN4zcUQ7DTfXY7d5ctZ2QeaLZwHhPQNsQd6GXTJegA@mail.gmail.com>
Message-ID: <MN2PR12MB3166BB3DDBFB99D51F40A1D58C390@MN2PR12MB3166.namprd12.prod.outlook.com>

Hi Sanjay,

In case of masakari-processmonitor, it only monitors processes as mentioned in the process_list.yaml which by default monitors libvirt-bin, nova-compute, instancemonitor, hostmonitor and sshd processes.

To test process failure, you should terminate any of the above processes.

In case of instancemonitor, you can shutdown the VM to test whether a notification is sent or not.

>> I have asked the same question in openstack forum, but not got a single response.
Sorry, I didn't notice your question on forum. I have replied above comment on forum as well.

Regards,
Tushar Patil

________________________________________
From: Sanjay K <isanjayk5 at gmail.com>
Sent: Monday, April 29, 2019 6:18:20 PM
To: openstack-discuss at lists.openstack.org
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack stein setup

Hi all,
I have been trying to setup Masakari in a 3 node setup - 1 controller + 2 computes with minimal openstack services installed using devstack stable/stein version. All these 3 nodes are Ubuntu 16.04 VMs. I have included Masakari plugin in controller's local.conf file and included masakari-monitor in both compute node's local.conf file. I want to test out VM/process failure in my test environment. To do so, when I kill one of the qemu process created for one instance (cirros 256 flavor VMs) on one of the compute with root user login, I did not see any notification under my horizon/instance-ha section for this (I have already created Segments, Hosts under instance-ha in horizon). Also the killed process is not restarted by Masakari.

I have asked the same question in openstack forum, but not got a single response.

masakari-notification-on-process-failure<https://ask.openstack.org/en/question/121490/masakari-notification-on-process-failure/>

Whether any additional services related to Masakari need to be configured on compute hosts to detect failures since I did not find exactly the documentation related inside devstack for this.

Please let me know if I am missing anything my set up. Any helps and pointers are most appreciated.

thank you for your reply.

best regards
Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.


From hongbin034 at gmail.com  Mon Apr 29 22:08:54 2019
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Mon, 29 Apr 2019 18:08:54 -0400
Subject: [Zun] deploying zun error at kuryr installation
In-Reply-To: <CAOJ6YEq18f72XyMyECm7qbuZqRveBDbaxVa+Y1QkWnGxiGMF7w@mail.gmail.com>
References: <CAOJ6YEq18f72XyMyECm7qbuZqRveBDbaxVa+Y1QkWnGxiGMF7w@mail.gmail.com>
Message-ID: <CAFNUc+SzX_zhO7oG6=SQdkrZ4mCg1Pn7JrK4HT_VR_iVpFM=_Q@mail.gmail.com>

Hi Alejandro,

Will it work if you change the kuryr config file to use port 5000? If yes,
I will update the kuryr installation guide to use that port.

*[neutron]*

auth_url = http://controller: <http://controller:35357/>5000

Best regards,
Hongbin

On Mon, Apr 29, 2019 at 4:54 PM Alejandro Ruiz Bermejo <
arbermejo0417 at gmail.com> wrote:

> Hi i've installed Openstack Queens on Ubuntu 18.04 and i'm following the
> Zun Installation Guide to deploy a container infrastructure. I'm following
> the steps to install kuryr-libnetwork (I've already installed docker on the
> compute node and it's working fine). The kuryr installation process had no
> errors but when i try to verify the operation as it's said in the guide
>
> docker network create --driver kuryr --ipam-driver kuryr \
>       --subnet 10.10.0.0/16 --gateway=10.10.0.1 test_net
>
> I'm Getting this error
> *Error* response from daemon: legacy plugin: Post
> http://10.8.9.54:23750/Plugin.Activate: dial tcp 10.8.9.54:23750:
> connect: connection refused
>
> I tryed to find the error wit **journalctl -u kuryr-libnetwork
>
> Apr 27 13:11:12 compute systemd[1]: Started Kuryr-libnetwork - Docker
> network plugin for Neutron.
>
> Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.273 10736
> *WARNING* keystoneauth.identity.generic.base [-] Failed to discover
> available identity versions when contacting http://controller:35357.
> Attempting to parse version from URL.: ConnectFailure: Unable to establish
> connection to  http://controller:35357:
> HTTPConnectionPool(host='controller', port=35357):
> MTTPConnectionPool(host='controller', port=35357): Max retries exceeded
> with url: / (Caused by
> NewConnectionError('<urllib3.connection.HTTPConnection object at
> 0x7fecef1a8090>: Failed to establish a new connection: [Errno 111]
> Connection refused',))
>
> Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.274 10736
> *CRITICAL* kuryr [-] Unhandled error: DiscoveryFailure: Could not
> determine a  suitable URL for the plugin
>
> Apr 27 13:11:13 compute kuryr-server[10736]: 2019-04-27 13:11:13.274 10736
> *ERROR* kuryr Traceback (most recent call last):
>
>
> This is the relevant content of my /etc/kuryr/kuryr.conf
>
> *[DEFAULT]*
>
> bindir = /usr/local/libexec/kuryr
>
> *[neutron]*
>
> www_authenticate_uri = http://controller:5000
>
> auth_url = http://controller:35357
>
> username = kuryr
>
> user_domain_name = default
>
> password = 123
>
> project_name = service
>
> project_domain_name = default
>
> auth_type = password
>
>
> And this is the one at /usr/lib/docker/plugins/kuryr/kuryr.spec:
>
> http://conrtoller:23750
>
>
> Btw compute node have connectivity with controller. I already have worked
> with the environment and launched kvm VMs on it
>
> Can someone help troubleshoot this error??
>
>
> *UPDATE1*
> I checked open ports on controller node and 23750 isn't open. I followed
> the directions at the guide, any recommendation?
>
> Also in the compute node when i run systemctl status kuryr-libnetwork this
> is the output
>
> ● kuryr-libnetwork.service - Kuryr-libnetwork - Docker network plugin for
> Neutron
>    Loaded: loaded (/etc/systemd/system/kuryr-libnetwork.service; enabled;
> vendor preset: enabled)
>    Active: failed (Result: exit-code) since Sat 2019-04-27 16:06:21 UTC;
> 2min 39s ago
>   Process: 17450 ExecStart=/usr/local/bin/kuryr-server --config-file
> /etc/kuryr/kuryr.conf (code=exited, status=1/FAILURE)
>  Main PID: 17450 (code=exited, status=1/FAILURE)
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr   File
> "/usr/lib/python2.7/dist-packages/keystoneauth1/identity/base.py", line
> 134, in get_access
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr     self.auth_ref = self.get_auth_ref(session)
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr   File
> "/usr/lib/python2.7/dist-packages/keystoneauth1/identity/generic/base.py",
> line 199, in get_auth_ref
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr     self._plugin = self._do_create_plugin(session)
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr   File
> "/usr/lib/python2.7/dist-packages/keystoneauth1/identity/generic/base.py",
> line 194, in _do_create_plugin
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr     raise exceptions.DiscoveryFailure('Could not determine a
> suiable URL '
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr DiscoveryFailure: Could not determine a suitable URL for the
> plugin
>
> Apr 27 16:06:21 compute kuryr-server[17450]: 2019-04-27 16:06:21.497 17450
> ERROR kuryr
>
> Apr 27 16:06:21 compute systemd[1]: kuryr-libnetwork.service: Main process
> exited, code=exited, status=1/FAILURE
>
> Apr 27 16:06:21 compute systemd[1]: kuryr-libnetwork.service: Failed with
> result 'exit-code'.
>
> *UPDATE2*
>
> I tried the recommendations given by **hongbin034** and confirm that i had
> a problem with Keystone.
> when i run openstack token issue after exporting the neutron environment
> varibles i get the following output
>
> Failed to discover available identity versions when contacting
> http://controller:35357. Attempting to parse version from URL.
> Could not determine a suitable URL for the plugin
>
> I checked and the port 35357 isn't even open at the controller node. But
> at the controller node installation there isn't any step configuring such
> port
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/8d349505/attachment-0001.html>

From egle.sigler at rackspace.com  Mon Apr 29 22:21:56 2019
From: egle.sigler at rackspace.com (Egle Sigler)
Date: Mon, 29 Apr 2019 22:21:56 +0000
Subject: [ptg] [interop] [refstack] Interop Forum and PTG sessions
Message-ID: <9088BA70-C488-4D47-B11C-8908213A6220@rackspace.com>

Hello Everyone,

If you in Denver for the summit this week, please join the interop working group team for our forum session on Tuesday, 4:20 pm – 5:00 pm meeting room 507:
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23657/interopwg-forum-session

PTG: Friday, 9:00 am – 10:45 am, Room 112

Thank you,
Egle Sigler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/8d81005a/attachment.html>

From miguel at mlavalle.com  Mon Apr 29 22:46:26 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Mon, 29 Apr 2019 16:46:26 -0600
Subject: [openstack-dev] [neutron] PTG agenda
Message-ID: <CAEzGLDjOJnuRtNP=JHcBMDSLCM4N4P1mGeUbyM3vTr=uwbZpBg@mail.gmail.com>

Hi Neutrinos,,

I took your proposals for PTG topics and organized them in an agenda.
Please look at
https://etherpad.openstack.org/p/openstack-networking-train-ptg. Let's have
a very productive meeting!

Best regards

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190429/e330dbcb/attachment.html>

From cdent+os at anticdent.org  Mon Apr 29 22:50:10 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 29 Apr 2019 16:50:10 -0600 (MDT)
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
Message-ID: <alpine.OSX.2.21.1904291648320.17312@cdent-a01.vmware.com>

On Mon, 29 Apr 2019, Eric Fried wrote:

>>> a) It assumes the meaning of "same tree" is "one level down from the
>>> root".
>>
>> Does it? I had casually interpreted
>> "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is
>> somewhere within the tree rooted at $GROUP_A at any level' but it
>> could just as easily be interpreted a few different ways, including
>> what you say.
>
> If I interpret that ^ correctly, it would require $GROUP_A (the subtree
> root) to provide resources, a scenario for which we have at least one
> counterexample (the one with network agents as resourceless providers).

Why would it require GROUP_A to provide resources? Haven't we
already established that we're going to need to lighten the
requirement that 'requiredN' must have a 'resourcesN'? If we
haven't, perhaps this is the thing that will push us that way?

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From openstack at fried.cc  Tue Apr 30 00:35:38 2019
From: openstack at fried.cc (Eric Fried)
Date: Mon, 29 Apr 2019 18:35:38 -0600
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <alpine.OSX.2.21.1904291648320.17312@cdent-a01.vmware.com>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
 <alpine.OSX.2.21.1904291648320.17312@cdent-a01.vmware.com>
Message-ID: <27624C30-2BB6-43DF-9613-783674389C0B@fried.cc>


> Why would it require GROUP_A to provide resources? Haven't we
> already established that we're going to need to lighten the
> requirement that 'requiredN' must have a 'resourcesN'? If we
> haven't, perhaps this is the thing that will push us that way?

Oic, so group A could be a (potentially resourceless) provider with a trait like NUMA_NODE or SRIOV_NET_AGENT.

If we can get by the other issue - to which I shall henceforth refer as "inter-group referencing" - I could get behind this.

Did we decide on "traits (and/or aggregates) flow down" too? I'm losing track of how all these things interact and which combinations are necessary to solve which use cases.

efried
.




From cdent+os at anticdent.org  Tue Apr 30 02:12:13 2019
From: cdent+os at anticdent.org (Chris Dent)
Date: Mon, 29 Apr 2019 20:12:13 -0600 (MDT)
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <27624C30-2BB6-43DF-9613-783674389C0B@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
 <alpine.OSX.2.21.1904291648320.17312@cdent-a01.vmware.com>
 <27624C30-2BB6-43DF-9613-783674389C0B@fried.cc>
Message-ID: <alpine.OSX.2.21.1904292005240.23378@cdent-a01.vmware.com>

On Mon, 29 Apr 2019, Eric Fried wrote:

> Did we decide on "traits (and/or aggregates) flow down" too? I'm losing track of how all these things interact and which combinations are necessary to solve which use cases.

I agree that it is getting hard to track. It seems that at least
both Jay and I are interested in seeing if "X flow down" is
workable.

What would make sense, to me, is to form a coherent model that
captures these ideas in a consistent fashion, and see which uses
cases it can satisfy well, which it cannot, and if those it cannot
can be substituted by some other solution (or dismissed (as not
cloudy?)).

The ideas seem to be:

* X flow down
* same_tree:$GROUP_A:$GROUP_B group policy referencing
* resource-less resource providers (and thus request groups with
   requireds, but not resources)

Does that jibe with what other people have been reading and
thinking?

Note that I don't think we should be looking for the perfect 100%
solution here. What we should be looking for is a good model that
makes it easier to satisfy some large percentage of the use cases
efficiently (both in running the solution and creating it).
Sometimes you can't do everything.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

From frickler at offenerstapel.de  Tue Apr 30 11:31:55 2019
From: frickler at offenerstapel.de (Jens Harbott)
Date: Tue, 30 Apr 2019 11:31:55 +0000
Subject: [Neutron] Create subnet gives ERROR "Body contains invalid data"
In-Reply-To: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
References: <DF4PR8401MB066532597B9052F9F27F9E5DEB390@DF4PR8401MB0665.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <1556623915.4997.42.camel@offenerstapel.de>

On Mon, 2019-04-29 at 12:33 +0000, Kelam, Koteswara Rao wrote:
> Tried to create a subnet with following curl command
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type:
> application/json" -H "Accept: application/json" -H "X-Auth-Token:
> $AUTH_TOKEN" -d '{'subnet': {'name': '8c7993a8-905e-4ad4-be3b-
> 11c692e38317', 'network_id': '8f5f7cff-a320-40ba-9903-0c4e6dd80c0c',
> 'ip_version': 4, 'cidr': '169.254.3.1/32', 'enable_dhcp': 'false'}}'
> 
> And got following ERROR:
> 
> {"NeutronError": {"message": "Body contains invalid data", "type":
> "HTTPBadRequest", "detail": ""}}
> 
> But when I tried with DOUBLE quotes in the body it got succeeded.
> 
> $ curl -s $END_POINT/neutron/v2.0/subnets -X POST -H "Content-Type:
> application/json" -H "Accept: application/json" -H "X-Auth-Token:
> $AUTH_TOKEN" -d '{"subnet": {"name": "8c7993a8-905e-4ad4-be3b-
> 11c692e38317", "network_id": "8f5f7cff-a320-40ba-9903-0c4e6dd80c0c",
> "ip_version": 4, "cidr": "169.254.3.1/32", "enable_dhcp": 'false'}}'
> 
> {"subnet":{"description":"","enable_dhcp":false,"tags":[],"network_id
> ":"8f5f7cff-a320-40ba-9903-
> 0c4e6dd80c0c","tenant_id":"39f81bc21a9f4eb7b87586d983b6ec3d","created
> _at":"2019-04-
> 29T11:56:57Z","segment_id":null,"dns_nameservers":[],"updated_at":"20
> 19-04-
> 29T11:56:57Z","gateway_ip":"169.254.3.2","ipv6_ra_mode":null,"allocat
> ion_pools":[{"start":"169.254.3.1","end":"169.254.3.1"}],"host_routes
> ":[],"revision_number":0,"ip_version":4,"ipv6_address_mode":null,"cid
> r":"169.254.3.1/32","project_id":"39f81bc21a9f4eb7b87586d983b6ec3d","
> id":"33de75fb-fa10-460a-9123-
> 577ae62a771a","subnetpool_id":null,"name":"8c7993a8-905e-4ad4-be3b-
> 11c692e38317"}}
> 
> Single quotes not allowed in requested body? Only double quotes
> allowed??
> Single quotes also used to work for me with older versions on
> neutron.

I think the issue lies in the way that your shell parses the quotes. If
you use

curl ... -d '{'subnet': {'...

bash will simply use the text within each pair of '' but omit all '
characters in the command being executed. To avoid that, enclose the
whole body in "", e.g.

curl ... -d "{'subnet': {'...}}" ...

so essentially revert what you are doing in the second, working
version.

Jens


From isanjayk5 at gmail.com  Tue Apr 30 13:04:21 2019
From: isanjayk5 at gmail.com (Sanjay K)
Date: Tue, 30 Apr 2019 18:34:21 +0530
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack
 stein setup
In-Reply-To: <MN2PR12MB3166BB3DDBFB99D51F40A1D58C390@MN2PR12MB3166.namprd12.prod.outlook.com>
References: <CABq8x-vEmN4zcUQ7DTfXY7d5ctZ2QeaLZwHhPQNsQd6GXTJegA@mail.gmail.com>
 <MN2PR12MB3166BB3DDBFB99D51F40A1D58C390@MN2PR12MB3166.namprd12.prod.outlook.com>
Message-ID: <CABq8x-tOpf3nCbCK-bDehAiLCqR73ccHseXD11JOYiuL57=UAw@mail.gmail.com>

Hi Tushar,
Thanks you for your quick response on this. As I have already included the
masakari-monitors plugin in my compute host's local.conf file in devstack,
I have the repo present in my VM. Following the steps to set up the conf
files and start the necessary masakari monitoring processes from this link
https://github.com/openstack/masakari-monitors/blob/master/README.rst I get
the same error when I start the 3 monitoring processes
(masakari-processmonitor, masakari-hostmonitor, masakari-instancemonitor) -

stack at devstack-:/etc/masakarimonitors$ masakari-processmonitor
Traceback (most recent call last):
  File "/usr/local/bin/masakari-processmonitor", line 10, in <module>
    sys.exit(main())
  File
"/usr/local/lib/python2.7/dist-packages/masakarimonitors/cmd/processmonitor.py",
line 31, in main
    config.parse_args(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/masakarimonitors/config.py",
line 32, in parse_args
    default_config_files=default_config_files)
  File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line
2127, in __call__
    self._check_required_opts()
  File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line
2865, in _check_required_opts
    raise RequiredOptError(opt.name, group)
oslo_config.cfg.RequiredOptError: value required for option auth-url in
group [api]

After masakari setup I can file all the required binaries in my
/usr/local/bin directory -

$ ls -ltr /usr/local/bin/masakari*
-rwxr-xr-x 1 root root  222 Apr 17 01:55 /usr/local/bin/masakari
-rwxr-xr-x 1 root root  976 Apr 21 23:41
/usr/local/bin/masakari-processmonitor.sh
-rwxr-xr-x 1 root root  918 Apr 21 23:41
/usr/local/bin/masakari-hostmonitor.sh
-rwxr-xr-x 1 root root 1854 Apr 29 01:01 /usr/local/bin/masakari-wsgi
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-status
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-manage
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-engine
-rwxr-xr-x 1 root root  155 Apr 29 01:01 /usr/local/bin/masakari-api
-rwxr-xr-x 1 root root  174 Apr 30 04:34
/usr/local/bin/masakari-processmonitor
-rwxr-xr-x 1 root root  188 Apr 30 04:34
/usr/local/bin/masakari-introspectiveinstancemonitor
-rwxr-xr-x 1 root root  175 Apr 30 04:34
/usr/local/bin/masakari-instancemonitor
-rwxr-xr-x 1 root root  171 Apr 30 04:34 /usr/local/bin/masakari-hostmonitor

Please let me know is there any issue with my masakari setup with devstack
and where can I find latest documentation on Masakari for using in devstack.

thanks for your pointer,
best regards,
Sanjay

On Tue, Apr 30, 2019 at 3:24 AM Patil, Tushar <Tushar.Patil at nttdata.com>
wrote:

> Hi Sanjay,
>
> In case of masakari-processmonitor, it only monitors processes as
> mentioned in the process_list.yaml which by default monitors libvirt-bin,
> nova-compute, instancemonitor, hostmonitor and sshd processes.
>
> To test process failure, you should terminate any of the above processes.
>
> In case of instancemonitor, you can shutdown the VM to test whether a
> notification is sent or not.
>
> >> I have asked the same question in openstack forum, but not got a single
> response.
> Sorry, I didn't notice your question on forum. I have replied above
> comment on forum as well.
>
> Regards,
> Tushar Patil
>
> ________________________________________
> From: Sanjay K <isanjayk5 at gmail.com>
> Sent: Monday, April 29, 2019 6:18:20 PM
> To: openstack-discuss at lists.openstack.org
> Subject: [devstack][stein][masakari]Using Masakari in multihost devstack
> stein setup
>
> Hi all,
> I have been trying to setup Masakari in a 3 node setup - 1 controller + 2
> computes with minimal openstack services installed using devstack
> stable/stein version. All these 3 nodes are Ubuntu 16.04 VMs. I have
> included Masakari plugin in controller's local.conf file and included
> masakari-monitor in both compute node's local.conf file. I want to test out
> VM/process failure in my test environment. To do so, when I kill one of the
> qemu process created for one instance (cirros 256 flavor VMs) on one of the
> compute with root user login, I did not see any notification under my
> horizon/instance-ha section for this (I have already created Segments,
> Hosts under instance-ha in horizon). Also the killed process is not
> restarted by Masakari.
>
> I have asked the same question in openstack forum, but not got a single
> response.
>
> masakari-notification-on-process-failure<
> https://ask.openstack.org/en/question/121490/masakari-notification-on-process-failure/
> >
>
> Whether any additional services related to Masakari need to be configured
> on compute hosts to detect failures since I did not find exactly the
> documentation related inside devstack for this.
>
> Please let me know if I am missing anything my set up. Any helps and
> pointers are most appreciated.
>
> thank you for your reply.
>
> best regards
> Disclaimer: This email and any attachments are sent in strictest
> confidence for the sole use of the addressee and may contain legally
> privileged, confidential, and proprietary data. If you are not the intended
> recipient, please advise the sender by replying promptly to this email and
> then delete and destroy this email and any attachments without any further
> use, copying or forwarding.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/920efd26/attachment.html>

From balazs.gibizer at ericsson.com  Tue Apr 30 13:27:18 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Tue, 30 Apr 2019 13:27:18 +0000
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
Message-ID: <1556630824.24201.0@smtp.office365.com>



On Mon, Apr 29, 2019 at 11:38 PM, Eric Fried <openstack at fried.cc> wrote:
>>  Jay suggested extending the JSON schema to allow groups that are
>>  names like resources_compute, required_network. That might allow for
>>  some conventions to emerge but still requires some measure of
>>  knowledge from the participants.
> 
> I think this is a good idea to pursue, because it gives us a way to
> predefine (by convention) what the groups are called, as opposed to
> having them be automatically, arbitrarily, unpredictably numbered. 
> It'll
> still break down in more complex scenarios where, say, there's more 
> than
> one device_group with different affinity requirements; but it could 
> work
> for the simpler setups.

I support this idea. Today The RequestGroup contains a requester_id 
field[1] to map the numbered group back to the neutron port (cyborg 
dev) it is originated from. If the group can be named instead of only 
numbered then this mapping can be encoded into the name of the group 
like resources_port_<port_uuid>. This would also made sure that name of 
the group is unique and more importantly it is stable (today we 
generate the number of the numbered group originated from neutron port) 
and that helps troubleshooting.

Cheers,
gibi

[1]https://github.com/openstack/nova/blob/ce5ef763b58cad09440e0da67733ce578068752a/nova/objects/request_spec.py#L1009



From balazs.gibizer at ericsson.com  Tue Apr 30 13:45:55 2019
From: balazs.gibizer at ericsson.com (=?iso-8859-1?Q?Bal=E1zs_Gibizer?=)
Date: Tue, 30 Apr 2019 13:45:55 +0000
Subject: [placement][nova][ptg] resource provider affinity
In-Reply-To: <27624C30-2BB6-43DF-9613-783674389C0B@fried.cc>
References: <alpine.OSX.2.21.1904091323251.93787@cdent-a01.vmware.com>
 <CAH7mGauikCiiDOQfOCG4sm03BHsLte1=dKcbB5=9xWcLYBcpgQ@mail.gmail.com>
 <776bc9b18cf33713708c22d893bd2a46d7a899ed.camel@redhat.com>
 <CAH7mGatzVVz=-pQuyUW2LH_PdeV9EcHbO+0qmQv7Hkvg618+Yw@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED527552AD6@fmsmsx122.amr.corp.intel.com>
 <CAH7mGasqm7kW3zLzFoO-9snLwvNMtX=sCYnj1vC0OZy93sXLKg@mail.gmail.com>
 <97bd8e53-0285-1c92-845f-21098b0b0e38@gmail.com>
 <alpine.OSX.2.21.1904281739320.5457@cdent-a01.vmware.com>
 <d1eb7c7a-f1fe-1679-bc69-fbf80d562d26@fried.cc>
 <alpine.OSX.2.21.1904282156350.7763@cdent-a01.vmware.com>
 <21aa22e7-be7d-8ecf-b5bd-9c6afcd789f5@fried.cc>
 <alpine.OSX.2.21.1904291648320.17312@cdent-a01.vmware.com>
 <27624C30-2BB6-43DF-9613-783674389C0B@fried.cc>
Message-ID: <1556631941.24201.1@smtp.office365.com>



On Tue, Apr 30, 2019 at 2:35 AM, Eric Fried <openstack at fried.cc> wrote:
> 
> Did we decide on "traits (and/or aggregates) flow down" too? I'm 
> losing track of how all these things interact and which combinations 
> are necessary to solve which use cases.
> 

Can we start collecting use cases in a spec doc with provider tree 
examples and a_c queries against those trees written in plain English? 
I'm happy to contribute to that spec with the bandwidth related 
examples.

gibi



From Tushar.Patil at nttdata.com  Tue Apr 30 15:17:24 2019
From: Tushar.Patil at nttdata.com (Patil, Tushar)
Date: Tue, 30 Apr 2019 15:17:24 +0000
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack
 stein setup
In-Reply-To: <CABq8x-tOpf3nCbCK-bDehAiLCqR73ccHseXD11JOYiuL57=UAw@mail.gmail.com>
References: <CABq8x-vEmN4zcUQ7DTfXY7d5ctZ2QeaLZwHhPQNsQd6GXTJegA@mail.gmail.com>
 <MN2PR12MB3166BB3DDBFB99D51F40A1D58C390@MN2PR12MB3166.namprd12.prod.outlook.com>,
 <CABq8x-tOpf3nCbCK-bDehAiLCqR73ccHseXD11JOYiuL57=UAw@mail.gmail.com>
Message-ID: <MN2PR12MB316685F5A63CD0914F08742A8C3A0@MN2PR12MB3166.namprd12.prod.outlook.com>

Hi Sanjay,

You will need to add following config options in masakarimonitors.conf under the [api] section.

auth_url
password
project_name
username
user_domain_id
project_domain_id
region

We have added support to install and run following masakari-monitors in the current master planned to available in Train cycle.

1. process monitor
2. instance monitor
3. introspective instance monitor

We are still working on adding support to install and run host monitors using devstack.

Regards,
Tushar Patil




________________________________________
From: Sanjay K <isanjayk5 at gmail.com>
Sent: Tuesday, April 30, 2019 10:04:21 PM
To: Patil, Tushar
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [devstack][stein][masakari]Using Masakari in multihost devstack stein setup

Hi Tushar,
Thanks you for your quick response on this. As I have already included the masakari-monitors plugin in my compute host's local.conf file in devstack, I have the repo present in my VM. Following the steps to set up the conf files and start the necessary masakari monitoring processes from this link https://github.com/openstack/masakari-monitors/blob/master/README.rst I get the same error when I start the 3 monitoring processes (masakari-processmonitor, masakari-hostmonitor, masakari-instancemonitor) -

stack at devstack-:/etc/masakarimonitors$ masakari-processmonitor
Traceback (most recent call last):
  File "/usr/local/bin/masakari-processmonitor", line 10, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/masakarimonitors/cmd/processmonitor.py", line 31, in main
    config.parse_args(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/masakarimonitors/config.py", line 32, in parse_args
    default_config_files=default_config_files)
  File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2127, in __call__
    self._check_required_opts()
  File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2865, in _check_required_opts
    raise RequiredOptError(opt.name<http://opt.name>, group)
oslo_config.cfg.RequiredOptError: value required for option auth-url in group [api]

After masakari setup I can file all the required binaries in my /usr/local/bin directory -

$ ls -ltr /usr/local/bin/masakari*
-rwxr-xr-x 1 root root  222 Apr 17 01:55 /usr/local/bin/masakari
-rwxr-xr-x 1 root root  976 Apr 21 23:41 /usr/local/bin/masakari-processmonitor.sh
-rwxr-xr-x 1 root root  918 Apr 21 23:41 /usr/local/bin/masakari-hostmonitor.sh
-rwxr-xr-x 1 root root 1854 Apr 29 01:01 /usr/local/bin/masakari-wsgi
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-status
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-manage
-rwxr-xr-x 1 root root  158 Apr 29 01:01 /usr/local/bin/masakari-engine
-rwxr-xr-x 1 root root  155 Apr 29 01:01 /usr/local/bin/masakari-api
-rwxr-xr-x 1 root root  174 Apr 30 04:34 /usr/local/bin/masakari-processmonitor
-rwxr-xr-x 1 root root  188 Apr 30 04:34 /usr/local/bin/masakari-introspectiveinstancemonitor
-rwxr-xr-x 1 root root  175 Apr 30 04:34 /usr/local/bin/masakari-instancemonitor
-rwxr-xr-x 1 root root  171 Apr 30 04:34 /usr/local/bin/masakari-hostmonitor

Please let me know is there any issue with my masakari setup with devstack and where can I find latest documentation on Masakari for using in devstack.

thanks for your pointer,
best regards,
Sanjay

On Tue, Apr 30, 2019 at 3:24 AM Patil, Tushar <Tushar.Patil at nttdata.com<mailto:Tushar.Patil at nttdata.com>> wrote:
Hi Sanjay,

In case of masakari-processmonitor, it only monitors processes as mentioned in the process_list.yaml which by default monitors libvirt-bin, nova-compute, instancemonitor, hostmonitor and sshd processes.

To test process failure, you should terminate any of the above processes.

In case of instancemonitor, you can shutdown the VM to test whether a notification is sent or not.

>> I have asked the same question in openstack forum, but not got a single response.
Sorry, I didn't notice your question on forum. I have replied above comment on forum as well.

Regards,
Tushar Patil

________________________________________
From: Sanjay K <isanjayk5 at gmail.com<mailto:isanjayk5 at gmail.com>>
Sent: Monday, April 29, 2019 6:18:20 PM
To: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: [devstack][stein][masakari]Using Masakari in multihost devstack stein setup

Hi all,
I have been trying to setup Masakari in a 3 node setup - 1 controller + 2 computes with minimal openstack services installed using devstack stable/stein version. All these 3 nodes are Ubuntu 16.04 VMs. I have included Masakari plugin in controller's local.conf file and included masakari-monitor in both compute node's local.conf file. I want to test out VM/process failure in my test environment. To do so, when I kill one of the qemu process created for one instance (cirros 256 flavor VMs) on one of the compute with root user login, I did not see any notification under my horizon/instance-ha section for this (I have already created Segments, Hosts under instance-ha in horizon). Also the killed process is not restarted by Masakari.

I have asked the same question in openstack forum, but not got a single response.

masakari-notification-on-process-failure<https://ask.openstack.org/en/question/121490/masakari-notification-on-process-failure/>

Whether any additional services related to Masakari need to be configured on compute hosts to detect failures since I did not find exactly the documentation related inside devstack for this.

Please let me know if I am missing anything my set up. Any helps and pointers are most appreciated.

thank you for your reply.

best regards
Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.
Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.


From openstack at hauschild.it  Tue Apr 30 15:30:22 2019
From: openstack at hauschild.it (Hartwig Hauschild)
Date: Tue, 30 Apr 2019 17:30:22 +0200
Subject: properly sizing openstack controlplane infrastructure
Message-ID: <20190430153021.jhdgri7g2nvpn5vj@alle-irre.de>

Hi everyone,

A colleague and I have more or less recently been tasked with redesigning
my employers openstack-infrastructure and it turned out that starting over
will be easier than fixing the existing stack as we've managed to lock
ourselves in a corner quite good.

The requirements we've got are basically "here's 50 compute-nodes, make sure
whatever you're building scales upwards from there".

We have the existing pike-stack as a reference but we don't really know how
the different services scale up with more compute-nodes to handle.

The pike-stack has three servers as control-plane, each of them with 96G of
RAM and they don't seem to have too much room left when coordinating 14
compute-nodes.

We're thinking about splitting the control-nodes into infrastructure
(db/rabbit/memcache) and API. 

What would I want to look for when sizing those control-nodes? I've not been
able to find any references for this at all, just rather nebulous '8G RAM
should do' which is around what our rabbit currently inhales.

Also: We're currently running Neutron in OVS-DVR-VXLAN-Configuration.
Does that properly scale up and above 50+ nodes or should we look into
offloading the networking onto something else?

I'm aware that the questions may sound a bit funny, but we have to spec out
the controlplane-hardware before we can start testing and we'd prefer not to
retrofit the servers because we goofed up.

Thanks for your time,

-- 
Cheers, 
	Hardy


From Kevin.Fox at pnnl.gov  Tue Apr 30 15:55:11 2019
From: Kevin.Fox at pnnl.gov (Fox, Kevin M)
Date: Tue, 30 Apr 2019 15:55:11 +0000
Subject: properly sizing openstack controlplane infrastructure
In-Reply-To: <20190430153021.jhdgri7g2nvpn5vj@alle-irre.de>
References: <20190430153021.jhdgri7g2nvpn5vj@alle-irre.de>
Message-ID: <1A3C52DFCD06494D8528644858247BF01C30E5B5@EX10MBOX03.pnnl.gov>

I've run that same network config at about 70 nodes with no problems. I've run the same without dvr at 150 nodes.

Your memory usage seems very high. I ran 150 nodes with a small 16g server ages ago. Might double check that.

Thanks,
Kevin
________________________________________
From: Hartwig Hauschild [openstack at hauschild.it]
Sent: Tuesday, April 30, 2019 8:30 AM
To: openstack-discuss at lists.openstack.org
Subject: properly sizing openstack controlplane infrastructure

Hi everyone,

A colleague and I have more or less recently been tasked with redesigning
my employers openstack-infrastructure and it turned out that starting over
will be easier than fixing the existing stack as we've managed to lock
ourselves in a corner quite good.

The requirements we've got are basically "here's 50 compute-nodes, make sure
whatever you're building scales upwards from there".

We have the existing pike-stack as a reference but we don't really know how
the different services scale up with more compute-nodes to handle.

The pike-stack has three servers as control-plane, each of them with 96G of
RAM and they don't seem to have too much room left when coordinating 14
compute-nodes.

We're thinking about splitting the control-nodes into infrastructure
(db/rabbit/memcache) and API.

What would I want to look for when sizing those control-nodes? I've not been
able to find any references for this at all, just rather nebulous '8G RAM
should do' which is around what our rabbit currently inhales.

Also: We're currently running Neutron in OVS-DVR-VXLAN-Configuration.
Does that properly scale up and above 50+ nodes or should we look into
offloading the networking onto something else?

I'm aware that the questions may sound a bit funny, but we have to spec out
the controlplane-hardware before we can start testing and we'd prefer not to
retrofit the servers because we goofed up.

Thanks for your time,

--
Cheers,
        Hardy



From daniel at speichert.pl  Tue Apr 30 16:17:20 2019
From: daniel at speichert.pl (Daniel Speichert)
Date: Tue, 30 Apr 2019 18:17:20 +0200 (CEST)
Subject: properly sizing openstack controlplane infrastructure
In-Reply-To: <20190430153021.jhdgri7g2nvpn5vj@alle-irre.de>
References: <20190430153021.jhdgri7g2nvpn5vj@alle-irre.de>
Message-ID: <2114088542.1037659.1556641040235.JavaMail.zimbra@speichert.pl>

----- Original Message -----
> From: "Hartwig Hauschild" <openstack at hauschild.it>
> To: openstack-discuss at lists.openstack.org
> Sent: Tuesday, April 30, 2019 9:30:22 AM
> Subject: properly sizing openstack controlplane infrastructure

> The requirements we've got are basically "here's 50 compute-nodes, make sure
> whatever you're building scales upwards from there".

It depends what's your end goal. 100? 500? >1000 nodes?
At some point things like Nova Cells will help (or become necessity).

> The pike-stack has three servers as control-plane, each of them with 96G of
> RAM and they don't seem to have too much room left when coordinating 14
> compute-nodes.

96 GB of RAM per controller is much more than enough for 14 compute nodes.
There's room for improvement in configuration.

> We're thinking about splitting the control-nodes into infrastructure
> (db/rabbit/memcache) and API.
> 
> What would I want to look for when sizing those control-nodes? I've not been
> able to find any references for this at all, just rather nebulous '8G RAM
> should do' which is around what our rabbit currently inhales.

You might want to check out Performance Docs:
https://docs.openstack.org/developer/performance-docs/

For configuration tips, I'd suggest looking at what openstack-ansible
or similar projects provide as "battle-tested" configuration.
It's a good baseline reference before you tune yourself.

-Daniel


From neil at tigera.io  Tue Apr 30 16:40:42 2019
From: neil at tigera.io (Neil Jerram)
Date: Tue, 30 Apr 2019 17:40:42 +0100
Subject: [devstack] Identity URL problem
Message-ID: <CAMGh4hOAhV2r1Xo-5NqYP5fjmTM1c-OQW1pYhXtr0w6N_EMf6w@mail.gmail.com>

Does anyone know what causes this problem at [1]:

2019-04-30 16:34:03.137 | +++ functions-common:oscwrap:2346            :
 command openstack role add admin --user neutron --project service
--user-domain Default --project-domain Default
2019-04-30 16:34:03.139 | +++ functions-common:oscwrap:2346            :
 openstack role add admin --user neutron --project service --user-domain
Default --project-domain Default
2019-04-30 16:34:04.331 | Failed to discover available identity versions
when contacting http://104.239.175.234/identity. Attempting to parse
version from URL.
2019-04-30 16:34:04.331 | Could not find versioned identity endpoints when
attempting to authenticate. Please check that your auth_url is correct. Not
Found (HTTP 404)

[1]
http://logs.openstack.org/79/638479/3/check/networking-calico-tempest-dsvm/5431e4b/logs/devstacklog.txt.gz

I think there are loads of uses of that URL, before where the
networking-calico plugin uses it, so I can't see why the plugin's use hits
that error.

Thanks,
    Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/3976903d/attachment.html>

From miguel at mlavalle.com  Tue Apr 30 17:52:46 2019
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Tue, 30 Apr 2019 11:52:46 -0600
Subject: [openstack-dev] [neutron] Neutron team dinner at Denver PTG
Message-ID: <CAEzGLDi9jzXpBd-10PkXaTw60jYoG5sb2akO=uSNZ6K_i1y_8Q@mail.gmail.com>

Hi Neutrinos,

After extensive consultations with the community, we decided that pizza and
beer is always a crowd pleaser among a bunch of software engineers. So our
team dinner will take place at Mellow Mushroom Pizza Bakers, located at
1201 16th Street, Denver, CO 80202, phone number (720) 328-9114. There is a
reservation under "Miguel" at 7pm on Friday May 3rd. Here you will find
walking directions from the Convention Center:
https://goo.gl/maps/G63j6FmuoyBKjA7RA

If you haven't done so already and are planning to attend the team dinner,
please register your name at the top of this etherpad:
https://etherpad.openstack.org/p/openstack-networking-train-ptg

Looking forward to see you there!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/7e97e27f/attachment.html>

From mark at stackhpc.com  Tue Apr 30 18:01:10 2019
From: mark at stackhpc.com (Mark Goddard)
Date: Tue, 30 Apr 2019 12:01:10 -0600
Subject: [kolla] Virtual PTG scheduling poll
In-Reply-To: <CAFHSqWr2Urj4X+sywQijvfHO54WHNdzd25sM=t10gwbCqb=VNQ@mail.gmail.com>
References: <CAFHSqWr2Urj4X+sywQijvfHO54WHNdzd25sM=t10gwbCqb=VNQ@mail.gmail.com>
Message-ID: <CAFHSqWosj6jcS61U79xcYTjjmQsCU5nAcP5-O8amwC=QP9AZKA@mail.gmail.com>

Hi,

We struggled to find a suitable date, so I've added another two weeks.
Please update your responses.

https://doodle.com/poll/adk2smds76d8db4u

Thanks,
Mark

On Mon, 15 Apr 2019 at 07:34, Mark Goddard <mark at stackhpc.com> wrote:

> Hi,
>
> Since most of the Kolla team aren't attending the PTG, we've agreed to
> hold a virtual PTG.
>
> We agreed to start with two 4 hour sessions. We can finish early or
> schedule another session, depending on how we progress. We'll use some
> video conferencing software TBD.
>
> I've created a Doodle poll here [2], please fill it in if you hope to
> attend. Times are in UTC.
>
> Please continue to fill out the planning Etherpad [1].
>
> Thanks,
> Mark
>
> [1] https://etherpad.openstack.org/p/kolla-train-ptg
> [2] https://doodle.com/poll/adk2smds76d8db4u
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/78a4ee1b/attachment-0001.html>

From arbermejo0417 at gmail.com  Tue Apr 30 21:29:18 2019
From: arbermejo0417 at gmail.com (Alejandro Ruiz Bermejo)
Date: Tue, 30 Apr 2019 17:29:18 -0400
Subject: [Zun] openstack appcontainer create Error
Message-ID: <CAOJ6YErbTW6DM=g5JzhCvyGogfsB11ziGz=cd6mgXpm5NnK92A@mail.gmail.com>

Hi, i'm installing Zun in Openstack Queens with Ubuntu 18.04.1 LTS, i
already have configured docker and kuyr-libnetwork. I'm following the guide
at https://docs.openstack.org/zun/queens/install/index.html. I followed all
the steps of the installation at  controller node and everything resulted
without problems.

After finished the installation direction at compute node  the *systemctl
status zun-compute* have the following errors

root at compute /h/team# systemctl status zun-compute
● zun-compute.service - OpenStack Container Service Compute Agent
   Loaded: loaded (/etc/systemd/system/zun-compute.service; enabled; vendor
preset: enabled)
   Active: active (running) since Tue 2019-04-30 16:46:56 UTC; 4h 26min ago
 Main PID: 2072 (zun-compute)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/zun-compute.service
           └─2072 /usr/bin/python /usr/local/bin/zun-compute

Apr 30 16:46:56 compute systemd[1]: Started OpenStack Container Service
Compute Agent.
Apr 30 16:46:57 compute zun-compute[2072]: 2019-04-30 16:46:57.929 2072
INFO zun.cmd.compute [-] Starting server in PID 2072
Apr 30 16:46:57 compute zun-compute[2072]: 2019-04-30 16:46:57.941 2072
INFO zun.container.driver [-] Loading container driver
'docker.driver.DockerDriver'
Apr 30 16:46:58 compute zun-compute[2072]: 2019-04-30 16:46:58.028 2072
INFO zun.container.driver [-] Loading container driver
'docker.driver.DockerDriver'
Apr 30 16:48:33 compute zun-compute[2072]: 2019-04-30 16:48:33.645 2072
INFO zun.image.driver [req-7e0b8325-1e09-4410-80f4-af807cbc0420
a16c6ef0319b4643a4ec8e56a1d025cb 59065d8f970b467aa94ef7b35f1edab5 default -
-] Loading container image driver 'glance'
Apr 30 16:48:33 compute zun-compute[2072]: 2019-04-30 16:48:33.911 2072
INFO zun.image.driver [req-7e0b8325-1e09-4410-80f4-af807cbc0420
a16c6ef0319b4643a4ec8e56a1d025cb 59065d8f970b467aa94ef7b35f1edab5 default -
-] Loading container image driver 'glance'
Apr 30 16:48:35 compute zun-compute[2072]: 2019-04-30 16:48:35.455 2072
INFO zun.image.driver [req-7e0b8325-1e09-4410-80f4-af807cbc0420
16c6ef0319b4643a4ec8e56a1d025cb 59065d8f970b467aa94ef7b35f1edab5 default -
-] Loading container image driver 'glance'
Apr 30 16:48:35 compute zun-compute[2072]: 2019-04-30 16:48:35.939 2072
ERROR zun.image.glance.driver [req-7e0b8325-1e09-4410-80f4-af807cbc0420
a16c6ef0319b4643a4ec8e56a1d025cb 59065d8f970b467aa94ef7b35f1edab5 default -
-] Imae cirros was not found in glance: ImageNotFound: Image cirros could
not be found.
Apr 30 16:48:35 compute zun-compute[2072]: 2019-04-30 16:48:35.940 2072
INFO zun.image.driver [req-7e0b8325-1e09-4410-80f4-af807cbc0420
a16c6ef0319b4643a4ec8e56a1d025cb 59065d8f970b467aa94ef7b35f1edab5 default -
-] Loading container image driver 'docker'
Apr 30 16:48:55 compute zun-compute[2072]: 2019-04-30 16:48:55.011 2072
ERROR zun.compute.manager [req-7bfa764a-45b8-4e2f-ac70-84d8bb71b135 - - - -
-] Error occurred while calling Docker create API: Docker internal error:
500 Server Error: Internal Server Error ("failed to update store for object
typpe *libnetwork.endpointCnt: client: etcd member http://controller:2379
has no leader").: DockerError: Docker internal error: 500 Server Error:
Internal Server Error ("failed to update store for object type
*libnetwork.endpointtCnt: client: etcd member http://controller:2379 has no
leader").

Also *systemctl status docker* show the next output

root at compute /h/team# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor
preset: enabled)
  Drop-In: /etc/systemd/system/docker.service.d
           └─docker.conf, http-proxy.conf, https-proxy.conf
   Active: active (running) since Tue 2019-04-30 16:46:25 UTC; 4h 18min ago
     Docs: https://docs.docker.com
 Main PID: 1777 (dockerd)
    Tasks: 21
   CGroup: /system.slice/docker.service
           └─1777 /usr/bin/dockerd --group zun -H tcp://compute:2375 -H
unix:///var/run/docker.sock --cluster-store etcd://controller:2379

Apr 30 16:46:20 compute dockerd[1777]:
time="2019-04-30T16:46:20.815305836Z" level=warning msg="Your kernel does
not support cgroup rt runtime"
Apr 30 16:46:20 compute dockerd[1777]:
time="2019-04-30T16:46:20.815933695Z" level=info msg="Loading containers:
start."
Apr 30 16:46:24 compute dockerd[1777]:
time="2019-04-30T16:46:24.378526837Z" level=info msg="Default bridge
(docker0) is assigned with an IP address 17
Apr 30 16:46:24 compute dockerd[1777]:
time="2019-04-30T16:46:24.572558877Z" level=info msg="Loading containers:
done."
Apr 30 16:46:25 compute dockerd[1777]:
time="2019-04-30T16:46:25.198101219Z" level=info msg="Docker daemon"
commit=e8ff056 graphdriver(s)=overlay2 vers
Apr 30 16:46:25 compute dockerd[1777]:
time="2019-04-30T16:46:25.198211373Z" level=info msg="Daemon has completed
initialization"
Apr 30 16:46:25 compute dockerd[1777]:
time="2019-04-30T16:46:25.232286069Z" level=info msg="API listen on
/var/run/docker.sock"
Apr 30 16:46:25 compute dockerd[1777]:
time="2019-04-30T16:46:25.232318790Z" level=info msg="API listen on
10.8.9.58:2375"
Apr 30 16:46:25 compute systemd[1]: Started Docker Application Container
Engine.
Apr 30 16:48:55 compute dockerd[1777]:
time="2019-04-30T16:48:55.009820439Z" level=error msg="Handler for POST
/v1.26/networks/create returned error: failed to update store for object
type *libnetwork.endpointCnt: client: etcd member http://controller:2379
has no leader"


When i try to launch an app container as the guide says it shows an Error
state and when i run opentack appcontainer show this is the reason of the
error
status_reason     | Docker internal error: 500 Server Error: Internal
Server Error ("failed to update store for object type
*libnetwork.endpointCnt: client: etcd member http://controller:2379 has no
leader")

I had some troubles installing Kuryr-libnetwork besides that i didn't had
any othet problem during the installation of Zun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/71a95042/attachment.html>

From hoanq13 at viettel.com.vn  Tue Apr 30 09:10:07 2019
From: hoanq13 at viettel.com.vn (hoanq13 at viettel.com.vn)
Date: Tue, 30 Apr 2019 16:10:07 +0700 (ICT)
Subject: [Vitrage] add datasource kapacitor for vitrage
In-Reply-To: <14511424.947437.1556614048877.JavaMail.zimbra@viettel.com.vn>
Message-ID: <1324083046.973516.1556615406841.JavaMail.zimbra@viettel.com.vn>

Hi, 
In our system, we use monitor by TICK stack (include: Telegraf for collect metric, InfluxDB for storage metric, Chronograf for visualize and Kapacitor alarming), which is popular monitor solution. 
We hope can integrate vitrage in, so we decide to write kapacitor datasource contribute for vitrage. 
The work is almost done , you can review in: 
https://review.opendev.org/653416 

So i send this mail hope for more review, ideal,... Appreciate it. 
also ask: have any step i miss in pipeline of contribute datasource vitrage? like create blueprints, vitrage-spec,vv.. Should i do it? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190430/f3d81fe1/attachment.html>