from:"Dmitry"


On 03/14/2018 01:33 PM, Frank Kloeker wrote:

Hi,

it's critical, I would say. They canceled the registration just today [1], but 
there are still copyrights for name parts like  "S-Bahn Halleipzig". I would 
remove it from the voting list to prevent us from trouble. S-Bahn is not really 
a location in Berlin. If it does, S-Bahn is broken ;-)


And it often is /me looks at S42 schedule :D

Actually, I agree, a means of transport is not quite a location.



kind regards

Frank (from Berlin)

[1] https://register.dpma.de/DPMAregister/marke/registerHABM?AKZ=007392194

Am 2018-03-14 13:14, schrieb Jeremy Freudberg:

Hi Dmitry,

According to Wikipedia [0] the trademark was removed. The citation [1]
is actually inaccurate; it was not the final ruling. Regardless [2]
seems to reflect the final result which is that the trademark is
cancelled.

Hope this helps.

[0]
https://en.wikipedia.org/wiki/S-train#Germany,_Austria_and_Switzerland
(end of paragraph
[1]
http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg=en=Aktuell=23159=1=323=1.pdf 


[2]
http://www.eurailpress.de/news/bahnbetrieb/single-view/news/bundesgerichtshof-db-verliert-marke-s-bahn.html 



On Wed, Mar 14, 2018 at 7:50 AM, Dmitry Tantsur <dtant...@redhat.com>
wrote:


Hi,

I suspect that S-Bahn may be a protected (copyright, trademark,
whatever) name. Did you have a chance to check it?

On 03/14/2018 12:58 AM, Paul Belanger wrote:


Greetings all,

It is time again to cast your vote for the naming of the S
Release. This time
is little different as we've decided to use a public polling
option over per
user private URLs for voting. This means, everybody should proceed
to use the
following URL to cast their vote:





https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3 


[1]

Because this is a public poll, results will currently be only
viewable by myself
until the poll closes. Once closed, I'll post the URL making the
results
viewable to everybody. This was done to avoid everybody seeing the
results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and
results will be
posted shortly after.

[1]



http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst 


[2]
---

According to the Release Naming Process, this poll is to determine
the
community preferences for the name of the R release of OpenStack.
It is
possible that the top choice is not viable for legal reasons, so
the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic
Latin alphabet
following the initial letter of the previous release, starting
with the
initial release of "Austin". After "Z", the next name should start
with
"A" again.

The name must be composed only of the 26 characters of the ISO
basic Latin
alphabet. Names which can be transliterated into this character
set are also
acceptable.

The name must refer to the physical or human geography of the
region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic
region under
consideration must be declared before the opening of nominations,
as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters.
Words that
describe the feature should not be included, so "Foo City" or "Foo
Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really
cool
should be added to a separate section of the wiki page and the TC
may make
an exception for one or more of them to be considered in the
Condorcet poll.
The naming official is responsible for presenting the list of
exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come
is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and
Berlin states of
Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around
Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be
conveniently
abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing
house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in
Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding
neighborhood)
(The adjective form, Saatwinkler is also a really cool
bridge but
that form is too long)

Sonne (Sonnenallee is the name of a large street i

Re: [openstack-dev] [tripleo] Blueprints for Rocky


Hi Alex,

I have two small ironic-related blueprints pending approval:
https://blueprints.launchpad.net/tripleo/+spec/ironic-rescue
https://blueprints.launchpad.net/tripleo/+spec/networking-generic-switch

and one larger:
https://blueprints.launchpad.net/tripleo/+spec/ironic-inspector-overcloud

Could you please check them?

I would also like to talk about possibility to enable cleaning by default in the 
undercloud, but I guess it deserves a separate thread.


On 03/13/2018 02:58 PM, Alex Schultz wrote:

Hey everyone,

So we currently have 63 blueprints for currently targeted for
Rocky[0].  Please make sure that any blueprints you are interested in
delivering have an assignee set and have been approved.  I would like
to have the ones we plan on delivering for Rocky to be updated by
April 3, 2018.  Any blueprints that have not been updated will be
moved out to the next cycle after this date.

Thanks,
-Alex

[0] https://blueprints.launchpad.net/tripleo/rocky

__
OpenStack Development Mailing 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] [tripleo] TLS by default

Just to clarify: only for public endpoints, right? I don't think e.g. 
ironic-python-agent can talk to self-signed certificates yet.


On 03/14/2018 07:03 AM, Juan Antonio Osorio wrote:

Hello,

As part of the proposed changed by the Security Squad [1], we'd like the 
deployment to use TLS by default.


The first target is to get the undercloud to use it, so a patch has been 
proposed recently [2] [3]. So, just wanted to give a heads up to people.


This should be just fine from a quickstart/testing point of view, since we 
explicitly set the value for autogenerating certificates in the undercloud [4] [5].


Note that there are also plans to change these defaults for the containerized 
undercloud and the overcloud.


BR

[1] https://etherpad.openstack.org/p/tripleo-security-squad
[2] https://review.openstack.org/#/c/552382/
[3] https://review.openstack.org/552781
[4] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/extras-common/defaults/main.yml#L15
[5] 
https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/undercloud-deploy/templates/undercloud.conf.j2#L117

--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



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




__
OpenStack Development Mailing 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] Poll: S Release Naming


On 03/14/2018 10:05 AM, Thierry Carrez wrote:

Jens Harbott wrote:

2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński :

Hi,

Are You sure this link is good? I just tried it and I got info that "Already 
voted" which isn't true in fact :)


Comparing with previous polls, these should be personalized links that
need to be sent out to each voter individually, so I agree that this
looks like a mistake.


We crashed CIVS for the last naming with a private poll sent to all the
Foundation membership, so the TC decided to use public (open) polling
this time around. Anyone with the link can vote, nothing was sent to
each of the voters individually.

The "Already voted" error might be due to CIVS limiting public polling
to one entry per IP, and a colleague of yours already voted... Maybe try
from another IP address ?



I don't think every small company has an unlimited pool of IP addresses.. 
Neither do people working from home from a big internet provider.


__
OpenStack Development Mailing 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] Poll: S Release Naming


Hi,

I suspect that S-Bahn may be a protected (copyright, trademark, whatever) name. 
Did you have a chance to check it?


On 03/14/2018 12:58 AM, Paul Belanger wrote:

Greetings all,

It is time again to cast your vote for the naming of the S Release. This time
is little different as we've decided to use a public polling option over per
user private URLs for voting. This means, everybody should proceed to use the
following URL to cast their vote:

   
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3

Because this is a public poll, results will currently be only viewable by myself
until the poll closes. Once closed, I'll post the URL making the results
viewable to everybody. This was done to avoid everybody seeing the results while
the public poll is running.

The poll will officially end on 2018-03-21 23:59:59[1], and results will be
posted shortly after.

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
---

According to the Release Naming Process, this poll is to determine the
community preferences for the name of the R release of OpenStack. It is
possible that the top choice is not viable for legal reasons, so the second or
later community preference could wind up being the name.

Release Name Criteria

Each release name must start with the letter of the ISO basic Latin alphabet
following the initial letter of the previous release, starting with the
initial release of "Austin". After "Z", the next name should start with
"A" again.

The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are also
acceptable.

The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part of
the initiation of the selection process.

The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may make
an exception for one or more of them to be considered in the Condorcet poll.
The naming official is responsible for presenting the list of exceptional
names for consideration to the TC before the poll opens.

Exact Geographic Region

The Geographic Region from where names for the S release will come is Berlin

Proposed Names

Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
Germany)

SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)

Spandau (One of the twelve boroughs of Berlin)

Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
abbreviated as )

Steglitz (a locality in the South Western part of the city)

Springer (Berlin is headquarters of Axel Springer publishing house)

Staaken (a locality within the Spandau borough)

Schoenholz (A zone in the Niederschönhausen district of Berlin)

Shellhaus (A famous office building)

Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)

Schiller (A park in the Mitte borough)

Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
(The adjective form, Saatwinkler is also a really cool bridge but
that form is too long)

Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
wall, also translates as "sun")

Savigny (Common place in City-West)

Soorstreet (Street in Berlin restrict Charlottenburg)

Solar (Skybar in Berlin)

See (Seestraße or "See Street" in Berlin)

Thanks,
Paul

__
OpenStack Development Mailing 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] PTG Summary

2018-03-12 Thread Dmitry Tantsur

Inline.

On 03/12/2018 01:00 PM, Tim Bell wrote:

My worry with re-running the burn-in every time we do cleaning is for resource 
utilisation. When the machines are running the burn-in, they're not doing 
useful physics so I would want to minimise the number of times this is run over 
the life time of a machine.

You only have to run it every time if you put the step into automated cleaning. 
However, we also have manual cleaning, which is run explicitly.

It may be possible to do something like the burn in with a dedicated set of 
steps but still use the cleaning state machine.

Yep, this is what manual cleaning is about: an operator explicitly requests it 
with a given set of steps. See 
https://docs.openstack.org/ironic/latest/admin/cleaning.html#manual-cleaning

Having a cleaning step set (i.e. burn-in means 
cpuburn,memtest,badblocks,benchmark) would make it more friendly for the 
administrator. Similarly, retirement could be done with additional steps such 
as reset2factory.

++

We may even add a reference set of clean steps to IPA, but we'll need your help 
implementing them. I am personally not familiar with how to do burn-in right 
(though IIRC Julia is).

Tim

-Original Message-
From: Dmitry Tantsur <dtant...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 12 March 2018 at 12:47
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ironic] PTG Summary

 Hi Tim,

 Thanks for the information.

 I personally don't see problems with cleaning running weeks, when needed. What

 I'd avoid is replicating the same cleaning machinery but with a different 
name.
 I think we should try to make cleaning work for this case instead.

 Dmitry

 On 03/12/2018 12:33 PM, Tim Bell wrote:

 > Julia,
 >
 > A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html
 >
 > Given that the burn in takes weeks to run, we'd see it as a different 
step to cleaning (with some parts in common such as firmware upgrades to latest 
levels)
 >
 > Tim
 >
 > -Original Message-
 > From: Julia Kreger <juliaashleykre...@gmail.com>
 > Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
 > Date: Thursday, 8 March 2018 at 22:10
 > To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
 > Subject: [openstack-dev] [ironic] PTG Summary
 >
 > ...
 >  Cleaning - Burn-in
 >
 >  As part of discussing cleaning changes, we discussed supporting a
 >  "burn-in" mode where hardware could be left to run load, memory, or
 >  other tests for a period of time. We did not have consensus on a
 >  generic solution, other than that this should likely involve
 >  clean-steps that we already have, and maybe another entry point into
 >  cleaning. Since we didn't really have consensus on use cases, we
 >  decided the logical thing was to write them down, and then go from
 >  there.
 >
 >  Action Items:
 >  * Community members to document varying burn-in use cases for
 >  hardware, as they may vary based upon industry.
 >  * Community to try and come up with a couple example clean-steps.
 >
 >
 >
 > 
__
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >

 __

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

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

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

Re: [openstack-dev] [ironic] PTG Summary

2018-03-12 Thread Dmitry Tantsur


Hi Tim,

Thanks for the information.

I personally don't see problems with cleaning running weeks, when needed. What 
I'd avoid is replicating the same cleaning machinery but with a different name. 
I think we should try to make cleaning work for this case instead.


Dmitry

On 03/12/2018 12:33 PM, Tim Bell wrote:

Julia,

A basic summary of CERN does burn-in is at 
http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html

Given that the burn in takes weeks to run, we'd see it as a different step to 
cleaning (with some parts in common such as firmware upgrades to latest levels)

Tim

-Original Message-
From: Julia Kreger <juliaashleykre...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, 8 March 2018 at 22:10
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [ironic] PTG Summary

...
 Cleaning - Burn-in
 
 As part of discussing cleaning changes, we discussed supporting a

 "burn-in" mode where hardware could be left to run load, memory, or
 other tests for a period of time. We did not have consensus on a
 generic solution, other than that this should likely involve
 clean-steps that we already have, and maybe another entry point into
 cleaning. Since we didn't really have consensus on use cases, we
 decided the logical thing was to write them down, and then go from
 there.
 
 Action Items:

 * Community members to document varying burn-in use cases for
 hardware, as they may vary based upon industry.
 * Community to try and come up with a couple example clean-steps.
 
 


__
OpenStack Development Mailing 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] [ironic] heads-up: classic drivers deprecation and future removal

2018-03-06 Thread Dmitry Tantsur


Hi all,

As you may already know, we have deprecated classic drivers in the Queens 
release. We don't have specific removal plans yet. But according to the 
deprecation policy we may remove them at any time after May 1st, which will be 
half way to Rocky milestone 2. Personally, I'd like to do it around then.


The `online_data_migrations` script will handle migrating nodes, if all required 
hardware interfaces and types are enabled before the upgrade to Queens. 
Otherwise, check the documentation [1] on how to update your nodes.


Dmitry

[1] 
https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.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] [tripleo] Queens RC1 was released!

2018-03-05 Thread Dmitry Tantsur


Hi!

A reminder that https://review.openstack.org/534842 is quite important, as it 
will enable upgrade to hardware types from classic drivers. The latter will be 
removed in one of the future releases. As it applies to online_data_migrations 
it will not be run after you upgrade to Queens without this patch.


On 03/05/2018 09:17 AM, Emilien Macchi wrote:

TripleO team is proud to announce that we released Queens RC1!

Some numbers:
210 bugs fixed
7 features implemented

In Pike RC1:
138 bug fixed
8 features implemented

In Ocata RC1:
62 bug fixed
7 features implemented

In Newton RC1:
51 bug fixed
11 features implemented


Unless we find a need to do it, we won't release RC2, but we'll see how it works 
during the next days.

We encourage people to backport their bugfixes to stable/queens.
Also all work related to FFU & upgrades is moving to rocky-1 but we expect the 
patches to be backported into stable/queens.


Reminder: backports to stable/queens should be done by patches authors to help 
PTL & TripleO stable maintainers.


Thanks and nice work everyone!
--
Emilien Macchi


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




__
OpenStack Development Mailing 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] Polling for new meeting time?

2018-03-05 Thread Dmitry Tantsur


On 03/04/2018 09:46 PM, Zhipeng Huang wrote:

Thx Julia,

Another option is instead of changing meeting time, you could establish a 
tick-tock meeting, for example odd weeks for US-Euro friendly times and even 
weeks for US-Asia friendly times.


We tried that roughly two years ago, and it did not work because very few people 
showed up on the APAC time. I think the goal of this poll is to figure out how 
many people would show up now.




On Mar 4, 2018 7:01 PM, "Julia Kreger" > wrote:


Greetings everyone!

As our community composition has shifted to be more global, the
question has arisen if we should consider shifting the meeting to be
more friendly to some of our contributors in the APAC time zones.
Alternatively this may involve changing our processes to better plan
and communicate, but the first step is to understand our overlaps and
what might work well for everyone.

I have created a doodle poll, from which I would like understand what
times would ideally work, and from there we can determine if there is
a better time to meet.

The poll can be found at: https://doodle.com/poll/6kuwixpkkhbwsibk


Please don't feel the need to select times that would be burdensome to
yourself. This is only to gather information as to the time of day
that would be ideal for everyone. All times are set as UTC on the
poll.

Once we have collected some data, we should expect to discuss during
our meeting on the 12th.

Thanks everyone!

-Julia

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

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




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




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

Re: [openstack-dev] [ironic] Polling for new meeting time?

2018-03-05 Thread Dmitry Tantsur


On 03/04/2018 07:00 PM, Julia Kreger wrote:

Greetings everyone!

As our community composition has shifted to be more global, the
question has arisen if we should consider shifting the meeting to be
more friendly to some of our contributors in the APAC time zones.
Alternatively this may involve changing our processes to better plan
and communicate, but the first step is to understand our overlaps and
what might work well for everyone.

I have created a doodle poll, from which I would like understand what
times would ideally work, and from there we can determine if there is
a better time to meet.

The poll can be found at: https://doodle.com/poll/6kuwixpkkhbwsibk

Please don't feel the need to select times that would be burdensome to
yourself. This is only to gather information as to the time of day
that would be ideal for everyone. All times are set as UTC on the
poll.


Are you sure? I'm asking because the last time I checked Doodle created all 
polls in some specific time, defaulting to your local time. Then for each 
participant it converts the times to their local time. E.g. for me the time span 
is 1am to to 12am Berlin time (UTC+1), is it what you expected?




Once we have collected some data, we should expect to discuss during
our meeting on the 12th.

Thanks everyone!

-Julia

__
OpenStack Development Mailing 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] Stepping down from Ironic core

2018-02-23 Thread Dmitry Tantsur


Hi Vasyl,

I'm sad to hear it :( Thank YOU for everything! The only thing in the world more 
valuable than your contributions to ironic is the joy of hanging out with you at 
the events :) Good luck and do not disappear.


Dmitry

On 02/23/2018 10:02 AM, Vasyl Saienko wrote:

Hey Ironic community!

Unfortunately I don't work on Ironic as much as I used to any more, so i'm
stepping down from core reviewers.

So, thanks for everything everyone, it's been great to work with you
all for all these years!!!


Sincerely,
Vasyl Saienko


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

2018-02-08 Thread Dmitry Tantsur


On 02/07/2018 10: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?


We do plan to use it, we just never had time to populate it :(



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]

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

2018-02-07 Thread 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] [ironic] Nominating Hironori Shiina for ironic-core

2018-02-06 Thread Dmitry Tantsur


+1

On 02/05/2018 07:12 PM, Julia Kreger wrote:

I would like to nominate Hironori Shiina to ironic-core. He has been
working in the ironic community for some time, and has been helping
over the past several cycles with more complex features. He has
demonstrated an understanding of Ironic's code base, mechanics, and
overall community style. His review statistics are also extremely
solid. I personally have a great deal of trust in his reviews.

I believe he would make a great addition to our team.

Thanks,

-Julia

__
OpenStack Development Mailing 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] [ironic] driver composition: help needed from vendors

2018-02-05 Thread Dmitry Tantsur


Hi everyone,

We have landed changes deprecating classic drivers, and we may remove classic 
drivers as early as end of Rocky. I would like to ask those who maintain drivers 
for ironic a few favors:


1. We have landed a database migration [1] to change nodes from classic drivers 
to hardware types automatically. Please check the mapping [2] for your drivers 
for correctness.


2. Please update your documentation pages to primarily use hardware types. 
You're free to still mention classic drivers or remove the information about 
them completely.


3. Please update your CI to use hardware types on master (queens and newer). 
Please make sure that the coverage does not suffer. For example, if you used to 
test pxe_foo and agent_foo, the updates CI should test "foo" hardware type with 
"iscsi" and "direct" deploy interfaces.


Please let us know if you have any concerns.

Thanks,
Dmitry

[1] https://review.openstack.org/534373
[2] https://review.openstack.org/539589

__
OpenStack Development Mailing 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 sushy bug-fix release

2018-02-05 Thread Dmitry Tantsur


Hi all,

I'm requesting an exception to proceed with the release of the sushy library. To 
my best knowledge, the library is only consumed by ironic and at least one other 
vendor support library which is outside of the official governance. The release 
request is [1]. It addresses a last minute bug in the authentication code, 
without it authentication will not work in some cases.


Thanks,
Dmitry

[1] https://review.openstack.org/540824

P.S.
We really need a feature freeze period for libraries to avoid this.. But it 
cannot be introduced with the current library release freeze. Another PTG topic? :)


__
OpenStack Development Mailing 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] Not running for PTL this cycle

2018-02-04 Thread Dmitry Tantsur


Hi all,

I guess it's quite obvious already, but I won't be running for PTL position this 
time. It's been a challenging and interesting journey, I've learned a lot, and I 
believe we've achieved a lot together. Now I'd like to get back to calm waters 
and allow others to driver the project forward :) Of course I'm not going 
anywhere far, and I'm ready to help whoever gets this chair with their new 
challenge.


Now a small request: please leave me anonymous feedback at 
https://goo.gl/forms/810u3j8Yh2fymUMG2 that'll help me to improve further :)


Thank you all,
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] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal


On 01/31/2018 06:23 PM, Lance Bragstad wrote:



On 01/31/2018 11:20 AM, Dmitry Tantsur wrote:

Hi!

On 01/31/2018 06:16 PM, Lance Bragstad wrote:

Hey folks,

The tracking tool for the policy-and-docs-in-code goal for Queens [0]
lists a couple projects remaining for the goal [1].  I wanted to start a
discussion with said projects to see how we want to go about the work in
the future, we have a couple of options.


I was under assumption that ironic has finished this goal. I'll wait
for pas-ha to weigh in, but I was not planning any activities for it.

It looks like there is still an unmerged patch tagged with the
policy-and-docs-in-code topic [0].

[0]
https://review.openstack.org/#/q/is:open+topic:policy-and-docs-in-code+project:openstack/ironic


But is it required? We've marked the goal as done already, and pas-ha is no 
longer working on it AFAIK.






I can update the document the goal document saying the work is still
underway for those projects. We can also set aside time at the PTG to
finish up that work if people would like more help. This might be
something we can leverage the baremetal/vm room for if we get enough
interest [2].


Mmm, the scope of the bm/vm room is already unclear to me, this may
add to the confusion. Maybe just a "Goals workroom"?



I want to get the discussion rolling if there is something we need to
coordinate for the PTG. Thoughts?

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.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 Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





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




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

Re: [openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

On 01/31/2018 06:15 PM, Matt Riedemann wrote:

On 1/30/2018 9:33 AM, Colleen Murphy wrote:

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?

From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1]
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true

[2]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html

[3]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html

[4]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html

These all seem like good topics for big cross-project issues.

I've never liked the "BM/VM" platform naming thing, it seems to imply that the
only things one needs to care about for these discussions is if they work on or
use nova and ironic, and that's generally not the case.

++ can we please rename it? I think people (myself included) will expect
specifically something related to bare metal instances co-existing with virtual
ones (e.g. scheduling or networking concerns). Which is also a great topic, but
it does not seem to be present on the list.

So if you do have a session about this really cross-project platform-specific
stuff, can we at least not call it "BM/VM"? Plus, "BM" always makes me think of
something I'd rather not see in a room with other people.

Re: [openstack-dev] [barbican] [glance] [ironic] [neutron] [tacker] [tc] policy in code goal


Hi!

On 01/31/2018 06:16 PM, Lance Bragstad wrote:

Hey folks,

The tracking tool for the policy-and-docs-in-code goal for Queens [0]
lists a couple projects remaining for the goal [1].  I wanted to start a
discussion with said projects to see how we want to go about the work in
the future, we have a couple of options.


I was under assumption that ironic has finished this goal. I'll wait for pas-ha 
to weigh in, but I was not planning any activities for it.




I can update the document the goal document saying the work is still
underway for those projects. We can also set aside time at the PTG to
finish up that work if people would like more help. This might be
something we can leverage the baremetal/vm room for if we get enough
interest [2].


Mmm, the scope of the bm/vm room is already unclear to me, this may add to the 
confusion. Maybe just a "Goals workroom"?




I want to get the discussion rolling if there is something we need to
coordinate for the PTG. Thoughts?

Thanks,

Lance


[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://www.lbragstad.com/policy-burndown/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126743.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 Development Mailing 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] ansible deploy, playbooks and containers?


Hi all,

I'd like to discuss one idea that came to me while trying to use the ansible 
deploy in TripleO.


The ansible deploy interface is all about customization. Meaning, we expect 
people to modify the playbooks. I have two concerns with it:


1. Nearly any additions requires a full copy of the playbooks. Which will make 
the operators miss any future updates to the shipped version (e.g. from packages).


2. We require operators to modify playbooks on the hard drive in a location, 
available to ironic-conductor. This is inconvenient when there are many 
conductors and quite hairy with containers.


So, what came to my mind is:

1. Let us maybe define some hook points in our playbooks and allow operators to 
overwrite only them? I'm not sure how it's going to look, so suggestions are 
welcome.


2. Let us maybe allow a swift or http(s) URL for the playbooks_path 
configuration? That will be a link to a tarball that will be unpacked by ironic 
to a temporary location before executing.


What do you think?

__
OpenStack Development Mailing 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][ironic] Tagging newton EOL


Hi!

Ironic is ready for newton EOL.

On 01/31/2018 05:17 AM, Tony Breeds wrote:

Hi All,
 When we tagged newton EOL in October there were in-flight reviews
for nova and ironic that needed to land before we could EOL them.  That
work completed but I dropped the ball.  So can we tag those last 2
repos?

As in October a member of the infra team needs to do this *or* I can
be added to Project Bootstrappers[1] for long enough to do this.

# EOL repos belonging to ironic
eol_branch.sh -- stable/newton newton-eol openstack/ironic
# EOL repos belonging to nova
eol_branch.sh -- stable/newton newton-eol openstack/nova

Yours Tony.

[1] https://review.openstack.org/#/admin/groups/26,members




__
OpenStack Development Mailing 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] FFE - classic drivers deprecation

2018-01-23 Thread Dmitry Tantsur

Hi all,

I'm writing to request an FFE for the classic drivers deprecation work [1][2].
This is a part of the driver composition reform [3] - the effort started in
Ocata to revamp bare metal drivers.

The following changes are in scope of this FFE:
1. Provide an automatic migration to hardware types as part of 'ironic-dbsync
online_data_migrations'

2. Update the CI to use hardware types
3. Issue a deprecation warning when loading classic drivers, and deprecate
enabled_drivers option.

Finishing it in Queens will allow us to stick to our schedule (outlined in [1])
to remove classic drivers in Rocky. Keeping two methods of loading drivers is a
maintenance burden. Even worse, two sets of mostly equivalent drivers confuse
users, and the confusion well increase as we introduce features (like rescue)
that are only available for nodes using the new-style drivers.

The downside of this work is that it introduces a non-trivial data migration
close to the end of the cycle. Thus, it is designed [1][2] to not fail if the
migration cannot fully succeed due to environmental reasons.

rloo and stendulker were so kind to agree to review this work during the feature
freeze window, if it gets an exception.

Dmitry

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/classic-drivers-future.html

[2] https://review.openstack.org/536298
[3]
http://specs.openstack.org/openstack/ironic-specs/specs/7.0/driver-composition-reform.html

Re: [openstack-dev] [ironic] FFE request for node rescue feature

2018-01-23 Thread Dmitry Tantsur

I'm +1 on this, because the feature has been proposed for a while (has changed
the contributor group at least once) and is needed for feature parity with
virtual machines in nova.

On 01/23/2018 06:56 AM, Shivanand Tendulker wrote:

The rescue feature [1] is an high priority for ironic in Queens. The spec for
the same was merged in Newton. This feature is necessary for users that lose
regular access to their machine (e.g. lost passwords).

Landing node rescue feature late in the cycle will lead to less time being
available for testing, with a risk that the feature being released with defects.
The code changes are fairly isolated from existing code to ensure it does not
cause any regression. The Ironic side rescue code patches are all in review [2],
and are now are getting positive reviews or minor negative feedback.

dtantsur and TheJulia have kindly agreed to review the same during the FFE
window.

[1]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/implement-rescue-mode.html
[2]
https://review.openstack.org/#/q/topic:bug/1526449+(status:open+AND+project:openstack/ironic)

Thanks and Regards,
Shiv (stendulker)

Re: [openstack-dev] [ironic] FFE request for node traits

2018-01-23 Thread Dmitry Tantsur

+1 on keeping moving forward with it. that's important for future nova work, as 
well as our deploy steps work.


On 01/22/2018 10:11 PM, Mark Goddard wrote:
The node traits feature [1] is an essential priority for ironic in Queens, and 
is an important step in the continuing evolution of scheduling enabled by the 
placement API. Traits will allow us to move away from capability-based 
scheduling. Capabilities have several limitations for scheduling including 
depending on filters in nova-scheduler rather than allowing placement to select 
matching hosts. Several upcoming features depend on traits [2].


Landing node traits late in the cycle will lead to less time being available for 
testing, with a risk that the feature is release with defects. There are changes 
at most major levels in the code except the drivers, but these are for the most 
part fairly isolated from existing code. The current issues with the grenade CI 
job mean that upgrade code paths are not being exercised frequently, and could 
lead to additional test/bug fix load on the team later in the cycle. The node 
traits code patches are all in review [3], and are now generally getting 
positive reviews or minor negative feedback.


rloo and TheJulia have kindly offered to review during the FFE window.

[1] 
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/node-traits.html
[2] 
https://review.openstack.org/#/c/504952/7/specs/approved/config-template-traits.rst

[3] https://review.openstack.org/#/q/topic:bug/1722194+(status:open)

Thanks,
Mark (mgoddard)


__
OpenStack Development Mailing 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] [ironic] Deadlines, feature freeze and exceptions


Hi all!

We're near the end of the cycle. Here are some important dates to be mindful of:

Thu, Jan 25th - final Queens releases of python-ironicclient and 
python-ironic-inspector-client. Any features that land after that point will get 
to Rocky, no exceptions. Yes, even if the API itself lands in ironic in Queens.


Thu, Jan 25th - begin of the feature freeze for ironic and many other projects. 
No features should land after that date without getting a formal exception first 
- please pay attention when approving the patches. A procedure for a feature 
freeze exception is outlined below.


Fri, Feb 2nd - hard feature freeze. All features with an exception must land by 
this point. Starting with Monday and until the branching we only land bug fixes 
and documentation updates to master.


Thu, Feb 8th - final feature releases for all remaining projects and creation of 
stable/queens. At this point the feature freeze is lifted and master is opened 
for Rocky development.


Now, how to request a feature freeze exception. Please:

* Send a email to this mailing list, with [ironic] and FFE in its subject.
* Outline the reason why you think the feature should go to Queens, and what are 
the downsides. Keep in mind that no API additions will get client support after 
this Thursday.

* Evaluate and explain the risks of landing the feature so late in the cycle.
* Finally, please find at least two cores that agree to review your changes 
during the feature freeze window, and include their names. This is important, we 
don't need FFEs that won't get reviewed.


Happy hacking,
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] [ironic] FFE - Requesting FFE for Routed Networks support.

This FFE was approved on today's meeting. Please note that the deadline to
merging it is Fri, Feb 2nd.

On 01/17/2018 10:54 AM, Harald Jensås wrote:

Requesting FFE for Routed Network support in networking-baremetal.
---

# Pros
--
With the patches up for review[7] we have a working ml2 agent;
__depends on neutron fix__; and mechanism driver combination that
enables support to bind ports on neutron routed networks.

Specifically we report the bridge_mappings data to neutron, which
enable the _find_candidate_subnets() method in neutron ipam[1] to
succeed in finding a candidate subnet available to the ironic node when
ports on routed segments are bound.

This functionality will allow users to take advantage of the
functionality added in DHCP Agent[2] which enables the DHCP agent to
service other subnets on the network via DHCP relay. For Ironic this
means we can support deploying nodes on a remote L3 network, e.g
different datacenter or different rack/rack-row.

# Cons
--
Integration with placement does not currently work.

Neutron uses Nova host-aggregates in combination with Placement.
Specifically hosts are added to a host-aggregate for segments based on
SEGMENT_HOST_MAPPING. Ironic nodes cannot currently be added to host-
aggregates in Nova. Because of this the following will appear in the
neutron logs when ironic-neutron agent is started:
RESP BODY: {"itemNotFound": {"message": "Compute host could not be found.", "code": 404}}

Also the placement api cannot be used to find good candidate ironic
nodes with a baremetal port on the correct segment. This will have to be worked
around by the operator via capabilities and flavor properties or manual
additions to resource providers in placement.

Depending on the direction of other projects, neutron and nova, the way
placement will finally work is not certain.

Either the nova work [3] and [4], or a neutron change to use placement
only or a fallback to placement in neutron would be possible. In either
case there should be no need to change the networking-baremetal agent
or mechanism driver.

# Risks
---
Unless this bug[5] is fixed we might break the current baremetal
mechanism driver functionality. I have proposed a patch[6] to neutron
that fix the issue. In case no fix lands for this neutron bug soon we
should probably push these changes to Rocky.

# Core reviewers

Julia Kreger, Sam Betts

[1] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/ip
am_backend_mixin.py#n697
[2] https://review.openstack.org/#/c/468744/
[3] https://review.openstack.org/#/c/421009/
[4] https://review.openstack.org/#/c/421011/
[5] https://bugs.launchpad.net/neutron/+bug/1743579
[6] https://review.openstack.org/#/c/534449/
[7] https://review.openstack.org/#/q/project:openstack/networking-barem
etal

Re: [openstack-dev] [ironic] Remove in-tree policy and config?


+1

I would really hate to not have a place to reference people to, but the 
documentation now provides such place. Keeping the examples up-to-date is quite 
annoying, I'm all for dropping them.


On 01/22/2018 01:45 PM, John Garbutt wrote:

Hi,

While I was looking at the traits work, I noticed we still have policy and 
config in tree for ironic and ironic inspector:


http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/ironic.conf.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json

And in a similar way:
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/policy.yaml.sample
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf

There is an argument that says we shouldn't force operators to build a full 
environment to generate these, but this has been somewhat superseded by us 
having good docs:


https://docs.openstack.org/ironic/latest/configuration/sample-config.html
https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-config.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-policy.html

It could look something like this (but with the tests working...):
https://review.openstack.org/#/c/536349

What do you all think?

Thanks,
johnthetubaguy


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




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

Re: [openstack-dev] [release] Lib branching for stable/queens