[openstack-dev] [Cyborg] Agent - Conductor update
Zhenghao ZH21 Wang
wangzh21 at lenovo.com
Wed Aug 8 11:10:56 UTC 2018
Hi Sundar,
All look good to me. And I agreed with the new solution as your suggestion. But I still confused why we will lost some device info if we do diff on agent?
Could u give me an example to explain how to lost and what we will lost?
Best regards
Zhenghao Wang
Cloud Researcher
Email: wangzh21 at lenovo.com
Tel: (+86) 18519550096
Enterprise & Cloud Research Lab, Lenovo Research
No.6 Shangdi West Road, Haidian District, Beijing
-----Original Message-----
From: openstack-dev-request at lists.openstack.org <openstack-dev-request at lists.openstack.org>
Sent: Tuesday, August 07, 2018 10:22 PM
To: openstack-dev at lists.openstack.org
Subject: [External] OpenStack-dev Digest, Vol 76, Issue 7
Send OpenStack-dev mailing list submissions to
openstack-dev at lists.openstack.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request at lists.openstack.org
You can reach the person managing the list at
openstack-dev-owner at lists.openstack.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."
Today's Topics:
1. Re: Paste unmaintained (Lance Bragstad)
2. Re: [tempest] Small doubt in Tempest setup (Goutham Pratapa)
3. Re: Paste unmaintained (Thomas Herve)
4. Re: [tempest] Small doubt in Tempest setup (Goutham Pratapa)
5. Re: [tripleo] Proposing Lukas Bezdicka core on TripleO
(Alex Schultz)
6. Re: [tripleo] Proposing Lukas Bezdicka core on TripleO
(Dougal Matthews)
7. Re: [releease][ptl] Missing and forced releases (Spyros Trigazis)
8. UC nomination period is now open! (Ed Leafe)
9. [tripleo] 3rd party ovb jobs are down (Wesley Hayutin)
10. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Thomas Goirand)
11. Re: [tripleo] EOL process for newton branches (Andreas Jaeger)
12. Re: [release][requirements][python-magnumclient] Magnumclient
FFE (Matthew Thode)
13. Denver PTG Registration Price Increases on August 23
(Kendall Waters)
14. zaqar-ui 5.0.0.0rc1 (rocky) (no-reply at openstack.org)
15. zaqar 7.0.0.0rc1 (rocky) (no-reply at openstack.org)
16. The state of the ironic universe - August 6th, 2018 (Julia Kreger)
17. Re: [OpenStack-dev][heat][keystone][security sig][all] SSL
option for keystone session (Zane Bitter)
18. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Sean McGinnis)
19. Re: Paste unmaintained (Sean McGinnis)
20. Re: [i18n] Edge and Containers whitepapers ready for
translation (Jimmy McArthur)
21. Re: [release][requirements][python-magnumclient] Magnumclient
FFE (Spyros Trigazis)
22. Re: [release][requirements][python-magnumclient] Magnumclient
FFE (Matthew Thode)
23. [neutron] Bug deputy report week July 30th - August 5th
(Miguel Lavalle)
24. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Zane Bitter)
25. [python3] champions, please review the updated process
(Doug Hellmann)
26. Re: [tripleo] 3rd party ovb jobs are down (Wesley Hayutin)
27. [nova] StarlingX diff analysis (Matt Riedemann)
28. [Cyborg] Agent - Conductor update (Nadathur, Sundar)
29. [all][election][senlin][tacker] Last chance to vote (Tony Breeds)
30. [Blazar] Stein etherpad (Masahito MUROI)
31. Re: [tripleo] EOL process for newton branches (Tony Breeds)
32. Re: [tripleo] EOL process for newton branches (Tony Breeds)
33. Re: [Openstack-operators] [nova] StarlingX diff analysis
(Flint WALRUS)
34. Re: [tripleo] EOL process for newton branches (Andreas Jaeger)
35. Re: [i18n] Edge and Containers whitepapers ready for
translation (Frank Kloeker)
36. [neutron] Does neutron support QinQ(vlan transparent) ?
(Frank Wang)
37. [tc] [all] TC Report 18-32 (Chris Dent)
38. Re: [neutron] Does neutron support QinQ(vlan transparent) ?
(Sean Mooney)
39. [nova]Notification update week 32 (Balázs Gibizer)
40. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Thomas Goirand)
41. [requirements][release] FFE for openstacksdk 0.17.2 (Monty Taylor)
42. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Sean Mooney)
43. Re: [Openstack-operators] [nova] StarlingX diff analysis
(Matt Riedemann)
44. Re: OpenStack lagging behind 2 major python versions: we need
a Python 3.7 gate (Thomas Goirand)
45. Re: [tripleo] 3rd party ovb jobs are down (Wesley Hayutin)
46. Re: [requirements][release] FFE for openstacksdk 0.17.2
(Matthew Thode)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Aug 2018 09:53:36 -0500
From: Lance Bragstad <lbragstad at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Paste unmaintained
Message-ID: <d671e0c3-0800-7a99-d5b2-c7a2dadfaa84 at gmail.com>
Content-Type: text/plain; charset="utf-8"
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/f4b7651e/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-dev/attachments/20180806/f4b7651e/attachment-0001.sig>
------------------------------
Message: 2
Date: Mon, 6 Aug 2018 20:25:09 +0530
From: Goutham Pratapa <pratapagoutham at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tempest] Small doubt in Tempest setup
Message-ID:
<CAAnEhiFAsUFfCZP7jJvLYA0DXMo4LY9K4z0+8JuBihbT3Ou2UQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Done thanks afazekas
Thanks
Goutham
On Mon, 6 Aug 2018 at 7:27 PM, Attila Fazekas <afazekas at redhat.com> 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 <afazekas at redhat.com>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Cheers !!!
Goutham Pratapa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/15d2ec9b/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 6 Aug 2018 17:13:23 +0200
From: Thomas Herve <therve at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Paste unmaintained
Message-ID:
<CAFsfq7+pENkaOMsdeUkXmXHJ8NzOX0yzGH1Ya+0zVZ05qNDRUw at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 2, 2018 at 4:27 PM, Doug Hellmann <doug at doughellmann.com> 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 | requirements.txt | 6 | Paste>=2.0.2 # MIT |
> | oslo.service | requirements.txt | 17 | Paste>=2.0.2 # MIT |
> | requirements | global-requirements.txt | 187 | Paste # MIT |
> | searchlight | requirements.txt | 27 | Paste>=2.0.2 # MIT |
> | tacker | requirements.txt | 6 | Paste>=2.0.2 # MIT |
> | tatu | requirements.txt | 18 | Paste # MIT |
> | tricircle | requirements.txt | 7 | Paste>=2.0.2 # MIT |
> | trio2o | requirements.txt | 7 | Paste # MIT |
> | trove | requirements.txt | 11 | Paste>=2.0.2 # MIT |
> | upstream-institute-virtual-environment | elements/upstream-training/static/tmp/requirements.txt | 147 | Paste==2.0.3 |
If you look for PasteDeploy you'll find quite a few more. I know at
least Heat and Swift don't depend on Paste but on PasteDeploy.
--
Thomas
------------------------------
Message: 4
Date: Mon, 6 Aug 2018 20:57:18 +0530
From: Goutham Pratapa <pratapagoutham at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tempest] Small doubt in Tempest setup
Message-ID:
<CAAnEhiGCcNagm+V5NCNzEy_ahOEkQo8rWa1rH=WWTNYfbVfiWQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <afazekas at redhat.com> 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 <afazekas at redhat.com>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Cheers !!!
Goutham Pratapa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/919144ab/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 6 Aug 2018 09:28:11 -0600
From: Alex Schultz <aschultz at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core
on TripleO
Message-ID:
<CAFsb3b6AE9hHdi5xAnesj6nZhftRHqJWyJu=8KsbXnUmOCj1HA at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
+1
On Mon, Aug 6, 2018 at 7:19 AM, Bogdan Dobrelya <bdobreli at redhat.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 6
Date: Mon, 6 Aug 2018 16:50:12 +0100
From: Dougal Matthews <dougal at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core
on TripleO
Message-ID:
<CAPMB-2Sw5iRZ_-DC4Kw486cM-zxTfgHPddCaYuKTxE8CiuiVCw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
+1
On 6 August 2018 at 16:28, Alex Schultz <aschultz at redhat.com> wrote:
> +1
>
> On Mon, Aug 6, 2018 at 7:19 AM, Bogdan Dobrelya <bdobreli at redhat.com>
> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/0af0d318/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 6 Aug 2018 18:34:42 +0200
From: Spyros Trigazis <strigazi at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [releease][ptl] Missing and forced
releases
Message-ID:
<CAB9QTQZFUE9mwP1DwU_ADtcLuh9jz4i0YnS-Kyn_=hThprqD5w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <sean.mcginnis at gmx.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/8daaf93c/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 6 Aug 2018 11:52:38 -0500
From: Ed Leafe <ed at leafe.com>
To: openstack-sigs at lists.openstack.org, OpenStack Operators
<openstack-operators at lists.openstack.org>, "OpenStack Development
Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>, openstack at lists.openstack.org,
user-committee <user-committee at lists.openstack.org>
Subject: [openstack-dev] UC nomination period is now open!
Message-ID: <277DC0C9-C34D-47D9-B14F-81E41F136909 at leafe.com>
Content-Type: text/plain; charset=utf-8
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-committee at 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
------------------------------
Message: 9
Date: Mon, 6 Aug 2018 10:56:49 -0600
From: Wesley Hayutin <whayutin at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [tripleo] 3rd party ovb jobs are down
Message-ID:
<CAOHJT4+x+RLa=H96-bB8nOwbtYL0O4qqdcA8-uBPvHH9RyHjQQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
<https://www.redhat.com/>
w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>4232509
IRC: weshay
<https://red.ht/sig>
View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/1e3a0aa2/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 6 Aug 2018 19:11:37 +0200
From: Thomas Goirand <zigo at debian.org>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID: <57e9dffb-26cd-e96a-cac9-49942f73ab11 at debian.org>
Content-Type: text/plain; charset=utf-8
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)
------------------------------
Message: 11
Date: Mon, 6 Aug 2018 19:27:37 +0200
From: Andreas Jaeger <aj at suse.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>, "tony at bakeyournoodle.com >> Tony
Breeds" <tony at bakeyournoodle.com>
Subject: Re: [openstack-dev] [tripleo] EOL process for newton branches
Message-ID: <5565c598-7327-b7f3-773b-2cfb26c8326b at suse.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
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-request at 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
------------------------------
Message: 12
Date: Mon, 6 Aug 2018 12:36:21 -0500
From: Matthew Thode <prometheanfire at gentoo.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev]
[release][requirements][python-magnumclient] Magnumclient FFE
Message-ID: <20180806173621.e7zgkkewmkg6qwkj at gentoo.org>
Content-Type: text/plain; charset="utf-8"
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)
-------------- 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-dev/attachments/20180806/451a278f/attachment-0001.sig>
------------------------------
Message: 13
Date: Mon, 6 Aug 2018 12:36:26 -0500
From: Kendall Waters <kendall at openstack.org>
To: OpenStack-operators at lists.openstack.org, "OpenStack Development
Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] Denver PTG Registration Price Increases on
August 23
Message-ID: <00AB295F-05B2-4DE6-8D56-31BC924D9123 at openstack.org>
Content-Type: text/plain; charset="utf-8"
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 <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 <http://www.openstack.org/ptg>
If you have any questions, please email ptg at openstack.org <mailto:ptg at openstack.org>.
Cheers,
Kendall
Kendall Waters
OpenStack Marketing & Events
kendall at openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/4045cdbb/attachment-0001.html>
------------------------------
Message: 14
From: no-reply at openstack.org
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] zaqar-ui 5.0.0.0rc1 (rocky)
Message-ID:
<mailman.192550.1533651704.1381.openstack-dev at lists.openstack.org>
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.
------------------------------
Message: 15
From: no-reply at openstack.org
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] zaqar 7.0.0.0rc1 (rocky)
Message-ID:
<mailman.192551.1533651704.1381.openstack-dev at lists.openstack.org>
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/
------------------------------
Message: 16
Date: Mon, 6 Aug 2018 13:53:03 -0400
From: Julia Kreger <juliaashleykreger at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] The state of the ironic universe - August
6th, 2018
Message-ID:
<CAF7gwdjtgmdWBUkoymN9Uh7iro4dR83Tkv3R47ymy9SX4_nJjA at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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
------------------------------
Message: 17
Date: Mon, 6 Aug 2018 14:58:37 -0400
From: Zane Bitter <zbitter at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-dev][heat][keystone][security
sig][all] SSL option for keystone session
Message-ID: <b042a1b9-7cc2-8953-5cc4-43f2b9a9e04b at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 18
Date: Mon, 6 Aug 2018 19:02:41 +0000
From: Sean McGinnis <sean.mcginnis at gmx.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID: <20180806190241.GA3368 at devvm1>
Content-Type: text/plain; charset=us-ascii
>
> 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
------------------------------
Message: 19
Date: Mon, 6 Aug 2018 19:06:35 +0000
From: Sean McGinnis <sean.mcginnis at gmx.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Paste unmaintained
Message-ID: <20180806190634.GB3368 at devvm1>
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 20
Date: Mon, 06 Aug 2018 14:07:24 -0500
From: Jimmy McArthur <jimmy at openstack.org>
To: Frank Kloeker <eumel at arcor.de>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>, Ildiko Vancsa
<ildiko at openstack.org>, Sebastian Marcet <sebastian at tipit.net>
Subject: Re: [openstack-dev] [i18n] Edge and Containers whitepapers
ready for translation
Message-ID: <5B689C6C.2010006 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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&T. 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 <eumel at arcor.de>
>>>>> 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 translation is more difficult.
>>>>>>
>>>>>> That's my point of view on translating edge computing whitepaper.
>>>>>>
>>>>>> For translating container whitepaper, I want to further ask the
>>>>>> followings since *I18n-based tools*
>>>>>> would mean for translators that translators can test and publish
>>>>>> translated whitepapers locally:
>>>>>>
>>>>>> - How to build translated container whitepaper using original
>>>>>> Silverstripe-based repository?
>>>>>> https://docs.openstack.org/i18n/latest/tools.html [5] describes
>>>>>> well how to build translated artifacts for RST-based OpenStack
>>>>>> repositories
>>>>>> but I could not find the way how to build translated container
>>>>>> whitepaper with translated resources on Zanata.
>>>>>> This is a little tricky. It's possible to set up a local version
>>>>>> of the OpenStack website
>>>>>>
>>>>> (https://github.com/OpenStackweb/openstack-org/blob/master/installation.md
>>>>>
>>>>>> [6]). However, we have to manually ingest the po files as they are
>>>>>> completed and then push them out to production, so that wouldn't do
>>>>>> much to help with your local build. I'm open to suggestions on how
>>>>>> we can make this process easier for the i18n team.
>>>>>>
>>>>>> Thank you,
>>>>>> Jimmy
>>>>>>
>>>>>> With many thanks,
>>>>>>
>>>>>> /Ian
>>>>>>
>>>>>> Jimmy McArthur wrote on 7/17/2018 11:01 PM:
>>>>>> Frank,
>>>>>>
>>>>>> I'm sorry to hear about the displeasure around the Edge paper. As
>>>>>> mentioned in a prior thread, the RST format that Akihiro worked did
>>>>>> not work with the Zanata process that we have been using with our
>>>>>> CMS. Additionally, the existing EDGE page is a PDF, so we had to
>>>>>> build a new template to work with the new HTML whitepaper layout we
>>>>>> created for the Containers paper. I outlined this in the thread "
>>>>>> [OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge Computing
>>>>>> Whitepaper Translation" on 6/25/18 and mentioned we would be ready
>>>>>> with the template around 7/13.
>>>>>>
>>>>>> We completed the work on the new whitepaper template and then put
>>>>>> out the pot files on Zanata so we can get the po language files
>>>>>> back. If this process is too cumbersome for the translation team,
>>>>>> I'm open to discussion, but right now our entire translation process
>>>>>> is based on the official OpenStack Docs translation process outlined
>>>>>> by the i18n team:
>>>>>> https://docs.openstack.org/i18n/latest/en_GB/tools.html [7]
>>>>>>
>>>>>> Again, I realize Akihiro put in some work on his own proposing the
>>>>>> new translation type. If the i18n team is moving to this format
>>>>>> instead, we can work on redoing our process.
>>>>>>
>>>>>> Please let me know if I can clarify further.
>>>>>>
>>>>>> Thanks,
>>>>>> Jimmy
>>>>>>
>>>>>> Frank Kloeker wrote:
>>>>>> Hi Jimmy,
>>>>>>
>>>>>> permission was added for you and Sebastian. The Container Whitepaper
>>>>>> is on the Zanata frontpage now. But we removed Edge Computing
>>>>>> whitepaper last week because there is a kind of displeasure in the
>>>>>> team since the results of translation are still not published beside
>>>>>> Chinese version. It would be nice if we have a commitment from the
>>>>>> Foundation that results are published in a specific timeframe. This
>>>>>> includes your requirements until the translation should be
>>>>>> available.
>>>>>>
>>>>>> thx Frank
>>>>>>
>>>>>> Am 2018-07-16 17:26, schrieb Jimmy McArthur:
>>>>>> Sorry, I should have also added... we additionally need permissions
>>>>>> so
>>>>>> that we can add the a new version of the pot file to this project:
>>>>>>
>>>>> https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
>>>>>
>>>>>> [8] Thanks!
>>>>>> Jimmy
>>>>>>
>>>>>> Jimmy McArthur wrote:
>>>>>> Hi all -
>>>>>>
>>>>>> We have both of the current whitepapers up and available for
>>>>>> translation. Can we promote these on the Zanata homepage?
>>>>>>
>>>>>>
>>>>> https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
>>>>>
>>>>>> [9]
>>>>>>
>>>>> https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684
>>>>>
>>>>>> [10] Thanks all!
>>>>>> Jimmy
>>>>>>
>>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> [12]
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> [12]
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> [12]
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> [12]
>>>>>
>>>>>
>>>>>
>>>>> Links:
>>>>> ------
>>>>> [1]
>>>>> https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center
>>>>> [2]
>>>>> https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack
>>>>> [3]
>>>>> https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing
>>>>> [4]
>>>>> https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192
>>>>> [5] https://docs.openstack.org/i18n/latest/tools.html
>>>>> [6]
>>>>> https://github.com/OpenStackweb/openstack-org/blob/master/installation.md
>>>>> [7] https://docs.openstack.org/i18n/latest/en_GB/tools.html
>>>>> [8]
>>>>> https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
>>>>> [9]
>>>>> https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
>>>>> [10]
>>>>> https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684
>>>>> [11]
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> [12]
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 21
Date: Mon, 6 Aug 2018 21:37:12 +0200
From: Spyros Trigazis <strigazi at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev]
[release][requirements][python-magnumclient] Magnumclient FFE
Message-ID:
<CAB9QTQYU29un=mdsknN=LVkTWsoust_7s40R33aHc5=43WC8rw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It is constraints only. There is no project
that requires the new version.
Spyros
On Mon, 6 Aug 2018, 19:36 Matthew Thode, <prometheanfire at gentoo.org> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/bc074d95/attachment-0001.html>
------------------------------
Message: 22
Date: Mon, 6 Aug 2018 15:06:23 -0500
From: Matthew Thode <prometheanfire at gentoo.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev]
[release][requirements][python-magnumclient] Magnumclient FFE
Message-ID: <20180806200623.vwsepip3mh2wpa6i at gentoo.org>
Content-Type: text/plain; charset="utf-8"
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, <prometheanfire at gentoo.org> 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)
-------------- 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-dev/attachments/20180806/c8370587/attachment-0001.sig>
------------------------------
Message: 23
Date: Mon, 6 Aug 2018 15:44:00 -0500
From: Miguel Lavalle <miguel at mlavalle.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [neutron] Bug deputy report week July 30th -
August 5th
Message-ID:
<CAEzGLDhsa4XokdDr5AnW0ZDHQA3Ze3S070DeY6MaHOqQ34t9Yg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/be241c1f/attachment-0001.html>
------------------------------
Message: 24
Date: Mon, 6 Aug 2018 16:52:04 -0400
From: Zane Bitter <zbitter at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID: <658519a3-e79e-cdac-6f55-7dad77df043b at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 25
Date: Mon, 06 Aug 2018 16:56:45 -0400
From: Doug Hellmann <doug at doughellmann.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [python3] champions, please review the
updated process
Message-ID: <1533588883-sup-4209 at lrrr.local>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 26
Date: Mon, 6 Aug 2018 15:55:05 -0600
From: Wesley Hayutin <whayutin at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Cc: Derek Higgins <dhiggins at redhat.com>, Kieran Forde
<kforde at redhat.com>
Subject: Re: [openstack-dev] [tripleo] 3rd party ovb jobs are down
Message-ID:
<CAOHJT4+J9ivO6gVq9-kLAJOo6iFTVY_Gzv-dQUhsVwxg6kKV2Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Aug 6, 2018 at 12:56 PM Wesley Hayutin <whayutin at redhat.com> 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
>
> <https://www.redhat.com/>
>
> w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>
> 4232509 IRC: weshay
> <https://red.ht/sig>
>
> View my calendar and check my availability for meetings HERE
> <https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
>
--
Wes Hayutin
Associate MANAGER
Red Hat
<https://www.redhat.com/>
w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>4232509
IRC: weshay
<https://red.ht/sig>
View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/b21da480/attachment-0001.html>
------------------------------
Message: 27
Date: Mon, 6 Aug 2018 17:03:28 -0500
From: Matt Riedemann <mriedemos at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>,
openstack-sigs at lists.openstack.org
Subject: [openstack-dev] [nova] StarlingX diff analysis
Message-ID: <d0503738-0106-0477-2091-90884aef1caa at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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
------------------------------
Message: 28
Date: Mon, 6 Aug 2018 15:16:31 -0700
From: "Nadathur, Sundar" <sundar.nadathur at intel.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Cyborg] Agent - Conductor update
Message-ID: <ce3eaecd-d724-26d1-bba2-9b2ef8f31e5c at intel.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180806/bbda699c/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 7 Aug 2018 10:20:45 +1000
From: Tony Breeds <tony at bakeyournoodle.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [all][election][senlin][tacker] Last chance
to vote
Message-ID: <20180807002010.GB9540 at thor.bakeyournoodle.com>
Content-Type: text/plain; charset="utf-8"
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.
-------------- 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-dev/attachments/20180807/9b292114/attachment-0001.sig>
------------------------------
Message: 30
Date: Tue, 7 Aug 2018 11:17:14 +0900
From: Masahito MUROI <muroi.masahito at lab.ntt.co.jp>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Blazar] Stein etherpad
Message-ID: <e698ba40-140b-083d-3940-004d812c1b8d at lab.ntt.co.jp>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Blazar folks,
I prepared the etherpad page for the Stein PTG.
https://etherpad.openstack.org/p/blazar-ptg-stein
best regards,
Masahito
------------------------------
Message: 31
Date: Tue, 7 Aug 2018 14:34:45 +1000
From: Tony Breeds <tony at bakeyournoodle.com>
To: Andreas Jaeger <aj at suse.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] EOL process for newton branches
Message-ID: <20180807043445.GH9540 at thor.bakeyournoodle.com>
Content-Type: text/plain; charset="utf-8"
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.
-------------- 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-dev/attachments/20180807/74f3d50b/attachment-0001.sig>
------------------------------
Message: 32
Date: Tue, 7 Aug 2018 15:08:10 +1000
From: Tony Breeds <tony at bakeyournoodle.com>
To: Andreas Jaeger <aj at suse.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] EOL process for newton branches
Message-ID: <20180807050810.GI9540 at thor.bakeyournoodle.com>
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180807/89bc8c5a/attachment-0001.sig>
------------------------------
Message: 33
Date: Tue, 7 Aug 2018 08:10:53 +0200
From: Flint WALRUS <gael.therond at gmail.com>
To: Matt Riedemann <mriedemos at gmail.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>,
openstack-sigs at lists.openstack.org,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [openstack-dev] [Openstack-operators] [nova] StarlingX
diff analysis
Message-ID:
<CAG+53ubghhVymP9UONvCwt38Ea2TkLzV7Z5d5c2SH86k5kuK=w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi matt, everyone,
I just read your analysis and would like to thank you for such work. I
really think there are numerous features included/used on this Nova rework
that would be highly beneficial for Nova and users of it.
I hope people will fairly appreciate you work.
I didn’t had time to check StarlingX code quality, how did you feel it
while you were doing your analysis?
Thanks a lot for this share.
I’ll have a closer look at it this afternoon as my company may be
interested by some features.
Kind regards,
G.
Le mar. 7 août 2018 à 00:03, Matt Riedemann <mriedemos at gmail.com> a écrit :
> 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-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180807/581a31e7/attachment-0001.html>
------------------------------
Message: 34
Date: Tue, 7 Aug 2018 08:38:45 +0200
From: Andreas Jaeger <aj at suse.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] EOL process for newton branches
Message-ID: <441e4cb8-10ee-2797-ee5c-fd6d212d3bc5 at suse.com>
Content-Type: text/plain; charset="utf-8"
On 2018-08-07 07:08, Tony Breeds wrote:
> Okay Ian gave me permission to do this. Those repos have been tagged
> newton-eol and had the branches deleted.
Thanks, Tony!
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
------------------------------
Message: 35
Date: Tue, 07 Aug 2018 09:49:17 +0200
From: Frank Kloeker <eumel at arcor.de>
To: Jimmy McArthur <jimmy at openstack.org>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>, Ildiko Vancsa
<ildiko at openstack.org>, Sebastian Marcet <sebastian at tipit.net>
Subject: Re: [openstack-dev] [i18n] Edge and Containers whitepapers
ready for translation
Message-ID: <4ef95237972fb567d9eaebba82bf9066 at arcor.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Many thanks, Jimmy! At last I draw your attention to Stackalytics.
Translation metrics for whitepapers not counted there. Maybe you have an
advice for https://review.openstack.org/#/c/588965/
kind regards
Frank
Am 2018-08-06 21:07, schrieb 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&T. 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 <eumel at arcor.de>
>>>>>> 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 translation is more difficult.
>>>>>>>
>>>>>>> That's my point of view on translating edge computing whitepaper.
>>>>>>>
>>>>>>> For translating container whitepaper, I want to further ask the
>>>>>>> followings since *I18n-based tools*
>>>>>>> would mean for translators that translators can test and publish
>>>>>>> translated whitepapers locally:
>>>>>>>
>>>>>>> - How to build translated container whitepaper using original
>>>>>>> Silverstripe-based repository?
>>>>>>> https://docs.openstack.org/i18n/latest/tools.html [5] describes
>>>>>>> well how to build translated artifacts for RST-based OpenStack
>>>>>>> repositories
>>>>>>> but I could not find the way how to build translated container
>>>>>>> whitepaper with translated resources on Zanata.
>>>>>>> This is a little tricky. It's possible to set up a local version
>>>>>>> of the OpenStack website
>>>>>>>
>>>>>> (https://github.com/OpenStackweb/openstack-org/blob/master/installation.md
>>>>>>> [6]). However, we have to manually ingest the po files as they
>>>>>>> are
>>>>>>> completed and then push them out to production, so that wouldn't
>>>>>>> do
>>>>>>> much to help with your local build. I'm open to suggestions on
>>>>>>> how
>>>>>>> we can make this process easier for the i18n team.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Jimmy
>>>>>>>
>>>>>>> With many thanks,
>>>>>>>
>>>>>>> /Ian
>>>>>>>
>>>>>>> Jimmy McArthur wrote on 7/17/2018 11:01 PM:
>>>>>>> Frank,
>>>>>>>
>>>>>>> I'm sorry to hear about the displeasure around the Edge paper.
>>>>>>> As
>>>>>>> mentioned in a prior thread, the RST format that Akihiro worked
>>>>>>> did
>>>>>>> not work with the Zanata process that we have been using with
>>>>>>> our
>>>>>>> CMS. Additionally, the existing EDGE page is a PDF, so we had to
>>>>>>> build a new template to work with the new HTML whitepaper layout
>>>>>>> we
>>>>>>> created for the Containers paper. I outlined this in the thread "
>>>>>>> [OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge Computing
>>>>>>> Whitepaper Translation" on 6/25/18 and mentioned we would be
>>>>>>> ready
>>>>>>> with the template around 7/13.
>>>>>>>
>>>>>>> We completed the work on the new whitepaper template and then put
>>>>>>> out the pot files on Zanata so we can get the po language files
>>>>>>> back. If this process is too cumbersome for the translation team,
>>>>>>> I'm open to discussion, but right now our entire translation
>>>>>>> process
>>>>>>> is based on the official OpenStack Docs translation process
>>>>>>> outlined
>>>>>>> by the i18n team:
>>>>>>> https://docs.openstack.org/i18n/latest/en_GB/tools.html [7]
>>>>>>>
>>>>>>> Again, I realize Akihiro put in some work on his own proposing
>>>>>>> the
>>>>>>> new translation type. If the i18n team is moving to this format
>>>>>>> instead, we can work on redoing our process.
>>>>>>>
>>>>>>> Please let me know if I can clarify further.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jimmy
>>>>>>>
>>>>>>> Frank Kloeker wrote:
>>>>>>> Hi Jimmy,
>>>>>>>
>>>>>>> permission was added for you and Sebastian. The Container
>>>>>>> Whitepaper
>>>>>>> is on the Zanata frontpage now. But we removed Edge Computing
>>>>>>> whitepaper last week because there is a kind of displeasure in
>>>>>>> the
>>>>>>> team since the results of translation are still not published
>>>>>>> beside
>>>>>>> Chinese version. It would be nice if we have a commitment from
>>>>>>> the
>>>>>>> Foundation that results are published in a specific timeframe.
>>>>>>> This
>>>>>>> includes your requirements until the translation should be
>>>>>>> available.
>>>>>>>
>>>>>>> thx Frank
>>>>>>>
>>>>>>> Am 2018-07-16 17:26, schrieb Jimmy McArthur:
>>>>>>> Sorry, I should have also added... we additionally need
>>>>>>> permissions
>>>>>>> so
>>>>>>> that we can add the a new version of the pot file to this
>>>>>>> project:
>>>>>>>
>>>>>> https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
>>>>>>> [8] Thanks!
>>>>>>> Jimmy
>>>>>>>
>>>>>>> Jimmy McArthur wrote:
>>>>>>> Hi all -
>>>>>>>
>>>>>>> We have both of the current whitepapers up and available for
>>>>>>> translation. Can we promote these on the Zanata homepage?
>>>>>>>
>>>>>>>
>>>>>> https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
>>>>>>> [9]
>>>>>>>
>>>>>> https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684
>>>>>>> [10] Thanks all!
>>>>>>> Jimmy
>>>>>>>
>>>>>>>
>>>>>> __________________________________________________________________________
>>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>>> Unsubscribe:
>>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>>> [11]
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> [12]
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> [12]
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> [12]
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe [11]
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> [12]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Links:
>>>>>> ------
>>>>>> [1]
>>>>>> https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center
>>>>>> [2]
>>>>>> https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack
>>>>>> [3]
>>>>>> https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing
>>>>>> [4]
>>>>>> https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192
>>>>>> [5] https://docs.openstack.org/i18n/latest/tools.html
>>>>>> [6]
>>>>>> https://github.com/OpenStackweb/openstack-org/blob/master/installation.md
>>>>>> [7] https://docs.openstack.org/i18n/latest/en_GB/tools.html
>>>>>> [8]
>>>>>> https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
>>>>>> [9]
>>>>>> https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
>>>>>> [10]
>>>>>> https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684
>>>>>> [11]
>>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>>> [12]
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
------------------------------
Message: 36
Date: Tue, 7 Aug 2018 16:15:26 +0800 (CST)
From: "Frank Wang" <wangpeihuixyz at 126.com>
To: "OpenStack Development Mailing List"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [neutron] Does neutron support QinQ(vlan
transparent) ?
Message-ID: <6e1ff2b5.671a.16513747f10.Coremail.wangpeihuixyz at 126.com>
Content-Type: text/plain; charset="gbk"
Hello folks,
I noted that the API already has the vlan_transparent attribute in the network, Do neutron-agents(linux-bridge, openvswitch) support QinQ? I didn't find any reference materials that could guide me on how to use or configure it.
Thank for your time reading this, Any comments would be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180807/011ee804/attachment-0001.html>
------------------------------
Message: 37
Date: Tue, 7 Aug 2018 12:28:03 +0100 (BST)
From: Chris Dent <cdent+os at anticdent.org>
To: OpenStack-dev at lists.openstack.org
Subject: [openstack-dev] [tc] [all] TC Report 18-32
Message-ID: <alpine.OSX.2.21.1808071227280.9466 at cdent-a01.vmware.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
HTML: https://anticdent.org/tc-report-18-32.html
The TC discussions of interest in the past week have been related to
the recent [PTL
elections](https://governance.openstack.org/election/) and planning
for the [forthcoming PTG](https://www.openstack.org/ptg).
## PTL Election Gaps
A few official projects had no nominee for the PTL position. An
[etherpad](https://etherpad.openstack.org/p/stein-leaderless) was
created to track this, and most of the situations have been
resolved. Pointers to some of the discussion:
* [Near the end of nomination
period](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-31.log.html#t2018-07-31T17:39:28).
* [Discussion about
Trove](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-02.log.html#t2018-08-02T13:59:11).
There's quite a bit here about how we evaluate the health of a
project and the value of volunteers, and for how long we are
willing to extend grace periods for projects which have a history
of imperfect health.
* [What to do about
RefStack](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-02.log.html#t2018-08-02T16:01:12)
which evolved to become a discussion about the role of the QA
team.
* [Freezer and
Searchlight](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-07.log.html#t2018-08-07T09:06:37).
Where we (the TC) seem to have some minor disagreement is the extent
to which we should be extending a lifeline to official projects
which are (for whatever reason) struggling to keep up with
responsibilities or we should be using the power to remove official
status as a way to highlight need.
## PTG Planning
The PTG is a month away, so the TC is doing a bit of planning to
prepare. There will be two different days during which the TC will
meet: Sunday afternoon before the PTG, and all day Friday. Most
planning is happening on [this
etherpad](https://etherpad.openstack.org/p/tc-stein-ptg). There is
also of specific etherpad about [the relationship between the TC and
the Foundation and Foundation corporate
members](https://etherpad.openstack.org/p/tc-board-foundation). And
one for [post-lunch
topics](https://etherpad.openstack.org/p/PTG4-postlunch).
IRC links:
* [Discussion about limiting the
agenda](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-03.log.html#t2018-08-03T12:31:38).
If there's any disagreement in this planning process, it is over
whether we should focus our time on topics we have some chance of
resolving or at least making some concrete progress, or we should
spend the time having open-ended discussions.
Ideally there would be time for both, as the latter is required to
develop the shared language that is needed to take real action. But
as is rampant in the community we are constrained by time and other
responsibilities.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
------------------------------
Message: 38
Date: Tue, 7 Aug 2018 12:32:44 +0100
From: Sean Mooney <work at seanmooney.info>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Does neutron support QinQ(vlan
transparent) ?
Message-ID:
<CA+RFP+xWiV8bk5o0VnW=1Z5sb+j3cEgRnySQrw9bGwkChyq7zw at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
TL;DR
it wont work with the ovs agent but "should" work with linux bridge.
see full message below for details.
regards
sean.
the linux bridge agent supports the vlan_transparent option only when
createing networks with an l3 segmentation type e.g. vxlan,gre...
ovs using the neutron l2 agnet does not supprot vlan_transparent
netwroks because of how that agent use vlans for tenant isolation on
the br-int.
it is possible to use achive vlan transparancy with ovs usign an sdn
controller such as odl or ovn but that was not what you asked in your
question so i wont expand on that futher.
if you deploy openstack with linux bridge networking and then create a
tenant network of type vxlan with vlan_transparancy set to true and
your tenants
generate QinQ traffic with an mtu reduced so that it will fix within
the vxlan tunnel unfragmented then yes it should be possibly however
you may need to disable port_security/security groups on the port as
im not sure if the ip tables firewall driver will correctly handel
this case.
an alternive to disabling security groups would be to add an explicit
rule that matched on the etehrnet type and allowed QinQ traffic on
ingress and egress from the vm.
as far as i am aware this is not tested in the gate so while it should
work the lack of documentation and test coverage means you will
likely be one of the first to test it if you
choose to do so and it may fail for many reasons.
On 7 August 2018 at 09:15, Frank Wang <wangpeihuixyz at 126.com> wrote:
> Hello folks,
>
> I noted that the API already has the vlan_transparent attribute in the
> network, Do neutron-agents(linux-bridge, openvswitch) support QinQ? I
> didn't find any reference materials that could guide me on how to use or
> configure it.
>
> Thank for your time reading this, Any comments would be appreciated.
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 39
Date: Tue, 07 Aug 2018 13:48:36 +0200
From: Balázs Gibizer <balazs.gibizer at ericsson.com>
To: OpenStack-dev <OpenStack-dev at lists.openstack.org>
Subject: [openstack-dev] [nova]Notification update week 32
Message-ID: <1533642516.26377.2 at smtp.office365.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hi,
Here is the latest notification subteam update.
Bugs
----
No RC potential notification bug is tracked.
No new bug since last week.
Weekly meeting
--------------
No meeting is planned for this week.
Cheers,
gibi
------------------------------
Message: 40
Date: Tue, 7 Aug 2018 13:52:48 +0200
From: Thomas Goirand <thomas at goirand.fr>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID: <f711f3ef-198f-39db-9945-0eea4494fc7a at goirand.fr>
Content-Type: text/plain; charset=utf-8
On 08/06/2018 09:02 PM, Sean McGinnis wrote:
>>
>> 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.
This is exactly what I'm complaining about. OpenStack upstream has very
wrong priorities. If we really are to switch to Python 3, then we got to
make sure we're current, because that's the version distros are end up
running. Or maybe we only care if "it works on devstack" (tm)?
Cheers,
Thomas Goirand (zigo)
------------------------------
Message: 41
Date: Tue, 7 Aug 2018 07:35:55 -0500
From: Monty Taylor <mordred at inaugust.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [requirements][release] FFE for openstacksdk
0.17.2
Message-ID: <082089a7-124e-2d20-77a5-8b5e9c0a8748 at inaugust.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hey all,
I'd like to request an FFE to release 0.17.2 of openstacksdk from
stable/rocky.
Infra discovered an issue that affects the production nodepool related
to the multi-threaded TaskManager and exception propagation. When it
gets triggered, we lose an entire cloud of capacity (whoops) until we
restart the associated nodepool-launcher process.
Nothing in OpenStack uses the particular feature in openstacksdk in
question (yet), so nobody should need to even bump constraints.
Thanks!
Monty
------------------------------
Message: 42
Date: Tue, 7 Aug 2018 14:24:44 +0100
From: Sean Mooney <work at seanmooney.info>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID:
<CA+RFP+y_jjmD3j-M0yW5YKA7yW_L6WYJ82hrJraWYNBiSnxZ9Q at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On 7 August 2018 at 12:52, Thomas Goirand <thomas at goirand.fr> wrote:
> On 08/06/2018 09:02 PM, Sean McGinnis wrote:
>>>
>>> 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.
>
> This is exactly what I'm complaining about. OpenStack upstream has very
> wrong priorities. If we really are to switch to Python 3, then we got to
> make sure we're current, because that's the version distros are end up
> running. Or maybe we only care if "it works on devstack" (tm)?
python 3.7 has some backward incompatible changes if i recall correctly
such as forked thread not inheriting open file descriptor form the parent.
i dont think that will bite us but it might mess with privsep deamon
though i think we
fork a full process not a thread in that case.
the point im trying to make here is that following the latest python versions
is likely going to require us to either A.) use only the backwards
compatible subset or B.)
make some code test what versions of python 3 we are using the same
way the six package does.
so im not sure pushing for python 3.7 is the right thing to do. also i would not
assume all distros will ship 3.7 in the near term. i have not check lately but
i believe cento 7 unless make 3.4 and 3.6 available in the default repos.
ubuntu 18.04 ships with 3.6 i believe
im not sure about other linux distros but since most openstack
deployment are done
on LTS releases of operating systems i would suspect that python 3.6
will be the main
python 3 versions we see deployed in production for some time.
having a 3.7 gate is not a bad idea but priority wise have a 3.6 gate
would be much higher on my list.
i think we as a community will have to decide on the minimum and
maximum python 3 versions
we support for each release and adjust as we go forward. i would
suggst a min of 3.5 and max of 3.6 for rocky.
for stien perhaps bump that to min of 3.6 max 3.7 but i think this is
something that needs to be address community wide
via a governance resolution rather then per project. it will also
impact the external python lib we can depend on too which is
another reason i think thie need to be a comuntiy wide discussion and
goal that is informed by what distros are doing but
not mandated by what any one distro is doing.
regards
sean.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 43
Date: Tue, 7 Aug 2018 08:29:04 -0500
From: Matt Riedemann <mriedemos at gmail.com>
To: Flint WALRUS <gael.therond at gmail.com>, Matt Riedemann
<mriedemos at gmail.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>,
openstack-sigs at lists.openstack.org,
"openstack-operators at lists.openstack.org"
<openstack-operators at lists.openstack.org>
Subject: Re: [openstack-dev] [Openstack-operators] [nova] StarlingX
diff analysis
Message-ID: <45bd7236-b9f8-026d-620b-7356d4effa49 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 8/7/2018 1:10 AM, Flint WALRUS wrote:
> I didn’t had time to check StarlingX code quality, how did you feel it
> while you were doing your analysis?
I didn't dig into the test diffs themselves, but it was my impression
that from what I was poking around in the local git repo, there were
several changes which didn't have any test coverage.
For the really big full stack changes (L3 CAT, CPU scaling and
shared/pinned CPUs on same host), toward the end I just started glossing
over a lot of that because it's so much code in so many places, so I
can't really speak very well to how it was written or how well it is
tested (maybe WindRiver had a more robust CI system running integration
tests, I don't know).
There were also some things which would have been caught in code review
upstream. For example, they ignore the "force" parameter for live
migration so that live migration requests always go through the
scheduler. However, the "force" parameter is only on newer
microversions. Before that, if you specified a host at all it would
bypass the scheduler, but the change didn't take that into account, so
they still have gaps in some of the things they were trying to
essentially disable in the API.
On the whole I think the quality is OK. It's not really possible to
accurately judge that when looking at a single diff this large.
--
Thanks,
Matt
------------------------------
Message: 44
Date: Tue, 7 Aug 2018 16:11:43 +0200
From: Thomas Goirand <zigo at debian.org>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack lagging behind 2 major python
versions: we need a Python 3.7 gate
Message-ID: <30fd7e68-3a58-2ab1-bba0-c4c5e0eb2bf5 at debian.org>
Content-Type: text/plain; charset=utf-8
On 08/07/2018 03:24 PM, Sean Mooney wrote:
> so im not sure pushing for python 3.7 is the right thing to do. also i would not
> assume all distros will ship 3.7 in the near term. i have not check lately but
> i believe cento 7 unless make 3.4 and 3.6 available in the default repos.
> ubuntu 18.04 ships with 3.6 i believe
The current plan for Debian is that we'll be trying to push for Python
3.7 for Buster, which freezes in January. This freeze date means that
it's going to be Rocky that will end up in the next Debian release. If
Python 3.7 is a failure, then late November, we will remove Python 3.7
from Unstable and let Buster release with 3.6.
As for Ubuntu, it is currently unclear if 18.10 will be released with
Python 3.7 or not, but I believe they are trying to do that. If not,
then 19.04 will for sure be released with Python 3.7.
> im not sure about other linux distros but since most openstack
> deployment are done
> on LTS releases of operating systems i would suspect that python 3.6
> will be the main
> python 3 versions we see deployed in production for some time.
In short: that's wrong.
> having a 3.7 gate is not a bad idea but priority wise have a 3.6 gate
> would be much higher on my list.
Wrong list. One version behind.
> i think we as a community will have to decide on the minimum and
> maximum python 3 versions
> we support for each release and adjust as we go forward.
Whatever the OpenStack community decides is not going to change what
distributions like Debian will do. This type of reasoning lacks a much
needed humility.
> i would suggst a min of 3.5 and max of 3.6 for rocky.
My suggestion is that these bugs are of very high importance and that
they should at least deserve attention. That the gate for Python 3.7
isn't ready, I can understand, as everyone's time is limited. This
doesn't mean that the OpenStack community at large should just dismiss
patches that are important for downstream.
> for stien perhaps bump that to min of 3.6 max 3.7 but i think this is
> something that needs to be address community wide
> via a governance resolution rather then per project.
At this point, dropping 3.5 isn't a good idea either, even for Stein.
> it will also
> impact the external python lib we can depend on too which is
> another reason i think thie need to be a comuntiy wide discussion and
> goal that is informed by what distros are doing but
> not mandated by what any one distro is doing.
> regards
> sean.
Postponing any attempt to support anything current is always a bad idea.
I don't see why there's even a controversy when one attempts to fix bugs
that will, sooner or later, also hit the gate.
Cheers,
Thomas Goirand (zigo)
------------------------------
Message: 45
Date: Tue, 7 Aug 2018 08:14:22 -0600
From: Wesley Hayutin <whayutin at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Cc: Derek Higgins <dhiggins at redhat.com>, Kieran Forde
<kforde at redhat.com>
Subject: Re: [openstack-dev] [tripleo] 3rd party ovb jobs are down
Message-ID:
<CAOHJT4JwTtE_bcaewL7FHiHjwfG=7pz+6vJYE+KcxHpLUx8v1A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Aug 6, 2018 at 5:55 PM Wesley Hayutin <whayutin at redhat.com> wrote:
> On Mon, Aug 6, 2018 at 12:56 PM Wesley Hayutin <whayutin at redhat.com>
> 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!
>
Following up,
legacy-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master job is at
a 78.6% pass rate today. Certainly an improvement.
We had a quick sync meeting this morning w/ RDO-Cloud admins, tripleo and
infra folks. There are two remaining issues.
There is an active issue w/ network connections, and an issue w/ instances
booting into node_failure status. New issues
creep up all the time and we're actively monitoring those as well. Still
shooting for 85% pass rate.
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
>>
>> <https://www.redhat.com/>
>>
>> w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>
>> 4232509 IRC: weshay
>> <https://red.ht/sig>
>>
>> View my calendar and check my availability for meetings HERE
>> <https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
>>
> --
>
> Wes Hayutin
>
> Associate MANAGER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>
> 4232509 IRC: weshay
> <https://red.ht/sig>
>
> View my calendar and check my availability for meetings HERE
> <https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
>
--
Wes Hayutin
Associate MANAGER
Red Hat
<https://www.redhat.com/>
w <cclayton at redhat.com>hayutin at redhat.com T: +1919 <+19197544114>4232509
IRC: weshay
<https://red.ht/sig>
View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180807/c59fef51/attachment-0001.html>
------------------------------
Message: 46
Date: Tue, 7 Aug 2018 09:21:39 -0500
From: Matthew Thode <prometheanfire at gentoo.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [requirements][release] FFE for
openstacksdk 0.17.2
Message-ID: <20180807142139.kk2jmbokrhkkzprk at gentoo.org>
Content-Type: text/plain; charset="utf-8"
On 18-08-07 07:35:55, Monty Taylor wrote:
> Hey all,
>
> I'd like to request an FFE to release 0.17.2 of openstacksdk from
> stable/rocky.
>
> Infra discovered an issue that affects the production nodepool related to
> the multi-threaded TaskManager and exception propagation. When it gets
> triggered, we lose an entire cloud of capacity (whoops) until we restart the
> associated nodepool-launcher process.
>
> Nothing in OpenStack uses the particular feature in openstacksdk in question
> (yet), so nobody should need to even bump constraints.
>
Well, considering constraints is the minimum you can ask for an FFE for,
we'll go with that :P
FFE approved
--
Matthew Thode (prometheanfire)
-------------- 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-dev/attachments/20180807/b1181f6d/attachment.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
End of OpenStack-dev Digest, Vol 76, Issue 7
********************************************
More information about the OpenStack-dev
mailing list