Re: [openstack-dev] PTG Denver Horns

[Matthew Thode]

On 18-08-07 23:18:26, David Medberry wrote:
> Requests have finally been made (today, August 7, 2018) to end the horns on
> the train from Denver to Denver International airport (within the city
> limits of Denver.) Prior approval had been given to remove the FLAGGERS
> that were stationed at each crossing intersection.
> 
> Of particular note (at the bottom of the article):
> 
> There’s no estimate for how long it could take the FRA to approve quiet
> zones.
> 
> ref:
> https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094
> 
> I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
> approved by next month's PTG. (The Renaissance is within Denver proper as
> near as I can tell so that nearby intersection should be covered by this
> ruling/decision if and when it comes down.)
> 

Thanks for the update, if you are up to it, keeping us informed on this
would be nice, if only for the hilarity.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [goal][python3] more updates to the goal tools

[super user]

Got it.

Nguyen Hai

On Wed, Aug 8, 2018 at 7:58 AM Doug Hellmann  wrote:

> Champions,
>
> I have made quite a few changes to the tools for generating the zuul
> migration patches today. If you have any patches you generated locally
> for testing, please check out the latest version of the tool (when all
> of the changes merge) and regenerate them.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][tc][election] Timing of the Upcoming Stein TC election

[Tony Breeds]

Hello all,
With the PTL elections behind us it's time to start looking at the
TC election.  Our charter[1] says:

  The election is held no later than 6 weeks prior to each OpenStack
  Summit (on or before ‘S-6’ week), with elections held open for no less
  than four business days.

Assuming we have the same structure that gives us a timeline of:

  Summit is at: 2018-11-13
  Latest possible completion is at: 2018-10-02
  Moving back to Tuesday: 2018-10-02
  TC Election from 2018-09-25T23:45 to 2018-10-02T23:45
  TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45
  TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45

This puts the bulk of the nomination period during the PTG, which is
sub-optimal as the nominations cause a distraction from the PTG but more
so because the campaigning will coincide with travel home, and some
community members take vacation along with the PTG.

So I'd like to bring up the idea of moving the election forward a
little so that it's actually the campaigning period that overlaps with
the PTG:

  TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45
  TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45
  TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45

This gives us longer campaigning and election periods.

There are some advantages to doing this:

 * A panel style Q could be held formally or informally ;P
 * There's improved scope for for incoming, outgoing and staying put TC
   members to interact in a high bandwidth way.
 * In personi/private discussions with TC candidates/members.

However it isn't without downsides:

  * Election fatigue, We've just had the PTL elections and the UC
elections are currently running.  Less break before the TC elections
may not be a good thing.
  * TC candidates that can't travel to the PTG could be disadvantaged
  * The campaigning would all happen at the PTG and not on the mailing
list disadvantaging community members not at the PTG.

So thoughts?

Yours Tony.

[1] https://governance.openstack.org/tc/reference/charter.html


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

[openstack-dev] PTG Denver Horns

[David Medberry]

Requests have finally been made (today, August 7, 2018) to end the horns on
the train from Denver to Denver International airport (within the city
limits of Denver.) Prior approval had been given to remove the FLAGGERS
that were stationed at each crossing intersection.

Of particular note (at the bottom of the article):

There’s no estimate for how long it could take the FRA to approve quiet
zones.

ref:
https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094

I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
approved by next month's PTG. (The Renaissance is within Denver proper as
near as I can tell so that nearby intersection should be covered by this
ruling/decision if and when it comes down.)

See y'all soon.

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

[openstack-dev] [chef] State of the Kitchen: 6th Edition

[Samuel Cassiba]

HTML: https://samuel.cassi.ba/state-of-the-kitchen-6th-edition

This is the sixth installment of what is going on with Chef OpenStack.
The goal is to give a quick overview to see our progress and what is on
the menu. Feedback is always welcome on the content and of what you would
like to see more.

### Notable Changes

* In the past month we released Chef OpenStack 17, which aligns with the
  Queens codename of OpenStack. Stabilization efforts
  centered largely around Chef major version updates and further
  leveraging Kitchen for integration testing. At the time of this
  writing, they are mirrored to GitHub and
  [Supermarket](https://supermarket.chef.io/users/openstack){:target="_blank"}.
* openstack-attic/openstack-chef has been brought back from the aether to
  
[openstack/openstack-chef](https://git.openstack.org/cgit/openstack/openstack-chef){:target="_blank"}.
  This is now the starting point for Chef OpenStack integration examples
  and documentation. Many thanks to infra for the smooth de-mothballing.
  A special thanks to fungi for putting on his decoder ring on
  a weekend!
* The openstack-dns (Designate) and overcloud primitives (client)
  cookbooks have been rehomed to the openstack/ namespace, donated by
  jklare, calbers and frickler. (thanks!)
* Support for aodh has been added to the telemetry cookbook. Thanks to
  Seb-Solon for the patches!

### Integration

* Containerization is progressing, but decisions of old are starting to
  need to be revisited. Networking is where the main area of focus needs
  to happen.
* In past releases, Chef OpenStack pared down the integration testing to
  facilitate in landing changes without clogging Zuul. With Zuul v3,
  that allows some of the older methods to be replaced with lighter
  weight playbooks. No doubt, as tests become reimplemented, the impact
  to the build queue times will have to be a consideration again.

### Stabilization

* With Rocky stable packages nearing GA, this means that the cookbooks
  will start focusing on stabilization in earnest. More to come.
* The mariadb 2.0 rewrite has not been released upstream in Sous Chefs.
  We are collaborating to test it in the Chef OpenStack framework and
  make a decision on when to release to Supermarket. The major change
  here is making it a pure set of resources, replacing the now-defunct
  database cookbook.

### On The Menu

*Slow Cooker Pulled Pork*
* 1 pork butt (shoulder cut) -- size matters not here, the same liquid
  measurements go for an average size as well as a large size
* Cookin' Sause (see below)
* 1 cup (240mL) cider vinegar
* 1 cup (240mL) beef stock (water works, too, but we like the flavor)
* 1-2 tsp (5-10mL) liquid smoke

 Cookin' Sause
* 1 cup (340g) yellow mustard
* 1/4 cup (57g) salt
* 1/4 cup (57g) ground black pepper
* 1/4 cup (57g) granulated garlic
* 1/4 cup (57g) granulated onion
* 1/4 cup (57g) ground cayenne

> Combine the spices and the mustard with a whisk. You can use the fancy
stuff here, but it's kind of a waste. Ol' Yella works just fine.
Your food, your call.

 Dippin' Sause -- not cookin' sause!

* 1 can tomato paste
* Cider vinegar
* Red pepper flakes

> There are no measurements on this because it's subjective. Trust your
senses and err on the side of needing to add more.

*to business!*

1. Rub pork butt with cookin' sause. Make that swine sublime.
2. Place that yellow mass of meat in your slow cooker
3. Add cider vinegar, stock, liquid smoke
4. Cook for 7.5-8 hours on low, until fork tender
5. Shred with forks until it doesn't look like mustard
6. Serve with dippin' sause, or use it as drownin' sause
7. Enjoy

Your humble line cook,
Samuel Cassiba (scas)

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

Re: [openstack-dev] [neutron] Does neutron support QinQ(vlan transparent) ?

[Frank Wang]

Thanks for your detail explanation, Sean. Actually, I'm more concern how ovs l2 
agent use vlans for tenant isolation on the br-int.

I wanna discuss it deeper here


Please correct me if I understanding something wrong, Is there any way to make 
ovs l2agent to support QinQ?

for example, I believe QinQ also is a kind of tunnel encapsulation, like vxlan, 
gre.
and I think we can implement it using Hierarchical Port Binding technique
It would need two level bindings(of course, need two mechanism drivers).

the top-level binding service vlan, lower-level binding customer vlan.
The br-int is responsible for customer vlan, the br-tun is responsible for 
service vlan,



Is it feasible?  please feel free to leave you any idea.


Thanks


At 2018-08-07 19:32:44, "Sean Mooney"  wrote:
>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  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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [publiccloud-wg] Asia-EU friendly meeting today

[Zhipeng Huang]

Hi team,

A kind reminder for the UTC 7:00 meeting today, please do remember to
register yourself to irc due to new channel policy.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Mohammed Naser]

Hi Victoria,

Thank you so much for all your wonderful work especially around Outreachy! :)

Sincerely,
Mohammed

On Tue, Aug 7, 2018 at 7:47 PM, Victoria Martínez de la Cruz
 wrote:
> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this effort
> for several rounds now and I believe is a good moment for somebody else to
> take the lead. You all know how important is Outreachy to me and I'm
> grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

[Ghanshyam Mann]

  On Wed, 08 Aug 2018 07:27:06 +0900 Monty Taylor  
wrote  
 > On 08/07/2018 05:03 PM, Akihiro Motoki wrote:
 > > Hi Cinder and API-SIG folks,
 > > 
 > > During reviewing a horizon bug [0], I noticed the behavior of Cinder API 
 > > 3.0 was changed.
 > > Cinder introduced more strict schema validation for creating/updating 
 > > volume encryption type
 > > during Rocky and a new micro version 3.53 was introduced[1].
 > > 
 > > Previously, Cinder API like 3.0 accepts unused fields in POST requests
 > > but after [1] landed unused fields are now rejected even when Cinder API 
 > > 3.0 is used.
 > > In my understanding on the microversioning, the existing behavior for 
 > > older versions should be kept.
 > > Is it correct?
 > 
 > I agree with your assessment that 3.0 was used there - and also that I 
 > would expect the api validation to only change if 3.53 microversion was 
 > used.

+1. As you know, neutron also implemented strict validation in Rocky but with 
discovery via config option and extensions mechanism. Same way Cinder should 
make it with backward compatible way till 3.53 version. 

-gmann 

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



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

[openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results

[Tony Breeds]

Thank you to the electorate, to all those who voted and to all
candidates who put their name forward for Project Team Lead (PTL) in
this election. A healthy, open process breeds trust in our decision
making capability thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in
extending congratulations to the following PTLs:

 * Adjutant  : Adrian Turjak   
 * Barbican  : Ade Lee 
 * Blazar: Pierre Riteau   
 * Chef OpenStack: Samuel Cassiba  
 * Cinder: Jay Bryant  
 * Cloudkitty: Luka Peschke
 * Congress  : Eric Kao
 * Cyborg: Li Liu  
 * Designate : Graham Hayes
 * Documentation : Petr Kovar  
 * Dragonflow: [1]
 * Ec2 Api   : Andrey Pavlov   
 * Freezer   : [1]
 * Glance: Erno Kuvaja 
 * Heat  : Rico Lin
 * Horizon   : Ivan Kolodyazhny
 * I18n  : Frank Kloeker   
 * Infrastructure: Clark Boylan
 * Ironic: Julia Kreger
 * Karbor: Pengju Jiao 
 * Keystone  : Lance Bragstad  
 * Kolla : Eduardo Gonzalez Gutierrez  
 * Kuryr : Daniel Mellado  
 * Loci  : [1]
 * Magnum: Spyros Trigazis 
 * Manila: Thomas Barron   
 * Masakari  : Sampath Priyankara  
 * Mistral   : Dougal Matthews 
 * Monasca   : Witek Bedyk 
 * Murano: Rong Zhu
 * Neutron   : Miguel Lavalle  
 * Nova  : Melanie Witt
 * Octavia   : Michael Johnson 
 * OpenStackAnsible  : Mohammed Naser  
 * OpenStackClient   : Dean Troyer 
 * OpenStackSDK  : Monty Taylor
 * OpenStack Charms  : Frode Nordahl   
 * OpenStack Helm: Pete Birley 
 * Oslo  : Ben Nemec   
 * Packaging Rpm : [1]
 * PowerVMStackers   : Matthew Edmonds 
 * Puppet OpenStack  : Tobias Urdin
 * Qinling   : Lingxian Kong   
 * Quality Assurance : Ghanshyam Mann  
 * Rally : Andrey Kurilin  
 * RefStack  : [1]
 * Release Management: Sean McGinnis   
 * Requirements  : Matthew Thode   
 * Sahara: Telles Nobrega  
 * Searchlight   : [1]
 * Security  : [1]
 * Senlin: Duc Truong  
 * Solum : Rong Zhu
 * Storlets  : Kota Tsuyuzaki  
 * Swift : John Dickinson  
 * Tacker: dharmendra kushwaha 
 * Telemetry : Julien Danjou   
 * Tricircle : baisen song 
 * Tripleo   : Juan Osorio Robles  
 * Trove : [1]
 * Vitrage   : Ifat Afek   
 * Watcher   : Alexander Chadin
 * Winstackers   : [1]
 * Zaqar : wang hao
 * Zun   : Wei Ji  

Elections:
* Senlin: 

[openstack-dev] Stepping down as coordinator for the Outreachy internships

[Victoria Martínez de la Cruz]

Hi all,

I'm reaching you out to let you know that I'll be stepping down as
coordinator for OpenStack next round. I had been contributing to this
effort for several rounds now and I believe is a good moment for somebody
else to take the lead. You all know how important is Outreachy to me and
I'm grateful for all the amazing things I've done as part of the Outreachy
program and all the great people I've met in the way. I plan to keep
involved with the internships but leave the coordination tasks to somebody
else.

If you are interested in becoming an Outreachy coordinator, let me know and
I can share my experience and provide some guidance.

Thanks,

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

Re: [openstack-dev] [requirements][sdk][release] FFE request for os-service-types

[Matthew Thode]

On 18-08-07 18:19:35, Monty Taylor wrote:
> Heya!
> 
> I'd like to request a FFE for os-service-types to release 1.3.0.
> 
> The main change is the inclusion of the qinling data from
> service-types-authority, as well as the addition of an alias for magnum.
> 
> There are also two minor changes to the python portion - a parameter was
> added to get_service_type allowing for a more permissive approach to unknown
> service - and the library now handles life correctly if a service type is
> requested with the incorrect number of _'s and -'s.
> 
> Nothing should need a lower bounds bump - only the normal U-C bump.
> 

ack'd

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [requirements][sdk][release] FFE request for os-service-types

[Monty Taylor]

Heya!

I'd like to request a FFE for os-service-types to release 1.3.0.

The main change is the inclusion of the qinling data from 
service-types-authority, as well as the addition of an alias for magnum.


There are also two minor changes to the python portion - a parameter was 
added to get_service_type allowing for a more permissive approach to 
unknown service - and the library now handles life correctly if a 
service type is requested with the incorrect number of _'s and -'s.


Nothing should need a lower bounds bump - only the normal U-C bump.

Thanks!
Monty

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

[openstack-dev] [goal][python3] more updates to the goal tools

[Doug Hellmann]

Champions,

I have made quite a few changes to the tools for generating the zuul
migration patches today. If you have any patches you generated locally
for testing, please check out the latest version of the tool (when all
of the changes merge) and regenerate them.

Doug

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

Re: [openstack-dev] [cinder][api] strict schema validation and microversioning

[Monty Taylor]

On 08/07/2018 05:03 PM, Akihiro Motoki wrote:

Hi Cinder and API-SIG folks,

During reviewing a horizon bug [0], I noticed the behavior of Cinder API 
3.0 was changed.
Cinder introduced more strict schema validation for creating/updating 
volume encryption type

during Rocky and a new micro version 3.53 was introduced[1].

Previously, Cinder API like 3.0 accepts unused fields in POST requests
but after [1] landed unused fields are now rejected even when Cinder API 
3.0 is used.
In my understanding on the microversioning, the existing behavior for 
older versions should be kept.

Is it correct?


I agree with your assessment that 3.0 was used there - and also that I 
would expect the api validation to only change if 3.53 microversion was 
used.



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

[openstack-dev] [cinder][api] strict schema validation and microversioning

[Akihiro Motoki]

Hi Cinder and API-SIG folks,

During reviewing a horizon bug [0], I noticed the behavior of Cinder API
3.0 was changed.
Cinder introduced more strict schema validation for creating/updating
volume encryption type
during Rocky and a new micro version 3.53 was introduced[1].

Previously, Cinder API like 3.0 accepts unused fields in POST requests
but after [1] landed unused fields are now rejected even when Cinder API
3.0 is used.
In my understanding on the microversioning, the existing behavior for older
versions should be kept.
Is it correct?

Thanks,
Akihiro

[0] https://bugs.launchpad.net/horizon/+bug/1783467
[1] https://review.openstack.org/#/c/573093/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [rally] ACTION REQUIRED for projects using readthedocs

[Sean McGinnis]

The recent release of rally failed the docs publishing to readthedocs. This
appears to be related to the actions required below.

The failure from the job can be found here:

http://logs.openstack.org/0c/0cd69c70492f800e0835da4de006fc292e43a5f1/release/trigger-readthedocs-webhook/e9de48a/job-output.txt.gz#_2018-08-07_21_10_16_898906

On Fri, Aug 03, 2018 at 02:20:40PM +1000, Ian Wienand wrote:
> Hello,
> 
> tl;dr : any projects using the "docs-on-readthedocs" job template
> to trigger a build of their documentation in readthedocs needs to:
> 
>  1) add the "openstackci" user as a maintainer of the RTD project
>  2) generate a webhook integration URL for the project via RTD
>  3) provide the unique webhook ID value in the "rtd_webhook_id" project
> variable
> 
> See
> 
>  
> https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
> 
> --
> 
> readthedocs has recently updated their API for triggering a
> documentation build.  In the old API, anyone could POST to a known URL
> for the project and it would trigger a build.  This end-point has
> stopped responding and we now need to use an authenticated webhook to
> trigger documentation builds.
> 
> Since this is only done in the post and release pipelines, projects
> probably haven't had great feedback that current methods are failing
> and this may be a surprise.  To check your publishing, you can go to
> the zuul builds page [1] and filter by your project and the "post"
> pipeline to find recent runs.
> 
> There is now some setup required which can only be undertaken by a
> current maintainer of the RTD project.
> 
> In short; add the "openstackci" user as a maintainer, add a "generic
> webhook" integration to the project, find the last bit of the URL from
> that and put it in the project variable "rtd_webhook_id".
> 
> Luckily OpenStack infra keeps a team of highly skilled digital artists
> on retainer and they have produced a handy visual guide available at
> 
>   https://imgur.com/a/Pp4LH31
> 
> Once the RTD project is setup, you must provide the webhook ID value
> in your project variables.  This will look something like:
> 
>  - project:
> templates:
>   - docs-on-readthedocs
>   - publish-to-pypi
> vars:
>   rtd_webhook_id: '12345'
> check:
>   jobs:
>   ...
> 
> For actual examples; see pbrx [2] which keeps its config in tree, or
> gerrit-dash-creator which has its configuration in project-config [3].
> 
> Happy to help if anyone is having issues, via mail or #openstack-infra
> 
> Thanks!
> 
> -i
> 
> p.s. You don't *have* to use the jobs from the docs-on-readthedocs
> templates and hence add infra as a maintainer; you can setup your own
> credentials with zuul secrets in tree and write your playbooks and
> jobs to use the generic role [4].  We're always happy to discuss any
> concerns.
> 
> [1] https://zuul.openstack.org/builds.html
> [2] https://git.openstack.org/cgit/openstack/pbrx/tree/.zuul.yaml#n17
> [3] 
> https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml
> [4] https://zuul-ci.org/docs/zuul-jobs/roles.html#role-trigger-readthedocs
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [openstack-helm] [vote] Core Reviewer nomination for Chris Wedgwood

[MCEUEN, MATT]

With this unanimous vote:  welcome Mr. Wedgwood to the OpenStack-Helm core 
reviewer team – thank you for your work to date, and I’m looking forward to 
paving the way to OSH greatness with you!

From: Pete Birley 
Sent: Tuesday, August 7, 2018 12:08 PM
To: t...@irrational.io
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-helm] [vote] Core Reviewer nomination 
for Chris Wedgwood

An emphatic +1, Chris has really done some great work reviewing, and 
contributing code.


On 7 August 2018 at 09:45, Tin Lam mailto:tin...@gmail.com>> 
wrote:
+1

On Tue, Aug 7, 2018 at 9:31 AM Alan Meadows 
mailto:alan.mead...@gmail.com>> wrote:
+1

On Fri, 2018-08-03 at 16:52 +, Richard Wellum 
mailto:richwel...@gmail.com>
> wrote:

>
> +1
>
> On Fri, Aug 3, 2018 at 11:39 AM Steve Wilkerson mailto:wilkers.steve@gmail.%0b>> com>
> wrote:
>
> > +1
> >
> > On Fri, Aug 3, 2018 at 10:05 AM, MCEUEN, MATT 
> > mailto:mm9...@att.com>>
> > wrote:
> >
> > > OpenStack-Helm core reviewer team,
> > >
> > > I would like to nominate Chris Wedgwood as core review for the
> > > OpenStack-Helm.
> > >
> > > Chris is one of the most prolific reviewers in the OSH community,
> > > but
> > > more importantly is a very thorough and helpful reviewer.  Many
> > > of my most
> > > insightful reviews are thanks to him, and I know the same is true
> > > for many
> > > other team members.  In addition, he is an accomplished OSH
> > > engineer and
> > > has contributed features that run the gamut, including Ceph
> > > integration,
> > > Calico support, Neutron configuration, Gating, and core Helm-
> > > Toolkit
> > > functionality.
> > >
> > > Please consider this email my +1 vote.
> > >
> > > A +1 vote indicates that you are in favor of his core reviewer
> > > candidacy,
> > > and a -1 is a veto.  Voting will be open for the next seven days
> > > (closing
> > > 8/10) or until all OpenStack-Helm core reviewers cast their vote.
> > >
> > > Thank you,
> > > Matt McEuen
> > >
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Regards,

Tin Lam

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

Re: [openstack-dev] [python-senlinclient][release][requirements] FFE for python-senlinclient 1.8.0

[Sean McGinnis]

On Tue, Aug 07, 2018 at 03:25:39PM -0500, Sean McGinnis wrote:
> Added requirements tag to the subject since this is a requirements FFE.
> 
> On Tue, Aug 07, 2018 at 11:44:04PM +0800, liu.xuefe...@zte.com.cn wrote:
> > hi, all
> > 
> > 
> > I'd like to request an FFE to release 1.8.0(stable/rocky)
> >  for python-senlinclient.
> > 
> > The CURRENT_API_VERSION has been changed to "1.10", we need this release.
> > 

XueFeng, do you just need upper-constraints raised for this, or also the
minimum version? From that last sentence, I'm assuming you need to ensure only
1.8.0 is used for Rocky deployments.


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

Re: [openstack-dev] [python-senlinclient][release][requirements] FFE for python-senlinclient 1.8.0

[Sean McGinnis]

Added requirements tag to the subject since this is a requirements FFE.

On Tue, Aug 07, 2018 at 11:44:04PM +0800, liu.xuefe...@zte.com.cn wrote:
> hi, all
> 
> 
> I'd like to request an FFE to release 1.8.0(stable/rocky)
>  for python-senlinclient.
> 
> The CURRENT_API_VERSION has been changed to "1.10", we need this release.
> 
> BestRegards,
> XueFeng


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


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

Re: [openstack-dev] [openstack-helm] [vote] Core Reviewer nomination for Chris Wedgwood

[Pete Birley]

An emphatic +1, Chris has really done some great work reviewing, and
contributing code.


On 7 August 2018 at 09:45, Tin Lam  wrote:

> +1
>
> On Tue, Aug 7, 2018 at 9:31 AM Alan Meadows 
> wrote:
>
>> +1
>>
>> On Fri, 2018-08-03 at 16:52 +, Richard Wellum > > wrote:
>>
>> >
>> > +1
>> >
>> > On Fri, Aug 3, 2018 at 11:39 AM Steve Wilkerson > > com>
>> > wrote:
>> >
>> > > +1
>> > >
>> > > On Fri, Aug 3, 2018 at 10:05 AM, MCEUEN, MATT 
>> > > wrote:
>> > >
>> > > > OpenStack-Helm core reviewer team,
>> > > >
>> > > > I would like to nominate Chris Wedgwood as core review for the
>> > > > OpenStack-Helm.
>> > > >
>> > > > Chris is one of the most prolific reviewers in the OSH community,
>> > > > but
>> > > > more importantly is a very thorough and helpful reviewer.  Many
>> > > > of my most
>> > > > insightful reviews are thanks to him, and I know the same is true
>> > > > for many
>> > > > other team members.  In addition, he is an accomplished OSH
>> > > > engineer and
>> > > > has contributed features that run the gamut, including Ceph
>> > > > integration,
>> > > > Calico support, Neutron configuration, Gating, and core Helm-
>> > > > Toolkit
>> > > > functionality.
>> > > >
>> > > > Please consider this email my +1 vote.
>> > > >
>> > > > A +1 vote indicates that you are in favor of his core reviewer
>> > > > candidacy,
>> > > > and a -1 is a veto.  Voting will be open for the next seven days
>> > > > (closing
>> > > > 8/10) or until all OpenStack-Helm core reviewers cast their vote.
>> > > >
>> > > > Thank you,
>> > > > Matt McEuen
>> > > >
>> > > > _
>> > > > _
>> > > > OpenStack Development Mailing List (not for usage questions)
>> > > > Unsubscribe:
>> > > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> Regards,
>
> Tin Lam
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] senlin 6.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/senlin/

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/senlin/log/?h=stable/rocky

Release notes for senlin can be found at:

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

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

https://bugs.launchpad.net/senlin-tempest-plugin

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


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

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

[Corey Bryant]

On Tue, Aug 7, 2018 at 11:28 AM, Zane Bitter  wrote:

> Top posting to avoid getting into the weeds.
>
> * OpenStack is indeed lagging behind
> * The road to 3.7 (and eventually 3.8) runs through 3.6
> * As part of the project-wide python3-first goal we aim to have everything
> working on 3.6 for Stein, so we are making some progress at least
> * As of now we are *not* dropping support for 3.5 in Stein
> * No matter what we do, the specific issue you're encountering is
> structural: we don't add support for a Python version in the gate until it
> is available in an Ubuntu LTS release, and that doesn't happen until after
> it is available in Debian, so you will always have the problem that new
> Python versions will be introduced in Debian before we have a gate for them
>

Thanks for mentioning this. I was concerned that there wouldn't be any
gating until Ubuntu 20.04 (April 2020) but Py3.7 is available in bionic
today. It's a bit older version but I think that's just because we're early
py3.7 stages, so we'll try to get that updated.

Thanks,
Corey

* Structural problems require structural solutions; "everybody work
> harder/pay more attention/prioritise differently" will not do it
> * I don't see any evidence that people are refusing to review patches that
> fix 3.7 issues, and I certainly don't think fixing them is 'controversial'
>
>
> On 07/08/18 10:11, Thomas Goirand wrote:
>
>> 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)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List 

[openstack-dev] [python-senlinclient][release]FFE for python-senlinclient 1.8.0

[liu.xuefeng1]

hi, all


I'd like to request an FFE to release 1.8.0(stable/rocky)
 for python-senlinclient.

The CURRENT_API_VERSION has been changed to "1.10", we need this release.

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

Re: [openstack-dev] [tripleo] Patches to speed up plan operations

[Dan Prince]

Thanks for taking this on Ian! I'm fully on board with the effort. I
like the consolidation and performance improvements. Storing t-h-t
templates in Swift worked okay 3-4 years ago. Now that we have more
templates, many of which need .j2 rendering the storage there has
become quite a bottleneck.

Additionally, since we'd be sending commands to Heat via local
filesystem template storage we could consider using softlinks again
within t-h-t which should help with refactoring and deprecation
efforts.

Dan
On Wed, Aug 1, 2018 at 7:35 PM Ian Main  wrote:
>
>
> Hey folks!
>
> So I've been working on some patches to speed up plan operations in TripleO.  
> This was originally driven by the UI needing to be able to perform a 'plan 
> upload' in something less than several minutes. :)
>
> https://review.openstack.org/#/c/581153/
> https://review.openstack.org/#/c/581141/
>
> I have a functioning set of patches, and it actually cuts over 2 minutes off 
> the overcloud deployment time.
>
> Without patch:
> + openstack overcloud plan create --templates 
> /home/stack/tripleo-heat-templates/ overcloud
> Creating Swift container to store the plan
> Creating plan from template files in: /home/stack/tripleo-heat-templates/
> Plan created.
> real3m3.415s
>
> With patch:
> + openstack overcloud plan create --templates 
> /home/stack/tripleo-heat-templates/ overcloud
> Creating Swift container to store the plan
> Creating plan from template files in: /home/stack/tripleo-heat-templates/
> Plan created.
> real0m44.694s
>
> This is on VMs.  On real hardware it now takes something like 15-20 seconds 
> to do the plan upload which is much more manageable from the UI standpoint.
>
> Some things about what this patch does:
>
> - It makes use of process-templates.py (written for the undercloud) to 
> process the jinjafied templates.  This reduces replication with the existing 
> version in the code base and is very fast as it's all done on local disk.
> - It stores the bulk of the templates as a tarball in swift.  Any individual 
> files in swift take precedence over the contents of the tarball so it should 
> be backwards compatible.  This is a great speed up as we're not accessing a 
> lot of individual files in swift.
>
> There's still some work to do; cleaning up and fixing the unit tests, testing 
> upgrades etc.  I just wanted to get some feedback on the general idea and 
> hopefully some reviews and/or help - especially with the unit test stuff.
>
> Thanks everyone!
>
> Ian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-08-07 16:11:43 +0200:
> On 08/07/2018 03:24 PM, Sean Mooney wrote:
> 
> > 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.

That goes both ways, Thomas. We're in the middle of the RC1 deadline
week for Rocky right now. This is not a great time to be pushing
for new work unrelated to finishing that release.

> > 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.

The community is not prepared to support 3.7 today. That doesn't
mean we will never support it, just that it is not the most important
thing for us to be doing right now. We'll get there.

Doug

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

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

[Zane Bitter]

Top posting to avoid getting into the weeds.

* OpenStack is indeed lagging behind
* The road to 3.7 (and eventually 3.8) runs through 3.6
* As part of the project-wide python3-first goal we aim to have 
everything working on 3.6 for Stein, so we are making some progress at least

* As of now we are *not* dropping support for 3.5 in Stein
* No matter what we do, the specific issue you're encountering is 
structural: we don't add support for a Python version in the gate until 
it is available in an Ubuntu LTS release, and that doesn't happen until 
after it is available in Debian, so you will always have the problem 
that new Python versions will be introduced in Debian before we have a 
gate for them
* Structural problems require structural solutions; "everybody work 
harder/pay more attention/prioritise differently" will not do it
* I don't see any evidence that people are refusing to review patches 
that fix 3.7 issues, and I certainly don't think fixing them is 
'controversial'


On 07/08/18 10:11, Thomas Goirand wrote:

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)

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




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

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

[Ian Y. Choi]

Oh my mistake - document not version. Rewriting:

For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper from two different 
projects into "openstack-org" project with different document names, and

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian



Ian Y. Choi wrote on 8/8/2018 12:06 AM:

Hello Frank,

I did not notice the list of project but just from the perspective of 
translation metrics in Stackalytics and Zanata,
whitepaper translation contribution is retrieved from Zanata to 
Stackalytics according to the implementation through 
https://review.openstack.org/#/c/288871/ .


For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper into "openstack-org" 
project with different version names, ane

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian

Frank Kloeker wrote on 8/7/2018 4:49 PM:
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 Don't know how to escape 
this. Maybe you will see the warning during import too.


kind regards

Frank

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

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

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

regards

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



Hi Jimmy,

from the GUI I'll get this link:

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


[1]

paper version  are only in container whitepaper:


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


[2]

In general there is no group named papers

kind regards

Frank

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

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


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


[3]

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

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

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

thx

Frank

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

Follow up on the Edge paper specifically:

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


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

Let me know if I can assist with anything.

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

Cheers,
Jimmy

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

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of 

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Dan Prince]

On Thu, Aug 2, 2018 at 5:42 PM Steve Baker  wrote:
>
>
>
> On 02/08/18 13:03, Alex Schultz wrote:
> > On Mon, Jul 9, 2018 at 6:28 AM, Bogdan Dobrelya  wrote:
> >> On 7/6/18 7:02 PM, Ben Nemec wrote:
> >>>
> >>>
> >>> On 07/05/2018 01:23 PM, Dan Prince wrote:
>  On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:
> >
> > I would almost rather see us organize the directories by service
> > name/project instead of implementation.
> >
> > Instead of:
> >
> > puppet/services/nova-api.yaml
> > puppet/services/nova-conductor.yaml
> > docker/services/nova-api.yaml
> > docker/services/nova-conductor.yaml
> >
> > We'd have:
> >
> > services/nova/nova-api-puppet.yaml
> > services/nova/nova-conductor-puppet.yaml
> > services/nova/nova-api-docker.yaml
> > services/nova/nova-conductor-docker.yaml
> >
> > (or perhaps even another level of directories to indicate
> > puppet/docker/ansible?)
> 
>  I'd be open to this but doing changes on this scale is a much larger
>  developer and user impact than what I was thinking we would be willing
>  to entertain for the issue that caused me to bring this up (i.e. how to
>  identify services which get configured by Ansible).
> 
>  Its also worth noting that many projects keep these sorts of things in
>  different repos too. Like Kolla fully separates kolla-ansible and
>  kolla-kubernetes as they are quite divergent. We have been able to
>  preserve some of our common service architectures but as things move
>  towards kubernetes we may which to change things structurally a bit
>  too.
> >>>
> >>> True, but the current directory layout was from back when we intended to
> >>> support multiple deployment tools in parallel (originally
> >>> tripleo-image-elements and puppet).  Since I think it has become clear 
> >>> that
> >>> it's impractical to maintain two different technologies to do essentially
> >>> the same thing I'm not sure there's a need for it now.  It's also worth
> >>> noting that kolla-kubernetes basically died because there wasn't enough
> >>> people to maintain both deployment methods, so we're not the only ones who
> >>> have found that to be true.  If/when we move to kubernetes I would
> >>> anticipate it going like the initial containers work did - development 
> >>> for a
> >>> couple of cycles, then a switch to the new thing and deprecation of the 
> >>> old
> >>> thing, then removal of support for the old thing.
> >>>
> >>> That being said, because of the fact that the service yamls are
> >>> essentially an API for TripleO because they're referenced in user
> >>
> >> this ^^
> >>
> >>> resource registries, I'm not sure it's worth the churn to move everything
> >>> either.  I think that's going to be an issue either way though, it's just 
> >>> a
> >>> question of the scope.  _Something_ is going to move around no matter how 
> >>> we
> >>> reorganize so it's a problem that needs to be addressed anyway.
> >>
> >> [tl;dr] I can foresee reorganizing that API becomes a nightmare for
> >> maintainers doing backports for queens (and the LTS downstream release 
> >> based
> >> on it). Now imagine kubernetes support comes within those next a few years,
> >> before we can let the old API just go...
> >>
> >> I have an example [0] to share all that pain brought by a simple move of
> >> 'API defaults' from environments/services-docker to environments/services
> >> plus environments/services-baremetal. Each time a file changes contents by
> >> its old location, like here [1], I had to run a lot of sanity checks to
> >> rebase it properly. Like checking for the updated paths in resource
> >> registries are still valid or had to/been moved as well, then picking the
> >> source of truth for diverged old vs changes locations - all that to loose
> >> nothing important in progress.
> >>
> >> So I'd say please let's do *not* change services' paths/namespaces in t-h-t
> >> "API" w/o real need to do that, when there is no more alternatives left to
> >> that.
> >>
> > Ok so it's time to dig this thread back up. I'm currently looking at
> > the chrony support which will require a new service[0][1]. Rather than
> > add it under puppet, we'll likely want to leverage ansible. So I guess
> > the question is where do we put services going forward?  Additionally
> > as we look to truly removing the baremetal deployment options and
> > puppet service deployment, it seems like we need to consolidate under
> > a single structure.  Given that we don't want force too much churn,
> > does this mean that we should align to the docker/services/*.yaml
> > structure or should we be proposing a new structure that we can try to
> > align on.
> >
> > There is outstanding tech-debt around the nested stacks and references
> > within these services when we added the container deployments so it's
> > something that would be beneficial to start tackling sooner rather
> > than 

[openstack-dev] qinling 1.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/qinling/

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/qinling/log/?h=stable/rocky

Release notes for qinling can be found at:

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




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

Re: [openstack-dev] Paste unmaintained

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-08-07 16:57:59 +0200:
> On 08/02/2018 04:27 PM, Doug Hellmann wrote:
> > 
> > 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.
> 
> Doug,
> 
> That's nice to have direct dependency, but this doesn't cover
> everything. If using uwsgi, if you want any kind of logging from the
> wsgi application, you need to use pastescript, which itself runtimes
> depends on paste. So, anything which potentially has an API also depends
> indirectly on Paste.

I'm not sure why that would be the case. Surely *any* middleware could
set up logging?

Doug

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

Re: [openstack-dev] Paste unmaintained

[Chris Dent]

On Tue, 7 Aug 2018, Thomas Goirand wrote:


That's nice to have direct dependency, but this doesn't cover
everything. If using uwsgi, if you want any kind of logging from the
wsgi application, you need to use pastescript, which itself runtimes
depends on paste. So, anything which potentially has an API also depends
indirectly on Paste.


Can you point to more info on this, as it doesn't correspond with my
experience of using uwsgi?

In my experience uwsgi has built in support for logging without
dependencies: https://uwsgi-docs.readthedocs.io/en/latest/LogFormat.html

As I said in IRC a while ago: It doesn't really matter how many of
our projects are using Paste or PasteDeploy: If any of them are,
then we have a problem to address. We already know that some of the
big/popular ones use it. That's enough to require us to work on a
solution.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ian Y. Choi]

Hello Frank,

I did not notice the list of project but just from the perspective of 
translation metrics in Stackalytics and Zanata,
whitepaper translation contribution is retrieved from Zanata to 
Stackalytics according to the implementation through 
https://review.openstack.org/#/c/288871/ .


For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper into "openstack-org" 
project with different version names, ane

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian

Frank Kloeker wrote on 8/7/2018 4:49 PM:
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 Don't know how to escape this. 
Maybe you will see the warning during import too.


kind regards

Frank

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

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

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

regards

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



Hi Jimmy,

from the GUI I'll get this link:

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


[1]

paper version  are only in container whitepaper:


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


[2]

In general there is no group named papers

kind regards

Frank

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

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


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


[3]

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

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

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

thx

Frank

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

Follow up on the Edge paper specifically:

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


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

Let me know if I can assist with anything.

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

Cheers,
Jimmy

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

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I indicated that we
would also be moving the Edge paper to HTML so that we could 
prevent

that additional 

Re: [openstack-dev] Paste unmaintained

[Thomas Goirand]

On 08/02/2018 04:27 PM, Doug Hellmann wrote:
> 
> 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  | 

Re: [openstack-dev] [tripleo] Patches to speed up plan operations

[Bogdan Dobrelya]

On 8/2/18 1:34 AM, Ian Main wrote:


Hey folks!

So I've been working on some patches to speed up plan operations in 
TripleO.  This was originally driven by the UI needing to be able to 
perform a 'plan upload' in something less than several minutes. :)


https://review.openstack.org/#/c/581153/
https://review.openstack.org/#/c/581141/

I have a functioning set of patches, and it actually cuts over 2 minutes 
off the overcloud deployment time.


Without patch:
+ openstack overcloud plan create --templates 
/home/stack/tripleo-heat-templates/ overcloud

Creating Swift container to store the plan
Creating plan from template files in: /home/stack/tripleo-heat-templates/
Plan created.
real    3m3.415s

With patch:
+ openstack overcloud plan create --templates 
/home/stack/tripleo-heat-templates/ overcloud

Creating Swift container to store the plan
Creating plan from template files in: /home/stack/tripleo-heat-templates/
Plan created.
real    0m44.694s

This is on VMs.  On real hardware it now takes something like 15-20 
seconds to do the plan upload which is much more manageable from the UI 
standpoint.


Some things about what this patch does:

- It makes use of process-templates.py (written for the undercloud) to 
process the jinjafied templates.  This reduces replication with the 
existing version in the code base and is very fast as it's all done on 
local disk.


Just wanted to say Special Big Thank You for doing that code 
consolidation work!


- It stores the bulk of the templates as a tarball in swift.  Any 
individual files in swift take precedence over the contents of the 
tarball so it should be backwards compatible.  This is a great speed up 
as we're not accessing a lot of individual files in swift.


There's still some work to do; cleaning up and fixing the unit tests, 
testing upgrades etc.  I just wanted to get some feedback on the general 
idea and hopefully some reviews and/or help - especially with the unit 
test stuff.


Thanks everyone!

     Ian


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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [openstack-helm] [vote] Core Reviewer nomination for Chris Wedgwood

[Alan Meadows]

+1

On Fri, 2018-08-03 at 16:52 +, Richard Wellum  wrote:

> 
> +1
> 
> On Fri, Aug 3, 2018 at 11:39 AM Steve Wilkerson  com>
> wrote:
> 
> > +1
> > 
> > On Fri, Aug 3, 2018 at 10:05 AM, MCEUEN, MATT 
> > wrote:
> > 
> > > OpenStack-Helm core reviewer team,
> > > 
> > > I would like to nominate Chris Wedgwood as core review for the
> > > OpenStack-Helm.
> > > 
> > > Chris is one of the most prolific reviewers in the OSH community,
> > > but
> > > more importantly is a very thorough and helpful reviewer.  Many
> > > of my most
> > > insightful reviews are thanks to him, and I know the same is true
> > > for many
> > > other team members.  In addition, he is an accomplished OSH
> > > engineer and
> > > has contributed features that run the gamut, including Ceph
> > > integration,
> > > Calico support, Neutron configuration, Gating, and core Helm-
> > > Toolkit
> > > functionality.
> > > 
> > > Please consider this email my +1 vote.
> > > 
> > > A +1 vote indicates that you are in favor of his core reviewer
> > > candidacy,
> > > and a -1 is a veto.  Voting will be open for the next seven days
> > > (closing
> > > 8/10) or until all OpenStack-Helm core reviewers cast their vote.
> > > 
> > > Thank you,
> > > Matt McEuen
> > > 
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [kolla] Dropping core reviewer

[Steven Dake (stdake)]

Kollians,


Many of you that know me well know my feelings towards participating as a core 
reviewer in a project.  Folks with the ability to +2/+W gerrit changes can 
sometimes unintentionally harm a codebase if they are not consistently 
reviewing and maintaining codebase context.  I also believe in leading an 
exception-free life, and I'm no exception to my own rules.  As I am not 
reviewing Kolla actively given my OpenStack individually elected board of 
directors service and other responsibilities, I am dropping core reviewer 
ability for the Kolla repositories.


I want to take a moment to thank the thousands of people that have contributed 
and shaped Kolla into the modern deployment system for OpenStack that it is 
today.  I personally find Kolla to be my finest body of work as a leader.  
Kolla would not have been possible without the involvement of the OpenStack 
global community working together to resolve the operational pain points of 
OpenStack.  Thank you for your contributions.


Finally, quoting Thierry [1] from our initial application to OpenStack, " ... 
Long live Kolla!"


Cheers!

-steve


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



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

Re: [openstack-dev] [requirements][release] FFE for openstacksdk 0.17.2

[Matthew Thode]

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)


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

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

[Wesley Hayutin]

On Mon, Aug 6, 2018 at 5:55 PM Wesley Hayutin  wrote:

> On Mon, Aug 6, 2018 at 12:56 PM Wesley Hayutin 
> wrote:
>
>> Greetings,
>>
>> There is currently an unplanned outtage atm for the tripleo 3rd party OVB
>> based jobs.
>> We will contact the list when there are more details.
>>
>> Thank you!
>>
>
> OK,
> I'm going to call an end to the current outtage. We are closely monitoring
> the ovb 3rd party jobs.
> I'll called for the outtage when we hit [1].  Once I deleted the stack
> that moved teh HA routers to back_up state, the networking came back online.
>
> Additionally Kieran and I had to work through a number of instances that
> required admin access to remove.
> Once those resources  were cleaned up our CI tooling removed the rest of
> the stacks in delete_failed status.The stacks in delete_failed status
> were holding ip address that were causing new stacks to fail [2]
>
> There are still active issues that could cause OVB jobs to fail.
> This connection issues [3] was originaly thought to be DNS, however that
> turned out to not be the case.
> You may also see your job have a "node_failure" status, Paul has sent
> updates about this issue and is working on a patch and integration into rdo
> software factory.
>
> The CI team is close to including all the console logs into the regular
> job logs, however if needed atm they can be viewed at [5].
> We are also adding the bmc to the list of instances that we collect logs
> from.
>
> *To summarize* the most recent outtage was infra related and the errors
> were swallowed up in the bmc console log that at the time was not available
> to users.
>
> We continue to monitor that ovb jobs at http://cistatus.tripleo.org/
> The  legacy-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master job
> is at a 53% pass rate, it needs to move to a > 85% pass rate to match other
> check jobs.
>
> Thanks all!
>

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

Wes Hayutin

Associate MANAGER

Red Hat



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


View my calendar and check my availability for meetings HERE

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

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

[Thomas Goirand]

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)

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

Re: [openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis

[Matt Riedemann]

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

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

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

[Sean Mooney]

On 7 August 2018 at 12:52, Thomas Goirand  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [requirements][release] FFE for openstacksdk 0.17.2

[Monty Taylor]

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

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

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

[Thomas Goirand]

On 08/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)

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

[openstack-dev] [nova]Notification update week 32

[Balázs Gibizer]

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




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

Re: [openstack-dev] [neutron] Does neutron support QinQ(vlan transparent) ?

[Sean Mooney]

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  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [tc] [all] TC Report 18-32

[Chris Dent]

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

[openstack-dev] [neutron] Does neutron support QinQ(vlan transparent) ?

[Frank Wang]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Frank Kloeker]

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 Don't know how to escape this. Maybe 
you will see the warning during import too.


kind regards

Frank

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

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

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

regards

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



Hi Jimmy,

from the GUI I'll get this link:


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

[1]

paper version  are only in container whitepaper:



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

[2]

In general there is no group named papers

kind regards

Frank

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

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



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

[3]

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

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

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

thx

Frank

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

Follow up on the Edge paper specifically:


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

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

Let me know if I can assist with anything.

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

Cheers,
Jimmy

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

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I indicated that we
would also be moving the Edge paper to HTML so that we could 
prevent

that additional design resource cost.
On the other hand, the source strings of edge computing 
whitepaper

which I18n team previously translated do not include HTML markup
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF,
which we unfortunately didn't have the resources to implement in 
the

same format.

I really appreciate Akihiro's work on RST-based support on
publishing translated edge computing whitepapers, since
translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work 
on
the RST-based translation.  At the moment, it's just not usable 
for

the reasons 

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

[Andreas Jaeger]

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


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

Re: [openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis

[Flint WALRUS]

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  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-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev