[openstack-dev] [neutron][networking-vpp]networking-vpp 17.10 for VPP 17.10 is available

[Ian Wells]

In conjunction with the release of VPP 17.10, I'd like to invite you all to
try out networking-vpp 17.10(*) for VPP 17.10.  VPP is a fast userspace
forwarder based on the DPDK toolkit, and uses vector packet processing
algorithms to minimise the CPU time spent on each packet and maximise
throughput.  networking-vpp is a ML2 mechanism driver that controls VPP on
your control and compute hosts to provide fast L2 forwarding under Neutron.

This version has a few additional enhancements, along with supporting the
VPP 17.10 API:
- we can now optionally sign data stored in etcd, the communication
mechanism we use, for additional security
- The L3 functionality has been reworked in preparation for HA.

Along with this, there have been the usual upkeep as Neutron versions
change, bug fixes, code and test improvements.

The README [1] explains how you can try out VPP using devstack: the
devstack plugin will deploy the mechanism driver and VPP itself and should
give you a working system with a minimum of hassle.  It will now use the
etcd version deployed by newer versions of devstack.

We will continuing development between now and VPP's 18.02 release in
February.  There are several features we're planning to work on (you'll
find a list in our RFE bugs at [2]), and we welcome anyone who would like
to come help us.

Everyone is welcome to join our biweekly IRC meetings, every other Monday
(the next one is due in a week), 0800 PST = 1600 GMT.
-- 
Ian.

(*) Yes, I know we're in November, but VPP was released last month just
before the summit, and then I went on holiday.  It's called 17.10 to
correspond to the VPP release.
[1]https://github.com/openstack/networking-vpp/blob/master/README.rst
[2]http://goo.gl/i3TzAt
__
OpenStack Development Mailing 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] [mistral][ptl] PTL is on vacation from Nov 23 till Dec 4

[Renat Akhmerov]

Ooh, my apologies for the typo!

Thanks Dougal )

Renat Akhmerov
@Nokia

On 20 Nov 2017, 18:42 +0700, Dougal Matthews , wrote:
>
>
> > On 20 November 2017 at 08:56, Renat Akhmerov  
> > wrote:
> > > Hi,
> > >
> > > I’ll be on vacation from Nov 23 till Dec 4, inclusive. Dougal Matthews 
> > > (d0gal) will be replacing me during this period.
> >
> > It doesn't matter too much, but it is d0ugal if anyone is looking for me on 
> > IRC :-)
> >
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [gnocchi]can we put the api on udp?

[李田清]

Hello,
right now, ceilometer notification agent can send samples by udp publisher..
But gnocchi can only accept by rest api. Is there a way to use udp to 
accept notification agent's samples that sending by udp?


Thanks a lot__
OpenStack Development Mailing 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] Diversity WG

[Amy Marrich]

At the Sydney Summit, there seemed to be interest in re-activating the
Diversity WG. I am sending this email to give some background on the group
as well as to gauge interest.

A charter was proposed to the board May 2015 by Egle Sigler, Kavit Munshi,
and Imad Sousou to form the group [1]. The group was formed a short time
later with Egle Sigler and Carol Barrett as co-chairs and falling under the
oversight of the Board.

The main work of the diversity group was the diversity survey and its
results which were released prior to the Tokyo Summit in October, 2015 and
we had about 20 people show up for the Working Group session held there to
go over the results. A working group session was also held at the Austin
Summit with about 10 people in attendance. It was not long after the Austin
summit that the group membership dwindled down and activity ended.

Things that came out of the work of the Diversity WG are the Git and Gerrit
Lunch and Learn held at the last 5 summits, the Communication Tools Lunch
and Learn held in Barcelona, and the Greeters in Barcelona that were
provided by the Women of OpenStack.

I feel there is still work to do in this area even if only revisiting the
survey and gathering more data that can be evaluated and used to help grow
the community.

If you are interested in helping to revive the Diversity WG please let me
know. The group used the Foundation mailing list (
foundat...@lists.openstack.org) with the [Diversity] tag and still has the
#openstack-diversity channel on Freenode though it is not currently being
logged as Egle and myself until recently were the only 2 members.

Thanks,

Amy Marrich (spotz)

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

[openstack-dev] [nova] No team meeting on Thursday Nov 23

[Matt Riedemann]

Due to the consumption of the cousin of a yard bird plus what I'm sure 
will be a glorious Minnesota Vikings victory, there will be no nova team 
meeting this week.


--

Thanks,

Matt

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

Re: [openstack-dev] Help needed with Fusion SPhere

[Rochelle Grober]

MISTAKE!!!

Ooops.  I’m sorry.  Please ignore.

--Rocky

From: Rochelle Grober
Sent: Monday, November 20, 2017 5:23 PM
To: Farhad Sunavala ; Zhiqiang Yang 

Cc: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: Help needed with Fusion SPhere

Hey, Farhad and Henry.

I am shipping your request to the OpenStack email list.  Though many of these 
people are in China, there are both upstream (OpenStack) and downstream 
(FusionSphere) people on this list.

I hope someone will speak up and work with Henry to accomplish the installation.

Thanks,

--Rocky

From: Farhad Sunavala
Sent: Monday, November 20, 2017 4:54 PM
To: Zhiqiang Yang >
Cc: Rochelle Grober 
>
Subject: Help needed with Fusion SPhere

Hi Rocky,

Henry from SW lab wanted to know who has worked with Fusion Sphere and can help 
him with the installation.
Would you know who can help him out?

Thanks,
Farhad.


Farhad Sunavala
Principal Engineer I Cloud Computing
Tel: 408-330-4499 I Mobile: 408-330-4499 I E-mail: 
farhad.sunav...@huawei.com
Company: Huawei I Address: Santa Clara, CA

[315px-Huawei]http://www.huawei.com
[cid:image002.jpg@01D36226.A42ABD20]
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure,reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it !
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面 
地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！

__
OpenStack Development Mailing 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] Help needed with Fusion SPhere

[Rochelle Grober]

Hey, Farhad and Henry.

I am shipping your request to the OpenStack email list.  Though many of these 
people are in China, there are both upstream (OpenStack) and downstream 
(FusionSphere) people on this list.

I hope someone will speak up and work with Henry to accomplish the installation.

Thanks,

--Rocky

From: Farhad Sunavala
Sent: Monday, November 20, 2017 4:54 PM
To: Zhiqiang Yang 
Cc: Rochelle Grober 
Subject: Help needed with Fusion SPhere

Hi Rocky,

Henry from SW lab wanted to know who has worked with Fusion Sphere and can help 
him with the installation.
Would you know who can help him out?

Thanks,
Farhad.


Farhad Sunavala
Principal Engineer I Cloud Computing
Tel: 408-330-4499 I Mobile: 408-330-4499 I E-mail: 
farhad.sunav...@huawei.com
Company: Huawei I Address: Santa Clara, CA

[315px-Huawei]http://www.huawei.com
[cid:image002.jpg@01D36224.26F3E860]
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure,reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it !
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面 
地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！

__
OpenStack Development Mailing 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] Planning for job execution outside the gate with Zuul v3

[Emilien Macchi]

On Mon, Nov 20, 2017 at 2:31 PM, David Moreau Simard  wrote:
> Hi,
>
> As the migration of review.rdoproject.org to Zuul v3 draws closer, I'd like
> to open up the discussion around how we want to approach an eventual
> migration to Zuul v3 outside the gate.
> I'd like to take this opportunity to allow ourselves to think outside the
> box, think about how we would like to shape the CI of TripleO from upstream
> to the product and then iterate to reach that goal.
>
> The reason why I mention "outside the gate" is because one of the features
> of Zuul v3 is to dynamically construct its configuration by including
> different repositories.
> For example, the Zuul v3 from review.rdoproject.org can selectively include
> parts of git.openstack.org/openstack-infra/tripleo-ci [1] and it will load
> the configuration found there for jobs, nodesets, projects, etc.
>
> This opens a great deal of opportunities for sharing content or centralizing
> the different playbooks, roles and job parameters in one single repository
> rather than spread across different repositories across the production
> chain.
> If we do things right, this could give us the ability to run the same jobs
> (which can be customized with parameters depending on the environment,
> release, scenario, etc.) from the upstream gate down to
> review.rdoproject.org and the later productization steps.
>
> There's pros and cons to the idea, but this is just an example of what we
> can do with Zuul v3.
>
> Another example of an interesting thought from Sagi is to boot virtual
> machines directly with pre-built images instead of installing the
> undercloud/overcloud every time.
> Something else to think about is how can we leverage all the Ansible things
> from TripleO Quickstart in Zuul v3 natively.
>
> There's of course constraints about what we can and can't do in the upstream
> gate... but let's avoid prematurely blocking ourselves and try to think
> about what we want to do ideally and figure out if, and how, we can do it.
> Whether it's about the things that we would like to do, can't do, or the
> things that don't work, I'm sure the feedback and outcome of this could
> prove useful to improve Zuul.
>
> How would everyone like to proceed ? Should we start an etherpad ? Do some
> "design dession" meetings ?
> I'm willing to help get the ball rolling and spearhead the effort but this
> is a community effort :)

It's good you started this thread, I had a discussion with Sam Doran
(on PTO this week AFIK) who is highly invested in Ansible and
motivated to help to have proper playbooks calling
tripleo-quickstart-extras roles.
One of the ideas that we discussed was to remove toci_gate_* scripts
and write Ansible playbooks that call the right modules with the right
variables.

+1 for an etherpad and start planning this work.

> Thanks !
>
> [1]: http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/zuul.d
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]



-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] Planning for job execution outside the gate with Zuul v3

[James E. Blair]

David Moreau Simard  writes:

> The reason why I mention "outside the gate" is because one of the features
> of Zuul v3 is to dynamically construct its configuration by including
> different repositories.
> For example, the Zuul v3 from review.rdoproject.org can selectively include
> parts of git.openstack.org/openstack-infra/tripleo-ci [1] and it will load
> the configuration found there for jobs, nodesets, projects, etc.
>
> This opens a great deal of opportunities for sharing content or
> centralizing the different playbooks, roles and job parameters in one
> single repository rather than spread across different repositories across
> the production chain.
> If we do things right, this could give us the ability to run the same jobs
> (which can be customized with parameters depending on the environment,
> release, scenario, etc.) from the upstream gate down to
> review.rdoproject.org and the later productization steps.

Thanks for starting this thread!  I think it's a great idea.

I'd just like to mention here for folks who may not be aware --
re-usability of this kind is an explicit design goal of Zuul v3.  We're
hoping that the zuul-jobs repo in particular can be used by any Zuul in
the world to run the same job content.  In fact, the core review team
on that repo has already grown to include contributors from outside the
OpenStack ecosystem altogether.

The openstack-zuul-jobs and other individual repos may also provide job
content that's usable by folks operating Zuuls related to OpenStack
(e.g., third-party CI operators and distributors, as is the case here).

And finally, at the very least, if jobs themselves aren't re-usable, we
hope that the Ansible roles they use will be re-usable.  It is for this
reason that we have focused heavily on role development with simplified
playbooks in the common Zuul v3 jobs so far.

-Jim

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

[openstack-dev] [nova] Queens blueprint status tracking

[Matt Riedemann]

For anyone that cares, or would like to use as a type of review 
dashboard, I've started tracking the status of the approved nova 
blueprints for Queens here:


https://etherpad.openstack.org/p/nova-queens-blueprint-status

I've got them categorized as usual and am trying to highlight the ones 
that need core review, e.g. some already have patches with a +2 on them.


--

Thanks,

Matt

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

Re: [openstack-dev] [TripleO] IPSEC integration

[Alex Schultz]

On Thu, Nov 16, 2017 at 12:01 AM, Juan Antonio Osorio
 wrote:
> Hello folks!
>
> A few months ago Dan Sneddon and me worked in an ansible role that would
> enable IPSEC for the overcloud [1]. Currently, one would run it as an extra
> step after the overcloud deployment. But, I would like to start integrating
> it to TripleO itself, making it another option, probably as a composable
> service.
>

Is there a spec for this or at least some more detail as to what
exactly this is solving?  I would really like some more explanation
around this feature than just an ansible role proposal.

> For this, I'm planning to move the tripleo-ipsec ansible role repository
> under the TripleO umbrella. Would that be fine with everyone? Or should I
> add this ansible role as part of another repository? After that's available
> and packaged in RDO. I'll then look into the actual TripleO composable
> service.
>

As I've previously indicated it probably should live under the tripleo
umbrella but I would like to see more details around this prior to
further integration.  It's also very late in the cycle (almost m2) to
be proposing something like this. Is the target for this Rocky?

That being said I don't see anything specific to this role that would
cause problems as part of the deployment process as it exists today.
I do see some possible conflicts around the iptables configuration as
we currently manage that via heat/puppet but I think it's smart enough
to not stomp on each other if we carefully format the rules.  Another
implementation item that might be problematic is the more hard-coded
configuration via template files. What is the plan to make those more
dynamic to support other roles besides just compute/controller?  Right
now tripleo-heat-templates is the source of configuration items that
we expose for the deployment.  What would we be looking to expose to
deployers since what is currently exposed from the role is minimal?

> Any input and contributions are welcome!
>
> [1] https://github.com/JAORMX/tripleo-ipsec
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>

Thanks,
-Alex

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

[openstack-dev] [TripleO] Planning for job execution outside the gate with Zuul v3

[David Moreau Simard]

Hi,

As the migration of review.rdoproject.org to Zuul v3 draws closer, I'd like
to open up the discussion around how we want to approach an eventual
migration to Zuul v3 outside the gate.
I'd like to take this opportunity to allow ourselves to think outside the
box, think about how we would like to shape the CI of TripleO from upstream
to the product and then iterate to reach that goal.

The reason why I mention "outside the gate" is because one of the features
of Zuul v3 is to dynamically construct its configuration by including
different repositories.
For example, the Zuul v3 from review.rdoproject.org can selectively include
parts of git.openstack.org/openstack-infra/tripleo-ci [1] and it will load
the configuration found there for jobs, nodesets, projects, etc.

This opens a great deal of opportunities for sharing content or
centralizing the different playbooks, roles and job parameters in one
single repository rather than spread across different repositories across
the production chain.
If we do things right, this could give us the ability to run the same jobs
(which can be customized with parameters depending on the environment,
release, scenario, etc.) from the upstream gate down to
review.rdoproject.org and the later productization steps.

There's pros and cons to the idea, but this is just an example of what we
can do with Zuul v3.

Another example of an interesting thought from Sagi is to boot virtual
machines directly with pre-built images instead of installing the
undercloud/overcloud every time.
Something else to think about is how can we leverage all the Ansible things
from TripleO Quickstart in Zuul v3 natively.

There's of course constraints about what we can and can't do in the
upstream gate... but let's avoid prematurely blocking ourselves and try to
think about what we want to do ideally and figure out if, and how, we can
do it.
Whether it's about the things that we would like to do, can't do, or the
things that don't work, I'm sure the feedback and outcome of this could
prove useful to improve Zuul.

How would everyone like to proceed ? Should we start an etherpad ? Do some
"design dession" meetings ?
I'm willing to help get the ball rolling and spearhead the effort but this
is a community effort :)

Thanks !

[1]: http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/zuul.d

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

[openstack-dev] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi All,

Friendly reminder that our next meeting is in 10 minutes on 
#openstack-meeting-3.

Meeting agenda etherpad: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

Thanks and Best Regards,
Ildikó



__
OpenStack Development Mailing 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] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Midcycle planning: https://etherpad.openstack.org/p/ironic-queens-midcycle
2. Use adapters for cinderclient: https://review.openstack.org/#/c/476171/
2.1. then also for inspector client: 
https://review.openstack.org/#/c/476172/
3. install guide update for hw types: https://review.openstack.org/#/c/517290/
3.1. before that, separate pages for deploy and boot interfaces: 
https://review.openstack.org/#/c/517632/
4. BIOS interface spec: https://review.openstack.org/#/c/496481/
5. Rescue:
5.1. driver interface https://review.openstack.org/#/c/509335/
5.2. RPC https://review.openstack.org/#/c/509336/
5.3. rescuewait timeout https://review.openstack.org/#/c/353156

Vendor priorities
-
cisco-ucs:
Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:

ilo:
https://review.openstack.org/207337 - Out-of-band Boot from UEFI iSCSI 
volume for HPE Proliant server
irmc:
SPEC to add a new hardware type for another FUJITSU server: PRIMEQUEST MMB:
https://review.openstack.org/#/c/515717/

oneview:
Add validations for OneView ML2 driver -  
https://review.openstack.org/#/c/508946/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
dnsmasq-based inspector PXE filter driver: 
https://review.openstack.org/#/c/466448/ TL;DR: replaces iptables with a 
dynamic configuration of dnsmasq (pretty cool thing too ;)
-   folks might consider trying the test patch to experiment manually with 
this https://review.openstack.org/#/c/468712/54
networking-baremetal:
neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 13 Nov 2017 and 20 Nov 2017)
  - Ironic: 219 bugs (-4) + 254 wishlist items (+7). 11 new (-2), 153 in 
progress (+2), 0 critical, 31 high and 35 incomplete (+1)
  - Inspector: 16 bugs + 31 wishlist items. 0 new (-2), 16 in progress, 0 
critical, 4 high and 5 incomplete (+2)
  - Nova bugs with Ironic tag: 14 (+1). 2 new (+1), 0 critical, 1 high
- HIGH bugs with patches to review:
  - Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
  - prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix to return 'root_uuid' as part of command status 
https://review.openstack.org/#/c/500719/4
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
  - If provisioning network is changed, Ironic conductor does not behave 
correctly https://bugs.launchpad.net/ironic/+bug/1679260: Ironic conductor 
works correctly on changes of networks: https://review.openstack.org/#/c/462931/
- (rloo) needs some direction

CI refactoring and missing test coverage

- Zuul v3 jobs in-tree migration tracking 
https://etherpad.openstack.org/p/ironic-zuulv3-intree-tracking:
- legacy jobs migration: everything migrated except for bifrost 
stable/ocata; one more patch
- cleaning up/centralizing job descriptions (eg 'irrelevant-files'): started
- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- RFE https://bugs.launchpad.net/python-ironicclient/+bug/1671145
- gerrit topic: 

Re: [openstack-dev] [Infra][Cinder] DataCore CI

[Sean McGinnis]

On Mon, Nov 20, 2017 at 09:57:59PM +0300, Mikhail Kebich wrote:
> Hi Sean,
> 
> So, do we need only to change Zuul project to start posting of comments?
> 
> Thanks,
> Mike
> 

Yep, that should be all you need to do.

Sean


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

Re: [openstack-dev] [Infra][Cinder] DataCore CI

[Mikhail Kebich]

Hi Sean,

So, do we need only to change Zuul project to start posting of comments?

Thanks,
Mike

On Mon, Nov 20, 2017 at 7:35 PM, Sean McGinnis 
wrote:

> On Mon, Nov 20, 2017 at 03:25:35PM +0300, Mikhail Kebich wrote:
> > Hello Infra Team,
> >
> > We have deployed DataCore CI to test changes in the Cinder project with
> the
> > DataCore Volume Driver.
> >
> > You can find an information about the DataCore CI system at:
> > https://wiki.openstack.org/wiki/ThirdPartySystems/DataCore_CI
> >
> > Logs are available at:
> > http://173.221.96.158/
> >
> > Could you please grant permission to the datacore-cinder-ci account to
> post
> > comments on changes in the Cinder project?
> >
> > Thanks in advance,
> > Mikhail Kebich
>
> Hi Mikhail,
>
> There are no permissions required to comment. That would only be needed if
> we
> wanted this CI to be able to vote, which we do not do for third party CI in
> Cinder.
>
> Thanks,
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [doc][infra][stable] we are ready to restore stable/mitaka for openstack-manuals

[Paul Belanger]

On Mon, Nov 20, 2017 at 05:40:26PM +0100, Andreas Jaeger wrote:
> On 2017-11-20 17:32, Doug Hellmann wrote:
> > As we agreed in the new documentation retention policy spec [1], I need
> > to restore the stable/mitaka branch for the openstack/openstack-manuals
> > repository and then trigger a build of the mitaka version of the guides.
> > I have a local patch ready that works, so I believe the next steps are
> > to create the branch, propose the patch, and fix whatever infra issues
> > we have due to running the change on such an old branch.
> > 
> > I believe I have the permissions needed to create the branch from the
> > existing mitaka-eol tag. Before I do that, however, I wanted to make
> > sure there are no additional steps needed. Should we delete the tag, for
> > example? Or is creating the branch sufficient?
> 
> Deletion of tag is not really working - everybody that has cloned the
> repo will have the tag locally. So, I suggest to leave it.
> 
> 
> I'm not aware of any other issues, go ahead - but let's wait a day or
> two if anybody else sees a problem,
> 
> Andreas
> 
> 
> > Doug
> > 
> > [1] 
> > http://specs.openstack.org/openstack/docs-specs/specs/queens/retention-policy.html
> 
++ Ready to support if needed.

__
OpenStack Development Mailing 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] [keystone] Upcoming Deadlines

[Lance Bragstad]

Sending out a reminder that we have a couple deadlines approaching.

First, *specification* *freeze* is *two weeks away*. Here is a short
list of things we've committed to but need the specification to merge:

- Unified Limits API [0]
- Application Credentials [1]
- System Scope [2]
- Scope Types [3]

These reviews should take priority.

Second, *feature* *proposal* *freeze* is *four weeks away*. Remember
that this deadline falls earlier than last release due to the holiday
season. So far, only application credentials and unified limits are
missing proposed implementations. Again, these are just proposals.
Feature freeze is January 26th.

If you have spare cycles and want to tag-team one of these efforts with
an existing owner, please don't hesitate to reach out. Let me know if
there is anything I've missed. Thanks!


[0] https://review.openstack.org/#/c/455709/
[1] https://review.openstack.org/#/c/512505/
[2] https://review.openstack.org/#/c/464763/
[3] https://review.openstack.org/#/c/500207/


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

Re: [openstack-dev] [release][ptl] Improving the process for release marketing

[Sean McGinnis]

Hello PTL's, release liaisons, and all those interested.

The changes on our side to support a release cycle highlights page have been
completed, and things have settled a bit from the Summit activies, so I think
now is a good time to get things going again for this.

See below for the background, but if you missed it or have forgotten by now, we
plan to have an easier way to collect significant "highlights" for each release
cycle in order to collect "key features" flagged by each team that marketing
teams can use during release communication times. The goal is to reduce the
number of times PTL's get asked by various groups to "tell us what changed in
this release."

The way we are approaching this is by adding a "cycle-highlights" key to the
deliverable file for your project [1]. This field will take RST formatted text
that will then be rendered into the highlights page we will share with
marketing.

Our goal is to have roughly three "highlights" per team for each release, but
this will vary based on the needs of the team and the amount of work done
during the cycle. If there is only one significant change to share, that is
fine. If there are five, that's OK too. Just keep in mind that these should be
limited to only the significant changes that you feel are worth communicating
to the marketing, sales, and end users out there that need to know what to
expect.

We will want to start collecting this information as we near RC releases, but
feel free to start adding items of interest with the upcoming Queens-2 release
if you already have changes worth noting.

And please ask here or in the #openstack-release channel if you have any
questions about how this works.

Thanks,
Sean

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466

P.S. This is for cycle_* deliverables only. If you see a need for this with the
independent releases, let me know and we can talk about how that might look.


On Tue, Sep 26, 2017 at 02:33:09PM -0700, Anne Bertucio wrote:
> Release marketing is a critical part of sharing what’s new in each release, 
> and we want to rework how the marketing community and projects work together 
> to make the release communications happen. 
> 
> Having multiple, repetetive demands to summarize "top features" during 
> release time can be pestering and having to recollect the information each 
> time isn't an effective use of time. Being asked to make polished, 
> "press-friendly" messages out of release notes can feel too far outside of 
> the PTL's focus areas or skills. At the same time, for technical content 
> marketers, attempting to find the key features from release notes, ML posts, 
> specs, Roadmap, etc., means interesting features are sometimes overlooked. 
> Marketing teams don't have the latest on what features landed and with what 
> caveats.
> 
> To address this gap, the Release team and Foundation marketing team propose 
> collecting information as part of the release tagging process. Similar to the 
> existing (unused) "highlights" field for an individual tag, we will collect 
> some text in the deliverable file to provide highlights for the series (about 
> 3 items). That text will then be used to build a landing page on 
> release.openstack.org that shows the "key features" flagged by PTLs that 
> marketing teams should be looking at during release communication times. The 
> page will link to the release notes, so marketers can start there to gather 
> additional information, eliminating repetitive asks of PTLs. The "pre 
> selection" of features means marketers can spend more time diving into 
> release note details and less sifting through them.
> 
> To supplement the written information, the marketing community is also going 
> to work together to consolidate follow up questions and deliver them in 
> "press corps" style (i.e. a single phone call to be asked questions from 
> multiple parties vs. multiple phone calls from individuals).
> 
> We will provide more details about the implementation for the highlights page 
> when that is ready, but want to gather feedback about both aspects of the 
> plan early.
> 
> Thanks for your input,
> Anne Bertucio and Sean McGinnis
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing 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] [ironic] save the date: virtual midcycle on Nov 27th

[Dmitry Tantsur]

On 11/20/2017 05:49 PM, Dmitry Tantsur wrote:

Hi all!

The winning date for the midcycle is Nov 27th. The call will take up to 4 hours, 
3pm UTC to 7pm UTC (unless I'm confusing time zones again). We will use the 
bluejeans room https://bluejeans.com/973312948 (works without plugins in recent 
browsers, see the etherpad for details).


Please also keep adding potential topics to 
https://etherpad.openstack.org/p/ironic-queens-midcycle


Small update: we have 4 topics for 4 hours already. We will cover additional 
topics only if time allows. Also if your topic requires any preparation, please 
propose it ASAP.




Dmitry



__
OpenStack Development Mailing 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] save the date: virtual midcycle on Nov 27th

[Dmitry Tantsur]

Hi all!

The winning date for the midcycle is Nov 27th. The call will take up to 4 hours, 
3pm UTC to 7pm UTC (unless I'm confusing time zones again). We will use the 
bluejeans room https://bluejeans.com/973312948 (works without plugins in recent 
browsers, see the etherpad for details).


Please also keep adding potential topics to 
https://etherpad.openstack.org/p/ironic-queens-midcycle


Dmitry

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

Re: [openstack-dev] [oslo][oslo.config] pluggable drivers for oslo.config spec ready for review

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2017-11-20 11:02:33 -0500:
> On 11/20/2017 10:19 AM, Doug Hellmann wrote:
> > The spec for adding pluggable drivers to oslo.config is ready for a
> > final queens review [1]. The latest draft should be simpler to implement
> > (important given where we are in the schedule) at the expense of always
> > requiring at least one configuration file to specify the location of
> > other configuration sources. We can improve on that design in the future
> > when we have the drivers working.
> 
> Hi Doug. Is this spec crucial for various PCI/security-minded folks to 
> review due to how plaintext configuration options are currently handled 
> for sensitive things like password and user/project IDs?
> 
> Best,
> -jay
> 

The spec is meant to enable securely storing secrets, but it's
foundation work before the secret store driver can actually be
implemented so it doesn't go into a lot of detail about the castellan
driver. Still, I would appreciate if the folks interested in that
feature look at it.

Doug

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

[openstack-dev] [tripleo] Status of CI

[Alex Schultz]

Hey folks,

So over the weekend we have successfully moved our jobs in-tree with
zuul v3 thanks to Emilien's hard work.  There are a few outstanding
issues with some stable branches that he is working on.  Additionally
we have switched scenario001 and scenaio003 to non-voting due to Bug
1731063[0].  We are still occasionally hitting heat issues due to Bug
1731032[1], however there is a possible fix for that one.  So I think
we're OK to start merging items in master as needed.   Do take some
time to review the current outstanding alerts as they do affect our
ability to merge fixes.  Also please check any new failures that might
occur to ensure we are not just ignoring other possible issues.

Thanks,
-Alex

[0] https://bugs.launchpad.net/tripleo/+bug/1731063
[1] https://bugs.launchpad.net/tripleo/+bug/1731032

__
OpenStack Development Mailing 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] [doc][infra][stable] we are ready to restore stable/mitaka for openstack-manuals

[Andreas Jaeger]

On 2017-11-20 17:32, Doug Hellmann wrote:
> As we agreed in the new documentation retention policy spec [1], I need
> to restore the stable/mitaka branch for the openstack/openstack-manuals
> repository and then trigger a build of the mitaka version of the guides.
> I have a local patch ready that works, so I believe the next steps are
> to create the branch, propose the patch, and fix whatever infra issues
> we have due to running the change on such an old branch.
> 
> I believe I have the permissions needed to create the branch from the
> existing mitaka-eol tag. Before I do that, however, I wanted to make
> sure there are no additional steps needed. Should we delete the tag, for
> example? Or is creating the branch sufficient?

Deletion of tag is not really working - everybody that has cloned the
repo will have the tag locally. So, I suggest to leave it.


I'm not aware of any other issues, go ahead - but let's wait a day or
two if anybody else sees a problem,

Andreas


> Doug
> 
> [1] 
> http://specs.openstack.org/openstack/docs-specs/specs/queens/retention-policy.html



-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

[Ruby Loo]

Thanks for bringing this up Dmitry. See inline...

On Tue, Nov 14, 2017 at 5:05 PM, Alex Schultz  wrote:

> On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur 
> wrote:
> > Hi folks!
> >
> > This was raised several times, now I want to bring it to the wider
> audience.
> > We're planning [1] to deprecate classic drivers in Queens and remove
> them in
> > Rocky. It was pointed at the Forum that we'd better provide an automatic
> > migration.
> >
> > I'd like to hear your opinion on the options:
> >
> > (1) Migration as part of 'ironic-dbsync upgrade'
> >
> > Pros:
> > * nothing new to do for the operators
> >
> > Cons:
> > * upgrade will fail completely, if for some nodes the matching hardware
> > types and/or interfaces are not enabled in ironic.conf
> >
>

ironic-dbsync upgrade has always (I think) been used to *only* update the
database schema. Not change the actual data in the database. I don't think
this is the right place to be doing this 'migration'.


> > (2) A separate script for migration
> >
> > Pros:
> > * can be done in advance (even while still on Pike)
> > * a failure won't fail the whole upgrade
> > * will rely on drivers enabled in actually running conductors, not on
> > ironic.conf
> >
> > Cons:
> > * a new upgrade action before Rocky
> > * won't be available in packaging
> > * unclear how to update nodes that are in some process (e.g. cleaning),
> will
> > probably have to be run several times
> >
> > (3) Migration as part of 'ironic-dbsync online_data_migration'
> >
> > Pros:
> > * nothing new to do for the operators, similar to (1)
> > * probably a more natural place to do this than (1)
> > * can rely on drivers enabled in actually running conductors, not on
> > ironic.conf
> >
> > Cons:
> > * data migration will fail, if for some nodes the matching hardware types
> > and/or interfaces are not enabled in ironic.conf
> >
>

The online_data_migration exists for situations just like this; migration
of data :) So this is my vote. It is fine if the call fails, this lets the
operators know that they will need to make changes. If we go with this, I
envision it working something like:

Queens: deprecate classic drivers
Queens: 'ironic-dbsync online_data_migrations' is run (at any point in
time, while ironic services are running). Among other things, it would
migrate classic drivers to hardware types, failing if needed hardware types
or interfaces are not enabled in the config file.
This must succeed before upgrading to Rocky
Rocky: if you try to upgrade to Rocky and the above Queens' ironic-dbsync
online_data_migrations fails, you will not be able to upgrade.


> Rather than fail in various ways, why not do like what nova has with a
> pre-upgrade status check[0] and then just handle it in ironic-dbsync
> upgrade?   This would allow operators to check prior to running the
> upgrade to understand what might need to be changed.  Additionally the
> upgrade command itself could leverage the status check to fail nicely.
>
>
I like the idea of a status check, although I am doubtful that it is
do-able in Queens, given the goals we have. But of course, that can be up
for discussion etc.


> > (4) Do nothing, let operators handle the migration.
> >
>
> Please no.
>
> >
> > The most reasonable option for me seems (3), then (4). What do you think?
> >
>
> So this was chatted about in relation to some environment tooling we
> have where we currently have where older 'pxe_ipmitool' defined and
> this will need to switch to be 'ipmi'[1]. The issue with the hard
> cutover on this one is any tooling which may have been written that
> currently works with multiple openstack releases to generate the
> required json for ironic will now have to take that into account.  I
> know in our case we'll be needing to support newton for longer so
> making the tooling openstack aware around this is just further
> tech-debt that we'll be creating. Is there a better solution that
> could be done either in ironic client or in the API to gracefully
> handle this transition for a longer period of time?  I think this may
> be one of those decisions that has a far reaching impact on
> deployers/operators due changes they will have to make to support
> multiple versions or as they upgrade between versions and they aren't
> fully aware of yet as many may not be on Ocata.  This change seems
> like it has a high UX impact and IMHO should be done very carefully.
>


It seems to me that if this going to cause undue hardship, that we consider
prolonging the deprecation period for eg. another cycle. I guess I'd like
to get an idea of how long is reasonable, to handle this transition... How
do we get more data points on this, or is Alex the representative for our
users out there? :)

--ruby


>
> Thanks,
> -Alex
>
> [0] https://docs.openstack.org/nova/pike/cli/nova-status.html
> [1] http://eavesdrop.openstack.org/irclogs/%23tripleo/%
> 23tripleo.2017-11-14.log.html#t2017-11-14T15:36:45
>
>
> > Dmitry

Re: [openstack-dev] [Infra][Cinder] DataCore CI

[Sean McGinnis]

On Mon, Nov 20, 2017 at 03:25:35PM +0300, Mikhail Kebich wrote:
> Hello Infra Team,
> 
> We have deployed DataCore CI to test changes in the Cinder project with the
> DataCore Volume Driver.
> 
> You can find an information about the DataCore CI system at:
> https://wiki.openstack.org/wiki/ThirdPartySystems/DataCore_CI
> 
> Logs are available at:
> http://173.221.96.158/
> 
> Could you please grant permission to the datacore-cinder-ci account to post
> comments on changes in the Cinder project?
> 
> Thanks in advance,
> Mikhail Kebich

Hi Mikhail,

There are no permissions required to comment. That would only be needed if we
wanted this CI to be able to vote, which we do not do for third party CI in
Cinder.

Thanks,
Sean

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

[openstack-dev] [doc][infra][stable] we are ready to restore stable/mitaka for openstack-manuals

[Doug Hellmann]

As we agreed in the new documentation retention policy spec [1], I need
to restore the stable/mitaka branch for the openstack/openstack-manuals
repository and then trigger a build of the mitaka version of the guides.
I have a local patch ready that works, so I believe the next steps are
to create the branch, propose the patch, and fix whatever infra issues
we have due to running the change on such an old branch.

I believe I have the permissions needed to create the branch from the
existing mitaka-eol tag. Before I do that, however, I wanted to make
sure there are no additional steps needed. Should we delete the tag, for
example? Or is creating the branch sufficient?

Doug

[1] 
http://specs.openstack.org/openstack/docs-specs/specs/queens/retention-policy.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

Re: [openstack-dev] [ironic] moving the weekly meeting to our channel?

[Ruby Loo]

On Wed, Nov 15, 2017 at 3:35 AM, Dmitry Tantsur  wrote:

> Hi all,
>
> Due to a technical issue we had to have our weekly meeting in our main
> channel this time. And we liked it :) I wonder if we should switch to it.
>
> Pros:
> * easier to find
> * no channel switching
>
> Cons:
> * potential conflicts with other meetings (already a problem, given how
> many rooms we have)
> * blocks the main channel for 1 hour for other business
>
> Opinions?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I think it is a great idea. No nays is a good sign. Let's do it. It'll be
one fewer things to deal with. Anyone that has other business, will find
out what they've been missing.

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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Ruby Loo]

On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker 
wrote:

> Thank you. I too vote for 'Option 1'.
>
> Thanks and Regards
> Shiv
>
>
>
> On Wed, Nov 15, 2017 at 1:03 AM, Villalovos, John L <
> john.l.villalo...@intel.com> wrote:
>
>> Thanks for sending this out.
>>
>>
>>
>> I would vote for Option 1.
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>>
>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* [openstack-dev] [ironic] inclusion of
>> openstack/networking-generic-switch project under OpenStack baremetal
>> program
>>
>>
>>
>> Hi all,
>>
>>
>>
>> as this topic it was recently brought up in ironic IRC meeting, I'd like
>> to start a discussion on the subject.
>>
>>
>>
>> A quick recap - networking-generic-switch project (n-g-s) was born out of
>> necessity to do two things:
>>
>>
>>
>> -  test the "network isolation for baremetal nodes" (a.k.a.
>> multi-tenancy) feature of ironic on upstream gates in virtualized
>> environment and
>>
>> - do the same on cheap/simple/dumb hardware switches that are not
>> supported by other various openstack/networking-* projects.
>>
>>
>>
>> Back when it was created AFAIR neutron governance (neutron stadium) was
>> under some changes, so in the end n-g-s ended up not belonging to any
>> official program.
>>
>>
>>
>> Over time n-g-s grew to be an essential part of ironic gate testing
>> (similar to virtualbmc). What's more, we have reports that it is already
>> being used in production.
>>
>>
>>
>> Currently the core reviewers team of n-g-s consists of 4 people (2 of
>> those are currently core reviewers in ironic too), all of them are working
>> for the same company (Mirantis). This poses some risk as companies and
>> people come and go, plus since some voting ironic gate jobs depend on n-g-s
>> stability, a more diverse group of core reviewers from baremetal program
>> might be beneficial to be able to land patches in case of severe gate
>> troubles.
>>
>>
>>
>> Currently I know of 3 proposed ways to change the current situation:
>>
>>
>>
>> 1) include n-g-s under ironic (OpenStack Baremetal program) governance,
>> effectively including ironic-core team to the core team of  n-g-s similar
>> to how ironic-inspector currently governed (keeping an extended sub-core
>> team). Reasoning for addition is the same as with virtualbmc/sushy
>> projects, with the debatable difference that the actual scope of n-g-s is
>> quite bigger and apparently includes production use-cases;
>>
>>
>>
>> 2) keep things as they are now, just add ironic-stable-maint team to the
>> n-g-s core reviewers to decrease low diversity risks;
>>
>>
>>
>> 3) merge the code from n-g-s into networking-baremetal project which is
>> already under ironic governance.
>>
>>
>>
>> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
>> fond of 3) as it kind of stretches the networking-baremetal scope too much
>> IMHO.
>>
>>
>>
>> Eager to hear your comments and proposals.
>>
>>
>>
>> Cheers,
>>
>> --
>>
>> Dr. Pavlo Shchelokovskyy
>>
>> Senior Software Engineer
>>
>> Mirantis Inc
>>
>> www.mirantis.com
>>
>>
 I'm good with 1 or 2. Since we have two 1's and no nays (so far), let's go
with 1 and move on :)

Thanks for bringing this up!

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

Re: [openstack-dev] [oslo][oslo.config] pluggable drivers for oslo.config spec ready for review

[Jay Pipes]

On 11/20/2017 10:19 AM, Doug Hellmann wrote:

The spec for adding pluggable drivers to oslo.config is ready for a
final queens review [1]. The latest draft should be simpler to implement
(important given where we are in the schedule) at the expense of always
requiring at least one configuration file to specify the location of
other configuration sources. We can improve on that design in the future
when we have the drivers working.


Hi Doug. Is this spec crucial for various PCI/security-minded folks to 
review due to how plaintext configuration options are currently handled 
for sensitive things like password and user/project IDs?


Best,
-jay

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

[openstack-dev] [Neutron][L3-subteam] Weekly IRC meeting cancelled on November 23rd

[Miguel Lavalle]

Dear L3-subteam,

Due to the Thanksgiving Holiday in the US, we will cancel our weekly
meeting on November 23rd. We will resume normally on the 30th

Regards

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

[openstack-dev] [oslo][oslo.config] pluggable drivers for oslo.config spec ready for review

[Doug Hellmann]

The spec for adding pluggable drivers to oslo.config is ready for a
final queens review [1]. The latest draft should be simpler to implement
(important given where we are in the schedule) at the expense of always
requiring at least one configuration file to specify the location of
other configuration sources. We can improve on that design in the future
when we have the drivers working.

Doug

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

__
OpenStack Development Mailing 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] [Infra][Cinder] DataCore CI

[Mikhail Kebich]

Hello Infra Team,

We have deployed DataCore CI to test changes in the Cinder project with the
DataCore Volume Driver.

You can find an information about the DataCore CI system at:
https://wiki.openstack.org/wiki/ThirdPartySystems/DataCore_CI

Logs are available at:
http://173.221.96.158/

Could you please grant permission to the datacore-cinder-ci account to post
comments on changes in the Cinder project?

Thanks in advance,
Mikhail Kebich
__
OpenStack Development Mailing 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] [mistral][ptl] PTL is on vacation from Nov 23 till Dec 4

[Dougal Matthews]

On 20 November 2017 at 08:56, Renat Akhmerov 
wrote:

> Hi,
>
> I’ll be on vacation from Nov 23 till Dec 4, inclusive. Dougal Matthews
> (d0gal) will be replacing me during this period.
>

It doesn't matter too much, but it is d0ugal if anyone is looking for me on
IRC :-)


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

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

[Sławomir Kapłoński]

Hi,

Tomorrow I will be on OpenStack Day in France so I will not be able to chair 
QoS meeting. Sorry.
Next meeting should be normally at 5.12.2017.

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




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

[openstack-dev] [murano] Cancel murano weekly meeting(11/21)

[Rong Zhu]

Hi, teams

let's skip the 21 Nov meeting due to China Bug Smash at Wuhan.


Thanks,
Rong Zhu

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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [QA] Proposal for a QA SIG

[Thierry Carrez]

Rochelle Grober wrote:
> Thierry Carrez wrote:
>> One question I have is whether we'd need to keep the "QA" project team at
>> all. Personally I think it would create confusion to keep it around, for no 
>> gain.
>> SIGs code contributors get voting rights for the TC anyway, and SIGs are free
>> to ask for space at the PTG... so there is really no reason (imho) to keep a
>> "QA" project team in parallel to the SIG ?
> 
> Well, you can get rid of the "QA Project Team" but you would then need to 
> replace it with something like the Tempest Project, or perhaps the Test 
> Project.  You still need a PTL and cores to write, review and merge tempest 
> fixes and upgrades, along with some of the tests.  The Interop Guideline 
> tests are part of Tempest because being there provides oversight on the style 
> and quality of the code of those tests.  We still need that.

SIGs can totally produce some code (and have review teams), but I agree
that in this case this code is basically a part of "the product" (rather
than a tool produced by guild of practitioners) and therefore makes
sense to be kept in an upstream project team. Let's keep things the way
they are, while we work out other changes that may trigger other
organizational shuffles (like reusing our project infrastructure beyond
just OpenStack).

I wonder if we should not call the SIG under a different name to reduce
the confusion between QA-the-project-team and QA-the-SIG. Collaborative
Testing SIG?

-- 
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] [mistral][ptl] PTL is on vacation from Nov 23 till Dec 4

[Renat Akhmerov]

Hi,

I’ll be on vacation from Nov 23 till Dec 4, inclusive. Dougal Matthews (d0gal) 
will be replacing me during this period.

Thanks

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