[openstack-dev] [ironic][triploe] support for firmware update

[Moshe Levi]

Hi all,

I saw that ironic-python-agent support custom hardware manager.
I would like to support firmware updates (In my case Mellanox nic) and I was 
wandering how custom hardware manager can be used in such case?
How it is integrated with ironic-python agent and also is there an integration 
to tripleO as well.

The use case for use is just to make sure the correct firmware is installed on 
the nic and if not update it during the triple deployment.




[1] - 
https://docs.openstack.org/ironic-python-agent/pike/contributor/hardware_managers.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][neutron] bare metal on vxlan network

[Moshe Levi]

Hi all,

Ironic supports  mutli tenancy for quite few releases and according to the spec 
[1] it can work with vlan/vxlan networks.
I see lot of mechanism driver that support vlan network such as [2] and [3] , 
but I didn't find any mechanism driver that work on vxlan network.
Is there a mechanism driver that can configure vtep on a switch exist for the 
bare metal?

Help would be appreciated


[1] 
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
[2] https://github.com/openstack/networking-arista
[3] https://github.com/openstack/networking-generic-switch
__
OpenStack Development Mailing 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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Hello PTLs and SIG Chairs!

So here's the deal, we have 50 spots that are first come, first served. We
have slots available before and after lunch both Tuesday and Thursday.

The google sheet here[1] should be set up so you have access to edit, but
if you can't for some reason just reply directly to me and I can add your
team to the list (I need team/sig name and contact email).

I will be locking the google sheet on *Monday February 26th so I need to
know if your team is interested by then. *

See you soon!

- Kendall Nelson (diablo_rojo)

[1]
https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
__
OpenStack Development Mailing 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] [QA] Meeting Thursday Feb 8th at 8:00 UTC

[gmann]

Hello everyone,

Hope everyone is back from vacation. QA team is resuming the regular
weekly meeting from today. OpenStack QA team IRC meeting will be
Thursday, Feb 8th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Feb_8th_2018_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

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

[openstack-dev] RefStack disable anonymous upload and database cleanup

[me...@openstack.org]

Hello all!
Over the course of the last few months, we have implemented and merged into 
production the option in RefStack server to disable the ability to upload 
refstack results as an anonymous user.
In its current state, the RefStack database includes many anonymous test 
results that ultimately end up unused. The RefStack team is planning to trim 
all anonymously upload test results in current database to contain only records 
used in the OpenStack Powered Trademark program. We will then disable the 
anonymous upload capability and require all test results to be managed with 
user accounts.
Over the next two weeks, with a target of completing the work by February 13, 
we will perform a staged update the RefStack server that will:
* Disable anonymous uploads.
* Purge the database of unlinked anonymous test results.

Test results associated with RefStack accounts will be unaffected. Please reach 
out to myself or any of the other RefStack team members with questions or 
concerns.
-- Megan Guiney
 __
OpenStack Development Mailing 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] End of PTL Nominations

[Zhipeng Huang]

Hi Kendall,

There is a small typo for cyborg PTL name, rushil helped e submit the
patch, but the name of the PTL should be Zhipeng Huang :) if you could
correct that on the governance page that would be less confusing :)

On Feb 8, 2018 8:06 AM, "Kendall Nelson"  wrote:

Hello Everyone!

The PTL Nomination period is now over. The official candidate list is
available on the election website[0].

There are 0 projects without candidates, so the TC will not have to appoint
any PTL's.

There are 3 projects that will have elections: Kolla, QA, & Mistral. The
details for those will be posted shortly after we setup the CIVS system.

Thank you,
- Kendall Nelson (diablo_rojo)

[0] http://governance.openstack.org/election/#Rocky-ptl-candidates


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

[openstack-dev] [All][Elections][QA][Mistral][Kolla] Polling Begins!

[Kendall Nelson]

Hello!

Polls for PTL elections are now open and will remain open for you to cast
your vote until Feb 14, 2018 23:45 UTC.

We are having elections for Kolla, Mistral & QA.

If you are a Foundation individual member and had a commit in
one of the program's projects[0] over the Pike-Queens timeframe (22 Feb
2017 to 29 Jan 2018) then you are eligible to vote. You should find your
email with a link to the Condorcet page to cast your vote in the inbox of
your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at
least one of the programs having an election:
* check the trash or spam folders of your gerrit Preferred
Email address, in case it went into trash or spam
* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the program
project repos[0] and email the election officials.

If we can confirm that you are entitled to vote, we will add you
to the voters list for the appropriate election.

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

Candidate statements/platforms can be found linked to Candidate names on
this page:
http://governance.openstack.org/election/#Rocky-ptl-candidates

Happy voting,

-Kendall Nelson (diablo_rojo)

[0] The list of the program projects eligible for electoral status:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=aug-2017-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg] Lightning talks

[Mike Perez]

Hey all!

I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
be on Friday March 2nd at 13:00-13:30 local time.

Appropriate 5 minute talk examples:
* Neat features in libraries like oslo that we should consider adopting in our
  community wide goals.
* Features and tricks in your favorite editor that makes doing work easier.
* Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
  in five minutes anyone?
* Some potential API specification from the API SIG that we should adopt as
  a community wide goal.

Please email me DIRECTLY the following information:

Title:
Speaker(s) full name:
Abstract:
Link to presentation or attachment if you have it already. Laptop on stage will
be loaded with your presentation already. I'll have open office available so
odp, odg, otp, pdf, limited ppt format support.

Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
emails to speakers requesting for slides. Thank you, looking forward to hearing
some great talks from our community!

-- 
Mike Perez (thingee)


pgppqFF0WWDDV.pgp
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] [ptg] Track around release cycle, consumption models and stable branches

[Borne Mace]

I would be interested in taking part in this discussion as well,

-- bm

On 02/07/2018 03:42 AM, Thierry Carrez wrote:

Hi everyone,

I was wondering if anyone would be interested in brainstorming the
question of how to better align our release cycle and stable branch
maintenance with the OpenStack downstream consumption models. That
includes discussing the place of the distributions, the need for LTS,
and where does the open source upstream project stop.

I have hesitated to propose it earlier, as it sounds like a topic that
should be discussed with the wider community at the Forum. And it will,
but it feels like this needs a deeper pre-discussion in a productive
setting, and tonyb and eumel8 have been proposing that topic on the
missing topics etherpad[1], so we might as well take some time at the
PTG to cover that.

Would anyone be interested in such a discussion ? It would be scheduled
on the Tuesday. How much time would we need ? I was thinking we could
use only Tuesday afternoon.

[1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics




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

[openstack-dev] [All][Elections] End of PTL Nominations

[Kendall Nelson]

Hello Everyone!

The PTL Nomination period is now over. The official candidate list is
available on the election website[0].

There are 0 projects without candidates, so the TC will not have to appoint
any PTL's.

There are 3 projects that will have elections: Kolla, QA, & Mistral. The
details for those will be posted shortly after we setup the CIVS system.

Thank you,
- Kendall Nelson (diablo_rojo)

[0] http://governance.openstack.org/election/#Rocky-ptl-candidates
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][cinder]Question about cinder as glance store

[Erlon Cruz]

That will depend on the Cinder/OS-brick iscsiadm versions right? Can you
tell what are the versions from where the problem was fixed?

Erlon

2018-02-07 8:27 GMT-02:00 Gorka Eguileor :

> On 07/02, Rikimaru Honjo wrote:
> > Hello,
> >
> > I'm planning to use cinder as glance store.
> > And, I'll setup cinder to connect storage by iSCSI multipath.
> >
> > In this case, can I run glance-api and cinder-volume on the same node?
> >
> > In my understanding, glance-api will attach a volume to own node and
> > write a uploaded image to the volume if glance backend is cinder.
> > I afraid that the race condition of cinder-volume's iSCSI operations
> > and glance-api's iSCSI operations.
> > Is there possibility of occurring it?
> > --
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> > Rikimaru Honjo
> > E-mail:honjo.rikim...@po.ntt-tx.co.jp
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Hi,
>
> When properly set with the right configuration and the right system and
> OpenStack packages, Cinder, OS-Brick, and Nova no longer have race
> conditions with iSCSI operations anymore (single or multipathed), not
> even with drivers that do "shared target".
>
> So I would assume that Glance won't have any issues either as long as
> it's properly making the Cinder and OS-Brick calls.
>
> Cheers,
> Gorka.
>
> __
> OpenStack Development Mailing 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Matthew Thode]

On 18-02-08 00:08:40, Ivan Kolodyazhny wrote:
> Hi Matt,
> 
> As discussed earlier today at the Horizon's meeting [2], we're not going to
> release horizon-cisco-ui and django_openstack_auth because of projects
> retirement [3] and [4].
> 
> 
> [2] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-02-
> 07-20.02.html
> [3] https://review.openstack.org/#/c/541803/
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126428.html
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
> 
> On Wed, Feb 7, 2018 at 11:31 PM, Tony Breeds 
> wrote:
> 
> > On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote:
> >
> > > Okay  It's safe to ignore then ;P  We should probably remove it from
> > > projects.txt if it really is empty  I'll propose that.
> >
> > Oh my bad, ironic-python-agent-builder was included as it's included as
> > an ironic project[1] NOT because it;s listed in projects.txt.  Given
> > that it's clearly not for me to remove anything.
> >
> > Having said that if the project hasn't had any updates at all since it's
> > creation in July 2017 perhaps it's no longer needed and could be
> > removed?
> >
> > Yours Tony.
> >
> > [1] http://git.openstack.org/cgit/openstack/governance/tree/
> > reference/projects.yaml#n1539
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

Yep, already removing horizon-cisco-ui from requirements.  (since infra
jumped the gun on us :P )

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Ivan Kolodyazhny]

Hi Matt,

As discussed earlier today at the Horizon's meeting [2], we're not going to
release horizon-cisco-ui and django_openstack_auth because of projects
retirement [3] and [4].


[2] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-02-
07-20.02.html
[3] https://review.openstack.org/#/c/541803/
[4]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126428.html

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, Feb 7, 2018 at 11:31 PM, Tony Breeds 
wrote:

> On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote:
>
> > Okay  It's safe to ignore then ;P  We should probably remove it from
> > projects.txt if it really is empty  I'll propose that.
>
> Oh my bad, ironic-python-agent-builder was included as it's included as
> an ironic project[1] NOT because it;s listed in projects.txt.  Given
> that it's clearly not for me to remove anything.
>
> Having said that if the project hasn't had any updates at all since it's
> creation in July 2017 perhaps it's no longer needed and could be
> removed?
>
> Yours Tony.
>
> [1] http://git.openstack.org/cgit/openstack/governance/tree/
> reference/projects.yaml#n1539
>
> __
> OpenStack Development Mailing 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Tony Breeds]

On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote:

> Okay  It's safe to ignore then ;P  We should probably remove it from
> projects.txt if it really is empty  I'll propose that.

Oh my bad, ironic-python-agent-builder was included as it's included as
an ironic project[1] NOT because it;s listed in projects.txt.  Given
that it's clearly not for me to remove anything.

Having said that if the project hasn't had any updates at all since it's
creation in July 2017 perhaps it's no longer needed and could be
removed?

Yours Tony.

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n1539


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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Tony Breeds]

On Wed, Feb 07, 2018 at 06:11:33PM +0100, Dmitry Tantsur wrote:
> Hi,
> 
> On 02/07/2018 05:23 PM, Matthew Thode wrote:
> > Hi all,
> > 
> > it looks like some of your projects may need to cut a queens
> > branch/release.  Is there anything we can do to move it along?
> 
> Review patches? Make the gate work faster? :)
> 
> The Ironic team is working on it, we expect stable/queens requests to come
> later today or early tomorrow. Two more comments inline.
> 
> > 
> > The following is the list I'm working off of (will be updated as
> > projects release)
> > https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
> > 
> > As of right now it's as follows.
> > 
> > # Projects without team or release model could not be found in 
> > openstack/releases for queens
> > openstack/almanach
> > openstack/compute-hyperv
> > openstack/ekko
> > openstack/gce-api
> > openstack/glare
> > openstack/ironic-staging-drivers
> 
> I don't think non-official projects get tracked via openstack/releases.

It's true they are not tracked in openstack/realeases but as they
receive requirements syncs via the bot we need to track them in
requirements.  I guess the bottom line is until/if
ironic-staging-drivers gets a queens branch you may need to be careful
with merging any requirements updates and possibly may request am ACK
from the requirements team.

Of course if ironic-staging-drivers doesn't have any relationship with a
series those statements are probably wrong.
 
> > openstack/kosmos
> > openstack/mixmatch
> > openstack/mogan
> > openstack/nemesis
> > openstack/networking-dpm
> > openstack/networking-l2gw
> > openstack/networking-powervm
> > openstack/nova-dpm
> > openstack/nova-lxd
> > openstack/nova-powervm
> > openstack/os-xenapi
> > openstack/python-cratonclient
> > openstack/python-glareclient
> > openstack/python-kingbirdclient
> > openstack/python-moganclient
> > openstack/python-oneviewclient
> > openstack/python-valenceclient
> > openstack/swauth
> > openstack/tap-as-a-service
> > openstack/trio2o
> > openstack/valence
> > openstack/vmware-nsx
> > openstack/vmware-nsxlib
> > 
> > # Projects missing a release/branch for queens
> > openstackclientOpenStackClient
> > anchor Security
> > ec2-apiec2-api
> > django_openstack_auth  horizon
> > horizon-cisco-ui   horizon
> > bifrostironic 
> > ironic-python-agent-builderironic
> 
> This one is empty and will not be released for Queens.

Okay  It's safe to ignore then ;P  We should probably remove it from
projects.txt if it really is empty  I'll propose that.

Yours Tony.


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

[openstack-dev] [horizon][ptl] Rocky PTL Candidacy

[Ivan Kolodyazhny]

Hello Team,

I would like to announce my candidacy for PTL of Horizon for Rocky release.


I use Horizon since I begin to work with OpenStack in Diablo timeframe. I
wasn't active contributor before Pike release, nevertheless, I can see how
both Horizon project and community changed over the times. I became Core
Reviewer in Queens and worked mostly on bug-fixing and other improvements.


Being a PTL is a challenging task especially for such project as Horizon. We
should be close both to the other OpenStack components and provide a great
user
experience for cloud users and operators.


As a PTL I will focus on the following areas:

* Continue to work on Horizon stabilization and improvements to bring great
UX
  for large-scale deployments.

* Finish work on mox to mock migrations in unit tests.

* Improve our integrational tests.

* Help everybody to contribute to Horizon via reviews, features
implementations
  and bugfixes.


I know, that being a PTL is a hard job, but we've got a good team and we'll
do
our best to make Horizon a bit better during the next cycle.


Thank you,


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

Re: [openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[Tony Breeds]

On Wed, Feb 07, 2018 at 12:42:05PM +0100, Thierry Carrez wrote:

> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.

+1 Sounds good to me.  I'll be there :)

Yours Tony.


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

[openstack-dev] [k8s] openstack-sig-k8s planning for Dublin

[Chris Hoge]

sig-k8s has a block of room time put aside for the Dublin PTG. I’ve set
up a planning etherpad for work and discussion topics[1]. High priority
items include:

* openstack provider breakout [2]
* provider testing
* documentation updates

Please feel free to add relevant agenda items, links, and discussion
topics.

We will begin some pre-planning today at the k8s-sig-openstack meeting,
taking place at 00 UTC Thursday [3] (Wednesday afternoon/evening for North
America, morning for Asia/Pacific region).

Thanks,
Chris

[1] https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg
[2] https://github.com/dims/openstack-cloud-controller-manager
[3] https://github.com/kubernetes/community/tree/master/sig-openstack#meetings


__
OpenStack Development Mailing 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][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Andrey Kurilin]

Hi Rico and stackers,

Thanks for raising this topic.

Short answer: please leave it as is for now. Rally team will work on ZuulV3
jobs soon.

Detailed: We are planning to make some big changes in our architecture
which includes splitting the main repo into a separate repository for a
framework and a separate repository for all OpenStack plugins.
To minimize work across all projects which have Rally job, we decided to
pause working on ZuulV3 until the split will be finished.
As for estimates, I'm planning to make the final release before splitting
today or tomorrow. As soon as new release will be ready, we will start
working on splitting and CI as well.

Thanks for the patient and for using Rally!

2018-02-07 10:13 GMT+02:00 Rico Lin :

> Hi heat and rally team
>
> Right now, in heat's zuul jobs. We still got one legacy job to change
> `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out
> here [2], but after discussion with infra team, it seems best if we can
> define this in rally, and reference it in heat.
> So my question to rally team for all these will be, do we still need this
> job? and how you guys think about if we put that into rally?
>
> [1] https://github.com/openstack-infra/project-config/blob/master/zuul.d/
> projects.yaml#L6979
> [2] https://review.openstack.org/#/c/509141
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] [openstack-helm] OpenStack-Helm Office Hours

[MCEUEN, MATT]

Team,

The OpenStack-Helm team will begin holding weekly Office Hours in IRC, with a 
goal of knowledge sharing and Q between the more experienced and the newer 
team members.  The project cores have committed to giving attention to at least 
one office hour during the week, and it should be a great way to ramp up on the 
project.  All are welcome to attend!

We're starting with three different hours per week, and we're keeping them up 
to date in our wiki [1].  Hope to see some new faces there.

[1] https://wiki.openstack.org/wiki/Openstack-helm

Thanks,
Matt McEuen


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

Re: [openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[Matthew Thode]

On 18-02-07 12:42:05, Thierry Carrez wrote:
> Hi everyone,
> 
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
> 
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
> 
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.
> 
> [1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
> 

I'll make myself available with both my requirements and distro
packaging hats.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [manila] [ptl] announcing PTL candidacy for manila

[Tom Barron]

Friends, Stackers, Community,

I write to announce my candidacy for the Manila PTL position for the
Rocky cycle.

I've worked in in OpenStack since Juno and actively in Manila since
Mitaka or so.  I've had more than one employer in that time and think
it's fair to say that I have a reputation for working upstream in the
interests of the community.  I am one of the more active Manila core
reviewers, care about welcoming and engaging new contributors,
encouraging participation, and at the same time preserving code quality
and the integrity of the project.

Ben Swartzlander is moving on to do other cool stuff, including work
as a Manila contributor.  I expect that I share a rather general
perception that no one can fill his shoes as PTL.  That said, I do
think that if we work together to make Manila shine we can make it
truly awesome!

Some areas I'd like us to work on in the near future include:

* python 3 support.  Upstream python 2 support is going away in 2020
 if I understand correctly and between now and then distros are
 likely to drop support for it.  We need to do our part to get manila
 working with python 3 in devstack, and also with python 3 when
 deployed at scale via frameworks like kolla, charms, and TripleO.

* performance and scale. We learned recently that Huawei public cloud 
 runs manila with thousands of shares and that CERN is planning to

 move from 83 shares to over 2000 shares.  Let's get more success
 stories with more back ends, build a common understanding of any
 bottlenecks, and work plans to address these.

* side-by-side deployment with kubernetes and other clouds.  Whether
 running kubernetes on OpenStack, deploying OpenStack services with
 kubernetes, or building standalone software defined storage with
 manila and cinder without other OpenStack services, this is a space
 where we need to explore and be actively engage.

* production quality open source software defined back ends.  Manila
 has great proprietary storage back ends, but shouldn't we have open
 source back ends that work reliably at scale as well?  We could make
 the generic driver great in this regard, or build out distributed
 file system back ends like cephfs with good data path HA and tenant
 separation.  There are perhaps other alternatives that haven't
 surfaced yet.  There's a lot of room here for innovation and
 certainly demand from cloud operators on this front.

* vendor participation: we have a mix of vendors introducing new
 back ends, sustained participation from vendors with existing
 back ends, and some back ends that no longer have attention from
 their vendors even though -- working with a distro -- I see customers
 indicating that they *want* to use those back ends if only the
 vendors were engaged!  Let's welcome new vendors with open arms
 and help all understand the mutual benefit of remaining involved
 with manila as the community evolves and grows.

Those are some of my ideas.  I offer them as much as anything to
stimulate others working on manila to come to PTG and the Rocky cycle
with their own initiatives.

Also, if you haven't been working in manila and any of the above seems
interesting (or just nuts) come on over!  Manila is a great place to
contribute and innovate!

Thanks for listening.

-- Tom Barron (tbarron



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] [all] [ptg] Reminder: Sign up for project interviews at PTG

[Rich Bowen]

A reminder - the PTG is now less than 3 weeks out. As you plan your 
schedule, please set aside time for a project/team interview, and sign 
up at 
https://docs.google.com/spreadsheets/d/1MK7rCgYXCQZP1AgQ0RUiuc-cEXIzW5RuRzz5BWhV4nQ/edit#gid=0


That document also contains a description of what kind you will want to 
prepare for your interview, and some examples of past interviews, which 
you can see at http://youtube.com/RDOCommunity


Thanks!

--
Rich Bowen - rbo...@redhat.com
@RDOcommunity // @CentOSProject // @rbowen

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

Re: [openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[Michael Johnson]

I am interested in contributing to this discussion.

Michael


On Wed, Feb 7, 2018 at 3:42 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
>
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
>
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.
>
> [1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

[Goutham Pratapa]

Hi Chris,

Thanks for writing to us.

Our idea is just the same. and we are working on how to do it :)

Thanks for the use-case :)

On Wed, Feb 7, 2018 at 9:50 PM, Chris Friesen 
wrote:

> On 02/05/2018 06:33 PM, Jay Pipes wrote:
>
> It does seem to me, however, that if the intention is *not* to get into the
>> multi-cloud orchestration game, that a simpler solution to this
>> multi-region
>> OpenStack deployment use case would be to simply have a global Glance and
>> Keystone infrastructure that can seamlessly scale to multiple regions.
>>
>> That way, there'd be no need for replicating anything.
>>
>
> One use-case I've seen for this sort of thing is someone that has multiple
> geographically-separate clouds, and maybe they want to run the same heat
> stack in all of them.
>
> So they can use global glance/keystone, but they need to ensure that they
> have the right flavor(s) available in all the clouds.  This needs to be
> done by the admin user, so it can't be done as part of the normal user's
> heat stack.


> Something like "create a keypair in each of the clouds with the same
> public key and same name" could be done by the end user with some coding,
> but it's convenient to have a tool to do it for you.
>
> Chris
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Kuryr] Rocky Kuryr PTL candidacy

[Daniel Mellado]

Dear all,

I'd like to announce my candidacy for PTL of the Kuryr project for the
Rocky cycle.

After being part of the Kuryr community for a while and running the
Upstream meetings for a while I'd be delighted to continue the Toni's
great work as PTL for the next six months as he won't be running for it
this cycle.

I do intend to keep acting as an interface for the cross-project
sessions and try to use this cycle to grow on requirements and stability.

Within the Rocky cycle there's a few topics I'd like to care about:

- Further enhance our testing coverage and SDN matrix.

- Kubernetess network policies.

- SRIOV support in Kuryr-Kubernetes.

- Multi pool driver.

- Further improve debugging and instrospection tools using Kubernetes
plugins.

Also, I'll try to support the visibility within the community and be a
mediator
for growing the project scope.

Thanks a lot!

Daniel Mellado (dmellado)

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



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] [all][Kingbird]Multi-Region Orchestrator

[Goutham Pratapa]

Hi Zane,

Thanks for writing to us.

We have a doubt and I have mentioned in the inline comments can you please
help us in that regard.

On Tue, Feb 6, 2018 at 11:53 PM, Zane Bitter  wrote:

> On 31/01/18 01:49, Goutham Pratapa wrote:
>
>> *Kingbird (The Multi Region orchestrator):*
>>
>> We are proud to announce kingbird is not only a centralized quota and
>> resource-manager but also a  Multi-region Orchestrator.
>>
>
> I'd invite you to consider coming up with a different short description
> for the project, because this one reads ambiguously. It can be interpreted
> as either an orchestrator that works across multiple regions, or a tool
> that 'orchestrates' multiple regions for some new definition of
> 'orchestration' (and I regret that we already have more than one). I gather
> you mean the latter; the former already exists in OpenStack.

>Yes as you said it can be interpreted as a tool that can orchestrate
> multiple-regions.

Just to be sure does openstack already has project which can replicate the
> resources and orchestrate??? why because In coming cycle our idea is that a
> user just gives a VM-ID or Vm-name and we sync all the resources with which
> the vm is actually created ofcourse we cant have the same network in
> target-region so we may need the network-id or port-id from the target
> region from user so that kingbird will boot up the requested vm in the
> target region(s).
>

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



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

[openstack-dev] [packaging-rpm] PTL candidacy

[Javier Pena]

Hello fellow packagers!

I would like to announce my candidacy to be the PTL for the Packaging Rpm
project during the Rocky development cycle.

During the last cycles, the project has become a great collaboration space for
people working on RPM packages for OpenStack products. We have a number of
great tools that help us in different areas, even beyond the boundaries of
RPM-based distributions [1], and a wide, up-to-date package set.

For the Rocky cycle, my focus would be on:

* Fixing 3rd party CI annoyances: we are often getting hit by known issues in
  the 3rd party CI systems. Let's try to work on those known issues and reduce
  their occurrence to a minimum, so we can spend more time on reviews and less
  time troubleshooting our CI.

* Work on getting the packages created by the project tested by some installer
  project. This would greatly help us in improving quality on those small
  details that only get caught during real life tests.

* Expanding OpenStack distribution usage of the artifacts generated by the
  Packaging Rpm project.

That, of course, would be in addition to our common goals: expanding our
contributor base, improving collaboration between RPM distributions, and
keeping a high quality set of packages.

Thanks for reading,
Javier

[1] - 
https://github.com/openstack/pymod2pkg/blob/master/pymod2pkg/__init__.py#L294-L316

__
OpenStack Development Mailing 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][ironic][neutron][swift][tricircle][vitrage][watcher] Help needed for your release

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I will request to a create stable/queens branch for Vitrage later today.

Thanks,
Ifat.

On 07/02/2018, 18:49, "Matthew Thode"  wrote:

On 18-02-07 16:33:52, Luke Hinds wrote:
> On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode 
> wrote:
> 
> > Hi all,
> >
> > it looks like some of your projects may need to cut a queens
> > branch/release.  Is there anything we can do to move it along?
> >
> > The following is the list I'm working off of (will be updated as
> > projects release)
> > https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
> >
> > As of right now it's as follows.
> 
> 
> From what I know anchor (security) has no maintainers / cores now, so I
> guess it would make sense to perhaps archive (I will follow this through
> outside this thread), so for now there is no need to tag a queens branch /
> release.

Ya, a bunch of those are maintainerless, the ones of primary concern are
those managed by ironic, swift, tricircle, vitrage, watcher, heat and 
neutron

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [release][ptl] Missing and old intermediary projects

[Bedyk, Witold]

Hi Sean,

thanks for the reminder. The changes for Monasca release are under way [1, 2].

Best greetings
Witek

[1] https://review.openstack.org/541767
[2] https://review.openstack.org/541776


> -Original Message-
> From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
> Sent: Freitag, 2. Februar 2018 23:35
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [release][ptl] Missing and old intermediary projects
> 
> Hey all,
> 
> Sending this kind of late on a Friday, but I will also include this 
> information in
> the weekly countdown email. Just hoping to increase the chances of it
> getting seen.
> 
> One of our release models is cycle-with-intermediary. With this type of
> project, the projects are able to do full releases at any time, with the
> commitment "to produce a release near the end of the 6-month
> development cycle to be used with projects using the other cycle-based
> release models".
> 
> Ideally, this means these projects will have one or more releases during the
> development cycle, and will have a final release leading up to the RC1
> deadline. This "final" release is then used to cut a stable/queens branch for
> the project.
> 
> Well, the RC1 milestone is coming up next Thursday, and we have a few
> projects following this release model that have not done any release yet for
> Queens.
> There are other projects that have done a Queens release, but it has been
> awhile since those were done, so we're not really sure if they are intended
> to be the last official release for Queens.
> 
> For those without a release - if nothing is done in time - the release team 
> will
> need to force a release off of HEAD to be able to create the stable/queens
> branch.
> 
> For those with old Queens releases - unless we hear otherwise, we will need
> to use the point of that last release to cut stable/queens for those repos.
> 
> The release team would rather not be the ones to decide when projects are
> released, nor be the ones to decide what becomes stable/queens for these
> projects. Please make every effort to release and/or branch these projects
> before next Thurday's deadline.
> 
> The projects with existing but old Queens releases are:
> 
> - swift
> - storlets
> - monasca / monasca-log-api
> 
> The projects that have not yet done a Queens intermediary release are:
> 
> - aodh, ceilometer, panko
> - heat-translator
> - ironic-ui
> - monasca-kibana-plugin, monasca-thresh
> - murano-agent
> - patrole
> - tacker-horizon
> - tripleo-quickstart
> - zun, zun-ui
> 
> For some of these, it might make sense to switch to a different release
> model.
> Some of the more mature ones may be better as "independent".
> 
> If you have any questions or problems that the release team can help with,
> please come see us in the #openstack-release channel.
> 
> Thanks,
> 
> Sean (smcginnis)
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume
[2] https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix
[3] 
https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html


Best Regards,
Ifat.


From: Paul Vaduva 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 7 February 2018 at 15:50
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: Ciprian Barbu 
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Ifat,

Yes I’ve checked the 1.3.1 refers to a deb package (python-vitrage) version 
built by us, so the git tag used to build that deb is 1.3.0.
But I also backported doctor datasource from vitreage git master branch.

I also noticed that when I configure snapshots_interval=10 I also get this 
exception in
/var/log/vitrage/graph.log around the time the alarms disapear.
https://hastebin.com/ukisajojef.sql

I've cherry picked your before mentioned change and the alarm that came from 
event is now persistent and the exception is gone.
So it was a bug.
I understand that for doctor datasources I need to have events for raising the 
alarm and also for clearing it is that correct?


Best Regards,
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 1:24 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


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


Best Regards,
Ifat.


From: Paul Vaduva >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, 7 February 2018 at 11:58
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention 

Re: [openstack-dev] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Dmitry Tantsur]

Hi,

On 02/07/2018 05:23 PM, Matthew Thode wrote:

Hi all,

it looks like some of your projects may need to cut a queens
branch/release.  Is there anything we can do to move it along?


Review patches? Make the gate work faster? :)

The Ironic team is working on it, we expect stable/queens requests to come later 
today or early tomorrow. Two more comments inline.




The following is the list I'm working off of (will be updated as
projects release)
https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f

As of right now it's as follows.

# Projects without team or release model could not be found in 
openstack/releases for queens
openstack/almanach
openstack/compute-hyperv
openstack/ekko
openstack/gce-api
openstack/glare
openstack/ironic-staging-drivers


I don't think non-official projects get tracked via openstack/releases.


openstack/kosmos
openstack/mixmatch
openstack/mogan
openstack/nemesis
openstack/networking-dpm
openstack/networking-l2gw
openstack/networking-powervm
openstack/nova-dpm
openstack/nova-lxd
openstack/nova-powervm
openstack/os-xenapi
openstack/python-cratonclient
openstack/python-glareclient
openstack/python-kingbirdclient
openstack/python-moganclient
openstack/python-oneviewclient
openstack/python-valenceclient
openstack/swauth
openstack/tap-as-a-service
openstack/trio2o
openstack/valence
openstack/vmware-nsx
openstack/vmware-nsxlib

# Projects missing a release/branch for queens
openstackclientOpenStackClient
anchor Security
ec2-apiec2-api
django_openstack_auth  horizon
horizon-cisco-ui   horizon
bifrostironic > 
ironic-python-agent-builderironic


This one is empty and will not be released for Queens.


magnum magnum
magnum-ui  magnum
manila-image-elements  manila
masakari   masakari
masakari-monitors  masakari
python-masakariclient  masakari
os-service-types   shade
tacker tacker # I think 
this one is released
tacker-horizon tacker # but not 
this one

# Repos with type: horizon-plugin  (typically release a little later)
manila-ui  manila
neutron-vpnaas-dashboard   neutron
senlin-dashboard   senlin
solum-dashboardsolum
watcher-dashboard  watcher

# Repos with type: other
heat-agentsheat
ironic-python-agentironic
kuryr-kubernetes   kuryr
neutron-vpnaas neutron
networking-hyperv  winstackers

# Repos with type: service
ironic ironic
swift  swift
tricircle  tricircle
vitragevitrage
watcherwatcher



__
OpenStack Development Mailing 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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Ed Leafe]

On Feb 2, 2018, at 2:11 AM, Duncan Thomas  wrote:
> 
> So I guess my question here is why is being RESTful good? Sure it's (very, 
> very loosely) a standard, but what are the actual advantages? Standards come 
> and go, what we want most of all is a good quality, easy to use API.

REST is HTTP. I don’t think that that is a “loose” standard by any measure.

> I'm not saying that going RESTful is wrong, but I don't see much discussion 
> about what the advantages are, only about how close we are to implementing it.

Here’s a quick summary of the advantages, courtesy of SO:

https://stackoverflow.com/questions/5320003/why-we-should-use-rest

REST is the standard for OpenStack APIs. Our job in the API-SIG is to help all 
projects develop their APIs to be as consistent as possible without using a 
top-down, heavy-handed approach. That’s why we included a suggestion for how to 
make your RPC-ish API consistent with other projects that also use an RPC-like 
approach to parts of their API.


-- Ed Leafe






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

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

[Goutham Pratapa]

On Tue, Feb 6, 2018 at 6:03 AM, Jay Pipes  wrote:

> Goutham, comments inline...
>
> Also, FYI, using HTML email with different color fonts to indicate
> different people talking is not particularly mailing list-friendly. For
> reasons why, just check out your last post:
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-Janu
> ary/126842.html
>
> You can't tell who is saying what in the mailing list post...
>
> Much better to use non-HTML email and demarcate responses with the
> traditional > marker. :)
>
> OK, comments inline below.
>
> On 01/31/2018 01:17 PM, Goutham Pratapa wrote:
>
>> Hi Jay,
>>
>> Thanks for the questions.. :)
>>
>> What precisely do you mean by "resources" above ??
>>
>> Resources as-in resources required to boot-up a vm (Keypair, Image,
>> Flavors )
>>
>
> Gotcha. Thanks for the answer.
>
> Also, by "syncing", do you mean "replicating"? The reason I ask is because
>> in the case of, say, VM "resources", you can't "sync" a VM across regions.
>> You can replicate its bootable image, but you can't "sync" a VM's state
>> across multiple OpenStack deployments.
>>
>> Yes as you said syncing as-in replicating only.
>>
>
> Gotcha. You could, of course, actually use synchronous (or semi-sync)
> replication for various databases, including Glance and Keystone's
> identity/assignment information, but yes, async replication is just as good.
>
> and yes we cannot sync vm's across regions but our idea is to
>> sync/replicate all the parameters required to boot a vm
>>
>
> OK, sounds good.
>
> (viz. *image, keypair, flavor*) which are originally there in the source
>> region to the target regions in a single-go.
>>
>
> Gotcha.
>
> Some questions on scope that piqued my interest while reading your
> response...
>
> Is Kingbird predominantly designed to be the multi-region orchestrator for
> OpenStack deployments that are all owned/operated by the same deployer? Or
> does Kingbird have intentions of providing glue services between multiple
> fully-independent OpenStack deployments (possibly operated by different
> deployers)?
>
> Further, does Kingbird intend to get into the multi-cloud (as in AWS,
> OpenStack, Azure, etc) orchestration game?
>>
>>  > For now Kingbird is designed for openstack  deployments that are all
>> owned by the same deployer and yes we would like to get into multi-cloud
>> orchestration dont know how ?? But the idea is there. (If you can please
>> guide us then may be we can acheive this :) )
>
> > We have to see how far we can adhere between different
>> multiple-openstack deployments
>
> I'm curious what you mean by "resource management". Could you elaborate a
>> bit on this?
>>
>> Resource management as-in managing the resources i.e say a user has a
>> glance image(*qcow2 or ami format*) or
>> say flavor(*works only if admin*) with some properties or keypair present
>> in one source regionand he wants the same image or
>> same flavor with same properties or the same keypair in another set of
>> regions user may have to recreate them in all target regions.
>>
>> But with the help of kingbird you can do all the operations in a single
>> go.
>>
>> --> If user wants to sync a resource of type keypair he can replicate the
>> keypair into multiple target regions in single go (similarly glance images
>> and flavors )
>> --> If user wants different type of resource( keypair,image and flavor)
>> in a single go then user can  give a yaml file as input and kingbird
>> replicates all resources in all target regions
>>
>
> OK, I understand your use case here, thanks.
>
> It does seem to me, however, that if the intention is *not* to get into
> the multi-cloud orchestration game, that a simpler solution to this
> multi-region OpenStack deployment use case would be to simply have a global
> Glance and Keystone infrastructure that can seamlessly scale to multiple
> regions.

> Frankly we never tried this. we will have to try this.
>
> That way, there'd be no need for replicating anything.
>
> I suppose what I'm recommending it that instead of the concept of a region
> (or availability zone in Nova for that matter) being a mostly-configuration
> option thing, that the OpenStack contributor community actually work to
> make regions (the concept that Keystone labels a region; which is just a
> grouping of service endpoints) the one and only concept of a user-facing
> "partition" throughout OpenStack.
>
> That way we would have OpenStack services like Glance, Nova, Cinder,
> Neutron, etc just *natively* understand which region they are in and how/if
> they can communicate with other regions.
>
> Sometimes it seems we (as a community) go through lots of hoops working
> around fundamental architectural problems in OpenStack instead of just
> fixing those problems to begin with. See: Nova cellsv1 (and some of
> cellsv2), Keystone federation, the lack of a real availability zone concept
> anywhere, Nova shelve/unshelve (partly developed because VMs and IPs were
> 

Re: [openstack-dev] [heat][horizon][ironic][neutron][swift][tricircle][vitrage][watcher] Help needed for your release

[Matthew Thode]

On 18-02-07 16:33:52, Luke Hinds wrote:
> On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode 
> wrote:
> 
> > Hi all,
> >
> > it looks like some of your projects may need to cut a queens
> > branch/release.  Is there anything we can do to move it along?
> >
> > The following is the list I'm working off of (will be updated as
> > projects release)
> > https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
> >
> > As of right now it's as follows.
> 
> 
> From what I know anchor (security) has no maintainers / cores now, so I
> guess it would make sense to perhaps archive (I will follow this through
> outside this thread), so for now there is no need to tag a queens branch /
> release.

Ya, a bunch of those are maintainerless, the ones of primary concern are
those managed by ironic, swift, tricircle, vitrage, watcher, heat and neutron

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [docs] Documentation meeting minutes for 2018-02-07

[Petr Kovar]

===
#openstack-doc: docteam
===


Meeting started by pkovar at 16:00:38 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-02-07-16.00.log.html
.



Meeting summary
---

* retired internal -core mailing list discussions on new core
  nominations and started discussing core team changes on -dev  (pkovar,
  16:07:28)

* Add deprecation badges to docs.o.o  (pkovar, 16:08:36)
  * LINK: https://review.openstack.org/#/c/530142/  (pkovar, 16:08:41)
  * Under review, further changes required in openstackdocstheme
(pkovar, 16:08:45)

* Rocky PTG  (pkovar, 16:12:12)
  * Planning etherpad for docs+i18n available  (pkovar, 16:12:17)
  * LINK: https://etherpad.openstack.org/p/docs-i18n-ptg-rocky  (pkovar,
16:12:22)
  * Sign up and tell us your ideas on what to discuss in the docs room
(pkovar, 16:12:26)

* Vancouver Summit  (pkovar, 16:13:45)
  * Planning to have a shared 10+10 mins project update slot with i18n
(pkovar, 16:14:00)
  * Looking for interested (co-)speakers  (pkovar, 16:14:34)

* Bug Triage Team  (pkovar, 16:17:17)
  * LINK: https://wiki.openstack.org/wiki/Documentation/SpecialityTeams
(pkovar, 16:17:23)

* Open discussion  (pkovar, 16:18:33)



Meeting ended at 16:22:51 UTC.



People present (lines said)
---

* pkovar (33)
* openstack (3)
* jamesmcarthur (1)



Generated by `MeetBot`_ 0.1.4


__
OpenStack Development Mailing 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]

[Luke Hinds]

On Wed, Feb 7, 2018 at 4:23 PM, Matthew Thode 
wrote:

> Hi all,
>
> it looks like some of your projects may need to cut a queens
> branch/release.  Is there anything we can do to move it along?
>
> The following is the list I'm working off of (will be updated as
> projects release)
> https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f
>
> As of right now it's as follows.


>From what I know anchor (security) has no maintainers / cores now, so I
guess it would make sense to perhaps archive (I will follow this through
outside this thread), so for now there is no need to tag a queens branch /
release.
__
OpenStack Development Mailing 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers] Hel

[Matthew Thode]

Hi all,

it looks like some of your projects may need to cut a queens
branch/release.  Is there anything we can do to move it along?

The following is the list I'm working off of (will be updated as
projects release)
https://gist.github.com/prometheanfire/9449355352d97207aa85172cd9ef4b9f

As of right now it's as follows.

# Projects without team or release model could not be found in 
openstack/releases for queens
openstack/almanach
openstack/compute-hyperv
openstack/ekko
openstack/gce-api
openstack/glare
openstack/ironic-staging-drivers
openstack/kosmos
openstack/mixmatch
openstack/mogan
openstack/nemesis
openstack/networking-dpm
openstack/networking-l2gw
openstack/networking-powervm
openstack/nova-dpm
openstack/nova-lxd
openstack/nova-powervm
openstack/os-xenapi
openstack/python-cratonclient
openstack/python-glareclient
openstack/python-kingbirdclient
openstack/python-moganclient
openstack/python-oneviewclient
openstack/python-valenceclient
openstack/swauth
openstack/tap-as-a-service
openstack/trio2o
openstack/valence
openstack/vmware-nsx
openstack/vmware-nsxlib

# Projects missing a release/branch for queens
openstackclientOpenStackClient
anchor Security
ec2-apiec2-api
django_openstack_auth  horizon
horizon-cisco-ui   horizon
bifrostironic
ironic-python-agent-builderironic
magnum magnum
magnum-ui  magnum
manila-image-elements  manila
masakari   masakari
masakari-monitors  masakari
python-masakariclient  masakari
os-service-types   shade
tacker tacker # I think 
this one is released
tacker-horizon tacker # but not 
this one

# Repos with type: horizon-plugin  (typically release a little later)
manila-ui  manila
neutron-vpnaas-dashboard   neutron
senlin-dashboard   senlin
solum-dashboardsolum
watcher-dashboard  watcher

# Repos with type: other
heat-agentsheat
ironic-python-agentironic
kuryr-kubernetes   kuryr
neutron-vpnaas neutron
networking-hyperv  winstackers

# Repos with type: service
ironic ironic
swift  swift
tricircle  tricircle
vitragevitrage
watcherwatcher

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [all][Kingbird]Multi-Region Orchestrator

[Chris Friesen]

On 02/05/2018 06:33 PM, Jay Pipes wrote:


It does seem to me, however, that if the intention is *not* to get into the
multi-cloud orchestration game, that a simpler solution to this multi-region
OpenStack deployment use case would be to simply have a global Glance and
Keystone infrastructure that can seamlessly scale to multiple regions.

That way, there'd be no need for replicating anything.


One use-case I've seen for this sort of thing is someone that has multiple 
geographically-separate clouds, and maybe they want to run the same heat stack 
in all of them.


So they can use global glance/keystone, but they need to ensure that they have 
the right flavor(s) available in all the clouds.  This needs to be done by the 
admin user, so it can't be done as part of the normal user's heat stack.


Something like "create a keypair in each of the clouds with the same public key 
and same name" could be done by the end user with some coding, but it's 
convenient to have a tool to do it for you.


Chris

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

Re: [openstack-dev] [requirements][release] FFE for constraints update for python-tackerclient bug-fix release

[Matthew Thode]

On 18-02-07 23:01:25, Yongsheng Gong wrote:
> Hi,
> 
> The tacker client has na initial queens release which does not have right 
> reno notes. Recently I have added some reno patches.
> And also the team wants a feature  to land in the queens release.
> 
> I have requested the newer release at 
> https://review.openstack.org/#/c/541638/ 
> 
> 
> The new feature is at https://review.openstack.org/#/c/541631/ 
> 
> 
> Please see how we can get it released?
> 

It should have time to get in for the freeze, the question I have is
'What in openstack is broken if we update upper-contraints after the
freeze instead of before?'

A follow up question is 'does this need a global-requirements.txt bump?'

+2 from me on the UC bump though

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [all][kolla][rdo] Collaboration with Kolla for the RDO test days

[David Moreau Simard]

Please note that the RDO test days have currently been re-scheduled to
(at least) next week, February 15th and 16th.

We are currently working our way through different issues and hope
they'll be sorted out in time by then.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Mon, Feb 5, 2018 at 10:31 AM, David Moreau Simard
 wrote:
> Hi everyone,
>
> We've started planning the deployment with the Kolla team, you can see
> the etherpad from the "operator" perspective here:
> https://etherpad.openstack.org/p/kolla-rdo-m3
>
> We'll advertise the test days and how users can participate soon.
>
> Thanks,
>
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Mon, Jan 29, 2018 at 8:29 AM, David Moreau Simard
>  wrote:
>> Hi !
>>
>> For those who might be unfamiliar with the RDO [1] community project:
>> we hang out in #rdo, we don't bite and we build vanilla OpenStack
>> packages.
>>
>> These packages are what allows you to leverage one of the deployment
>> projects such as TripleO, PackStack or Kolla to deploy on CentOS or
>> RHEL.
>> The RDO community collaborates with these deployment projects by
>> providing trunk and stable packages in order to let them develop and
>> test against the latest and the greatest of OpenStack.
>>
>> RDO test days typically happen around a week after an upstream
>> milestone has been reached [2].
>> The purpose is to get everyone together in #rdo: developers, users,
>> operators, maintainers -- and test not just RDO but OpenStack itself
>> as installed by the different deployment projects.
>>
>> We tried something new at our last test day [3] and it worked out great.
>> Instead of encouraging participants to install their own cloud for
>> testing things, we supplied a cloud of our own... a bit like a limited
>> duration TryStack [4].
>> This lets users without the operational knowledge, time or hardware to
>> install an OpenStack environment to see what's coming in the upcoming
>> release of OpenStack and get the feedback loop going ahead of the
>> release.
>>
>> We used Packstack for the last deployment and invited Packstack cores
>> to deploy, operate and troubleshoot the installation for the duration
>> of the test days.
>> The idea is to rotate between the different deployment projects to
>> give every interested project a chance to participate.
>>
>> Last week, we reached out to Kolla to see if they would be interested
>> in participating in our next RDO test days [5] around February 8th.
>> We supply the bare metal hardware and their core contributors get to
>> deploy and operate a cloud with real users and developers poking
>> around.
>> All around, this is a great opportunity to get feedback for RDO, Kolla
>> and OpenStack.
>>
>> We'll be advertising the event a bit more as the test days draw closer
>> but until then, I thought it was worthwhile to share some context for
>> this new thing we're doing.
>>
>> Let me know if you have any questions !
>>
>> Thanks,
>>
>> [1]: https://www.rdoproject.org/
>> [2]: https://www.rdoproject.org/testday/
>> [3]: 
>> https://dmsimard.com/2017/11/29/come-try-a-real-openstack-queens-deployment/
>> [4]: http://trystack.org/
>> [5]: 
>> http://eavesdrop.openstack.org/meetings/kolla/2018/kolla.2018-01-24-16.00.log.html
>>
>> David Moreau Simard
>> Senior Software Engineer | OpenStack RDO
>>
>> dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[Lance Bragstad]

On 02/07/2018 05:28 AM, Thierry Carrez wrote:
> Lance Bragstad wrote:
>> On 02/05/2018 09:34 AM, Thierry Carrez wrote:
>>> Lance Bragstad wrote:
 Colleen started a thread asking if there was a need for a baremetal/vm
 group session [0], which generated quite a bit of positive response. Is
 there still a possibility of fitting that in on either Monday or
 Tuesday? The group is usually pretty large.

 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html
>>> Yes, we can still allocate a 80-people room or a 30-people one. Let me
>>> know if you prefer Monday, Tuesday or both.
>> Awesome - we're collecting topics in an etherpad, but we're likely only
>> going to get to three or four of them [0] [1]. We can work those topics
>> into two sessions. One on Monday and one on Tuesday, just to break
>> things up in case other things are happening those days that people want
>> to get to.
> Looking at that etherpad, do you need the room allocated for all the day
> on Monday/Tuesday ? It's doable, but if you already know you won't do
> anything on Monday afternoon, we can make that room reservable then.
I agree. I don't think we will need all of Monday and Tuesday. I wanted
to get a rough schedule put together so we wouldn't need to reserve the
entire room all day. So far we haven't received feedback on the proposed
schedule, so it's probably safe to mark the times listed in the etherpad.
>
> What should the track name be ? Some people suggested "cross-project
> identity integration" instead of baremetal-vm.
I'm terrible with names. Since the topics are identity specific, that
would make sense, but I do feel as though we high-jacked the session and
the name =/

I think John Garbutt came up with the original name. I'm sure he can
explain the reasoning for it better than I can.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [tacker] PTL candidacy from yong sheng gong

[Yongsheng Gong]

This is my self-nomination to continue running as Tacker PTL for the
Rocky cycle.

Lots happened in Takcer Queens cycle. More documents, More features are coming
in. VNFFG is enhanced, Kubernetes vim and container VNF are introduced.
Private Zabbix based application monitoring is done too. Openstack client Tacker
commands are also being developed.


In Rocky cycle, I plan to

- Continue to stablize tacker and make it of production quality.
- Go on with tacker document.
- Enhance container based VNF
- Make a way to connect VM based VNF and container Based VNF
- Introduce more types of VIM, such as public vim, SDN controller vim


Thanks for your consideration.

Yong sheng gong










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

[openstack-dev] [requirements][release] FFE for constraints update for python-tackerclient bug-fix release

[Yongsheng Gong]

Hi,

The tacker client has na initial queens release which does not have right reno 
notes. Recently I have added some reno patches.
And also the team wants a feature  to land in the queens release.

I have requested the newer release at https://review.openstack.org/#/c/541638/ 


The new feature is at https://review.openstack.org/#/c/541631/ 


Please see how we can get it released?

Thanks


Yong sheng gong
Tacker

__
OpenStack Development Mailing 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] [docs] Documentation meeting today

[Petr Kovar]

Hi all,

The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
OpenStack Development Mailing 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] Meet DoubleNO³

[Cédric Jeanneret]

Dear all,

In the need of a "lab TripleO" in order to validate updates before
pushing to production, I created some ansible receipt, and a whole
isolated network. This isolated network mimic 1:1 the current
production, and is mainly based on libvirt.

I named this "project" DoubleNO³, and it tells a lot of thing regarding
the concepts and architecture:
Double-NATed-tripleO

Some explanations:

On a dedicated baremetal, I've installed:
- CentOS 7
- Libvirt components

The main VMs are:
- virtualized RedHat Satellite (in order to use repository snapshots)
- virtualized undercloud (prod)
- virtualized undercloud (lab)
- virtualized computes (lab, 4 nodes)
- virtualized controllers (lab, 3 nodes)
- virtualized ceph-storages (lab, 2 nodes, with additional volumes for
Ceph setup emulation)

The lab instances share a network bridge (name it lab-trunk), and each
VM has the "right" amount of network interfaces (we use bonding in prod).

In order to isolate the lab, I've created a second layer, with a
dedicated "prenat" instance (lab-prenat). This one has two interfaces:
- one on a libvirt "NAT" network (eth0)
- one on lab-trunk bridge (eth1)

Regarding IPs, eth0 has a private IP in the 192.168.x.y scope, is the
default route to Internet via the libvirt NAT.
Eth1 has multiple IPs:
- one that emulates the public gateway of our production deploy
- all the IPMI addresses of our productive nodes

The second pool allows to keep Ironic configuration 1:1 with production.
In order to make IPMI calls, I've deployed VirtualBMC on the lab-prenat
instance, and am using the qemu+ssh capability of libvirt in order to
talk to the hypervisor and manage the VMs.

All of that is working pretty nicely together. As I decided to use a
virtual Undercloud node instead of baremetal, it was pretty easy to
duplicate the current undercloud node, drop the stack, and redeploy the
virtual lab in a swift way.

Of course, all wasn't as painless as it seems, I had "some" issues with
the network, especially for IPMI: I wanted to have the virtualBMC
directly on the hypervisor, and had many issues with libvirt itpables
rules. In the end, using the qemu+ssh was just the right, easy way to do
things. And this prevent any IPMI listener to be displayed on the outside.

But in the end: we actually have a 1:1 matching lab we can use in order
to validate every updates, and an easy way to rollback to a previous
consistent state using libvirt snapshots.

Would anyone be interested in a more "academic" documentation about the
whole stuff (especially the lab itself - satellite is an (interesting)
option)?
If so, where should I push that doc? Probably somewhere in "advanced
deployment" or something like that.

Unfortunately, I don't think I'll be able to open the ansible code soon,
but at least the concepts can be explained, and configuration example
provided.


Cheers,

C.

-- 
Cédric Jeanneret
Senior Linux System Administrator
Infrastructure Solutions

Camptocamp SA
PSE-A / EPFL, 1015 Lausanne

Phone: +41 21 619 10 32
Office: +41 21 619 10 02
Email: cedric.jeanne...@camptocamp.com



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] [ptg] Track around release cycle, consumption models and stable branches

[Sean McGinnis]

On Wed, Feb 07, 2018 at 12:42:05PM +0100, Thierry Carrez wrote:
> Hi everyone,
> 
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
> 

This would be great if we can get some distro/packaging representation in the
room.


__
OpenStack Development Mailing 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] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Ifat,

Yes I’ve checked the 1.3.1 refers to a deb package (python-vitrage) version 
built by us, so the git tag used to build that deb is 1.3.0.
But I also backported doctor datasource from vitreage git master branch.

I also noticed that when I configure snapshots_interval=10 I also get this 
exception in
/var/log/vitrage/graph.log around the time the alarms disapear.
https://hastebin.com/ukisajojef.sql

I've cherry picked your before mentioned change and the alarm that came from 
event is now persistent and the exception is gone.
So it was a bug.
I understand that for doctor datasources I need to have events for raising the 
alarm and also for clearing it is that correct?


Best Regards,
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 1:24 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


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


Best Regards,
Ifat.


From: Paul Vaduva >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, 7 February 2018 at 11:58
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

Best Regards,
Paul Vaduva
__
OpenStack Development Mailing 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] [acceleration]Cyborg Team Weekly Meeting 2018.02.07

[Zhipeng Huang]

Hi Team,

Weekly meeting happen starting UTC1500 at #openstack-cyborg , we will wrap
up all the remaining patches and discuss PTG schedule.

-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[James Page]

Hi Thierry

On Wed, 7 Feb 2018 at 11:42 Thierry Carrez  wrote:

> Hi everyone,
>
> I was wondering if anyone would be interested in brainstorming the
> question of how to better align our release cycle and stable branch
> maintenance with the OpenStack downstream consumption models. That
> includes discussing the place of the distributions, the need for LTS,
> and where does the open source upstream project stop.
>
> I have hesitated to propose it earlier, as it sounds like a topic that
> should be discussed with the wider community at the Forum. And it will,
> but it feels like this needs a deeper pre-discussion in a productive
> setting, and tonyb and eumel8 have been proposing that topic on the
> missing topics etherpad[1], so we might as well take some time at the
> PTG to cover that.
>
> Would anyone be interested in such a discussion ? It would be scheduled
> on the Tuesday. How much time would we need ? I was thinking we could
> use only Tuesday afternoon.


I would be interested in participating in this (and I'll still be around
Tuesday PM).

Cheers

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

[openstack-dev] [ptg] Track around release cycle, consumption models and stable branches

[Thierry Carrez]

Hi everyone,

I was wondering if anyone would be interested in brainstorming the
question of how to better align our release cycle and stable branch
maintenance with the OpenStack downstream consumption models. That
includes discussing the place of the distributions, the need for LTS,
and where does the open source upstream project stop.

I have hesitated to propose it earlier, as it sounds like a topic that
should be discussed with the wider community at the Forum. And it will,
but it feels like this needs a deeper pre-discussion in a productive
setting, and tonyb and eumel8 have been proposing that topic on the
missing topics etherpad[1], so we might as well take some time at the
PTG to cover that.

Would anyone be interested in such a discussion ? It would be scheduled
on the Tuesday. How much time would we need ? I was thinking we could
use only Tuesday afternoon.

[1] https://etherpad.openstack.org/p/PTG-Dublin-missing-topics

-- 
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] [ptg] Dublin PTG proposed track schedule

[Dmitry Tantsur]

On 02/07/2018 12:28 PM, Thierry Carrez wrote:

Lance Bragstad wrote:

On 02/05/2018 09:34 AM, Thierry Carrez wrote:

Lance Bragstad wrote:

Colleen started a thread asking if there was a need for a baremetal/vm
group session [0], which generated quite a bit of positive response. Is
there still a possibility of fitting that in on either Monday or
Tuesday? The group is usually pretty large.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html

Yes, we can still allocate a 80-people room or a 30-people one. Let me
know if you prefer Monday, Tuesday or both.

Awesome - we're collecting topics in an etherpad, but we're likely only
going to get to three or four of them [0] [1]. We can work those topics
into two sessions. One on Monday and one on Tuesday, just to break
things up in case other things are happening those days that people want
to get to.


Looking at that etherpad, do you need the room allocated for all the day
on Monday/Tuesday ? It's doable, but if you already know you won't do
anything on Monday afternoon, we can make that room reservable then.

What should the track name be ? Some people suggested "cross-project
identity integration" instead of baremetal-vm.


++ please do not use bm-vm, it confuses everyone not involved from the beginning





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




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

Re: [openstack-dev] [ptg] Dublin PTG proposed track schedule

[Thierry Carrez]

Lance Bragstad wrote:
> On 02/05/2018 09:34 AM, Thierry Carrez wrote:
>> Lance Bragstad wrote:
>>> Colleen started a thread asking if there was a need for a baremetal/vm
>>> group session [0], which generated quite a bit of positive response. Is
>>> there still a possibility of fitting that in on either Monday or
>>> Tuesday? The group is usually pretty large.
>>>
>>> [0]
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.html
>> Yes, we can still allocate a 80-people room or a 30-people one. Let me
>> know if you prefer Monday, Tuesday or both.
> Awesome - we're collecting topics in an etherpad, but we're likely only
> going to get to three or four of them [0] [1]. We can work those topics
> into two sessions. One on Monday and one on Tuesday, just to break
> things up in case other things are happening those days that people want
> to get to.

Looking at that etherpad, do you need the room allocated for all the day
on Monday/Tuesday ? It's doable, but if you already know you won't do
anything on Monday afternoon, we can make that room reservable then.

What should the track name be ? Some people suggested "cross-project
identity integration" instead of baremetal-vm.

-- 
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] [vitrage] Vitrage alarm processing behavior

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi Paul,

It sounds like a bug. Alarms created by a datasource are not supposed to be 
deleted later on. It might be a bug that was fixed in Queens [1].

I’m not sure which Vitrage version you are actually using. I failed to find a 
vitrage version 1.3.1. Could it be that you are referring to a version of 
python-vitrageclient or vitrage-dashboard?

In any case, if you are using an older version, I suggest that you try to use 
the fix that I mentioned [1] and see if it helps.


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


Best Regards,
Ifat.


From: Paul Vaduva 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 7 February 2018 at 11:58
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

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

Re: [openstack-dev] [nova] Notification update week 6

[Balázs Gibizer]

On Tue, Feb 6, 2018 at 7:04 PM, Matt Riedemann  
wrote:

On 2/5/2018 9:32 AM, Balázs Gibizer wrote:

Introduce instance.lock and instance.unlock notifications
-
A specless bp has been proposed to the Rocky cycle
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances 


Some preliminary discussion happened in an earlier patch
https://review.openstack.org/#/c/526251/

Add the user id and project id of the user initiated the instance
action to the notification
-
A new bp has been proposed
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications 


As the user who initiates the instance action (e.g. reboot) could be
different from the user owning the instance it would make sense to
include the user_id and project_id of the action initiatior to the
versioned instance action notifications as well.


Both should be mentioned during the 'open discussion' part of the 
weekly nova meeting but at first glance I think these are both OK.


I've added them to the agenda for tomorrow.

cheers,
gibi


--

Thanks,

Matt

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [glance][cinder]Question about cinder as glance store

[Gorka Eguileor]

On 07/02, Rikimaru Honjo wrote:
> Hello,
>
> I'm planning to use cinder as glance store.
> And, I'll setup cinder to connect storage by iSCSI multipath.
>
> In this case, can I run glance-api and cinder-volume on the same node?
>
> In my understanding, glance-api will attach a volume to own node and
> write a uploaded image to the volume if glance backend is cinder.
> I afraid that the race condition of cinder-volume's iSCSI operations
> and glance-api's iSCSI operations.
> Is there possibility of occurring it?
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi,

When properly set with the right configuration and the right system and
OpenStack packages, Cinder, OS-Brick, and Nova no longer have race
conditions with iSCSI operations anymore (single or multipathed), not
even with drivers that do "shared target".

So I would assume that Glance won't have any issues either as long as
it's properly making the Cinder and OS-Brick calls.

Cheers,
Gorka.

__
OpenStack Development Mailing 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] how to reproduce tripleo ci

[Jiří Stránský]

On 6.2.2018 19:58, Wesley Hayutin wrote:

Greetings,

The TripleO-CI team has added a recreate / reproduce script to all the
tripleo upstream ci jobs as an artifact [1-2] much like the devstack
reproduce.sh script.  If you find yourself in need of recreating a tripleo
ci job please take a look at the instructions.


That looks great, kudos CI team!



At this time the reproduction of ci is only supported by using an openstack
cloud to provision test nodes, libvirt and other approaches are not yet
supported but are on the roadmap.


If someone needs to deploy on libvirt something resembling CI, it seems 
generally possible to use the featuresets as general_config for OOOQ on 
libvirt too (with small tweaks). I've used featuresets to deploy 
overcloud (on a pre-existing reusable undercloud) when working on 
Kubernetes/OpenShift [3-4].


The main thing to watch out for is that the featuresets may be setting 
NIC configs unsuitable for libvirt env. I think those are set either via 
the `network_isolation_args` parameter directly in the featureset, or 
via referencing a t-h-t scenario which includes 
`OS::TripleO::*::Net::SoftwareConfig` overrides in its resource 
registry. So one has to make sure to override those overrides. :)


Jirka



Thank you!

[1]
https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html
[2] http://tripleo.org/contributor/reproduce-ci.html

[3] https://www.jistr.com/blog/2017-11-21-kubernetes-in-tripleo/
[4] https://www.jistr.com/blog/2018-01-04-openshift-origin-in-tripleo/




__
OpenStack Development Mailing 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] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Vitrage developers,

I have a question about vitrage innerworkings, I ported doctor datasource from 
master branch to an earlier version of vitrage (1.3.1).
I noticed some behavior I am wondering if it's ok or it is bug of some sort.
Here it is:
1. I am sending some event for rasing an alarm to doctor datasource of vitrage.
2. I am receiving the event hence the alarm is displayed on vitrage dashboard 
attached to the affected resource (as expected)
3. If I have configured snapshot_interval=10 in /etc/vitrage/vitrage.conf The 
alarm disapears after a while
fragment from /etc/vitrage/vitrage.conf
***
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
snapshots_interval=10
***
On the other hand if I comment it out the alarm persists
**
[datasources]
types = 
nova.host,nova.instance,nova.zone,cinder.volume,neutron.network,neutron.port,doctor
#snapshots_interval=10
**

I am interested if this behavior is correct or is this a bug.
My intention is to create some sort of hybrid datasource starting from the 
doctor one, that receives events for raising alarms like compute.host.down
but uses polling to clear them.

Best Regards,
Paul Vaduva
__
OpenStack Development Mailing 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] [tc] Community Goals for Rocky

[Thierry Carrez]

Matt Riedemann wrote:
> On 2/6/2018 8:44 AM, Emilien Macchi wrote:
>> TC voted (but not approved yet) and selected 2 goals that will likely
>> be approved if no strong voice is raised this week:
>>
>> Remove mox
>> https://review.openstack.org/#/c/532361/
>>
>> Toggle the debug option at runtime
>> https://review.openstack.org/#/c/534605/
>>
>> If you have any comment on these 2 selected goals, please say it now
>> otherwise TC will approve it and we'll discuss about details at the PTG.
> 
> Have we had any substantial input from the elected user committee
> members about their priority for the proposed goals? We have a lot of TC
> input on these, and some (but not much) developer feedback, but it seems
> if we have an elected set of people that represent our users, we should
> get their input on the goals we plan to prioritize community-wide in the
> upcoming release, yeah?

We got a few comments on the reviews and the TC office hours. I'll shoot
a pointer to this thread to openstack-ops to make sure they are aware of it.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat

[Rico Lin]

Hi heat and rally team

Right now, in heat's zuul jobs. We still got one legacy job to change
`legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out here
[2], but after discussion with infra team, it seems best if we can define
this in rally, and reference it in heat.
So my question to rally team for all these will be, do we still need this
job? and how you guys think about if we put that into rally?

[1]
https://github.com/openstack-infra/project-config/blob/master/zuul.d/projects.yaml#L6979
[2] https://review.openstack.org/#/c/509141
-- 
May The Force of OpenStack Be With You,

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