Re: [openstack-dev] [User-committee] [publiccloud-wg] Meeting tomorrow

[Zhipeng Huang]

cc'ed sig list.

Kind reminder for the meeting about 2 and half hours away, we will do a
review of the denver ptg summary [0] and then go over the forum sessions
which we want to propose [1]

This is an EU/APAC friendly meeting so please do join us if you are in the
region :)

[0]https://etherpad.openstack.org/p/publiccloud-wg-stein-ptg-summary
[1]https://etherpad.openstack.org/p/BER-forum-public-cloud

On Tue, Sep 18, 2018 at 8:05 PM Tobias Rydberg <
tobias.rydb...@citynetwork.eu> wrote:

> Hi everyone,
>
> Don't forget that we have a meeting tomorrow at 0700 UTC at IRC channel
> #openstack-publiccloud.
>
> See you all there!
>
> Cheers,
> Tobias
>
> --
> Tobias Rydberg
> Senior Developer
> Twitter & IRC: tobberydberg
>
> www.citynetwork.eu | www.citycloud.com
>
> INNOVATION THROUGH OPEN IT INFRASTRUCTURE
> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [python3] tempest and grenade conversion to python 3.6

[Ghanshyam Mann]

  On Wed, 19 Sep 2018 02:28:29 +0900 Doug Hellmann  
wrote  
 > Excerpts from Clark Boylan's message of 2018-09-18 09:53:45 -0700:
 > > On Tue, Sep 18, 2018, at 9:46 AM, Nate Johnston wrote:
 > > > Hello python 3.6 champions,
 > > > 
 > > > I have looked around a little, and I don't see a method for me to
 > > > specifically select the version of python that the tempest and grenade
 > > > jobs for my project (neutron) are using.  I assume one of four things
 > > > is at play here:
 > > > 
 > > > A. These projects already shifted to python 3 and I don't have to worry
 > > > about it
 > > > 
 > > > B. There is a toggle for the python version I just have not seen yet
 > > > 
 > > > C. These projects are still on python 2 and need help to do a conversion
 > > > to python 3, which would affect all customers
 > > > 
 > > > D. Something else that I have failed to imagine
 > > > 
 > > > Could you elaborate which of these options properly reflects the state
 > > > of affairs?  If the answer is "C" then perhaps we can start a discussion
 > > > on that migration.
 > > 
 > > For our devstack and grenade jobs tempest is installed using tox [0]. And 
 > > since the full testenv in tempest's tox.ini doesn't specify a python 
 > > version [1] I expect that it will attempt a python2 virtualenv on every 
 > > platform (Arch linux may be an exception but we don't test that).
 > > 
 > > I think that means C is the situation here. To change that you can set 
 > > basepython to python3 (see [2] for an example) which will run tempest 
 > > under whichever python3 is present on the system. The one gotcha for this 
 > > is that it will break tempest on centos which does not have python3. Maybe 
 > > the thing to do there is add a full-python2 testenv that centos can run?
 > > 
 > > [0] 
 > > https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest#n653
 > > [1] https://git.openstack.org/cgit/openstack/tempest/tree/tox.ini#n74
 > > [2] https://git.openstack.org/cgit/openstack-infra/zuul/tree/tox.ini#n7
 > > 
 > > Hope this helps,
 > > Clark
 > > 
 > 
 > While having tempest run under python 3 would be great, I'm not sure
 > that's necessary in order to test a service.
 > 
 > Don't those jobs use devstack to install the system being tested? And
 > devstack uses some environment variables to control the version of
 > python. For example the tempest-full-py3 job [1] defines USE_PYTHON3 as
 > 'true'.
 > 
 > What's probably missing is a version of the grenade job that allows us
 > to control that USE_PYTHON3 variable before and after the upgrade.
 > 
 > I see a few different grenade jobs (neutron-grenade,
 > neutron-grenade-multinode,
 > legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
 > Which ones are "current" and would make a good candidate as a base for a
 > new job?

All these are legacy job,  only name changed so i will not recommend them to 
use as base. Currently those are on neutron repo instead of grenade. We 
discussed this in PTG about finishing the grenade base zuul v3 job work so that 
other project can use as base. Work is in progress[1] and on priority[2] for us 
to finish as early as possible. 

[1] 
https://review.openstack.org/#/q/topic:grenade_zuulv3+(status:open+OR+status:merged)
[2] https://etherpad.openstack.org/p/qa-stein-priority

-gmann
 > 
 > Doug
 > 
 > [1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n70
 > 
 > __
 > 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] [python3] tempest and grenade conversion to python 3.6

[Matthew Treinish]

On Tue, Sep 18, 2018 at 09:52:50PM -0500, Matt Riedemann wrote:
> On 9/18/2018 12:28 PM, Doug Hellmann wrote:
> > What's probably missing is a version of the grenade job that allows us
> > to control that USE_PYTHON3 variable before and after the upgrade.
> > 
> > I see a few different grenade jobs (neutron-grenade,
> > neutron-grenade-multinode,
> > legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
> > Which ones are "current" and would make a good candidate as a base for a
> > new job?
> 
> Grenade just runs devstack on the old side (e.g. stable/rocky) using the
> devstack stackrc file (which could have USE_PYTHON3 in it), runs tempest
> 'smoke' tests to create some resources, saves off some information about
> those resources in a "database" (just an ini file), then runs devstack on
> the new side (e.g. master) using the new side stackrc file and verifies
> those saved off resources made it through the upgrade. It's all bash so
> there isn't anything python-specific about grenade.

This isn't quite right, we run devstack on the old side. But, on the new side
we don't actually run devstack. Grenade updates the code, runs DB migrations
(and any other mandatory upgrade steps), and then just relaunches the service.
That's kind of the point to make sure new code works with old config.

The target (ie new side) stackrc and localrc/local.conf are there for the
common functions shared between devstack and grenade which are used to do things
like pull the code and start services to make sure they run against the proper
branches. Since there isn't any point in reimplementing the same exact thing.
But we don't do a full devstack run, that's why you see only see stack.sh run
once in the logs on a grenade job.

> 
> I saw, but didn't comment on, the other thread about if it would be possible
> to create a grenade-2to3 job. I'd think that is pretty doable based on the
> USE_PYTHON3 variable. We'd just have that False on the old side, and True on
> the new side, and devstack will do it's thing. Right now the USE_PYTHON3
> variable is global in devstack-gate [1] (which is the thing that
> orchestrates the grenade run for the legacy jobs), but I'm sure we could
> hack that to be specific to the base (old) and target (new) release for the
> grenade run.

I don't think this will work because we won't be running any initial python 3
setup on the system. I think it will just update paths and try to use python3
pip and python3 paths for things, but it will be missing the things it needs
for those to work. It's probably worth a try either way (a quick experiment
to say definitively) but my gut is telling me that it's not going to be that
simple.


-Matt Treinish

> 
> [1] 
> https://github.com/openstack-infra/devstack-gate/blob/95fa4343104eafa655375cce3546d27139211d13/devstack-vm-gate-wrap.sh#L434
> 


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] [python3] tempest and grenade conversion to python 3.6

[Matt Riedemann]

On 9/18/2018 9:52 PM, Matt Riedemann wrote:

On 9/18/2018 12:28 PM, Doug Hellmann wrote:

What's probably missing is a version of the grenade job that allows us
to control that USE_PYTHON3 variable before and after the upgrade.

I see a few different grenade jobs (neutron-grenade,
neutron-grenade-multinode,
legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
Which ones are "current" and would make a good candidate as a base for a
new job?


Grenade just runs devstack on the old side (e.g. stable/rocky) using the 
devstack stackrc file (which could have USE_PYTHON3 in it), runs tempest 
'smoke' tests to create some resources, saves off some information about 
those resources in a "database" (just an ini file), then runs devstack 
on the new side (e.g. master) using the new side stackrc file and 
verifies those saved off resources made it through the upgrade. It's all 
bash so there isn't anything python-specific about grenade.


I saw, but didn't comment on, the other thread about if it would be 
possible to create a grenade-2to3 job. I'd think that is pretty doable 
based on the USE_PYTHON3 variable. We'd just have that False on the old 
side, and True on the new side, and devstack will do it's thing. Right 
now the USE_PYTHON3 variable is global in devstack-gate [1] (which is 
the thing that orchestrates the grenade run for the legacy jobs), but 
I'm sure we could hack that to be specific to the base (old) and target 
(new) release for the grenade run.


[1] 
https://github.com/openstack-infra/devstack-gate/blob/95fa4343104eafa655375cce3546d27139211d13/devstack-vm-gate-wrap.sh#L434 





To answer Doug's original question, neutron-grenade-multinode is 
probably best to model for a new job if you want to test rolling 
upgrades, because that job has two compute nodes and leaves one on the 
'old' side so it would upgrade the controller services and one compute 
to Stein and leave the other compute at Rocky. So if you start with 
python2 on the old side and upgrade to python3 for everything except one 
compute, you'll have a pretty good idea of whether or not that rolling 
upgrade works through our various services and libraries, like the 
oslo.messaging stuff noted in the other thread.


--

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] [python3] tempest and grenade conversion to python 3.6

[Matt Riedemann]

On 9/18/2018 12:28 PM, Doug Hellmann wrote:

What's probably missing is a version of the grenade job that allows us
to control that USE_PYTHON3 variable before and after the upgrade.

I see a few different grenade jobs (neutron-grenade,
neutron-grenade-multinode,
legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
Which ones are "current" and would make a good candidate as a base for a
new job?


Grenade just runs devstack on the old side (e.g. stable/rocky) using the 
devstack stackrc file (which could have USE_PYTHON3 in it), runs tempest 
'smoke' tests to create some resources, saves off some information about 
those resources in a "database" (just an ini file), then runs devstack 
on the new side (e.g. master) using the new side stackrc file and 
verifies those saved off resources made it through the upgrade. It's all 
bash so there isn't anything python-specific about grenade.


I saw, but didn't comment on, the other thread about if it would be 
possible to create a grenade-2to3 job. I'd think that is pretty doable 
based on the USE_PYTHON3 variable. We'd just have that False on the old 
side, and True on the new side, and devstack will do it's thing. Right 
now the USE_PYTHON3 variable is global in devstack-gate [1] (which is 
the thing that orchestrates the grenade run for the legacy jobs), but 
I'm sure we could hack that to be specific to the base (old) and target 
(new) release for the grenade run.


[1] 
https://github.com/openstack-infra/devstack-gate/blob/95fa4343104eafa655375cce3546d27139211d13/devstack-vm-gate-wrap.sh#L434


--

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] [octavia] Optimize the query of the octavia database

[Michael Johnson]

Hi All,

I have created a patch that resolves this regression:
https://review.openstack.org/#/c/603242/

Please take a look. Locally it showed dramatic improvements. List load
balancers went from two and half minutes down to seconds when I had a
thousand Act/Stdby LBs.

The patch may need some touch ups around testing, but the
functionality should be good.

We also have some team members working on Rally support for Octavia,
so hopefully we will be able to catch a regression like this
immediately in the future. Please support those efforts if you can
contribute some time.

Michael
On Fri, Sep 14, 2018 at 6:01 PM Jeff Yang  wrote:
>
> Ok, Thank you very much for your work.
>
> Adam Harwell  于2018年9月15日周六 上午8:26写道：
>>
>> It's high priority for me as well, so we should be able to get something 
>> done very soon, I think. Look for something early next week maybe?
>>
>> Thanks,
>> --Adam
>>
>> On Thu, Sep 13, 2018, 21:18 Jeff Yang  wrote:
>>>
>>> Thanks:
>>> I found the correlative patch in neutron-lbaas: 
>>> https://review.openstack.org/#/c/568361/
>>>
>>> The bug was marked high level by our QA team. I need to fix it as soon 
>>> as possible.
>>>  Does Michael Johnson have any good suggestion? I am willing to 
>>> complete the
>>>  repair work of this bug. If your patch still takes a while to prepare.
>>>
>>> Michael Johnson  于2018年9月14日周五 上午7:56写道：

 This is a known regression in the Octavia API performance. It has an
 existing story[0] that is under development. You are correct, that
 star join is the root of the problem.
 Look for a patch soon.

 [0] https://storyboard.openstack.org/#!/story/2002933

 Michael
 On Thu, Sep 13, 2018 at 10:32 AM Erik Olof Gunnar Andersson
  wrote:
 >
 > This was solved in neutron-lbaas recently, maybe we could adopt the same 
 > method for Octavia?
 >
 > Sent from my iPhone
 >
 > On Sep 13, 2018, at 4:54 AM, Jeff Yang  wrote:
 >
 > Hi, All
 >
 > As octavia resources increase, I found that running the "openstack 
 > loadbalancer list" command takes longer and longer. Sometimes a 504 
 > error is reported.
 >
 > By reading the code, I found that octavia will performs complex left 
 > outer join queries when acquiring resources such as loadbalancer, 
 > listener, pool, etc. in order to only make one trip to the database.
 > Reference code: http://paste.openstack.org/show/730022 Line 133
 > Generated SQL statements: http://paste.openstack.org/show/730021
 >
 > So, I suggest that adjust the query strategy to provide different join 
 > queries for different resources.
 >
 > https://storyboard.openstack.org/#!/story/2003751
 >
 > __
 > 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 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 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] Ops Forum Session Brainstorming

[Erik McCormick]

This is a friendly reminder for anyone wishing to see Ops-focused sessions
in Berlin to get your submissions in soon. We have a couple things there
that came out of the PTG, but that's it so far. See below for details.

Cheers,
Erik



On Wed, Sep 12, 2018, 5:07 PM Erik McCormick 
wrote:

> Hello everyone,
>
> I have set up an etherpad to collect Ops related session ideas for the
> Forum at the Berlin Summit. Please suggest any topics that you would
> like to see covered, and +1 existing topics you like.
>
> https://etherpad.openstack.org/p/ops-forum-stein
>
> Cheers,
> Erik
>
__
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] Stein TC Polling is open!

[Kendall Nelson]

Hello!

The poll for the TC Election is now open and will remain open until Sep 27,
2018 23:45 UTC.

We are selecting 6 TC members, please rank all candidates in your order of
preference. For more information on condorcet voting and how it works, you
can read more here[0].

You are eligible to vote if you are a Foundation individual member[1] that
also has committed to one of the official programs projects[2] over the Aug
11, 2017 00:00 UTC - Aug 30, 2018 00:00 UTC timeframe (Queens to Rocky) or
if you are one of the extra-atcs.[3]

What to do if you don't see the email and have a commit in at least one of
the official programs projects[2] and are a Foundation individual member:
* check the trash or spam folder of your gerrit Preferred Email address[4],
in case it went into trash or spam
* wait a bit and check again, in case your email server (or CIVS) is a bit
slow
* find the sha of at least one commit from the program project repos[2] and
the link to your foundation member profile and email them to the election
officials[1]. If we can confirm that you are entitled to vote, we will add
you to the voters list and you will be emailed a ballot.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote!

Candidate statements/platforms can be found linked to candidate names[6].

Happy voting!

Thank you,
-The Election Officials

[0] https://en.wikipedia.org/wiki/Condorcet_method
[1] http://www.openstack.org/community/members/
[2]
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2018-elections

[3] Look for the extra-atcs element in [2]
[4] Sign into review.openstack.org: Go to Settings > Contact Information.
Look at the email listed as your preferred email. That is where the ballot
has been sent.
[5] http://governance.openstack.org/election/#election-officials
[6] http://governance.openstack.org/election/#stein-tc-candidates
__
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] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Duc Truong]

Thanks for creating the etherpad.

I have added a question on the common library in the etherpad.
I think we can iterate on the basic proposal before the forum in
Berlin so that we can get input from developers who won't be
able to attend in person.

On Tue, Sep 18, 2018 at 11:46 AM Rico Lin  wrote:

> cool Duc, and it's nicely started:
> https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
> I also submit the etherpad, will add you as moderator once it's selected
> (don't know why, but can't add any more now from the web).
>
> Please add whatever you like to that etherpad, I will try to input more
> information ASAP.
> all information will continue to be used with or without that forum.
>
> On Wed, Sep 19, 2018 at 12:51 AM Duc Truong 
> wrote:
>
>> Hi Rico,
>>
>> I'm the Senlin PTL and would be happy to have a forum discussion in
>> Berlin about the future of autoscaling.
>>
>> Can you go ahead and start an etherpad to capture the proposed agenda
>> and discussion items?  Also, feel free to submit the forum submission
>> so that we can get it on the schedule.
>>
>> Thanks,
>>
>> Duc (dtruong)
>>
>> On Mon, Sep 17, 2018 at 8:28 PM Rico Lin 
>> wrote:
>>
>>> *TL;DR*
>>> *How about a forum in Berlin for discussing autoscaling integration (as
>>> a long-term goal) in OpenStack?*
>>>
>>>
>>> Hi all, as we start to discuss how can we join develop from Heat and
>>> Senlin as we originally planned when we decided to fork Senlin from Heat
>>> long time ago.
>>>
>>> IMO the biggest issues we got now are we got users using autoscaling in
>>> both services, appears there is a lot of duplicated effort, and some great
>>> enhancement didn't exist in another service.
>>> As a long-term goal (from the beginning), we should try to join
>>> development to sync functionality, and move users to use Senlin for
>>> autoscaling. So we should start to review this goal, or at least we should
>>> try to discuss how can we help users without break or enforce anything.
>>>
>>> What will be great if we can build common library cross projects, and
>>> use that common library in both projects, make sure we have all improvement
>>> implemented in that library, finally to use Senlin from that from that
>>> library call in Heat autoscaling group. And in long-term, we gonna let all
>>> user use more general way instead of multiple ways but generate huge
>>> confusing for users.
>>>
>>> *As an action, I propose we have a forum in Berlin and sync up all
>>> effort from both teams to plan for idea scenario design. The forum
>>> submission [1] ended at 9/26.*
>>> Also would benefit from both teams to start to think about how they can
>>> modulize those functionalities for easier integration in the future.
>>>
>>> From some Heat PTG sessions, we keep bring out ideas on how can we
>>> improve current solutions for Autoscaling. We should start to talk about
>>> will it make sense if we combine all group resources into one, and inherit
>>> from it for other resources (ideally gonna deprecate rest resource types).
>>> Like we can do Batch create/delete in Resource Group, but not in ASG. We
>>> definitely got some unsynchronized works inner Heat, and cross Heat and
>>> Senlin.
>>>
>>> Please let me know who is interesting in this idea, so we can work
>>> together and reach our goal step by step.
>>> Also please provide though if you got any concerns about this proposal.
>>>
>>> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
>>> --
>>> May The Force of OpenStack Be With You,
>>>
>>> *Rico Lin*irc: ricolin
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [User-committee][tc] Joint UC/TC Meeting

[Doug Hellmann]

[Redirecting this from the openstack-tc list to the -dev list.]

Excerpts from Melvin Hillsman's message of 2018-09-18 17:43:57 -0500:
> Hey everyone,
> 
> UC is proposing a joint UC/TC meeting at the end of the month say starting
> after Berlin to work more closely together. The last Monday of the month at
> 1pm US Central time is current proposal, throwing it out here now for
> feedback/discussion, so that would make the first one Monday, November
> 26th, 2018.
> 

__
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] Forum Topic Submission Period

[Jimmy McArthur]

Hey Matt,


Matt Riedemann wrote:


Just a process question.


Good question.
I submitted a presentation for the normal marketing blitz part of the 
summit which wasn't accepted (I'm still dealing with this emotionally, 
btw...) 

If there's anything I can do...
but when I look at the CFP link for Forum topics, my thing shows up 
there as "Received" so does that mean my non-Forum-at-all submission 
is now automatically a candidate for the Forum because that would not 
be my intended audience (only suits and big wigs please).
Forum Submissions would be considered separate and non-Forum submissions 
will not be considered for the Forum. The submission process is based on 
the track you submit to and, in the case of the Forum, we separate this 
track out from the rest of the submission process.


If you think there is still something funky, send me a note via 
speakersupp...@openstack.org or ji...@openstack.org and I'll work 
through it with you.


Cheers,
Jimmy




__
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] Berlin Forum Proposals

[Jay S Bryant]

Team,

I have created an etherpad for our Forum Topic Planning: 
https://etherpad.openstack.org/p/cinder-berlin-forum-proposals


Please add your ideas to the etherpad.  Thank you!

Jay


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

Re: [openstack-dev] Forum Topic Submission Period

[Matt Riedemann]

On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th.  Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum topics 
through. Don't rely only on a PTL to make the agenda... step on up and 
place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, but 
if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy


Just a process question. I submitted a presentation for the normal 
marketing blitz part of the summit which wasn't accepted (I'm still 
dealing with this emotionally, btw...) but when I look at the CFP link 
for Forum topics, my thing shows up there as "Received" so does that 
mean my non-Forum-at-all submission is now automatically a candidate for 
the Forum because that would not be my intended audience (only suits and 
big wigs please).


--

Thanks,

Matt

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

[openstack-dev] [ptg][cinder] Stein PTG Summary Page Ready ...

[Jay S Bryant]

Team,

I have put together the following page with a summary of all our 
discussions at the PTG: 
https://wiki.openstack.org/wiki/CinderSteinPTGSummary


Please review the contents and let me know if anything needs to be changed.

Jay


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

[openstack-dev] Fwd: Denver Ops Meetup post-mortem

[Chris Morgan]

-- Forwarded message -
From: Chris Morgan 
Date: Tue, Sep 18, 2018 at 2:13 PM
Subject: Denver Ops Meetup post-mortem
To: OpenStack Operators 


 Hello All,
  Last week we had a successful Ops Meetup embedded in the OpenStack
Project Team Gathering in Denver.

Despite generally being a useful gathering, there were definitely lessons
learned and things to work on, so I thought it would be useful to share a
post-mortem. I encourage everyone to share their thoughts on this as well.

What went well:

- some of the sessions were great and a lot of progress was made
- overall attendance in the ops room was good
- more developers were able to join the discussions
- facilities were generally fine
- some operators leveraged being at PTG to have useful involvement in other
sessions/discussions such as Keystone, User Committee, Self-Healing SIG,
not to mention the usual "hallway conversations", and similarly some
project devs were able to bring pressing questions directly to operators.

What didn't go so well:

- Merging into upgrade SIG didn't go particularly well
- fewer ops attended (in particular there were fewer from outside the US)
- Some of the proposed sessions were not well vetted
- some ops who did attend stated the event identity was diluted, it was
less attractive
- we tried to adjust the day 2 schedule to include late submissions,
however it was probably too late in some cases

I don't think it's so important to drill down into all the whys and
wherefores of how we fell down here except to say that the ops meetups team
is a small bunch of volunteers all with day jobs (presumably just like
everyone else on this mailing list). The usual, basically.

Much more important : what will be done to improve things going forward:

- The User Committee has offered to get involved with the technical
content. In particular to bring forward topics from other relevant events
into the ops meetup planning process, and then take output from ops meetups
forward to subsequent events. We (ops meetup team) have welcomed this.

- The Ops Meetups Team will endeavor to start topic selection earlier and
have a more critical approach. Having a longer list of possible sessions
(when starting with material from earlier events) should make it at least
possible to devise a better agenda. Agenda quality drives attendance to
some extent and so can ensure a virtuous circle.

- We need to work out whether we're doing fixed schedule events (similar to
previous mid-cycle Ops Meetups) or fully flexible PTG-style events, but
grafting one onto the other ad-hoc clearly is a terrible idea. This needs
more discussion.

- The Ops Meetups Team continues to explore strange new worlds, or at least
get in touch with more and more OpenStack operators to find out what the
meetups team and these events could do for them and hence drive the process
better. One specific work item here is to help the (widely disparate)
operator community with technical issues such as getting setup with the
openstack git/gerrit and IRC. The latter is the preferred way for the
community to meet, but is particularly difficult now with the registered
nickname requirement. We will add help documentation on how to get over
this hurdle.

- YOUR SUGGESTION HERE

Chris

-- 
Chris Morgan 


-- 
Chris Morgan 
__
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] Are we ready to put stable/ocata into extended maintenance mode?

[Alex Schultz]

On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann  wrote:
> The release page says Ocata is planned to go into extended maintenance mode
> on Aug 27 [1]. There really isn't much to this except it means we don't do
> releases for Ocata anymore [2]. There is a caveat that project teams that do
> not wish to maintain stable/ocata after this point can immediately end of
> life the branch for their project [3]. We can still run CI using tags, e.g.
> if keystone goes ocata-eol, devstack on stable/ocata can still continue to
> install from stable/ocata for nova and the ocata-eol tag for keystone.
> Having said that, if there is no undue burden on the project team keeping
> the lights on for stable/ocata, I would recommend not tagging the
> stable/ocata branch end of life at this point.
>
> So, questions that need answering are:
>
> 1. Should we cut a final release for projects with stable/ocata branches
> before going into extended maintenance mode? I tend to think "yes" to flush
> the queue of backports. In fact, [3] doesn't mention it, but the resolution
> said we'd tag the branch [4] to indicate it has entered the EM phase.
>
> 2. Are there any projects that would want to skip EM and go directly to EOL
> (yes this feels like a Monopoly question)?
>

I believe TripleO would like to EOL instead of EM for Ocata as
indicated by the thead
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.html

Thanks,
-Alex

> [1] https://releases.openstack.org/
> [2]
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
> [3]
> https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
> [4]
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Openstack-sigs] Are we ready to put stable/ocata into extended maintenance mode?

[Sean McGinnis]

On Tue, Sep 18, 2018 at 02:27:03PM -0500, Matt Riedemann wrote:
> The release page says Ocata is planned to go into extended maintenance mode
> on Aug 27 [1]. There really isn't much to this except it means we don't do
> releases for Ocata anymore [2]. There is a caveat that project teams that do
> not wish to maintain stable/ocata after this point can immediately end of
> life the branch for their project [3]. We can still run CI using tags, e.g.
> if keystone goes ocata-eol, devstack on stable/ocata can still continue to
> install from stable/ocata for nova and the ocata-eol tag for keystone.
> Having said that, if there is no undue burden on the project team keeping
> the lights on for stable/ocata, I would recommend not tagging the
> stable/ocata branch end of life at this point.
> 
> So, questions that need answering are:
> 
> 1. Should we cut a final release for projects with stable/ocata branches
> before going into extended maintenance mode? I tend to think "yes" to flush
> the queue of backports. In fact, [3] doesn't mention it, but the resolution
> said we'd tag the branch [4] to indicate it has entered the EM phase.
> 
> 2. Are there any projects that would want to skip EM and go directly to EOL
> (yes this feels like a Monopoly question)?
> 
> [1] https://releases.openstack.org/
> [2] 
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
> [3] 
> https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
> [4] 
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
> 
> -- 
> 
> Thanks,
> 
> Matt

I have a patch that's been pending for marking it as extended maintenance:

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

That's just the state for Ocata. You raise some other good points here that I
am curious to see input on.

Sean


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

[openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

[Matt Riedemann]

The release page says Ocata is planned to go into extended maintenance 
mode on Aug 27 [1]. There really isn't much to this except it means we 
don't do releases for Ocata anymore [2]. There is a caveat that project 
teams that do not wish to maintain stable/ocata after this point can 
immediately end of life the branch for their project [3]. We can still 
run CI using tags, e.g. if keystone goes ocata-eol, devstack on 
stable/ocata can still continue to install from stable/ocata for nova 
and the ocata-eol tag for keystone. Having said that, if there is no 
undue burden on the project team keeping the lights on for stable/ocata, 
I would recommend not tagging the stable/ocata branch end of life at 
this point.


So, questions that need answering are:

1. Should we cut a final release for projects with stable/ocata branches 
before going into extended maintenance mode? I tend to think "yes" to 
flush the queue of backports. In fact, [3] doesn't mention it, but the 
resolution said we'd tag the branch [4] to indicate it has entered the 
EM phase.


2. Are there any projects that would want to skip EM and go directly to 
EOL (yes this feels like a Monopoly question)?


[1] https://releases.openstack.org/
[2] 
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3] 
https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[4] 
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life


--

Thanks,

Matt

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

[openstack-dev] [TripleO] Edge Squad meeting

[James Slagle]

Hi,

Thanks to those who responded on the etherpad poll for a meeting time
for the TripleO Edge squad:
http://lists.openstack.org/pipermail/openstack-dev/2018-August/134069.html

We've selected 1400UTC on Thursdays in #tripleo. I've started a rough
agenda in the etherpad:
https://etherpad.openstack.org/p/tripleo-edge-squad-status
Feel free to add other items, and bring them up in the meeting on Thursday.

One of the goals of the meeting should be to capture action items we
can complete before we meet again the following week. If you have any
ideas or would like to collaborate on something, please bring them up.

See everyone for the meeting. Thanks!

-- 
-- James Slagle
--

__
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] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Rico Lin]

cool Duc, and it's nicely started:
https://etherpad.openstack.org/p/autoscaling-integration-and-feedback
I also submit the etherpad, will add you as moderator once it's selected
(don't know why, but can't add any more now from the web).

Please add whatever you like to that etherpad, I will try to input more
information ASAP.
all information will continue to be used with or without that forum.

On Wed, Sep 19, 2018 at 12:51 AM Duc Truong  wrote:

> Hi Rico,
>
> I'm the Senlin PTL and would be happy to have a forum discussion in
> Berlin about the future of autoscaling.
>
> Can you go ahead and start an etherpad to capture the proposed agenda
> and discussion items?  Also, feel free to submit the forum submission
> so that we can get it on the schedule.
>
> Thanks,
>
> Duc (dtruong)
>
> On Mon, Sep 17, 2018 at 8:28 PM Rico Lin 
> wrote:
>
>> *TL;DR*
>> *How about a forum in Berlin for discussing autoscaling integration (as a
>> long-term goal) in OpenStack?*
>>
>>
>> Hi all, as we start to discuss how can we join develop from Heat and
>> Senlin as we originally planned when we decided to fork Senlin from Heat
>> long time ago.
>>
>> IMO the biggest issues we got now are we got users using autoscaling in
>> both services, appears there is a lot of duplicated effort, and some great
>> enhancement didn't exist in another service.
>> As a long-term goal (from the beginning), we should try to join
>> development to sync functionality, and move users to use Senlin for
>> autoscaling. So we should start to review this goal, or at least we should
>> try to discuss how can we help users without break or enforce anything.
>>
>> What will be great if we can build common library cross projects, and use
>> that common library in both projects, make sure we have all improvement
>> implemented in that library, finally to use Senlin from that from that
>> library call in Heat autoscaling group. And in long-term, we gonna let all
>> user use more general way instead of multiple ways but generate huge
>> confusing for users.
>>
>> *As an action, I propose we have a forum in Berlin and sync up all effort
>> from both teams to plan for idea scenario design. The forum submission [1]
>> ended at 9/26.*
>> Also would benefit from both teams to start to think about how they can
>> modulize those functionalities for easier integration in the future.
>>
>> From some Heat PTG sessions, we keep bring out ideas on how can we
>> improve current solutions for Autoscaling. We should start to talk about
>> will it make sense if we combine all group resources into one, and inherit
>> from it for other resources (ideally gonna deprecate rest resource types).
>> Like we can do Batch create/delete in Resource Group, but not in ASG. We
>> definitely got some unsynchronized works inner Heat, and cross Heat and
>> Senlin.
>>
>> Please let me know who is interesting in this idea, so we can work
>> together and reach our goal step by step.
>> Also please provide though if you got any concerns about this proposal.
>>
>> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
May The Force of OpenStack Be With You,

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

Re: [openstack-dev] [Openstack-sigs] [tc][uc]Community Wide Long Term Goals

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-09-18 12:27:06 -0500:
> On Tue, Sep 18, 2018 at 12:17 PM Doug Hellmann 
> wrote:
> 
> > Excerpts from Lance Bragstad's message of 2018-09-18 11:56:22 -0500:
> > > On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann 
> > > wrote:
> > >
> > > > Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> > > > > Hi,
> > > > >
> > > > > Based upon the discussion we had at the TC session in the afternoon,
> > I'm
> > > > > starting to draft a patch to add long term goal mechanism into
> > > > governance.
> > > > > It is by no means a complete solution at the moment (still have not
> > > > thought
> > > > > through the execution method yet to make sure the outcome), but feel
> > free
> > > > > to provide your feedback at https://review.openstack.org/#/c/602799/
> > .
> > > > >
> > > > > --
> > > > > Zhipeng (Howard) Huang
> > > >
> > > > [I commented on the patch, but I'll also reply here for anyone not
> > > > following the review.]
> > > >
> > > > I'm glad to see the increased interest in goals. Before we change
> > > > the existing process, though, I would prefer to see engagement with
> > > > the current process. We can start by having SIGs and WGs update the
> > > > etherpad where we track goal proposals
> > > > (https://etherpad.openstack.org/p/community-goals) and then we can
> > > > see if we actually need to manage goals across multiple release
> > > > cycles as a single unit.
> > > >
> > >
> > > Depending on the official outcome of this resolution, I was going to try
> > > and use the granular RBAC work to test out this process.
> > >
> > > I can still do that, or I can hold off if appropriate.
> >
> > The Python 3 transition has been going on for 5-6 years now, and
> > started before we had even the current goals process in place. I
> > think it's completely possible for us to do work that takes a long
> > time without making the goals process more complex.  Let's try to
> > keep the process lightweight, and make incremental changes to it
> > based on real shortcomings (adding champions is one example of a
> > tweak that made a significant improvement).
> >
> > It may be easy to continue to prioritize a follow-up part of a
> > multi-part goal we have already started, but I would rather we don't
> > *require* that in case we have some other significant work that we
> > have to rally folks to complete (I'm thinking of things like
> > addressing security issues, some new technical challenge that comes
> > up, or other community needs that we don't foresee at the start of
> > a multi-part goal). We designed the current process to encourage
> > those sorts of conversations to happen on a regular basis, after
> > all, so I'm very happy to see interest in using it. But let's try
> > to use what we have before we assume it's broken.
> >
> 
> That's fair.
> 
> >
> > I think you could (and should) start by describing the stages you
> > anticipate for the RBAC stuff, and then we can see which parts need
> > to be done before we adopt a goal, which part are goals, and whether
> > enough momentum picks up that we don't need to make later parts
> > formal goals.
> >
> 
> Do you have a particular medium in mind?

Not really. As we discussed in IRC, you'll want to balance the need to
have something that's easy to edit with the need to have our usual peer
review. So some things like tracking the phases or work may be done
better with storyboard or an etherpad, and other things like working out
significant technical details may work better as documentation or spec
reviews.

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] [puppet] [placement]

[Lee Yarwood]

On 17-09-18 08:48:01, Emilien Macchi wrote:
> On Mon, Sep 17, 2018 at 5:29 AM Lee Yarwood  wrote:
> 
> > FWIW I've also started work on the RDO packaging front [1] and would be
> > happy to help with this puppet extraction.
> >
> 
> Good to know, thanks.
> Once we have the repo in place, here is a plan proposal:
> 
> * Populate the repo with cookiecutter & adjust to Placement service
> * cp code from nova::placement (and nova::wsgi::apache_placement)
> * package placement and puppet-placement in RDO
> * start testing puppet-placement in puppet-openstack-integration
> * switch tripleo-common / THT to deploy placement in nova_placement
> container
> * switch tripleo to use puppet-placement (in THT)
> * probably rename nova_placement container/service into placement or
> something generic
> 
> Feedback is welcome,

Thanks Emilien,

The only thing I'd add would be TripleO/THT powered upgrades, after
switching to puppet-placement.

We discussed this in both the Nova and Upgrades SIG rooms and the end
goal was to have TripleO able to extract placement during an upgrade to
S by M2. I appreciate this is an optimistic goal for upgrades but I
think it's just about possible given the extended cycle.
 
Cheers,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] [python3] tempest and grenade conversion to python 3.6

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2018-09-18 09:53:45 -0700:
> On Tue, Sep 18, 2018, at 9:46 AM, Nate Johnston wrote:
> > Hello python 3.6 champions,
> > 
> > I have looked around a little, and I don't see a method for me to
> > specifically select the version of python that the tempest and grenade
> > jobs for my project (neutron) are using.  I assume one of four things
> > is at play here:
> > 
> > A. These projects already shifted to python 3 and I don't have to worry
> > about it
> > 
> > B. There is a toggle for the python version I just have not seen yet
> > 
> > C. These projects are still on python 2 and need help to do a conversion
> > to python 3, which would affect all customers
> > 
> > D. Something else that I have failed to imagine
> > 
> > Could you elaborate which of these options properly reflects the state
> > of affairs?  If the answer is "C" then perhaps we can start a discussion
> > on that migration.
> 
> For our devstack and grenade jobs tempest is installed using tox [0]. And 
> since the full testenv in tempest's tox.ini doesn't specify a python version 
> [1] I expect that it will attempt a python2 virtualenv on every platform 
> (Arch linux may be an exception but we don't test that).
> 
> I think that means C is the situation here. To change that you can set 
> basepython to python3 (see [2] for an example) which will run tempest under 
> whichever python3 is present on the system. The one gotcha for this is that 
> it will break tempest on centos which does not have python3. Maybe the thing 
> to do there is add a full-python2 testenv that centos can run?
> 
> [0] 
> https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest#n653
> [1] https://git.openstack.org/cgit/openstack/tempest/tree/tox.ini#n74
> [2] https://git.openstack.org/cgit/openstack-infra/zuul/tree/tox.ini#n7
> 
> Hope this helps,
> Clark
> 

While having tempest run under python 3 would be great, I'm not sure
that's necessary in order to test a service.

Don't those jobs use devstack to install the system being tested? And
devstack uses some environment variables to control the version of
python. For example the tempest-full-py3 job [1] defines USE_PYTHON3 as
'true'.

What's probably missing is a version of the grenade job that allows us
to control that USE_PYTHON3 variable before and after the upgrade.

I see a few different grenade jobs (neutron-grenade,
neutron-grenade-multinode,
legacy-grenade-dsvm-neutron-multinode-live-migration, possibly others).
Which ones are "current" and would make a good candidate as a base for a
new job?

Doug

[1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n70

__
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-sigs] [tc][uc]Community Wide Long Term Goals

[Lance Bragstad]

On Tue, Sep 18, 2018 at 12:17 PM Doug Hellmann 
wrote:

> Excerpts from Lance Bragstad's message of 2018-09-18 11:56:22 -0500:
> > On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann 
> > wrote:
> >
> > > Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> > > > Hi,
> > > >
> > > > Based upon the discussion we had at the TC session in the afternoon,
> I'm
> > > > starting to draft a patch to add long term goal mechanism into
> > > governance.
> > > > It is by no means a complete solution at the moment (still have not
> > > thought
> > > > through the execution method yet to make sure the outcome), but feel
> free
> > > > to provide your feedback at https://review.openstack.org/#/c/602799/
> .
> > > >
> > > > --
> > > > Zhipeng (Howard) Huang
> > >
> > > [I commented on the patch, but I'll also reply here for anyone not
> > > following the review.]
> > >
> > > I'm glad to see the increased interest in goals. Before we change
> > > the existing process, though, I would prefer to see engagement with
> > > the current process. We can start by having SIGs and WGs update the
> > > etherpad where we track goal proposals
> > > (https://etherpad.openstack.org/p/community-goals) and then we can
> > > see if we actually need to manage goals across multiple release
> > > cycles as a single unit.
> > >
> >
> > Depending on the official outcome of this resolution, I was going to try
> > and use the granular RBAC work to test out this process.
> >
> > I can still do that, or I can hold off if appropriate.
>
> The Python 3 transition has been going on for 5-6 years now, and
> started before we had even the current goals process in place. I
> think it's completely possible for us to do work that takes a long
> time without making the goals process more complex.  Let's try to
> keep the process lightweight, and make incremental changes to it
> based on real shortcomings (adding champions is one example of a
> tweak that made a significant improvement).
>
> It may be easy to continue to prioritize a follow-up part of a
> multi-part goal we have already started, but I would rather we don't
> *require* that in case we have some other significant work that we
> have to rally folks to complete (I'm thinking of things like
> addressing security issues, some new technical challenge that comes
> up, or other community needs that we don't foresee at the start of
> a multi-part goal). We designed the current process to encourage
> those sorts of conversations to happen on a regular basis, after
> all, so I'm very happy to see interest in using it. But let's try
> to use what we have before we assume it's broken.
>

That's fair.


>
> I think you could (and should) start by describing the stages you
> anticipate for the RBAC stuff, and then we can see which parts need
> to be done before we adopt a goal, which part are goals, and whether
> enough momentum picks up that we don't need to make later parts
> formal goals.
>

Do you have a particular medium in mind?


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

Re: [openstack-dev] [nova] When can/should we change additionalProperties=False in GET /servers(/detail)?

[Matt Riedemann]

On 9/17/2018 9:41 PM, Ghanshyam Mann wrote:

   On Tue, 18 Sep 2018 09:33:30 +0900 Alex Xu  wrote 
  > That only means after 599276 we only have servers API and 
os-instance-action API stopped accepting the undefined query parameter.
  > What I'm thinking about is checking all the APIs, add json-query-param 
checking with additionalProperties=True if the API don't have yet. And using 
another microversion set additionalProperties to False, then the whole Nova API 
become consistent.

I too vote for doing it for all other API together. Restricting the unknown 
query or request param are very useful for API consistency. Item#1 in this 
etherpadhttps://etherpad.openstack.org/p/nova-api-cleanup

If you would like, i can propose a quick spec for that and positive response to 
do all together then we skip to do that in 599276 otherwise do it for GET 
servers in 599276.

-gmann


I don't care too much about changing all of the other 
additionalProperties=False in a single microversion given we're already 
kind of inconsistent with this in a few APIs. Consistency is ideal, but 
I thought we'd be lumping in other cleanups from the etherpad into the 
same microversion/spec which will likely slow it down during spec 
review. For example, I'd really like to get rid of the weird server 
response field prefixes like "OS-EXT-SRV-ATTR:". Would we put those into 
the same mass cleanup microversion / spec or split them into individual 
microversions? I'd prefer not to see an explosion of microversions for 
cleaning up oddities in the API, but I could see how doing them all in a 
single microversion could be complicated.


--

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-sigs] [tc][uc]Community Wide Long Term Goals

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-09-18 11:56:22 -0500:
> On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann 
> wrote:
> 
> > Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> > > Hi,
> > >
> > > Based upon the discussion we had at the TC session in the afternoon, I'm
> > > starting to draft a patch to add long term goal mechanism into
> > governance.
> > > It is by no means a complete solution at the moment (still have not
> > thought
> > > through the execution method yet to make sure the outcome), but feel free
> > > to provide your feedback at https://review.openstack.org/#/c/602799/ .
> > >
> > > --
> > > Zhipeng (Howard) Huang
> >
> > [I commented on the patch, but I'll also reply here for anyone not
> > following the review.]
> >
> > I'm glad to see the increased interest in goals. Before we change
> > the existing process, though, I would prefer to see engagement with
> > the current process. We can start by having SIGs and WGs update the
> > etherpad where we track goal proposals
> > (https://etherpad.openstack.org/p/community-goals) and then we can
> > see if we actually need to manage goals across multiple release
> > cycles as a single unit.
> >
> 
> Depending on the official outcome of this resolution, I was going to try
> and use the granular RBAC work to test out this process.
> 
> I can still do that, or I can hold off if appropriate.

The Python 3 transition has been going on for 5-6 years now, and
started before we had even the current goals process in place. I
think it's completely possible for us to do work that takes a long
time without making the goals process more complex.  Let's try to
keep the process lightweight, and make incremental changes to it
based on real shortcomings (adding champions is one example of a
tweak that made a significant improvement).

It may be easy to continue to prioritize a follow-up part of a
multi-part goal we have already started, but I would rather we don't
*require* that in case we have some other significant work that we
have to rally folks to complete (I'm thinking of things like
addressing security issues, some new technical challenge that comes
up, or other community needs that we don't foresee at the start of
a multi-part goal). We designed the current process to encourage
those sorts of conversations to happen on a regular basis, after
all, so I'm very happy to see interest in using it. But let's try
to use what we have before we assume it's broken.

I think you could (and should) start by describing the stages you
anticipate for the RBAC stuff, and then we can see which parts need
to be done before we adopt a goal, which part are goals, and whether
enough momentum picks up that we don't need to make later parts
formal goals.

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-sigs] [tc][uc]Community Wide Long Term Goals

[Harry Rybacki]

On Tue, Sep 18, 2018 at 12:57 PM Lance Bragstad  wrote:
>
>
>
> On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann  wrote:
>>
>> Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
>> > Hi,
>> >
>> > Based upon the discussion we had at the TC session in the afternoon, I'm
>> > starting to draft a patch to add long term goal mechanism into governance.
>> > It is by no means a complete solution at the moment (still have not thought
>> > through the execution method yet to make sure the outcome), but feel free
>> > to provide your feedback at https://review.openstack.org/#/c/602799/ .
>> >
>> > --
>> > Zhipeng (Howard) Huang
>>
>> [I commented on the patch, but I'll also reply here for anyone not
>> following the review.]
>>
>> I'm glad to see the increased interest in goals. Before we change
>> the existing process, though, I would prefer to see engagement with
>> the current process. We can start by having SIGs and WGs update the
>> etherpad where we track goal proposals
>> (https://etherpad.openstack.org/p/community-goals) and then we can
>> see if we actually need to manage goals across multiple release
>> cycles as a single unit.
>
>
> Depending on the official outcome of this resolution, I was going to try and 
> use the granular RBAC work to test out this process.
>
My thoughts exactly.

> I can still do that, or I can hold off if appropriate.

Breaking down the remaining work per Doug's suggestion would be good.
We've done this a time-or-three before as the target
has moved around. It's probably do for another one.

/R
>
>>
>>
>> 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 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-sigs] [tc][uc]Community Wide Long Term Goals

[Lance Bragstad]

On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann 
wrote:

> Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> > Hi,
> >
> > Based upon the discussion we had at the TC session in the afternoon, I'm
> > starting to draft a patch to add long term goal mechanism into
> governance.
> > It is by no means a complete solution at the moment (still have not
> thought
> > through the execution method yet to make sure the outcome), but feel free
> > to provide your feedback at https://review.openstack.org/#/c/602799/ .
> >
> > --
> > Zhipeng (Howard) Huang
>
> [I commented on the patch, but I'll also reply here for anyone not
> following the review.]
>
> I'm glad to see the increased interest in goals. Before we change
> the existing process, though, I would prefer to see engagement with
> the current process. We can start by having SIGs and WGs update the
> etherpad where we track goal proposals
> (https://etherpad.openstack.org/p/community-goals) and then we can
> see if we actually need to manage goals across multiple release
> cycles as a single unit.
>

Depending on the official outcome of this resolution, I was going to try
and use the granular RBAC work to test out this process.

I can still do that, or I can hold off if appropriate.


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

Re: [openstack-dev] [python3] tempest and grenade conversion to python 3.6

[Clark Boylan]

On Tue, Sep 18, 2018, at 9:46 AM, Nate Johnston wrote:
> Hello python 3.6 champions,
> 
> I have looked around a little, and I don't see a method for me to
> specifically select the version of python that the tempest and grenade
> jobs for my project (neutron) are using.  I assume one of four things
> is at play here:
> 
> A. These projects already shifted to python 3 and I don't have to worry
> about it
> 
> B. There is a toggle for the python version I just have not seen yet
> 
> C. These projects are still on python 2 and need help to do a conversion
> to python 3, which would affect all customers
> 
> D. Something else that I have failed to imagine
> 
> Could you elaborate which of these options properly reflects the state
> of affairs?  If the answer is "C" then perhaps we can start a discussion
> on that migration.

For our devstack and grenade jobs tempest is installed using tox [0]. And since 
the full testenv in tempest's tox.ini doesn't specify a python version [1] I 
expect that it will attempt a python2 virtualenv on every platform (Arch linux 
may be an exception but we don't test that).

I think that means C is the situation here. To change that you can set 
basepython to python3 (see [2] for an example) which will run tempest under 
whichever python3 is present on the system. The one gotcha for this is that it 
will break tempest on centos which does not have python3. Maybe the thing to do 
there is add a full-python2 testenv that centos can run?

[0] https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/tempest#n653
[1] https://git.openstack.org/cgit/openstack/tempest/tree/tox.ini#n74
[2] https://git.openstack.org/cgit/openstack-infra/zuul/tree/tox.ini#n7

Hope this helps,
Clark

__
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] [heat][senlin] Action Required. Idea to propose for a forum for autoscaling features integration

[Duc Truong]

Hi Rico,

I'm the Senlin PTL and would be happy to have a forum discussion in
Berlin about the future of autoscaling.

Can you go ahead and start an etherpad to capture the proposed agenda
and discussion items?  Also, feel free to submit the forum submission
so that we can get it on the schedule.

Thanks,

Duc (dtruong)

On Mon, Sep 17, 2018 at 8:28 PM Rico Lin  wrote:

> *TL;DR*
> *How about a forum in Berlin for discussing autoscaling integration (as a
> long-term goal) in OpenStack?*
>
>
> Hi all, as we start to discuss how can we join develop from Heat and
> Senlin as we originally planned when we decided to fork Senlin from Heat
> long time ago.
>
> IMO the biggest issues we got now are we got users using autoscaling in
> both services, appears there is a lot of duplicated effort, and some great
> enhancement didn't exist in another service.
> As a long-term goal (from the beginning), we should try to join
> development to sync functionality, and move users to use Senlin for
> autoscaling. So we should start to review this goal, or at least we should
> try to discuss how can we help users without break or enforce anything.
>
> What will be great if we can build common library cross projects, and use
> that common library in both projects, make sure we have all improvement
> implemented in that library, finally to use Senlin from that from that
> library call in Heat autoscaling group. And in long-term, we gonna let all
> user use more general way instead of multiple ways but generate huge
> confusing for users.
>
> *As an action, I propose we have a forum in Berlin and sync up all effort
> from both teams to plan for idea scenario design. The forum submission [1]
> ended at 9/26.*
> Also would benefit from both teams to start to think about how they can
> modulize those functionalities for easier integration in the future.
>
> From some Heat PTG sessions, we keep bring out ideas on how can we improve
> current solutions for Autoscaling. We should start to talk about will it
> make sense if we combine all group resources into one, and inherit from it
> for other resources (ideally gonna deprecate rest resource types). Like we
> can do Batch create/delete in Resource Group, but not in ASG. We definitely
> got some unsynchronized works inner Heat, and cross Heat and Senlin.
>
> Please let me know who is interesting in this idea, so we can work
> together and reach our goal step by step.
> Also please provide though if you got any concerns about this proposal.
>
> [1] https://www.openstack.org/summit/berlin-2018/call-for-presentations
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [python3] tempest and grenade conversion to python 3.6

[Nate Johnston]

Hello python 3.6 champions,

I have looked around a little, and I don't see a method for me to
specifically select the version of python that the tempest and grenade
jobs for my project (neutron) are using.  I assume one of four things
is at play here:

A. These projects already shifted to python 3 and I don't have to worry
about it

B. There is a toggle for the python version I just have not seen yet

C. These projects are still on python 2 and need help to do a conversion
to python 3, which would affect all customers

D. Something else that I have failed to imagine

Could you elaborate which of these options properly reflects the state
of affairs?  If the answer is "C" then perhaps we can start a discussion
on that migration.

Thanks!

Nate Johnston

__
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] GUI for Swift object storage

[Tim Burke]

Hate to nitpick, but Cyberduck is licensed GPLv3 -- you can browse the source 
(and confirm the license) at https://trac.cyberduck.io/browser/trunk 
 and https://trac.cyberduck.io/ 
 indicates the source is available via git or svn. 
They do nag you to donate, though.

Swift explorer is Apache 2, available at 
https://github.com/roikku/swift-explorer 
. I don't know anything about 
Gladinet.

Tim

> On Sep 17, 2018, at 7:31 PM, M Ranga Swami Reddy  wrote:
> 
> All GUI tools are non open source...need to pay like cyberduck etc.
> Looking for open source GUI for Swift API access.
> 
> On Tue, 18 Sep 2018, 06:41 John Dickinson, mailto:m...@not.mn>> 
> wrote:
> That's a great question.
> 
> A quick google search shows a few like Swift Explorer, Cyberduck, and 
> Gladinet. But since Swift supports the S3 API (check with your cluster 
> operator to see if this is enabled, or examine the results of a GET /info 
> request), you can use any available S3 GUI client as well (as long as you can 
> configure the endpoints you connect to).
> 
> --John
> 
> On 17 Sep 2018, at 16:48, M Ranga Swami Reddy wrote:
> 
> Hi - is there any GUI (open source) available for Swift objects storage?
> 
> Thanks
> Swa
> __
> 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 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] [oslo][tacker][daisycloud-core][meteos] Removal of rpc_backend config opt from oslo.messaging

[Ken Giusti]

Thanks to work done by Steve Kowalik we're ready to remove the old
rpc_backend transport configuration option that has been deprecated since
mid 2016.  This removal involves changes to the oslo.messaging.ConfFixture
as well.

Steve has provided patches to those projects affected by these changes
Almost all projects have merged these patches.

There are a few projects - included in the subject line - where the
necessary patches have not yet landed.  If you're a committer on one of
these projects please make an effort to review the patches proposed for
your project:

https://review.openstack.org/#/q/topic:bug/1712399+status:open

Our goal is to land the removal next week.

thanks

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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Sylvain Bauza]

Le mar. 18 sept. 2018 à 16:00, Thierry Carrez  a
écrit :

> Sylvain Bauza wrote:
> >
> >
> > Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley  > > a écrit :
> >
> > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
> > [...]
> >  > I can understand that IRC cannot be used in China which is very
> >  > painful and mostly it is used weChat.
> > [...]
> >
> > I have yet to hear anyone provide first-hand confirmation that
> > access to Freenode's IRC servers is explicitly blocked by the
> > mainland Chinese government. There has been a lot of speculation
> > that the usual draconian corporate firewall policies (surprise, the
> > rest of the World gets to struggle with those too, it's not just a
> > problem in China) are blocking a variety of messaging protocols from
> > workplace networks and the people who encounter this can't tell the
> > difference because they're already accustomed to much of their other
> > communications being blocked at the border. I too have heard from
> > someone who's heard from someone that "IRC can't be used in China"
> > but the concrete reasons why continue to be missing from these
> > discussions.
> >
> > Thanks fungi, that's the crux of the problem I'd like to see discussed
> > in the governance change.
> > In this change, it states the non-use of existing and official
> > communication tools as to be "cumbersome". See my comment on PS1, I
> > thought the original concern was technical.
> >
> > Why are we discussing about WeChat now ? Is that because a large set of
> > our contributors *can't* access IRC or because they *prefer* any other ?
> > In the past, we made clear for a couple of times why IRC is our
> > communication channel. I don't see those reasons to be invalid now, but
> > I'm still open to understand the problems about why our community
> > becomes de facto fragmented.
>
> Agreed, I'm still trying to grasp the issue we are trying to solve here.
>
> We really need to differentiate between technical blockers (firewall),
> cultural blockers (language) and network effect preferences (preferred
> platform).
>
> We should definitely try to address technical blockers, as we don't want
> to exclude anyone. We can also allow for a bit of flexibility in the
> tools used in our community, to accommodate cultural blockers as much as
> we possibly can (keeping in mind that in the end, the code has to be
> written, proposed and discussed in a single language). We can even
> encourage community members to reach out on local social networks... But
> I'm reluctant to pass an official resolution to recommend that TC
> members engage on specific platforms because "everyone is there".
>
>
I second your opinion on this. Before voting on a TC resolution, we first
need at least to understand the problem.
Like I said previously, stating 'cumbersome' in the proposed resolution
doesn't imply a technical issue hence me jumping straight on the 3rd
possibility you mentioned, which is "by convenience".

In that case, the TC should rather reinforce the message that, as a whole
community, we try to avoid silos and that contributors should be highly
encouraged to stop discussing on other channels but the official ones.
Having the First Contact SIG be the first line for helping those people to
migrate to IRC (by helping them understand how it works, how to play with,
which kind of setup is preferrable (bouncers)) seems a great idea.

-Sylvain

-- 
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [election][tc]Question for candidates about global reachout

[Thomas Goirand]

On 09/14/2018 09:52 PM, Zhipeng Huang wrote:
> This is a joint question from mnaser and me :)
> 
> For the candidates who are running for tc seats, please reply to this
> email to indicate if you are open to use certain social media app in
> certain region (like Wechat in China

Even if I do use WeChat because of some of my Chinese friends that know
only that, I am strongly against using such a proprietary network,
especially for open development.

It's ok-ish if some Chinese want to create local community in WeChat.
It's not if the whole project vouches for this type of networks.

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] [election][tc]Question for candidates about global reachout

[Doug Hellmann]

Excerpts from Zhipeng Huang's message of 2018-09-14 13:52:50 -0600:
> This is a joint question from mnaser and me :)
> 
> For the candidates who are running for tc seats, please reply to this email
> to indicate if you are open to use certain social media app in certain
> region (like Wechat in China, Line in Japan, etc.), in order to reach out
> to the OpenStack developers in that region and help them to connect to the
> upstream community as well as answering questions or other activities that
> will help. (sorry for the long sentence ... )
> 
> Rico and I already sign up for Wechat communication for sure :)
> 
> -- 
> Zhipeng (Howard) Huang

[I replied on the governance resolution
https://review.openstack.org/#/c/602697/, but I will copy my reply
here since not everyone is following the comments there.]

While I support the end result this resolution is trying to achieve,
I don't think a TC resolution is the right way to go about it. The
existing governance resolutions are primarily used to document
decisions where there was a disagreement or solutions to issues
that need to be formally addressed. I don't think either criteria
applies in this case.

No member of our community needs permission to use social media,
so we don't need to document an opinion about that.

Formally encouraging members of our community, whether they are on
the TC or not, to reach out to other members also feels unnecessary.
We proudly declare our community to be open to anyone who wants to
participate in https://governance.openstack.org/tc/reference/opens.html
and many members of our community do engage in the sort of outreach
that is described in this resolution.

If there is a particular area of the community not being heard,
then we should work to understand why that is happening. If the
cause is really that too few of the TC members are signed up for
the right social media tools, then I think we have a much more
fundamental issue to address in the expectations of the community
and how the TC communicates as a group.

I believe a better approach to achieve the outcome this resolution
is trying to implement would be to organize some of the folks who
have already indicated that they are willing to help with outreach
and to work together to bring anyone who wants to participate in
the community into the existing communication channels (especially
the mailing list), so that we can all collaborate there together.
There was support for an approach like that in the room during the
meeting last week.

Doug

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

[openstack-dev] [goals][python3] week 6 update

[Doug Hellmann]

This is the 6th week of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html). 

== What we learned last week ==

I spoke with a few teams at the PTG to clarify the process and the
"definition of done" for the goal. If you have similar questions, please
get in touch.

There are still a lot of patches failing jobs.

== Ongoing and Completed Work ==

I have updated the status report output to separate the zuul
migration, documentation, and unit test changes. In the chart below
+ means completed, - means not needed, and x/y means x open patches
out of y total (except in the bottom line where the numbers are
counting teams).

I am not yet tracking any work on functional tests.

+-+-+--+-+--+-+---++
| Team| zuul| tox defaults | Docs| 3.6 unit | Failing | 
Total | Champion   |
+-+-+--+-+--+-+---++
| adjutant| +   | -| -   | +|   0 | 
5 | Doug Hellmann  |
| barbican|  11/ 13 | +|   1/  3 | +|   6 | 
   20 | Doug Hellmann  |
| blazar  |   2/ 16 | +| +   | +|   0 | 
   25 | Nguyen Hai |
| Chef OpenStack  | +   | -| -   | -|   0 | 
1 | Doug Hellmann  |
| cinder  |   1/ 22 | +| +   | +|   1 | 
   31 | Doug Hellmann  |
| cloudkitty  | +   | +| +   | +|   0 | 
   24 | Doug Hellmann  |
| congress| +   | +| +   | +|   0 | 
   24 | Nguyen Hai |
| cyborg  | +   | +| +   | +|   0 | 
   16 | Nguyen Hai |
| designate   | +   | +| +   | +|   0 | 
   24 | Nguyen Hai |
| Documentation   | +   | +| +   | +|   0 | 
   22 | Doug Hellmann  |
| dragonflow  | +   | -| +   | +|   0 | 
6 | Nguyen Hai |
| ec2-api | +   | -| +   | +|   0 | 
   12 ||
| freezer |   3/ 23 | +| +   |   2/  4  |   2 | 
   33 ||
| glance  |   1/ 16 |   1/  4  |   1/  3 |   1/  3  |   2 | 
   26 | Nguyen Hai |
| heat|   5/ 27 |   1/  5  |   1/  6 |   1/  7  |   3 | 
   45 | Doug Hellmann  |
| horizon | +   | +| +   | +|   0 | 
   11 | Nguyen Hai |
| I18n| +   | -| -   | -|   0 | 
2 | Doug Hellmann  |
| InteropWG   | +   | -| +   |   1/  3  |   0 | 
   10 | Doug Hellmann  |
| ironic  |  14/ 60 | +|   2/ 13 |   2/ 12  |   4 | 
   90 | Doug Hellmann  |
| karbor  |  15/ 15 | +|   2/  2 |   3/  3  |   0 | 
   22 | Nguyen Hai |
| keystone| +   | +| +   | +|   0 | 
   47 | Doug Hellmann  |
| kolla   | +   | -| +   | +|   0 | 
   12 ||
| kuryr   |   5/ 16 | +|   2/  6 |   2/  5  |   8 | 
   28 | Doug Hellmann  |
| magnum  | +   | +| +   | +|   0 | 
   24 ||
| manila  |   3/ 19 | +| +   | +|   3 | 
   28 | Goutham Pacha Ravi |
| masakari| +   | +| +   | -|   0 | 
   21 | Nguyen Hai |
| mistral | +   | +| +   | +|   0 | 
   37 | Nguyen Hai |
| monasca |   3/ 66 |   1/  7  | +   | +|   4 | 
   90 | Doug Hellmann  |
| murano  | +   | +| +   | +|   0 | 
   37 ||
| neutron |  30/ 73 | +|   2/ 14 |   3/ 13  |  16 | 
  106 | Doug Hellmann  |
| nova|  14/ 23 | +|   1/  5 |   1/  5  |   0 | 
   37 ||
| octavia | +   | +| +   | +|   0 | 
   34 | Nguyen Hai |
| OpenStack Charms|  17/117 | -| -   | -|  14 | 
  117 | Doug Hellmann  |
| OpenStack-Helm  | +   | -| +   | -|   0 | 
4 ||
| OpenStackAnsible|  31/270 |   2/ 32  |   9/ 65 | -|  23 | 
  367 ||
| OpenStackClient | +   | +| +   | +|   0 | 
 

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Samuel Cassiba]

On Tue, Sep 18, 2018 at 5:34 AM Jeremy Stanley  wrote:
>
> On 2018-09-18 10:23:33 +0800 (+0800), Zhipeng Huang wrote:
> [...]
> > Jeremy, what I'm saying here, and also addressed in comments with
> > the related resolution patch, is that personality reasons are the
> > ones that we have to respect and no form of governance change
> > could help solve the problem. However other than that, we could
> > always find a way to address the issue for remedies, if we don't
> > have a good answer now maybe we will have sometime later.
> >
> > Preference on  social tooling is something that the technical
> > committee is able to address, with isolation of usage of
> > proprietary tools for certain scenario and also strict policy on
> > enforcing the open source communication solutions we have today as
> > the central ones the community will continue to use. This is not
> > an unsolvable problem given that we have a technical committee,
> > but personality issues are, no matter what governance instrument
> > we have.
>
> Once again, I think we're talking past each other. I was replying to
> (and quoted from) the provided sample rejection letter. First I
> wanted to point out that I had already rejected the premise earlier
> on this thread even though it was suggested that no rejection had
> yet been provided. Second, the sample letter seemed to indicate what
> I believe to be a fundamental misunderstanding among those pushing
> this issue: the repeated attempts I've seen so far to paint a
> disinterest in participating in wechat interactions as mere
> "personal preference," and the idea that those who hold this
> "preference" are somehow weak or afraid of the people they'll
> encounter there.
>
> For me, it borders on insulting. I (and I believe many others) have
> strong ideological opposition to participating in these forums, not
> mere personal preferences.
> --
> Jeremy Stanley
>

It is incredibly difficult to convey intent over primarily text-based
mediums, of which I primarily interact with individuals I've never
seen in-person. What is my ideological principle, is someone's
personal preference, isn't even a thought to yet another.

I work within other FLOSS projects outside of OpenStack. With some, my
primary interactions take place over Slack, because they made the
conscious choice to hoist their user community to a free instance,
nominating people to an ambassador role for keeping their message
intact on IRC. Other times, it's over GitHub, where the whole
interaction takes place within the one platform.

Within OpenStack, some people I've only ever worked with through code
reviews or bug reports. Others, IRC or email. People are going to
gravitate toward what makes sense for them, but that's where the lines
between ideology and preference blur.

Agreeing to keep the important lines of communication to a certain
medium is the preference here, but it's also the ideological belief.
The debates ongoing are not Wechat versus Twitter versus IRC versus
Slack. It's over keeping the intent of being open, which is defined in
the very namesake.

Many moons ago, Chef OpenStack was advised to actively eschew video
meetings before being approved to being an OpenStack project under the
Big Tent experiment during the rise of the hype. This happened,
despite the active actions for openness and inclusiveness into the
weekly video meetings, because there was no text record to reference.
This, in turn, resulted in fewer and fewer developers being able to
justify having an hour a week to 'mess around' on IRC, and thus the
hastening of the deflationary period. With a video running, it was more
reasonable to being able to justify an hour to a conference room or an
office to further the intent of openness in the community.

I directly see the benefit in having a means to reach the greater
community (hi! o/) but I do not directly see the correlation in
defining a given social platform as being The Platform for Relevant
Communications beyond email or code review. Email and code review are,
by far, the most accessible points around the globe.

For the Horde^Wcode,

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] [Openstack-sigs] [tc][uc]Community Wide Long Term Goals

[Doug Hellmann]

Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
> Hi,
> 
> Based upon the discussion we had at the TC session in the afternoon, I'm
> starting to draft a patch to add long term goal mechanism into governance.
> It is by no means a complete solution at the moment (still have not thought
> through the execution method yet to make sure the outcome), but feel free
> to provide your feedback at https://review.openstack.org/#/c/602799/ .
> 
> -- 
> Zhipeng (Howard) Huang

[I commented on the patch, but I'll also reply here for anyone not
following the review.]

I'm glad to see the increased interest in goals. Before we change
the existing process, though, I would prefer to see engagement with
the current process. We can start by having SIGs and WGs update the
etherpad where we track goal proposals
(https://etherpad.openstack.org/p/community-goals) and then we can
see if we actually need to manage goals across multiple release
cycles as a single unit.

Doug

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

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

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-38.html

Rather than writing a TC Report this week, I've written a report on
the [OpenStack Stein
PTG](https://anticdent.org/openstack-stein-ptg.html).

--
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] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Dean Troyer]

On Tue, Sep 18, 2018 at 7:40 AM, Jeremy Stanley  wrote:
> I have yet to hear anyone provide first-hand confirmation that
> access to Freenode's IRC servers is explicitly blocked by the
> mainland Chinese government. There has been a lot of speculation
[...]

Data point: I have a couple of reports from some of our StarlingX
contributors that access to Freenode IRC works from our (Intel) sites
but not from home.  I am not going to speculate as to the cause, it
clearly is not open access, but also not totally closed off.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Jay S Bryant]

On 9/18/2018 7:40 AM, Jeremy Stanley wrote:

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]

I can understand that IRC cannot be used in China which is very
painful and mostly it is used weChat.

[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.

I have team members in Shanghai who are able to access IRC.  I will 
double check, but I am not aware of them doing anything to work around 
the national firewall.  So, I am guessing that we are dealing with the 
usual corporate firewall issues.




__
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] [tc] notes from stein ptg meetings of the technical committee

[Zane Bitter]

On 17/09/18 5:07 PM, Jay Pipes wrote:
Also, for the record, I actually wasn't referring to Adjutant 
specifically when I referred in my original post to "only tangentially 
related to cloud computing". I was referring to my recollection of 
fairly recent history. I remember the seemingly endless debates about 
whether some applicants "fit" the OpenStack ecosystem or whether the 
applicant was merely trying to jump on a hype bandwagon for marketing 
purposes. Again, I wasn't specifically referring to Adjutant here, so I 
apologize if my words came across that way.


Thanks for the clarification. What you're referring to is also an 
acknowledged problem, which we discussed at the Forum and are attempting 
to address with the Technical Vision (which we need to find a better 
name for). We didn't really discuss that on the Sunday though, because 
it was a topic on the formal agenda for Friday. Sunday's discussion was 
purely a retrospective on the Adjutant application, so you should read 
Doug's summary in that context.


cheers,
Zane.

__
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-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Thierry Carrez]

Sylvain Bauza wrote:



Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley > a écrit :


On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]
 > I can understand that IRC cannot be used in China which is very
 > painful and mostly it is used weChat.
[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.

Thanks fungi, that's the crux of the problem I'd like to see discussed 
in the governance change.
In this change, it states the non-use of existing and official 
communication tools as to be "cumbersome". See my comment on PS1, I 
thought the original concern was technical.


Why are we discussing about WeChat now ? Is that because a large set of 
our contributors *can't* access IRC or because they *prefer* any other ?
In the past, we made clear for a couple of times why IRC is our 
communication channel. I don't see those reasons to be invalid now, but 
I'm still open to understand the problems about why our community 
becomes de facto fragmented.


Agreed, I'm still trying to grasp the issue we are trying to solve here.

We really need to differentiate between technical blockers (firewall), 
cultural blockers (language) and network effect preferences (preferred 
platform).


We should definitely try to address technical blockers, as we don't want 
to exclude anyone. We can also allow for a bit of flexibility in the 
tools used in our community, to accommodate cultural blockers as much as 
we possibly can (keeping in mind that in the end, the code has to be 
written, proposed and discussed in a single language). We can even 
encourage community members to reach out on local social networks... But 
I'm reluctant to pass an official resolution to recommend that TC 
members engage on specific platforms because "everyone is there".


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Jeremy Stanley]

On 2018-09-18 14:52:28 +0200 (+0200), Sylvain Bauza wrote:
[...]
> Why are we discussing about WeChat now? Is that because a large
> set of our contributors *can't* access IRC or because they
> *prefer* any other?

Until we get confirmation either way, I'm going to work under the
assumption that there are actual network barriers to using IRC for
these contributors and that it's not just a matter of preference. I
mainly want to know the source of these barriers because that will
determine how to go about addressing them.

If it's restrictions imposed by employers, it may be hard for
employees to raise the issue in predominantly confrontation-averse
cultures. The First Contact SIG is working on a document which
outlines the communications and workflows used by our community with
a focus on explaining to managers and other staff at contributing
organizations what allowances they can make to ease and improve the
experience of those they've tasked with working upstream.

If the barriers are instead imposed by national government, then
urging contributors within those borders to flaunt the law and
interact with the rest of our community over IRC is not something
which should be taken lightly. That's not to say it can't be solved,
but the topic then is a much more political one and our community
may not be an appropriate venue for those discussions.

> In the past, we made clear for a couple of times why IRC is our
> communication channel. I don't see those reasons to be invalid
> now, but I'm still open to understand the problems about why our
> community becomes de facto fragmented.

I think the extended community is already fragmented across a
variety of discussion fora. Some watch for relevant hashtags on
Twitter and engage in discussions there. I gather there's an
unofficial OpenStack Slack channel where lots of newcomers show up
to ask questions because they assume the OpenStack community relies
on Slack the same way the Kubernetes community does, and so a few
volunteers from our community hang out there and try to redirect
questions to more appropriate places. I've also heard tell of an
OpenStack subReddit which some stackers help moderate and try to
provide damage control/correct misstatements there. I don't think
these are necessarily a problem, and the members of our community
who work to spread accurate information to these places are in many
cases helping reduce the actual degree of fragmentation.

I'm still trying to make up my mind on 602697 which is why I haven't
weighed in on the proposal yet. So far I feel like it probably
doesn't bring anything new, since we already declare how and where
official discussion takes place and the measure doesn't make any
attempt to change that. We also don't regulate where unofficial
discussions are allowed to take place, and so it doesn't open up any
new possibilities which were previously disallowed.
-- 
Jeremy Stanley


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] GUI for Swift object storage

[Clay Gerrard]

I don't know about a good open source cross-platform GUI client, but the
SwiftStack one is slick and doesn't seem to be behind a paywall (yet?)

https://www.swiftstack.com/downloads

There's probably some proprietary integration that won't make sense - but
it should work with any Swift end-point.  Let me know how it goes!

-Clay

N.B. IANAL, so you should probably double check the license/terms if you're
planning on doing anything more sophisticated than personal use.

On Mon, Sep 17, 2018 at 9:31 PM M Ranga Swami Reddy 
wrote:

> All GUI tools are non open source...need to pay like cyberduck etc.
> Looking for open source GUI for Swift API access.
>
> On Tue, 18 Sep 2018, 06:41 John Dickinson,  wrote:
>
>> That's a great question.
>>
>> A quick google search shows a few like Swift Explorer, Cyberduck, and
>> Gladinet. But since Swift supports the S3 API (check with your cluster
>> operator to see if this is enabled, or examine the results of a GET /info
>> request), you can use any available S3 GUI client as well (as long as you
>> can configure the endpoints you connect to).
>>
>> --John
>>
>> On 17 Sep 2018, at 16:48, M Ranga Swami Reddy wrote:
>>
>> Hi - is there any GUI (open source) available for Swift objects storage?
>>
>> Thanks
>> Swa
>> __
>> 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 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-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Sylvain Bauza]

Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley  a écrit :

> On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
> [...]
> > I can understand that IRC cannot be used in China which is very
> > painful and mostly it is used weChat.
> [...]
>
> I have yet to hear anyone provide first-hand confirmation that
> access to Freenode's IRC servers is explicitly blocked by the
> mainland Chinese government. There has been a lot of speculation
> that the usual draconian corporate firewall policies (surprise, the
> rest of the World gets to struggle with those too, it's not just a
> problem in China) are blocking a variety of messaging protocols from
> workplace networks and the people who encounter this can't tell the
> difference because they're already accustomed to much of their other
> communications being blocked at the border. I too have heard from
> someone who's heard from someone that "IRC can't be used in China"
> but the concrete reasons why continue to be missing from these
> discussions.
>


Thanks fungi, that's the crux of the problem I'd like to see discussed in
the governance change.
In this change, it states the non-use of existing and official
communication tools as to be "cumbersome". See my comment on PS1, I thought
the original concern was technical.

Why are we discussing about WeChat now ? Is that because a large set of our
contributors *can't* access IRC or because they *prefer* any other ?
In the past, we made clear for a couple of times why IRC is our
communication channel. I don't see those reasons to be invalid now, but I'm
still open to understand the problems about why our community becomes de
facto fragmented.

-Sylvain





> --
> Jeremy Stanley
> __
> 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] [ptg] Post-lunch presentations schedule

[Bedyk, Witold]

Stephen,

could you please share your presentation slides?

Thanks
Witek


> -Original Message-
> From: Thierry Carrez 
> Sent: Freitag, 24. August 2018 11:21
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] [ptg] Post-lunch presentations schedule



> Friday: Lightning talks
> Fast-paced 5-min segments to talk about anything... Summaries of team
> plans for Stein encouraged. A presentation of Sphinx in OpenStack by
> stephenfin will open the show.
__
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-sigs] [Openstack-operators] [tc]Global Reachout Proposal

[Jeremy Stanley]

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]
> I can understand that IRC cannot be used in China which is very
> painful and mostly it is used weChat.
[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.
-- 
Jeremy Stanley


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] [election][tc]Question for candidates about global reachout

[Jeremy Stanley]

On 2018-09-18 10:23:33 +0800 (+0800), Zhipeng Huang wrote:
[...]
> Jeremy, what I'm saying here, and also addressed in comments with
> the related resolution patch, is that personality reasons are the
> ones that we have to respect and no form of governance change
> could help solve the problem. However other than that, we could
> always find a way to address the issue for remedies, if we don't
> have a good answer now maybe we will have sometime later.
> 
> Preference on  social tooling is something that the technical
> committee is able to address, with isolation of usage of
> proprietary tools for certain scenario and also strict policy on
> enforcing the open source communication solutions we have today as
> the central ones the community will continue to use. This is not
> an unsolvable problem given that we have a technical committee,
> but personality issues are, no matter what governance instrument
> we have.

Once again, I think we're talking past each other. I was replying to
(and quoted from) the provided sample rejection letter. First I
wanted to point out that I had already rejected the premise earlier
on this thread even though it was suggested that no rejection had
yet been provided. Second, the sample letter seemed to indicate what
I believe to be a fundamental misunderstanding among those pushing
this issue: the repeated attempts I've seen so far to paint a
disinterest in participating in wechat interactions as mere
"personal preference," and the idea that those who hold this
"preference" are somehow weak or afraid of the people they'll
encounter there.

For me, it borders on insulting. I (and I believe many others) have
strong ideological opposition to participating in these forums, not
mere personal preferences.
-- 
Jeremy Stanley


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] Bumping eventlet to 0.24.1

[Dmitry Tantsur]

On 9/6/18 8:52 AM, Matthew Thode wrote:

On 18-08-23 09:50:13, Matthew Thode wrote:

This is your warning, if you have concerns please comment in
https://review.openstack.org/589382 .  cross tests pass, so that's a
good sign... atm this is only for stein.



I pushed the big red button.


Ironic grenade might have been broken by this change: 
https://bugs.launchpad.net/neutron/+bug/1792925. No clear evidence, but that 
seems to be the only suspect.





__
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] Meeting tomorrow

[Tobias Rydberg]

Hi everyone,

Don't forget that we have a meeting tomorrow at 0700 UTC at IRC channel 
#openstack-publiccloud.


See you all there!

Cheers,
Tobias

--
Tobias Rydberg
Senior Developer
Twitter & IRC: tobberydberg

www.citynetwork.eu | www.citycloud.com

INNOVATION THROUGH OPEN IT INFRASTRUCTURE
ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED


__
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] [kayobe] Stein forum topics

[Mark Goddard]

Hi,

Brainstorming for the Stein forum in Berlin has started, please add your
proposal topics before 26th September to
https://etherpad.openstack.org/p/kayobe-stein-forum.

Forum topics are proposed using the same CFP method as Summit
presentations:
https://www.openstack.org/summit/berlin-2018/call-for-presentations

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

Re: [openstack-dev] [tc] notes from stein ptg meetings of the technical committee

[Thierry Carrez]

Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-09-17 17:07:43 -0400:

On 09/17/2018 04:50 PM, Doug Hellmann wrote:

[...]
I don't remember the history quite the way Jay does, either. I
remember us trying to base the decision more about what the team
was doing than how the code looked or whether the implementation
met anyone's idea of "good". That's why we retained the requirement
that the project "aligns with the OpenStack Mission".


Hmm. I very specifically remember the incubation and graduation review
of Zaqar and the fact that over a couple cycles of TC elections, the
"advice" given by the TC about specific technical implementation details
changed, often arbitrarily, depending on who was on the TC and what day
of the week it was. In fact, I pretty vividly remember this arbitrary
nature of the architectural review being one of the primary reasons we
switched to a purely objective set of criteria.


I remember talking about objectivity, but I also remember that we
stopped reviewing aspects of a project like it's architecture or
implementation details to avoid having the case you describe recur.
I remember that because I had a hard time coming around to that
point of view, at first.

You're correct, however, that the resolution we adopted as the first
step toward the big tent change
(https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#recognize-all-our-community-is-a-part-of-openstack)
does talk about making decisions based on team practices and projects
fitting the mission as being objective requirements. And the patch
that implemented the first part of the big tent change
(https://review.openstack.org/#/c/145740/14) also talks about
objectivity.

It's interesting that we took different things away from the same
discussion. :-)

In any case, I think we've learned there is still quite a bit of
subjectivity in the question about whether a project fits the
mission.


Right. Back then our goal was definitely to remove the most subjective 
requirements. We removed judgment on whether the project was a good 
idea, or whether the technical architecture was sound, or whether the 
project was "mature" enough. We only kept two criteria: alignment with 
the OpenStack culture, and alignment with the OpenStack mission.


Those are not purely objective criteria though. We had cases where we 
had to do a leap of faith whether the project really aligns with the 
OpenStack culture. And we had projects that were in a grey area even 
with our very vague mission statement. The Adjutant discussion, in the 
end, was about whether it would significantly hurt interoperability, and 
therefore be detrimental to the OpenStack mission rather than helping it.


--
Thierry Carrez (ttx)

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

[openstack-dev] [kolla] Stein forum topics proposal

[Eduardo Gonzalez]

Hi, Berlin forum brainstorming has started, please add your proposal topics
before 26th september

https://etherpad.openstack.org/p/kolla-forum-stein

Forum topics are proposed the same method as Summit presentations

https://www.openstack.org/summit/berlin-2018/call-for-presentations

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

[openstack-dev] [charms] retiring the ceph charm

[James Page]

Hi All

We deprecated and stopped releasing the ceph charm a few cycles back in
preference to the split ceph-osd/ceph-mon charms; consider this official
notification of retirement!

Cheers

James
__
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