Re: [openstack-dev] [tripleo] EOL process for newton branches

[Tony Breeds]

On Tue, Aug 07, 2018 at 02:34:45PM +1000, Tony Breeds wrote:
> On Mon, Aug 06, 2018 at 07:27:37PM +0200, Andreas Jaeger wrote:
> > Tony,
> > 
> > On 2018-07-19 06:59, Tony Breeds wrote:
> > > On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote:
> > > > Option 2, EOL everything.
> > > > Thanks a lot for your help on this one, Tony.
> > > 
> > > No problem.
> > > 
> > > I've created:
> > >   https://review.openstack.org/583856
> > > to tag final releases for tripleo deliverables and then mark them as
> > > EOL.
> > 
> > This one has merged now.
> 
> Thanks.
> 
> > > 
> > > Once that merges we can arrange for someone, with appropriate
> > > permissions to run:
> > > 
> > > # EOL repos belonging to tripleo
> > > eol_branch.sh -- stable/newton newton-eol \
> > >   openstack/instack openstack/instack-undercloud \
> > >   openstack/os-apply-config openstack/os-collect-config \
> > >   openstack/os-net-config openstack/os-refresh-config \
> > >   openstack/puppet-tripleo openstack/python-tripleoclient 
> > > \
> > >   openstack/tripleo-common 
> > > openstack/tripleo-heat-templates \
> > >   openstack/tripleo-image-elements \
> > >   openstack/tripleo-puppet-elements openstack/tripleo-ui \
> > >   openstack/tripleo-validations
> > 
> > Tony, will you coordinate with infra to run this yourself again - or let
> > them run it for you, please?
> 
> I'm happy with either option.  If it hasn't been run when I get online
> tomorrow I'll ask on #openstack-infra and I'll do it myself.

Okay Ian gave me permission to do this. Those repos have been tagged
newton-eol and had the branches deleted.

Yours Tony.


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

Re: [openstack-dev] [tripleo] EOL process for newton branches

[Tony Breeds]

On Mon, Aug 06, 2018 at 07:27:37PM +0200, Andreas Jaeger wrote:
> Tony,
> 
> On 2018-07-19 06:59, Tony Breeds wrote:
> > On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote:
> > > Option 2, EOL everything.
> > > Thanks a lot for your help on this one, Tony.
> > 
> > No problem.
> > 
> > I've created:
> >   https://review.openstack.org/583856
> > to tag final releases for tripleo deliverables and then mark them as
> > EOL.
> 
> This one has merged now.

Thanks.

> > 
> > Once that merges we can arrange for someone, with appropriate
> > permissions to run:
> > 
> > # EOL repos belonging to tripleo
> > eol_branch.sh -- stable/newton newton-eol \
> >   openstack/instack openstack/instack-undercloud \
> >   openstack/os-apply-config openstack/os-collect-config \
> >   openstack/os-net-config openstack/os-refresh-config \
> >   openstack/puppet-tripleo openstack/python-tripleoclient \
> >   openstack/tripleo-common openstack/tripleo-heat-templates 
> > \
> >   openstack/tripleo-image-elements \
> >   openstack/tripleo-puppet-elements openstack/tripleo-ui \
> >   openstack/tripleo-validations
> 
> Tony, will you coordinate with infra to run this yourself again - or let
> them run it for you, please?

I'm happy with either option.  If it hasn't been run when I get online
tomorrow I'll ask on #openstack-infra and I'll do it myself.
 
> Note that we removed the script with retiring release-tools repo, I propose
> to readd with https://review.openstack.org/589236 and
> https://review.openstack.org/589237 and would love your review on these,
> please. I want to be sure that we import the right version...

Thanks for doing that!  LGTM +1 :)

Yours Tony.


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

[openstack-dev] [Blazar] Stein etherpad

[Masahito MUROI]

Hi Blazar folks,

I prepared the etherpad page for the Stein PTG.

https://etherpad.openstack.org/p/blazar-ptg-stein


best regards,
Masahito


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

[openstack-dev] [all][election][senlin][tacker] Last chance to vote

[Tony Breeds]

Hello Senlin and Tacker contributors,

Just a quick reminder that elections are closing soon, if you haven't
already you should use your right to vote and pick your favourite
candidate!

You have until Aug 07, 2018 23:45 UTC.

Thanks for your time!


Yours Tony.


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

[openstack-dev] [Cyborg] Agent - Conductor update

[Nadathur, Sundar]

Hi,
   The Cyborg agent in a compute node collects information about 
devices from the Cyborg drivers on that node. It then needs to push that 
information to the Cyborg conductor in the controller, which then needs 
to persist it in the Cyborg db and update Placement. Further, the agent 
needs to collect and update this information periodically (or possibly 
in response to notifications) to handle hot add/delete of devices, 
reprogramming (for FPGAs), health failure of devices, etc.


In this morning's call, we discussed how to do this periodic update [1]. 
In particular, we talked about how to compute the difference between the 
previous device configuration in a compute node and the current one, 
whether the agent do should do that diff or the controller, etc. Since 
there are many fields per device, and they are tree-structured, the 
complexity of doing the diff seemed large.


On taking a closer look, however, the amount of computation needed to do 
the update is not huge. Say, for discussion's sake, that the controller 
has a snapshot of the entire device config for a specific compute node, 
i.e. an array of device structures NewConfig[]. It reads the current 
list of devices for that node from the db, CurrentConfig[]. Then the 
controller's logic is like this:


 * Determine the list of devices in NewConfig[] but not in
   CurrentConfig[] (this is a set difference in Python [2]): they are
   the newly added ones. For each newly added device, do a single
   transaction to add all the fields to the db together.
 * Determine the list of devices in CurrentConfig[] but not in
   NewConfig[]: they are the deleted devices.For each such device, do a
   single transaction to delete that entry.
 * For each modified device, compute what has changed, and update that
   alone. This is the per-field diff.

Say each field in the device structure is a string of 100 characters, 
and it takes 1 nanosecond to add, delete or modify a character. So, each 
field takes 100 ns to update (add/delete/modify). Say 20 fields per 
device: so 2 us to add, delete or modify a device. Say 10 devices per 
compute node: so 20 us per node. 500 nodes will take 10 milliseconds. 
So, if each node sends a refresh every second, the controller will spend 
a very small fraction of that time in updating the db, even including 
transaction costs, set difference computation, etc.


This back-of-the-envelope calculation shows that we need not try to 
optimize too early: the agent should send the entire device config over 
to the controller, and let it update the db per-device and per-field.


[1] https://etherpad.openstack.org/p/cyborg-rocky-development
[2] https://docs.python.org/2/library/sets.html

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

[openstack-dev] [nova] StarlingX diff analysis

[Matt Riedemann]

In case you haven't heard, there was this StarlingX thing announced at 
the last summit. I have gone through the enormous nova diff in their 
repo and the results are in a spreadsheet [1]. Given the enormous 
spreadsheet (see a pattern?), I have further refined that into a set of 
high-level charts [2].


I suspect there might be some negative reactions to even doing this type 
of analysis lest it might seem like promoting throwing a huge pile of 
code over the wall and expecting the OpenStack (or more specifically the 
nova) community to pick it up. That's not my intention at all, nor do I 
expect nova maintainers to be responsible for upstreaming any of this.


This is all educational to figure out what the major differences and 
overlaps are and what could be constructively upstreamed from the 
starlingx staging repo since it's not all NFV and Edge dragons in here, 
there are some legitimate bug fixes and good ideas. I'm sharing it 
because I want to feel like my time spent on this in the last week 
wasn't all for nothing.


[1] 
https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing
[2] 
https://docs.google.com/presentation/d/1P-__JnxCFUbSVlEoPX26Jz6VaOyNg-jZbBsmmKA2f0c/edit?usp=sharing


--

Thanks,

Matt

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

Re: [openstack-dev] [tripleo] 3rd party ovb jobs are down

[Wesley Hayutin]

On Mon, Aug 6, 2018 at 12:56 PM Wesley Hayutin  wrote:

> Greetings,
>
> There is currently an unplanned outtage atm for the tripleo 3rd party OVB
> based jobs.
> We will contact the list when there are more details.
>
> Thank you!
>

OK,
I'm going to call an end to the current outtage. We are closely monitoring
the ovb 3rd party jobs.
I'll called for the outtage when we hit [1].  Once I deleted the stack that
moved teh HA routers to back_up state, the networking came back online.

Additionally Kieran and I had to work through a number of instances that
required admin access to remove.
Once those resources  were cleaned up our CI tooling removed the rest of
the stacks in delete_failed status.The stacks in delete_failed status
were holding ip address that were causing new stacks to fail [2]

There are still active issues that could cause OVB jobs to fail.
This connection issues [3] was originaly thought to be DNS, however that
turned out to not be the case.
You may also see your job have a "node_failure" status, Paul has sent
updates about this issue and is working on a patch and integration into rdo
software factory.

The CI team is close to including all the console logs into the regular job
logs, however if needed atm they can be viewed at [5].
We are also adding the bmc to the list of instances that we collect logs
from.

*To summarize* the most recent outtage was infra related and the errors
were swallowed up in the bmc console log that at the time was not available
to users.

We continue to monitor that ovb jobs at http://cistatus.tripleo.org/
The  legacy-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master job is
at a 53% pass rate, it needs to move to a > 85% pass rate to match other
check jobs.

Thanks all!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1570136
[2] http://paste.openstack.org/show/727444/
[3] https://bugs.launchpad.net/tripleo/+bug/1785342
[4] https://review.openstack.org/#/c/584488/
[5] http://38.145.34.41/console-logs/?C=M;O=D






>
> --
>
> Wes Hayutin
>
> Associate MANAGER
>
> Red Hat
>
> 
>
> w hayu...@redhat.comT: +1919 <+19197544114>
> 4232509 IRC:  weshay
> 
>
> View my calendar and check my availability for meetings HERE
> 
>
-- 

Wes Hayutin

Associate MANAGER

Red Hat



w hayu...@redhat.comT: +1919 <+19197544114>4232509
   IRC:  weshay


View my calendar and check my availability for meetings HERE

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

[openstack-dev] [python3] champions, please review the updated process

[Doug Hellmann]

I have updated the README.rst in the goal-tools repository with an
updated process for preparing, proposing, and tracking the zuul
migration patches. I need the other champions to look over the
instructions and let me know if any parts are confusing or incomplete.
Please do that as soon as you can, so we can be prepared to start
generating patches after the final release for Rocky is done.

http://git.openstack.org/cgit/openstack/goal-tools/tree/README.rst#n22

Doug

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

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Zane Bitter]

On 06/08/18 13:11, Thomas Goirand wrote:

On 08/02/2018 10:43 AM, Andrey Kurilin wrote:

 There's also some "raise StopIteration" issues in:
 - ceilometer
 - cinder
 - designate
 - glance
 - glare
 - heat
 - karbor
 - manila
 - murano
 - networking-ovn
 - neutron-vpnaas
 - nova
 - rally


Can you provide any traceback or steps to reproduce the issue for Rally
project ?


I assume Thomas is only trying to run the unit tests, since that's what 
he has to do to verify the package?



I'm not sure there's any. The only thing I know is that it has stop
StopIteration stuff, but I'm not sure if they are part of generators, in
which case they should simply be replaced by "return" if you want it to
be py 3.7 compatible.


I was about to say nobody is doing 'raise StopIteration' where they mean 
'return' until I saw that the Glance tests apparently were :D


The main issue though is when StopIteration is raised by one thing that 
happens to be called from *another* generator. e.g. many of the Heat 
tests that are failing are because we supplied a too-short list of 
side-effects to a mock and calling next() on them raises StopIteration, 
but because the calls were happening from inside a generator the 
StopIterations previously just got swallowed. If no generator were 
involved the test would have failed with the StopIteration exception. 
(Note: this was a bug - either in the code or more likely the tests. The 
purpose of the change in py37 was to expose this kind of bug wherever it 
exists.)



I didn't have time to investigate these, but at least Glance was
affected, and a patch was sent (as well as an async patch). None of them
has been merged yet:

https://review.openstack.org/#/c/586050/
https://review.openstack.org/#/c/586716/

That'd be ok if at least there was some reviews. It looks like nobody
cares but Debian & Ubuntu people... :(

Cheers,

Thomas Goirand (zigo)

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




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

[openstack-dev] [neutron] Bug deputy report week July 30th - August 5th

[Miguel Lavalle]

Dear Neutron Team,

I was the bugs deputy for the week of July 39th - August 6th (inclusive, so
bcafarel has to start on the 7th). Here's the summary of the bugs that were
filed:

High:

https://bugs.launchpad.net/neutron/+bug/1785656
test_internal_dns.InternalDNSTest
fails even though dns-integration extension isn't loaded. Proposed fixes:
https://review.openstack.org/#/c/589247, https://review.openstack.org/#
/c/589255


Medium:

https://bugs.launchpad.net/neutron/+bug/1784837 Test
tempest.scenario.test_security_groups_basic_ops.TestSecurity
GroupsBasicOps.test_in_tenant_traffic fails in
neutron-tempest-dvr-ha-multinode-full job
https://bugs.launchpad.net/neutron/+bug/1784836 Functional tests from
neutron.tests.functional.db.migrations fails randomly
https://bugs.launchpad.net/neutron/+bug/1785582 Connectivity to instance
after L3 router migration from Legacy to HA fails. Assigned to Slawek


Low:

https://bugs.launchpad.net/neutron/+bug/1785025 Install and configure
controller node in Neutron
https://bugs.launchpad.net/neutron/+bug/1784586 Networking guide doesn't
clarify that subnets inherit the RBAC policies of their network. Fix:
https://review.openstack.org/#/c/588844


In discussion:
https://bugs.launchpad.net/neutron/+bug/1784484 intermittent issue getting
assigned MACs for SRIOV nics, causes nova timeout
https://bugs.launchpad.net/neutron/+bug/1784259 Neutron RBAC not working
for multiple extensions
https://bugs.launchpad.net/neutron/+bug/1785615 DNS resolution through
eventlet contact nameservers if there's an IPv4 or IPv6 entry present in
hosts file


RFEs:

https://bugs.launchpad.net/neutron/+bug/1784879 Neutron doesn't update
Designate with some use cases
https://bugs.launchpad.net/neutron/+bug/1784590 neutron-dynamic-routing bgp
agent should have options for MP-BGP
https://bugs.launchpad.net/neutron/+bug/1785608 [RFE] neutron ovs agent
support baremetal port using smart nic


Invalid:

https://bugs.launchpad.net/neutron/+bug/1784950 get_device_details RPC
fails if host not specified
https://bugs.launchpad.net/neutron/+bug/1785189 Floatingip and router
bandwidth speed limit failure


Incomplete:

https://bugs.launchpad.net/neutron/+bug/1785349 policy.json does not
contain rule for auto-allocated-topologies removal
https://bugs.launchpad.net/neutron/+bug/1785539 Some notifications related
to l3 flavor pass context



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

Re: [openstack-dev] [release][requirements][python-magnumclient] Magnumclient FFE

[Matthew Thode]

On 18-08-06 21:37:12, Spyros Trigazis wrote:
> It is constraints only. There is no project
> that requires the new version.
> 
> Spyros
> 
> On Mon, 6 Aug 2018, 19:36 Matthew Thode,  wrote:
> 
> > On 18-08-06 18:34:42, Spyros Trigazis wrote:
> > > Hello,
> > >
> > > I have requested a release for python-magnumclient [0].
> > > Per Doug Hellmann's comment in [0], I am requesting a FFE for
> > > python-magnumclient.
> > >
> >
> > My question to you is if this needs to be a constraints only thing or if
> > there is some project that REQUIRES this new version to work (in which
> > case that project needs to update it's exclusions or minumum).
> >

Has my ack then

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [release][requirements][python-magnumclient] Magnumclient FFE

[Spyros Trigazis]

It is constraints only. There is no project
that requires the new version.

Spyros

On Mon, 6 Aug 2018, 19:36 Matthew Thode,  wrote:

> On 18-08-06 18:34:42, Spyros Trigazis wrote:
> > Hello,
> >
> > I have requested a release for python-magnumclient [0].
> > Per Doug Hellmann's comment in [0], I am requesting a FFE for
> > python-magnumclient.
> >
>
> My question to you is if this needs to be a constraints only thing or if
> there is some project that REQUIRES this new version to work (in which
> case that project needs to update it's exclusions or minumum).
>
> --
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Jimmy McArthur]

A heads up that the Translators are now listed at the bottom of the page 
as well, along with the rest of the paper contributors:


https://www.openstack.org/edge-computing/cloud-edge-computing-beyond-the-data-center?lang=ja_JP

Cheers!
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

thanks for announcement. Great stuff! It looks really great and it's 
easy to navigate. I think a special thanks goes to Sebastian for 
designing the pages. One small remark: have you tried text-align: 
justify? I think it would be a little bit more readable, like a 
science paper (German word is: Ordnung)
I put the projects again on the frontpage of the translation platform, 
so we'll get more translations shortly.


kind regards

Frank

Am 2018-08-02 21:07, schrieb Jimmy McArthur:

The Edge and Containers translations are now live.  As new
translations become available, we will add them to the page.

https://www.openstack.org/containers/
https://www.openstack.org/edge-computing/

Note that the Chinese translation has not been added to Zanata at this
time, so I've left the PDF download up on that page.

Thanks everyone and please let me know if you have questions or 
concerns!


Cheers!
Jimmy

Jimmy McArthur wrote:

Frank,

We expect to have these papers up this afternoon. I'll update this 
thread when we do.


Thanks!
Jimmy

Frank Kloeker wrote:

Hi Sebastian,

okay, it's translated now. In Edge whitepaper is the problem with 
XML-Parsing of the term AT Don't know how to escape this. Maybe 
you will see the warning during import too.


kind regards

Frank

Am 2018-07-30 20:09, schrieb Sebastian Marcet:

Hi Frank,
i was double checking pot file and realized that original pot missed
some parts of the original paper (subsections of the paper) 
apologizes

on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  
wrote:



Hi Jimmy,

from the GUI I'll get this link:

https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center 


[1]

paper version  are only in container whitepaper:


https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack 


[2]

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:
Frank,

We're getting a 404 when looking for the pot file on the Zanata API:

https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing 


[3]

As a result, we can't pull the po files.  Any idea what might be
happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

Korean and German version are now done on the new format. Can you
check publishing?

thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:
Hi all -

Follow up on the Edge paper specifically:

https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 


[4] This is now available. As I mentioned on IRC this morning, it
should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:
Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I indicated that we
would also be moving the Edge paper to HTML so that we could prevent
that additional design resource cost.
On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF,
which we unfortunately didn't have the resources to implement in the
same format.

I really appreciate Akihiro's work on RST-based support on
publishing translated edge computing whitepapers, since
translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on
the RST-based translation.  At the moment, it's just not usable for
the reasons mentioned above.
On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML
based 

Re: [openstack-dev] Paste unmaintained

[Sean McGinnis]

On Mon, Aug 06, 2018 at 09:53:36AM -0500, Lance Bragstad wrote:
> 
> >
> 
> Morgan has been working through the migration since June, and it's been
> quite involved [0]. At one point he mentioned trying to write-up how he
> approached the migration for keystone. I understand that not every
> project structures their APIs the same way, but a high-level guide might
> be helpful for some if the long-term goal is to eventually move off of
> paste (e.g. how we approached it, things that tripped us up, how we
> prepared the code base for flask, et cetera).
> 
> I'd be happy to help coordinate a session or retrospective at the PTG if
> other groups find that helpful.
> 

I would find this very useful. I'm not sure the Cinder team has the resources
to tackle something like this immediately, but having a better understanding of
what would be involved would really help scope the work.

And if we have existing examples to follow and at least an outline of the steps
to do the work, it might be a good low-hanging-fruit type of thing for someone
to tackle if they are looking to get involved.

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

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Sean McGinnis]

> 
> I didn't have time to investigate these, but at least Glance was
> affected, and a patch was sent (as well as an async patch). None of them
> has been merged yet:
> 
> https://review.openstack.org/#/c/586050/
> https://review.openstack.org/#/c/586716/
> 
> That'd be ok if at least there was some reviews. It looks like nobody
> cares but Debian & Ubuntu people... :(
> 

Keep in mind that your priorities are different than everyone elses. There are
large parts of the community still working on Python 3.5 support (our
officially supported Python 3 version), as well as smaller teams overall
working on things like critical bugs.

Unless and until we declare Python 3.7 as our new target (which I don't think
we are ready to do yet), these kinds of patches will be on a best effort basis.

Making sure that duplicate patches are not pushed up will also help increase
the chances that they will eventually make it through as well.

Sean

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

Re: [openstack-dev] [OpenStack-dev][heat][keystone][security sig][all] SSL option for keystone session

[Zane Bitter]

On 06/08/18 00:46, Rico Lin wrote:

Hi all
I would like to trigger a discussion on providing directly SSL content 
for KeyStone session. Since all team using SSL, I believe this maybe 
concerns to other projects as well.


As we consider to implement customize SSL option for Heat remote stack 
[3] (and multicloud support [1]), I'm trying to figure out what is the 
best solution for this. Current SSL option in KeyStone session didn't 
allow us to provide directly CERT/Key string, instead only allow us to 
provide CERT/Key file path. Which is actually a limitation of 
python with the version less than 3.7 ([2]). As we not gonna easily get 
ride of previous python versions, we try to figure out what is the best 
solution we can approach here.


Some way, we can think about, like using pipeline, or create a file, 
encrypted it and send the file path out to KeyStone session.


Would like to hear more from all for any advice or suggestion on how can 
we approach this.


Create a temporary directory using tempfile.mkdtemp() as shown here:

https://security.openstack.org/guidelines/dg_using-temporary-files-securely.html#correct

This probably only needs to happen once per process. (Also I would pass 
mode=0o600 when creating the file instead of using umask().)


Assuming the data gets read only once, then I'd suggest rather than 
using a tempfile, create a named pipe using os.mkfifo(), open it, and 
write the data. Then pass the filename of the FIFO to the SSL lib. Close 
it again after and remove the pipe.



[1] https://etherpad.openstack.org/p/ptg-rocky-multi-cloud
[2] https://www.python.org/dev/peps/pep-0543/
[3] https://review.openstack.org/#/c/480923/
  --
May The Force of OpenStack Be With You,
*/Rico Lin
/*irc: ricolin





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




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

[openstack-dev] The state of the ironic universe - August 6th, 2018

[Julia Kreger]

News!
=
In the past month we released ironic 11.0 and now this week we expect
to release ironic 11.1.

With 11.1, ironic has:

* The ``deploy_steps`` framework in order to give better control over
what consists of a deployment.
* BIOS settings management interfaces for the ``ilo`` and ``irmc``
hardware types.
* Ramdisk deploy interface has merged. We await your bug reports!
* Conductors can now be grouped into specific failure domains with
specific nodes assigned to those failure domains. This allows for an
operator to configure a conductor in data center A to manage only the
hardware in data center A, and not data center B.
* Capability has been added to the API to allow driver interface
values to be reset to the conductor default values when the driver
name is being changed.
* Support for partition images with ppc64le hardware has merged.
Previously operators could only use whole disk images on that
architecture.
* Out-of-band RAID configuration is now available with the ``irmc``
hardware type.
* Several bug fixes related to cleaning, PXE, and UEFI booting.

In slightly depressing news the ``xclarity`` hardware type has been
deprecated. This is due to the fact the third-party CI for the
hardware type has not yet been established. The team working on the
hardware type is continuing to work on getting CI up and running, and
we expect to rescind the deprecation in the next release of ironic.

Stein Planning
--

Our Stein planning etherpad[0] has had some activity and we have
started to started to place procedural -2s on major changes which will
impact the Rocky release. Expect these to be removed once we've
released Ironic 11.1.

Recent New Specifications
=

* Support for SmartNICs[1]

* Rework inspector boot mangement[2]

Specifications starting to see activity
===

* Make IPA to ironic API communication optional[3]

* Cleanhold state to enable cleaning steps collection [4]

Recently merged specifications
==

* Owner information storage[5]

* Direct Deploy with local HTTP server[6]



[0]: https://etherpad.openstack.org/p/ironic-stein-ptg

[1]: https://review.openstack.org/582767

[2]: https://review.openstack.org/589230

[3]: https://review.openstack.org/#/c/212206

[4]: https://review.openstack.org/507910

[5]: https://review.openstack.org/560089

[6]: https://review.openstack.org/504039

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

[openstack-dev] zaqar 7.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/zaqar/

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

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

http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/rocky

Release notes for zaqar can be found at:

http://docs.openstack.org/releasenotes/zaqar/




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

[openstack-dev] zaqar-ui 5.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for zaqar-ui for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/zaqar-ui/

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

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

http://git.openstack.org/cgit/openstack/zaqar-ui/log/?h=stable/rocky

Release notes for zaqar-ui can be found at:

http://docs.openstack.org/releasenotes/zaqar-ui/

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

https://bugs.launchpad.net/zaqar-ui

and tag it *rocky-rc-potential* to bring it to the zaqar-ui
release crew's attention.


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

[openstack-dev] Denver PTG Registration Price Increases on August 23

[Kendall Waters]

Hi everyone,

The September 2018 PTG in Denver is right around the corner! Friendly reminder 
that ticket prices will increase to USD $599 on August 22 at 11:59pm PT (August 
23 at 6:59 UTC). So purchase your tickets before the price increases. Register 
here: https://denver2018ptg.eventbrite.com 


Our discounted hotel block is filling up and will sell out. The last date to 
book in the hotel block is August 20 so book now here: www.openstack.org/ptg 


If you have any questions, please email p...@openstack.org 
.

Cheers,
Kendall 

Kendall Waters
OpenStack Marketing & Events
kend...@openstack.org



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

Re: [openstack-dev] [release][requirements][python-magnumclient] Magnumclient FFE

[Matthew Thode]

On 18-08-06 18:34:42, Spyros Trigazis wrote:
> Hello,
> 
> I have requested a release for python-magnumclient [0].
> Per Doug Hellmann's comment in [0], I am requesting a FFE for
> python-magnumclient.
> 

My question to you is if this needs to be a constraints only thing or if
there is some project that REQUIRES this new version to work (in which
case that project needs to update it's exclusions or minumum).

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [tripleo] EOL process for newton branches

[Andreas Jaeger]

Tony,

On 2018-07-19 06:59, Tony Breeds wrote:

On Wed, Jul 18, 2018 at 08:08:16PM -0400, Emilien Macchi wrote:

Option 2, EOL everything.
Thanks a lot for your help on this one, Tony.


No problem.

I've created:
  https://review.openstack.org/583856
to tag final releases for tripleo deliverables and then mark them as
EOL.


This one has merged now.



Once that merges we can arrange for someone, with appropriate
permissions to run:

# EOL repos belonging to tripleo
eol_branch.sh -- stable/newton newton-eol \
  openstack/instack openstack/instack-undercloud \
  openstack/os-apply-config openstack/os-collect-config \
  openstack/os-net-config openstack/os-refresh-config \
  openstack/puppet-tripleo openstack/python-tripleoclient \
  openstack/tripleo-common openstack/tripleo-heat-templates \
  openstack/tripleo-image-elements \
  openstack/tripleo-puppet-elements openstack/tripleo-ui \
  openstack/tripleo-validations


Tony, will you coordinate with infra to run this yourself again - or let 
them run it for you, please?


Note that we removed the script with retiring release-tools repo, I 
propose to readd with https://review.openstack.org/589236 and
https://review.openstack.org/589237 and would love your review on these, 
please. I want to be sure that we import the right version...


thanks,
Andreas



Yours Tony.



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




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


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

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Thomas Goirand]

On 08/02/2018 10:43 AM, Andrey Kurilin wrote:
> There's also some "raise StopIteration" issues in:
> - ceilometer
> - cinder
> - designate
> - glance
> - glare
> - heat
> - karbor
> - manila
> - murano
> - networking-ovn
> - neutron-vpnaas
> - nova
> - rally
> 
> 
> Can you provide any traceback or steps to reproduce the issue for Rally
> project ?

I'm not sure there's any. The only thing I know is that it has stop
StopIteration stuff, but I'm not sure if they are part of generators, in
which case they should simply be replaced by "return" if you want it to
be py 3.7 compatible.

I didn't have time to investigate these, but at least Glance was
affected, and a patch was sent (as well as an async patch). None of them
has been merged yet:

https://review.openstack.org/#/c/586050/
https://review.openstack.org/#/c/586716/

That'd be ok if at least there was some reviews. It looks like nobody
cares but Debian & Ubuntu people... :(

Cheers,

Thomas Goirand (zigo)

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

[openstack-dev] [tripleo] 3rd party ovb jobs are down

[Wesley Hayutin]

Greetings,

There is currently an unplanned outtage atm for the tripleo 3rd party OVB
based jobs.
We will contact the list when there are more details.

Thank you!

-- 

Wes Hayutin

Associate MANAGER

Red Hat



w hayu...@redhat.comT: +1919 <+19197544114>4232509
   IRC:  weshay


View my calendar and check my availability for meetings HERE

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

[openstack-dev] UC nomination period is now open!

[Ed Leafe]

As the subject says, the nomination period for the summer[0] User Committee 
elections is now open. 

Any individual member of the Foundation who is an Active User Contributor (AUC) 
can propose their candidacy (except the three sitting UC members elected in the 
previous election).

Self-nomination is common; no third party nomination is required. Nominations 
are made by sending an email to the user-commit...@lists.openstack.org 
mailing-list, with the subject: “UC candidacy” by August 17, 05:59 UTC. The 
email can include a description of the candidate platform. The candidacy is 
then confirmed by one of the election officials, after verification of the 
electorate status of the candidate.

[0] Sorry, southern hemisphere people!


-- Ed Leafe






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

Re: [openstack-dev] [releease][ptl] Missing and forced releases

[Spyros Trigazis]

Hello,

I have requested a release for python-magnumclient [0].
Per Doug Hellmann's comment in [0], I am requesting a FFE for
python-magnumclient.

Apologies for the inconvenience,
Spyros

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


On Fri, 3 Aug 2018 at 18:52, Sean McGinnis  wrote:

> Today the release team reviewed the rocky deliverables and their releases
> done
> so far this cycle. There are a few areas of concern right now.
>
> Unreleased cycle-with-intermediary
> ==
> There is a much longer list than we would like to see of
> cycle-with-intermediary deliverables that have not done any releases so
> far in
> Rocky. These deliverables should not wait until the very end of the cycle
> to
> release so that pending changes can be made available earlier and there
> are no
> last minute surprises.
>
> For owners of cycle-with-intermediary deliverables, please take a look at
> what
> you have merged that has not been released and consider doing a release
> ASAP.
> We are not far from the final deadline for these projects, but it would
> still
> be good to do a release ahead of that to be safe.
>
> Deliverables that miss the final deadline will be at risk of being dropped
> from
> the Rocky coordinated release.
>
> Unrelease client libraries
> ==
> The following client libraries have not done a release:
>
> python-cloudkittyclient
> python-designateclient
> python-karborclient
> python-magnumclient
> python-searchlightclient*
> python-senlinclient
> python-tricircleclient
>
> The deadline for client library releases was last Thursday, July 26. This
> coming Monday the release team will force a release on HEAD for these
> clients.
>

The release I proposed in [0] is the current HEAD of the master branch.


>
> * python-searchlight client is currently planned on being dropped due to
>   searchlight itself not having met the minimum of two milestone releases
>   during the rocky cycle.
>
> Missing milestone 3
> ===
> The following projects missed tagging a milestone 3 release:
>
> cinder
> designate
> freezer
> mistral
> searchlight
>
> Following policy, a milestone 3 tag will be forced on HEAD for these
> deliverables on Monday.
>
> Freezer and searchlight missed previous milestone deadlines and will be
> dropped
> from the Rocky coordinated release.
>
> If there are any questions or concerns, please respond here or get ahold of
> someone from the release management team in the #openstack-release channel.
>
> --
> Sean McGinnis (smcginnis)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Dougal Matthews]

+1

On 6 August 2018 at 16:28, Alex Schultz  wrote:

> +1
>
> On Mon, Aug 6, 2018 at 7:19 AM, Bogdan Dobrelya 
> wrote:
> > +1
> >
> > On 8/1/18 1:31 PM, Giulio Fidente wrote:
> >>
> >> Hi,
> >>
> >> I would like to propose Lukas Bezdicka core on TripleO.
> >>
> >> Lukas did a lot work in our tripleoclient, tripleo-common and
> >> tripleo-heat-templates repos to make FFU possible.
> >>
> >> FFU, which is meant to permit upgrades from Newton to Queens, requires
> >> in depth understanding of many TripleO components (for example Heat,
> >> Mistral and the TripleO client) but also of specific TripleO features
> >> which were added during the course of the three releases (for example
> >> config-download and upgrade tasks). I believe his FFU work to have been
> >> very challenging.
> >>
> >> Given his broad understanding, more recently Lukas started helping doing
> >> reviews in other areas.
> >>
> >> I am so sure he'll be a great addition to our group that I am not even
> >> looking for comments, just votes :D
> >>
> >
> >
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Alex Schultz]

+1

On Mon, Aug 6, 2018 at 7:19 AM, Bogdan Dobrelya  wrote:
> +1
>
> On 8/1/18 1:31 PM, Giulio Fidente wrote:
>>
>> Hi,
>>
>> I would like to propose Lukas Bezdicka core on TripleO.
>>
>> Lukas did a lot work in our tripleoclient, tripleo-common and
>> tripleo-heat-templates repos to make FFU possible.
>>
>> FFU, which is meant to permit upgrades from Newton to Queens, requires
>> in depth understanding of many TripleO components (for example Heat,
>> Mistral and the TripleO client) but also of specific TripleO features
>> which were added during the course of the three releases (for example
>> config-download and upgrade tasks). I believe his FFU work to have been
>> very challenging.
>>
>> Given his broad understanding, more recently Lukas started helping doing
>> reviews in other areas.
>>
>> I am so sure he'll be a great addition to our group that I am not even
>> looking for comments, just votes :D
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tempest] Small doubt in Tempest setup

[Goutham Pratapa]

stestr worked thanks but im getting the same error for

ostestr -l

any idea on what to do ??


On Mon, Aug 6, 2018 at 7:27 PM, Attila Fazekas  wrote:

> I was tried to be quick and become wrong. ;-)
>
> Here are the working ways:
>
> On Mon, Aug 6, 2018 at 3:49 PM, Attila Fazekas 
> wrote:
>
>> Please use ostestr or stestr instead of testr.
>>
>> $ git clone https://github.com/openstack/tempest
>> $ cd tempest/
>> $ stestr init
>> $ stestr list
>>
>> $ git clone https://github.com/openstack/tempest
>> $ cd tempest/
>> $ ostestr -l #old way, also worked, does to steps
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] Paste unmaintained

[Thomas Herve]

On Thu, Aug 2, 2018 at 4:27 PM, Doug Hellmann  wrote:
> Excerpts from Stephen Finucane's message of 2018-08-02 15:11:25 +0100:
>> tl;dr: It seems Paste [1] may be entering unmaintained territory and we
>> may need to do something about it.
>>
>> I was cleaning up some warning messages that nova was issuing this
>> morning and noticed a few coming from Paste. I was going to draft a PR
>> to fix this, but a quick browse through the Bitbucket project [2]
>> suggests there has been little to no activity on that for well over a
>> year. One particular open PR - "Python 3.7 support" - is particularly
>> concerning, given the recent mailing list threads on the matter.
>>
>> Given that multiple projects are using this, we may want to think about
>> reaching out to the author and seeing if there's anything we can do to
>> at least keep this maintained going forward. I've talked to cdent about
>> this already but if anyone else has ideas, please let me know.
>>
>> Stephen
>>
>> [1] https://pypi.org/project/Paste/
>> [2] https://bitbucket.org/ianb/paste/
>> [3] https://bitbucket.org/ianb/paste/pull-requests/41
>>
>
> The last I heard, a few years ago Ian moved away from Python to
> JavaScript as part of his work at Mozilla. The support around
> paste.deploy has been sporadic since then, and was one of the reasons
> we discussed a goal of dropping paste.ini as a configuration file.
>
> Do we have a real sense of how many of the projects below, which
> list Paste in requirements.txt, actually use it directly or rely
> on it for configuration?
>
> Doug
>
> $ beagle search --ignore-case --file requirements.txt 'paste[><=! ]'
> +++--++
> | Repository | Filename   
> | Line | Text   |
> +++--++
> | airship-armada | requirements.txt   
> |8 | Paste>=2.0.3   |
> | airship-deckhand   | requirements.txt   
> |   12 | Paste # MIT|
> | anchor | requirements.txt   
> |9 | Paste # MIT|
> | apmec  | requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | barbican   | requirements.txt   
> |   22 | Paste>=2.0.2 # MIT |
> | cinder | requirements.txt   
> |   37 | Paste>=2.0.2 # MIT |
> | congress   | requirements.txt   
> |   11 | Paste>=2.0.2 # MIT |
> | designate  | requirements.txt   
> |   25 | Paste>=2.0.2 # MIT |
> | ec2-api| requirements.txt   
> |   20 | Paste # MIT|
> | freezer-api| requirements.txt   
> |8 | Paste>=2.0.2 # MIT |
> | gce-api| requirements.txt   
> |   16 | Paste>=2.0.2 # MIT |
> | glance | requirements.txt   
> |   31 | Paste>=2.0.2 # MIT |
> | glare  | requirements.txt   
> |   29 | Paste>=2.0.2 # MIT |
> | karbor | requirements.txt   
> |   28 | Paste>=2.0.2 # MIT |
> | kingbird   | requirements.txt   
> |7 | Paste>=2.0.2 # MIT |
> | manila | requirements.txt   
> |   30 | Paste>=2.0.2 # MIT |
> | meteos | requirements.txt   
> |   29 | Paste # MIT|
> | monasca-events-api | requirements.txt   
> |6 | Paste # MIT|
> | monasca-log-api| requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | murano | requirements.txt   
> |   28 | Paste>=2.0.2 # MIT |
> | neutron| requirements.txt   
> |6 | Paste>=2.0.2 # MIT |
> | nova   | requirements.txt   
> |   19 | Paste>=2.0.2 # MIT |
> | novajoin  

Re: [openstack-dev] [tempest] Small doubt in Tempest setup

[Goutham Pratapa]

Done thanks afazekas

Thanks
Goutham

On Mon, 6 Aug 2018 at 7:27 PM, Attila Fazekas  wrote:

> I was tried to be quick and become wrong. ;-)
>
> Here are the working ways:
>
> On Mon, Aug 6, 2018 at 3:49 PM, Attila Fazekas 
> wrote:
>
>> Please use ostestr or stestr instead of testr.
>>
>> $ git clone https://github.com/openstack/tempest
>> $ cd tempest/
>> $ stestr init
>> $ stestr list
>>
>> $ git clone https://github.com/openstack/tempest
>> $ cd tempest/
>> $ ostestr -l #old way, also worked, does to steps
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Cheers !!!
Goutham Pratapa
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Paste unmaintained

[Lance Bragstad]

On 08/02/2018 09:36 AM, Chris Dent wrote:
> On Thu, 2 Aug 2018, Stephen Finucane wrote:
>
>> Given that multiple projects are using this, we may want to think about
>> reaching out to the author and seeing if there's anything we can do to
>> at least keep this maintained going forward. I've talked to cdent about
>> this already but if anyone else has ideas, please let me know.
>
> I've sent some exploratory email to Ian, the original author, to get
> a sense of where things are and whether there's an option for us (or
> if for some reason us wasn't okay, me) to adopt it. If email doesn't
> land I'll try again with other media
>
> I agree with the idea of trying to move away from using it, as
> mentioned elsewhere in this thread and in IRC, but it's not a simple
> step as at least in some projects we are using paste files as
> configuration that people are allowed (and do) change. Moving away
> from that is the hard part, not figuring out how to load WSGI
> middleware in a modern way.

++

Keystone has been battling this specific debate for several releases.
The mutable configuration goal in addition to some much needed technical
debt cleanup was the final nail. Long story short, moving off of paste
eases the implementations for initiatives we've had in the pipe for a
long time. We started an effort to move to flask in Rocky.

Morgan has been working through the migration since June, and it's been
quite involved [0]. At one point he mentioned trying to write-up how he
approached the migration for keystone. I understand that not every
project structures their APIs the same way, but a high-level guide might
be helpful for some if the long-term goal is to eventually move off of
paste (e.g. how we approached it, things that tripped us up, how we
prepared the code base for flask, et cetera).

I'd be happy to help coordinate a session or retrospective at the PTG if
other groups find that helpful.

[0]
https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [tc] Technical Committee status update for 6 August

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- extra ATCs for I18n team: https://review.openstack.org/586751
- move security team repos to the SIG: https://review.openstack.org/586896 

== Leaderless teams after Stein PTL elections ==

We had 7 teams without any volunteers to serve as PTL for the Stein
cycle. The TC is handling each on a case-by-case basis, working
with the project teams and considering the broader context of
activity over the last cycle.

Omer Anson has volunteered to be PTL for the Dragonflow team. Omer
is the current PTL, so I do not anticipate any issues with the TC
confirming him to serve again.

Sam Yaple has agreed to serve as the PTL for the Loci team. Sam is
active in the project, so I do not anticipate any issues with his
confirmation.

Dirk Mueller has volunteered to serve as packaging-rpm team PTL. I do
not anticipate any issues with his confirmation, either.

- https://review.openstack.org/#/c/588617/

Jeremy and Julia are going to work with the RefStack team and Interop
working group to settle the ownership of the repositories currently
owned by the RefStack team. I anticipate the RefStack team being
dissolved when those new owners are found for those repositories.

Dariusz Krol has volunteered to serve as Trove team PTL. The TC
considered Dariusz's status carefully, because he is not currently
a contributor to Trove, but the Trove team seems willing to accept
Dariusz, so I anticipate the TC accepting him as PTL.

- https://review.openstack.org/#/c/588510/

Paul and Chris are working to contact the Winstackers team about
whether they want to find a volunteer to serve as PTL, or if the
team should be dissolved.

In addition to missing the PTL election, the Freezer and Searchlight
teams missed enough deadlines during the cycle for the release
management team to drop them from the Rocky release. We do not want
to continue to list teams as official if the projects are not
maintained and the teams are not active in the community. Given the
apparent lack of participation in community processes, we are
considering removing both teams from governance. We will not be
rushing to make a decision, however, so if you are interested in
either project please join the relevant thread with your input.

- removing both from the rocky release: 
https://review.openstack.org/#/c/588605/ 
- removing freezer from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132873.html and 
https://review.openstack.org/#/c/588645/
- removing searchlight from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132874.html and 
https://review.openstack.org/#/c/588644/

== Ongoing Discussions ==

Ian has updated his proposals to change the project testing interface
to support PDF generation and documentation translation. These need
to be reviewed by folks familiar with the tools and processes.

- https://review.openstack.org/#/c/572559/
- https://review.openstack.org/#/c/588110/

Sean has posted a new draft of the goal to create automated upgrade
checker tools.

- https://review.openstack.org/#/c/585491/

I have a patch to remove expired extra ATCs from several projects.
"Extra ATC" status is time-limited, just as regular ATC status is. This
patch is just housekeeping to remove some names that have expired.

- https://review.openstack.org/#/c/588586/

The TC is planning 2 meetings during the week of the PTG. The
proposed agendas are up for comment.

- https://etherpad.openstack.org/p/tc-stein-ptg

== TC member actions/focus/discussions for the coming week(s) ==

The PTG is approaching quickly. Please complete any remaining team
health checks.

Besides the items listed above as ongoing discussions, we have
several other governance reviews open without sufficient votes to
be approved. Please review.

- https://review.openstack.org/#/q/project:openstack/governance+is:open

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

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

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string 

Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Dave Wilde]

+1


From: Markos Chandras 
Sent: Monday, August 6, 2018 4:35:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as 
core reviewer

On 07/30/2018 11:16 AM, jean-phili...@evrard.me wrote:
> Hello everyone,
>
> I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
> OpenStack-Ansible.
> The BBC team [1] has been very active recently across the board, but worked 
> heavily in our ops repo, making sure the experience is complete for operators.
>
> I value Jonathan's opinion (I remember the storage backend conversations for 
> lxc/systemd-nspawn!), and I'd like this positive trend to continue. On top of 
> it Jonathan has been recently reviewing quite a series of patches, and is 
> involved into some of our important work: bringing the Bionic support.
>
> Best regards,
> Jean-Philippe Evrard (evrardjp)

+1

Jonathan will be a valuable addition to the project.

--
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

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

Re: [openstack-dev] [tempest] Small doubt in Tempest setup

[Attila Fazekas]

I was tried to be quick and become wrong. ;-)

Here are the working ways:

On Mon, Aug 6, 2018 at 3:49 PM, Attila Fazekas  wrote:

> Please use ostestr or stestr instead of testr.
>
> $ git clone https://github.com/openstack/tempest
> $ cd tempest/
> $ stestr init
> $ stestr list
>
> $ git clone https://github.com/openstack/tempest
> $ cd tempest/
> $ ostestr -l #old way, also worked, does to steps
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tempest] Small doubt in Tempest setup

[Attila Fazekas]

Please use ostestr or stestr instead of testr.

$ git clone https://github.com/openstack/tempest
$ cd tempest/
$ stestr --list

$ ostestr -l #old way, also worked

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

Re: [openstack-dev] [nova] How to debug no valid host failures with placement

[Jay Pipes]

On 08/04/2018 07:35 PM, Michael Glasgow wrote:

On 8/2/2018 7:27 PM, Jay Pipes wrote:
It's not an exception. It's normal course of events. NoValidHosts 
means there were no compute nodes that met the requested resource 
amounts.


To clarify, I didn't mean a python exception.


Neither did I. I was referring to exceptional behaviour, not a Python 
exception.



I concede that I should've chosen a better word for the type of
object I have in mind.

If a SELECT statement against an Oracle DB returns 0 rows, is that an 
exception? No. Would an operator need to re-send the SELECT statement 
with an EXPLAIN SELECT in order to get information about what indexes 
were used to winnow the result set (to zero)? Yes. Either that, or the 
operator would need to gradually re-execute smaller SELECT statements 
containing fewer filters in order to determine which join or predicate 
caused a result set to contain zero rows.


I'm not sure if this analogy fully appreciates the perspective of the 
operator.  You're correct of course that if you select on a db and the 
correct answer is zero rows, then zero rows is the right answer, 100% of 
the time.


Whereas what I thought we meant when we talk about "debugging no valid 
host failures" is that zero rows is *not* the right answer, and yet 
you're getting zero rows anyway.


No, "debugging no valid host failures" doesn't mean that zero rows is 
the wrong answer. It means "find out why Nova thinks there's nowhere 
that my instance will fit".



So yes, absolutely with an Oracle DB you would get an ORA-X
exception in that case, along with a trace file that told you where
things went off the rails.  Which is exactly what we don't have
here.
That is precisely the opposite of what I was saying. Again, getting no 
results is *not* an error. It's normal behaviour and indicates there 
were no compute hosts that met the requirements of the request. This is 
not an error or exceptional behaviour. It's simply the result of a query 
against the placement database.


If you get zero rows returned, that means you need to determine what 
part of your request caused the winnowed result set to go from >0 rows 
to 0 rows.


And what we've been discussing is exactly the process by which such an 
investigation could be done. There are two options: do the investigation 
*inline* as part of the original request or do it *offline* after the 
original request returns 0 rows.


Doing it inline means splitting the large query we currently construct 
into multiple queries (for each related group of requested resources 
and/or traits) and logging the number of results grabbed for each of 
those queries.


Doing if offline means developing some diagnostic tool that an operator 
could run (similar to what Windriver did with [1]). The issue with that 
is that the diagnostic tool can only represent the resource usage at the 
time the diagnostic tool was run, not when the original request that 
returned 0 rows ran.


[1] 
https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-94f87e728df6465becce5241f3da53c8R330


If I understand your perspective correctly, it's basically that 
placement is working as designed, so there's nothing more to do except 
pore over debug output.  Can we consider:


  (1) that might not always be true if there are bugs


Bugs in the placement service are an entirely separate issue. They do 
occur, of course, but we're not talking about that here.


  (2) even when it is technically true, from the user's perspective, I'd 
posit that it's rare that a user requests an instance with the express 
intent of not launching an instance. (?)  If they're "debugging" this 
issue, it means there's a misconfiguration or some unexpected state that 
they have to go find.


Depends on what you have in mind as a "user". If I launch an instance in 
an AWS region, I'd be very surprised if the service told me there was 
nowhere to place my instance unless of course I'd asked it to launch an 
instance with requirements that exceeded AWS' ability to launch.


If you're talking about a user of a private IT cloud with a single rack 
of compute hosts, that user might very well expect to see a return of 
"sorry mate, there's nowhere to put your request right now.".


There is no explicit or implicit SLA or guarantee that Nova needs to 
somehow create a place to put an instance when no such place exists to 
put the instance.


Best,
-jay

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

[openstack-dev] [tempest] Small doubt in Tempest setup

[Goutham Pratapa]

Hi all,

This is regarding Tempest setup I have cloned and setup my tempest i could
run my tests with

'*nosetests*' also but when i try  to run with *testr* im getting


*$ testr list-tests *


*No .testr.conf config file*

any idea why it is occurring and any idea how to fix it will really help..

Thanks in advance.

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

[openstack-dev] [cyborg] Cyborg Driver Sub Team Meeting on ZOOM this week

[Li Liu]

 Hi Team,

The Cyborg Driver Sub Team Meeting will be using ZOOM this week at
10AM Eastern Time Monday

The Joining url is
https://zoom.us/j/236172152


-- 
Thank you

Regards

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

[openstack-dev] [cyborg] Cyborg Driver Sub Team Meeting on ZOOM this week

[Li Liu]

Hi Team,

The Cyborg Driver Sub Team Meeting will be using ZOOM this week at
10AM Eastern Time Monday

The Joining url is




-- 
Thank you

Regards

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

Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Bogdan Dobrelya]

+1

On 8/1/18 1:31 PM, Giulio Fidente wrote:

Hi,

I would like to propose Lukas Bezdicka core on TripleO.

Lukas did a lot work in our tripleoclient, tripleo-common and
tripleo-heat-templates repos to make FFU possible.

FFU, which is meant to permit upgrades from Newton to Queens, requires
in depth understanding of many TripleO components (for example Heat,
Mistral and the TripleO client) but also of specific TripleO features
which were added during the course of the three releases (for example
config-download and upgrade tasks). I believe his FFU work to have been
very challenging.

Given his broad understanding, more recently Lukas started helping doing
reviews in other areas.

I am so sure he'll be a great addition to our group that I am not even
looking for comments, just votes :D




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-05-14 08:52:08 -0400:
> Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
> > Excerpts from Doug Hellmann's message of 2018-03-22 16:16:06 -0400:
> > > Excerpts from Doug Hellmann's message of 2018-03-21 16:02:06 -0400:
> > > > Excerpts from Doug Hellmann's message of 2018-03-15 07:03:11 -0400:
> > > > > 
> > > > > TL;DR
> > > > > -
> > > > > 
> > > > > Let's stop copying exact dependency specifications into all our
> > > > > projects to allow them to reflect the actual versions of things
> > > > > they depend on. The constraints system in pip makes this change
> > > > > safe. We still need to maintain some level of compatibility, so the
> > > > > existing requirements-check job (run for changes to requirements.txt
> > > > > within each repo) will change a bit rather than going away completely.
> > > > > We can enable unit test jobs to verify the lower constraint settings
> > > > > at the same time that we're doing the other work.
> > > > 
> > > > The new job definition is in https://review.openstack.org/555034 and I
> > > > have updated the oslo.config patch I mentioned before to use the new job
> > > > instead of one defined in the oslo.config repo (see
> > > > https://review.openstack.org/550603).
> > > > 
> > > > I'll wait for that job patch to be reviewed and approved before I start
> > > > adding the job to a bunch of other repositories.
> > > > 
> > > > Doug
> > > 
> > > The job definition for openstack-tox-lower-constraints [1] was approved
> > > today (thanks AJaegar and pabelenger).
> > > 
> > > I have started proposing the patches to add that job to the repos listed
> > > in openstack/requirements/projects.txt using the topic
> > > "requirements-stop-syncing" [2]. I hope to have the rest of those
> > > proposed by the end of the day tomorrow, but since they have to run in
> > > batches I don't know if that will be possible.
> > > 
> > > The patch to remove the update proposal job is ready for review [3].
> > > 
> > > As is the patch to allow project requirements to diverge by changing the
> > > rules in the requirements-check job [4].
> > > 
> > > We ran into a snag with a few of the jobs for projects that rely on
> > > having service projects installed. There have been a couple of threads
> > > about that recently, but Monty has promised to start another one to
> > > provide all of the necessary context so we can fix the issues and move
> > > ahead.
> > > 
> > > Doug
> > > 
> > 
> > All of the patches to define the lower-constraints test jobs have been
> > proposed [1], and many have already been approved and merged (thank you
> > for your quick reviews).
> > 
> > A few of the jobs are failing because the projects depend on installing
> > some other service from source. We will work out what to do with those
> > when we solve that problem in a more general way.
> > 
> > A few of the jobs failed because the dependencies were wrong. In a few
> > cases I was able to figure out what was wrong, but I can use some help
> > from project teams more familiar with the code bases to debug the
> > remaining failures.
> > 
> > In a few cases projects didn't have python 3 unit test jobs, so I
> > configured the new job to use python 2. Teams should add a step to their
> > python 3 migration plan to update the version of python used in the new
> > job, when that is possible.
> > 
> > I believe we are now ready to proceed with updating the
> > requirements-check job to relax the rules about which changes are
> > allowed [2].
> > 
> > Doug
> > 
> > [1] 
> > https://review.openstack.org/#/q/topic:requirements-stop-syncing+status:open
> > [2] https://review.openstack.org/555402
> 
> We still have about 50 open patches related to adding the
> lower-constraints test job. I'll keep those open until the third
> milestone of the Rocky development cycle, and then abandon the rest to
> clear my gerrit view so it is usable again.
> 
> If you want to add lower-constraints tests to your project and have
> an open patch in the list [1], please take it over and fix the
> settings then approve the patch (the fix usually involves making
> the values in lower-constraints.txt match the values in the various
> requirements.txt files).
> 
> If you don't want the job, please leave a comment on the patch to
> tell me and I will abandon it.
> 
> Doug

As mentioned in my earlier email, I have abandoned the ~30 reviews
that remained open this morning. Please do feel free to restore
those and take them over if you want the job.

Doug

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

[openstack-dev] [ironic] Stein PTG Planning Etherpad

[Julia Kreger]

Greetings everyone,

A few weeks ago I created an etherpad[1] to begin discussion of ideas
and thoughts for items to discuss during the PTG. I've raised this
during our meetings, but not yet raised it to the mailing list.

If you are interested, please feel free to add discussion items,
comment, or provide additional context if it is something you care
about. Please do so by August 23rd.

Thanks!
-Julia

[1]: https://etherpad.openstack.org/p/ironic-stein-ptg

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

Re: [openstack-dev] [release] Release countdown for week R-3, August 6-10

[Dmitry Tantsur]

On 08/03/2018 06:40 PM, Sean McGinnis wrote:

On Fri, Aug 03, 2018 at 11:23:56AM -0500, Sean McGinnis wrote:

-



More information on deadlines since we appear to have some conflicting
information documented. According to the published release schedule:

https://releases.openstack.org/rocky/schedule.html#r-finalrc

we stated intermediary releases had to be done by the final RC date. So based
on that, cycle-with-intermediary projects have until August 20 to do their
final release.


Another hint though: if your project uses grenade, you probably want to have 
stable/rocky at the same time as everyone else.




Of course, doing before that deadline is highly encouraged to make sure there
are not any last minute problems to work through, if at all possible.



Upcoming Deadlines & Dates
--

RC1 deadline: August 9

cycle-with-intermediary deadline: August 20





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




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

[openstack-dev] [opensatck-dev][qa][barbican][novajoin][networking-fortinet][vmware-nsx] Dependency of Tempest changes

[Ghanshyam Mann]

Hi All,

Tempest patch [1] removes the deprecated config option for volume v1 API and it 
has dependency on may plugins. I have proposed the patches to each plugins 
using that option [2] to stop using that option so that their gate will not be 
broken if Tempest patch merge. Also I have made Tempest patch dependency on 
each plugins commit. Many of those dependent patch has merged but 4 patches are 
still hanging around  since long time which is blocking Tempest change to get 
merge. 

 Below are the plugins which have not merged the changes:
   barbican-tempest-plugin - https://review.openstack.org/#/c/573174/ 
   novajoin-tempest-plugin - https://review.openstack.org/#/c/573175/ 
   networking-fortinet - https://review.openstack.org/#/c/573170/   
   vmware-nsx-tempest-plugin - https://review.openstack.org/#/c/573172/ 

I want to merge this tempest patch in Rocky release which I am planing to do in 
next week. To make that happen we have to merge the Tempest patch soon. If 
above patches are not merged by plugins team within 2-3 days which means those 
plugins might not be active or do not care for gate, I am going to remove their 
dependency on Tempest patch and merge that.

[1] https://review.openstack.org/#/c/573135/ 
[2] 
https://review.openstack.org/#/q/topic:remove-support-of-cinder-v1-api+(status:open+OR+status:merged)

-gmann





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

Re: [openstack-dev] [mistral] Clearing out old gerrit reviews

[Renat Akhmerov]

Awesome! We need to do it periodically :) It’ll be easier to sort out patches.

Thanks

Renat Akhmerov
@Nokia
On 6 Aug 2018, 16:24 +0700, Dougal Matthews , wrote:
>
>
> > On 3 August 2018 at 10:45, Dougal Matthews  wrote:
> > > > On 9 July 2018 at 16:13, Dougal Matthews  wrote:
> > > > > Hey folks,
> > > > >
> > > > > I'd like to propose that we start abandoning old Gerrit reviews.
> > > > >
> > > > > This report shows how stale and out of date some of the reviews are:
> > > > > http://stackalytics.com/report/reviews/mistral-group/open
> > > > >
> > > > > I would like to initially abandon anything without any activity for a 
> > > > > year, but we might want to consider a shorter limit - maybe 6 months. 
> > > > > Reviews can be restored, so the risk is low.
> > > > >
> > > > > What do you think? Any objections or counter suggestions?
> > > > >
> > > > > If I don't hear any complaints, I'll go ahead with this next week (or 
> > > > > maybe the following week).
> > > >
> > > > That time line was ambitious. I didn't get started :-)
> > > >
> > > > However, I did decide it would be best to formalise this plan 
> > > > somewhere. So I quickly wrote up the plan in a Mistral policy spec. If 
> > > > we can agree there and merge it, then I'll go ahead and start the 
> > > > cleanup.
> > > >
> > > > https://review.openstack.org/#/c/588492/
> >
> > The spec merged today, so I did a first pass and abandoned 24 reviews that 
> > met the criteria.
> >
> > It will be interesting to see if any of them are restored.
> >
> > Dougal
> >
> >
> > > >
> > > >
> > > > >
> > > > > Cheers,
> > > > > Dougal
> > >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer

[Markos Chandras]

On 07/30/2018 11:16 AM, jean-phili...@evrard.me wrote:
> Hello everyone,
> 
> I'd like to propose Jonathan Rosser (jrosser) as core reviewer for 
> OpenStack-Ansible.
> The BBC team [1] has been very active recently across the board, but worked 
> heavily in our ops repo, making sure the experience is complete for operators.
> 
> I value Jonathan's opinion (I remember the storage backend conversations for 
> lxc/systemd-nspawn!), and I'd like this positive trend to continue. On top of 
> it Jonathan has been recently reviewing quite a series of patches, and is 
> involved into some of our important work: bringing the Bionic support.
> 
> Best regards,
> Jean-Philippe Evrard (evrardjp)

+1

Jonathan will be a valuable addition to the project.

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

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

Re: [openstack-dev] [mistral] Clearing out old gerrit reviews

[Dougal Matthews]

On 3 August 2018 at 10:45, Dougal Matthews  wrote:

> On 9 July 2018 at 16:13, Dougal Matthews  wrote:
>
>> Hey folks,
>>
>> I'd like to propose that we start abandoning old Gerrit reviews.
>>
>> This report shows how stale and out of date some of the reviews are:
>> http://stackalytics.com/report/reviews/mistral-group/open
>>
>> I would like to initially abandon anything without any activity for a
>> year, but we might want to consider a shorter limit - maybe 6 months.
>> Reviews can be restored, so the risk is low.
>>
>> What do you think? Any objections or counter suggestions?
>>
>> If I don't hear any complaints, I'll go ahead with this next week (or
>> maybe the following week).
>>
>
> That time line was ambitious. I didn't get started :-)
>
> However, I did decide it would be best to formalise this plan somewhere.
> So I quickly wrote up the plan in a Mistral policy spec. If we can agree
> there and merge it, then I'll go ahead and start the cleanup.
>
> https://review.openstack.org/#/c/588492/
>

The spec merged today, so I did a first pass and abandoned 24 reviews that
met the criteria.

It will be interesting to see if any of them are restored.

Dougal



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

Re: [openstack-dev] Should we add a tempest-slow job?

[Ghanshyam Mann]

  On Fri, 27 Jul 2018 00:14:04 +0900 Matt Riedemann  
wrote  
 > On 5/13/2018 9:06 PM, Ghanshyam Mann wrote:
 > >> +1 on idea. As of now slow marked tests are from nova, cinder and
 > >> neutron scenario tests and 2 API swift tests only [4]. I agree that
 > >> making a generic job in tempest is better for maintainability. We can
 > >> use existing job for that with below modification-
 > >> -  We can migrate
 > >> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" job
 > >> zuulv3 in tempest repo
 > >> -  We can see if we can move migration tests out of it and use
 > >> "nova-live-migration" job (in tempest check pipeline ) which is much
 > >> better in live migration env setup and controlled by nova.
 > >> -  then it can be name something like
 > >> "tempest-scenario-multinode-lvm-multibackend".
 > >> -  run this job in nova, cinder, neutron check pipeline instead of 
 > >> experimental.
 > > Like this 
 > > -https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:scenario-tests-job
 > > 
 > > That makes scenario job as generic with running all scenario tests
 > > including slow tests with concurrency 2. I made few cleanup and moved
 > > live migration tests out of it which is being run by
 > > 'nova-live-migration' job. Last patch making this job as voting on
 > > tempest side.
 > > 
 > > If looks good, we can use this to run on project side pipeline as voting.
 > > 
 > > -gmann
 > > 
 > 
 > I should have said something earlier, but I've said it on my original 
 > nova change now:
 > 
 > https://review.openstack.org/#/c/567697/
 > 
 > What was implemented in Tempest isn't really at all what I was going 
 > for, especially since it doesn't run the API tests marked 'slow'. All I 
 > want is a job like tempest-full (which excludes slow tests) to be 
 > tempest-full which *only* runs slow tests. They would run a mutually 
 > exclusive set of tests so we have that coverage. I don't care if the 
 > scenario tests are run in parallel or serial (it's probably best to 
 > start in serial like tempest-full today and then change to parallel 
 > later if that settles down).
 > 
 > But I think it's especially important given:
 > 
 > https://review.openstack.org/#/c/567697/2
 > 
 > That we have a job which only runs slow tests because we're going to be 
 > marking more tests as "slow" pretty soon and we don't need the overlap 
 > with the existing tests that are run in tempest-full.

Agree with your point. We have tempest-slow job now available on tempest side 
to use across projects[1].

I have updated this - https://review.openstack.org/#/c/567697


[1] 
https://github.com/openstack/tempest/blob/b2b666bd4b9aab08d0b7724c1f0b7465adde0d8d/.zuul.yaml#L146

-gmann

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



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

Re: [openstack-dev] [nova] tempest-full-py3 rename means we now run that job on test-only changes

[Ghanshyam Mann]

  On Sun, 05 Aug 2018 06:44:26 +0900 Matt Riedemann  
wrote  
 > I've reported a nova bug for this:
 > 
 > https://bugs.launchpad.net/nova/+bug/1785425
 > 
 > But I'm not sure what is the best way to fix it now with the zuul v3 
 > hotness. We had an irrelevant-files entry in project-config for the 
 > tempest-full job but we don't have that for tempest-full-py3, so should 
 > we just rename that in project-config (guessing not)? Or should we do 
 > something in nova's .zuul.yaml like this (guessing yes):
 > 
 > https://review.openstack.org/#/c/578878/
 > 
 > The former is easy and branchless but I'm guessing the latter is what we 
 > should do long-term (and would require backports to stable branches).

Yeah, tempest-full-py3 does not have nova specific irreverent-file defined on 
project-config side. 

Just for background, same issue was for other job also like tempest-full and 
grenade job where tempest-full used to run on doc/test only changes also [1]  
which is fixed after making the 'files' and 'irrelevant-files' overridable in 
zuul [2].

IMO same solution can be done for tempest-full-py3 too, I pushed the patch for 
that [3]. For new job, i feel we should always plan to do it in nova's 
.zuul.yaml and old entry on project-config side can be move to nova side during 
job migration work. 


[1] https://bugs.launchpad.net/nova/+bug/1745405  
https://bugs.launchpad.net/nova/+bug/1745431
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131304.html
[3] https://review.openstack.org/#/c/589039/

-gmann

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



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