[openstack-dev] [TripleO] roles_data.yaml equivalent in containers

[Abhishek Kane]

Hi,

In THT I have an environment file and corresponding puppet service for Veritas 
HyperScale.
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/veritas-hyperscale/veritas-hyperscale-config.yaml
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/veritas-hyperscale-controller.yaml

This service needs rabbitmq user the hooks for it is 
“veritas_hyperscale::hs_rabbitmq”-
https://github.com/openstack/puppet-tripleo/blob/master/manifests/profile/base/rabbitmq.pp#L172

In order to configure Veritas HyperScale, I add 
“OS::TripleO::Services::VRTSHyperScale” to roles_data.yaml file and use 
following command-

# openstack overcloud deploy --templates -r /home/stack/roles_data.yaml -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/veritas-hyperscale-config.yaml
 -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/cinder-veritas-hyperscale-config.yaml

This command sets “veritas_hyperscale_controller_enabled” to true in hieradata 
and all the hooks gets called.

I am trying to containerize Veritas HyperScale services. I used following 
config file in quickstart-
http://paste.openstack.org/show/624438/

It has the environment files-
  -e 
{{overcloud_templates_path}}/environments/veritas-hyperscale/cinder-veritas-hyperscale-config.yaml
  -e 
{{overcloud_templates_path}}/environments/veritas-hyperscale/veritas-hyperscale-config.yaml

But this itself doesn’t set “veritas_hyperscale_controller_enabled” to true in 
hieradata and veritas_hyperscale::hs_rabbitmq doesn’t get called.
https://github.com/openstack/tripleo-heat-templates/blob/master/roles_data.yaml#L56


How do I add OS::TripleO::Services::VRTSHyperScale in case of containers?

Thanks,
Abhishek

__
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][horizon] Migration to heat-dashboard: how can we move this forward?

[Kaz Shinohara]

 Hi Akihiro,


Thanks for your kind following up :)

> (1) Patch reviews and approvals in horizon
Could you please stop to accept heat-dashboard related patches without
critical ones ?
According to our discussion in the last PTG, we made heat-dashboard
repo taking horizon repo as upstream & now trying to land it in
queens-2.
Of course we will keep looking at what's going on in Horizon side &
will cherry-pick the leftovers if needed in the end.

> (2) Bug Management
Yes we can take over those bugs, but now we are focusing to stabilize
heat-dashboard-self.
We would like to fix them after we will safely land heat-dashboard in queens-2.

Regards,
Kaz Shinohara

2017-10-25 11:47 GMT+09:00 Akihiro Motoki :
> Hi Heat dashboard team,
>
> I noticed heat-dashboard repository was created.
> I have several questions from horizon side.
>
> A big question is "When does the switch happen?"
>
> This mainly affects two things:
>
> (1) Patch reviews and approvals in horizon
>
> Should the horizon team stop to accept heat-dashboard related patches
> into the horizon repo now?
> If you want to migrate in parallel, you need to take care of what
> happens in the horizon repo continuously.
> The simplest way is to stop any activities in horizon side.
>
> Note that one patch landed yesterday into the horizon repo.
> Perhaps the heat-dashboard team will cherry-pick it into your repository.
>
> (2) Bug Management
>
> Is it okay to forward heat-related bugs into heat-dashboard launchpad?
> When do we start?
> There are several number of existing bugs related to the heat dashboard.
> The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
> https://bugs.launchpad.net/horizon/+bugs?field.tag=heat
>
> Thanks,
> Akihiro
>
> __
> 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] [all][charms][fuel][Packaging-Deb] Remove old numeric branches

[Tony Breeds]

On Wed, Sep 20, 2017 at 01:52:11PM -0400, Tony Breeds wrote:
> Hello all,
> Now we have cleaned up some of the older series based branches I've
> taken a look at some of the numeric based branches.
> 
> The projects in $subject are particularly impacted.  I've made my best
> guess at which branches are current, but I'd really appreciate guidance
> on the life span of these branches.
> 
> As before as the ultimate consumer of the data is infra I've presented
> this in a form that's easy for them to consume:
> 
> Ideally I'd like to move on this this week but that isn't enough
> consultation.  So I'll pass the list to infra Monday 2nd October

The branches in 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122381.html
have been removed now.

There was small issues with the openstack/deb-gnocchi and
openstack/deb-python-gnocchiclient in that the .gitreview file pointed
at the wrong repo (upstream in this case).  These were corrected
manually

Also:
 - openstack/deb-python-django-pyscss
 - openstack/charm-plumgrid-director
 - openstack/charm-plumgrid-edge
 - openstack/charm-plumgrid-gateway

All seemed to be missing .gitreview files to the remote needed to be
added manually.

Yours Tony.


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

Re: [openstack-dev] [stable] Preping for the stable/newton EOL

[Tony Breeds]

On Tue, Oct 24, 2017 at 05:11:15PM +1100, Tony Breeds wrote:
> On Fri, Oct 06, 2017 at 10:15:56AM +1100, Tony Breeds wrote:
> > On Wed, Oct 04, 2017 at 02:51:06PM +1100, Tony Breeds wrote:
> > > I'll prep the list of repos that will be tagged EOL real soon now for
> > > review.
> > 
> > As promised here's the list.  The fomat is new, It's grouped by project
> > team so it should be easy for teams to find repos they care about.
> > 
> > The only wart may be repos I couldn't find an owning team for, so check
> > the '-' as the owning team.
> > 
> > I'm proposing to EOL all projects that meet one or more of the following
> > criteria:
> > 
> > - The project is openstack-dev/devstack, openstack-dev/grenade or
> >   openstack/requirements (although these wil be done last)
> > - The project has the 'check-requirements' job listed as a template in
> >   project-config:zuul/layout.yaml
> > - The project gates with either devstack or grenade jobs
> > - The project is listed in governance:reference/projects.yaml and is tagged
> >   with 'stable:follows-policy'.
> > 
> > 
> > Based on previous cycles I have opted out:
> > - 'openstack/group-based-policy'
> > - 'openstack/openstack-ansible' # So they can add EOL tags
> > 
> > Also based on recent email's with tripleo I have opted out:
> > - 'openstack/instack'
> > - 'openstack/instack-undercloud'
> > - 'openstack/os-apply-config'
> > - 'openstack/os-collect-config'
> > - 'openstack/os-net-config'
> > - 'openstack/os-refresh-config'
> > - 'openstack/puppet-tripleo'
> > - 'openstack/python-tripleoclient'
> > - 'openstack/tripleo-common'
> > - 'openstack/tripleo-heat-templates'
> > - 'openstack/tripleo-puppet-elements'
> > - 'openstack/tripleo-validations'
> > - 'openstack/tripleo-image-elements'
> > - 'openstack/tripleo-ui'
> 
> I've also removed the following repos as the have open release requests
> for stable/newton
>  - openstack/nova
>  - openstack/ironic
>  - openstack/openstack-ansible*
> 
> And at the request of the docs team I've omitted:
>  - openstack/openstack-manuals
> 
> to facilitate 'badging' of the newton docs.

The repos listed in 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123910.html
have been retired.

There were a couple of issues
- openstack/deb-python-os-cloud-config
- openstack/bareon
My clones of both had stale gerrit remotes that has been corrected
manually.

The timing of the next phase is uncertain right now but I'd like to take
care of:

- openstack/nova
- openstack/ironic
- openstack/openstack-ansible*
- openstack/openstack-manuals

before the summit if possible.

Thanks to the infra team for enabling this to happen today.

Tony.


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

[openstack-dev] [heat][horizon] Migration to heat-dashboard: how can we move this forward?

[Akihiro Motoki]

Hi Heat dashboard team,

I noticed heat-dashboard repository was created.
I have several questions from horizon side.

A big question is "When does the switch happen?"

This mainly affects two things:

(1) Patch reviews and approvals in horizon

Should the horizon team stop to accept heat-dashboard related patches
into the horizon repo now?
If you want to migrate in parallel, you need to take care of what
happens in the horizon repo continuously.
The simplest way is to stop any activities in horizon side.

Note that one patch landed yesterday into the horizon repo.
Perhaps the heat-dashboard team will cherry-pick it into your repository.

(2) Bug Management

Is it okay to forward heat-related bugs into heat-dashboard launchpad?
When do we start?
There are several number of existing bugs related to the heat dashboard.
The horizon team now just adds 'heat' tag and is waiting for heat-dashboard.
https://bugs.launchpad.net/horizon/+bugs?field.tag=heat

Thanks,
Akihiro

__
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] [os-vif] [nova] Changes to os-vif cores

[Tony Breeds]

On Tue, Oct 24, 2017 at 03:32:15PM +0100, Stephen Finucane wrote:
> Hey,
> 
> I'm not actually sure what the protocol is for adding/removing cores to a
> library project without a PTL, so I'm just going to put this out there: I'd
> like to propose the following changes to the os-vif core team.

FWIW, os-vif is part of nova in terms of governance so Matt is the PTL
for os-vif ;P

https://governance.openstack.org/tc/reference/projects/nova.html#os-vif
 
> - Add 'nova-core'
> 
>   os-vif makes extensive use of objects and we've had a few hiccups around
>   versionings and the likes recently [1][2]. I'd the expertise of some of the
>   other nova cores here as we roll this out to projects other than nova, and I
>   trust those not interested/knowledgeable in this area to stay away :)
> 
> - Remove Russell Bryant, Maxime Leroy
> 
>   These folks haven't been active on os-vif  [3][4] for a long time and I 
> think
>   they can be safely removed.
> 
> To the existing core team members, please respond with a yay/nay and we'll 
> wait
> a week before doing anything.

FWIW that all sounds reasonable to me.

Yours Tony.


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

Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Jeremy Stanley]

On 2017-10-24 16:24:39 -0700 (-0700), Armando M. wrote:
[...]
> I hope I represented the conversation correctly!
[...]

Totally accurate, thanks!
-- 
Jeremy Stanley


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

Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Armando M.]

On 24 October 2017 at 13:13, Jeremy Stanley  wrote:

> On 2017-10-24 11:31:56 -0700 (-0700), Armando M. wrote:
> [...]
> > the work on neutron-lib is slowly progressing but it's not close enough
> to
> > allow us to break the dependency that requires neutron sub-projects to
> add
> > neutron to the list of required-projects (which I believe the sort of the
> > error in the release pipeline stems from).
> [...]
>
> It's not entirely clear to me what about a Neutron plug-in would
> actually require the neutron source installed just to be able to
> generate a tarball (or wheel) or build sphinx docs. Couldn't that be
> solved even if things like installation or unit testing still
> continue to need neutron?
>

Jeremy and I talked about this in [1].

To sum it up: the necessity of neutron for plugins is primarily for testing
and installation to the best of my knowledge. Other coupling tied to bash
scripts that control gate jobs could be easily addressed if it gets in the
way. Therefore, should we move away from tox for release specific tasks,
it's entirely possible to drop the custom project definition.

I hope I represented the conversation correctly!

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/latest.log.html#t2017-10-24T23:06:35


> --
> 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Emilien Macchi]

I figured that Sydney would be a great opportunity to have face2face
discussion around this topic, and I commit to be there and try to make
progress on this discussion.
I would love to get some people representing their deployment projects
and operators as well.

Please join us :
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20456/what-do-operators-want-from-the-stable-policy
and probably 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20480/upstream-lts-releases

Thanks,

On Tue, Oct 17, 2017 at 8:32 AM, Fox, Kevin M  wrote:
> So, my $0.02.
>
> A supported/recent version of a tool to install an unsupported version of a 
> software is not a bad thing.
>
> OpenStack has a bad reputation (somewhat deservedly) for being hard to 
> upgrade. This has mostly gotten better over time but there are still a large 
> number of older, unsupported deployments at this point.
>
> Sometimes, burning down the cloud isn't an option and sometimes upgrading in 
> place isn't an option either, and they are stuck on an unsupported version.
>
> Being able to deploy with a more modern installer the same version of the 
> cloud your running in production and shift the load to it (sideways upgrade), 
> but then have an upgrade path provided by the tool would be a great thing.
>
> Thanks,
> Kevin
> 
> From: Michał Jastrzębski [inc...@gmail.com]
> Sent: Monday, October 16, 2017 3:50 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] 
> [puppet] Proposing changes in stable policy for installers
>
> So my 0.02$
>
> Problem with handling Newton goes beyond deployment tools. Yes, it's
> popular to use, but if our dependencies (openstack services
> themselves) are unmaintained, so should we. If we say "we support
> Newton" in deployment tools, we make kind of promise we can't keep. If
> for example there is CVE in Nova that affects Newton, there is nothing
> we can do about it and our "support" is meaningless.
>
> Not having LTS kind of model was issue for OpenStack operators
> forever, but that's not problem we can solve in deployment tools
> (although we are often asked for that because our communities are
> largely operators and we're arguably closest projects to operators).
>
> I, for one, think we should keep current stable policy, not make
> exception for deployment tools, and address this issue across the
> board. What Emilien is describing is real issue that hurts operators.
>
> On 16 October 2017 at 15:38, Emilien Macchi  wrote:
>> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  
>> wrote:
>>> Emilien Macchi wrote:
 [...]
 ## Proposal

 Proposal 1: create a new policy that fits for projects like installers.
 I kicked-off something here: https://review.openstack.org/#/c/511968/
 (open for feedback).
 Content can be read here:
 http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
 Tag created here: https://review.openstack.org/#/c/511969/ (same,
 please review).

 The idea is really to not touch the current stable policy and create a
 new one, more "relax" that suits well for projects like installers.

 Proposal 2: change the current policy and be more relax for projects
 like installers.
 I haven't worked on this proposal while it was something I was
 considering doing first, because I realized it could bring confusion
 in which projects actually follow the real stable policy and the ones
 who have exceptions.
 That's why I thought having a dedicated tag would help to separate them.

 Proposal 3: no change anywhere, projects like installer can't claim
 stability etiquette (not my best option in my opinion).

 Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
 TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
 this need), please get involved in the review process.
>>>
>>> My preference goes to proposal 1, however rather than call it "relaxed"
>>> I would make it specific to deployment/lifecycle or cycle-trailing
>>> projects.
>>>
>>> Ideally this policy could get adopted by any such project. The
>>> discussion started on the review and it's going well, so let's see where
>>> it goes :)
>>
>> Thierry, when I read your comment on Gerrit I understand you prefer to
>> amend the existing policy and just make a note for installers (which
>> is I think the option #2 that I proposed). Can you please confirm
>> that?
>> So far I see option #1 has large consensus here, I'll wait for
>> Thierry's answer to continue to work on it.
>>
>> Thanks for the feedback so far!
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [release][ptl] Releases repo frozen

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-10-17 10:37:25 -0500:
> Just a heads up that the releases repo is frozen while we work through some
> zuul v3 migration issues. Jobs are passing, but some of the important
> post-release processing that needs to happen will require a little more
> tinkering to get right.
> 
> Feel free to propose release patches, but just know that we will not be able 
> to
> process any of them until these issues are resolved.
> 
> Sorry for any inconvenience.
> 
> Sean (smcginnis)
> 

We're starting to have folks ask for releases. The jobs are still not
passing 100% of the time, so the release team is running the releases
carefully so we can watch for failures and deal with them immediately.
Please continue to be patient; we promise we'll get to your releases as
soon as possible.

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] [publiccloud-wg] Reminder meeting PublicCloud WG

[Tobias Rydberg]

Hi everyone,

Don't forget tomorrows meeting for the PublicCloudWorkingGroup.
November 25th 1400 UTC  in IRC channel 
#openstack-meeting-3


Etherpad and agenda: https://etherpad.openstack.org/p/publiccloud-wg

Regards,
Tobias Rydberg


smime.p7s
Description: S/MIME Cryptographic 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] [ceilometer] the workload partition will cause consumer disappeared

[gordon chung]

On 2017-10-23 09:57 PM, 李田清 wrote:
>       We test ceilometer workload partition, and find even with one 
> rabbitmq server, the ceilometer-pipe
>       will lost its consumers. Does anyone know this?
>       I configure, batch_size =1, batch_timeout =1, 
> and pipeline_processing_queues = 1.
>       If anyone know this, please point it out. Thanks
and you see no errors in notification-agent? does it start with a 
consumer or is there never a consumer?

are you setting pipeline_processing_queues=1 as a test? because it sort 
of defeats purpose.

cheers,

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

Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Jeremy Stanley]

On 2017-10-24 11:31:56 -0700 (-0700), Armando M. wrote:
[...]
> the work on neutron-lib is slowly progressing but it's not close enough to
> allow us to break the dependency that requires neutron sub-projects to add
> neutron to the list of required-projects (which I believe the sort of the
> error in the release pipeline stems from).
[...]

It's not entirely clear to me what about a Neutron plug-in would
actually require the neutron source installed just to be able to
generate a tarball (or wheel) or build sphinx docs. Couldn't that be
solved even if things like installation or unit testing still
continue to need neutron?
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] [all] TC Report 43

[Clay Gerrard]

On Tue, Oct 24, 2017 at 11:26 AM, Chris Dent  wrote:

>
>
> Since this is the second [week in a
> row](https://anticdent.org/tc-report-42.html) that Josh showed up with
> an idea, I wonder what next week will bring?
>
>
^ That's pretty cool.  Thanks for sending this as always Chris.

-Clay
__
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] [policy] AWS IAM session

[Lance Bragstad]

Gentle reminder that this will be happening tomorrow. See you then!

On 10/20/2017 09:46 AM, Lance Bragstad wrote:
> I just sent a calendar invite to everyone who responded to this thread
> or voted in the agenda. The session will be recorded if you are unable
> to make it.
>
> Thanks!
>
> On 10/18/2017 10:10 AM, Lance Bragstad wrote:
>> Now that we have some good feedback on the doodle, it looks like we
>> have two sessions that will work for everyone. One is October 25th
>> from 15:00 - 16:00 UTC and the other is also the 25th from 16:00 - 17:00.
>>
>> Let's shoot to meet at *15:00 UTC* on *October 25th* and if the
>> meeting goes over, we have time allocated for that. Would anyone like
>> a formal calendar invite? If so, I can send one out. The etherpad [0]
>> will act as our "schedule", but we'll likely just work through the
>> cases we've documented.
>>
>> Thanks!
>>
>> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
>>
>>
>> On 10/16/2017 08:45 AM, Lance Bragstad wrote:
>>> Sending out a gentle reminder to vote for time slots that work for
>>> you [0]. We'll keep the poll open for a few more days, or until we
>>> reach quorum. Thanks!
>>>
>>> [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu
>>>
>>> On 10/11/2017 01:48 PM, Lance Bragstad wrote:
 Oh - one note about the doodle [0]. All proposed times are in UTC,
 so just keep that in mind when selecting your availability.

 Thanks!

 [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu

 On 10/11/2017 01:44 PM, Lance Bragstad wrote:
> In today's policy meeting we went through and started prepping for
> the session. Relevant information has been captured in the
> etherpad [0].
>
> We're going to hold the meeting using *Google* *Hangouts*. I'll
> update the etherpad with a link to the hangout once we settle on a
> date. If you plan on attending, please *vote* *for* *available*
> *times* [1]. I've proposed a bunch of time slots (4 each day for
> the next two weeks) to try and find a time that works for
> everyone. People from US, AU, and EU will be trying to attended,
> so we're not going to find a perfect time for everyone. Having
> said that, *we're going to record the session*.
>
> Most of what we talked about in the meeting today uncovered the
> need to go over the basics of AWS IAM. That should be something we
> can do with a free account, which I'm going to sign up for. If we
> need more time we can have another session or look at options for
> upgrading the account.
>
>
> [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
> [1] https://doodle.com/poll/ntkpzgmcv3k6v5qu
>
> On 10/09/2017 04:23 PM, Lance Bragstad wrote:
>> I've put a scheduling session on the books for the next policy
>> meeting [0][1]. Advertising it here since folks who want to be
>> involved have responded to the thread.
>>
>> Let's use this meeting time to iron out account details and
>> figure out what exactly we want to get out of the session.
>>
>>
>> [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
>> [1] https://etherpad.openstack.org/p/keystone-policy-meeting
>>
>> On 10/05/2017 02:24 AM, Colleen Murphy wrote:
>>> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad
>>> mailto:lbrags...@gmail.com>> wrote:
>>>
>>> Hey all,
>>>
>>> It was mentioned in today's keystone meeting [0] that it
>>> would be useful
>>> to go through AWS IAM (or even GKE) as a group. With all the
>>> recent
>>> policy discussions and work, it seems useful to get our eyes
>>> on another
>>> system. The idea would be to spend time using a video
>>> conference/screen
>>> share to go through and play with policy together. The end
>>> result should
>>> keep us focused on the implementations we're working on
>>> today, but also
>>> provide clarity for the long-term vision of OpenStack's RBAC
>>> system.
>>>
>>> Are you interested in attending? If so, please respond to
>>> the thread.
>>> Once we have some interest, we can gauge when to hold the
>>> meeting, which
>>> tools we can use, and setting up a test IAM account.
>>>
>>> Thanks,
>>>
>>> Lance
>>>
>>> [0]
>>> 
>>> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
>>> 
>>> 
>>>
>>> Please count me in.
>>>
>>> Colleen
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org

[openstack-dev] [keystone] Queens-1 Retrospective

[Lance Bragstad]

Hey all,

We're going to hold our queens-1 retrospective next week during the
keystone weekly meeting [0]. All information for the retro can be found
in Trello [1].

Thanks!

[0] http://eavesdrop.openstack.org/#Keystone_Team_Meeting
[1] https://trello.com/c/gVMeyWIK/60-schedule-queens-1-retrospective




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

Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Armando M.]

On 24 October 2017 at 10:35, Doug Hellmann  wrote:

> Excerpts from Jeremy Stanley's message of 2017-10-24 15:05:34 +:
> > On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> > > It looks like the publish-to-pypi-neutron template modifies
> > > publish-to-pypi by adding openstack/neutron to the
> required-repositories
> > > list for the release-openstack-python job. That repository was also at
> > > some point added directly to the release-openstack-python job. So
> > > technically the extension via the template is not needed. The same
> > > applies to publish-to-pypi-horizon.
> > [...]
> >
> > Both are stop-gap solutions and I think either is fine in the short
> > term to get us through the bulk of the release request backlog.
> > Longer term we want to have neither of those. Python projects should
> > be able to build sdists/wheels[1], documentation[2] and release
> > notes[3] without tox (a behavior change which significantly
> > complicates preinstalling source code from other projects, so best
> > if their release jobs simply don't rely on doing that at all).
> >
> > > As we find other projects with more dependencies, we're going to
> > > end up with more custom templates.
> > [...]
> >
> > If we do, this only accelerates the need for something like a
> > community goal for fixing this in those respective Python
> > plugin/extension projects.
>
> Right. I know the neutron team has been working on their library system
> for quite a while. Maybe someone can report on the progress there?
>

the work on neutron-lib is slowly progressing but it's not close enough to
allow us to break the dependency that requires neutron sub-projects to add
neutron to the list of required-projects (which I believe the sort of the
error in the release pipeline stems from).


>
> I don't know if the horizon team is working on that (I'm just uninformed
> about what they're doing). So maybe someone from that team can comment?
>
> >
> > > One alternative to keeping multiple variants, and defining more in
> > > the future, is to add required-repositories to the
> release-openstack-python
> > > job directly, as we discover they are needed. Of course that means
> > > we will clone repositories for some jobs that don't actually use
> > > them. I don't know how big of an issue that really is, but the issue
> > > of not knowing which instances of a job actually need a particular
> > > dependency seems like more of a justification for keeping separate
> > > templates than any runtime savings we would have by skipping a
> > > couple of extra calls to git clone.
> > [...]
> >
> > Well, in this case you're talking about Zuul needing to calculate
> > merge states for the neutron and horizon repos and then push these
> > into every build of the affected jobs, which is no small amount of
> > overhead on its own given the size of those particular repos. Also,
> > once the tox-siblings role[4] is back in action (likely later this
> > week?) Zuul will go back to preinstalling any required-projects from
> > source into tox virtualenvs for these jobs, which is quite a bit
> > more overhead still at that point.
>
> Yes, we don't want that, so I think that means we want to retain the
> multiple project templates for the short-term.


> >
> > [1] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2678231
> > [2] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=2c0cdd2
> > [3] http://git.openstack.org/cgit/openstack/governance/commit/?
> id=df438a7
> > [4] http://git.openstack.org/cgit/openstack-infra/zuul-jobs/
> tree/roles/tox-siblings
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] [all] TC Report 43

[Chris Dent]

# Welcome New TC Members

Main news to report about the OpenStack Technical Committee (TC) is that
the elections have finished and there are some new members. The three
incumbents that ran returned for another year, meaning three new
people join. There's more information in a [superuser
article](http://superuser.openstack.org/articles/openstack-tc-pike-elections/).
Welcome and congratulations to everyone.

After each election a new chair is selected. Any member of the TC may
be the chair, self-nomination is done by posting a review. The traditional
chair, Thierry, has posted [his
nomination](https://review.openstack.org/#/c/514553/1).

A [welcome
message](http://lists.openstack.org/pipermail/openstack-tc/2017-October/001477.html)
was posted to the TC mailing list with information and references for
how things work.

# TC Participation

At last Thursday's [office
hours](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-19.log.html#t2017-10-19T15:01:02)
Emilien asked, as a thought experiment, what people thought of the
idea of TC term limits. In typical office hours fashion, this quickly
went off into a variety of topics, some only tangentially related to
term limits.

To summarize, incompletely, the pro-reason is: Make room and
opportunities for new leadership. The con-reason is: Maintain a degree
of continuity.

This led to some discussion of the value of "history and baggage" and
whether such things are a keel or anchor in managing the nautical
metaphor of OpenStack. We did not agree, which is probably good
because somewhere in the middle is likely true.

Things then circled back to the nature of the TC: court of last resort
or something with a more active role in executive leadership. If the former,
who does the latter? Many questions related to significant change are
never resolved because it is not clear who does these things.

There's a camp that says "the people who step up to do it". In my experience
this is a statement made by people in a position of privilege and may
(intentionally or otherwise) exclude others or lead to results which have
unintended consequences.

This then led to meandering about the nature of facilitation.

(Like I said, a variety of topics.)

We did not resolve these questions except to confirm that the only way
to address these things is to engage with not just the discussion, but
also the work.

# OpenStack Technical Blog

Josh Harlow showed up with [an
idea](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-19.log.html#t2017-10-19T18:19:30).
An OpenStack equivalent of the [kubernetes
blog](http://blog.kubernetes.io/), focused on interesting technology
in OpenStack. This came up again on
[Friday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-20.log.html#t2017-10-20T18:13:01).

It's clear that anyone and everyone _could_ write their own blogs and
syndicate to the [OpenStack planet](http://planet.openstack.org/) but
this doesn't have the same panache and potential cadence as an
official thing _might_. It comes down to people having the time. Eking
out the time for this blog, for example, can be challenging.

Since this is the second [week in a
row](https://anticdent.org/tc-report-42.html) that Josh showed up with
an idea, I wonder what next week will bring?

--
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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-10-24 15:05:34 +:
> On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > It looks like the publish-to-pypi-neutron template modifies
> > publish-to-pypi by adding openstack/neutron to the required-repositories
> > list for the release-openstack-python job. That repository was also at
> > some point added directly to the release-openstack-python job. So
> > technically the extension via the template is not needed. The same
> > applies to publish-to-pypi-horizon.
> [...]
> 
> Both are stop-gap solutions and I think either is fine in the short
> term to get us through the bulk of the release request backlog.
> Longer term we want to have neither of those. Python projects should
> be able to build sdists/wheels[1], documentation[2] and release
> notes[3] without tox (a behavior change which significantly
> complicates preinstalling source code from other projects, so best
> if their release jobs simply don't rely on doing that at all).
> 
> > As we find other projects with more dependencies, we're going to
> > end up with more custom templates.
> [...]
> 
> If we do, this only accelerates the need for something like a
> community goal for fixing this in those respective Python
> plugin/extension projects.

Right. I know the neutron team has been working on their library system
for quite a while. Maybe someone can report on the progress there?

I don't know if the horizon team is working on that (I'm just uninformed
about what they're doing). So maybe someone from that team can comment?

> 
> > One alternative to keeping multiple variants, and defining more in
> > the future, is to add required-repositories to the release-openstack-python
> > job directly, as we discover they are needed. Of course that means
> > we will clone repositories for some jobs that don't actually use
> > them. I don't know how big of an issue that really is, but the issue
> > of not knowing which instances of a job actually need a particular
> > dependency seems like more of a justification for keeping separate
> > templates than any runtime savings we would have by skipping a
> > couple of extra calls to git clone.
> [...]
> 
> Well, in this case you're talking about Zuul needing to calculate
> merge states for the neutron and horizon repos and then push these
> into every build of the affected jobs, which is no small amount of
> overhead on its own given the size of those particular repos. Also,
> once the tox-siblings role[4] is back in action (likely later this
> week?) Zuul will go back to preinstalling any required-projects from
> source into tox virtualenvs for these jobs, which is quite a bit
> more overhead still at that point.

Yes, we don't want that, so I think that means we want to retain the
multiple project templates for the short-term.

> 
> [1] http://git.openstack.org/cgit/openstack/governance/commit/?id=2678231
> [2] http://git.openstack.org/cgit/openstack/governance/commit/?id=2c0cdd2
> [3] http://git.openstack.org/cgit/openstack/governance/commit/?id=df438a7
> [4] 
> http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/tox-siblings

__
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] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

Sigh, sorry. I forgot that we're moving back to winter time this weekend. I 
*think* the time is 3pm UTC then. It seems to be 11am eastern US: 
https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15&p1=37&p2=tz_et.


On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

And the winner is Mon, 30 Oct, 2pm UTC!

The bluejeans ID is https://bluejeans.com/757528759
(works without plugins in recent FF and Chrome; if it asks to install an app, 
ignore it and look for a link saying "join with browser")


On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

Hi all!

I'd like to invite you to the discussion of the way to implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.

Note that it's going to be a technical discussion - please make sure you
understand what traits are and why ironic cares about them. See below for more
context.

We'll probably use my bluejeans account, as it works without plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:

We discussed this a little bit further in IRC [1].  We're all in
agreement, but it's worth being precise on a couple of points:

* We're distinguishing between a "feature" and the "trait" that
represents it in placement.  For the sake of this discussion, a
"feature" can (maybe) be switched on or off, but a "trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
    * If it can be done by virt at spawn time, then it makes sense to have
the trait on the RP, and you can switch the feature on/off via a
separate extra_spec.
    * But if it's e.g. an admin action, and spawn has no control, then the
trait needs to be *added* whenever the feature is *on*, and *removed*
whenever the feature is *off*.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13 



On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried mailto:openst...@fried.cc>> wrote:

  I agree with Sean.  In general terms:

  * A resource provider should be marked with a trait if that feature
    * Can be turned on or off (whether it's currently on or not); or
    * Is always on and can't ever be turned off.


No, traits are not boolean. If a resource provider stops providing a
capability, then the existing related trait should just be removed,
that's it.
If you see a trait, that's just means that the related capability for
the Resource Provider is supported, that's it too.

MHO.

-Sylvain



  * A consumer wanting that feature present (doesn't matter whether it's
  on or off) should specify it as a required *trait*.
  * A consumer wanting that feature present and turned on should
    * Specify it as a required trait; AND
    * Indicate that it be turned on via some other mechanism (e.g. a
  separate extra_spec).

  I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
  for placement purity.

  Please invite me to the hangout or whatever.

  Thanks,
  Eric

  On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
  >
  >
  >
  >
  > *From:*Jay Pipes [mailto:jaypi...@gmail.com
  ]
  > *Sent:* Monday, October 23, 2017 12:20 PM
  > *To:* OpenStack Development Mailing List
  mailto:openstack-dev@lists.openstack.org>>
  > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
  >
  >
  >
  > Writing from my phone... May I ask that before you proceed with any 
plan

  > that uses traits for state information that we have a hangout or
  > videoconference to discuss this? Unfortunately today and tomorrow I'm
  > not able to do a hangout but I can do one on Wednesday any time of 
the day.

  >
  >
  >
  > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
  ptg that
  > we wanted to standardizes tratis for “verified boot” /*
  >
  > */that included a trait for uefi secure boot enabled and to
  indicated a
  > hardware root of trust, e.g. intel boot guard or similar/*
  >
  > */we distinctly wanted to be able to tag nova compute hosts with those
  > new traits so we could require that vms that request/*
  >
  > */a host with uefi secure boot enabled and a hardware root of
  trust are
  > scheduled only to those nodes. /*
  >
  > */ /*
  >
  > */There are many other examples that effect both vms and bare
  metal such
  > as, ecc/interleaved memory, cluster on die, /*
  >
  > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
  > threading, power states … all of these feature may be present on the
  > platform/*
  >
  > */but I also need to know if they are turned on. Ruling out state in
  > traits means all o

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

And the winner is Mon, 30 Oct, 2pm UTC!

The bluejeans ID is https://bluejeans.com/757528759
(works without plugins in recent FF and Chrome; if it asks to install an app, 
ignore it and look for a link saying "join with browser")


On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

Hi all!

I'd like to invite you to the discussion of the way to implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.

Note that it's going to be a technical discussion - please make sure you
understand what traits are and why ironic cares about them. See below for more
context.

We'll probably use my bluejeans account, as it works without plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:

We discussed this a little bit further in IRC [1].  We're all in
agreement, but it's worth being precise on a couple of points:

* We're distinguishing between a "feature" and the "trait" that
represents it in placement.  For the sake of this discussion, a
"feature" can (maybe) be switched on or off, but a "trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
* If it can be done by virt at spawn time, then it makes sense to have
the trait on the RP, and you can switch the feature on/off via a
separate extra_spec.
* But if it's e.g. an admin action, and spawn has no control, then the
trait needs to be *added* whenever the feature is *on*, and *removed*
whenever the feature is *off*.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13

On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried mailto:openst...@fried.cc>> wrote:

  I agree with Sean.  In general terms:

  * A resource provider should be marked with a trait if that feature
* Can be turned on or off (whether it's currently on or not); or
* Is always on and can't ever be turned off.


No, traits are not boolean. If a resource provider stops providing a
capability, then the existing related trait should just be removed,
that's it.
If you see a trait, that's just means that the related capability for
the Resource Provider is supported, that's it too.

MHO.

-Sylvain



  * A consumer wanting that feature present (doesn't matter whether it's
  on or off) should specify it as a required *trait*.
  * A consumer wanting that feature present and turned on should
* Specify it as a required trait; AND
* Indicate that it be turned on via some other mechanism (e.g. a
  separate extra_spec).

  I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
  for placement purity.

  Please invite me to the hangout or whatever.

  Thanks,
  Eric

  On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
  >
  >
  >
  >
  > *From:*Jay Pipes [mailto:jaypi...@gmail.com
  ]
  > *Sent:* Monday, October 23, 2017 12:20 PM
  > *To:* OpenStack Development Mailing List
  mailto:openstack-dev@lists.openstack.org>>
  > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
  >
  >
  >
  > Writing from my phone... May I ask that before you proceed with any plan
  > that uses traits for state information that we have a hangout or
  > videoconference to discuss this? Unfortunately today and tomorrow I'm
  > not able to do a hangout but I can do one on Wednesday any time of the 
day.
  >
  >
  >
  > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
  ptg that
  > we wanted to standardizes tratis for “verified boot” /*
  >
  > */that included a trait for uefi secure boot enabled and to
  indicated a
  > hardware root of trust, e.g. intel boot guard or similar/*
  >
  > */we distinctly wanted to be able to tag nova compute hosts with those
  > new traits so we could require that vms that request/*
  >
  > */a host with uefi secure boot enabled and a hardware root of
  trust are
  > scheduled only to those nodes. /*
  >
  > */ /*
  >
  > */There are many other examples that effect both vms and bare
  metal such
  > as, ecc/interleaved memory, cluster on die, /*
  >
  > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
  > threading, power states … all of these feature may be present on the
  > platform/*
  >
  > */but I also need to know if they are turned on. Ruling out state in
  > traits means all of this logic will eventually get pushed to scheduler
  > filters/*
  >
  > */which will be suboptimal long term as more state is tracked.
  Software
  > defined infrastructure may be the future but hardware defined
  software/*
  >
  > */is sadly the prese

Re: [openstack-dev] [TripleO] Deployment workflow changes for ui/client

[Emilien Macchi]

On Tue, Oct 24, 2017 at 8:16 AM, James Slagle  wrote:
> On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek  wrote:
>> Having a workflow which wraps whole deployment sounds great from the UI side
>> too as it allows us to simplify the steps you described above. IIRC the
>> reason the whole deployment did not get wrapped into a single workflow
>> before is that the workflow/tasks timeouted before the deployment could
>> finish which caused the workflow to fail.
>>
>> It should not be problematic to integrate these changes in GUI. The soon we
>> can test it the better. As Brad noted, it is important to get as many Zaqar
>> messages as possible so we can track the progress properly.
>
> Thanks :). Sounds like at least the 3 of us, are in general agreement
> about moving more towards wrapping all the deployment logic into a
> single workflow, or as few workflows as possible. Doing so will reduce
> the amount of logic we have to do client side and in the UI.
>
> That being said...as I started to look in that direction, I realized
> it is a lot of work to get us there, even if we did just enough to
> support using config-download. I feel like such an effort should
> probably be tracked in its own blueprint and properly scoped so that
> the risk is well understood. I'd estimate it to be fairly disruptive
> given the amount of changes needed in the clients and workflows.
>
> To that end, I'm proposing we push such an effort off to Rocky, given
> we already passed Queens-1.

+1, let's make iterations and config-download seems an excellent one.

> For config-download for Queens, I've proposed the following as an
> alternative solution:
>
> https://review.openstack.org/#/c/514701/ (python-tripleoclient)
> https://review.openstack.org/#/c/512876/ (tripleo-common)
>
> I think it's fairly simple with low risk and it just follows the
> existing pattern of calling an additional workflow to add
> functionality. If we're happy with where we get to in queens with
> config-download, we could consider making it the default.

We'll give feedback in the review.

Thanks James for this update,
-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo] Tripleo CI Community meeting tomorrow

[Emilien Macchi]

On Tue, Oct 24, 2017 at 8:50 AM, Arx Cruz  wrote:
> Hello
>
> We are going to have a TripleO CI Community meeting tomorrow 10/25/2017 at 1
> pm UTC time.
> The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
> channel.
>
> After that, we will hold Office Hours starting at 4PM UTC in case someone
> from community have any questions related to CI.
>
> Hope to see you there.
>
> 1 - https://bluejeans.com/7071866728
>
>
> Kind regards,
> Arx Cruz

quick question, is it a regular time or will it change in the future?

(so I can update my calendar)

Thanks,
-- 
Emilien Macchi

__
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] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 10/25/2017 at
1 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
 channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/7071866728



Kind regards,
Arx Cruz
__
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] [FEMDC] Wed. 25. IRC Meeting 15:00 UTC

[Alexandre van Kempen]

Dear all, 

A gentle reminder for our tomorrow meeting at 15:00 UTC 

A draft agenda is available at line 1413, you are very welcome to add any item.
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 


Best,

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

Re: [openstack-dev] [TripleO] Deployment workflow changes for ui/client

[James Slagle]

On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek  wrote:
> Having a workflow which wraps whole deployment sounds great from the UI side
> too as it allows us to simplify the steps you described above. IIRC the
> reason the whole deployment did not get wrapped into a single workflow
> before is that the workflow/tasks timeouted before the deployment could
> finish which caused the workflow to fail.
>
> It should not be problematic to integrate these changes in GUI. The soon we
> can test it the better. As Brad noted, it is important to get as many Zaqar
> messages as possible so we can track the progress properly.

Thanks :). Sounds like at least the 3 of us, are in general agreement
about moving more towards wrapping all the deployment logic into a
single workflow, or as few workflows as possible. Doing so will reduce
the amount of logic we have to do client side and in the UI.

That being said...as I started to look in that direction, I realized
it is a lot of work to get us there, even if we did just enough to
support using config-download. I feel like such an effort should
probably be tracked in its own blueprint and properly scoped so that
the risk is well understood. I'd estimate it to be fairly disruptive
given the amount of changes needed in the clients and workflows.

To that end, I'm proposing we push such an effort off to Rocky, given
we already passed Queens-1.

For config-download for Queens, I've proposed the following as an
alternative solution:

https://review.openstack.org/#/c/514701/ (python-tripleoclient)
https://review.openstack.org/#/c/512876/ (tripleo-common)

I think it's fairly simple with low risk and it just follows the
existing pattern of calling an additional workflow to add
functionality. If we're happy with where we get to in queens with
config-download, we could consider making it the default.

-- 
-- 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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Jeremy Stanley]

On 2017-10-24 09:42:25 -0400 (-0400), Doug Hellmann wrote:
[...]
> It looks like the publish-to-pypi-neutron template modifies
> publish-to-pypi by adding openstack/neutron to the required-repositories
> list for the release-openstack-python job. That repository was also at
> some point added directly to the release-openstack-python job. So
> technically the extension via the template is not needed. The same
> applies to publish-to-pypi-horizon.
[...]

Both are stop-gap solutions and I think either is fine in the short
term to get us through the bulk of the release request backlog.
Longer term we want to have neither of those. Python projects should
be able to build sdists/wheels[1], documentation[2] and release
notes[3] without tox (a behavior change which significantly
complicates preinstalling source code from other projects, so best
if their release jobs simply don't rely on doing that at all).

> As we find other projects with more dependencies, we're going to
> end up with more custom templates.
[...]

If we do, this only accelerates the need for something like a
community goal for fixing this in those respective Python
plugin/extension projects.

> One alternative to keeping multiple variants, and defining more in
> the future, is to add required-repositories to the release-openstack-python
> job directly, as we discover they are needed. Of course that means
> we will clone repositories for some jobs that don't actually use
> them. I don't know how big of an issue that really is, but the issue
> of not knowing which instances of a job actually need a particular
> dependency seems like more of a justification for keeping separate
> templates than any runtime savings we would have by skipping a
> couple of extra calls to git clone.
[...]

Well, in this case you're talking about Zuul needing to calculate
merge states for the neutron and horizon repos and then push these
into every build of the affected jobs, which is no small amount of
overhead on its own given the size of those particular repos. Also,
once the tox-siblings role[4] is back in action (likely later this
week?) Zuul will go back to preinstalling any required-projects from
source into tox virtualenvs for these jobs, which is quite a bit
more overhead still at that point.

[1] http://git.openstack.org/cgit/openstack/governance/commit/?id=2678231
[2] http://git.openstack.org/cgit/openstack/governance/commit/?id=2c0cdd2
[3] http://git.openstack.org/cgit/openstack/governance/commit/?id=df438a7
[4] 
http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/tox-siblings
-- 
Jeremy Stanley


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

Re: [openstack-dev] [gnocchi] Redis for storage backend

[Yaguang Tang]

Hi Gordon，

Thanks for your test results， we investigate more on our env, finally it
turns out that our ceph cluster isn't work as expected.
which made gnocchi performance decrease a lot.

On Thu, Oct 19, 2017 at 1:09 AM, gordon chung  wrote:

>
>
> On 2017-10-18 12:15 PM, Yaguang Tang wrote:
> >
> > We launched 300vms and each vm has about 10 metrics, OpenStack cluster
> > have 3 controllers and 2 compute nodes(ceph replication is set to 2).
>
> seems smaller than my test, i have 20K metrics in my test
>
> >
> > what we want to archive is to make all metric measures data get
> > processed as soon as possible, metric processing delay is set to 10s,
> > and ceilometer polling interval is 30s.
>
> are you batching the data you push to gnocchi? in gnocchi4.1, the redis
> driver will (attempt to) process immediately, rather than cyclically
> using the metric processing delay.
>
> >
> > when the backend of incoming and storeage is set to ceph, the average of
> > "gnocchi status"
> > shows that there are around 7000 measures waiting to be process, but
> > when changing incoming and storage backend to Redis, the result of
> > gnocchi status shows unprocessed measures is around 200.
>
> i should clarify, having a high gnocchi status is not a bad thing, ie,
> if you just send a large spike of measures, it's expected to jump. it's
> bad if never shrinks.
>
> that said, how many workers do you have? i have 18 workers for 20K
> metrics and it takes 2minutes i believe? do you have debug enable? how
> long does it take to process metric?
>
> when i tested gnocchi+ceph vs gnocchi+redis, i didn't see a very large
> difference in performance (redis was definitely better though). maybe
> it's your ceph environment?
>
> >
> > we try to add more metricd process on every controller nodes, to improve
> > the performance of
> > calculate and writing speed to storage backend but  have little effect.
>
> performance should increase (relatively) proportionally. ie. if you 2x
> metricd, you should perform (almost) 2x quicker. if you add 5% more
> metricd, you should perform (almost) 5% quicker.
>
> cheers,
>
> --
> gord
> __
> 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
>



-- 
Tang Yaguang
__
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][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Tue, Oct 24, 2017 at 1:47 PM, Thierry Carrez 
wrote:

> Colleen Murphy wrote:
> > On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke
> > mailto:diana.joan.cla...@gmail.com>>
> wrote:
> >
> > Congrats on being elected to the TC, Colleen!
> >
> > You mentioned earlier in this thread that, "a major problem in the
> > tech world is not just attracting underrepresented contributors, but
> > retaining them".
> >
> > I'm curious if the TC has considered polling the people that have
> left
> > OpenStack for their experiences on this front.
> >
> > Something along the lines of:
> >
> > "I see you contributed 20 patches in the last cycle, but haven't
> > contributed recently, why did you stop contributing?".
> >
> > Given the recent layoffs, I suspect many of the responses will be
> > predicable, but you might find some worthwhile nuggets there
> > nonetheless.
> >
> > I'm not aware of such an initiative so far but I do think it would be
> > useful, and perhaps something we can partner with the foundation on.
>
> Kind of parallel to the polling idea:
>
> John Dickinson has some interesting scripts that he runs to detect
> deviation from a past contribution pattern (like someone who used to
> contribute a few patches per cycle but did not contribute anything over
> the past cycle, or someone who used to contribute a handful of patches
> per month who did not send a single patch over the past month). Once
> oddities in the contribution pattern are detected, he would contact the
> person to ask if anything happened or changed that made them stop
> contributing.
>
> John would probably describe it better than I did. I like that it's not
> just quantitative but more around deviation from an established
> contribution pattern, which lets him spot issues earlier.
>
It's great to hear that something like this already exists.

>
> Note that this sort of analysis works well when combined with personal
> outreach, which works better at project team level... If done at
> OpenStack level you would likely have more difficulty making it feel
> personal (if I end up reaching out to a Tacker dev that stopped
> contributing, it won't be as effective as if the Tacker PTL did the
> outreach).

That's a really good point, but I would counter that in certain
circumstances this might not result in the most honest answers, if for
example the reason for leaving was due to personal problems with the PTL or
someone in the team leadership.

Even with a personalized outreach approach, I think it's important that the
data be recorded centrally so it can be analyzed across the various teams
for trends.

> One thing we could do would be to productize those tools and
> make them available to a wider number of people.
>
++

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

[openstack-dev] [os-vif] [nova] Changes to os-vif cores

[Stephen Finucane]

Hey,

I'm not actually sure what the protocol is for adding/removing cores to a
library project without a PTL, so I'm just going to put this out there: I'd
like to propose the following changes to the os-vif core team.

- Add 'nova-core'

  os-vif makes extensive use of objects and we've had a few hiccups around
  versionings and the likes recently [1][2]. I'd the expertise of some of the
  other nova cores here as we roll this out to projects other than nova, and I
  trust those not interested/knowledgeable in this area to stay away :)

- Remove Russell Bryant, Maxime Leroy

  These folks haven't been active on os-vif  [3][4] for a long time and I think
  they can be safely removed.

To the existing core team members, please respond with a yay/nay and we'll wait
a week before doing anything.

Cheers,
Stephen

[1] https://review.openstack.org/#/c/508498/
[2] https://review.openstack.org/#/c/509107/
[3] https://review.openstack.org/#/q/reviewedby:%22Russell+Bryant+%253Crbryant%
2540redhat.com%253E%22+project:openstack/os-vif
[4] https://review.openstack.org/#/q/reviewedby:%22Maxime+Leroy+%253Cmaxime.ler
oy%25406wind.com%253E%22+project:openstack/os-vif

__
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] [oslo][bilean][cue][poppy] Remove the parameter enforce_type from set_override and set_default

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-10-24 14:27:11 +0800:
> We plan to remove  the parameter enforce_type from set_override and
> set_default  in oslo.config [1].  we have been blocking  its usage in
> bilean, cue, poppy for a long time. patchs were posted in these projects
> [2][3][4].   What we can do next, Just remove the Depends-On and go ahead
> in oslo side ? or push reviewers of these projects.
> 
> 
> [1] https://review.openstack.org/#/c/503181/
> [2]https://review.openstack.org/#/c/503199/
> [3]https://review.openstack.org/#/c/503236/
> [4] https://review.openstack.org/#/c/503249/

Based on recent contribution levels, I think we can ignore all three of
those projects.

Bilean:
http://stackalytics.com/?release=pike&module=bilean&metric=commits

Cue:
http://stackalytics.com/?release=all&metric=commits&module=cue-group

Poppy: http://stackalytics.com/?release=all&metric=commits&module=poppy

I suggest we remove the depends-on, leave the patches in those projects
up for review, and move ahead.

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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-10-24 13:47:32 +0200:
> Colleen Murphy wrote:
> > On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke
> > mailto:diana.joan.cla...@gmail.com>> wrote:
> > 
> > Congrats on being elected to the TC, Colleen!
> > 
> > You mentioned earlier in this thread that, "a major problem in the
> > tech world is not just attracting underrepresented contributors, but
> > retaining them".
> > 
> > I'm curious if the TC has considered polling the people that have left
> > OpenStack for their experiences on this front.
> > 
> > Something along the lines of:
> > 
> >     "I see you contributed 20 patches in the last cycle, but haven't
> > contributed recently, why did you stop contributing?".
> > 
> > Given the recent layoffs, I suspect many of the responses will be
> > predicable, but you might find some worthwhile nuggets there
> > nonetheless.
> > 
> > I'm not aware of such an initiative so far but I do think it would be
> > useful, and perhaps something we can partner with the foundation on.
> 
> Kind of parallel to the polling idea:
> 
> John Dickinson has some interesting scripts that he runs to detect
> deviation from a past contribution pattern (like someone who used to
> contribute a few patches per cycle but did not contribute anything over
> the past cycle, or someone who used to contribute a handful of patches
> per month who did not send a single patch over the past month). Once
> oddities in the contribution pattern are detected, he would contact the
> person to ask if anything happened or changed that made them stop
> contributing.
> 
> John would probably describe it better than I did. I like that it's not
> just quantitative but more around deviation from an established
> contribution pattern, which lets him spot issues earlier.
> 
> Note that this sort of analysis works well when combined with personal
> outreach, which works better at project team level... If done at
> OpenStack level you would likely have more difficulty making it feel
> personal (if I end up reaching out to a Tacker dev that stopped
> contributing, it won't be as effective as if the Tacker PTL did the
> outreach). One thing we could do would be to productize those tools and
> make them available to a wider number of people.
> 

Yes, any tools that we can use to produce real data to inform an
outreach program would be useful.

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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Davanum Srinivas]

Please see below:

On Tue, Oct 24, 2017 at 10:11 AM, Thierry Carrez  wrote:
> Doug Hellmann wrote:
>> [...]
>> It feels like we have two related by not necessarily dependent
>> policy questions we need to answer before we decide how to proceed:
>
> I don't have strong opinions on any of those two, I think anything would
> work. If I had to pick between yes and no, here is my gut feeling:
>
>> (a) Do we want to move the release job definitions from project-config
>> and openstack-zuul-jobs to the releases repo?
>
> Leaning towards yes as it will (imho) simplify maintenance. We'll still
> have a couple of privileged jobs that will live on the infra side though?

Agree with Thierry.

>> (b) Do we want to have multiple release job templates due to custom
>> dependencies (or any other reason)?
>
> Leaning towards no if we can avoid it, again to simplify operations.
> That said, it will be difficult to enforce...

Same. Let's start without it and revisit if we need them later.

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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Sean McGinnis]

On Tue, Oct 24, 2017 at 09:42:25AM -0400, Doug Hellmann wrote:
> The neutron queens milestone release is held up right now because
> some of the repositories are using a release job template that isn't
> recognized by the validation code in the releases repository.  I'm
> trying to decide between adding the custom job template to the
> validation code or changing the release jobs for those neutron
> repositories to use the one that isn't custom. I think we'll have
> the same problem with horizon plugins using the custom job template
> set up for them.
> 
> It looks like the publish-to-pypi-neutron template modifies
> publish-to-pypi by adding openstack/neutron to the required-repositories
> list for the release-openstack-python job. That repository was also at
> some point added directly to the release-openstack-python job. So
> technically the extension via the template is not needed. The same
> applies to publish-to-pypi-horizon.
> 
> I see a few issues with keeping job template variants:
> 
> 1. Having multiple release job variants complicates the release
>repo validation logic. That logic was put in place after we
>discovered several projects without release jobs defined at all,
>so we definitely want to keep some level of validation in place.
> 
> 2. As we continue to make changes to the release jobs, we're going
>to have to consider whether to make those changes in multiple
>places, which seems error prone.

This is my big concern. Chances are very likely things will get missed.

> 
> 3. As we find other projects with more dependencies, we're going
>to end up with more custom templates.
> 
> Those issues may be mitigated if we move the release job definitions
> into the releases repo as we have discussed, because it will be
> more obvious that we have multiple related templates that are
> variants of one another and we can make the relevant changes all
> together in one patch.
> 
> One alternative to keeping multiple variants, and defining more in
> the future, is to add required-repositories to the release-openstack-python
> job directly, as we discover they are needed. Of course that means
> we will clone repositories for some jobs that don't actually use
> them. I don't know how big of an issue that really is, but the issue
> of not knowing which instances of a job actually need a particular
> dependency seems like more of a justification for keeping separate
> templates than any runtime savings we would have by skipping a
> couple of extra calls to git clone.
> 
> It feels like we have two related by not necessarily dependent
> policy questions we need to answer before we decide how to proceed:
> 
> (a) Do we want to move the release job definitions from project-config
> and openstack-zuul-jobs to the releases repo?
> 

This seems like a good compromise to me. If we at least have them all in one
place, it will make it a lot easier to make sure we are able to get everything
updated as needed.

> (b) Do we want to have multiple release job templates due to custom
> dependencies (or any other reason)?
> 

I'm guessing we will want this. We will most likely at some point have some
need to have unique requirements for certain jobs.

> Thoughts?
> 
> 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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> It feels like we have two related by not necessarily dependent
> policy questions we need to answer before we decide how to proceed:

I don't have strong opinions on any of those two, I think anything would
work. If I had to pick between yes and no, here is my gut feeling:

> (a) Do we want to move the release job definitions from project-config
> and openstack-zuul-jobs to the releases repo?

Leaning towards yes as it will (imho) simplify maintenance. We'll still
have a couple of privileged jobs that will live on the infra side though?

> (b) Do we want to have multiple release job templates due to custom
> dependencies (or any other reason)?

Leaning towards no if we can avoid it, again to simplify operations.
That said, it will be difficult to enforce...

-- 
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] [release][infra][zuul][zuulv3][horizon][neutron] project-specific release job templates

[Doug Hellmann]

The neutron queens milestone release is held up right now because
some of the repositories are using a release job template that isn't
recognized by the validation code in the releases repository.  I'm
trying to decide between adding the custom job template to the
validation code or changing the release jobs for those neutron
repositories to use the one that isn't custom. I think we'll have
the same problem with horizon plugins using the custom job template
set up for them.

It looks like the publish-to-pypi-neutron template modifies
publish-to-pypi by adding openstack/neutron to the required-repositories
list for the release-openstack-python job. That repository was also at
some point added directly to the release-openstack-python job. So
technically the extension via the template is not needed. The same
applies to publish-to-pypi-horizon.

I see a few issues with keeping job template variants:

1. Having multiple release job variants complicates the release
   repo validation logic. That logic was put in place after we
   discovered several projects without release jobs defined at all,
   so we definitely want to keep some level of validation in place.

2. As we continue to make changes to the release jobs, we're going
   to have to consider whether to make those changes in multiple
   places, which seems error prone.

3. As we find other projects with more dependencies, we're going
   to end up with more custom templates.

Those issues may be mitigated if we move the release job definitions
into the releases repo as we have discussed, because it will be
more obvious that we have multiple related templates that are
variants of one another and we can make the relevant changes all
together in one patch.

One alternative to keeping multiple variants, and defining more in
the future, is to add required-repositories to the release-openstack-python
job directly, as we discover they are needed. Of course that means
we will clone repositories for some jobs that don't actually use
them. I don't know how big of an issue that really is, but the issue
of not knowing which instances of a job actually need a particular
dependency seems like more of a justification for keeping separate
templates than any runtime savings we would have by skipping a
couple of extra calls to git clone.

It feels like we have two related by not necessarily dependent
policy questions we need to answer before we decide how to proceed:

(a) Do we want to move the release job definitions from project-config
and openstack-zuul-jobs to the releases repo?

(b) Do we want to have multiple release job templates due to custom
dependencies (or any other reason)?

Thoughts?

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] [networking-ovn] Error while running unit tests(master branch)

[Lucas Alvares Gomes]

Hi Pranab,

> I don't see any errors in final results. But, as you can see here [1],
> couple of tests are showing ERROR before that.
>
> [1] http://paste.openstack.org/show/624436/
>

Ah, I see what you mean now. Off the top of my head I don't know what
is the cause, I will need to some troubleshooting. But, I can confirm
that I see the same errors by running the tests locally on my machine.

I have opened a bug against it at
https://bugs.launchpad.net/networking-ovn/+bug/1726845 so we can keep
track of the problem and to raise more awareness about it. The
importance was set to medium because the tests run still succeed
regardless of those exceptions being raised.

Thanks a lot of identifying and reporting this problem, hopefully we
can get it fixed soon!

Cheers,
Lucas

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

Re: [openstack-dev] [tripleo][networking] Organizing the networking squad

[Brent Eagles]

On Mon, Oct 16, 2017 at 2:44 PM, Harald Jensas  wrote:

> Include me as well Brent.
>
>
> //
> Harald
>
> On 16 Oct 2017 3:41 p.m., "Saravanan KR"  wrote:
>
> Thanks for initiating Brent. Yes, I would participate in the networking
> squad.
>
> Regards,
> Saravanan KR
>
> On Mon, Oct 16, 2017 at 6:43 PM, Brent Eagles  wrote:
> > Hi,
> >
> > On Tue, Oct 10, 2017 at 10:55 AM, Brent Eagles 
> wrote:
> >>
> >> Hi all,
> >>
> >> The list of TripleO squads includes a "networking squad". In previous
> >> cycles, coordinating outside of IRC and email conversations seemed
> >> unnecessary as there were only a few contributors and a small number of
> >> initiatives. However, with future container related work, increased
> usage of
> >> ansible, ongoing efforts like routed networks and NFV, os-net-config
> related
> >> issues, and the increasing number of backends and networking related
> >> services being added to TripleO, the world of TripleO networking seems
> >> increasingly busy. I propose that we start organizing properly with
> periodic
> >> sync-ups and coordinating efforts via etherpad (or similar) as well as
> >> reporting into the weekly tripleo meeting.
> >>
> >> Cheers,
> >>
> >> Brent
> >
> >
> > This was initially not directed at anyone in particular but I've added
> > possible interested parties to this thread in case it gets lost in the
> > noise! Please reply if you are interested in participating in the
> networking
> > squad. Proposed first orders of business are:
> >
> >  - establish the squad's scope
> >  - agree on whether we need a scheduled sync up meeting and if so, sort
> out
> > a meeting time time
> >  - outline initial areas of interest and concern and action items
> >
> > Cheers,
> >
> > Brent
>
>
​Thanks for the replies everyone!​

The squad has a status etherpad! See
https://etherpad.openstack.org/p/tripleo-networking-squad-status. It is
very sparse for now as we are just getting organized, but I've added a
visually grepped list of blueprints that seem likely related as an
illustration of just how much is planned or underway!

I'll be reaching out to you all over the next few days to try and
coordinate a meeting time. As always, timezones may prove a challenge but
we should be able to sort something out.

Thanks again for your interest and participation!

Cheers,

Brent
__
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] [ironic] ironic and traits

[Eric Fried]

Yeah, a couple of things here.

First, as you say, and as its champions have been very adamant about,
this isn't what placement was meant for.

Second, as I understand it, there's not actually going to be any way for
this information to reach the compute node through placement.  The
provider summaries in the allocation candidates always contain _all_ the
traits on the RP, not just the ones that were requested.  When I asked
about this in Denver, it was made clear that the only way to know which
traits were requested was via the flavor.

That being the case, we should make these configurables their own thing
in the flavor rather than trying to overload placement with them.

But I'm led to understand that Ironic can't see the flavor for some reason?

On 10/24/2017 01:52 AM, Alex Xu wrote:
> It sounds like Ironic use the Trait to configure the
> instance 
> https://review.openstack.org/#/c/504952/5/specs/approved/config-template-traits.rst@95
> 
> The downside I can see is that the extra burden added to the placement.
> As the example, used in the spec:
> * CUSTOM_BM_CONFIG_BIOS_VMX_ON
> * CUSTOM_BM_CONFIG_BIOS_VMX_OFF
> 
> Actually, the placement only needs to find a host whose CPU have VMX
> feature. So it only one trait "HW_CPU_X86_VMX". But to use Trait to
> config the instance, we have to add each possible value as trait to the
> placement.
> 
> That isn't very terrible for the boolean value, but if there are 10
> values, or it is just an integer value.
> 
> That sounds like we put information isn't about the scheduling to the
> placement, and those information adds extra burden to the placement.
> 
> 2017-10-23 22:09 GMT+08:00 Eric Fried  >:
> 
> We discussed this a little bit further in IRC [1].  We're all in
> agreement, but it's worth being precise on a couple of points:
> 
> * We're distinguishing between a "feature" and the "trait" that
> represents it in placement.  For the sake of this discussion, a
> "feature" can (maybe) be switched on or off, but a "trait" can either be
> present or absent on a RP.
> * It matters *who* can turn a feature on/off.
>   * If it can be done by virt at spawn time, then it makes sense to have
> the trait on the RP, and you can switch the feature on/off via a
> separate extra_spec.
>   * But if it's e.g. an admin action, and spawn has no control, then the
> trait needs to be *added* whenever the feature is *on*, and *removed*
> whenever the feature is *off*.
> 
> [1]
> 
> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13
> 
> 
> 
> On 10/23/2017 08:15 AM, Sylvain Bauza wrote:
> >
> >
> > On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried  > >> wrote:
> >
> >     I agree with Sean.  In general terms:
> >
> >     * A resource provider should be marked with a trait if that
> feature
> >       * Can be turned on or off (whether it's currently on or not); or
> >       * Is always on and can't ever be turned off.
> >
> >
> > No, traits are not boolean. If a resource provider stops providing a
> > capability, then the existing related trait should just be removed,
> > that's it.
> > If you see a trait, that's just means that the related capability for
> > the Resource Provider is supported, that's it too.
> >
> > MHO.
> >
> > -Sylvain
> >
> >  
> >
> >     * A consumer wanting that feature present (doesn't matter
> whether it's
> >     on or off) should specify it as a required *trait*.
> >     * A consumer wanting that feature present and turned on should
> >       * Specify it as a required trait; AND
> >       * Indicate that it be turned on via some other mechanism (e.g. a
> >     separate extra_spec).
> >
> >     I believe this satisfies Dmitry's (Ironic's) needs, but also
> Jay's drive
> >     for placement purity.
> >
> >     Please invite me to the hangout or whatever.
> >
> >     Thanks,
> >     Eric
> >
> >     On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
> >     >  
> >     >
> >     >  
> >     >
> >     > *From:*Jay Pipes [mailto:jaypi...@gmail.com
> 
> >     >]
> >     > *Sent:* Monday, October 23, 2017 12:20 PM
> >     > *To:* OpenStack Development Mailing List
> >      
> >      >>
> >     > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
> >     >
> >     >  
> >     >
> >     > Writin

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Thierry Carrez]

Tony Breeds wrote:
> On Mon, Oct 23, 2017 at 09:35:34AM +0100, Jean-Philippe Evrard wrote:
> 
>> I agree, we should care about not repeating this Pike trend. It looks
>> like Queens is better in terms of turnout (see the amazing positive
>> delta!). However, I can't help but noticing that the trend for
>> turnouts is slowly reducing (excluding some outliers) since the
>> beginning of these stats.
> 
> Yup, the table makes that pretty visible.
>  
>> Any idea on how to improve that?

One facet of this trends may not be negative:

As we make it more and more clear that TC activity is more about duties
than about rights (more about stewardship then leadership), people care
a bit less about specific individuals and are less motivated by the vote
itself. If the activity of the TC was a lot more conflict and a lot less
consensus (as it used to be in the past) then I think people would care
more about representation of their interests and who exactly ends up
being elected.

-- 
Thierry Carrez (ttx)



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

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Thierry Carrez]

Colleen Murphy wrote:
> On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke
> mailto:diana.joan.cla...@gmail.com>> wrote:
> 
> Congrats on being elected to the TC, Colleen!
> 
> You mentioned earlier in this thread that, "a major problem in the
> tech world is not just attracting underrepresented contributors, but
> retaining them".
> 
> I'm curious if the TC has considered polling the people that have left
> OpenStack for their experiences on this front.
> 
> Something along the lines of:
> 
>     "I see you contributed 20 patches in the last cycle, but haven't
> contributed recently, why did you stop contributing?".
> 
> Given the recent layoffs, I suspect many of the responses will be
> predicable, but you might find some worthwhile nuggets there
> nonetheless.
> 
> I'm not aware of such an initiative so far but I do think it would be
> useful, and perhaps something we can partner with the foundation on.

Kind of parallel to the polling idea:

John Dickinson has some interesting scripts that he runs to detect
deviation from a past contribution pattern (like someone who used to
contribute a few patches per cycle but did not contribute anything over
the past cycle, or someone who used to contribute a handful of patches
per month who did not send a single patch over the past month). Once
oddities in the contribution pattern are detected, he would contact the
person to ask if anything happened or changed that made them stop
contributing.

John would probably describe it better than I did. I like that it's not
just quantitative but more around deviation from an established
contribution pattern, which lets him spot issues earlier.

Note that this sort of analysis works well when combined with personal
outreach, which works better at project team level... If done at
OpenStack level you would likely have more difficulty making it feel
personal (if I end up reaching out to a Tacker dev that stopped
contributing, it won't be as effective as if the Tacker PTL did the
outreach). One thing we could do would be to productize those tools and
make them available to a wider number of people.

-- 
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] [TripleO] Deployment workflow changes for ui/client

[Jiri Tomasek]

On Fri, Oct 20, 2017 at 1:20 PM, Brad P. Crochet  wrote:

> On Thu, Oct 19, 2017 at 4:56 PM James Slagle 
> wrote:
>
>> I've been looking at how we can hook up the deployment changes for
>> config-download[1] with the existing deployment workflows in Mistral.
>>
>> However, it seems we have not sufficiently abstracted the logic to do
>> a "deployment" behind a given workflow(s). The existing things a
>> client (or UI) has to do is:
>>
>> - call tripleo.deployment.v1.deploy_plan
>> - poll for success/failure of that workflow
>> - poll for success/failure of in progress Heat stack (list events, etc)
>> - call tripleo.deployment.v1.overcloudrc
>> (probably more things too)
>>
>> If I want to make some changes to the deployment workflow, such that
>> after the Heat stack operation is complete, we run a config-download
>> action/workflow, then apply the generated ansible via
>> ansible-playbook, I can't really do that without requiring all clients
>> to also get updated to use those new steps (via calling new workflows,
>> etc).
>>
>> As a first attempt, I took a shot at creating a workflow that does every
>> step:
>> https://review.openstack.org/#/c/512876/
>> But even that will require client changes as it necessitates a
>> behavior change in that the workflow has to wait for the stack to be
>> complete as opposed to returning as soon as the stack operation is
>> accepted by Heat.
>>
>>
> Thankfully we already have that capability. :)
>
>
>> I'd like to implement this in a way that minimizes the impact of
>> changes on both python-tripleoclient and tripleo-ui, but it's looking
>> as if some changes would be required to use this new ansible driven
>> approach.
>>
>> Thoughts or feedback on how to proceed? I'm guess I'm also wondering
>> if the existing API exposed by the workflows is easy to consume by the
>> UI, or if it would be better to be wrapped in a single workflow...at
>> least that way we could make logical implementation changes without
>> requiring ui/cilent changes.
>>
>> [1] https://blueprints.launchpad.net/tripleo/+spec/ansible-
>> config-download
>>
>>
> +1 to all of this. I think from the CLI perspective, it should be a
> minimal impact. If anything, it will get rid of a lot of code that doesn't
> really belong. I can't say what the impact to the UI would be. However, one
> thing that we should make sure of is that we send messages back through
> Zaqar to keep the CLI and UI informed of what is occurring. That should
> happen already with most of the existing workflows.
>
> This is a great step in the right direction. The Workflows squad will be
> happy to assist in any way we can. We will start by reviewing what you have
> so far.
>

Having a workflow which wraps whole deployment sounds great from the UI
side too as it allows us to simplify the steps you described above. IIRC
the reason the whole deployment did not get wrapped into a single workflow
before is that the workflow/tasks timeouted before the deployment could
finish which caused the workflow to fail.

It should not be problematic to integrate these changes in GUI. The soon we
can test it the better. As Brad noted, it is important to get as many Zaqar
messages as possible so we can track the progress properly.

-- Jirka


>
>
>> --
>> -- 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
>>
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385 <(704)%20236-9385>
>
>
> __
> 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] roles_data.yaml equivalent in containers

[Abhishek Kane]

Hi,

In THT I have an environment file and corresponding puppet service for Veritas 
HyperScale.
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/veritas-hyperscale/veritas-hyperscale-config.yaml
https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/veritas-hyperscale-controller.yaml

This service needs rabbitmq user the hooks for it is 
“veritas_hyperscale::hs_rabbitmq”-
https://github.com/openstack/puppet-tripleo/blob/master/manifests/profile/base/rabbitmq.pp#L172

In order to configure Veritas HyperScale, I add 
“OS::TripleO::Services::VRTSHyperScale” to roles_data.yaml file and use 
following command-

# openstack overcloud deploy --templates -r /home/stack/roles_data.yaml -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/veritas-hyperscale-config.yaml
 -e 
/usr/share/openstack-tripleo-heat-templates/environments/veritas-hyperscale/cinder-veritas-hyperscale-config.yaml

This command sets “veritas_hyperscale_controller_enabled” to true in hieradata 
and all the hooks gets called.

I am trying to containerize Veritas HyperScale services. I used following 
config file in quickstart-
http://paste.openstack.org/show/624438/

It has the environment files-
  -e 
{{overcloud_templates_path}}/environments/veritas-hyperscale/cinder-veritas-hyperscale-config.yaml
  -e 
{{overcloud_templates_path}}/environments/veritas-hyperscale/veritas-hyperscale-config.yaml

But this itself doesn’t set “veritas_hyperscale_controller_enabled” to true in 
hieradata and veritas_hyperscale::hs_rabbitmq doesn’t get called.
https://github.com/openstack/tripleo-heat-templates/blob/master/roles_data.yaml#L56


How do I add OS::TripleO::Services::VRTSHyperScale in case of containers?

Thanks,
Abhishek
__
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] IBM z/VM CI asks for reporting permission to Nova changes

[Xiao Mei GZ Zheng]

Hi Andreas,

 

It's very kind of you .Thank you very much for your advice and we have fixed it .

 

Best Regards!

 

- Original message -
From: Andreas Scheuring 
To: "OpenStack Development Mailing List (not for usage questions)" 
Cc:
Subject: Re: [openstack-dev] IBM z/VM CI asks for reporting permission to Nova changes
Date: Tue, Oct 17, 2017 8:11 PM
 
Hi Laurene, 
 

at the moment the z/VM CI is posting a +1 even though the job failed. That’s because in zuul layout.yaml the job is probably set to "voting: false.” You can easily fix this by setting it to “true”.

 

For example see https://review.openstack.org/#/c/512190/

 

Regards, 





---

Andreas Scheuring (andreas_s)

 

 



On 12. Oct 2017, at 06:42, Xiao Mei GZ Zheng  wrote:
 



Hello,

I'm requesting reporting permission (non-voting) to Nova changes for the IBM z/VM CI. The wiki is on link [1].

We designed the CI using nodepool , zuul and Jenkins. The newly uploaded patches will receive an initial +/-1 reports from Jenkins only for the nova project (just comments on patches but not vote on them). Tests completed on the z/VM Driver CI system check-nova pipeline. For more information see[2]. To recheck it, you just submit a comment with only zvm:recheck in the comment. 

The IBM z/VM CI system has been running for a long time in a stable fashion. We present all test artifacts on a public link [3] to make debugging failed tests easier. You can see environment details, openstack logs and tempest logs.

* Gerrit Account: zvmosci

* Gerrit query on patches where the CI commented: [4]

* Proposal for naming: IBM z/VM CI

For any questions feel free to reach out to me (Laurene) or to Leon!

[1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI

[2] https://wiki.openstack.org/wiki/ZVMDriver/zVM-CI


[3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/


[4] https://review.openstack.org/#/c/410596/

Thanks & Best Regards!

Laurene(Xiao Mei) Zheng 

Software developer, CSTL
IBM China Systems & Technology Lab (CSTL)
 

__
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=xBwd2jI5NgaWbKb7nCTcei4BjD53a-iaRDSJP5PlqOg&m=bAOjpvrqevtIQ3DgdrtEuGx9ZcS-LExURqkCAP3zd44&s=MA-l-y3O6gsjwr9lqRDV2vPffPcLdg4xosK46Y98L8I&e=


 




__
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] [networking-ovn] Error while running unit tests(master branch)

[pranab boruah]

Thanks Lucas for the reply.

I don't see any errors in final results. But, as you can see here [1],
couple of tests are showing ERROR before that.

[1] http://paste.openstack.org/show/624436/

Regards,
Pranab

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Swapnil Kulkarni]

On Tue, Oct 24, 2017 at 1:01 PM, Swapnil Kulkarni  wrote:
> On Sat, Oct 21, 2017 at 5:29 AM, Kendall Nelson  wrote:
>> Hello Everyone :)
>>
>> Please join me in congratulating the 6 newly elected members of the
>> Technical Committee (TC)!
>>
>> Colleen Murphy (cmurphy)
>> Doug Hellmann (dhellmann)
>> Emilien Macchi (emilienm)
>> Jeremy Stanley (fungi)
>> Julia Kreger (TheJulia)
>> Paul Belanger (pabelanger)
>>
>> Full results:
>> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>>
>> Election process details and results are also available here:
>> https://governance.openstack.org/election/
>>
>> Thank you to all of the candidates, having a good group of candidates helps
>> engage the community in our democratic process.
>>
>> Thank you to all who voted and who encouraged others to vote. We need to
>> ensure your voice is heard.
>>
>> Thank you for another great round.
>>
>> -Kendall Nelson (diablo_rojo)
>>
>> [1] https://review.openstack.org/#/c/513881/
>>
>> __
>> 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
>>
>
>
> Congratulations ot a

Congratulations to all elected TC members.

~coolsvap

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

Re: [openstack-dev] [all] [elections] Technical Committee Election Results

[Swapnil Kulkarni]

On Sat, Oct 21, 2017 at 5:29 AM, Kendall Nelson  wrote:
> Hello Everyone :)
>
> Please join me in congratulating the 6 newly elected members of the
> Technical Committee (TC)!
>
> Colleen Murphy (cmurphy)
> Doug Hellmann (dhellmann)
> Emilien Macchi (emilienm)
> Jeremy Stanley (fungi)
> Julia Kreger (TheJulia)
> Paul Belanger (pabelanger)
>
> Full results:
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>
> Election process details and results are also available here:
> https://governance.openstack.org/election/
>
> Thank you to all of the candidates, having a good group of candidates helps
> engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to
> ensure your voice is heard.
>
> Thank you for another great round.
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://review.openstack.org/#/c/513881/
>
> __
> 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
>


Congratulations ot a

__
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][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke 
wrote:

> Congrats on being elected to the TC, Colleen!
>
> You mentioned earlier in this thread that, "a major problem in the
> tech world is not just attracting underrepresented contributors, but
> retaining them".
>
> I'm curious if the TC has considered polling the people that have left
> OpenStack for their experiences on this front.
>
> Something along the lines of:
>
> "I see you contributed 20 patches in the last cycle, but haven't
> contributed recently, why did you stop contributing?".
>
> Given the recent layoffs, I suspect many of the responses will be
> predicable, but you might find some worthwhile nuggets there
> nonetheless.
>
I'm not aware of such an initiative so far but I do think it would be
useful, and perhaps something we can partner with the foundation on.

Colleen

>
> Congrats again,
>
> --diana
>
> On Sun, Oct 15, 2017 at 3:38 AM, Colleen Murphy 
> wrote:
> > A major problem in the tech world is not just attracting underrepresented
> > contributors, but retaining them. They leave their communities or careers
> > because of bias problems. To my knowledge, that doesn't happen in
> OpenStack,
> > but just because I can't see it doesn't mean it's not there. A long-term
> > study of participation by underrepresented demographics will help us
> answer
> > this and fix it if necessary.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] No QoS meeting today

[Sławomir Kapłoński]

Hello,

There will be no QoS meeting today. Next one will be on 7.11.2017.
Sorry.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
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